Współczesne systemy informatyczne są dość złożone. Przede wszystkim ich złożoność wynika ze złożoności przetwarzanych w nich danych. Złożoność danych często wynika z różnorodności stosowanych modeli danych. Na przykład, gdy dane stają się „duże”, jedną z problematycznych cech jest nie tylko ich objętość („wolumen”), ale także ich różnorodność („różnorodność”).
Jeśli jeszcze nie znalazłeś błędu w rozumowaniu, czytaj dalej.
Zawartość
Trwałość poligloty
Powyższe prowadzi do tego, że czasami nawet w ramach jednego systemu konieczne jest wykorzystanie kilku różnych SZBD do przechowywania danych i rozwiązywania różnych problemów ich przetwarzania, z których każdy obsługuje własny model danych. Lekką ręką M. Fowlera, wiele znanych książek i jedna z Manifest Agile, tak nazywa się tę sytuację przechowywanie wielowariantowe („uporczywość poligloty”).
Fowler ma także następujący przykład organizacji przechowywania danych w w pełni funkcjonalnej i obciążającej aplikacji z zakresu e-commerce.
Przykład ten jest oczywiście nieco przesadzony, ale można znaleźć pewne względy przemawiające za wyborem tego lub innego systemu DBMS do odpowiedniego celu, na przykład: .
Wiadomo, że bycie służącą w takim zoo nie jest łatwe.
- Ilość kodu przechowującego dane rośnie proporcjonalnie do liczby używanych systemów DBMS; ilość danych synchronizujących kod jest dobra, jeśli nie proporcjonalna do kwadratu tej liczby.
- Jako wielokrotność liczby wykorzystywanych SZBD, koszty zapewnienia charakterystyki przedsiębiorstwa (skalowalność, odporność na awarie, wysoka dostępność) każdego z używanych SZBD rosną.
- Niemożliwe jest zapewnienie cech korporacyjnych podsystemu magazynowania jako całości – zwłaszcza transakcyjności.
Z punktu widzenia dyrektora zoo wszystko wygląda tak:
- Kilkukrotny wzrost kosztów licencji i wsparcia technicznego ze strony producenta DBMS.
- Nadmierne zatrudnienie i wydłużone terminy.
- Bezpośrednie straty finansowe lub kary z powodu niespójności danych.
Następuje znaczny wzrost całkowitego kosztu posiadania systemu (TCO). Czy jest jakieś wyjście z sytuacji „wielu opcji przechowywania”?
Wiele modeli
Termin „magazyn wieloczynnikowy” wszedł do użytku w 2011 roku. Świadomość problemów podejścia i poszukiwanie rozwiązania zajęło kilka lat, a już w 2015 roku ustami analityków Gartnera została sformułowana odpowiedź:
- Z "»:
Przyszłość systemów DBMS, ich architektur i sposobów wykorzystania jest wielomodelowa.
- Z "»:
Wiodące operacyjne systemy DBMS będą oferować wiele modeli – relacyjnych i nierelacyjnych – w ramach jednej platformy.
Wygląda na to, że tym razem analitycy Gartnera nie mylili się w swoich prognozach. Jeśli wejdziesz na stronę z DBMS w DB-Engines, widać toоWiększość jej liderów pozycjonuje się jako wielomodelowe systemy DBMS. To samo można zobaczyć na stronie z dowolną oceną prywatną.
Poniższa tabela przedstawia DBMS - liderów w każdym z prywatnych ratingów, które twierdzą, że są wielomodelowe. Dla każdego SZBD wskazany jest pierwotnie obsługiwany model (który był kiedyś jedynym) i wraz z nim modele aktualnie obsługiwane. Na liście znajdują się również systemy DBMS, które pozycjonują się jako „pierwotnie wielomodelowe” i według twórców nie mają żadnego początkowego odziedziczonego modelu.
| DBMS | Model początkowy | Dodatkowe modele |
|---|---|---|
| wyrocznia | Relacyjny | Wykres, dokument |
| MS SQL | Relacyjny | Wykres, dokument |
| PostgreSQL | Relacyjny | Wykres*, dokument |
| MarekLogika | film dokumentalny | Wykres, relacyjny |
| MongoDB | film dokumentalny | Klucz-wartość, wykres* |
| DataStax | Szeroka kolumna | Dokument, wykres |
| Redis | Kluczowa wartość | Dokument, wykres* |
| ArangoDB | - | Wykres, dokument |
| OrientDB | - | Wykres, dokument, relacyjny |
| Azure CosmosDB | - | Wykres, dokument, relacyjny |
Uwagi do tabeli
Gwiazdkami w tabeli zaznaczono stwierdzenia wymagające zastrzeżeń:
- System DBMS PostgreSQL nie obsługuje grafowego modelu danych, ale ten produkt go obsługuje , takie jak AgensGraph.
- W odniesieniu do MongoDB bardziej poprawne jest mówienie o obecności operatorów grafów w języku zapytań (, ) niż o obsługę modelu grafowego, choć oczywiście ich wprowadzenie wymagało pewnych optymalizacji na poziomie pamięci fizycznej w kierunku obsługi modelu grafowego.
- W odniesieniu do Redis mamy na myśli rozszerzenie .
Następnie dla każdej z klas pokażemy, jak w SZBD tej klasy zaimplementowana jest obsługa kilku modeli. Za najważniejsze uznamy modele relacyjne, dokumentowe i grafowe, a na przykładach konkretnych SZBD pokażemy, jak implementowane są „brakujące”.
Wielomodelowy system zarządzania bazą danych oparty na modelu relacyjnym
Wiodące obecnie SZBD są relacyjne; prognozy Gartnera nie można by uznać za prawdziwą, gdyby RDBMS nie wykazywały ruchu w kierunku multimodelowania. I demonstrują. Teraz pomysł, że wielomodelowy DBMS jest jak szwajcarski nóż, który nie potrafi nic dobrze zrobić, można skierować bezpośrednio do Larry'ego Ellisona.
Autor preferuje jednak implementację multimodelowania w Microsoft SQL Server, na przykładzie którego zostanie opisana obsługa RDBMS dla modeli dokumentów i grafów.
Model dokumentu w MS SQL Server
Na Habré pojawiły się już dwa znakomite artykuły o tym, jak MS SQL Server implementuje obsługę modelu dokumentu; ograniczę się do krótkiego powtórzenia i komentarza:
Sposób obsługi modelu dokumentu w MS SQL Server jest dość typowy dla relacyjnych systemów DBMS: proponuje się przechowywanie dokumentów JSON w zwykłych polach tekstowych. Obsługa modelu dokumentu polega na zapewnieniu specjalnych operatorów do analizowania tego JSON:
- wyodrębnić wartości atrybutów skalarnych,
- wyodrębnić dokumenty podrzędne.
Drugi argument obu operatorów jest wyrażeniem w składni podobnej do JSONPath.
Abstrakcyjnie można powiedzieć, że tak przechowywane dokumenty nie są „bytami pierwszej klasy” w relacyjnym systemie DBMS, w przeciwieństwie do krotek. Konkretnie w MS SQL Server nie ma obecnie indeksów na polach dokumentów JSON, co utrudnia łączenie tabel wykorzystujących wartości tych pól, a nawet wybieranie dokumentów korzystających z tych wartości. Istnieje jednak możliwość utworzenia dla takiego pola kolumny wyliczanej i indeksu na niej.
Dodatkowo MS SQL Server umożliwia wygodne konstruowanie dokumentu JSON z zawartości tabel za pomocą operatora - możliwość, w pewnym sensie, odwrotna do poprzedniej, konwencjonalnego przechowywania. Oczywiste jest, że niezależnie od tego, jak szybki jest RDBMS, takie podejście jest sprzeczne z ideologią dokumentowych DBMS, które zasadniczo przechowują gotowe odpowiedzi na popularne zapytania i mogą rozwiązywać jedynie problemy związane z łatwością programowania, ale nie szybkością.
Wreszcie MS SQL Server pozwala rozwiązać odwrotny problem konstrukcji dokumentu: możesz rozłożyć JSON na tabele za pomocą . Jeśli dokument nie jest całkowicie płaski, będziesz musiał go użyć CROSS APPLY.
Model grafowy w MS SQL Server
Obsługa modelu grafowego (LPG) jest również w pełni zaimplementowana w Microsoft SQL Server : Proponuje się użycie specjalnych tabel do przechowywania węzłów i krawędzi grafów. Takie tabele tworzone są za pomocą wyrażeń CREATE TABLE AS NODE и CREATE TABLE AS EDGE odpowiednio.
Tabele pierwszego typu przypominają zwykłe tabele do przechowywania rekordów, z tą tylko zewnętrzną różnicą, że tabela zawiera pole systemowe $node_id — unikalny identyfikator węzła wykresu w bazie danych.
Podobnie tabele drugiego typu posiadają pola systemowe $from_id и $to_id, wpisy w takich tablicach jasno definiują połączenia pomiędzy węzłami. Do przechowywania relacji każdego typu używana jest osobna tabela.
Zilustrujmy to przykładem. Niech dane wykresu będą miały układ podobny do pokazanego na rysunku. Następnie, aby utworzyć odpowiednią strukturę w bazie danych należy uruchomić następujące zapytania DDL:
CREATE TABLE Person (
ID INTEGER NOT NULL,
name VARCHAR(100)
) AS NODE;
CREATE TABLE Cafe (
ID INTEGER NOT NULL,
name VARCHAR(100),
) AS NODE;
CREATE TABLE likes (
rating INTEGER
) AS EDGE;
CREATE TABLE friendOf
AS EDGE;
ALTER TABLE likes
ADD CONSTRAINT EC_LIKES CONNECTION (Person TO Cafe);Główną specyfiką takich tabel jest to, że w zapytaniach do nich można używać wzorców grafów o składni podobnej do Cyphera (jednak „*„itp. nie są jeszcze obsługiwane). Na podstawie pomiarów wydajności można również założyć, że sposób przechowywania danych w tych tabelach różni się od sposobu przechowywania danych w zwykłych tabelach i jest zoptymalizowany pod kątem wykonywania takich zapytań grafowych.
SELECT Cafe.name
FROM Person, likes, Cafe
WHERE MATCH (Person-(friendOf)-(likes)->Cafe)
AND Person.name = 'John';Co więcej, dość trudno jest nie używać tych wzorców wykresów podczas pracy z takimi tabelami, ponieważ w zwykłych zapytaniach SQL w celu rozwiązania podobnych problemów konieczne będzie podjęcie dodatkowych wysiłków w celu uzyskania systemowych identyfikatorów węzłów „wykresu” ($node_id, $from_id, $to_id; Z tego samego powodu nie są tu pokazane zapytania o wstawienie danych, gdyż są one niepotrzebnie uciążliwe).
Podsumowując opis implementacji modeli dokumentów i grafów w MS SQL Server, chciałbym zauważyć, że takie implementacje jednego modelu na drugim nie wydają się udane, przede wszystkim z punktu widzenia projektowania języka. Konieczne jest rozszerzenie jednego języka na drugi, języki nie są całkowicie „ortogonalne”, zasady zgodności mogą być dość dziwaczne.
Wielomodelowy system zarządzania bazą danych oparty na modelu dokumentu
W tej sekcji chciałbym zilustrować implementację wielomodelowego systemu DBMS w dokumentach na przykładzie niezbyt popularnego z nich, MongoDB (jak już powiedziano, ma on tylko operatory grafów warunkowych $lookup и $graphLookup, nie pracując nad kolekcjami podzielonymi na fragmenty), ale na przykładzie bardziej dojrzałego i „korporacyjnego” systemu DBMS .
Niech więc kolekcja zawiera zestaw dokumentów XML następującego typu (MarkLogic umożliwia także przechowywanie dokumentów JSON):
<Person INN="631803299804">
<name>John</name>
<surname>Smith</surname>
</Person>Model relacyjny w MarkLogic
Relacyjny widok zbioru dokumentów można utworzyć za pomocą (zawartość pierwiastków value w poniższym przykładzie może występować dowolna ścieżka XPath):
<template >
<context>/Person</context>
<rows>
<row>
<view-name>Person</view-name>
<columns>
<column>
<name>SSN</name>
<value>@SSN</value>
<type>string</type>
</column>
<column>
<name>name</name>
<value>name</value>
</column>
<column>
<name>surname</name>
<value>surname</value>
</column>
</columns>
</row>
<rows>
</template>Do utworzonego widoku możesz zaadresować zapytaniem SQL (na przykład poprzez ODBC):
SELECT name, surname FROM Person WHERE name="John"Niestety widok relacyjny utworzony przez szablon wyświetlania jest tylko do odczytu. Podczas przetwarzania żądania MarkLogic spróbuje go użyć . Wcześniej MarkLogic miał całkowicie ograniczone widoki relacyjne i zapisywalne, ale obecnie są uważane za przestarzałe.
Model wykresu w MarkLogic
Dzięki obsłudze modelu grafowego (RDF) wszystko wygląda mniej więcej tak samo. Znów z pomocą możesz utworzyć reprezentację RDF zbioru dokumentów z powyższego przykładu:
<template >
<context>/Person</context>
<vars>
<var>
<name>PREFIX</name>
<val>"http://example.org/example#"</val>
</var>
</vars>
<triples>
<triple>
<subject><value>sem:iri( $PREFIX || @SSN )</value></subject>
<predicate><value>sem:iri( $PREFIX || surname )</value></predicate>
<object><value>xs:string( surname )</value></object>
</triple>
<triple>
<subject><value>sem:iri( $PREFIX || @SSN )</value></subject>
<predicate><value>sem:iri( $PREFIX || name )</value></predicate>
<object><value>xs:string( name )</value></object>
</triple>
</triples>
</template>Możesz zaadresować wynikowy wykres RDF za pomocą zapytania SPARQL:
PREFIX : <http://example.org/example#>
SELECT ?name ?surname {
:631803299804 :name ?name ; :surname ?surname .
}W przeciwieństwie do modelu relacyjnego MarkLogic obsługuje model grafowy na dwa inne sposoby:
- DBMS może być pełnoprawnym, oddzielnym magazynem danych RDF (w nim zawarte będą trójki w przeciwieństwie do opisanych powyżej ).
- RDF w specjalnej serializacji można po prostu wstawić do dokumentów XML lub JSON (następnie zostaną wywołane trójki ). Jest to prawdopodobnie alternatywa dla mechanizmów
idrefitd.
Dobry pomysł na to, jak „naprawdę” wszystko działa w MarkLogic, daje w tym sensie jest niskopoziomowy, chociaż jego cel jest raczej odwrotny - próba abstrakcji od stosowanego modelu danych, zapewnienie spójnej pracy z danymi w różnych modelach, transakcyjność itp.
Wielomodelowy DBMS „bez modelu głównego”
Na rynku dostępne są również systemy DBMS, które początkowo pozycjonują się jako wielomodelowe, bez żadnego odziedziczonego modelu głównego. Obejmują one , (od 2018 roku firma deweloperska należy do SAP) oraz (usługa w ramach platformy chmurowej Microsoft Azure).
W rzeczywistości w ArangoDB i OrientDB istnieją „podstawowe” modele. W obu przypadkach są to własne modele danych, będące uogólnieniami modelu dokumentowego. Uogólnienia mają przede wszystkim ułatwić możliwość wykonywania zapytań o charakterze grafowym i relacyjnym.
Modele te są jedynymi dostępnymi do użycia w określonym systemie DBMS; ich własne języki zapytań są zaprojektowane do współpracy z nimi. Oczywiście takie modele i SZBD są obiecujące, jednak brak kompatybilności ze standardowymi modelami i językami uniemożliwia wykorzystanie tych SZBD w starszych systemach – w celu zastąpienia już tam używanych SZBD.
Był już wspaniały artykuł o ArangoDB i OrientDB na Habré: .
ArangoDB
ArangoDB twierdzi, że obsługuje grafowy model danych.
Węzły wykresu w ArangoDB to zwykłe dokumenty, a krawędzie to dokumenty specjalnego typu, które wraz ze zwykłymi polami systemowymi mają (_key, _id, _rev) pola systemowe _from и _to. Dokumenty w dokumentach DBMS są tradycyjnie łączone w zbiory. Kolekcje dokumentów reprezentujących krawędzie nazywane są w ArangoDB kolekcjami krawędzi. Nawiasem mówiąc, dokumenty kolekcji Edge są również dokumentami, więc krawędzie w ArangoDB mogą również działać jako węzły.
Surowe dane
Stwórzmy kolekcję persons, którego dokumenty wyglądają tak:
[
{
"_id" : "people/alice" ,
"_key" : "alice" ,
"name" : "Алиса"
},
{
"_id" : "people/bob" ,
"_key" : "bob" ,
"name" : "Боб"
}
]Niech też będzie zbiórka cafes:
[
{
"_id" : "cafes/jd" ,
"_key" : "jd" ,
"name" : "Джон Донн"
},
{
"_id" : "cafes/jj" ,
"_key" : "jj" ,
"name" : "Жан-Жак"
}
]Potem zbiór likes może wyglądać tak:
[
{
"_id" : "likes/1" ,
"_key" : "1" ,
"_from" : "persons/alice" ,
"_to" : "cafes/jd",
"since" : 2010
},
{
"_id" : "likes/2" ,
"_key" : "2" ,
"_from" : "persons/alice" ,
"_to" : "cafes/jj",
"since" : 2011
} ,
{
"_id" : "likes/3" ,
"_key" : "3" ,
"_from" : "persons/bob" ,
"_to" : "cafes/jd",
"since" : 2012
}
]Zapytania i wyniki
Zapytanie w stylu wykresu w języku AQL używanym w ArangoDB, zwracające w czytelnej dla człowieka formie informację o tym, kto lubi którą kawiarnię, wygląda następująco:
FOR p IN persons
FOR c IN OUTBOUND p likes
RETURN { person : p.name , likes : c.name }W stylu relacyjnym, w którym „obliczamy” relacje, a nie je przechowujemy, zapytanie to można przepisać w ten sposób (nawiasem mówiąc, bez kolekcji likes mógłby obejść się bez):
FOR p IN persons
FOR l IN likes
FILTER p._key == l._from
FOR c IN cafes
FILTER l._to == c._key
RETURN { person : p.name , likes : c.name }Wynik w obu przypadkach będzie taki sam:
[
{ "person" : "Алиса" , likes : "Жан-Жак" } ,
{ "person" : "Алиса" , likes : "Джон Донн" } ,
{ "person" : "Боб" , likes : "Джон Донн" }
]Więcej zapytań i wyników
Jeśli powyższy format wyniku wydaje się bardziej typowy dla relacyjnego DBMS niż dla dokumentowego DBMS, możesz wypróbować to zapytanie (lub możesz użyć ):
FOR p IN persons
RETURN {
person : p.name,
likes : (
FOR c IN OUTBOUND p likes
RETURN c.name
)
}Wynik będzie wyglądał następująco:
[
{ "person" : "Алиса" , likes : ["Жан-Жак" , "Джон Донн"] } ,
{ "person" : "Боб" , likes : ["Джон Донн"] }
]OrientDB
Podstawą implementacji modelu wykresu na modelu dokumentu w OrientDB jest Pola dokumentu oprócz mniej lub bardziej standardowych wartości skalarnych posiadają także wartości typów takich jak LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. Wartościami tego typu są linki lub zbiory linków do dokumenty.
Identyfikator dokumentu nadawany przez system ma „znaczenie fizyczne”, wskazujące pozycję rekordu w bazie i wygląda mniej więcej tak: @rid : #3:16. Zatem wartości właściwości referencyjnych są tak naprawdę wskaźnikami (jak w modelu grafowym), a nie warunkami selekcji (jak w modelu relacyjnym).
Podobnie jak ArangoDB, krawędzie w OrientDB są reprezentowane jako osobne dokumenty (chociaż jeśli krawędź nie ma własnych właściwości, można ją utworzyć i nie będzie stanowić odrębnego dokumentu).
Surowe dane
W formacie zbliżonym do OrientDB, dane z poprzedniego przykładu dla ArangoDB będą wyglądać mniej więcej tak:
[
{
"@type": "document",
"@rid": "#11:0",
"@class": "Person",
"name": "Алиса",
"out_likes": [
"#30:1",
"#30:2"
],
"@fieldTypes": "out_likes=LINKBAG"
},
{
"@type": "document",
"@rid": "#12:0",
"@class": "Person",
"name": "Боб",
"out_likes": [
"#30:3"
],
"@fieldTypes": "out_likes=LINKBAG"
},
{
"@type": "document",
"@rid": "#21:0",
"@class": "Cafe",
"name": "Жан-Жак",
"in_likes": [
"#30:2",
"#30:3"
],
"@fieldTypes": "in_likes=LINKBAG"
},
{
"@type": "document",
"@rid": "#22:0",
"@class": "Cafe",
"name": "Джон Донн",
"in_likes": [
"#30:1"
],
"@fieldTypes": "in_likes=LINKBAG"
},
{
"@type": "document",
"@rid": "#30:1",
"@class": "likes",
"in": "#22:0",
"out": "#11:0",
"since": 1262286000000,
"@fieldTypes": "in=LINK,out=LINK,since=date"
},
{
"@type": "document",
"@rid": "#30:2",
"@class": "likes",
"in": "#21:0",
"out": "#11:0",
"since": 1293822000000,
"@fieldTypes": "in=LINK,out=LINK,since=date"
},
{
"@type": "document",
"@rid": "#30:3",
"@class": "likes",
"in": "#21:0",
"out": "#12:0",
"since": 1325354400000,
"@fieldTypes": "in=LINK,out=LINK,since=date"
}
]Jak widzimy, wierzchołki przechowują także informacje o krawędziach przychodzących i wychodzących. Na Interfejs API dokumentów musi sam monitorować integralność referencyjną, a interfejs Graph API przejmuje tę pracę. Zobaczmy jednak, jak wygląda dostęp do OrientDB w „czystych” językach zapytań, które nie są zintegrowane z językami programowania.
Zapytania i wyniki
Zapytanie podobne w celu do zapytania z przykładu dla ArangoDB w OrientDB wygląda następująco:
SELECT name AS person_name, OUT('likes').name AS cafe_name
FROM Person
UNWIND cafe_nameWynik zostanie uzyskany w następującej formie:
[
{ "person_name": "Алиса", "cafe_name": "Джон Донн" },
{ "person_name": "Алиса", "cafe_name": "Жан-Жак" },
{ "person_name": "Боб", "cafe_name": "Жан-Жак" }
]Jeśli format wyniku znów wydaje się zbyt „relacyjny”, musisz usunąć linię z :
[
{ "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
{ "person_name": "Боб", "cafe_name": [ "Жан-Жак" ' }
]Język zapytań OrientDB można opisać jako SQL ze wstawkami przypominającymi gremlin. W wersji 2.2 pojawił się formularz żądania podobny do Cyphera, :
MATCH {CLASS: Person, AS: person}-likes->{CLASS: Cafe, AS: cafe}
RETURN person.name AS person_name, LIST(cafe.name) AS cafe_name
GROUP BY person_nameFormat wyniku będzie taki sam jak w poprzednim żądaniu. Zastanów się, co należy usunąć, aby było bardziej „relacyjne”, jak w pierwszym zapytaniu.
Azure CosmosDB
W mniejszym stopniu to, co powiedziano powyżej o ArangoDB i OrientDB, dotyczy Azure CosmosDB. CosmosDB udostępnia następujące interfejsy API dostępu do danych: SQL, MongoDB, Gremlin i Cassandra.
Do dostępu do danych w modelu dokumentu wykorzystywane są interfejsy SQL API i MongoDB API. Gremlin API i Cassandra API - do dostępu do danych odpowiednio w formacie wykresu i kolumny. Dane we wszystkich modelach są zapisywane w formacie modelu wewnętrznego CosmosDB: („sekwencja-rekordu atomu”), która również jest zbliżona do sekwencji dokumentu.
Natomiast wybrany przez użytkownika model danych i wykorzystywane API są ustalane w momencie zakładania konta w serwisie. Nie ma możliwości dostępu do danych załadowanych w jednym modelu w formacie innego modelu, co ilustruje coś takiego:
Tym samym multimodelowość w Azure CosmosDB to dziś jedynie możliwość korzystania z kilku baz danych obsługujących różne modele jednego producenta, co nie rozwiązuje wszystkich problemów wielowariantowego przechowywania danych.
Wielomodelowy system DBMS oparty na modelu grafowym?
Na uwagę zasługuje fakt, że na rynku nie ma jeszcze wielomodelowych SZBD bazujących na modelu grafowym (poza wielomodelową obsługą jednocześnie dwóch modeli grafowych: RDF i LPG; zobacz o tym w ). Największe trudności sprawia implementacja modelu dokumentu na modelu grafowym, a nie relacyjnym.
Pytanie, jak zaimplementować model relacyjny na wierzchu modelu grafowego, było rozważane już podczas tworzenia tego ostatniego. Jak , Na przykład, :
W podejściu grafowym nie ma nic, co stoi na przeszkodzie utworzeniu warstwy (np. poprzez odpowiednie indeksowanie) w grafowej bazie danych, która umożliwia widok relacyjny z (1) odzyskiwaniem krotek ze zwykłych par klucz-wartość i (2) grupowaniem krotki według typu relacji.
Implementując model dokumentu na podstawie modelu wykresu, należy pamiętać na przykład o następujących kwestiach:
- Elementy tablicy JSON są uważane za uporządkowane, ale te, które wychodzą z wierzchołka krawędzi grafu, nie są takie;
- Dane w modelu dokumentu są zwykle zdenormalizowane, nadal nie chcesz przechowywać kilku kopii tego samego osadzonego dokumentu, a dokumenty podrzędne zwykle nie mają identyfikatorów;
- Z drugiej strony ideologia DBMS dokumentów polega na tym, że dokumenty są gotowymi „agregatami”, których nie trzeba budować za każdym razem od nowa. Wymagane jest zapewnienie modelowi grafowemu możliwości szybkiego uzyskania podgrafu odpowiadającego gotowemu dokumentowi.
Niektóre reklamy
Autor artykułu związany jest z rozwojem systemu NitrosBase DBMS, którego modelem wewnętrznym jest graf, natomiast modele zewnętrzne – relacyjny i dokumentowy – są jego reprezentacjami. Wszystkie modele są równe: w każdym z nich dostępne są prawie wszystkie dane przy użyciu naturalnego dla niego języka zapytań. Co więcej, w dowolnym widoku dane można zmienić. Zmiany zostaną odzwierciedlone w modelu wewnętrznym i odpowiednio w innych widokach.
Mam nadzieję, że opiszę jak wygląda dopasowywanie modeli w NitrosBase w którymś z kolejnych artykułów.
wniosek
Mam nadzieję, że ogólne zarysy tzw. multimodelingu stały się mniej więcej jasne dla czytelnika. Wielomodelowe systemy DBMS są zupełnie inne, a „obsługa wielu modeli” może wyglądać inaczej. Aby zrozumieć, co w każdym konkretnym przypadku nazywa się „wielomodelowym”, warto odpowiedzieć na następujące pytania:
- Czy mówimy o wspieraniu modeli tradycyjnych, czy o jakimś modelu „hybrydowym”?
- Czy modele są „równe”, czy też jeden z nich jest przedmiotem pozostałych?
- Czy modelki są wobec siebie „obojętne”? Czy dane zapisane w jednym modelu można odczytać w innym lub nawet nadpisać?
Myślę, że na pytanie o znaczenie wielomodelowego DBMS można już odpowiedzieć pozytywnie, ale interesujące jest pytanie, które typy z nich będą bardziej poszukiwane w najbliższej przyszłości. Wydaje się, że większe zapotrzebowanie będzie na wielomodelowe SZBD obsługujące modele tradycyjne, przede wszystkim relacyjne; Popularność wielomodelowych SZBD, oferujących nowe modele, łączące w sobie zalety różnych tradycyjnych, jest kwestią bardziej odległej przyszłości.
W ankiecie mogą brać udział tylko zarejestrowani użytkownicy. , Proszę.
Czy korzystasz z wielomodelowego systemu DBMS?
-
Nie używamy tego, przechowujemy wszystko w jednym DBMS i w jednym modelu
-
Wykorzystujemy wielomodelowe możliwości tradycyjnych systemów DBMS
-
Ćwiczymy wytrwałość poligloty
-
Korzystamy z nowego, wielomodelowego systemu DBMS (Arango, Orient, CosmosDB)
Głosowało 19 użytkowników. 4 użytkowników wstrzymało się od głosu.
Źródło: www.habr.com