Hệ thống thông tin hiện đại khá phức tạp. Ít nhất, sự phức tạp của chúng là do độ phức tạp của dữ liệu được xử lý trong đó. Sự phức tạp của dữ liệu thường nằm ở sự đa dạng của các mô hình dữ liệu được sử dụng. Vì vậy, ví dụ, khi dữ liệu trở nên “lớn”, một trong những đặc điểm có vấn đề không chỉ là khối lượng (“khối lượng”) mà còn là tính đa dạng (“đa dạng”) của nó.

Nếu bạn chưa tìm thấy lỗ hổng trong lý luận thì hãy đọc tiếp.

nội dung

sự kiên trì đa ngôn ngữ
Đa mô hình
DBMS đa mô hình dựa trên mô hình quan hệ
     Mô hình tài liệu trong MS SQL Server
     Mô hình đồ thị trong MS SQL Server
DBMS đa mô hình dựa trên mô hình tài liệu
     Mô hình quan hệ trong MarkLogic
     Mô hình đồ thị trong MarkLogic
DBMS đa mô hình “không có mô hình chính”
     ArangoDB
     Phương Đông
     Azure CosmosDB
DBMS đa mô hình dựa trên mô hình đồ thị?
Kết luận
Опрос

sự kiên trì đa ngôn ngữ

Điều trên dẫn đến thực tế là đôi khi ngay cả trong khuôn khổ của một hệ thống cũng cần phải sử dụng một số DBMS khác nhau để lưu trữ dữ liệu và giải quyết các vấn đề khác nhau khi xử lý chúng, mỗi vấn đề hỗ trợ mô hình dữ liệu riêng. Với bàn tay nhẹ nhàng của M. Fowler, tác giả một số cuốn sách nổi tiếng và một trong những đồng tác giả Tuyên ngôn Agile, tình trạng này được gọi là lưu trữ đa dạng (“sự kiên trì đa ngôn ngữ”).

Fowler cũng có ví dụ sau về việc tổ chức lưu trữ dữ liệu trong một ứng dụng đầy đủ tính năng và có tải trọng cao trong lĩnh vực thương mại điện tử.

Tất nhiên, ví dụ này có phần phóng đại, nhưng có thể tìm thấy một số cân nhắc có lợi cho việc chọn một hoặc một DBMS khác cho mục đích tương ứng, ví dụ: đây.

Rõ ràng là người hầu trong một sở thú như vậy không hề dễ dàng.

Số lượng mã thực hiện lưu trữ dữ liệu tăng tỷ lệ thuận với số lượng DBMS được sử dụng; lượng dữ liệu đồng bộ mã tốt nếu không tỷ lệ thuận với bình phương của số này.
Là bội số của số lượng DBMS được sử dụng, chi phí cung cấp các đặc tính doanh nghiệp (khả năng mở rộng, khả năng chịu lỗi, tính sẵn sàng cao) của mỗi DBMS được sử dụng sẽ tăng lên.
Không thể đảm bảo các đặc điểm doanh nghiệp của toàn bộ hệ thống con lưu trữ - đặc biệt là tính giao dịch.

Theo quan điểm của giám đốc sở thú, mọi thứ trông như thế này:

Chi phí cấp phép và hỗ trợ kỹ thuật từ nhà sản xuất DBMS tăng lên gấp nhiều lần.
Thừa nhân lực và tăng thời hạn.
Tổn thất tài chính trực tiếp hoặc bị phạt do dữ liệu không nhất quán.

Tổng chi phí sở hữu (TCO) của hệ thống tăng lên đáng kể. Có cách nào thoát khỏi tình trạng “nhiều lựa chọn lưu trữ” không?

Đa mô hình

Thuật ngữ “lưu trữ đa biến” được sử dụng vào năm 2011. Nhận thức về các vấn đề của cách tiếp cận và việc tìm kiếm giải pháp phải mất vài năm và đến năm 2015, qua miệng các nhà phân tích của Gartner, câu trả lời đã được đưa ra:

