Dlaczego używanie MySQL do stron ze słownikami jest złym pomysłem?

55

Planuję zaprojektować i skonfigurować bazę danych do przechowywania wpisów słownika (zwykle pojedynczych słów) i ich znaczenia w innym języku. Tak więc, na przykład, Słownik tabeli musi mieć pozycję i definicję, a każdy rekord tabeli ma odniesienie do identyfikatora rekordu zapisanego w Tag(Każdy wpis musi mieć znacznik lub kategorię).

Ponieważ moje dane mają strukturę, pomyślałem, że użycie bazy danych SQL (takiej jak MySQL) nie jest złym pomysłem; ale ludzie mówią, że MongoDB jest znacznie lepszy pod względem wydajności.

Po stronie klienta aplikacja musi mieć możliwość zapewnienia pola wyszukiwania z funkcją autouzupełniania, która korzysta z interfejsu API REST udostępnianego przez backend. Czy w takim scenariuszu można bezpiecznie korzystać z MySQL? czy powinienem użyć do tego MongoDB lub ElasticSearch innego rozwiązania? W ten sposób należy przechowywać i uzyskiwać dostęp do setek tysięcy rekordów.

Aziz Az
źródło
79
Ludzie, którzy ci mówią, nie przeprowadzili wiele badań w tym zakresie. Język o największym słownictwie, angielski, ma mniej niż milion odrębnych słów. Jest to w zakresie możliwości wydajności relacyjnej bazy danych.
TheCatWhisperer
25
Nie widzę tu nic, co mogłoby sprawić, że pomyślałem, że MySQL nie działałoby w tym przypadku dobrze. Wydajność przy prostym wyszukiwaniu nie byłaby problemem, a jeśli trzeba iść tą drogą, ma ona wyszukiwanie pełnotekstowe.
GrandmasterB
46
Jeśli chodzi o „MongoDB jest znacznie lepszy pod względem wydajności” - jako niemodyfikowane stwierdzenie bez wyjaśnienia zakresu, jest to nonsens rangi. Na przykład zobacz Narzędzia wiersza polecenia mogą być 235 razy szybsze niż klaster Hadoop (który natrafiłem na link w Kryzysie otyłości witryny ).
Wildcard
82
Mam dość ludzi, którzy mówią, że relacyjne bazy danych są złe, a MongoDB jest lepszy, ponieważ jest szybszy. To tak, jakby powiedzieć, że samochody są złe i powinniśmy używać samolotów, ponieważ podróżują szybciej. Radzę zignorować takie porady.
Brandon
13
@Brandon Smutne jest to, że całe twierdzenie, że „NoSQL jest o wiele szybszy” sprowadza się zazwyczaj do teoretycznego wyjaśnienia, dlaczego powinny być o wiele lepsze, ale w praktyce nie dotyczy to nawet wielu scenariuszy z prawdziwego świata. Zobacz np . Tutaj . Używany zestaw testów jest open source i dostępny również na github. Hell CERN dobrze zarządza swoimi danymi PB z OracleDB.
Voo

Odpowiedzi:

95

