Interesują mnie strategie projektowania, które stosowałeś z nierelacyjnymi bazami danych „nosql” - to znaczy (głównie nowa) klasa magazynów danych, które nie używają tradycyjnego projektowania relacyjnego lub SQL (np. Hypertable, CouchDB, SimpleDB, magazyn danych Google App Engine, Voldemort, Cassandra, SQL Data Services itp.). Często są również określane jako „magazyny kluczy / wartości” i u podstawy działają jak gigantyczne rozproszone trwałe tablice skrótów.
W szczególności chcę się dowiedzieć o różnicach w koncepcyjnym projektowaniu danych z tymi nowymi bazami danych. Co jest łatwiejsze, a co trudniejsze, czego w ogóle nie można zrobić?
Czy wymyśliłeś alternatywne projekty, które działają znacznie lepiej w świecie nierelacyjnym?
Czy uderzyłeś głową w coś, co wydaje się niemożliwe?
Czy udało Ci się wypełnić lukę za pomocą jakichkolwiek wzorców projektowych, np. Przy tłumaczeniu z jednego na drugi?
Czy w ogóle tworzysz teraz jawne modele danych (np. W UML), czy też porzuciłeś je całkowicie na korzyść częściowo ustrukturyzowanych / zorientowanych na dokumenty obiektów blob?
Czy brakuje Ci głównych usług dodatkowych, które zapewniają systemy RDBMS, takich jak integralność relacyjna, obsługa dowolnie złożonych transakcji, wyzwalacze itp.?
Pochodzę z relacyjnych baz danych SQL, więc normalizację mam we krwi. To powiedziawszy, czerpię korzyści z nierelacyjnych baz danych pod względem prostoty i skalowania, a moje przeczucie mówi mi, że musi istnieć bogatsze pokrywanie się możliwości projektowych. Co ty zrobiłeś?
Do Twojej wiadomości, odbyły się tutaj dyskusje StackOverflow na podobne tematy:
Odpowiedzi:
Myślę, że musisz wziąć pod uwagę, że nierelacyjne DBMS różnią się znacznie pod względem ich modelu danych, a zatem koncepcyjny projekt danych również będzie się znacznie różnić. W wątku Projektowanie danych w nierelacyjnych bazach danych grupy NOSQL Google różne paradygmaty są podzielone na następujące kategorie:
Zajmuję się głównie graficznymi bazami danych , a elegancja projektowania danych przy użyciu tego paradygmatu była tym, co mnie tam sprowadziło, zmęczonego niedociągnięciami RDBMS . Na tej stronie wiki umieściłem kilka przykładów projektowania danych przy użyciu bazy danych wykresów, a także przykład, jak modelować podstawowe dane filmu / aktora / roli IMDB .
Prezentacja slajdów (udostępnianie slajdów) Graph Databases and the Future of Large Scale Knowledge Management by Marko Rodriguez zawiera bardzo ładne wprowadzenie do projektowania danych przy użyciu również graficznej bazy danych.
Odpowiedzi na konkretne pytania z punktu widzenia graphdb:
Projekt alternatywny: dodawanie relacji między wieloma różnymi rodzajami jednostek bez żadnych obaw lub potrzeby wstępnego definiowania, które jednostki mogą się łączyć.
Niwelowanie luki: staram się robić to inaczej dla każdego przypadku, w oparciu o samą domenę, ponieważ nie chcę „wykresu tabelarycznego” i tym podobnych. Jednak tutaj jest kilka informacji na temat automatycznego tłumaczenia z RDBMS na graphdb.
Jawne modele danych: robię to cały czas (w stylu tablicy), a następnie używam modelu, który jest również w bazie danych.
Miss ze świata RDBMS: łatwe sposoby tworzenia raportów. Aktualizacja: może to nie jest to trudne do tworzenia raportów z bazy danych wykresu, zobacz Tworzenie raportu dla bazy danych Neo4J Sample .
źródło
Dopiero co zacząłem od nierelacyjnych baz danych i nadal próbuję to obejść i dowiedzieć się, jaki byłby najlepszy model. Mogę mówić tylko w imieniu CouchDB.
Mimo to mam kilka wstępnych wniosków:
Czy wymyśliłeś alternatywne projekty, które działają znacznie lepiej w świecie nierelacyjnym?
Koncentracja na projektowaniu zmienia się: projekt modelu dokumentu (odpowiadającego tabelom DB) staje się prawie nieistotny, podczas gdy wszystko zależy od projektowania widoków (odpowiadających zapytaniom).
Baza danych dokumentów zamienia złożoność: SQL ma nieelastyczne dane i elastyczne zapytania, bazy danych dokumentów są na odwrót.
Model CouchDB to zbiór „dokumentów JSON” (w zasadzie zagnieżdżonych tabel skrótów). Każdy dokument ma unikalny identyfikator i można go w prosty sposób pobrać za pomocą identyfikatora. Dla każdego innego zapytania piszesz „widoki”, które są nazwanymi zestawami funkcji mapowania / redukcji. Widoki zwracają wynik w postaci listy par klucz / wartość.
Sztuczka polega na tym, że nie należy wysyłać zapytań do bazy danych w takim sensie, w jakim wysyłamy zapytania do bazy danych SQL: wyniki działania funkcji widoku są przechowywane w indeksie, a można zapytać tylko o indeks. (Jako „pobierz wszystko”, „pobierz klucz” lub „pobierz zakres klucza”).
Najbliższa analogia w świecie SQL byłaby taka, gdybyś mógł wysyłać zapytania do bazy danych tylko przy użyciu procedur składowanych - każde zapytanie, które chcesz obsługiwać, musi być wstępnie zdefiniowane.
Projekt dokumentów jest niezwykle elastyczny. Znalazłem tylko dwa ograniczenia:
Ale wszystko zależy od projektowania widoków.
Alternatywne projekty, które odkryłem, że rzędy wielkości pracy są lepsze z CouchDB niż z jakąkolwiek bazą danych SQL, są na poziomie systemu, a nie na poziomie pamięci. Jeśli masz jakieś dane i chcesz je udostępnić na stronie internetowej, złożoność całego systemu jest zmniejszona o co najmniej 50%:
W przypadku zwykłych aplikacji internetowych bazy danych oparte na dokumentach / JSON są ogromną korzyścią, a wady mniej elastycznych zapytań i dodatkowego kodu do walidacji danych wydają się niewielką ceną do zapłacenia.
Czy uderzyłeś głową w coś, co wydaje się niemożliwe?
Jeszcze nie. Mapowanie / redukcja jako metoda wysyłania zapytań do bazy danych jest nieznana i wymaga dużo więcej myślenia niż pisanie SQL. Istnieje dość mała liczba prymitywów, więc uzyskanie potrzebnych wyników jest przede wszystkim kwestią kreatywności w określaniu kluczy.
Istnieje ograniczenie polegające na tym, że zapytania nie mogą przeglądać dwóch lub więcej dokumentów w tym samym czasie - nie ma połączeń ani innych rodzajów relacji obejmujących wiele dokumentów, ale jak dotąd nic nie było nie do pokonania.
Jako przykład ograniczenia, liczenia i sumy są łatwe, ale średnie nie mogą być obliczane przez widok / zapytanie CouchDB. Poprawka: Zwróć sumę i policz osobno i oblicz średnią na kliencie.
Czy udało Ci się wypełnić lukę za pomocą jakichkolwiek wzorców projektowych, np. Przy tłumaczeniu z jednego na drugi?
Nie jestem pewien, czy to wykonalne. To bardziej kompletne przeprojektowanie, jak tłumaczenie programu w stylu funkcjonalnym na styl obiektowy. Ogólnie rzecz biorąc, typów dokumentów jest znacznie mniej niż tabel SQL i więcej danych w każdym dokumencie.
Jednym ze sposobów, aby o tym pomyśleć, jest przyjrzenie się kodowi SQL w poszukiwaniu wstawek i typowych zapytań: które tabele i kolumny są aktualizowane, gdy na przykład klient składa zamówienie? A które z miesięcznych raportów sprzedaży? Te informacje powinny prawdopodobnie znaleźć się w tym samym dokumencie.
To znaczy: jeden dokument do zamówienia, zawierający identyfikator klienta i identyfikatory produktów, z powielonymi polami, jeśli jest to konieczne, aby uprościć zapytania. Wszystko w dokumencie może być łatwo sprawdzane, wszystko, co wymaga porównania między, powiedzmy, Zamówieniem i Klientem, musi być zrobione przez klienta. Jeśli więc chcesz uzyskać raport sprzedaży według regionu, prawdopodobnie powinieneś umieścić kod regionu w zamówieniu.
Czy w ogóle tworzysz teraz jawne modele danych (np. W UML)?
Przepraszamy, nigdy nie robiłem zbyt wiele UML przed bazami danych dokumentów :)
Ale potrzebujesz jakiegoś modelu mówiącego, które pola należą do których dokumentów i jakie rodzaje wartości zawierają. Zarówno dla twojego własnego późniejszego odniesienia, jak i dla upewnienia się, że wszyscy używający DB znają konwencje. Ponieważ na przykład nie pojawia się błąd, jeśli zapiszesz datę w polu tekstowym, a każdy może dodać lub usunąć dowolne pole, potrzebujesz zarówno kodu walidacyjnego, jak i konwencji, aby uzyskać luz. Zwłaszcza jeśli pracujesz z zasobami zewnętrznymi.
Czy brakuje Ci którejś z głównych dodatkowych usług dostarczanych przez RDBMS?
Nie. Ale z wykształcenia jestem programistą aplikacji internetowych, zajmujemy się bazami danych tylko w takim zakresie, w jakim musimy :)
Firma, dla której pracowałem, stworzyła produkt (aplikację internetową), który został zaprojektowany do działania w bazach danych SQL pochodzących od wielu dostawców, a „dodatkowe usługi” są tak różne od DB do DB, że musiały być wdrażane oddzielnie dla każdego DB. Więc mniej pracy było dla nas, aby przenieść funkcjonalność z RDBMS. To nawet rozszerzyło się na wyszukiwanie pełnotekstowe.
Więc cokolwiek rezygnuję, jest czymś, czego tak naprawdę nigdy nie miałem. Oczywiście twoje doświadczenia mogą się różnić.
Uwaga: obecnie pracuję nad aplikacją internetową do obsługi danych finansowych, notowań giełdowych i tym podobnych. Jest to bardzo dobre dopasowanie do bazy danych dokumentów, z mojego punktu widzenia wszystkie zalety bazy danych (trwałość i zapytania) są bezproblemowe.
Ale te dane są dość niezależne od siebie, nie ma złożonych zapytań relacyjnych. Otrzymuj najnowsze notowania według tickera, pobieraj cytaty według tickera i zakresu dat, pobieraj meta-informacje firmy, to prawie wszystko. Innym przykładem, który widziałem, była aplikacja blogowa, a blogi również nie charakteryzują się ogromnie skomplikowanymi schematami bazy danych.
Próbuję powiedzieć, że wszystkie udane aplikacje baz danych dokumentów, które znam, dotyczyły danych, które nie miały zbyt wielu powiązań: dokumenty (jak w wyszukiwarce Google), posty na blogach, artykuły z wiadomościami, dane finansowe .
Spodziewam się, że istnieją zbiory danych, które lepiej odwzorowują SQL niż model dokumentu, więc wyobrażam sobie, że SQL przetrwa.
Ale dla tych z nas, którzy chcą prostego sposobu na przechowywanie i pobieranie danych - a podejrzewam, że jest nas wielu - bazy danych dokumentów (jak w CouchDB) są wybawieniem.
źródło
Odpowiadam na to z CouchDB z tyłu głowy, ale przypuszczam, że większość z nich będzie prawdą również dla innych DB. Przyjrzeliśmy się użyciu CouchDB, ale ostatecznie zdecydowaliśmy się na to nie, ponieważ nasz dostęp do danych nie jest wcześniej znany, a skalowalność nie jest problemem.
Trudniej:
Łatwiej:
Modelowanie powinno być mniej więcej takie samo, ale musisz uważać na to, co umieścisz w jednym dokumencie: UML może być również używany zarówno do modelowania OO, jak i modelowania DB, które już są dwiema różnymi bestiami.
Chciałbym zobaczyć dobrą, otwartą bazę danych OO ładnie zintegrowaną z C # / Silverlight. Żeby wybór był jeszcze trudniejszy. :)
źródło
Pliki płaskie od dawna uważane są za tajemnicze i niepraktyczne w przypadku zbioru danych o dowolnej wielkości. Jednak szybsze komputery z większą ilością pamięci umożliwiają załadowanie pliku do pamięci i sortowanie go w czasie rzeczywistym, przynajmniej w przypadku stosunkowo małych aplikacji n i lokalnych, przeznaczonych dla jednego użytkownika.
Na przykład zazwyczaj można odczytać zbiór 10 000 rekordów ORAZ posortować go według pola w mniej niż pół sekundy, co jest akceptowalnym czasem odpowiedzi.
Oczywiście istnieją powody, aby używać bazy danych zamiast zwykłego pliku - operacje relacyjne, integralność danych, możliwość wielu użytkowników, zdalny dostęp, większa pojemność, standaryzacja itp., Ale zwiększona prędkość komputera i pojemność pamięci spowodowały manipulację w pamięci danych w niektórych przypadkach jest bardziej praktyczne.
źródło
Relacyjne bazy danych, które widzę w prawdziwym życiu, nie są w ogóle dobrze znormalizowane, wbrew twojemu twierdzeniu. Na pytanie projektanci odpowiadają, że dzieje się tak głównie ze względu na wydajność. RDBM nie są dobre w łączeniu, więc tabele wydają się być zbyt szerokie z punktu widzenia normalizacji. Bazy danych zorientowane obiektowo są w tym znacznie lepsze.
Innym punktem, w którym RDBM mają problemy, jest obsługa kluczy zależnych od historii / czasu.
źródło