Từ "Hướng dẫn thị trường dành cho cơ sở dữ liệu NoSQL - 2015»:
Tương lai của DBMS, kiến trúc và cách sử dụng chúng là đa mô hình.
Từ "Magic Quadrant cho ODBMS - 2016»:
Các DBMS hoạt động hàng đầu sẽ cung cấp nhiều mô hình—quan hệ và phi quan hệ—như một phần của một nền tảng duy nhất.

Có vẻ như lần này các nhà phân tích của Gartner đã đúng với dự đoán của họ. Nếu bạn đi đến trang với đánh giá chính DBMS trên DB-Engines, bạn có thể thấy điều đóоHầu hết các nhà lãnh đạo của nó đều tự định vị mình là các DBMS đa mô hình. Điều tương tự có thể được nhìn thấy trên trang với bất kỳ đánh giá riêng tư nào.

Bảng dưới đây hiển thị DBMS - những hệ thống dẫn đầu trong từng xếp hạng riêng tư, được cho là đa mô hình. Đối với mỗi DBMS, mô hình được hỗ trợ ban đầu (từng là mô hình duy nhất) và cùng với nó là các mô hình hiện được hỗ trợ sẽ được chỉ định. Cũng được liệt kê là các DBMS tự định vị mình là “đa mô hình ban đầu” và theo những người sáng tạo, không có bất kỳ mô hình kế thừa ban đầu nào.

DBMS	Mô hình ban đầu	Các mô hình bổ sung
Oracle	quan hệ	Đồ thị, tài liệu
MSSQL	quan hệ	Đồ thị, tài liệu
PostgreSQL	quan hệ	Đồ thị*, tài liệu
đánh dấuLogic	Phim tài liệu	Đồ thị, quan hệ
MongoDB	Phim tài liệu	Khóa-giá trị, biểu đồ*
Dữ liệuStax	Cột rộng	Tài liệu, đồ thị
Redis	Giá trị cốt lõi	Tài liệu, đồ thị*
ArangoDB	-	Đồ thị, tài liệu
Phương Đông	-	Đồ thị, tài liệu, quan hệ
Azure CosmosDB	-	Đồ thị, tài liệu, quan hệ

Bảng ghi chú

Dấu hoa thị trong bảng đánh dấu các câu yêu cầu đặt trước:

Cơ sở dữ liệu PostgreSQL không hỗ trợ mô hình dữ liệu đồ thị, nhưng sản phẩm này hỗ trợ nó dựa vào nó, chẳng hạn như AgensGraph.
Liên quan đến MongoDB, sẽ đúng hơn khi nói về sự hiện diện của các toán tử đồ thị trong ngôn ngữ truy vấn ($lookup, $graphLookup) hơn là về việc hỗ trợ mô hình đồ thị, mặc dù tất nhiên, việc giới thiệu chúng yêu cầu một số tối ưu hóa ở mức lưu trữ vật lý theo hướng hỗ trợ mô hình đồ thị.
Liên quan đến Redis, chúng tôi muốn nói đến phần mở rộng RedisGraph.

Tiếp theo, đối với mỗi lớp, chúng tôi sẽ chỉ ra cách triển khai hỗ trợ cho một số mô hình trong DBMS từ lớp này. Chúng tôi sẽ coi các mô hình quan hệ, tài liệu và đồ thị là quan trọng nhất và sử dụng các ví dụ về các DBMS cụ thể để chỉ ra cách triển khai “những cái còn thiếu”.

DBMS đa mô hình dựa trên mô hình quan hệ

Các DBMS hàng đầu hiện nay là các DBMS quan hệ; dự báo của Gartner không thể được coi là đúng nếu các RDBMS không thể hiện sự chuyển động theo hướng đa mô hình. Và họ chứng minh. Giờ đây, ý tưởng rằng một DBMS đa mô hình giống như một con dao Thụy Sĩ, không thể làm tốt bất cứ điều gì, có thể được hướng trực tiếp đến Larry Ellison.

Tuy nhiên, tác giả thích triển khai đa mô hình hóa trong Microsoft SQL Server hơn, trên ví dụ về hỗ trợ RDBMS cho các mô hình tài liệu và đồ thị sẽ được mô tả.

Mô hình tài liệu trong MS SQL Server

