Современите информациски системи се доста сложени. Не и најмалку важно, нивната сложеност се должи на сложеноста на податоците обработени во нив. Комплексноста на податоците често лежи во разновидноста на користените модели на податоци. Така, на пример, кога податоците стануваат „големи“, една од проблематичните карактеристики не е само нивниот волумен („волумен“), туку и нивната разновидност („разновидност“).

Ако сè уште не најдовте грешка во расудувањето, тогаш прочитајте.

содржина

Полиглотна упорност
Мулти-модел
Мулти-модел DBMS базиран на релациски модел
     Модел на документ во MS SQL Server
     Графички модел во MS SQL Server
Мулти-модел DBMS врз основа на моделот на документот
     Релациски модел во MarkLogic
     Графички модел во MarkLogic
Мулти-модел DBMS „без главен модел“
     АрангоДБ
     OrientDB
     Azure CosmosDB
Мулти-модел DBMS базиран на графички модел?
Заклучок
Опрос

Полиглотна упорност

Горенаведеното води до фактот дека понекогаш дури и во рамките на еден систем е неопходно да се користат неколку различни DBMS за складирање на податоци и решавање на различни проблеми на нивната обработка, од кои секоја поддржува свој модел на податоци. Со лесната рака на М. Фаулер, авторот голем број познати книги и една од коавтори Агилен манифест, оваа ситуација се вика складирање со повеќе варијанти („Полиглотна упорност“).

Фаулер исто така го има следниов пример за организирање складирање податоци во целосна опремена и оптоварена апликација во областа на е-трговија.

Овој пример, се разбира, е донекаде претеран, но може да се најдат некои размислувања во корист на изборот на еден или друг DBMS за соодветната цел, на пример, тука.

Јасно е дека да се биде слуга во таква зоолошка градина не е лесно.

Количината на код што врши складирање податоци расте пропорционално со бројот на користени DBMS; количината на податоци за синхронизирање на кодот е добра ако не е пропорционална со квадратот на овој број.
Како повеќекратно од бројот на користени DBMS, трошоците за обезбедување карактеристики на претпријатието (приспособливост, толеранција на грешки, висока достапност) на секој од користените DBMS се зголемуваат.
Невозможно е да се обезбедат карактеристиките на претпријатието на потсистемот за складирање како целина - особено трансакционалноста.

Од гледна точка на директорот на зоолошката градина, сè изгледа вака:

Повеќекратно зголемување на цената на лиценците и техничката поддршка од производителот на DBMS.
Превработеност и зголемени рокови.
Директни финансиски загуби или казни поради недоследност на податоците.

Има значително зголемување на вкупните трошоци за сопственост на системот (TCO). Дали има некој излез од ситуацијата на „повеќе опции за складирање“?

Мулти-модел

Терминот „мултиваријатно складирање“ влезе во употреба во 2011 година. Свесноста за проблемите на пристапот и барањето решение траеше неколку години, а до 2015 година, преку устата на аналитичарите на Гартнер, беше формулиран одговорот:

од "Пазарен водич за NoSQL DBMS - 2015 година"

Иднината на DBMS, нивните архитектури и начини на нивно користење е мулти-модел.
од "Магичен квадрант за ODBMS - 2016 година"

Водечките оперативни DBMS ќе понудат повеќе модели - релациски и нерелациски - како дел од една платформа.

Се чини дека овој пат аналитичарите на Гартнер беа во право со својата прогноза. Ако одите на страницата со главен рејтинг DBMS на DB-Engines, можете да го видите тоаоПовеќето од неговите лидери се позиционираат конкретно како мулти-модел DBMS. Истото може да се види на страницата со која било приватна оцена.

Табелата подолу ги прикажува DBMS - лидерите во секоја од приватните рејтинзи, кои тврдат дека се мулти-модел. За секој DBMS е наведен оригиналниот поддржан модел (кој некогаш беше единствениот) и заедно со него моделите што моментално се поддржани. Наведени се и DBMS кои се позиционираат како „оригинално мулти-модел“ и, според креаторите, немаат почетен наследен модел.

