Nowoczesne systemy informacyjne są dość skomplikowane. Ich złożoność wynika w dużej mierze z różnorodności przetwarzanych danych. Złożoność danych często polega na różnorodności stosowanych modeli danych. Na przykład, gdy dane stają się „duże”, jedną z uciążliwych cech ich charakterystyki jest nie tylko ich objętość („volume”), ale także różnorodność („variety”).

Jeśli jak na razie nie znajdujesz błędów w rozważaniach, to czytaj dalej.

Spis treści

Polyglot persistence
Wielomodelowość
Wielomodelowe DBMS oparte na modelu relacyjnym
     Model dokumentowy w MS SQL Server
     Model grafowy w MS SQL Server
Wielomodelowe DBMS oparte na modelu dokumentowym
     Model relacyjny w MarkLogic
     Model grafowy w MarkLogic
Wielomodelowe DBMS „bez głównego modelu”
     ArangoDB
     OrientDB
     Azure CosmosDB
Wielomodelowe DBMS oparte na modelu grafowym?
Podsumowanie
Ankieta

Polyglot persistence

Powyższe prowadzi do sytuacji, w której w ramach jednej systemu czasami należy stosować kilka różnych DBMS do przechowywania danych i rozwiązywania różnych zadań związanych z ich przetwarzaniem, z których każdy wspiera swój model danych. Dzięki M. Fowlerowi, autora wielu znanym książkom i jednemu z współautorów Manifestu Agile, taka sytuacja zyskała nazwę wielowariantowego przechowywania („polyglot persistence”).

Fowler dostarcza również przykład organizacji przechowywania danych w pełnofunkcjonalnej i wysokoobciążonej aplikacji w dziedzinie e-commerce.

Ten przykład jest oczywiście nieco przerysowany, ale można znaleźć niektóre argumenty na rzecz wyboru danego DBMS do konkretnego celu, na przykład, tutaj.

Jasne jest, że bycie pracownikiem w takim zoo nie jest łatwe.

Wielkość kodu odpowiedzialnego za zapis danych rośnie proporcjonalnie do liczby używanych DBMS; wielkość kodu synchronizującego dane — o ile dobrze, to nie proporcjonalnie do kwadratu tej liczby.
Wydatki na zapewnienie cech enterprise (skalowalność, odporność na awarie, wysoka dostępność) każdej z używanych DBMS rosną w proporcji do liczby używanych DBMS.
Nie można zapewnić cech enterprise całego subsystemu przechowywania — szczególnie transakcyjności.

Z perspektywy dyrektora zoo sytuacja wygląda następująco:

Wielokrotne zwiększenie kosztów licencji i wsparcia technicznego od producenta DBMS.
Rozrost zespołu i wydłużenie terminów.
Bezpośrednie straty finansowe lub kary za niespójność danych.

Występuje znaczny wzrost całkowitego kosztu posiadania systemu (TCO). Czy istnieje jakieś wyjście z sytuacji «wielowariantowego przechowywania»?

Wielomodelowość

Termin «wielowariantowe przechowywanie» wszedł do użytku w 2011 roku. Uświadomienie sobie problemów podejścia i szukanie rozwiązania zajęło kilka lat, a do 2015 roku ustami analityków Gartnera odpowiedź została sformułowana:

Z «Market Guide for NoSQL DBMSs — 2015»:
Przyszłość systemów DBMS, ich architektur i sposobów użycia — multimodalność.
Z «Magic Quadrant for ODBMS — 2016»:
Wiodące operacyjne systemy DBMS będą oferować kilka modeli — relacyjny i nierelacyjne — w ramach jednej platformy.

