ระบบสารสนเทศสมัยใหม่ค่อนข้างซับซ้อน ไม่น้อยไปกว่านั้น ความซับซ้อนนั้นเกิดจากความซับซ้อนของข้อมูลที่ประมวลผลในนั้น ความซับซ้อนของข้อมูลมักขึ้นอยู่กับแบบจำลองข้อมูลที่หลากหลายที่ใช้ ตัวอย่างเช่น เมื่อข้อมูลกลายเป็น "ขนาดใหญ่" ลักษณะปัญหาประการหนึ่งไม่ใช่แค่ปริมาณ ("ปริมาตร") เท่านั้น แต่ยังรวมถึงความหลากหลายของข้อมูล ("ความหลากหลาย") ด้วย

หากคุณยังไม่พบข้อบกพร่องในการให้เหตุผล โปรดอ่านต่อ

Содержание

ความเพียรที่พูดได้หลายภาษา
หลายรุ่น
DBMS หลายโมเดลตามโมเดลเชิงสัมพันธ์
     แบบจำลองเอกสารใน MS SQL Server
     โมเดลกราฟใน MS SQL Server
DBMS หลายรุ่นตามโมเดลเอกสาร
     โมเดลเชิงสัมพันธ์ใน MarkLogic
     โมเดลกราฟใน MarkLogic
DBMS หลายรุ่น "ไม่มีโมเดลหลัก"
     ArangoDB
     OrientDB
     อาซัวร์ คอสมอสดีบี
DBMS หลายรุ่นใช้แบบจำลองกราฟหรือไม่
ข้อสรุป
Опрос

ความเพียรที่พูดได้หลายภาษา

ข้างต้นนำไปสู่ความจริงที่ว่าบางครั้งแม้จะอยู่ในกรอบของระบบเดียวก็จำเป็นต้องใช้ DBMS ที่แตกต่างกันหลายตัวในการจัดเก็บข้อมูลและแก้ไขปัญหาต่าง ๆ ในการประมวลผลซึ่งแต่ละอันรองรับแบบจำลองข้อมูลของตัวเอง ด้วยมืออันบางเบาของเอ็ม.ฟาวเลอร์ นักบิน หนังสือชื่อดังหลายเล่มและหนึ่งในนั้น ผู้เขียนร่วม Agile Manifesto สถานการณ์นี้เรียกว่า พื้นที่เก็บข้อมูลหลายรูปแบบ (“การคงอยู่ของการพูดได้หลายภาษา”)

Fowler ยังมีตัวอย่างต่อไปนี้ของการจัดระเบียบพื้นที่จัดเก็บข้อมูลในแอปพลิเคชันที่มีคุณสมบัติครบถ้วนและมีภาระงานสูงในด้านอีคอมเมิร์ซ

แน่นอนว่าตัวอย่างนี้ค่อนข้างเกินจริง แต่สามารถพบข้อควรพิจารณาบางประการในการเลือก DBMS หนึ่งรายการหรืออื่นเพื่อวัตถุประสงค์ที่เกี่ยวข้องได้เช่น ที่นี่.

เห็นได้ชัดว่าการเป็นคนรับใช้ในสวนสัตว์แห่งนี้ไม่ใช่เรื่องง่าย

จำนวนโค้ดที่ดำเนินการจัดเก็บข้อมูลจะเพิ่มขึ้นตามสัดส่วนของจำนวน DBMS ที่ใช้ จำนวนข้อมูลการซิงโครไนซ์โค้ดจะดีหากไม่ได้สัดส่วนกับกำลังสองของตัวเลขนี้
เมื่อคูณจำนวน DBMS ที่ใช้ ค่าใช้จ่ายในการจัดเตรียมคุณลักษณะขององค์กร (ความสามารถในการปรับขนาด ความทนทานต่อข้อผิดพลาด ความพร้อมใช้งานสูง) ของ DBMS แต่ละตัวที่ใช้ก็เพิ่มขึ้น
เป็นไปไม่ได้ที่จะรับประกันคุณลักษณะระดับองค์กรของระบบย่อยการจัดเก็บข้อมูลโดยรวม โดยเฉพาะอย่างยิ่งการทำธุรกรรม

