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.
Odpowiedzi:
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.
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
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”
Jeśli potrzebujesz szybkości, potrzebujesz buforowania na relacyjnej bazie danych, a nie uszkodzonego relacyjnego modelu danych
Właściwie znormalizowana baza danych przyspiesza wyszukiwanie i wyszukiwanie klucza podstawowego, ponieważ jest po prostu mniej bitów do przesiewania.
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.
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.
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.
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.
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”.
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.
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.
źródło
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ść.
źródło
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.
źródło
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.
źródło