Wygląda na to, że tym razem analitycy Gartnera się nie pomylili. Jeśli przejdziesz na stronę z głównym rankingiem systemów DBMS na DB-Engines, można zauważyć, że większość jego liderów pozycjonuje się jako multimodalne systemy DBMS. To samo można zauważyć na stronie z każdym prywatnym rankingiem.większąW poniższej tabeli przedstawiono wiodące systemy DBMS w każdym z prywatnych rankingów, które deklarują swoją multimodalność. Dla każdego systemu DBMS podano początkowy obsługiwany model (który kiedyś był jedynym) oraz inne modele, które są wspierane obecnie. Przedstawiono również systemy DBMS, które pozycjonują się jako „z natury multimodalne”, nie mające według twórców żadnego początkowego dziedziczonego modelu.

Początkowy model

DBMS	Modele dodatkowe	Relacyjny
Oracle	Grafowy, dokumentowy	Grafowy*, dokumentowy
MS SQL	Grafowy, dokumentowy	Grafowy*, dokumentowy
PostgreSQL	Grafowy, dokumentowy	MarkLogic
Dokumentowy	Grafowy, relacyjny	Klucz-wartość, grafowy*
MongoDB	Grafowy, relacyjny	DataStax
Wide-column	Dokumentowy, grafowy	Klucz-wartość
Redis	Dokumentowy, grafowy*	Grafowy, dokumentowy, relacyjny
ArangoDB	—	Grafowy*, dokumentowy
OrientDB	—	Uwagi do tabeli
Azure CosmosDB	—	Uwagi do tabeli

Gwiazdkami w tabeli oznaczono stwierdzenia wymagające zastrzeżeń:

System DBMS PostgreSQL nie obsługuje modelu grafowego, ale obsługiwany jest przez taki produkt

na jego podstawie , jak na przykład AgensGraph.W odniesieniu do MongoDB bardziej właściwe jest mówienie o obecności operatorów grafowych w języku zapytań (
$lookup$graphLookup, ), niż o wsparciu modelu grafowego, chociaż ich wprowadzenie wymagało pewnych optymalizacji na poziomie fizycznego przechowywania w kierunku wsparcia modelu grafowego.), co do wsparcia modelu grafowego, chociaż ich wprowadzenie wymagało pewnych optymalizacji na poziomie fizycznego przechowywania w kierunku wsparcia modelu grafowego.
W odniesieniu do Redis odnosi się to do rozszerzenia RedisGraph.

Dalej przedstawimy dla każdej klasy, jak realizowane jest wsparcie dla kilku modeli w DBMS tej klasy. Najważniejsze modele, które weźmiemy pod uwagę, to model relacyjny, dokumentowy i grafowy, a na przykładach konkretnych DBMS pokażemy, jak realizowane są 'braki'.

Wielomodelowe DBMS oparte na modelu relacyjnym

Wiodącymi DBMS w tej chwili są DBMS relacyjne, prognoza Gartnera nie mogłaby być uznana za zrealizowaną, gdyby RDBMS nie wykazywały ruchów w kierunku multimodalności. A one to pokazują. Teraz rozważania o tym, że multimodalny DBMS jest jak scyzoryk szwajcarski, którym nic nie można zrobić dobrze, można skierować bezpośrednio do Larry'ego Ellisona.

Autorowi jednak bardziej podoba się realizacja multimodalności w Microsoft SQL Server, na przykładzie którego opisane będzie wsparcie RDBMS dla modeli dokumentowych i grafowych.

Model dokumentowy w MS SQL Server

Jak w MS SQL Server zrealizowane jest wsparcie dla modelu dokumentowego, na Habrze już były dwa doskonałe artykuły, ograniczę się do krótkiego streszczenia i komentarza:

Sposób wsparcia modelu dokumentowego w MS SQL Server jest dość typowy dla relacyjnych DBMS: dokumenty JSON proponuje się przechowywać w zwykłych polach tekstowych. Wsparcie modelu dokumentowego polega na udostępnieniu specjalnych operatorów do analizy tego JSON:

JSON_VALUE do wyodrębniania skalarnych wartości atrybutów,
JSON_QUERY do wyodrębniania poddokumentów.