จากมุมมองของผู้อำนวยการสวนสัตว์ ทุกอย่างจะเป็นดังนี้:

ต้นทุนใบอนุญาตและการสนับสนุนด้านเทคนิคเพิ่มขึ้นหลายเท่าจากผู้ผลิต DBMS
การเพิ่มจำนวนพนักงานและเพิ่มกำหนดเวลา
การสูญเสียทางการเงินหรือการลงโทษโดยตรงเนื่องจากข้อมูลไม่สอดคล้องกัน

ต้นทุนรวมในการเป็นเจ้าของ (TCO) ของระบบเพิ่มขึ้นอย่างมาก มีวิธีใดบ้างที่จะออกจากสถานการณ์ของ "ตัวเลือกการจัดเก็บข้อมูลที่หลากหลาย"?

หลายรุ่น

คำว่า "พื้นที่เก็บข้อมูลหลายตัวแปร" ถูกนำมาใช้ในปี 2011 การตระหนักถึงปัญหาของแนวทางดังกล่าวและการค้นหาวิธีแก้ไขใช้เวลาหลายปี และภายในปี 2015 จากปากของนักวิเคราะห์ของ Gartner คำตอบก็ได้รับการกำหนดขึ้น:

จาก "คู่มือการตลาดสำหรับ NoSQL DBMS - 2015":
อนาคตของ DBMS สถาปัตยกรรม และวิธีการใช้งานมีหลายรุ่น
จาก "Magic Quadrant สำหรับ ODBMS - 2016":
DBMS การดำเนินงานชั้นนำจะนำเสนอโมเดลหลายรูปแบบ ทั้งแบบเชิงสัมพันธ์และไม่เชิงสัมพันธ์ โดยเป็นส่วนหนึ่งของแพลตฟอร์มเดียว

ดูเหมือนว่าคราวนี้นักวิเคราะห์ของ Gartner จะถูกต้องกับการคาดการณ์ของพวกเขา หากเข้าเพจด้วย คะแนนหลัก DBMS บน DB-Engines คุณจะเห็นได้ว่าоผู้นำส่วนใหญ่วางตำแหน่งตนเองเป็น DBMS หลายรุ่นโดยเฉพาะ เดียวกันนี้สามารถเห็นได้บนเพจที่มีการให้คะแนนส่วนตัว

ตารางด้านล่างแสดง DBMS - ผู้นำในการจัดอันดับส่วนตัวแต่ละรายการ ซึ่งอ้างว่าเป็นแบบหลายรุ่น สำหรับแต่ละ DBMS จะมีการระบุรุ่นดั้งเดิมที่รองรับ (ซึ่งครั้งหนึ่งเคยเป็นรุ่นเดียว) และรุ่นที่รองรับในปัจจุบันด้วย นอกจากนี้ ยังมีรายการ DBMS ที่วางตำแหน่งตัวเองเป็น "แต่เดิมมีหลายโมเดล" และผู้สร้างระบุว่าไม่มีโมเดลที่สืบทอดมาแต่แรก

DBMS	รุ่นเริ่มต้น	รุ่นเพิ่มเติม
คำพยากรณ์	เชิงสัมพันธ์	กราฟเอกสาร
MSSQL	เชิงสัมพันธ์	กราฟเอกสาร
PostgreSQL	เชิงสัมพันธ์	กราฟ* เอกสาร
มาร์คลอจิก	สารคดี	กราฟเชิงสัมพันธ์
MongoDB	สารคดี	คีย์-ค่า กราฟ*
ดาต้าสแตกซ์	คอลัมน์กว้าง	สารคดีกราฟ
Redis	คีย์-ค่า	สารคดี กราฟ*
ArangoDB	-	กราฟเอกสาร
OrientDB	-	กราฟ เอกสาร เชิงสัมพันธ์
อาซัวร์ คอสมอสดีบี	-	กราฟ เอกสาร เชิงสัมพันธ์