ДБМС	Почетен модел	Дополнителни модели
Oracle	Релациски	Графикон, документ
MS SQL	Релациски	Графикон, документ
PostgreSQL	Релациски	Графикон*, документ
MarkLogic	Документарец	Графикон, релациски
MongoDB	Документарец	Клуч-вредност, графикон*
DataStax	Широка колона	Документарен филм, графикон
Redis	Клуч-вредност	документарен филм, графикон*
АрангоДБ	-	Графикон, документ
OrientDB	-	Графикон, документ, релациски
Azure CosmosDB	-	Графикон, документ, релациски

Белешки на масата

Ѕвездичките во табелата означуваат изјави за кои е потребна резервација:

PostgreSQL DBMS не го поддржува моделот на податоци со графикони, но овој производ го поддржува врз основа на тоа, како што е AgensGraph.
Во однос на MongoDB, поправилно е да се зборува за присуство на графски оператори во јазикот за пребарување ($lookup, $graphLookup) отколку за поддршка на моделот на графиконот, иако, се разбира, нивното воведување бараше одредени оптимизации на ниво на физичко складирање во насока на поддршка на моделот на графикот.
Во однос на Редис мислиме на екстензијата RedisGraph.

Следно, за секоја од класите, ќе покажеме како поддршката за неколку модели се имплементира во DBMS од оваа класа. Ќе ги сметаме релациските, моделите на документи и графикони како најважни и ќе користиме примери на специфични DBMS за да покажеме како се имплементираат „оние што недостасуваат“.

Мулти-модел DBMS базиран на релациски модел

Водечките DBMS во моментов се релациски; прогнозата на Гартнер не може да се смета за вистинита ако RDBMS не покажат движење во насока на мулти-моделирање. И демонстрираат. Сега идејата дека мулти-модел DBMS е како швајцарски нож, кој не може да направи ништо добро, може да се насочи директно до Лари Елисон.

Авторот, сепак, претпочита имплементација на мулти-моделирање во Microsoft SQL Server, на примерот на кој ќе биде опишана поддршката за RDBMS за модели на документи и графикони.

Модел на документ во MS SQL Server

Веќе имаше две одлични статии на Хабре за тоа како MS SQL Server имплементира поддршка за моделот на документи; ќе се ограничам на кратко прераскажување и коментар:

Начинот на поддршка на моделот на документи во MS SQL Server е сосема типичен за релационите DBMS: документите JSON се предлагаат да се складираат во обични текстуални полиња. Поддршката за моделот на документ е да обезбеди специјални оператори за анализа на овој JSON:

JSON_VALUE да се извлечат скаларни вредности на атрибутот,
JSON_QUERY да се извлечат поддокументи.

Вториот аргумент на двата оператори е израз во синтаксата слична на JSONPath.

Апстрактно, можеме да кажеме дека документите складирани на овој начин не се „првокласни ентитети“ во релациска DBMS, за разлика од точките. Поточно, во MS SQL Server моментално нема индекси на полињата на документите JSON, што го отежнува спојувањето на табелите користејќи ги вредностите на овие полиња, па дури и изборот на документи користејќи ги овие вредности. Сепак, можно е да се создаде пресметана колона за такво поле и индекс на него.

Дополнително, MS SQL Server обезбедува можност за практично конструирање на документ JSON од содржината на табелите користејќи го операторот FOR JSON PATH - можност, во одредена смисла, спротивна на претходната, конвенционално складирање. Јасно е дека без разлика колку е брз RDBMS, овој пристап е во спротивност со идеологијата на DBMS на документи, кои во суштина складираат готови одговори на популарните прашања и можат да решаваат само проблеми со леснотијата на развој, но не и брзината.