Nie mogę ci powiedzieć, dlaczego to zły pomysł. Mogę jednak podać kilka powodów, dla których relacyjna baza danych jest dobrym pomysłem.

  1. Pamiętaj, że nie wszyscy szukają definicji w słowniku. Częściej niż nie, słownik jest używany do znalezienia poprawnej pisowni. Oznacza to, że nie tylko znajdujesz igłę w stogu siana , ale przeszukujesz stóg siana w poszukiwaniu igieł podobnych do opisanego przez użytkownika (jeśli mogę użyć idiomu).

    Nie będziesz po prostu sprawdzać kluczy głównych. Będziesz wyszukiwał słowa kluczowe

  2. Słowa mogą być powiązane, w znaczeniu lub pisowni ( czytaj, czytaj , czerwony i trzcina )

    Ilekroć zobaczysz słowo „powiązane”, pomyśl „Relacyjna baza danych”

  3. Jeśli potrzebujesz szybkości, potrzebujesz buforowania na relacyjnej bazie danych, a nie uszkodzonego relacyjnego modelu danych

  4. Właściwie znormalizowana baza danych przyspiesza wyszukiwanie i wyszukiwanie klucza podstawowego, ponieważ jest po prostu mniej bitów do przesiewania.

  5. Ludzie, którzy mówią, że znormalizowane bazy danych działają wolniej, odnoszą się do 0,1% przypadków, w których jest to prawdą. W pozostałych 99,9% przypadków tak naprawdę nie pracowali z prawdziwie znormalizowaną bazą danych, aby zobaczyć wydajność z pierwszej ręki, więc zignoruj ​​ją. Pracowałem ze znormalizowaną bazą danych. Kocham to. Nie chcę wracać. I nie jestem facetem z bazy danych. Jestem facetem C # / JavaScript / HTML / Ruby.

  6. Słowa mają pochodzenie. W rzeczywistości wiele słów w tym samym języku może mieć to samo pochodzenie, co jest innym słowem w innym języku. Na przykład życiorys (to, co przesyłamy na strony osób rekrutujących, abyśmy mogli otrzymywać nieprzerwane rozmowy telefoniczne i e-maile przez następne 7 lat) to francuskie słowo.

  7. Słownik określa również, jakie to słowo (rzeczownik, czasownik, przymiotnik ect). To nie jest tylko fragment tekstu: „rzeczownik” ma również znaczenie. Dodatkowo za pomocą relacyjnej bazy danych możesz powiedzieć „daj mi wszystkie rzeczowniki dla języka angielskiego”, a ponieważ znormalizowana baza danych będzie wykorzystywać klucze obce, a klucze obce mają (lub powinny mieć) indeksy, wyszukiwanie będzie szybkie.

  8. Pomyśl, jak wymawia się słowa. Zwłaszcza w języku angielskim wiele słów ma tę samą wymowę (patrz mój przykład powyżej z tekstem read i reed lub read and red).

    Wymowa słowa jest sama w sobie innym słowem. Relacyjna baza danych pozwala na użycie obcych kluczy do dowolnej wymowy. Informacje te nie zostaną skopiowane w relacyjnej bazie danych. Zostaje duplikowane jak szalone w bazie danych bez SQL.

  9. A teraz porozmawiajmy o liczbie mnogiej i liczbie pojedynczej słów. :) Pomyśl „łódka” i „łódki”. Lub sam fakt, że słowo jest „liczba pojedyncza” lub „liczba mnoga”.

  10. O! A teraz porozmawiajmy o czasie przeszłym, czasie teraźniejszym, czasie przyszłym i imiesłowie obecnym (szczerze mówiąc, nie wiem, co to bzdury „teraźniejszy imiesłów”. Myślę, że ma to coś wspólnego ze słowami kończącymi się na „ing” w Angielski czy coś takiego).

    Wyszukaj „bieg” i powinieneś zobaczyć inne czasy: biegał, biegał, biegał

    W rzeczywistości „czas” jest innym związkiem.

  11. Angielski nie robi tego zbyt często, ale płeć to kolejna rzecz, która określa słowo. Języki takie jak hiszpański mają przyrostki określające, czy rzeczownik jest mężczyzną czy kobietą. Jeśli musisz wypełnić puste pola zdania, w wielu językach płeć jest niezwykle ważna.

    Ponieważ przy ustalaniu płci nie zawsze można polegać na konwencjach językowych (w języku hiszpańskim słowa kończące się na „o” są rodzaju męskiego / męskiego, ale nie jest tak w przypadku wszystkich słów), potrzebujesz wartości identyfikującej: mężczyzna lub kobieta. To kolejna relacja, którą znormalizowana baza danych obsługuje z wdziękiem nawet przy milionach rekordów.

Przy wszystkich pokręconych regułach i relacjach między słowami, a nawet w różnych językach, trudno mi sobie wyobrazić ten magazyn danych jako „magazyn dokumentów”, jak zapewnia rozwiązanie bez SQL. Istnieje tak wiele i tak duża różnorodność relacji między słowami i ich składnikami, że relacyjna baza danych jest jedynym sensownym rozwiązaniem.