Drugim argumentem obu operatorów jest wyrażenie w składni podobnej do JSONPath.

Abstrakcyjnie można powiedzieć, że przechowywane w ten sposób dokumenty nie są w relacyjnej DBMS „pierwszej klasy”, w przeciwieństwie do krotek. Konkretnie w MS SQL Server w tej chwili brakuje indeksów dla pól dokumentów JSON, co utrudnia operacje łączenia tabel według wartości tych pól, a nawet pobieranie dokumentów według tych wartości. Niemniej jednak można utworzyć dla takiego pola obliczalną kolumnę i indeks na nim.

Dodatkowo MS SQL Server oferuje możliwość wygodnego konstruowania dokumentu JSON z zawartości tabel przy użyciu operatora FOR JSON PATH — możliwość, w pewnym sensie przeciwną do zwykłego przechowywania. Oczywiście, niezależnie od tego, jak szybka jest RDBMS, takie podejście stoi w sprzeczności z ideologią dokumentowych baz danych, które w zasadzie przechowują gotowe odpowiedzi na popularne zapytania; może to rozwiązywać jedynie problemy wygody rozwoju, ale nie wydajności.

Wreszcie, MS SQL Server umożliwia rozwiązanie zadania odwrotnego do konstruowania dokumentu: można rozłożyć JSON na tabele za pomocą OPENJSON. Jeśli dokument nie jest całkiem płaski, będzie konieczne użycie CROSS APPLY.

Model grafowy w MS SQL Server

Wsparcie dla modelu grafowego (LPG) jest również w Microsoft SQL Server zapewnione w sposób przewidywalny: proponowane jest użycie specjalnych tabel do przechowywania węzłów i krawędzi grafu. Takie tabele tworzy się za pomocą wyrażeń CREATE TABLE AS NODE i CREATE TABLE AS EDGE odpowiednio.

Tabela pierwszego rodzaju jest podobna do zwykłych tabel przechowujących rekordy, z tą jedyną różnicą, że w tabeli znajduje się pole systemowe $node_id — unikalny w obrębie bazy danych identyfikator węzła grafu.

Podobnie, tabele drugiego rodzaju mają pola systemowe $from_id i $to_id, a zapisy w takich tabelach jasno określają relacje między węzłami. Do przechowywania relacji każdego rodzaju używana jest osobna tabela.

Ilustrujmy to przykładem. Niech dane grafowe mają schemat jak na przedstawionym rysunku. Aby stworzyć odpowiadającą strukturę w bazie danych, należy wykonać 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łówna specyfika tych tabel polega na tym, że w zapytaniach do nich można używać wzorów grafowych z iście składnią przypominającą Cypher (zresztą, „*” etc. na razie nie są wspierane). Na podstawie pomiarów wydajności można również przypuszczać, że sposób przechowywania danych w tych tabelach różni się od mechanizmu przechowywania danych w zwykłych tabelach i jest zoptymalizowany do 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 pracować z takimi tabelami i nie używać tych wzorców grafowych, ponieważ w zwykłych zapytaniach SQL, aby rozwiązać podobne problemy, konieczne będzie podjęcie dodatkowych wysiłków w celu uzyskania systemowych „grafowych” identyfikatorów węzłów ($node_id, $from_id, $to_id; z tego samego powodu zapytania dotyczące wstawiania danych nie zostały tutaj przedstawione jako zbyt rozbudowane).

Podsumowując opis implementacji modeli dokumentów i grafów w MS SQL Server, chciałbym zaznaczyć, że podobne implementacje jednego modelu na drugim nie wydają się udane przede wszystkim z punktu widzenia projektowania języka. Należy rozszerzać jeden język drugim, języki nie są całkowicie „ortogonalne”, zasady kombinacji mogą być dość dziwaczne.

Wielomodelowe DBMS oparte na modelu dokumentowym

