Nierelacyjne bazy danych - NoSQL

[by_ikar]

Witam wszystkich, jakiś czas temu przeczytałem kilka informacji na temat baz NoSQL, zarówno baz typu key-value jak i baz łączących funkcjonalność relacyjnych baz i szybkość baz key-value. Najbardziej zainteresowała mnie baza MongoDB. Chciałbym kilka projektów oprzeć o tą właśnie bazę danych, lecz nie przeprowadzałem jeszcze żadnych testów, posiadam jedynie czysto teoretyczną wiedzę zaczerpniętą z blogów i oficjalnej dokumentacji wyżej wymienionej bazy. Dlatego też chciałbym się zapytać, czy ktoś z użytkowników tego forum, miał styczność z MongoDB, lub bazami typu NoSQL? Rozszerzając swoje pytanie, chciałbym się dowiedzieć czy ktoś już zbudował jakąś stronę/blog czy co kolwiek, gdzie wcześniej używał przykładowo MySQL'a. Chciałbym wiedzieć z jakimi problemami będę musiał się uporać podczas przepisywania kilku serwisów, oraz nauki nowych przyzwyczajeń związanych z bazami danych. Z góry przepraszam jeżeli zbyt ogólnie skonstruowałem swoje pytania. Dzięki z góry za udzielone odpowiedzi.

Pozdrawiam F.

[Mion]

Zasadnicze pytanie - co Ci to da, lub inaczej jakie korzyści Zamierzasz uzyskać przy korzystaniu z tego typu rozwiązań ?

[shad]

Powiem tak do standardowych zastosowań typu strona internetowa, sklepy internetowe to bazy sql'owe lepiej ci się sprawdzą. Mocną dziedziną nierelacyjnych baz danych (bazy key=>vaule, bazy dokumentowe) typu mongodb, itd lepiej ci się sprawdzą przy przetwarzaniu dużych lub gigantycznych ilościach danych, gdzie narzut relacyjności trochę daje popalić, itd.

[by_ikar]

Chciałbym móc w najprostszy sposób przedstawić efekt jaki chcę uzyskać, ale nie wiem czy tak się da.. Więc, przykładowo opiszę to na zasadzie portalu ogłoszeniowego, gdzie użytkownik ma możliwość dodania ogłoszenia, i przykładowo wybierając kategorię "motoryzacja", sposób dodawania ogłoszeń zmieniłby się o dodatkowe pola, typu pojemność silnika, marka, model, w przypadku naczep i samochodów transportowych, takie dane jak pojemność ładunkowa itp. W przypadku mysql'a musiałbym tworzyć albo jedna tabelkę z wieloma pustymi polami, albo kilka różnych tabelek, gdzie znajdowałby się odpowiednie powiązania, np dla samochodów transportowych dane dotyczące pojemności ładunkowej i następnie łączenie tych tabelek. Lecz właśnie, w przypadku wielu takich zróżnicowanych kategorii, łączenie wielu tabelek mija się z celem i jest nieco kłopotliwe, stąd właśnie pomysł z bazą danych zorientowana dokumentowo. Właściwie potrzebowałbym takiej swobody w przypadku kilku konkretnych tabel, ale łączenie dwóch rodzajów baz danych do jednego zastosowania to trochę przerost formy nad treścią, dlatego chyba lepiej całość przenieść już na jedną bazę danych.

Innymi słowy, korzyści jakie zamierzam uzyskać to brak ograniczeń takie jak sztywne pola w bazie sql'owej. I czy rozwiązanie jakie planuje jest w ogóle opłacalne, czy zwyczajnie będzie to przerost formy nad treścią? Niektóre z serwisów już teraz generują dość spory ruch, więc to byłoby dodatkowe odciążenie, o ile dobrze czytałem jeżeli chodzi o porównywanie wydajnościowe bazy mysql z bazą mongodb. Chyba że istnieją jeszcze jakieś inne bazy danych, które opierają się o język sql, ale nie ma tam sztywnych zasad dotyczących tabel. Bo w sumie najbardziej zależy mi na wydajności i funkcjonalności, lecz nie wiem jakie problemy płyną od strony technicznej, czy dużo jest z tym babrania, czy php dobrze to obsługuje, itp. Jeżeli ktoś korzystał z tego typu bazy danych, mógłby się podzielić wiedzą, jak i wrażeniami.

[INOMan]

Bazy NoSQL są używane do specyficznych zadań i zazwyczaj robi się miks bazy relacyjnej z bazą NoSQL.

Główna zaleta bazy NoSQL jest taka, że możesz przyjąć ogromną ilość danych w krótkim czasie (tłumacząc na SQL: "INSERTów") i dlatego tego typu bazy są używane np. przez facebooka (Casandra) albo twittera.

Główną wadą jest słaba integralność takiej bazy danych. Co to jest integralność bazy danych możesz znaleźć np. tutaj: https://pl.wikipedia.org/wiki/Integralno%C5%9B%C4%87_danych.

[Mion]

