Non-Relational Database Design [zamknięty]

Dopiero zacząłem od non-relational DBs, i nadal staram się owinąć głowę wokół niego i dowiedzieć się, jaki byłby najlepszy model. I mogę mówić tylko za CouchDB.

Mimo to mam kilka wstępnych wniosków:

Czy wymyśliłeś alternatywne projekty, które działają znacznie lepiej w nie-relacyjnym świecie?

Nacisk na projekt zmienia się: projekt modelu dokumentu (odpowiadającego tabelom DB) staje się niemal nieistotny, a wszystko zależy od projektowanie widoków (odpowiadających zapytaniom).

Dokument DB rodzaj swaps złożoności: SQL ma nieelastyczne Dane i elastyczne zapytania, dokument DBs są na odwrót.

Model CouchDB jest zbiorem "dokumentów JSON" (zasadniczo zagnieżdżonych tabel skrótów). Każdy dokument ma unikalny identyfikator i może być trywialnie pobrany przez ID. Dla każdego innego zapytania piszesz "widoki", które są nazwane zestawami funkcji map/reduce. Widoki zwracają wynik ustawiony jako lista klucza / wartości pary.

Sztuczka polega na tym, że nie odpytywasz bazy danych w tym sensie, że odpytywasz bazę danych SQL: wyniki uruchamiania funkcji widoku są przechowywane w indeksie i tylko indeks może być zapytany. (Jako "get everything", "get key" lub "get key range".)

Najbliższą analogią w świecie SQL byłoby, gdybyś mógł tylko odpytywać DB za pomocą procedur przechowywanych - każde zapytanie, które chcesz obsługiwać, musi być predefiniowane.

Projekt dokumentów jest niezwykle elastyczny. Mam znaleziono tylko dwa ograniczenia:

• przechowuj Powiązane Dane razem w tym samym dokumencie, ponieważ nie ma nic odpowiadającego połączeniu.
• nie rób tak dużych dokumentów, aby były zbyt często aktualizowane (jak umieszczenie całej sprzedaży firmy w danym roku w tym samym dokumencie), ponieważ każda aktualizacja dokumentu powoduje ponowną indeksację.

Ale wszystko zależy od projektowania widoków.

Alternatywne wzory, które odkryłem, że działają rzędów wielkości lepiej z CouchDB niż jakakolwiek baza danych SQL jest na poziomie systemu, a nie na poziomie pamięci masowej. Jeśli masz jakieś Dane i chcesz je podać do strony internetowej, złożoność całego systemu jest zmniejszona o co najmniej 50%:

• no designing DB tables (minor issue)
W 2007 roku firma została założona przez firmę JDBC, która od 2007 roku zajmuje się dystrybucją i dystrybucją sprzętu komputerowego.]}
• proste mapowanie DB-to-object z JSON, które jest prawie trywialne w porównaniu do tego samego w SQL (Ważne!)
• możesz potencjalnie pominąć cały serwer aplikacji, ponieważ możesz zaprojektować dokumenty do pobrania bezpośrednio przez przeglądarkę za pomocą AJAX i dodać trochę polerowania JavaScript, zanim zostaną wyświetlone jako HTML. (ogromny!!)

Dla zwykłych aplikacji webowych DBS oparte na dokumencie / JSON to ogromna wygrana,a wady mniej elastycznych zapytań i dodatkowy kod do walidacji danych wydaje się niewielką ceną.

Czy trafiłeś twoja głowa przeciwko czemuś, co wydaje się niemożliwe?

Jeszcze nie. Map/reduce jako sposób zapytań do bazy danych jest nieznany i wymaga znacznie więcej myślenia niż pisanie SQL. Istnieje dość mała liczba prymitywów, więc uzyskanie potrzebnych wyników to przede wszystkim kwestia kreatywności w określaniu kluczy.

Istnieje ograniczenie w tym, że zapytania nie mogą patrzeć na dwa lub więcej dokumentów w tym samym czasie - nie łączy ani innych rodzajów relacji wielodokumentowych, ale do tej pory nic nie było nie do pokonania.