W tej sekcji chciałbym zilustrować realizację multimodelowości w dokumentowych DBMS na przykładzie mniej popularnego z nich, MongoDB (jak wspomniano, zawiera ona jedynie warunkowe operatory grafowe, $graphLookup i ), niż o wsparciu modelu grafowego, chociaż ich wprowadzenie wymagało pewnych optymalizacji na poziomie fizycznego przechowywania w kierunku wsparcia modelu grafowego., które nie działają na partycjonowanych kolekcjach), zastępując je bardziej dojrzałym i 'enterprise' DBMS. Dokumentowy.

Załóżmy więc, że kolekcja zawiera zestaw dokumentów XML w następującym formacie (MarkLogic również pozwala na przechowywanie dokumentów JSON):

John
  Smith

Model relacyjny w MarkLogic

Relacyjne przedstawienie kolekcji dokumentów można stworzyć za pomocą szablonu mapowania (zawartość elementów value w poniższym przykładzie może być dowolnym XPath):

/Person
  
    
      Person
      
        
          SSN
          @SSN
          string
        
        
          name
          name
        
        
          surname
          surname

Do utworzonego przedstawienia można odwołać się w zapytaniu SQL (na przykład przez ODBC):

SELECT name, surname FROM Person WHERE name="John"

Niestety, relacyjne przedstawienie utworzone za pomocą szablonu mapowania jest dostępne tylko do odczytu. Podczas przetwarzania zapytania do niego MarkLogic spróbuje użyć indeksów dokumentów. Wcześniej w MarkLogic istniały również ograniczone relacyjne przedstawienia, które były w pełni oparte na indeksach i dostępne do zapisu, ale obecnie uważane są za przestarzałe.

Model grafowy w MarkLogic

Z obsługą modelu grafowego (RDF) sytuacja wygląda podobnie. Ponownie za pomocą szablonu mapowania można stworzyć RDF-reprezentację kolekcji dokumentów z powyższego przykładu:

/Person
    
      
        PREFIX
        "http://example.org/example#"
      
    
  
    
      sem:iri( $PREFIX || @SSN )
      sem:iri( $PREFIX || surname )
      
    
    
      sem:iri( $PREFIX || @SSN )
      sem:iri( $PREFIX || name )

Do uzyskanego grafu RDF można skierować zapytanie SPARQL:

PREFIX : 
SELECT ?name ?surname {
  :631803299804 :name ?name ; :surname ?surname .
}

W przeciwieństwie do modelu relacyjnego, model grafowy MarkLogic obsługuje również na dwa inne sposoby:

DBMS może być w pełni funkcjonalnym, odrębnym magazynem danych RDF (potrójki będą nazywane managed w przeciwieństwie do powyżej opisanych extracted).
RDF w specjalnej serializacji może być po prostu wstawiony do dokumentów XML lub JSON (a wtedy potrójki będą zwane unmanaged). Prawdopodobnie jest to alternatywa dla mechanizmów idref i tym podobnych.

Dobre zrozumienie tego, jak „naprawdę” wszystko działa w MarkLogic, daje Optic API, w tym sensie jest to niskopoziomowe, chociaż jego przeznaczenie jest raczej odwrotne — spróbować abstrahować od używanego modelu danych, zapewniając spójną pracę z danymi w różnych modelach, transakcyjność itp.

Wielomodelowe DBMS „bez głównego modelu”

Na rynku są również dostępne DBMS, które pozycjonują się jako pierwotnie multimodelowe, nie mające żadnego dziedziczonego modelu głównego. Do ich liczby należą ArangoDB, OrientDB (od 2018 roku firma-deweloper należy do SAP) oraz CosmosDB (usługa w ramach chmurowej platformy Microsoft Azure).

W rzeczywistości „podstawowe” modele w ArangoDB i OrientDB istnieją. W każdym z tych przypadków są to własne modele danych, będące uogólnieniami dokumentowym. Uogólnienia polegają głównie na uproszczeniu możliwości przeprowadzania zapytań grafowych i relacyjnych.

