ระบบสารสนเทศสมัยใหม่ค่อนข้างซับซ้อน ไม่น้อยไปกว่านั้น ความซับซ้อนนั้นเกิดจากความซับซ้อนของข้อมูลที่ประมวลผลในนั้น ความซับซ้อนของข้อมูลมักขึ้นอยู่กับแบบจำลองข้อมูลที่หลากหลายที่ใช้ ตัวอย่างเช่น เมื่อข้อมูลกลายเป็น "ขนาดใหญ่" ลักษณะปัญหาประการหนึ่งไม่ใช่แค่ปริมาณ ("ปริมาตร") เท่านั้น แต่ยังรวมถึงความหลากหลายของข้อมูล ("ความหลากหลาย") ด้วย
หากคุณยังไม่พบข้อบกพร่องในการให้เหตุผล โปรดอ่านต่อ
ความเพียรที่พูดได้หลายภาษา
ข้างต้นนำไปสู่ความจริงที่ว่าบางครั้งแม้จะอยู่ในกรอบของระบบเดียวก็จำเป็นต้องใช้ DBMS ที่แตกต่างกันหลายตัวในการจัดเก็บข้อมูลและแก้ไขปัญหาต่าง ๆ ในการประมวลผลซึ่งแต่ละอันรองรับแบบจำลองข้อมูลของตัวเอง ด้วยมืออันบางเบาของเอ็ม.ฟาวเลอร์
Fowler ยังมีตัวอย่างต่อไปนี้ของการจัดระเบียบพื้นที่จัดเก็บข้อมูลในแอปพลิเคชันที่มีคุณสมบัติครบถ้วนและมีภาระงานสูงในด้านอีคอมเมิร์ซ
แน่นอนว่าตัวอย่างนี้ค่อนข้างเกินจริง แต่สามารถพบข้อควรพิจารณาบางประการในการเลือก DBMS หนึ่งรายการหรืออื่นเพื่อวัตถุประสงค์ที่เกี่ยวข้องได้เช่น
เห็นได้ชัดว่าการเป็นคนรับใช้ในสวนสัตว์แห่งนี้ไม่ใช่เรื่องง่าย
- จำนวนโค้ดที่ดำเนินการจัดเก็บข้อมูลจะเพิ่มขึ้นตามสัดส่วนของจำนวน DBMS ที่ใช้ จำนวนข้อมูลการซิงโครไนซ์โค้ดจะดีหากไม่ได้สัดส่วนกับกำลังสองของตัวเลขนี้
- เมื่อคูณจำนวน DBMS ที่ใช้ ค่าใช้จ่ายในการจัดเตรียมคุณลักษณะขององค์กร (ความสามารถในการปรับขนาด ความทนทานต่อข้อผิดพลาด ความพร้อมใช้งานสูง) ของ DBMS แต่ละตัวที่ใช้ก็เพิ่มขึ้น
- เป็นไปไม่ได้ที่จะรับประกันคุณลักษณะระดับองค์กรของระบบย่อยการจัดเก็บข้อมูลโดยรวม โดยเฉพาะอย่างยิ่งการทำธุรกรรม
จากมุมมองของผู้อำนวยการสวนสัตว์ ทุกอย่างจะเป็นดังนี้:
- ต้นทุนใบอนุญาตและการสนับสนุนด้านเทคนิคเพิ่มขึ้นหลายเท่าจากผู้ผลิต DBMS
- การเพิ่มจำนวนพนักงานและเพิ่มกำหนดเวลา
- การสูญเสียทางการเงินหรือการลงโทษโดยตรงเนื่องจากข้อมูลไม่สอดคล้องกัน
ต้นทุนรวมในการเป็นเจ้าของ (TCO) ของระบบเพิ่มขึ้นอย่างมาก มีวิธีใดบ้างที่จะออกจากสถานการณ์ของ "ตัวเลือกการจัดเก็บข้อมูลที่หลากหลาย"?
หลายรุ่น
คำว่า "พื้นที่เก็บข้อมูลหลายตัวแปร" ถูกนำมาใช้ในปี 2011 การตระหนักถึงปัญหาของแนวทางดังกล่าวและการค้นหาวิธีแก้ไขใช้เวลาหลายปี และภายในปี 2015 จากปากของนักวิเคราะห์ของ Gartner คำตอบก็ได้รับการกำหนดขึ้น:
- จาก "
คู่มือการตลาดสำหรับ NoSQL DBMS - 2015 ":
อนาคตของ DBMS สถาปัตยกรรม และวิธีการใช้งานมีหลายรุ่น
- จาก "
Magic Quadrant สำหรับ ODBMS - 2016 ":
DBMS การดำเนินงานชั้นนำจะนำเสนอโมเดลหลายรูปแบบ ทั้งแบบเชิงสัมพันธ์และไม่เชิงสัมพันธ์ โดยเป็นส่วนหนึ่งของแพลตฟอร์มเดียว
ดูเหมือนว่าคราวนี้นักวิเคราะห์ของ Gartner จะถูกต้องกับการคาดการณ์ของพวกเขา หากเข้าเพจด้วย
ตารางด้านล่างแสดง 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
สุดท้ายนี้ 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
ด้วยการรองรับโมเดลกราฟ (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
DBMS หลายรุ่น "ไม่มีโมเดลหลัก"
นอกจากนี้ยังมี DBMS ในตลาดที่วางตำแหน่งตัวเองเป็นโมเดลหลายรุ่นตั้งแต่แรก โดยไม่มีโมเดลหลักที่สืบทอดมา เหล่านี้ได้แก่
ในความเป็นจริง มีโมเดล "หลัก" ใน ArangoDB และ OrientDB ในทั้งสองกรณี สิ่งเหล่านี้คือแบบจำลองข้อมูลของตนเอง ซึ่งเป็นลักษณะทั่วไปของเอกสาร ลักษณะทั่วไปมีไว้เพื่ออำนวยความสะดวกในการสืบค้นกราฟและลักษณะเชิงสัมพันธ์เป็นหลัก
โมเดลเหล่านี้เป็นโมเดลเดียวที่พร้อมใช้งานใน DBMS ที่ระบุ ภาษาคิวรีของตัวเองได้รับการออกแบบให้ใช้งานได้ แน่นอนว่าโมเดลและ DBMS ดังกล่าวมีแนวโน้มดี แต่การขาดความเข้ากันได้กับโมเดลและภาษามาตรฐาน ทำให้ไม่สามารถใช้ DBMS เหล่านี้ในระบบเดิมได้ เพื่อแทนที่ DBMS ที่ใช้อยู่แล้วในนั้น
มีบทความที่ยอดเยี่ยมเกี่ยวกับ ArangoDB และ OrientDB บนHabréอยู่แล้ว:
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 จะไม่มีคุณสมบัติเป็นของตัวเอง แต่ก็สามารถทำได้
ข้อมูลดิบ
ในรูปแบบที่ใกล้เคียงกัน
[
{
"@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"
}
]
ดังที่เราเห็น จุดยอดยังเก็บข้อมูลเกี่ยวกับขอบขาเข้าและขาออกด้วย ที่
แบบสอบถามและผลลัพธ์
แบบสอบถามที่คล้ายกับแบบสอบถามจากตัวอย่างสำหรับ 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:
แต่โมเดลข้อมูลที่ผู้ใช้เลือกและ 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 รายงดออกเสียง
ที่มา: will.com