Конечно, MS SQL Server ви овозможува да го решите спротивниот проблем на конструкцијата на документите: можете да го разложите JSON на табели користејќи OPENJSON. Ако документот не е целосно рамен, ќе треба да го користите CROSS APPLY.

Графички модел во MS SQL Server

Поддршката за моделот граф (LPG) е целосно имплементирана и во Microsoft SQL Server предвидливи: Се предлага да се користат специјални табели за складирање на јазли и за складирање на рабовите на графикот. Таквите табели се креираат со помош на изрази CREATE TABLE AS NODE и CREATE TABLE AS EDGE соодветно.

Табелите од првиот тип се слични на обичните табели за складирање записи, со единствената надворешна разлика што табелата содржи системско поле $node_id — единствен идентификатор на графички јазол во базата на податоци.

Слично на тоа, табелите од вториот тип имаат системски полиња $from_id и $to_id, записите во таквите табели јасно ги дефинираат врските помеѓу јазлите. Посебна табела се користи за складирање на врски од секој тип.

Да го илустрираме ова со пример. Нека податоците од графиконот имаат распоред како оној прикажан на сликата. Потоа, за да ја креирате соодветната структура во базата на податоци, треба да ги извршите следните 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);

Главната специфичност на ваквите табели е тоа што во барањата против нив е можно да се користат шеми на графикони со синтакса слична на Cypher (сепак, „*„итн. сè уште не се поддржани). Врз основа на мерењата на перформансите, исто така може да се претпостави дека начинот на кој податоците се чуваат во овие табели е различен од начинот на кој податоците се складираат во обичните табели и дека е оптимизиран за извршување на такви барања за графикони.

SELECT Cafe.name
  FROM Person, likes, Cafe
  WHERE MATCH (Person-(friendOf)-(likes)->Cafe)
  AND Person.name = 'John';

Покрај тоа, доста е тешко да не се користат овие шеми на графикони кога се работи со такви табели, бидејќи во обичните SQL прашања за решавање слични проблеми ќе биде неопходно да се направат дополнителни напори за да се добијат идентификатори на јазли на системот (графикон).$node_id, $from_id, $to_id; Од истата причина, барањата за вметнување податоци не се прикажани овде бидејќи се непотребно незгодни).

Да го резимираме описот на имплементациите на моделите на документи и графикони во MS SQL Server, би забележал дека таквите имплементации на еден модел врз друг не изгледаат успешни, првенствено од гледна точка на јазичниот дизајн. Неопходно е да се прошири еден јазик со друг, јазиците не се целосно „ортогонални“, правилата за компатибилност може да бидат прилично бизарни.

Мулти-модел DBMS врз основа на моделот на документот

Во овој дел, би сакал да ја илустрирам имплементацијата на мулти-модел во документ DBMS користејќи го примерот на не најпопуларниот од нив, MongoDB (како што беше кажано, има само условни графски оператори $lookup и $graphLookup, не работи на распарчени колекции), туку користејќи го примерот на позрел и „претпријатен“ DBMS MarkLogic.

Значи, дозволете колекцијата да содржи збир на XML документи од следниов тип (MarkLogic исто така ви овозможува да складирате JSON документи):

<Person INN="631803299804">
  <name>John</name>
  <surname>Smith</surname>
</Person>

Релациски модел во MarkLogic