หมายเหตุบนโต๊ะ

เครื่องหมายดอกจันในคำสั่งเครื่องหมายตารางที่ต้องจอง:

PostgreSQL DBMS ไม่รองรับโมเดลข้อมูลกราฟ แต่ผลิตภัณฑ์นี้รองรับ ขึ้นอยู่กับมันเช่น AgensGraph
สำหรับ MongoDB นั้นถูกต้องมากกว่าที่จะพูดถึงการมีอยู่ของตัวดำเนินการกราฟในภาษาคิวรี ($lookup, $graphLookup) มากกว่าการสนับสนุนโมเดลกราฟ แม้ว่าแน่นอนว่า การแนะนำจำเป็นต้องมีการปรับให้เหมาะสมในระดับพื้นที่จัดเก็บข้อมูลทางกายภาพในทิศทางของการรองรับโมเดลกราฟ
ในส่วนที่เกี่ยวข้องกับ Redis เราหมายถึงส่วนขยาย RedisGraph.

ต่อไป สำหรับแต่ละคลาส เราจะแสดงให้เห็นว่าการสนับสนุนสำหรับหลายรุ่นถูกนำไปใช้ใน DBMS จากคลาสนี้อย่างไร เราจะพิจารณาแบบจำลองเชิงสัมพันธ์ เอกสาร และกราฟว่ามีความสำคัญที่สุด และใช้ตัวอย่างของ DBMS เฉพาะเพื่อแสดงให้เห็นว่า "ส่วนที่หายไป" ถูกนำไปใช้อย่างไร

DBMS หลายโมเดลตามโมเดลเชิงสัมพันธ์

DBMS ชั้นนำในปัจจุบันมีความสัมพันธ์กัน การคาดการณ์ของ Gartner ไม่สามารถถือเป็นจริงได้หาก RDBMS ไม่แสดงการเคลื่อนไหวไปในทิศทางของการสร้างแบบจำลองหลายตัว และพวกเขาแสดงให้เห็น ตอนนี้ แนวคิดที่ว่า DBMS หลายรุ่นก็เหมือนกับมีดสวิสที่ไม่สามารถทำอะไรได้ดีนัก สามารถส่งตรงไปยังแลร์รี เอลลิสันได้โดยตรง

อย่างไรก็ตามผู้เขียนชอบการใช้งานการสร้างแบบจำลองหลายตัวใน Microsoft SQL Server โดยจะอธิบายตัวอย่างที่รองรับ RDBMS สำหรับโมเดลเอกสารและกราฟ

แบบจำลองเอกสารใน MS SQL Server

มีบทความที่ยอดเยี่ยมสองบทความเกี่ยวกับHabréเกี่ยวกับวิธีที่ 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 หลายรุ่นตามโมเดลเอกสาร

ในส่วนนี้ ฉันอยากจะอธิบายการใช้งาน multi-model ในเอกสาร DBMS โดยใช้ตัวอย่างของ MongoDB ที่ไม่ได้รับความนิยมมากที่สุด (อย่างที่บอกไปแล้วว่ามีเพียงตัวดำเนินการกราฟแบบมีเงื่อนไขเท่านั้น $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>

คุณสามารถระบุกราฟ RDF ที่เป็นผลลัพธ์ได้ด้วยการสืบค้น SPARQL:

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

ไม่เหมือนกับแบบจำลองเชิงสัมพันธ์ MarkLogic สนับสนุนโมเดลกราฟด้วยวิธีอื่นสองวิธี:

DBMS สามารถเป็นที่จัดเก็บข้อมูล RDF แยกต่างหากเต็มรูปแบบ (จะเรียกว่าแฝดสามในนั้น) การจัดการ ตรงกันข้ามกับที่อธิบายไว้ข้างต้น สกัด).
RDF ในการทำให้เป็นอนุกรมแบบพิเศษสามารถแทรกลงในเอกสาร XML หรือ JSON ได้ (จากนั้นแฝดสามจะถูกเรียก) ไม่มีการจัดการ). นี่อาจเป็นอีกทางเลือกหนึ่งของกลไก idref เป็นต้น