Đã có hai bài viết xuất sắc trên Habré về cách MS SQL Server triển khai hỗ trợ cho mô hình tài liệu. Tôi sẽ giới hạn ở phần kể lại và bình luận ngắn gọn:

Cách hỗ trợ mô hình tài liệu trong MS SQL Server khá điển hình cho các DBMS quan hệ: Các tài liệu JSON được đề xuất lưu trữ trong các trường văn bản thông thường. Hỗ trợ cho mô hình tài liệu là cung cấp các toán tử đặc biệt để phân tích JSON này:

JSON_VALUE để trích xuất các giá trị thuộc tính vô hướng,
JSON_QUERY để trích xuất các tài liệu phụ.

Đối số thứ hai của cả hai toán tử là một biểu thức có cú pháp giống JSONPath.

Tóm lại, chúng ta có thể nói rằng các tài liệu được lưu trữ theo cách này không phải là “thực thể hạng nhất” trong DBMS quan hệ, không giống như các bộ dữ liệu. Cụ thể, trong MS SQL Server hiện tại không có chỉ mục trên các trường của tài liệu JSON, điều này gây khó khăn cho việc nối các bảng bằng cách sử dụng các giá trị của các trường này và thậm chí chọn tài liệu bằng các giá trị này. Tuy nhiên, có thể tạo một cột được tính toán cho trường đó và chỉ mục trên đó.

Ngoài ra, MS SQL Server còn cung cấp khả năng xây dựng tài liệu JSON từ nội dung của các bảng một cách thuận tiện bằng cách sử dụng toán tử FOR JSON PATH - một khả năng, theo một nghĩa nào đó, ngược lại với khả năng trước đó, việc lưu trữ thông thường. Rõ ràng là cho dù RDBMS có nhanh đến đâu thì cách tiếp cận này vẫn mâu thuẫn với hệ tư tưởng của DBMS tài liệu, về cơ bản lưu trữ các câu trả lời có sẵn cho các truy vấn phổ biến và chỉ có thể giải quyết các vấn đề về tính dễ phát triển chứ không phải về tốc độ.

Cuối cùng, MS SQL Server cho phép bạn giải quyết vấn đề ngược lại trong việc xây dựng tài liệu: bạn có thể phân tách JSON thành các bảng bằng cách sử dụng OPENJSON. Nếu tài liệu không phẳng hoàn toàn, bạn sẽ cần sử dụng CROSS APPLY.

Mô hình đồ thị trong MS SQL Server

Hỗ trợ mô hình đồ thị (LPG) cũng được triển khai đầy đủ trong Microsoft SQL Server có thể dự đoán được: Đề xuất sử dụng các bảng đặc biệt để lưu trữ các nút và lưu trữ các cạnh của đồ thị. Các bảng như vậy được tạo bằng cách sử dụng các biểu thức CREATE TABLE AS NODE и CREATE TABLE AS EDGE tương ứng.

Các bảng thuộc loại thứ nhất tương tự như các bảng thông thường để lưu trữ các bản ghi, với điểm khác biệt duy nhất bên ngoài là bảng chứa trường hệ thống. $node_id - mã định danh duy nhất của một nút biểu đồ trong cơ sở dữ liệu.

Tương tự, các bảng thuộc loại thứ hai có các trường hệ thống $from_id и $to_id, các mục trong các bảng như vậy xác định rõ ràng các kết nối giữa các nút. Một bảng riêng biệt được sử dụng để lưu trữ các mối quan hệ của từng loại.

Hãy để chúng tôi minh họa điều này bằng một ví dụ. Hãy để dữ liệu biểu đồ có bố cục giống như trong hình. Sau đó, để tạo cấu trúc tương ứng trong cơ sở dữ liệu, bạn cần chạy các truy vấn DDL sau:

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

