bazie Modelowanie NoSQL (przy konwersji z bazy danych SQL)

Question

Mam bazę danych SQL, który chcę przekonwertować do jednego NoSQL (obecnie używam RavenDB)

Oto moje tabele:

śledzenia :

ID (PK, bigint, not null) 
DeploymentID (FK, int, not null) 
AppCode (int, not null) 

Wdrożenie:

DeploymentID (PK, int, not null) 
DeploymentVersion (varchar(10), not null) 
DeploymentName (nvarchar(max), not null) 

Zastosowanie:

AppID (PK, int, not null) 
AppName (nvarchar(max), not null) 

Obecnie mam te wiersze w moich tabelach:

Ślad:

ID: 1 , DeploymentID: 1, AppCode: 1 
ID: 2 , DeploymentID: 1, AppCode: 2 
ID: 3 , DeploymentID: 1, AppCode: 3 
ID: 3 , DeploymentID: 2, AppCode: 1 

Wdrożenie:

DeploymentID: 1 , DeploymentVersion: 1.0, DeploymentName: "Test1" 
DeploymentID: 2 , DeploymentVersion: 1.0, DeploymentName: "Test2" 

Zastosowanie:

AppID: 1 , AppName: "Test1" 
AppID: 2 , AppName: "Test2" 
AppID: 3 , AppName: "Test3" 

Moje pytanie brzmi: JAK zbudować mój model dokumentu NoSQL?

Powinno to wyglądać tak:

trace/1 
{ 
"Deployment": [ { "DeploymentVersion": "1.0", "DeploymentName": "Test1" } ], 
"Application": "Test1" 
} 

trace/2 
{ 
"Deployment": [ { "DeploymentVersion": "1.0", "DeploymentName": "Test1" } ], 
"Application": "Test2" 
} 

trace/3 
{ 
"Deployment": [ { "DeploymentVersion": "1.0", "DeploymentName": "Test1" } ], 
"Application": "Test3" 
} 

trace/4  
{ 
"Deployment": [ { "DeploymentVersion": "1.0", "DeploymentName": "Test2" } ], 
"Application": "Test1" 
} 

a co jeśli Wdrożenie 1 zostanie zmienione? Czy powinienem przejrzeć każdy dokument i zmienić dane?

Kiedy powinienem używać referencji w NoSQL?

Answer 1

Sposób modelowania dokumentów zależy głównie od aplikacji i domeny. Stamtąd można udoskonalić model dokumentu poprzez zrozumienie wzorców dostępu do danych.

Ślepe próby odwzorowania relacyjnego modelu danych na model nierelacyjny prawdopodobnie nie są dobrym pomysłem.

AKTUALIZACJA: Myślę, że Matt ma główną ideę mojego punktu tutaj. Próbuję powiedzieć, że nie istnieje żadna zalecana metoda (o której mi wiadomo) do przetłumaczenia relacyjnego modelu danych (takiego jak znormalizowany schemat SQL) do nierelacyjnego modelu danych (takiego jak model dokumentu) bez zrozumienia i biorąc pod uwagę domenę aplikacji. Pozwól, że nieco się tutaj rozwiążę ...

Po przejrzeniu Twojego schematu SQL, nie mam pojęcia, co to jest ślad poza tabelą, która wydaje się dołączać do aplikacji i wdrożeń. Nie mam też pojęcia, w jaki sposób twoja aplikacja zwykle wysyła zapytania do danych. Wiedza na ten temat niewiele różni się, gdy modelujesz swoje dokumenty, tak jak ma to wpływ na sposób modelowania twoich obiektów aplikacji (lub obiektów domenowych).

Tak więc model dokumentu sugerowany w pytaniu może, ale nie musi działać dla Ciebie.

Answer 2

Bazy dokumentów takie jak Raven nie są relacyjnymi bazami danych. NIE MOŻESZ najpierw zbudować modelu bazy danych, a później zdecydować się na różne interesujące sposoby jej wyszukiwania.Zamiast tego należy najpierw określić, które wzorce dostępu mają być obsługiwane, a następnie odpowiednio zaprojektować schematy dokumentów.

Aby odpowiedzieć na Twoje pytanie, naprawdę musimy wiedzieć, w jaki sposób zamierzasz korzystać z danych. Na przykład wyświetlanie wszystkich śladów uporządkowanych według czasu jest wyraźnie odmiennym scenariuszem niż wyświetlanie śladów powiązanych z konkretnym wdrożeniem lub aplikacją. Każde z tych wymagań będzie dyktować inny projekt, ponieważ będzie je wspierać.

Sam w sobie może być przydatny dla Ciebie (?), Ale podejrzewam, że chcesz więcej konkretnych odpowiedzi :) Więc proszę dodać kilka dodatkowych informacji na temat zamierzonego użycia.

Istnieje kilka „do” i „zakazów” przy podejmowaniu decyzji w sprawie strategii:

zrobić: Optymalizacja dla typowych przypadków użycia. Często występuje rozbicie na 20/80, gdzie 20% dysków UX 80% obciążenia - klasyczny przykład strony docelowej aplikacji internetowych. Pierwszym priorytetem jest upewnienie się, że są one tak wydajne, jak to tylko możliwe. Upewnij się, że twój model danych pozwala albo A) ładować je na jedno żądanie IO, albo B) jest przyjazny dla pamięci podręcznej.

DONT: nie wpadnij w pułapkę "N + 1". Ten wzorzec ma miejsce, gdy model danych zmusza do wykonywania połączeń N w celu załadowania N podmiotów, często poprzedzonych dodatkowym wywołaniem, aby uzyskać listę N-identyfikatorów. To zabójca, zwłaszcza razem z # 3 ...

DO: Zawsze ograniczaj (poprzez UX) ilość danych, które chcesz pobrać. Jeśli użytkownik ma 3729 komentarzy, najwyraźniej nie pobierzesz ich wszystkich naraz. Nawet gdyby było to wykonalne z perspektywy bazy danych, doświadczenie użytkownika byłoby okropne. Właśnie dlatego wyszukiwarki wykorzystują paradygmat "następnych 20 wyników". Możesz więc (na przykład) dopasować strukturę bazy danych do UX i zapisać komentarze w blokach 20. Następnie każda odświeżana strona wymaga pojedynczego DB get.

DO: Zrównoważyć wymagania dotyczące odczytu i zapisu. Niektóre typy systemów są ciężkie do odczytu i można założyć, że dla każdego zapisu będzie wiele odczytów (dobrym przykładem jest StackOverflow). Czyli jest sens, aby pisanie było droższe, aby uzyskać korzyści z odczytu. Na przykład denormalizacja i powielanie danych. Inne systemy są równomiernie zbalansowane lub nawet ciężkie i wymagają innych podejść.

DO: Wykorzystaj wymiar CZASU na swoją korzyść. Twitter jest klasycznym przykładem: 99,99% tweetów nigdy nie będzie dostępnych po pierwszej godzinie/dniu/tygodniu/czymkolwiek. Otwiera to wszelkiego rodzaju interesujące możliwości optymalizacji w twoim schemacie danych.

To tylko wierzchołek góry lodowej. Proponuję trochę przeczytać na bazujących na kolumnach systemach NoSQL (takich jak Cassandra)