ความคิดที่ดีเกี่ยวกับวิธีการทำงานของ MarkLogic ใน MarkLogic ออปติคัล APIในแง่นี้ มันเป็นระดับต่ำ แม้ว่าจุดประสงค์จะค่อนข้างตรงกันข้าม - เพื่อพยายามนามธรรมจากแบบจำลองข้อมูลที่ใช้ เพื่อให้แน่ใจว่าการทำงานสอดคล้องกับข้อมูลในรูปแบบที่แตกต่างกัน การทำธุรกรรม ฯลฯ

DBMS หลายรุ่น "ไม่มีโมเดลหลัก"

นอกจากนี้ยังมี DBMS ในตลาดที่วางตำแหน่งตัวเองเป็นโมเดลหลายรุ่นตั้งแต่แรก โดยไม่มีโมเดลหลักที่สืบทอดมา เหล่านี้ได้แก่ ArangoDB, OrientDB (ตั้งแต่ปี 2018 บริษัทพัฒนาเป็นของ SAP) และ คอสมอสดีบี (บริการเป็นส่วนหนึ่งของแพลตฟอร์มคลาวด์ Microsoft Azure)

ในความเป็นจริง มีโมเดล "หลัก" ใน ArangoDB และ OrientDB ในทั้งสองกรณี สิ่งเหล่านี้คือแบบจำลองข้อมูลของตนเอง ซึ่งเป็นลักษณะทั่วไปของเอกสาร ลักษณะทั่วไปมีไว้เพื่ออำนวยความสะดวกในการสืบค้นกราฟและลักษณะเชิงสัมพันธ์เป็นหลัก

โมเดลเหล่านี้เป็นโมเดลเดียวที่พร้อมใช้งานใน DBMS ที่ระบุ ภาษาคิวรีของตัวเองได้รับการออกแบบให้ใช้งานได้ แน่นอนว่าโมเดลและ DBMS ดังกล่าวมีแนวโน้มดี แต่การขาดความเข้ากันได้กับโมเดลและภาษามาตรฐาน ทำให้ไม่สามารถใช้ DBMS เหล่านี้ในระบบเดิมได้ เพื่อแทนที่ DBMS ที่ใช้อยู่แล้วในนั้น

มีบทความที่ยอดเยี่ยมเกี่ยวกับ ArangoDB และ OrientDB บนHabréอยู่แล้ว: เข้าร่วมในฐานข้อมูล NoSQL.

ArangoDB

ArangoDB อ้างว่ารองรับโมเดลข้อมูลกราฟ