Điểm đặc biệt chính của các bảng như vậy là trong các truy vấn đối với chúng, có thể sử dụng các mẫu biểu đồ có cú pháp giống Cypher (tuy nhiên, “*"v.v. chưa được hỗ trợ). Dựa trên các phép đo hiệu suất, cũng có thể giả định rằng cách lưu trữ dữ liệu trong các bảng này khác với cách lưu trữ dữ liệu trong các bảng thông thường và được tối ưu hóa để thực hiện các truy vấn biểu đồ như vậy.

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

Hơn nữa, rất khó để không sử dụng các mẫu biểu đồ này khi làm việc với các bảng như vậy, vì trong các truy vấn SQL thông thường để giải quyết các vấn đề tương tự, sẽ cần phải nỗ lực thêm để có được các mã định danh nút “biểu đồ” hệ thống ($node_id, $from_id, $to_id; Vì lý do tương tự, các truy vấn để chèn dữ liệu không được hiển thị ở đây vì chúng cồng kềnh không cần thiết).

Để tóm tắt mô tả về việc triển khai các mô hình tài liệu và đồ thị trong MS SQL Server, tôi cần lưu ý rằng việc triển khai mô hình này chồng lên mô hình khác dường như không thành công, chủ yếu từ quan điểm thiết kế ngôn ngữ. Cần phải mở rộng ngôn ngữ này với ngôn ngữ khác, các ngôn ngữ không hoàn toàn “trực giao”, các quy tắc tương thích có thể khá kỳ quái.

DBMS đa mô hình dựa trên mô hình tài liệu

Trong phần này, tôi muốn minh họa việc triển khai đa mô hình trong các DBMS tài liệu bằng cách sử dụng ví dụ về một DBMS không phổ biến nhất trong số đó, MongoDB (như đã nói, nó chỉ có các toán tử biểu đồ có điều kiện $lookup и $graphLookup, không hoạt động trên các bộ sưu tập được phân chia), nhưng sử dụng ví dụ về một DBMS “doanh nghiệp” và trưởng thành hơn đánh dấuLogic.

Vì vậy, hãy để bộ sưu tập chứa một tập hợp các tài liệu XML thuộc loại sau (MarkLogic cũng cho phép bạn lưu trữ các tài liệu JSON):

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

Mô hình quan hệ trong MarkLogic

Một cái nhìn quan hệ của một tập hợp các tài liệu có thể được tạo ra bằng cách sử dụng mẫu hiển thị (nội dung của các phần tử value trong ví dụ bên dưới có thể có XPath tùy ý):

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

Bạn có thể xử lý chế độ xem đã tạo bằng truy vấn SQL (ví dụ: thông qua ODBC):

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

Thật không may, chế độ xem quan hệ được tạo bởi mẫu hiển thị là chỉ đọc. Khi xử lý yêu cầu về nó, MarkLogic sẽ cố gắng sử dụng chỉ mục tài liệu. Trước đây, MarkLogic có quan điểm hạn chế, hoàn toàn dựa trên chỉ số và có thể ghi, nhưng bây giờ chúng được coi là không được dùng nữa.

Mô hình đồ thị trong MarkLogic

Với sự hỗ trợ cho mô hình đồ thị (RDF), mọi thứ đều giống nhau. Một lần nữa với sự giúp đỡ mẫu hiển thị bạn có thể tạo bản trình bày RDF của tập hợp tài liệu từ ví dụ trên:

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

Bạn có thể xử lý biểu đồ RDF kết quả bằng truy vấn SPARQL:

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

Không giống như mô hình quan hệ, MarkLogic hỗ trợ mô hình đồ thị theo hai cách khác:

Một DBMS có thể là một kho lưu trữ dữ liệu RDF hoàn chỉnh và riêng biệt (các bộ ba trong đó sẽ được gọi là quản lý trái ngược với những gì được mô tả ở trên trích xuất).
RDF ở dạng tuần tự hóa đặc biệt có thể được chèn đơn giản vào các tài liệu XML hoặc JSON (và các bộ ba sau đó sẽ được gọi không được quản lý). Đây có lẽ là một giải pháp thay thế cho cơ chế idref vv

Một ý tưởng hay về cách mọi thứ “thực sự” hoạt động trong MarkLogic được đưa ra bởi API quang học, theo nghĩa này, nó ở mức độ thấp, mặc dù mục đích của nó hoàn toàn ngược lại - cố gắng trừu tượng hóa khỏi mô hình dữ liệu được sử dụng, để đảm bảo hoạt động nhất quán với dữ liệu trong các mô hình, giao dịch khác nhau, v.v.

DBMS đa mô hình “không có mô hình chính”

Ngoài ra còn có các DBMS trên thị trường tự định vị mình là đa mô hình ban đầu, không có bất kỳ mô hình chính kế thừa nào. Bao gồm các ArangoDB, Phương Đông (kể từ năm 2018, công ty phát triển thuộc về SAP) và CosmosDB (dịch vụ như một phần của nền tảng đám mây Microsoft Azure).

Trên thực tế, có những mô hình “cốt lõi” trong ArangoDB và OrientDB. Trong cả hai trường hợp, đây là các mô hình dữ liệu của riêng chúng, là những khái quát hóa của tài liệu. Việc khái quát hóa chủ yếu nhằm tạo điều kiện thuận lợi cho khả năng thực hiện các truy vấn của biểu đồ và tính chất quan hệ.

Những mô hình này là những mô hình duy nhất có sẵn để sử dụng trong DBMS được chỉ định; ngôn ngữ truy vấn riêng của chúng được thiết kế để hoạt động với chúng. Tất nhiên, các mô hình và DBMS như vậy đầy hứa hẹn, nhưng việc thiếu khả năng tương thích với các mô hình và ngôn ngữ tiêu chuẩn khiến không thể sử dụng các DBMS này trong các hệ thống cũ—để thay thế các DBMS đã được sử dụng ở đó.

Đã có một bài viết tuyệt vời về ArangoDB và OrientDB trên Habré: THAM GIA cơ sở dữ liệu NoSQL.

ArangoDB

ArangoDB yêu cầu hỗ trợ cho mô hình dữ liệu đồ thị.

Các nút của biểu đồ trong ArangoDB là các tài liệu thông thường và các cạnh là các tài liệu thuộc loại đặc biệt, cùng với các trường hệ thống thông thường, có (_key, _id, _rev) trường hệ thống _from и _to. Các tài liệu trong DBMS tài liệu thường được kết hợp thành các bộ sưu tập. Bộ sưu tập tài liệu biểu thị các cạnh được gọi là bộ sưu tập cạnh trong ArangoDB. Nhân tiện, tài liệu thu thập cạnh cũng là tài liệu, vì vậy các cạnh trong ArangoDB cũng có thể hoạt động như các nút.

Dữ liệu thô

Hãy để chúng tôi có một bộ sưu tập persons, có tài liệu trông như thế này:

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

Hãy để có một bộ sưu tập cafes:

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

Sau đó bộ sưu tập likes có thể trông như thế này:

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

Truy vấn và kết quả

Một truy vấn kiểu đồ thị bằng ngôn ngữ AQL được sử dụng trong ArangoDB, trả về thông tin ở dạng người có thể đọc được về ai thích quán cà phê nào, trông như thế này:

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

Theo kiểu quan hệ, trong đó chúng ta đang "tính toán" các mối quan hệ thay vì lưu trữ chúng, truy vấn này có thể được viết lại như thế này (nhân tiện, không cần tập hợp likes có thể làm mà không cần):

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 }

