현대 정보 시스템은 매우 복잡합니다. 무엇보다도, 그 복잡성은 그 안에서 처리되는 데이터의 복잡성으로 인해 발생합니다. 데이터의 복잡성은 종종 사용되는 데이터 모델의 다양성에 있습니다. 따라서 예를 들어 데이터가 "큰" 경우 문제가 되는 특성 중 하나는 데이터의 양("볼륨")뿐 아니라 다양성("다양성")입니다.

추론에서 아직 결함을 찾지 못했다면 계속 읽으십시오.

내용

다언어 지속성
다중 모델
관계형 모델 기반의 다중 모델 DBMS
     MS SQL Server의 문서 모델
     MS SQL Server의 그래프 모델
문서 모델 기반의 다중 모델 DBMS
     MarkLogic의 관계형 모델
     MarkLogic의 그래프 모델
“주모델 없는” 다중모델 DBMS
     아랑고DB
     OrientDB
     애저 코스모스DB
그래프 모델 기반의 다중 모델 DBMS?
결론
Опрос

다언어 지속성

위의 내용은 때로는 하나의 시스템 프레임워크 내에서도 여러 개의 서로 다른 DBMS를 사용하여 데이터를 저장하고 이를 처리하는 다양한 문제를 해결해야 한다는 사실로 이어지며, 각 DBMS는 자체 데이터 모델을 지원합니다. M. Fowler의 가벼운 손길로, 저자 많은 유명한 책들과 그 중 하나 공동 저자 애자일 선언문(Agile Manifesto), 이런 상황을 이렇게 부릅니다. 다중 변형 스토리지 (“다언어 지속성”).

Fowler는 또한 전자 상거래 분야의 모든 기능을 갖춘 고부하 애플리케이션에서 데이터 저장소를 구성하는 다음과 같은 예를 가지고 있습니다.

물론 이 예는 다소 과장되었지만 해당 목적에 맞게 하나 또는 다른 DBMS를 선택하는 데 유리한 몇 가지 고려 사항을 찾을 수 있습니다. 예를 들어 다음과 같습니다. 여기에.

그런 동물원에서 하인이 되는 것이 쉽지 않다는 것은 분명합니다.

• 데이터 저장을 수행하는 코드의 양은 사용되는 DBMS 수에 비례하여 증가합니다. 데이터를 동기화하는 코드의 양은 이 숫자의 제곱에 비례하지 않더라도 좋습니다.
• 사용되는 DBMS 수의 배수에 따라 사용되는 각 DBMS의 기업 특성(확장성, 내결함성, 고가용성)을 제공하는 비용이 증가합니다.
• 스토리지 하위 시스템 전체의 기업 특성, 특히 트랜잭션성을 보장하는 것은 불가능합니다.

동물원 책임자의 관점에서 보면 모든 것이 다음과 같습니다.

• DBMS 제조업체의 라이센스 및 기술 지원 비용이 여러 번 증가했습니다.
• 인력 과잉 및 마감일 증가.
• 데이터 불일치로 인한 직접적인 금전적 손실이나 벌금.

시스템의 총 소유 비용(TCO)이 크게 증가합니다. "여러 스토리지 옵션" 상황에서 벗어날 수 있는 방법이 있습니까?

다중 모델

"다변량 저장"이라는 용어는 2011년에 사용되었습니다. 접근 방식의 문제점을 인식하고 솔루션을 찾는 데 수년이 걸렸으며 2015년에 Gartner 분석가의 입을 통해 답변이 공식화되었습니다.

• "에서NoSQL DBMS 시장 가이드 - 2015»:
  

  DBMS의 미래, 아키텍처 및 사용 방법은 다중 모델입니다.

• "에서ODBMS 매직 쿼드런트 - 2016»:
  

  주요 운영 DBMS는 단일 플랫폼의 일부로 관계형 및 비관계형 등 다양한 모델을 제공합니다.

이번에는 Gartner 분석가의 예측이 옳았던 것 같습니다. 해당 페이지로 이동하시면 주요 평가 DB-Engine의 DBMS를 보면 알 수 있습니다.о대부분의 리더는 스스로를 다중 모델 DBMS로 포지셔닝합니다. 비공개 등급이 있는 페이지에서도 동일한 내용을 볼 수 있습니다.

