[b.....h]

#programowanie #webdev
potrzebuje pomyslow na cos takiego: mam zamiar przechowywac duuuuzo danych, zalozmy do 500 znakow w kazdym wpisie, wpisow zalozmy ze bedzie 3 miliony, i tutaj zaczynaja sie pytania
lepiej uzyc bazy danych, czy po prostu na plikach operowac - co bedzie szybsze, zajmowalo mniej miejsca dla wielu wpisow?
czy oplaca sie kompresowac stosunkowo krotkie teksty (ok 500 znakow), czy koszt dekompresji jest niewspolmierny do zysku przestrzeni?

[Spisssek]

@blowfish: Lepiej, bazę danych, bo na pliku to musisz cały wczytać żeby przeszukać.
No chyba, że każdy wpis = osobny plik

[japer]

@blowfish: Bazy. Bazy mają lepsze zarządzanie takimi rzeczami. Często sobie blobują takie dane, cacheują, więc lepiej baza. Używać będziesz serwera, czy coś pokroju sqlite?

[b.....h]

@Spisssek: myslalem zeby do kazdego linku po znormalizowaniu go robic osobny plik, w sensie strona dziala zalozmy tak:
sttoma.pl/wykop.pl/user/sratata
i tworze plik wykop.pl/uset/sratata i zapisuje tam dane, potem jak ktos wejdzie pod dany link, to wypisuje dany plik

[j.....s]

@blowfish: umieszczając w bazie pomijasz indeksowanie całego pliku do wyszukania konkretnego ciągu znaków. Baza danych jest zdecydowanie lepsza. Jej typ - zależy już od Ciebie :)

[b.....h]

@japer: serwer, ale na poczatku nie stac mnie na duza przestrzen dyskowa xD

[notauser]

@blowfish: Wydaje mi się, że prawdziwy dylemat tutaj to SQL vs NoSQL(MongoDB)

[A.....h]

@blowfish: Tak jak wyżej, raczej bazy, raczej NoSQL moim zdaniem - przetestuj sobie. W przypadku, który podałeś, niezależnie czy plik/baza, pewnie ogromną robotę zrobi dobrze skonfigurowany cache.

[JavaEngineer]

@notauser: W systemach klasy workflow, systemach DMS, EDMS dokumenty są przechowywane często nie w bazie a na File Systemie = wydajność masz FileSystem ------ Program , Baza korzysta z File systemu operacyjnego i własnego jeśli się nie mylę.

Jeden obiekt bazy danych należy zwykle do jednej przestrzeni tabel i jego zawartość może być zapisana w więcej niż jednym pliku fizycznym w systemie plików.

Podstawową jednostką fizyczną zapisu danych jest blok danych

[Regis86]

@notauser: @Aysorth: Ludzie, 3M wpisów po 500 bajtów to 1.3GB - wy chcecie do tego NoSQL zaprzęgać? Chyba, że w celach edukacyjnych.

@blowfish: Pytanie co zamierzasz z tym później robić, ale na 99% tak czy inaczej odpowiedź to baza

[JavaEngineer]

@Regis86: Taki PostgreSQL da sobie radę z tym ? Czy lepiej MySQL ?

[Regis86]

@JavaEngineer: Pracowałem kiedyś z Postgresem, który miał 120 GB, widziałem takie po 600 GB, a istnieją (tak twierdzi dokumentacja) bazy do 32TB. Na zwykłym lapku kilka-kilkanaście giga pójdzie na luzie. Oczywiście MySQL da sobie radę równie dobrze.

[b.....h]

@Regis86: user wchodzi na strone janusz.pl/cebula
jesli klucz 'cebula' nie istnieje, to wywala ze brak strony, jesli istnieje, to wypisuje dany wpis. zakladam ze wpisy beda krotsze od 500 znakow bo to ma byc tl;dr z roznych stron, tak w skrocie

[JavaEngineer]

@Regis86: No kwestia zależy co on tam będzie robić jak zrobi Selecta z podselectami z joinami itp po tej tabeli z wpisami to może być wolniej, mało napisał ogólnie to ciężki powiedzieć.
Portale stoją na Relacyjnych bazach np, MySQL gdzie wszystkie artykuły, newsy itp zapisane sa plain tekstem w bd

[Regis86]

@blowfish: Przy takim zastosowaniu docelowo może mieć sens użycie Redisa (prosty key-value store), ale na start zawsze SQL. Tańsze w utrzymaniu, a do tego bardziej elastyczne jeśli chodzi o sposób użytkowania (jeśli np. okaże się, że potrzebujesz też wyszukiwać). Tak jak nie należy optymalizować kodu zbyt wcześniej, tak samo nie należy robić tego z oprogramowaniem. Odpalisz "prototyp", zobaczysz czego potrzebujesz, jakie masz charakterystyki użycia, a ilość wpisów pójdzie w dziesiątki gigabajtów,

[b.....h]

@Regis86: czyli po prostu robic standardowo, i jak sie zacznie cos psuc zmieniac, tego mi bylo trzeba, dzieki xD

[jankiel7410]

@blowfish: bazy mają rozkminione różne sztuczki żeby efektywnie przetrzymywać takie rzeczy, indeksować, optymalizować zapytania i wiele, wiele innych. Wybór jest prosty.

3mln wpisów na bazie to nie jest wcale tak dużo w kategoriach przestrzeni dyskowej, mam bazkę 20GB ciężkich tekstów i działa spoko.

@Regis86 też pomyślałem od Redisie, ale jak OP cebulaczy jak tu przyoszczędzić na HDD, to raczej nie będzie się pchał w trzymanie tego w RAM.

I zgadzam się,

[Regis86]

@jankiel7410: Nigdy nie przesiedli się na Cassandrę: "Twitter announced it was planning to move entirely from MySQL to Cassandra,[54][55] though soon after retracted this, keeping Tweets in MySQL while using Cassandra for analytics."

Ale masa firm tak robiła i to jest właściwa droga - zaczynanie małego projektu od drogiej technologii (sprzęt) to samobój. Takie rzeczy się robi przy 2 iteracji danej usługi (albo później - wcześniej można "kombinować" z oryginalnym rozwiązaniem

[jankiel7410]

@Regis86: o, a ja przez ten cały czas myślałem że mieli krótki romans z Cassandrą, nawet widziałem jakąś ich prezentację jak Cassandra odpowiada na ich problemy. Widać nigdy nie weszło na produkcję.

Dzięki za wyprowadzenie z błędu.

[h.....c]

@blowfish: Przy takiej ilości danych spokojnie da radę sqlowa baza na mysqlu czy postgresie. Pracowałem z wielokrotnie większymi o podobnej charakterystyce i żadnych problemów nie było.
Natomiast możesz też w celach edukacyjnych postawić jakąś nosqlową np Mongodb, i trzymać wpisy w postaci wygodnych w obsłudze JSONów - nie musisz bawić się w joiny, jeden wpis = jeden element kolekcji, z kompletnymi danymi.
Minusami takiego rozwiązania są redundancja danych (w tym przypadku