Kết quả trong cả hai trường hợp sẽ giống nhau:

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

Nhiều truy vấn và kết quả hơn

Nếu định dạng kết quả ở trên có vẻ điển hình cho DBMS quan hệ hơn là cho DBMS tài liệu, bạn có thể thử truy vấn này (hoặc bạn có thể sử dụng COLLECT):

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

Kết quả sẽ như thế này:

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

Phương Đông

Cơ sở để triển khai mô hình đồ thị trên mô hình tài liệu trong OrientDB là cơ hội Các trường tài liệu, ngoài các giá trị vô hướng tiêu chuẩn ít nhiều còn có các giá trị thuộc loại như LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. Giá trị của các loại này là liên kết hoặc tập hợp các liên kết tới số nhận dạng hệ thống các tài liệu.

Mã định danh tài liệu do hệ thống chỉ định có “ý nghĩa vật lý”, cho biết vị trí của bản ghi trong cơ sở dữ liệu và trông giống như sau: @rid : #3:16. Do đó, giá trị của thuộc tính tham chiếu thực chất là con trỏ (như trong mô hình đồ thị) chứ không phải là điều kiện lựa chọn (như trong mô hình quan hệ).

Giống như ArangoDB, các cạnh trong OrientDB được biểu diễn dưới dạng các tài liệu riêng biệt (mặc dù nếu một cạnh không có thuộc tính riêng thì nó có thể được tạo nhẹvà nó sẽ không tương ứng với một tài liệu riêng biệt).