Greg Burghardt
źródło
7
W przypadku nr 1 indeksowanie jest często jedną z mocnych stron nierelacyjnych ofert, a nie słabością.
JimmyJames
61
@JimmyJames Nie zastanawiaj się przez chwilę, że systemy relacyjne nie używają tego samego rodzaju indeksów. Wiele z tych technik było pionierami w tym świecie.
Blrfl,
14
„Za każdym razem, gdy zobaczysz słowo„ powiązany ”, pomyśl„ Relacyjna baza danych ””. Nie zgadzam się „Relacyjny” w „relacyjnej bazie danych” odnosi się do samych krotek. Powiązany jest zbyt szeroki termin, aby to oświadczenie
mogło
12
Istnieją również bazy danych wykresów (przychodzi na myśl Neo4j), które wyraźnie koncentrują się na przemierzaniu relacji, a nie na wykonywaniu tradycyjnych połączeń. Może to być korzystne, ponieważ wiele słowników to tak naprawdę sieci słów; na przykład projekt WordNet używa własnego formatu graficznego zamiast tradycyjnego RDMS.
tucuxi
4
I downvoted tę odpowiedź tylko dla „Kiedy widzisz słowo«związany»myśleć" relacyjnej bazy danych.”; To niedorzeczne . Uwielbiam relacyjne bazy danych, ale model relacyjny nie jest odpowiedni dla wszystkich rodzajów relacji. Twój pogląd na znormalizowane dane również jest całkowicie błędny. Normalizacja danych optymalizuje edycje , ponieważ dane nie są powielane, a nie wyszukiwania. (Dlatego raporty DB nie normalizują się. Używają technik modelowania wymiarowego i schematów gwiezdnych.) Nie sądzę, że wiesz o czym mówisz. 80 głosów pozytywnych potwierdza wszystkie moje obawy dotyczące porad na tej stronie.
jpmc26
27

Jeśli korzystasz ze sklepu klucz-wartość (który oferuje ci zubożały model programowania) i okazuje się, że potrzebujesz więcej struktury (w twoim przypadku, powiedzmy, dodając trzeci język), lub musisz wykonać bardziej złożone zapytania dotyczące dołączeń , poświęcisz sporo czasu na reorganizację kluczy, denormalizację danych i / lub zapętlanie wszystkich danych, aby znaleźć to, czego potrzebujesz.

Jeśli zaczynasz od relacyjnej bazy danych, możesz pracować nad projektem aplikacji, kodem i wypróbować ją, koncentrując się bardziej na naturalnym modelu danych aplikacji, a nie na przekształceniu go w formę klucz-wartość.

Po ustabilizowaniu się aplikacji możesz pracować nad wydajnością, mierząc różne opcje. Przed zmianą technologii w SQL należy wykonać kilka sztuczek związanych z wydajnością. Dowiesz się dużo o swojej aplikacji i będziesz w znacznie lepszej sytuacji, aby zdecydować, czy relacja cię krzywdzi i czy klucz-wartość będzie działać na twoim modelu danych.

Jeśli okaże się, że klucz-wartość jest dokładnie tym, czego potrzebuje twoja aplikacja, możesz przełączyć się bez marnowania znacznych inwestycji w model relacyjny, podczas gdy na odwrót możesz stracić czas, sprawiając, że model klucz-wartość robi rzeczy, które są banalne w modelu relacyjnym.

Zastanów się nad relacyjną bazą danych jako narzędziem przyspieszającym projektowanie, pisanie i uruchamianie aplikacji w obliczu stale zmieniających się wymagań, gdy dowiadujesz się więcej o swojej domenie i użytkownikach.

Kiedy masz miliony użytkowników, prawie na pewno i tak będziesz musiał zmienić projekt, nawet jeśli na początku wybrałeś klucz-wartość.