아래 표는 다중 모델이라고 주장하는 각 비공개 등급의 선두주자인 DBMS를 보여줍니다. 각 DBMS에 대해 원래 지원되는 모델(한때 유일한 모델)과 현재 지원되는 모델이 표시됩니다. 또한 자체적으로 "원래 다중 모델"로 자리매김하고 작성자에 따르면 초기 상속된 모델이 없는 DBMS도 나열되어 있습니다.

DBMS	초기 모델	추가 모델
신탁	관계형	그래프, 문서
MS의 SQL	관계형	그래프, 문서
PostgreSQL	관계형	그래프*, 문서
마크로직	기록한 것	그래프, 관계형
MongoDB의	기록한 것	키-값, 그래프*
데이터스택스	와이드 컬럼	다큐멘터리, 그래프
Redis	핵심 가치	다큐멘터리, 그래프*
아랑고DB	-	그래프, 문서
OrientDB	-	그래프, 문서, 관계형
애저 코스모스DB	-	그래프, 문서, 관계형

테이블 노트

예약이 필요한 테이블 표시 문의 별표:

• PostgreSQL DBMS는 그래프 데이터 모델을 지원하지 않지만, 이 제품은 지원합니다. 그것을 기반으로, AgensGraph와 같은.
• MongoDB와 관련하여 쿼리 언어에 그래프 연산자가 있다고 말하는 것이 더 정확합니다($lookup, $graphLookup) 그래프 모델 지원에 관한 것보다 물론 도입에는 그래프 모델 지원 방향으로 물리적 스토리지 수준에서 일부 최적화가 필요했습니다.
• Redis와 관련하여 우리는 확장을 의미합니다. 레디스그래프.

다음으로, 각 클래스에 대해 이 클래스의 DBMS에서 여러 모델에 대한 지원이 어떻게 구현되는지 보여드리겠습니다. 관계형, 문서 및 그래프 모델을 가장 중요하게 고려하고 특정 DBMS의 예를 사용하여 "누락된 모델"이 어떻게 구현되는지 보여줍니다.

관계형 모델 기반의 다중 모델 DBMS

현재 주요 DBMS는 관계형이므로 RDBMS가 다중 모델링 방향으로의 움직임을 보이지 않는다면 Gartner의 예측은 사실이라고 간주될 수 없습니다. 그리고 그들은 시연합니다. 이제 다중 모델 DBMS는 아무것도 잘 할 수 없는 스위스 칼과 같다는 생각이 Larry Ellison에게 직접적으로 전달될 수 있습니다.

그러나 저자는 문서 및 그래프 모델에 대한 RDBMS 지원이 설명될 예에서 Microsoft SQL Server의 다중 모델링 구현을 선호합니다.

MS SQL Server의 문서 모델

MS SQL Server가 문서 모델에 대한 지원을 구현하는 방법에 대해 Habré에는 이미 두 개의 훌륭한 기사가 있습니다. 간략한 설명과 설명으로 제한하겠습니다.

• SQL Server 2016에서 JSON 작업
• SQL 서버 2017 JSON

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

이 섹션에서는 가장 인기가 없는 MongoDB의 예를 사용하여 문서 DBMS에서 다중 모델의 구현을 설명하고 싶습니다(말한 대로 조건부 그래프 연산자만 있음). $lookup и $graphLookup, 샤딩된 컬렉션에서 작업하지 않음), 보다 성숙하고 "엔터프라이즈" DBMS의 예를 사용합니다. 마크로직.

따라서 컬렉션에 다음 유형의 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>

SPARQL 쿼리를 사용하여 결과 RDF 그래프를 처리할 수 있습니다.

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

관계형 모델과 달리 MarkLogic은 두 가지 다른 방식으로 그래프 모델을 지원합니다.

1. DBMS는 RDF 데이터의 완전한 별도 저장소가 될 수 있습니다. 관리 위에서 설명한 것과는 대조적으로 추출한).
2. 특수 직렬화의 RDF는 XML 또는 JSON 문서에 간단히 삽입할 수 있습니다(그러면 세 쌍이 호출됩니다). 관리되지 않는). 이것은 아마도 메커니즘의 대안일 것입니다. idref 기타