Jako przykładowe ograniczenie, liczniki i sumy są łatwe, ale średnich nie można obliczyć za pomocą widoku / zapytania CouchDB. Fix: zwróć sumę i policz osobno i Oblicz średnią na kliencie.

Czy uzupełniłeś lukę o jakieś wzorce projektowe, np. do tłumaczenia z jednego na drugi?

Nie jestem pewien, czy to możliwe. To bardziej kompletny przeprojektowanie, jak tłumaczenie funkcjonalnego programu stylowego na styl obiektowy. W ogólnie rzecz biorąc, istnieje znacznie mniej typów dokumentów niż tabele SQL i więcej danych w każdym dokumencie.

Jednym ze sposobów myślenia o tym jest spojrzenie na swój SQL dla wstawek i typowych zapytań: które tabele i kolumny są aktualizowane, gdy Klient składa zamówienie, na przykład? A które do miesięcznych raportów sprzedaży? Te informacje powinny być w tym samym dokumencie.

Czyli: jeden dokument do zamówienia, zawierający ID klienta i ID Produktu, z replikowanymi polami w razie potrzeby do uprość zapytania. Wszystko w dokumencie może być łatwo queried, wszystko, co wymaga powiązania między say zamówienia i klienta musi być wykonane przez Klienta. Więc jeśli chcesz raport sprzedaży według regionu, prawdopodobnie powinieneś umieścić kod regionu w zamówieniu.

Czy w ogóle robisz teraz jawne modele danych (np. w UML)?

Sorry, nigdy nie robiłem zbyt wiele UML przed dokumentem DBs:)

Ale potrzebny jest jakiś model mówiący, które pola należą do których dokumenty i jakie wartości zawierają. Zarówno dla własnego odniesienia później i aby upewnić się, że każdy korzystający z DB zna konwencje. Ponieważ na przykład zapisywanie daty w polu tekstowym nie powoduje już błędu, a każdy może dodać lub usunąć dowolne pole, na które ma ochotę, potrzebujesz zarówno kodu weryfikacyjnego, jak i konwencji, aby podnieść Luz. Zwłaszcza jeśli pracujesz z zewnętrznymi zasobami.

Czy tęsknisz za którąś z głównych dodatkowych usług, które zapewniają RDBMSes?

Nie. Ale moje doświadczenie to Web Application developer, zajmujemy się bazami danych tylko w takim zakresie, w jakim musimy :)

Firma, dla której pracowałem, stworzyła produkt (webapp), który został zaprojektowany do działania w bazach danych SQL od wielu dostawców, A "Dodatkowe usługi" są tak różne od DB do DB, że musiały być zaimplementowane oddzielnie dla każdego DB. Więc to było mniej pracy dla nas, aby przenieść funkcjonalność z RDBMS. Rozszerzono to nawet na wyszukiwanie pełnotekstowe.

Więc cokolwiek daję up to coś, czego nigdy nie miałem. Oczywiście, twoje doświadczenie może się różnić.

Zastrzeżenie: to, nad czym teraz pracuję, to webapp dla danych finansowych, notowań giełdowych i tym podobnych. Jest to bardzo dobre dopasowanie do DB dokumentu, z mojego punktu widzenia dostaję wszystkie zalety DB (wytrwałość i zapytania) bez żadnych kłopotów.

Ale dane te są dość niezależne od siebie, nie ma złożonych zapytań relacyjnych. Pobierz najnowsze cytaty przez ticker, Pobierz cytaty według tickera i zakresu dat, zdobądź meta-informacje o firmie, to prawie wszystko. Innym przykładem, jaki widziałem, była aplikacja blogowa, a blogi również nie charakteryzują się ogromnie skomplikowanymi schematami baz danych.

Próbuję powiedzieć, że wszystkie udane aplikacje document DBs, które znam, były z danymi, które nie miały zbyt wielu wzajemnych powiązań: dokumenty (jak w wyszukiwarce Google), posty na blogu, artykuły informacyjne, dane finansowe.

