Орчин үеийн мэдээллийн системүүд нэлээд төвөгтэй байдаг. Хамгийн багадаа тэдний нарийн төвөгтэй байдал нь тэдгээрт боловсруулсан өгөгдлийн нарийн төвөгтэй байдлаас шалтгаална. Өгөгдлийн нарийн төвөгтэй байдал нь ихэвчлэн ашигласан өгөгдлийн загваруудын олон янз байдалд оршдог. Жишээлбэл, өгөгдөл "том" болох үед асуудалтай шинж чанаруудын нэг нь түүний эзлэхүүн ("эзэлхүүн") төдийгүй олон янз байдал ("төрөл бүрийн") юм.
Хэрэв та үндэслэлийн алдааг хараахан олоогүй бол үргэлжлүүлэн уншина уу.
Агуулга
Полиглотын тууштай байдал
Дээрх нь заримдаа нэг системийн хүрээнд өгөгдөл хадгалах, тэдгээрийг боловсруулах янз бүрийн асуудлыг шийдвэрлэхийн тулд хэд хэдэн өөр DBMS ашиглах шаардлагатай болдог бөгөөд тус бүр нь өөрийн өгөгдлийн загварыг дэмждэг. М.Фаулерын хөнгөн гараар хэд хэдэн алдартай ном ба нэг Agile Manifesto, энэ нөхцөл байдал гэж нэрлэдэг олон хувилбарт хадгалалт (“полиглотын тууштай байдал”).
Фоулер цахим худалдааны салбарт бүрэн ажиллагаатай, ачаалал ихтэй программ дээр өгөгдөл хадгалах ажлыг зохион байгуулах дараах жишээг үзүүлэв.
Мэдээжийн хэрэг, энэ жишээ нь зарим талаараа хэтрүүлсэн боловч холбогдох зорилгоор нэг эсвэл өөр DBMS-ийг сонгоход чиглэсэн зарим санааг олж болно, жишээлбэл, .
Ийм амьтны хүрээлэнд үйлчлэгч байх амаргүй нь ойлгомжтой.
- Мэдээллийн хадгалалтыг гүйцэтгэдэг кодын хэмжээ нь ашигласан DBMS-ийн тоотой пропорциональ өсдөг; Кодын синхрончлолын өгөгдлийн хэмжээ нь энэ тооны квадраттай пропорциональ биш бол сайн байна.
- Ашигласан DBMS-ийн тооноос хэд дахин нэмэгдвэл ашигласан DBMS тус бүрийн аж ахуйн нэгжийн шинж чанарыг (хэмжих чадвар, алдааны тэсвэрлэлт, өндөр хүртээмж) хангах зардал нэмэгддэг.
- Хадгалах дэд системийн аж ахуйн нэгжийн шинж чанарыг, ялангуяа гүйлгээг бүхэлд нь хангах боломжгүй юм.
Амьтны хүрээлэнгийн даргын бодлоор бүх зүйл дараах байдалтай байна.
- DBMS үйлдвэрлэгчийн лиценз, техникийн дэмжлэгийн өртөг хэд дахин нэмэгдсэн.
- Ажилтныг хэтрүүлэн ажиллуулж, эцсийн хугацааг нэмэгдүүлсэн.
- Өгөгдлийн зөрүүгээс шууд санхүүгийн алдагдал эсвэл торгууль.
Системийн өмчлөлийн нийт зардал (TCO) мэдэгдэхүйц нэмэгдсэн байна. "Олон хадгалах сонголт" -оос гарах арга зам бий юу?
Олон загвартай
"Олон хувилбарт хадгалалт" гэсэн нэр томъёо 2011 онд хэрэглэгдэж эхэлсэн. Арга барилын асуудлуудыг мэдэж, шийдвэрлэх арга замыг эрэлхийлэх нь хэдэн жилийн турш үргэлжилсэн бөгөөд 2015 он гэхэд Gartner-ийн шинжээчдийн амаар хариултыг томъёолсон.
- "-аас"
DBMS-ийн ирээдүй, тэдгээрийн архитектур, тэдгээрийг ашиглах арга замууд нь олон загвартай байдаг.
- "-аас"
Тэргүүлэх үйл ажиллагааны DBMS нь нэг платформын нэг хэсэг болгон харилцааны болон хамааралгүй олон загварыг санал болгоно.
Энэ удаад Gartner-ын шинжээчид таамагласандаа зөв байсан бололтой. -тэй хуудас руу орвол DB-Engines дээрх DBMS, та үүнийг харж болнооИхэнх удирдагчид өөрсдийгөө олон загварт DBMS гэж тусгайлан тодорхойлдог. Үүнтэй ижил зүйлийг ямар ч хувийн үнэлгээтэй хуудсан дээрээс харж болно.
Доорх хүснэгтэд олон загвартай гэж үздэг хувийн үнэлгээ тус бүрийн тэргүүлэгч DBMS-ийг харуулав. DBMS бүрийн хувьд анхны дэмжигдсэн загвар (энэ нь цорын ганц байсан) болон үүнтэй хамт одоогоор дэмжигдсэн загваруудыг зааж өгсөн болно. Өөрсдийгөө "анх олон загвартай" гэж тодорхойлсон бөгөөд бүтээгчдийн үзэж байгаагаар анхны удамшлын загвар байхгүй DBMS-уудыг мөн жагсаасан болно.
| DBMS | Анхны загвар | Нэмэлт загварууд |
|---|---|---|
| Oracle-ийн | Харилцааны | График, баримт бичиг |
| MS SQL | Харилцааны | График, баримт бичиг |
| PostgreSQL | Харилцааны | График*, баримт бичиг |
| MarkLogic | Баримтат кино | График, хамаарал |
| МонгоБ | Баримтат кино | Түлхүүр утга, график* |
| DataStax | Өргөн багана | Баримтат кино, график |
| Redis | Түлхүүр утга | Баримтат кино, график* |
| ArangoDB | - | График, баримт бичиг |
| OrientDB | - | График, баримт бичиг, харилцаа холбоо |
| Azure CosmosDB | - | График, баримт бичиг, харилцаа холбоо |
Ширээн дээрх тэмдэглэл
Хүснэгт дэх одоор захиалга шаардлагатай мэдэгдлийг тэмдэглэнэ.
- PostgreSQL DBMS нь график өгөгдлийн загварыг дэмждэггүй ч энэ бүтээгдэхүүн нь үүнийг дэмждэг AgensGraph гэх мэт.
- MongoDB-тэй холбоотойгоор асуулгын хэлэнд график оператор байгаа талаар ярих нь илүү зөв юм (, ) график загварыг дэмжихээс илүүтэй, гэхдээ мэдээжийн хэрэг, тэдгээрийг нэвтрүүлэхэд график загварыг дэмжих чиглэлд физик хадгалах түвшинд зарим оновчлол хийх шаардлагатай байсан.
- Redis-тай холбоотойгоор бид өргөтгөлийг хэлнэ .
Дараа нь, анги тус бүрийн хувьд бид энэ ангийн DBMS-д хэд хэдэн загварт зориулсан дэмжлэг хэрхэн хэрэгжиж байгааг харуулах болно. Бид харилцаа холбоо, баримт бичиг, график загваруудыг хамгийн чухал гэж үзэж, тодорхой DBMS-ийн жишээн дээр "дутсан"-ыг хэрхэн хэрэгжүүлж байгааг харуулах болно.
Харилцааны загварт суурилсан олон загварт DBMS
Одоогийн байдлаар тэргүүлэгч DBMS-үүд нь харилцан хамааралтай байдаг; RDBMS нь олон загварчлалын чиглэлд хөдөлгөөнийг харуулаагүй бол Gartner-ийн таамаглал үнэн гэж үзэх боломжгүй юм. Мөн тэд харуулж байна. Одоо олон загварт DBMS нь юу ч хийж чадахгүй Швейцарийн хутга шиг гэсэн санааг Ларри Эллисон руу шууд чиглүүлж болно.
Зохиогч нь Microsoft SQL Server дээр олон загварчлалыг хэрэгжүүлэхийг илүүд үздэг бөгөөд үүний жишээн дээр баримт бичиг, график загварт зориулсан RDBMS дэмжлэгийг тайлбарлах болно.
MS SQL сервер дэх баримт бичгийн загвар
MS SQL Server нь баримт бичгийн загварт дэмжлэг үзүүлэх талаар Habré-ийн талаар хоёр гайхалтай нийтлэл аль хэдийн гарсан; Би товч тайлбар, тайлбараар хязгаарлагдах болно:
MS SQL Server дээрх баримт бичгийн загварыг дэмжих арга нь харилцааны DBMS-ийн хувьд нэлээд түгээмэл байдаг: JSON баримтуудыг энгийн текст талбарт хадгалахыг санал болгож байна. Баримт бичгийн загварт дэмжлэг үзүүлэх нь энэ JSON-г задлан шинжлэх тусгай операторуудыг хангах явдал юм:
- скаляр атрибутын утгыг гаргаж авах,
- дэд баримт бичгийг задлах.
Хоёр операторын хоёр дахь аргумент нь JSONPath-тэй төстэй синтакс дахь илэрхийлэл юм.
Товчхондоо, ийм байдлаар хадгалагдсан баримтууд нь tuple-ээс ялгаатай нь харилцааны DBMS-д "нэгдүгээр зэрэглэлийн нэгж" биш гэж хэлж болно. Тодруулбал, MS SQL Server дээр одоогоор JSON баримтын талбарууд дээр индекс байхгүй байгаа нь эдгээр талбаруудын утгыг ашиглан хүснэгтүүдийг нэгтгэх, тэр ч байтугай эдгээр утгыг ашиглан баримтыг сонгоход хэцүү болгодог. Гэхдээ ийм талбарт тооцоолсон багана, түүн дээр индекс үүсгэх боломжтой.
Нэмж дурдахад MS SQL Server нь оператор ашиглан хүснэгтийн агуулгаас JSON баримт бичгийг хялбархан бүтээх боломжийг олгодог. - тодорхой утгаараа өмнөхтэй харьцуулахад ердийн хадгалах боломж. RDBMS нь хичнээн хурдан байсан ч энэ арга нь түгээмэл асуултуудад бэлэн хариултуудыг хадгалдаг баримт бичгийн DBMS-ийн үзэл баримтлалтай зөрчилдөж байгаа нь тодорхой бөгөөд зөвхөн боловсруулахад хялбар асуудлыг шийдэж чаддаг, гэхдээ хурдтай биш юм.
Эцэст нь, MS SQL Server нь баримт бичгийн эсрэг талын асуудлыг шийдвэрлэх боломжийг танд олгоно: та JSON-г хүснэгт болгон задалж болно. . Хэрэв баримт бичиг нь бүрэн хавтгай биш бол та ашиглах хэрэгтэй болно CROSS APPLY.
MS SQL сервер дээрх график загвар
График (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>Та үүссэн RDF графикийг SPARQL асуулгаар шийдэж болно:
PREFIX : <http://example.org/example#>
SELECT ?name ?surname {
:631803299804 :name ?name ; :surname ?surname .
}Харилцааны загвараас ялгаатай нь MarkLogic график загварыг өөр хоёр аргаар дэмждэг:
- DBMS нь RDF мэдээллийн бүрэн хэмжээний тусдаа хадгалалт байж болно (үүнийг гурвалсан гэж нэрлэдэг дээр дурдсантай харьцуулахад ).
- Тусгай цуваачлал дахь RDF-ийг XML эсвэл JSON баримт бичигт оруулах боломжтой (мөн гурвалсан файлуудыг дараа нь дуудах болно. ). Энэ нь магадгүй механизмын өөр хувилбар юм
idrefболон бусад.
MarkLogic дээр бүх зүйл "үнэхээр" хэрхэн ажилладаг талаар сайн санааг өгсөн , энэ утгаараа энэ нь доод түвшнийх боловч зорилго нь эсрэгээрээ байдаг - ашигласан өгөгдлийн загвараас хийсвэрлэхийг оролдох, өөр өөр загвар дахь өгөгдөлтэй тууштай ажиллах, гүйлгээ хийх гэх мэт.
Олон загварт DBMS "үндсэн загваргүй"
Зах зээл дээр удамшлын үндсэн загваргүй, анхдагч олон загварт байрладаг DBMS-үүд байдаг. Үүнд: , (2018 оноос хойш хөгжүүлэлтийн компани нь SAP-д харьяалагддаг) ба (Microsoft Azure үүл платформын нэг хэсэг болох үйлчилгээ).
Үнэн хэрэгтээ ArangoDB болон OrientDB дээр "үндсэн" загварууд байдаг. Аль ч тохиолдолд эдгээр нь өөрсдийн өгөгдлийн загварууд бөгөөд энэ нь нэг баримт бичгийн ерөнхий дүгнэлт юм. Ерөнхий дүгнэлтүүд нь голчлон график болон харилцааны шинж чанартай асуултуудыг гүйцэтгэх чадварыг хөнгөвчлөхөд чиглэгддэг.
Эдгээр загварууд нь заасан DBMS-д ашиглах боломжтой цорын ганц загварууд бөгөөд өөрсдийн хүсэлтийн хэлүүд нь тэдэнтэй ажиллахад зориулагдсан болно. Мэдээжийн хэрэг, ийм загварууд болон DBMS нь ирээдүйтэй боловч стандарт загвар, хэлтэй нийцэхгүй байгаа нь эдгээр DBMS-ийг хуучин системд ашиглах боломжгүй болгож, тэнд аль хэдийн ашиглагдсан DBMS-ийг солих боломжийг олгодог.
Habré дээр ArangoDB болон OrientDB-ийн тухай гайхалтай нийтлэл аль хэдийн байсан: .
ArangoDB
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
}
]Асуулт ба үр дүн
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-д илүү энгийн мэт санагдаж байвал та энэ асуулгыг туршиж үзэж болно (эсвэл та ашиглаж болно). ):
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"
}
]Бидний харж байгаагаар оройнууд нь ирж буй болон гарч буй ирмэгүүдийн талаархи мэдээллийг хадгалдаг. At Document API нь лавлагааны бүрэн бүтэн байдлыг өөрөө хянах ёстой бөгөөд График 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": "Жан-Жак" }
]Хэрэв үр дүнгийн формат дахин хэтэрхий "харьцаатай" мэт санагдаж байвал та мөрийг арилгах хэрэгтэй :
[
{ "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
{ "person_name": "Боб", "cafe_name": [ "Жан-Жак" ' }
]OrientDB-ийн асуулгын хэлийг Gremlin шиг оруулгатай SQL гэж тодорхойлж болно. 2.2 хувилбарт Cypher-тэй төстэй хүсэлтийн маягт гарч ирэв. :
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 нь SQL, MongoDB, Gremlin болон Cassandra зэрэг өгөгдөлд хандах API-уудыг хангадаг.
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