MarkLogic에서 "실제로" 작동하는 방식에 대한 좋은 아이디어는 다음과 같습니다. 광학 API, 이러한 의미에서 목적은 오히려 반대이지만 사용된 데이터 모델에서 추상화하고 다양한 모델, 트랜잭션성 등의 데이터에 대한 일관된 작업을 보장하기 위해 낮은 수준입니다.

“주모델 없는” 다중모델 DBMS

상속된 메인 모델 없이 초기에 다중 모델로 자리매김하는 DBMS도 시장에 나와 있습니다. 여기에는 다음이 포함됩니다 아랑고DB, OrientDB (2018년부터 개발 회사는 SAP에 속함) 및 코스모스DB (Microsoft Azure 클라우드 플랫폼의 일부인 서비스).

실제로 ArangoDB와 OrientDB에는 "핵심" 모델이 있습니다. 두 경우 모두 문서 모델을 일반화한 자체 데이터 모델입니다. 일반화는 주로 그래프 및 관계형 쿼리를 수행하는 기능을 용이하게 하기 위한 것입니다.

이러한 모델은 지정된 DBMS에서 사용할 수 있는 유일한 모델이며 자체 쿼리 언어는 이러한 모델과 함께 작동하도록 설계되었습니다. 물론 그러한 모델과 DBMS는 유망하지만 표준 모델 및 언어와의 호환성 부족으로 인해 이러한 DBMS를 레거시 시스템에서 사용하여 이미 사용된 DBMS를 대체하는 것은 불가능합니다.

Habré에는 ArangoDB와 OrientDB에 관한 훌륭한 기사가 이미 있습니다: NoSQL 데이터베이스에 JOIN.

아랑고DB

ArangoDB는 그래프 데이터 모델을 지원한다고 주장합니다.

ArangoDB에서 그래프의 노드는 일반 문서이고, 가장자리는 일반 시스템 필드와 함께 (_key, _id, _rev) 시스템 분야 _from и _to. 문서 DBMS의 문서는 전통적으로 컬렉션으로 결합됩니다. Edge를 나타내는 문서 모음을 ArangoDB에서는 Edge Collection이라고 합니다. 그런데 엣지 수집 문서도 문서이기 때문에 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 
  }
]

쿼리 및 결과

누가 어떤 카페를 좋아하는지에 대한 정보를 사람이 읽을 수 있는 형식으로 반환하는 ArangoDB에서 사용되는 AQL 언어의 그래프 스타일 쿼리는 다음과 같습니다.

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의 Edge는 별도의 문서로 표현됩니다. (Edge에 자체 속성이 없는 경우 경량, 별도의 문서에 해당하지 않습니다).

원시 데이터

에 가까운 형식으로 덤프 형식 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에 대한 액세스가 어떤 모습인지 살펴보겠습니다.

쿼리 및 결과

OrientDB의 ArangoDB 예제 쿼리와 목적이 유사한 쿼리는 다음과 같습니다.

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의 쿼리 언어는 Gremlin과 같은 삽입이 포함된 SQL로 설명할 수 있습니다. 버전 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

결과 형식은 이전 요청과 동일합니다. 첫 번째 쿼리처럼 좀 더 "관계형"으로 만들기 위해 제거해야 할 항목이 무엇인지 생각해 보세요.

애저 코스모스DB

ArangoDB 및 OrientDB에 대해 위에서 언급한 내용은 어느 정도는 Azure CosmosDB에도 적용됩니다. CosmosDB는 SQL, MongoDB, Gremlin 및 Cassandra와 같은 데이터 액세스 API를 제공합니다.

SQL API 및 MongoDB API는 문서 모델의 데이터에 액세스하는 데 사용됩니다. Gremlin API 및 Cassandra API - 각각 그래프 및 열 형식의 데이터에 액세스합니다. 모든 모델의 데이터는 CosmosDB 내부 모델 형식으로 저장됩니다. ARS (“atom-record-sequence”), 이는 문서 XNUMX에도 가깝습니다.

그러나 사용자가 선택한 데이터 모델과 사용되는 API는 서비스에서 계정을 생성하는 시점에 고정됩니다. 다음과 같이 한 모델에 로드된 데이터에 다른 모델의 형식으로 액세스하는 것은 불가능합니다.

따라서 현재 Azure CosmosDB의 다중 모델은 한 제조업체의 다양한 모델을 지원하는 여러 데이터베이스를 사용할 수 있는 기능일 뿐이며, 이는 다중 변형 스토리지의 모든 문제를 해결하지 못합니다.