Każdy pojazd posiada z góry znane cechy które jednak nie we wszystkich występują wiec dajesz w tym wypadku wartość NULL oczywiście nie jest tym samym co puste pole w tabeli jednak zaprojektowanie takiej tabeli nie stanowi problemu. Z kolei jeden pojazd może występować w wielu kategoriach i tutaj nieocenione stają się relacyjne bazy danych oparte właśnie na relacjach miedzy nimi. Do tego dochodzi wyszukiwanie danych.

Przyznam się, że nie znam baz typu NoSQL, ale znam relacyjne i nie wyobrażam sobie pisania serwisu ogłoszeń motoryzacyjnych nie mając w zanadrzu zalet jakie ze sobą takie bazy danych niosą.

[mrtn]

to co opisujesz to akurat klasyczny przykład dla bazy relacyjnej - wręcz akademickie zadanie rozpisania bazy danych produktów gdzie parametry są zależne od grupy produktowej.

Relacyjność jest jak najbardziej dla bazy ogłoszeń porzadana a dobrze założone triggery eliminują kod zajmujący się integralnością - zmiany liczników, usunięcia powiązań, ogłoszeń przypiętych np do kont, terminów wyświetleń, archiwów, zdjęć i setki innych.

[by_ikar]

Tak, macie racje, relacyjność musi w takiego typu serwisie występować, ponieważ te dane trzeba jakoś łączyć, tyle że MangoDB również posiada tą cechę relacyjności, przynajmniej tyle wyczytałem. Samochód osobowy nie posiada wielu cech takich jakie posiadają samochody ciężarowe, pomijając samochody dostawcze, naczepy i ciągniki, a do całości dochodzą jeszcze zdjęcia i inne opcje danego ogłoszenia. W samym czystym ogłoszeniu już jest 28 pól a to w sumie tylko podstawowe funkcje danego ogłoszenia. Potrafię projektować relacyjne bazy danych, nie sprawia mi to większego problemu. Ale przy dużej ilości opcji, jak jest np w profilu użytkownika na portalu typu facebook, czy nasza klasa, niezaznaczenie 50% pól formularza = połowa miejsca w bazie zbędna. Właśnie czegoś takiego chcę uniknąć, żeby nie tworzyć zbędne pola które i tak są przeważnie nie wypełniane.

Zamiast tworzyć jak na chwilę obecną 3 różnych tabel i ich łączyć ze sobą, gdzie podczas wyszukiwania, liczba join'nów jest przerażająca jak dla mnie, rozwiązanie jakie oferuje, oczywiście jak narazie teoretycznie, bo nie instalowałem tej bazy danych i jej nie testowałem, to zdaje się że mongodb rozwiązuje moje problemy.. I w sumie trzymając wszystko w jednym wierszu, średnio jest mi potrzebna relacyjność, jak by tak dobrze sprawę przemyśleć.

Zamiast joinów z wieloma tabelami byłby w sumie tylko jeden join, a tabela z ogłoszeniem w przypadku MongoDB wyglądałaby mniej więcej tak:

{ "id" : 11, "cat" : 3, osobowe : [{ pojemnosc : 2.3, kolor : "czerwony", miejsc : "5", rok_produkcji : "1989" }] }
{ "id" : 12, "cat" : 4, osobowe : [{ pojemnosc : 4.0, kolor : "czarny", rok_produkcji : "1989" }], ciezarowe : [{ naczepa : "brak", typ : "dostawcze" }] }

Co jest moim zdaniem mega wygodne, tylko jeszcze nie wiem na ile ta wygoda sprawdza się w praktyce

Mam pytanie #INOMan, czy może pracowałeś z MongoDB? I w nim również są problemy z integralnością? Na jakiej zasadzie bazy typu NoSQL tracą tą spójność? Gubią gdzieś dane po drodze? Czy jak to wygląda, bo nie bardzo wiem co masz dokładnie na myśli. Chciałbym jakichś konkretów, ale widzę że to jest jeszcze "za nowe" i w sumie sporo osób nie testowała jeszcze tego. Dzisiaj jak znajdę chwilę przymierze się do testów, i zobaczymy jak wypadnie przy insert, update i select. Piszą że wyszukiwanie dość sprawnie działa w takiej bazie danych, ale jak sprawnie to się chyba przekonam dzisiaj, wyeksportuje całą 200 megową bazę mysql do MongoDB. Jeżeli będzie spełniał moje oczekiwania, to chyba się skuszę na przepisanie serwisów.

[Mion]

@ połowa miejsca w bazie zbędna.

Tylko, że pola z "wartością" typu NULL nie zawierają zbyt wiele miejsca w bazie.

Jak już chcesz zaoszczędzić miejsca to nie dawaj wartości cechy jako wartość słowną, ale liczbę skojarzoną z dana wartością na zasadzie tablicy np:

$wartosciKolory = array(1=>'bialy', 2=>'czerwony', 3=>'niebieski' ....) itd

Jak dla mnie starasz się wymyślić koło na nowo.

[Maximus Marius]

Jednak przy bazach danych dość przydatna rzecz to doświadczenie , bo z jednej strony teoria a z drugiej praktyka