Dữ liệu thô

Ở dạng gần định dạng kết xuất Cơ sở dữ liệu OrientDB, dữ liệu từ ví dụ trước cho ArangoDB sẽ trông giống như sau:

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

Như chúng ta có thể thấy, các đỉnh cũng lưu trữ thông tin về các cạnh vào và ra. Tại sử dụng API Tài liệu phải tự giám sát tính toàn vẹn tham chiếu và API Đồ thị đảm nhận công việc này. Nhưng hãy xem quyền truy cập vào OrientDB trông như thế nào trong các ngôn ngữ truy vấn “thuần túy” không được tích hợp vào các ngôn ngữ lập trình.

Truy vấn và kết quả

Một truy vấn có mục đích tương tự như truy vấn trong ví dụ về ArangoDB trong OrientDB trông như sau:

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

Kết quả sẽ thu được dưới dạng sau:

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

Nếu định dạng kết quả lại có vẻ quá “quan hệ”, bạn cần xóa dòng bằng UNWIND():

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

Ngôn ngữ truy vấn của OrientDB có thể được mô tả dưới dạng SQL với các phần chèn giống Gremlin. Trong phiên bản 2.2, một biểu mẫu yêu cầu giống Cypher đã xuất hiện, 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

Định dạng kết quả sẽ giống như trong yêu cầu trước đó. Hãy suy nghĩ về những gì cần phải loại bỏ để làm cho nó trở nên “quan hệ” hơn, giống như trong truy vấn đầu tiên.

Azure CosmosDB

Ở mức độ thấp hơn, những gì đã nói ở trên về ArangoDB và OrientDB áp dụng cho Azure CosmosDB. CosmosDB cung cấp các API truy cập dữ liệu sau: SQL, MongoDB, Gremlin và Cassandra.

API SQL và API MongoDB được sử dụng để truy cập dữ liệu trong mô hình tài liệu. API Gremlin và API Cassandra - để truy cập dữ liệu ở định dạng biểu đồ và cột tương ứng. Dữ liệu trong tất cả các mô hình được lưu ở định dạng mô hình nội bộ CosmosDB: ARS (“chuỗi bản ghi nguyên tử”), cũng gần với tài liệu.

Tuy nhiên, mô hình dữ liệu do người dùng chọn và API được sử dụng sẽ cố định tại thời điểm tạo tài khoản trong dịch vụ. Không thể truy cập dữ liệu được tải trong một mô hình ở định dạng của mô hình khác, như được minh họa bằng nội dung như sau:

Do đó, đa mô hình trong Azure CosmosDB ngày nay chỉ có khả năng sử dụng một số cơ sở dữ liệu hỗ trợ các mô hình khác nhau từ một nhà sản xuất, điều này không giải quyết được tất cả các vấn đề về lưu trữ nhiều biến thể.

DBMS đa mô hình dựa trên mô hình đồ thị?

Đáng chú ý là thực tế là chưa có DBMS đa mô hình nào trên thị trường dựa trên mô hình đồ thị (ngoại trừ hỗ trợ đa mô hình cho hai mô hình đồ thị đồng thời: RDF và LPG; xem phần này trong xuất bản trước). Những khó khăn lớn nhất là do việc triển khai mô hình tài liệu trên mô hình đồ thị, thay vì mô hình quan hệ.

Câu hỏi về cách triển khai một mô hình quan hệ trên mô hình đồ thị đã được xem xét ngay cả trong quá trình hình thành mô hình sau. Làm sao đã nói, ví dụ, David McGovern:

Không có gì cố hữu trong cách tiếp cận biểu đồ ngăn cản việc tạo một lớp (ví dụ: bằng cách lập chỉ mục phù hợp) trên cơ sở dữ liệu biểu đồ cho phép chế độ xem quan hệ với (1) khôi phục các bộ dữ liệu từ các cặp giá trị khóa thông thường và (2) nhóm các bộ dữ liệu theo loại quan hệ.

Khi triển khai mô hình tài liệu trên mô hình đồ thị, bạn cần lưu ý những điều sau:

Các phần tử của mảng JSON được coi là có thứ tự, nhưng những phần tử xuất phát từ đỉnh của một cạnh của biểu đồ thì không;
Dữ liệu trong mô hình tài liệu thường không được chuẩn hóa; bạn vẫn không muốn lưu trữ nhiều bản sao của cùng một tài liệu được nhúng và các tài liệu phụ thường không có mã nhận dạng;
Mặt khác, hệ tư tưởng của DBMS tài liệu là các tài liệu là những “tập hợp” được tạo sẵn và không cần phải xây dựng lại mỗi lần. Cần phải cung cấp cho mô hình biểu đồ khả năng nhanh chóng có được biểu đồ con tương ứng với tài liệu đã hoàn thành.

Một chút quảng cáo

Tác giả của bài viết có liên quan đến sự phát triển của NitrosBase DBMS, mô hình bên trong là biểu đồ và các mô hình bên ngoài - quan hệ và tài liệu - là các biểu diễn của nó. Tất cả các mô hình đều như nhau: hầu hết mọi dữ liệu đều có sẵn trong bất kỳ mô hình nào bằng cách sử dụng ngôn ngữ truy vấn tự nhiên. Hơn nữa, ở bất kỳ chế độ xem nào, dữ liệu đều có thể được thay đổi. Những thay đổi sẽ được phản ánh trong mô hình nội bộ và theo đó, trong các chế độ xem khác.

Tôi hy vọng sẽ mô tả việc so khớp mô hình trông như thế nào trong NitrosBase ở một trong các bài viết sau.

Kết luận

Tôi hy vọng rằng những nét phác thảo chung về cái được gọi là đa mô hình hóa đã ít nhiều trở nên rõ ràng đối với người đọc. Các DBMS đa mô hình khá khác nhau và “hỗ trợ đa mô hình” có thể trông khác nhau. Để hiểu cái được gọi là "đa mô hình" trong từng trường hợp cụ thể, sẽ rất hữu ích khi trả lời các câu hỏi sau:

Chúng ta đang nói về việc hỗ trợ các mô hình truyền thống hay một loại mô hình “lai” nào đó?
Các mô hình có “bằng nhau” hay một trong số chúng là chủ đề của những mô hình khác?
Các người mẫu có “thờ ơ” với nhau không? Dữ liệu được ghi trong một mô hình có thể được đọc trong một mô hình khác hoặc thậm chí bị ghi đè không?

Tôi nghĩ rằng câu hỏi về mức độ liên quan của DBMS đa mô hình đã có thể được trả lời một cách tích cực, nhưng câu hỏi thú vị là loại nào trong số chúng sẽ có nhu cầu nhiều hơn trong tương lai gần. Có vẻ như các DBMS đa mô hình hỗ trợ các mô hình truyền thống, chủ yếu là quan hệ, sẽ có nhu cầu lớn hơn; Sự phổ biến của các DBMS đa mô hình, đưa ra các mô hình mới kết hợp các ưu điểm của nhiều mô hình truyền thống khác nhau, là một vấn đề của tương lai xa hơn.

Chỉ những người dùng đã đăng ký mới có thể tham gia khảo sát. Đăng nhập, xin vui lòng.

Bạn có sử dụng DBMS đa mô hình không?

Chúng tôi không sử dụng nó, chúng tôi lưu trữ mọi thứ trong một DBMS và trong một mô hình
Chúng tôi sử dụng khả năng đa mô hình của DBMS truyền thống
Chúng tôi thực hành sự kiên trì đa ngôn ngữ
Chúng tôi sử dụng DBMS đa mô hình mới (Arango, Orient, CosmosDB)

19 người dùng bình chọn. 4 người dùng bỏ phiếu trắng.

Nguồn: www.habr.com