그래프 모델 기반의 다중 모델 DBMS?

주목할만한 점은 아직 시장에 그래프 모델을 기반으로 하는 다중 모델 DBMS가 없다는 사실입니다(RDF와 LPG라는 두 가지 그래프 모델을 동시에 지원하는 다중 모델 지원은 제외). 이전 간행물). 가장 큰 어려움은 관계형 모델이 아닌 그래프 모델 위에 문서 모델을 구현하는 데서 발생합니다.

그래프 모델 위에 관계형 모델을 어떻게 구현하느냐는 문제는 그래프 모델을 구성하는 과정에서도 고려됐다. 어떻게 그는 말했다예를 들어, 데이비드 맥거번:

(1) 일반적인 키 값 쌍에서 튜플을 복구하고 (2) 관계 유형별 튜플.

그래프 모델 위에 문서 모델을 구현할 때 다음 사항을 염두에 두어야 합니다.

• JSON 배열의 요소는 순서가 있는 것으로 간주되지만 그래프 가장자리의 꼭지점에서 나오는 요소는 순서가 없습니다.
• 문서 모델의 데이터는 일반적으로 비정규화되어 있으므로 동일한 포함 문서의 여러 복사본을 저장하고 싶지 않으며 일반적으로 하위 문서에는 식별자가 없습니다.
• 반면, 문서 DBMS의 이념은 문서가 매번 새로 구축할 필요가 없는 기성품 "집합체"라는 것입니다. 완성된 문서에 해당하는 하위 그래프를 빠르게 얻을 수 있는 기능을 그래프 모델에 제공해야 합니다.

일부 광고

이 기사의 저자는 내부 모델이 그래프이고 외부 모델(관계형 및 문서)이 표현인 NitrosBase DBMS의 개발과 관련되어 있습니다. 모든 모델은 동일합니다. 자연스러운 쿼리 언어를 사용하여 거의 모든 데이터를 사용할 수 있습니다. 또한 어떤 보기에서든 데이터가 변경될 수 있습니다. 변경 사항은 내부 모델에 반영되며 그에 따라 다른 보기에도 반영됩니다.

다음 기사 중 하나를 통해 NitrosBase의 모델 매칭이 어떤 모습인지 설명하겠습니다.

결론

다중 모델링이라 불리는 것의 일반적인 개요가 독자들에게 어느 정도 명확해졌기를 바랍니다. 다중 모델 DBMS는 상당히 다르며 "다중 모델 지원"도 다르게 보일 수 있습니다. 각각의 특정 사례에서 "다중 모델"이 무엇인지 이해하려면 다음 질문에 답하는 것이 유용합니다.

1. 우리는 전통적인 모델을 지원하는 것에 대해 이야기하고 있습니까, 아니면 일종의 "하이브리드" 모델을 지원하는 것에 대해 이야기하고 있습니까?
2. 모델이 "동등"합니까, 아니면 그 중 하나가 다른 모델의 주제입니까?
3. 모델은 서로 "무관심"합니까? 한 모델에 기록된 데이터를 다른 모델에서 읽거나 덮어쓸 수 있나요?

다중 모델 DBMS의 타당성에 대한 질문은 이미 긍정적으로 대답할 수 있다고 생각합니다. 그러나 흥미로운 질문은 가까운 미래에 어떤 유형의 DBMS가 더 수요가 많을 것인가입니다. 주로 관계형인 기존 모델을 지원하는 다중 모델 DBMS의 수요가 더 커질 것으로 보입니다. 다양한 기존 DBMS의 장점을 결합한 새로운 모델을 제공하는 다중 모델 DBMS의 인기는 더 먼 미래의 문제입니다.

등록된 사용자만 설문 조사에 참여할 수 있습니다. 로그인제발

다중 모델 DBMS를 사용하시나요?

• 우리는 그것을 사용하지 않고 모든 것을 하나의 DBMS와 하나의 모델에 저장합니다.

• 우리는 전통적인 DBMS의 다중 모델 기능을 사용합니다.

• 우리는 다중 언어 지속성을 실천합니다.

• 새로운 다중 모델 DBMS(Arango, Orient, CosmosDB)를 사용합니다.

19명의 사용자가 투표했습니다. 4명의 사용자가 기권했습니다.

출처 : habr.com