โหนดของกราฟใน ArangoDB เป็นเอกสารธรรมดา และขอบเป็นเอกสารประเภทพิเศษที่มี (พร้อมกับฟิลด์ระบบปกติ)_key, _id, _rev) ฟิลด์ระบบ _from и _to. เอกสารใน DBMS ของเอกสารจะรวมกันเป็นคอลเลกชันแบบดั้งเดิม คอลเลกชันของเอกสารที่เป็นตัวแทนของ Edge เรียกว่าคอลเลกชัน Edge ใน ArangoDB อย่างไรก็ตาม เอกสารการรวบรวม Edge ก็เป็นเอกสารเช่นกัน ดังนั้น Edge ใน 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 จะแสดงเป็นเอกสารแยกกัน (แม้ว่า 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 มีลักษณะอย่างไรในภาษาคิวรี "บริสุทธิ์" ที่ไม่ได้รวมเข้ากับภาษาการเขียนโปรแกรม

แบบสอบถามและผลลัพธ์

แบบสอบถามที่คล้ายกับแบบสอบถามจากตัวอย่างสำหรับ 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

รูปแบบผลลัพธ์จะเหมือนกับคำขอก่อนหน้า ลองนึกถึงสิ่งที่จำเป็นต้องลบออกเพื่อทำให้ "สัมพันธ์กัน" มากขึ้น เช่น ในข้อความค้นหาแรกสุด

อาซัวร์ คอสมอสดีบี

ในระดับที่น้อยกว่า สิ่งที่กล่าวไว้ข้างต้นเกี่ยวกับ ArangoDB และ OrientDB จะนำไปใช้กับ Azure CosmosDB CosmosDB จัดเตรียม API การเข้าถึงข้อมูลต่อไปนี้: SQL, MongoDB, Gremlin และ Cassandra

SQL API และ MongoDB API ใช้เพื่อเข้าถึงข้อมูลในรูปแบบเอกสาร Gremlin API และ Cassandra API - สำหรับการเข้าถึงข้อมูลในรูปแบบกราฟและคอลัมน์ตามลำดับ ข้อมูลในทุกรุ่นจะถูกบันทึกในรูปแบบโมเดลภายใน CosmosDB: ARS (“atom-record-sequence”) ซึ่งอยู่ใกล้กับเอกสารเช่นกัน

แต่โมเดลข้อมูลที่ผู้ใช้เลือกและ API ที่ใช้ได้รับการแก้ไขในขณะที่สร้างบัญชีในบริการ ไม่สามารถเข้าถึงข้อมูลที่โหลดในโมเดลหนึ่งในรูปแบบอื่นได้ ดังตัวอย่างต่อไปนี้:

ดังนั้น ปัจจุบัน Azure CosmosDB หลายรุ่นจึงเป็นเพียงความสามารถในการใช้ฐานข้อมูลหลายตัวที่รองรับโมเดลที่แตกต่างจากผู้ผลิตรายเดียว ซึ่งไม่สามารถแก้ปัญหาทั้งหมดของพื้นที่จัดเก็บข้อมูลหลายตัวแปรได้

DBMS หลายรุ่นใช้แบบจำลองกราฟหรือไม่

ที่น่าสังเกตคือความจริงที่ว่ายังไม่มี DBMS หลายรุ่นในตลาดที่อิงตามโมเดลกราฟ (ยกเว้นการสนับสนุนหลายโมเดลสำหรับสองโมเดลกราฟพร้อมกัน: RDF และ LPG ดูสิ่งนี้ใน สิ่งพิมพ์ก่อนหน้า). ปัญหาที่ยิ่งใหญ่ที่สุดเกิดจากการนำโมเดลเอกสารไปใช้กับโมเดลกราฟ แทนที่จะเป็นโมเดลเชิงสัมพันธ์

คำถามเกี่ยวกับวิธีการนำแบบจำลองเชิงสัมพันธ์ไปใช้กับแบบจำลองกราฟนั้นได้รับการพิจารณาแม้กระทั่งในระหว่างการก่อตัวของแบบจำลองหลัง ยังไง กล่าวว่ายกตัวอย่างเช่น เดวิด แมคโกเวิร์น:

ไม่มีสิ่งใดที่มีอยู่ในแนวทางกราฟที่ป้องกันการสร้างเลเยอร์ (เช่น โดยการจัดทำดัชนีที่เหมาะสม) บนฐานข้อมูลกราฟที่เปิดใช้งานมุมมองเชิงสัมพันธ์ด้วย (1) การกู้คืนสิ่งอันดับจากคู่ค่าคีย์ปกติและ (2) การจัดกลุ่มของ สิ่งอันดับตามประเภทความสัมพันธ์

เมื่อใช้โมเดลเอกสารร่วมกับโมเดลกราฟ คุณต้องคำนึงถึงสิ่งต่อไปนี้:

องค์ประกอบของอาร์เรย์ JSON นั้นถือว่ามีลำดับ แต่องค์ประกอบที่เล็ดลอดออกมาจากจุดยอดของขอบของกราฟนั้นไม่ได้เป็นเช่นนั้น
ข้อมูลในโมเดลเอกสารมักจะถูกทำให้เป็นปกติ คุณยังไม่ต้องการเก็บสำเนาของเอกสารที่ฝังตัวเดียวกันหลายสำเนา และโดยปกติแล้วเอกสารย่อยจะไม่มีตัวระบุ
ในทางกลับกัน อุดมการณ์ของเอกสาร DBMS คือเอกสารเป็น "มวลรวม" สำเร็จรูปที่ไม่จำเป็นต้องสร้างใหม่ทุกครั้ง จำเป็นต้องจัดเตรียมแบบจำลองกราฟที่มีความสามารถในการรับกราฟย่อยที่สอดคล้องกับเอกสารที่เสร็จสมบูรณ์อย่างรวดเร็ว

โฆษณาสักหน่อย

ผู้เขียนบทความเกี่ยวข้องกับการพัฒนา NitrosBase DBMS ซึ่งเป็นแบบจำลองภายในซึ่งเป็นกราฟ และแบบจำลองภายนอก - เชิงสัมพันธ์และเอกสาร - เป็นตัวแทน โมเดลทั้งหมดเท่าเทียมกัน: ข้อมูลเกือบทั้งหมดมีอยู่ในรุ่นใดรุ่นหนึ่งโดยใช้ภาษาคิวรีที่เป็นธรรมชาติ ยิ่งไปกว่านั้น ในทุกมุมมอง ข้อมูลก็สามารถเปลี่ยนแปลงได้ การเปลี่ยนแปลงจะสะท้อนให้เห็นในโมเดลภายในและในมุมมองอื่นๆ ตามนั้น

ฉันหวังว่าจะอธิบายว่าการจับคู่โมเดลใน NitrosBase เป็นอย่างไรในบทความใดบทความหนึ่งต่อไปนี้

ข้อสรุป

ฉันหวังว่าโครงร่างทั่วไปของสิ่งที่เรียกว่าการสร้างแบบจำลองหลายรูปแบบจะมีความชัดเจนสำหรับผู้อ่านไม่มากก็น้อย DBMS หลายรุ่นมีความแตกต่างกันมาก และ “การรองรับหลายรุ่น” อาจดูแตกต่างออกไป เพื่อให้เข้าใจถึงสิ่งที่เรียกว่า "หลายรุ่น" ในแต่ละกรณี จะเป็นประโยชน์ในการตอบคำถามต่อไปนี้:

เรากำลังพูดถึงการสนับสนุนรุ่นดั้งเดิมหรือรุ่น "ไฮบริด" บางประเภทหรือไม่?
โมเดลต่างๆ “เท่าเทียมกัน” หรือเป็นหนึ่งในนั้นที่เป็นเรื่องของรุ่นอื่นๆ หรือไม่?
โมเดล "ไม่แยแส" ซึ่งกันและกันหรือไม่? ข้อมูลที่เขียนในรูปแบบหนึ่งสามารถอ่านในอีกรูปแบบหนึ่งหรือเขียนทับได้หรือไม่?

ฉันคิดว่าคำถามเกี่ยวกับความเกี่ยวข้องของ DBMS หลายรุ่นสามารถตอบได้ในเชิงบวกแล้ว แต่คำถามที่น่าสนใจคือประเภทใดจะเป็นที่ต้องการมากขึ้นในอนาคตอันใกล้นี้ ดูเหมือนว่า DBMS หลายโมเดลที่รองรับโมเดลแบบดั้งเดิม ซึ่งเน้นเชิงสัมพันธ์เป็นหลัก จะเป็นที่ต้องการมากขึ้น ความนิยมของ DBMS หลายรุ่นที่นำเสนอโมเดลใหม่ที่รวมข้อดีของโมเดลดั้งเดิมต่างๆ เข้าด้วยกัน เป็นเรื่องของอนาคตอันไกลโพ้น

เฉพาะผู้ใช้ที่ลงทะเบียนเท่านั้นที่สามารถเข้าร่วมในการสำรวจได้ เข้าสู่ระบบ, โปรด.