Pracuję nad projektem, w którym próbuję zdecydować się na użycie standardowej relacyjnej bazy danych SQL lub obiektów JSON do przechowywania danych o zdarzeniu lub działaniu.
Projekt będzie przechowywać dane dotyczące wielu typów zdarzeń, dlatego postanowiłem opisać tylko jeden typ zdarzenia dla tego pytania.
Wydarzenie z muzyką na żywo (opisane w całości przy użyciu schematu JSON na dole tego pytania) to obiekt, który przechowuje dane, takie jak miejsce zdarzenia, czas / data wydarzenia i koszt wydarzenia. Obiekt zdarzenia muzyki na żywo ma zarówno jeden do jednego (wydarzenie -> nazwa, wydarzenie -> opis), jak i jeden do wielu (wydarzenie -> miejsca, wydarzenie -> daty, wydarzenie -> typy biletów ) relacje. Ponadto obiekt zdarzenia może zawierać jeden lub więcej identyfikatorów wykonawców, które łączą się z obiektem wykonawców. Obiekt wykonawcy przechowuje dane dotyczące muzyków, którzy występują na imprezie z muzyką na żywo.
Dane będą wyszukiwane przez użytkowników przy użyciu zarówno prostych („Znajdź mnie wydarzeń o nazwie„ x ””), jak i złożonych („Znajdź mnie wydarzeń z gatunkiem muzycznym„ x ”i kosztem„ y ”w promieniu„ z ”od mojego obecnego lokalizacja ”). Dane zostaną przesłane przez użytkowników za pomocą formularza internetowego.
Jak zapewne można stwierdzić po zdefiniowanym schemacie JSON, pierwotnie zamierzałem używać obiektów JSON do przechowywania tych danych, ale słyszałem od niektórych osób, które twierdzą, że ponieważ moje dane są czysto relacyjne, powinienem trzymać się starszych metod.
Byłbym wdzięczny za wszelkie przemyślenia na temat zalet i wad każdego podejścia, biorąc pod uwagę moje potrzeby. Jeśli potrzebujesz czegoś wyjaśnionego, możesz zapytać.
{
"event": {
"eventID":{
"type":"string"
},
"eventType":{
"type":"array",
"eventTypeItem":{
"type":"string"
}
},
"eventName":{
"type":"string"
},
"eventDescription":{
"type":"string"
},
"eventVenueList":{
"type":"array",
"eventVenueListID":{
"type":"integer"
}
},
"eventURL":{
"type":"string"
},
"eventTwitter":{
"type":"string"
},
"eventFB":{
"type":"string"
},
"eventInstagram":{
"type":"string"
},
"eventEmail":{
"type":"string",
"format":"email"
},
"eventContactPerson":{
"type":"string"
},
"eventDoorTime": {
"type":"string",
"format":"date-time"
},
"eventPerformerIDList":{
"type":"array",
"liveMusicPerformerID":{
"type":"integer"
}
},
"eventSetList":{
"type":"array",
"eventPerformerID":{
"type":"integer"
},
"eventPerformerStartTime":{
"type":"string",
"format":"date-time"
},
"eventPerformerEndTime":{
"type":"string",
"format":"date-time"
}
},
"eventDateList": {
"type":"array",
"eventDateItem": {
"type":"string",
"format":"date-time"
}
},
"eventDateStartTime": {
"type":"string",
"format":"date-time"
},
"eventDateEndTime": {
"type":"string",
"format":"date-time"
},
"eventTicket":{
"type":"array",
"eventTicketType":{
"type":"string"
},
"eventTicketLowPrice":{
"type":"number"
},
"eventTicketHighPrice":{
"type":"number"
},
"eventDatesAdvancePrice": {
"type":"number"
}
}
},
"performer": {
"performerID": {
"type":"integer"
},
"performerType": {
"type":"string"
},
"performerName": {
"type":"string"
},
"performerAlternateName": {
"type":"array",
"performerAlterateNameItem":{
"type":"string"
}
},
"performerGenreList": {
"type":"array",
"performerGenreItem":{
"type":"string"
}
},
"performerURL": {
"type":"string"
}
}
}
Odpowiedzi:
Myślę, że twoje pytanie naprawdę sprowadza się do: Kiedy powinienem zastosować podejście NoSQL vs. RDBMS? Wcześniej zdecydowałeś się na JSON (decyzja typu NoSQL), być może dlatego, że masz klientów Ajax.
Oczywiście odpowiedź na pytanie, kiedy stosować podejście NoSQL vs. RDBMS, dotyczy w zasadzie rodzaju danych, z którymi pracujesz i jakich klientów oczekujesz. Jeśli Twoje dane są zasadniczo relacyjne (dość płaskie hierarchie, brak dziwnych typów danych, takich jak obrazy lub dźwięk, przewidywalne relacje między schematami, które można łatwo opisać za pomocą kluczy), a oczekuje się, że Twoi klienci w końcu będą obejmować osoby, które chcą wykonywać zapytania Business Intelligence (odpytywanie ad hoc), wtedy RDBMS jest właściwą drogą. Przekształcenie zapytania w reprezentację JSON jest dość łatwe, więc nie obciąża znacząco klientów Ajax - dodaje tylko niewielką transformację kodującą do twoich punktów końcowych (REST / SOAP / cokolwiek). Odwrotnie, jeśli twoje dane są bardzo hierarchiczne (głębokie schematy), zawierają dziwne typy danych, takie jak obrazy, audio, wideo itp., istnieje kilka relacji między jednostkami i wiesz, że twoi użytkownicy końcowi nie będą wykonywać BI, wtedy NoSQL / przechowywanie JSON może być odpowiedni.
Oczywiście nawet te ogólne wytyczne nie są solidne. Powodem, dla którego Google opracował system plików Google, MapReduce (prace, które Doug Cutting wykorzystał do zbudowania Hadoop w Yahoo), a później BigQuery (zorientowany na NoSQL [schematyczny] sposób zarządzania danymi na dużą skalę), było właśnie to, że mieli dużo ad hoc Żądania BI i nie mogli uzyskać relacyjnych podejść do skalowania do skal tera / peta / exa / zetta / yotta, którymi próbowali zarządzać. Jedynym praktycznym podejściem było skalowanie, poświęcenie części przyjazności dla użytkownika zapytań ad-hoc, jaką zapewnia RDBMS, i zastąpienie prostego algorytmu (MapReduce), który można dość łatwo zakodować dla dowolnego zapytania.
Biorąc pod uwagę powyższy schemat, moje pytanie brzmiałoby w zasadzie: Dlaczego nie miałbyś używać RDBMS? Nie widzę powodu, by tego nie robić. Nasz zawód powinien być inżynierem, a nie modą, więc naszym instynktem powinno być wybranie najprostszego rozwiązania, które działa, prawda? Mam na myśli, że twoje punkty końcowe mogą musieć wykonać małe tłumaczenie, jeśli Twoi klienci to Ajaxy, ale twoje dane wyglądają bardzo płasko i wydaje się prawdopodobne, że użytkownicy biznesowi będą chcieli wykonywać wszelkiego rodzaju doraźne zapytania dotyczące np. Wydarzeń muzycznych (które w ubiegłym roku najwięcej osób wzięło udział w promieniu 50 mil od naszej stolicy?)
„Nie idź do elfów po radę, bo powiedzą„ nie ”i„ tak ”. - Frodo
źródło
Uważam, że jest tu więcej czynników, których możesz nie szukać. Istnieją tutaj dwie ogólne obawy:
Przechowywanie
Istnieje wiele opinii na temat tego, dlaczego używać do przechowywania danych magazynu bez SQL lub RDBMS. Jednym z najważniejszych elementów, które uważaliśmy za przydatne, jest to, że możemy łatwo definiować i przechowywać obiekty json w pamięci bez konieczności martwienia się o zdefiniowanie pełnej struktury lub relacji między różnymi typami obiektów. Niektóre inne powody korzystania z bazy danych NoSql to możliwość automatycznego dzielenia danych, wyszukiwania na podstawie lokalizacji i łatwa konserwacja. Istnieje wiele dobrych baz danych NoSql, moje osobiste preferencje to MongoDB. Jeśli jednak wcześniej nie korzystałeś z bazy danych NoSql, istnieje pewna krzywa uczenia się podczas nauki ponownego łączenia umysłu. Większość z nas korzysta z RDBMS od jakiegoś czasu i potrzeba świadomego wysiłku, aby zerwać z tym nawykiem. Dodatkowo, będziesz chciał ponownie wykonać model danych w miarę postępów i lepszego zrozumienia pojęć. Jeśli zdolność do refaktoryzacji lub przebudowy nie jest opcją dla twojego projektu, sugeruję trzymać się tego, co już wiesz najlepiej.
Szukaj
Jeśli masz zamiar zapewnić jakiekolwiek użyteczne wyszukiwanie, zdecydowanie zalecamy skorzystanie z dedykowanej wyszukiwarki tekstowej, takiej jak SOLR, do wyszukiwania. Wyszukiwanie tekstu jest powolne, a jeśli masz wiele odłamków, jeszcze bardziej wolniejsze. SOLR obsługuje niezwykle szybkie wyszukiwanie tekstu, w tym parametry wyszukiwania ważonego, wyszukiwania oparte na lokalizacji i wiele innych. SOLR nie nadaje się jednak jako główny magazyn danych. Oznacza to, że podczas dodawania lub aktualizowania zdarzeń będziesz musiał stworzyć mechanizmy podwójnego wstawiania i aktualizacji zarówno podstawowej bazy danych, jak i warstwy SOLR. Ponadto będziesz musiał później aktualizować SOLR, usuwając wszelkie nieaktualne / zakończone zdarzenia.
Chociaż wydaje się, że to dużo dodatkowej pracy, podziękujesz sobie za dalekowzroczność korzystania z wyszukiwarki pełnotekstowej później. Żadna z baz danych NoSql lub RDBMS nie jest bliska wydajności i zwinności SOLR / Lucene.
źródło
Po pierwsze, jeśli próbujesz przechowywać dane JSON w dowolnym magazynie, ale nie w bazie danych NoSQL , zdecydowanie odradzam korzystanie z JSON. Powodem jest to, że jeśli na przykład przechowujesz dane jako plik JSON, jego otwarcie, parsowanie, przechodzenie przez niego itd. Będzie bardzo wolne.
Na początku powiedziałem, że mogę zawęzić twoje pytanie do: jakie są zalety i wady NoSQL i RDBMS ? I na to już już tysiące razy odpowiedziano w sieci.
Rejestrując swój projekt, możesz oczywiście użyć NoSQL lub RDBMS ; Jednak ogólnie mogę ci polecić od razu po wyjęciu z pudełka i poszukaj innych mniej widocznych czynników, które mogą pomóc ci zdecydować między dwiema opcjami. Spróbuj sprawdzić, która opcja może przyspieszyć rozwój? Co jest bardziej odpowiednie dla innych członków zespołu - jeśli nie jesteś wyłącznym programistą. Jeśli to sprzedajesz, który z nich jest tańszy, łatwiejszy i ogólnie bardziej odpowiedni dla klientów, którzy nie są programistami?
W ten sposób możesz w końcu zdecydować, którą drogą wybrać, w przeciwnym razie naprawdę trudno będzie podjąć decyzję na podstawie podanych informacji, ponieważ obie opcje mogłyby pasować całkiem dobrze.
źródło
W większości aplikacji istnieją wymagania
W celu spełnienia wymagań dla punktu 1 wymagana jest metoda utrwalania danych. Zazwyczaj, jeśli ilość danych jest bardzo mała, a typ danych jest prosty i nie wymaga szerokich możliwości wyszukiwania, można zastosować prostą strukturę plików. W miarę, jak dane stają się bardziej złożone, może być stosowana struktura XML (lub nawet JSON) z danymi nadal przechowywanymi w plikach. Wyszukiwanie staje się jednak bardziej problematyczne. Wraz ze wzrostem ilości danych i złożonością wyszukiwania zwykle wybiera się bazę danych, która zapewnia standardowe w branży metody utrwalania danych, zapytań itp. Bazy danych mogą być zaprojektowane do obsługi dużych ilości danych oraz przechowywania, wyszukiwania i wyszukiwania danych szybko i skutecznie .
Aby spełnić wymagania dla punktu 2, istnieją różne różne metody umożliwiające wymianę danych między systemami, w tym XML, JSON itp.
Metody te pozwalają użytkownikowi zdefiniować strukturę danych i są niezależne od języka, umożliwiając wymianę danych między różnymi systemami.
W twoim konkretnym przypadku poprawnie używasz JSON opisuje zestaw wydarzeń muzycznych. Chociaż można przechowywać dane w formacie JSON, przeszukiwanie tych danych w miarę wzrostu liczby wydarzeń muzycznych będzie powolne i nieefektywne.
Stosując podejście rozdzielania obaw, lepszym rozwiązaniem jest zebranie danych, przechowywanie w bazie danych, wykonanie zapytania na podstawie danych wprowadzonych przez użytkownika w bazie danych, a następnie zwrócenie wyników w formacie JSON po stronie klienta, aby wyświetlić dane.
Dodatkowym problemem związanym z podejściem JSON jest zmieniająca się struktura danych. Obecnie twoja struktura jest stosunkowo prosta. Możesz korzystać z tej struktury przez kilka miesięcy, a następnie identyfikowane jest dodatkowe pole. Co zatem robisz ze wszystkimi istniejącymi obiektami JSON? Ich aktualizacja byłaby problematyczna.
Jeśli korzystałeś z bazy danych, wówczas dodanie dodatkowego pola jest stosunkowo proste i tylko twój kod do wygenerowania JSON musiałby zostać zmodyfikowany w jednym miejscu, dając ci cały nowy JSON z nowym polem.
W skrócie wykorzystaj każdy element technologii do tego, co został zaprojektowany dla JSON do wymiany danych i bazę danych do utrwalania danych.
źródło
Myślę, że odniesiesz większy sukces przy użyciu NoSQL niż SQL do przechowywania tych danych, ze względu na zapytania, które musisz wykonać.
Również fakt, że niektóre dane są czysto relacyjne, nie oznacza już, że muszą zostać utrwalone w niektórych RDBMS (SQL). Dane relacyjne IMO lepiej przełożyłyby się na bazy danych wykresów.
Oczywiście możesz również pisać zapytania w SQL, ale wydajność będzie straszna z powodu liczby sprzężeń, które będziesz musiał mieć (biorąc pod uwagę, że twoje dane zostaną nieco znormalizowane, a nie wszystkie w jednej tabeli zdarzeń).
Podsumowując, będziesz mieć więcej swobody, używając NoSQL (a więc JSON lub innego formatu obsługiwanego przez bazę danych), biorąc pod uwagę, że możesz modyfikować swój schemat w przyszłości bez uwzględnienia już utrwalonych danych.
Biorąc pod uwagę NoSQL, możesz również zajrzeć do baz danych grafów, jeśli planujesz używać bardzo złożonych zapytań, ponieważ przyniosą one korzyści w łatwym ich tworzeniu, a także w wykonywaniu ich bardzo szybko.
źródło
Myślę, że powinieneś używać obu tych rozwiązań i nie uważam tego za decyzję „przeciw”.
Relacyjna baza danych ma sens dla szybkiego i wydajnego przechowywania i wyszukiwania danych o relacyjnych właściwościach.
JSON to świetny format danych, ponieważ jest prosty, lekki i idealny do przekazywania surowych danych w bardzo podstawowym formacie ze składnią odpowiednią do przechowywania i wymiany informacji tekstowych. Doskonale nadaje się do przesyłania niewielkich ilości danych między przeglądarką a serwerem. Nie jest w tak łatwym formacie, aby zacząć używać zapytań o dane typu relacyjnego.
Polecam więc SQL do przechowywania danych i JSON dla formatu transportu danych.
Prawdą jest, że nie ma opcji klucz-wartość noSQL, takich jak Mongo, Redis itp. Miałyby one tę zaletę, że mogą być łatwiejsze do mapowania do formatu JSON, ale generalnie są nieco trudniejsze w przypadku zapytań. Główną przeszkodą jest brak znajomości przez ogólną społeczność IT, zwłaszcza w porównaniu z SQL, który jest tak dobrze znany i posiada szeroki wachlarz zasobów i wiedzy dostępnych dla prawie każdej możliwej sytuacji.
źródło