Spodziewam się, że tam czy zbiory danych, które mapują lepiej do SQL niż do modelu dokumentu, więc wyobrażam sobie, że SQL przetrwa.

Ale dla tych z nas, którzy po prostu chcą prostego sposobu przechowywania i pobierania danych-i podejrzewam, że jest nas wielu - bazy dokumentów (jak w CouchDB) są darem niebios.

Odpowiadam na to z CouchDB w tyle mojego umysłu, ale przypuszczam, że większość byłaby prawdziwa również dla innych DBs. Przyjrzeliśmy się użyciu CouchDB, ale ostatecznie zdecydowaliśmy się na to, ponieważ nasz dostęp do danych nie jest wcześniej znany, a skalowalność nie jest problemem.

:

• wymaga przemyślenia na poziomie konceptualnym, więc jest "trudniejsze", ponieważ jest po prostu inne. Ponieważ musisz znać swoje wzorce dostępu do danych z wyprzedzeniem, nie można zastosować automatycznego tłumaczenia. Będziesz musiał dodaj przynajmniej wzorzec dostępu.
• spójność nie jest obsługiwana przez bazę danych, ale musi być rozpatrywana w aplikacji. Mniej Gwarancji oznacza łatwiejszą migrację, fail-over i lepszą skalowalność kosztem bardziej skomplikowanej aplikacji. Aplikacja musi radzić sobie z konfliktami i niespójnościami.
• Linki krzyżujące dokumenty (lub klucz/wartość) muszą być rozpatrywane również na poziomie aplikacji.
• bazy danych typu SQL mają IDE, które są znacznie bardziej dojrzałe. You get a lot bibliotek wsparcia (chociaż warstwy tych bibliotek sprawiają, że rzeczy znacznie bardziej skomplikowane niż potrzebne dla SQL).

Łatwiej:

• szybciej, jeśli znasz swoje wzorce dostępu do danych.
• migracja / Fail-over jest łatwiejsza dla bazy danych, ponieważ jako programista aplikacji nie składamy żadnych obietnic. Chociaż dostajesz ostateczną konsekwencję. Prawdopodobnie. W końcu. Jakiś czas.
• Jeden klucz / wartość jest znacznie łatwiejszy do zrozumienia niż jeden wiersz z tabeli. Wszystkie (drzewo) relacje są już w, A kompletne obiekty mogą być rozpoznawane.

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 są już dwoma różnymi bestiami.

Chciałbym zobaczyć dobrą otwartą bazę danych oo ładnie zintegrowaną z C# / Silverlight. Żeby jeszcze bardziej utrudnić wybór. :)

Pliki płaskie od dawna są uważane za tajemnicze i niepraktyczne dla 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 dla stosunkowo małych aplikacji n i lokalnych, dla pojedynczego użytkownika.

Na przykład, zwykle można odczytać plik zawierający 10 000 rekordów i posortować go na polu w czasie krótszym niż pół sekundy, co jest akceptowalnym czasem odpowiedzi.

Oczywiście istnieją powody, aby używać bazy danych zamiast płaski plik-operacje relacyjne, integralność danych, zdolność wielu użytkowników, zdalny dostęp, większa pojemność, standaryzacja itp., ale zwiększona szybkość komputera i pojemność pamięci sprawiły, że manipulowanie danymi w pamięci stało się w niektórych przypadkach bardziej praktyczne.

Relacyjne bazy danych, które widzę w prawdziwym życiu, nie są zbyt dobrze znormalizowane, wbrew Pańskiemu twierdzeniu. Na pytanie projektanci mówią mi, że to głównie ze względu na wydajność. RDBMs nie są dobre w łączeniu, więc tabele wydają się być zbyt szerokie z punktu widzenia normalizacji. Zorientowane obiektowo bazy danych są w tym znacznie lepsze.

Innym punktem, w którym RDBMs ma problemy, jest obsługa kluczy zależnych od historii/czasu.