Erik Eidt
źródło
13
Epilog w tym artykule opisuje dokładnie scenariusz zmiany wymagań unieważniających projekt. Opisuje jedną (prawdziwą) aplikację jako „idealny przypadek użycia dla MongoDB”, ale następnie opisuje, w jaki sposób stosunkowo niewielka zmiana wymagań, która byłaby trywialna do wdrożenia w RDBMS, wymagała przyzwoitej pracy i spowodowałaby przeniesienie jej do przypadku użycia, który (jak wyjaśniono w poprzednich częściach artykułu) bardzo nie jest dobrym przypadkiem użycia Mongo.
Derek Elkins,
5
Artykuł Sarah MongoDB jest dokładnie tym, przez co przeszliśmy z produktem 1.0, który zbudowaliśmy z niego; do 1.1 korzystaliśmy z Postgres.
Joe
@DerekElkins, super referencja, dzięki!
Erik Eidt
1
„ale następnie opisuje, jak stosunkowo niewielka zmiana wymagań byłaby łatwa do wdrożenia w RDBMS” Jasne, ale jest odwrotnie. Używamy RDBMS w pracy i napotykamy problemy, które byłyby trywialne do rozwiązania w MongoDB. O dziwo, wymagania dotyczące oprogramowania nie zawsze są idealnie dostosowane do możliwości używanych przez nas narzędzi.
NPSF3000,
@ NPSF3000, byłoby wspaniale, gdybyś mógł zacytować referencje, takie jak blog lub tekst, który na ten temat opracował!
Erik Eidt,
10

W przypadku tak małej bazy danych prawdopodobnie nie będzie to miało większego wpływu na wydajność. Standardowy RDBMS nie jest tutaj strasznym pomysłem, ponieważ przypuszczalnie powinno być o wiele więcej odczytów niż zapisów danego wpisu. Wydajność nie wydaje się być głównym czynnikiem do tego. Buforowanie w warstwie aplikacji również łagodzi takie obawy.

Innym aspektem jest replikacja i odporność. Relacyjne bazy danych są zwykle projektowane wokół jednej instancji. Powinieneś przeczytać twierdzenie o WPR i zastanowić się, co jest dla Ciebie najważniejsze.

JimmyJames
źródło
Jak CAP ma zastosowanie do stosunkowo normalnej aplikacji internetowej? W zależności od zestawu prawdopodobnie utrzymasz tysiące połączeń przychodzących, a warstwa pamięci podręcznej strony może to zwiększyć o rząd wielkości. CAP staje się czymś, co należy wziąć pod uwagę, gdy systemy rozproszone są jedynym sposobem na osiągnięcie celu.
Ben
2
@Ben Resiliency jest celem samym w sobie. Jeśli posiadanie jednego punktu awarii jest nie do przyjęcia dla aplikacji, rozwiązania rozproszone oferują rozwiązanie. Rozwiązania inne niż RDBMS są bardziej zorientowane na to. To nie tylko objętość do rozważenia. Opóźnienia i dostępność są niepokojące. Jeśli twoim wymaganiem jest mieć 99,9% czasu sprawności. Możesz być wyłączony tylko przez około 9 godzin w roku, a utrata danych w jednym db jest katastrofalna, więc musisz uwzględnić replikację / kopie zapasowe / migawki. Błędem jest myśleć, że to koniecznie upraszcza rzeczy.
JimmyJames
2

Te bazy danych NoSQL na początku zawsze brzmią jak dobry pomysł, ale na pewno będziesz mieć problemy, gdy zaczniesz zajmować się przypadkami skrajnymi (np. Gdzie słowa kluczowe muszą być wyszukiwane według ich wartości (lub ich części).

Na początku bezpieczniejszą opcją byłoby skorzystanie z relacyjnej bazy danych, a następnie denormalizacja. MySQL jest świetny do tego celu (proste relacyjne bazy danych z wyszukiwaniem tekstowym), nie ma zbyt wielu przypadków użycia, w których zmaga się z tego rodzaju danymi. Po prostu upewnij się, że masz poprawnie skonfigurowane indeksy, a przekonasz się, że będzie on działał na poziomie porównywalnym (lub lepszym podczas wyszukiwania tekstu) z bazą danych NoSQL, a także zapewni elastyczność w modyfikowaniu logiki aplikacji bez konieczności związany z konkretną strukturą danych.

Gdy znajdziesz najczęstsze wykorzystanie danych (i jeśli okaże się, że nie spełnia Twoich wymagań wydajności), możesz przystąpić do normalizacji danych, wysyłając dane do ustalonego formatu, który można załadować (i pobrać z) schemat NoSQL.

joel.cass
źródło