Te modele są jedynymi dostępnymi do użycia w wskazanych systemach baz danych, a do pracy z nimi przeznaczone są specjalne języki zapytań. Oczywiście, te modele i systemy baz danych mają potencjał, jednak brak kompatybilności ze standardowymi modelami i językami uniemożliwia ich zastosowanie w systemach dziedziczonych – nie można ich używać jako zamienników dla już istniejących systemów baz danych.

Na temat ArangoDB i OrientDB na Habrze już była znakomita artykuł: JOIN w bazach danych NoSQL.

ArangoDB

ArangoDB ogłasza wsparcie dla modelu danych grafowych.

Węzły grafu w ArangoDB to zwykłe dokumenty, a krawędzie to dokumenty specjalnego typu, posiadające obok zwykłych pól systemowych (_key, _id, _rev) pola systemowe _from i _to. Dokumenty w dokumentowych systemach baz danych tradycyjnie grupowane są w kolekcje. Kolekcje dokumentów przedstawiających krawędzie w ArangoDB nazywane są kolekcjami krawędzi. Warto dodać, że dokumenty kolekcji krawędzi również są dokumentami, dlatego krawędzie w ArangoDB mogą też pełnić rolę węzłów.

Dane źródłowe

Załóżmy, że mamy kolekcję persons, której dokumenty wyglądają następująco:

[
  {
    "_id"  : "people\/alice" ,
    "_key" : "alice" ,
    "name" : "Alicja"
  },
  {
    "_id"  : "people\/bob" ,
    "_key" : "bob" ,
    "name" : "Bob"  
  }
]

Załóżmy także, że istnieje kolekcja cafes:

[
  {
    "_id" : "cafes\/jd" ,
    "_key" : "jd" ,
    "name" : "John Donne"  
  },
  {
    "_id" : "cafes\/jj" ,
    "_key" : "jj" ,
    "name" : "Jean-Jacques"
  }
]

W takim razie kolekcja likes może wyglądać następująco:

[
  {
    "_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 grafowym w używanym w ArangoDB języku AQL, które zwraca w zrozumiałej formie informacje o tym, które kawiarnie lubią poszczególne osoby, 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, kiedy raczej "obliczamy" związki, a nie je przechowujemy, to zapytanie można przepisać w ten sposób (przy okazji, bez kolekcji likes można by było się obejść):

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" : "Alicja" , likes : "Jean-Jacques" } ,
  { "person" : "Alicja" , likes : "John Donne" } ,
  { "person" : "Bob" , likes : "John Donne" }
]

Więcej zapytań i wyników

Jeśli wydaje się, że format wyniku powyżej bardziej odpowiada relacyjnej bazie danych niż dokumentowej, można spróbować takiego zapytania (można też skorzystać z COLLECT):

FOR p IN persons
  RETURN {
    person : p.name,
    likes : (
      FOR c IN OUTBOUND p likes
      RETURN c.name
    )
}

Wynik będzie miał następujący kształt:

[
  { "person" : "Alicja" , likes : ["Jean-Jacques" , "John Donne"]  } ,
  { "person" : "Bob" , likes : ["John Donne"] }
]

OrientDB

Podstawą wdrożenia modelu grafowego na bazie dokumentów w OrientDB jest możliwość posiadanie pól dokumentów oprócz względnie standardowych wartości skalarnych również wartości takich typów jak LINK, LINKLIST, LINKSET, LINKMAP i LINKBAG. Wartości tych typów to linki lub zbiory linków do identyfikatorów systemowych dokumentów.

Przypisywany przez system identyfikator dokumentu ma "fizyczne znaczenie", wskazując pozycję zapisu w bazie i wygląda mniej więcej tak: @rid : #3:16. W ten sposób wartości właściwości odniesień są rzeczywiście bardziej wskaźnikami (jak w modelu grafowym), a nie warunkami selekcji (jak w relacyjnej).

Podobnie jak w ArangoDB, w OrientDB krawędzie są przedstawiane jako osobne dokumenty (choć jeśli krawędź nie ma swoich właściwości, można ją uczynić lekką, i nie będzie odpowiadał jej osobny dokument).

Dane źródłowe

W formacie zbliżonym do formatu zrzutu bazy OrientDB, dane z poprzedniego przykładu dla ArangoDB wyglądałyby mniej więcej tak:

[
     {
      "@type": "document",
      "@rid": "#11:0",
      "@class": "Person",
      "name": "Alicja",
      "out_likes": [
        "#30:1",
        "#30:2"
      ],
      "@fieldTypes": "out_likes=LINKBAG"
    },
    {
      "@type": "document",
      "@rid": "#12:0",
      "@class": "Person",
      "name": "Bob",
      "out_likes": [
        "#30:3"
      ],
      "@fieldTypes": "out_likes=LINKBAG"
    },
    {
      "@type": "document",
      "@rid": "#21:0",
      "@class": "Cafe",
      "name": "Jean-Jacques",
      "in_likes": [
        "#30:2",
        "#30:3"
      ],
      "@fieldTypes": "in_likes=LINKBAG"
    },
    {
      "@type": "document",
      "@rid": "#22:0",
      "@class": "Cafe",
      "name": "John Donne",
      "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 również przechowują informacje o przychodzących i wychodzących krawędziach. Przy użyciu API dokumentów związanych z integralnością odniesień należy monitorować samodzielnie, podczas gdy Graph API przejmuje tę pracę na siebie. Zobaczmy jednak, jak wygląda zapytanie do OrientDB w czystych, niezintegrowanych z językami programowania językach zapytań.

Zapytania i wyniki

Zapytanie, analogiczne 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_name

Wynik zostanie zwrócony w następującej formie:

[
  { "person_name": "Alicja", "cafe_name": "John Donne" },
  { "person_name": "Alicja", "cafe_name": "Jean-Jacques" },
  { "person_name": "Bob",  "cafe_name": "Jean-Jacques" }
]

Jeśli format wyniku wydaje się zbyt „relacyjny”, należy usunąć linię z UNWIND():

[
  { "person_name": "Alicja", "cafe_name": [ "John Donne", "Jean-Jacques" ] },
  { "person_name": "Bob",  "cafe_name": [ "Jean-Jacques" ] }
]

Język zapytań OrientDB można scharakteryzować jako SQL z wstawkami przypominającymi Gremlin. W wersji 2.2 pojawiła się forma zapytania podobna do Cypher, MATCH :

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_name

Format wyniku będzie taki sam, jak w poprzednim zapytaniu. Zastanów się, co należy usunąć, aby był bardziej „relacyjny”, jak w najpierwszym zapytaniu.

Azure CosmosDB

W mniejszym stopniu to, co powiedziano powyżej o ArangoDB i OrientDB, odnosi się do Azure CosmosDB. CosmosDB oferuje następujące API dostępu do danych: SQL, MongoDB, Gremlin i Cassandra.

API SQL i API MongoDB są używane do dostępu do danych w modelu dokumentów. API Gremlin i API Cassandra — do dostępu do danych w odpowiednio modelu grafowym i kolumnowym. Dane we wszystkich modelach są przechowywane w formacie wewnętrznego modelu CosmosDB: ARS („atom-record-sequence”), które jest również bliskie modelowi dokumentów.

Jednak wybrany przez użytkownika model danych oraz używane API są ustalane w momencie zakupu konta w usłudze. Nie można uzyskać dostępu do danych załadowanych w jednym modelu w formacie innego modelu, co można by zobrazować mniej więcej takim rysunkiem:

W ten sposób multimodelowość w Azure CosmosDB obecnie oznacza jedynie możliwość korzystania z kilku baz danych obsługujących różne modele od jednego dostawcy, co nie rozwiązuje wszystkich problemów z wielowariantowym przechowywaniem.

Wielomodelowe DBMS oparte na modelu grafowym?

Zwraca uwagę fakt, że na rynku brakuje na razie multimodelnych DBMS opartych na modelu grafowym (chyba że uznać multimodelowość jako wsparcie jednocześnie dla dwóch modeli grafowych: RDF i LPG; więcej na ten temat w poprzedniej publikacji). Największe trudności sprawia realizacja na modelu grafowym dokumentowym, a nie relacyjnym.

Pytanie, jak zrealizować relacyjną warstwę na modelu grafowym, było poruszane już w czasach wczesnego rozwoju tego drugiego. Jak powiedział, na przykład, David McGovern:

Nie ma nic w podejściu grafowym, co uniemożliwiałoby stworzenie warstwy (np. poprzez odpowiednie indeksowanie) na bazie danych grafowych, która umożliwia widok relacyjny z (1) odzyskiwaniem krotek z tradycyjnych par klucz-wartość oraz (2) grupowaniem krotek według typu relacji.

Podczas realizacji modelu dokumentowego na modelu grafowym należy mieć na uwadze, na przykład, to, że:

Elementy tablicy JSON są uważane za uporządkowane, co wynika z wierzchołka krawędzi grafu — nie;
Dane w modelu dokumentowym są zazwyczaj denormalizowane, nie chcemy przechowywać kilku kopii tego samego zagnieżdżonego dokumentu, a identyfikatorów poddokumentów zazwyczaj nie ma;
Z drugiej strony, ideologia dokumentowych systemów baz danych polega na tym, że dokumenty są gotowymi „agregatami”, które nie muszą być każdorazowo budowane od nowa. W modelu grafowym należy zapewnić możliwość szybkiego uzyskania podgrafu odpowiadającego gotowemu dokumentowi.

Trochę reklamy

Autor artykułu jest związany z rozwojem systemu baz danych NitrosBase, którego wewnętrzny model jest grafowy, a modele zewnętrzne — relacyjny i dokumentowy — stanowią jego reprezentacje. Wszystkie modele są równouprawnione: praktycznie każde dane są dostępne w każdym z nich z użyciem naturalnego dla niej języka zapytań. Co więcej, w każdej reprezentacji dane mogą być zmieniane. Zmiany odzwierciedlają się w modelu wewnętrznym i, odpowiednio, w innych reprezentacjach.

Jak wygląda odpowiedniość modeli w NitrosBase — opiszę, mam nadzieję, w jednym z kolejnych artykułów.

Podsumowanie

Mam nadzieję, że ogólne zarysy tego, co nazywa się multimodalnością, stały się dla czytelnika mniej więcej jasne. Multimodalne nazywane są dość różne systemy baz danych, a „wsparcie dla różnych modeli” może wyglądać różnie. Dla zrozumienia, co oznacza „multimodalność” w każdym konkretnym przypadku, pomocne jest odpowiedzenie na następujące pytania:

Czy mowa o wsparciu tradycyjnych modeli, czy o jakimś jednym „hybrydowym” modelu?
Czy modele są „równouprawnione”, czy jedna z nich jest podporządkowana innym?
Czy modele są sobie obojętne? Czy dane zapisane w jednym modelu mogą być odczytane w innym lub nawet nadpisane?

Myślę, że na pytanie o aktualność multymodelowych baz danych już można udzielić pozytywnej odpowiedzi, ale interesuje mnie, które z ich typów będą bardziej pożądane w najbliższym czasie. Wydaje się, że bardziej poszukiwane będą multymodelowe bazy danych wspierające tradycyjne modele, przede wszystkim relacyjne; natomiast popularność multymodelowych baz danych oferujących nowe modele, które łączą zalety różnych tradycyjnych, to kwestia bardziej odległej przyszłości.

Tylko zarejestrowani użytkownicy mogą brać udział w ankiecie. Zaloguj się, proszę.