Може да се креира релациски приказ на збирка документи со користење шаблон за прикажување (содржина на елементи value во примерот подолу може да има произволна 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>

Можете да го адресирате креираниот приказ со SQL барање (на пример, преку ODBC):

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

За жал, релацискиот приказ создаден од шаблонот за приказ е само за читање. Кога обработува барање за него, MarkLogic ќе се обиде да го користи индекси на документи. Претходно, MarkLogic имаше целосно ограничени релациски погледи врз основа на индекс и може да се запишуваат, но сега се сметаат за застарени.

Графички модел во MarkLogic

Со поддршка за моделот график (RDF), сè е приближно исто. Повторно со помош шаблон за прикажување можете да креирате RDF репрезентација на збирка документи од примерот погоре:

<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>

Можете да го адресирате добиениот RDF график со SPARQL барање:

PREFIX : <http://example.org/example#>
SELECT ?name ?surname {
  :631803299804 :name ?name ; :surname ?surname .
}

За разлика од релацискиот, MarkLogic го поддржува графичкиот модел на два други начини:

DBMS може да биде полноправно посебно складирање на RDF податоци (тројки во него ќе се нарекуваат успеа за разлика од оние опишани погоре извлечена).
RDF во специјална серијализација може едноставно да се вметне во XML или JSON документи (а потоа ќе се повикаат тројки неконтролирано). Ова е веројатно алтернатива на механизмите idref итн

Добра идеја за тоа како работите „навистина“ функционираат во MarkLogic е дадена од Оптички API, во оваа смисла, тој е на ниско ниво, иако неговата цел е прилично спротивна - да се обиде да се апстрахира од користениот модел на податоци, да обезбеди конзистентна работа со податоците во различни модели, трансакционалност итн.

Мулти-модел DBMS „без главен модел“

На пазарот има и DBMS кои се позиционираат како првично мултимодел, без наследен главен модел. Тие вклучуваат АрангоДБ, OrientDB (од 2018 година развојната компанија припаѓа на SAP) и CosmosDB (услуга како дел од платформата за облак Microsoft Azure).

Всушност, постојат „основни“ модели во ArangoDB и OrientDB. Во двата случаи, ова се нивните сопствени модели на податоци, кои се генерализации на документот. Генерализациите се главно за да се олесни можноста за извршување на прашања од графикон и релациона природа.

Овие модели се единствените достапни за употреба во наведениот DBMS; нивните јазици за пребарување се дизајнирани да работат со нив. Се разбира, таквите модели и DBMS се ветувачки, но недостатокот на компатибилност со стандардните модели и јазици го оневозможува користењето на овие DBMS во наследните системи - за замена на DBMS што веќе се користат таму.

Веќе имаше прекрасна статија за ArangoDB и OrientDB на Habré: ПРИКЛУЧЕТЕ СЕ во NoSQL базите на податоци.

АрангоДБ

ArangoDB тврди дека има поддршка за модел на податоци со графикони.

Јазлите на графикот во ArangoDB се обични документи, а рабовите се документи од посебен тип кои, заедно со редовните системски полиња, имаат (_key, _id, _rev) системски полиња _from и _to. Документите во DBMS на документи традиционално се комбинираат во збирки. Колекциите на документи кои претставуваат рабови се нарекуваат збирки на рабови во ArangoDB. Патем, документите за собирање рабови се исто така документи, така што рабовите во ArangoDB исто така можат да дејствуваат како јазли.

Сурови податоци

Дозволете ни да имаме колекција persons, чии документи изгледаат вака:

[
  {
    "_id"  : "people/alice" ,
    "_key" : "alice" ,
    "name" : "Алиса"
  },
  {
    "_id"  : "people/bob" ,
    "_key" : "bob" ,
    "name" : "Боб"  
  }
]

Нека има и колекција cafes:

[
  {
    "_id" : "cafes/jd" ,
    "_key" : "jd" ,
    "name" : "Джон Донн"  
  },
  {
    "_id" : "cafes/jj" ,
    "_key" : "jj" ,
    "name" : "Жан-Жак"
  }
]

Потоа колекцијата likes може да изгледа вака:

[
  {
    "_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 
  }
]

Прашања и резултати

Прашањето во стилот на графиконот на јазикот AQL што се користи во ArangoDB, враќајќи информации читливи од луѓе за тоа кој сака кафуле, изгледа вака:

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

Во релациски стил, каде што ги „пресметуваме“ односите наместо да ги складираме, ова барање може да се преработи вака (патем, без збирката likes може без):

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 }

Резултатот во двата случаи ќе биде ист:

[
  { "person" : "Алиса" , likes : "Жан-Жак" } ,
  { "person" : "Алиса" , likes : "Джон Донн" } ,
  { "person" : "Боб" , likes : "Джон Донн" }
]

Повеќе прашања и резултати

Ако форматот на резултат погоре се чини дека е потипичен за релациона DBMS отколку за документ DBMS, можете да го испробате ова барање (или можете да го користите COLLECT):

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

Резултатот ќе изгледа вака:

[
  { "person" : "Алиса" , likes : ["Жан-Жак" , "Джон Донн"]  } ,
  { "person" : "Боб" , likes : ["Джон Донн"] }
]

OrientDB

Основата за имплементација на графички модел на врвот на модел на документ во OrientDB е можност полињата за документи, покрај повеќе или помалку стандардни скаларни вредности, имаат и вредности од типови како што се LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. Вредностите на овие типови се врски или збирки на врски до системски идентификатори документи.

Идентификаторот на документот доделен од системот има „физичко значење“, што ја означува позицијата на записот во базата на податоци и изгледа вака: @rid : #3:16. Така, вредностите на референтните својства се навистина покажувачи (како во графичкиот модел) наместо услови за избор (како во релациониот модел).

Како ArangoDB, рабовите во OrientDB се претставени како посебни документи (иако ако некој раб нема свои својства, може да се направи лесен, и нема да одговара на посебен документ).

Сурови податоци

Во формат близок до формат на депонија OrientDB база на податоци, податоците од претходниот пример за ArangoDB би изгледале вака:

[
     {
      "@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"
    }
  ]

Како што можеме да видиме, темињата исто така складираат информации за дојдовните и појдовните рабови. На користејќи Document API треба да го следи самиот референцијален интегритет, а Graph API ја презема оваа работа. Но, да видиме како изгледа пристапот до OrientDB во „чистите“ јазици за пребарување кои не се интегрирани во програмските јазици.

Прашања и резултати

Барањето слично по цел на барањето од примерот за ArangoDB во OrientDB изгледа вака:

SELECT name AS person_name, OUT('likes').name AS cafe_name
   FROM Person
   UNWIND cafe_name

Резултатот ќе се добие во следнава форма:

[
  { "person_name": "Алиса", "cafe_name": "Джон Донн" },
  { "person_name": "Алиса", "cafe_name": "Жан-Жак" },
  { "person_name": "Боб",  "cafe_name": "Жан-Жак" }
]

Ако форматот на резултатот повторно изгледа премногу „релациски“, треба да ја отстраните линијата со UNWIND():