Potrafię projektować relacyjne bazy danych, nie sprawia mi to większego problemu. Ale przy dużej ilości opcji, jak jest np w profilu użytkownika na portalu typu facebook, czy nasza klasa, niezaznaczenie 50% pól formularza = połowa miejsca w bazie zbędna. Właśnie czegoś takiego chcę uniknąć, żeby nie tworzyć zbędne pola które i tak są przeważnie nie wypełniane.

Zamiast tworzyć jak na chwilę obecną 3 różnych tabel i ich łączyć ze sobą, gdzie podczas wyszukiwania, liczba join'nów jest przerażająca jak dla mnie, rozwiązanie jakie oferuje, oczywiście jak narazie teoretycznie, bo nie instalowałem tej bazy danych i jej nie testowałem, to zdaje się że mongodb rozwiązuje moje problemy.. I w sumie trzymając wszystko w jednym wierszu, średnio jest mi potrzebna relacyjność, jak by tak dobrze sprawę przemyśleć.

Za bardzo skupiasz uwagę na mało istotnych aspektach a nie zwracasz uwagi na rzeczy ważne,

np. nie wiem co komu przeszkadza że miejsce sie marnuje ? Jesteś pewnien że na pewno te miejsce się marnuje ? Albo w jakim to celu jest tak zrobione a nie inaczej ? Marnowanie miejsca albo nawet redundancja to czasami zabieg zamierzony

Czy ogłoszenie musi mieć 28 pól w bazie danych, no przecież nie musi można to zrobić inaczej.

Jak masz 3 tabele i liczba join jest przerażająca to pewnie ten SQL jest ciekawy i raczej coś masz "nie teges"

Nie mówię żeby nie interesować sie alternatywnymi rozwiązaniami do RDBMS ale raczej aby nie robić tego na siłę , i tylko w uzasadnionych przypadkach

[slawek22]

Hm... nie wiem po co się interesujesz nierelacyjnymi BD, no chyba, że w serwisie chcesz mieć więcej niż 10 milionów ogłoszeń. Nierelacyjne BD bardzo dobrze się emulują na mysql/myisam. Co prawda są cholernie wolne (bo tradycyjne bazy danych są 10-100x wolniejsze niż nierelacyjne). Podejście powinno być takie, że sobie definiujesz standardowe właściwości, które ma każde ogłoszenie a resztę zapisujesz jako klucz=>wartość w polu TEXT/BLOB + ew. kompresujesz to i dodajesz pole dla wyszukiwania.

to co opisujesz to akurat klasyczny przykład dla bazy relacyjnej - wręcz akademickie zadanie rozpisania bazy danych produktów gdzie parametry są zależne od grupy produktowej.

Klasyczny - nie klasyczny. Prawdopodobnie wszystko robisz na takich bazach, co nie znaczy, że to nie może bardzo dobrze działać zrobione inaczej

Relacyjność jest jak najbardziej dla bazy ogłoszeń porzadana a dobrze założone triggery eliminują kod zajmujący się integralnością - zmiany liczników, usunięcia powiązań, ogłoszeń przypiętych np do kont, terminów wyświetleń, archiwów, zdjęć i setki innych.

Tylko nie wspominasz, ile to "kosztuje". Powiedzmy, że limit ogłoszeń dla takiej bazy na mySQL to 10 milionów jak ją zrobisz bez sprawdzania spójności / auto fk / triggerów na myisam. Jak sobie zaprojektujesz ładną, znormalizowaną bazę na innoDB to limit spadnie jakieś 10x a być może jeszcze bardziej. Bo głupi count(*) + Group By nawet z odpowiednio poindeksowanymi polami dla większych tabel to koszmar. Powiesz, że można cache zrobić albo generować tabelę pomocniczą w cron czy przy dodawaniu ogłoszenia. Ale takie coś spójne już nie jest i można równie dobrze całość na myisam zrobić a integralność danych załatwić paroma outer joinami + inner w kwerendach.

Potrafię projektować relacyjne bazy danych, nie sprawia mi to większego problemu. Ale przy dużej ilości opcji, jak jest np w profilu użytkownika na portalu typu facebook

Chyba jednak masz bardzo małe doświadczenie, bo widzisz niedogodności tam gdzie ich nie ma. Rozmiar pól praktycznie się nie liczy. To indeksy mają się mieścić w pamięci. Co ci po tym, że wiersze mało zajmują jeśli indeksy nie mieszczą się w RAM i najprostsza zmiana struktury zajmuje kilka godzin a kwerendy wleką się tak, że można sobie kawę zaparzyć zanim się strona pokaże?

Przypomina to zastanawianie się programistów php, czy używać pojedynczych czy podwójnych cudzysłowów... bo jeden jest 0,00001% szybszy od drugiego. Więc robią z kodu sieczkę - zamiast zainstalować APC czy xcache, który wydajność zwiększa od kilku do kilkudziesięciu razy, bo jakieś bzdury tam wyczytali w jednym czy drugim komputer-świecie.

Poza tym brak informacji w polu często też jest informacją. Jak joinów jest <10 to nie ma się co przerażać a przy takich prostych bazach to tak na prawdę oprócz indeksów nie ma czego optymalizować na tak niskim poziomie jak rozmiar wiersza !!!