[
  { "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
  { "person_name": "Боб",  "cafe_name": [ "Жан-Жак" ' }
]

Јазикот за пребарување на OrientDB може да се опише како SQL со инсерти слични на Gremlin. Во верзијата 2.2, се појави формулар за барање сличен на 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

Форматот на резултатот ќе биде ист како и во претходното барање. Размислете што треба да се отстрани за да се направи по „релациона“, како во првото барање.

Azure CosmosDB

Во помала мера, она што беше кажано погоре за ArangoDB и OrientDB се однесува на Azure CosmosDB. CosmosDB ги обезбедува следните API за пристап до податоци: SQL, MongoDB, Gremlin и Cassandra.

SQL API и MongoDB API се користат за пристап до податоци во моделот на документот. Gremlin API и Cassandra API - за пристап до податоци во формати на графикони и колони, соодветно. Податоците во сите модели се зачувуваат во формат на внатрешен модел на CosmosDB: АРС („атом-запис-секвенца“), што е исто така блиску до документот.

Но, моделот на податоци избран од корисникот и користениот API се фиксирани во моментот на креирање сметка во услугата. Не е возможно да се пристапи до податоците вчитани во еден модел во формат на друг модел, како што е илустрирано со нешто како ова:

Така, мулти-моделот во Azure CosmosDB денес е само можност за користење на неколку бази на податоци кои поддржуваат различни модели од еден производител, што не ги решава сите проблеми на складирање со повеќе варијанти.

Мулти-модел DBMS базиран на графички модел?

Вреди да се забележи фактот дека на пазарот сè уште нема DBMS со повеќе модели кои се засноваат на графички модел (освен поддршката за повеќе модели за истовремено два графички модели: RDF и LPG; видете го ова во претходната публикација). Најголемите потешкотии се предизвикани од имплементацијата на модел на документ на врвот на модел на графикон, наместо на релациски.

Прашањето како да се имплементира релациски модел на врвот на графичкиот модел беше разгледано дури и за време на формирањето на вториот. Како кажана пример Дејвид Мекговерн:

Нема ништо инхерентно во пристапот на графиконот што го спречува создавањето слој (на пример, со соодветно индексирање) на базата на податоци на графикони што овозможува релациски приказ со (1) враќање на торките од вообичаените парови на клучни вредности и (2) групирање на торки по тип на релација.

Кога имплементирате модел на документ на врвот на модел на графикон, треба да го имате на ум, на пример, следново:

Елементите на низата JSON се сметаат за подредени, но оние што произлегуваат од темето на работ на графикот не се;
Податоците во моделот на документ обично се денормализираат; сепак не сакате да складирате неколку копии од истиот вграден документ, а поддокументите обично немаат идентификатори;
Од друга страна, идеологијата на DBMS на документи е дека документите се готови „агрегати“ кои не треба да се градат одново секој пат. Потребно е на моделот на графикот да му се обезбеди можност брзо да се добие подграф што одговара на готовиот документ.

Малку рекламирање

Авторот на статијата е поврзан со развојот на NitrosBase DBMS, чиј внатрешен модел е график, а надворешните модели - релациони и документарни - се негови претстави. Сите модели се еднакви: речиси секој податок е достапен во кој било од нив со користење на јазик за прашања што е природен за него. Покрај тоа, во секој поглед, податоците може да се променат. Промените ќе се рефлектираат во внатрешниот модел и, соодветно, во други погледи.

Се надевам дека ќе опишам како изгледа совпаѓањето на моделите во NitrosBase во една од следните написи.

Заклучок

Се надевам дека општите контури на она што се нарекува мултимоделирање станаа повеќе или помалку јасни на читателот. Мулти-моделските DBMS се сосема различни, а „поддршката за повеќе модели“ може да изгледа поинаку. За да се разбере она што се нарекува „мулти-модел“ во секој конкретен случај, корисно е да се одговори на следниве прашања:

Дали зборуваме за поддршка на традиционални модели или некаков „хибриден“ модел?
Дали моделите се „еднакви“ или еден од нив е предмет на другиот?
Дали моделите се „рамнодушни“ едни на други? Дали податоците напишани во еден модел може да се читаат во друг или дури и да се препишат?

Мислам дека на прашањето за релевантноста на мулти-модел DBMS веќе може да се одговори позитивно, но интересното прашање е кои типови од нив ќе бидат повеќе барани во блиска иднина. Се чини дека повеќемоделните DBMS кои поддржуваат традиционални модели, првенствено релациони, ќе бидат во поголема побарувачка; Популарноста на DBMS со повеќе модели, кои нудат нови модели кои ги комбинираат предностите на различните традиционални, е прашање на подалечна иднина.

Само регистрирани корисници можат да учествуваат во анкетата. Најави се, вие сте добредојдени.

Дали користите мулти-модел DBMS?

Ние не го користиме, складираме сè во еден DBMS и во еден модел
Ние користиме мулти-модел способности на традиционалните DBMS
Ние практикуваме полиглотна упорност
Ние користиме нови мулти-моделски DBMS (Arango, Orient, CosmosDB)

Гласаа 19 корисници. 4 корисници се воздржаа.

Извор: www.habr.com

Дали мултимоделските DBMS се основата на современите информациски системи?