Семаль вэб болон холбосон өгөгдөл нь сансар огторгуйтай адил: тэнд амьдрал байхгүй. Тэнд удаан хугацаагаар явахын тулд... Тэд хүүхэд байхдаа “Би сансрын нисгэгч болмоор байна” гэсэн хариуд юу гэж хэлснийг мэдэхгүй. Гэхдээ та дэлхий дээр юу болж байгааг ажиглаж болно; Сонирхогч одон орон судлаач эсвэл бүр мэргэжлийн хүн болох нь илүү хялбар байдаг.
Нийтлэл нь сүүлийн үеийн, хэдэн сараас илүүгүй, RDF хадгалалтын ертөнцийн чиг хандлагуудад анхаарлаа хандуулах болно. Эхний догол мөрөнд байгаа зүйрлэл нь захын доорх баатарлаг хэмжээтэй сурталчилгааны зургаас санаа авсан болно.
I. RDF хандалтад зориулсан GraphQL
Энэхүү боломжийг дараах байдлаар олгож байна.
- Оддын нохой (
блог ,баримт бичиг ); - TopQuadrant бүтээгдэхүүн (
вэбинар ,баримт бичиг ).
Хэрэв репозитор ийм боломжийг олгохгүй бол зохих "шийдвэрлэгч" бичиж бие даан хэрэгжүүлж болно. Жишээлбэл, Францын төсөл дээр тэд ийм зүйл хийсэн
Семаль вэб ба холбосон өгөгдлийн үнэн алдартны үзэл баримтлалаас харахад энэ бүхэн харамсалтай нь мэдээжийн хэрэг, дараагийн өгөгдлийн сило дээр баригдсан интеграцчлалд зориулагдсан мэт санагдахаас гадна тохирох платформууд биш юм (Мэдээж RDF дэлгүүрүүд) .
GraphQL-ийг SPARQL-тэй харьцуулсан сэтгэгдэл хоёр талтай.
- Нэг талаараа, GraphQL нь SPARQL-ийн алс холын хамаатан мэт харагддаг: энэ нь REST-ийн хувьд ердийн асуултуудын түүвэрлэлт, олон тооны асуултуудыг шийддэг - үүнгүйгээр үүнийг авч үзэх боломжгүй юм. асуулгын хэл, наад зах нь вэб;
- Нөгөө талаас, GraphQL-ийн хатуу схем нь сэтгэл дундуур байна. Иймээс түүний "дотоод харах чадвар" нь RDF-ийн бүрэн рефлекстэй харьцуулахад маш хязгаарлагдмал юм шиг санагддаг. Мөн өмчийн замын аналог байхгүй тул яагаад "График" болох нь тодорхойгүй байна.
II. MongoDB-д зориулсан адаптерууд
Өмнөх чиг хандлагатай нэмэлт.
- Одоо Stardog-д
магадгүй - ялангуяа бүгд ижил GraphQL дээр - MongoDB-ийн өгөгдлийг виртуал RDF графикт буулгах тохиргоог хийх; - Ontotext GraphDB саяхан бий болсон
Энэ нь олгодог MongoDB Query дээр SPARQL руу фрагмент оруулах.
Хэрэв бид эдгээр эх сурвалжуудад хадгалагдсан JSON-г RDF хэлбэрээр илэрхийлэх боломжийг олгодог JSON эх сурвалжийн адаптеруудын талаар илүү өргөн хүрээтэй ярих юм бол бид нэлээд удаан хугацаанд хадгалагдаж ирсэн JSON-г эргэн санах болно.
Эхний хоёр чиг хандлагыг нэгтгэн дүгнэвэл RDF-ийн агуулахууд нь "полиглотын тууштай байдал" -ын нөхцөлд нэгтгэх, ажиллахад бүрэн бэлэн байгааг харуулж байна гэж хэлж болно. Гэсэн хэдий ч энэ нь удаан хугацааны туршид моодноос гарч, солигдож байгаа нь мэдэгдэж байна
Товчхондоо бол ямар ч боломжгүй. Би олон загварт DBMS-ийн сэдэвт тусдаа өгүүллийг зориулахыг хүсч байна, гэхдээ одоогоор график загвар дээр суурилсан олон загварт DBMS байхгүй байгааг тэмдэглэж болно (RDF-ийг түүний төрөл гэж үзэж болно) . Зарим жижиг олон загварчлал - өөр LPG график загварт зориулсан RDF хадгалалтын дэмжлэг - энэ хэсэгт хэлэлцэх болно
III. OLTP vs. OLAP
Гэсэн хэдий ч ижил Gartner
Гэхдээ OLTP-OLAP масштабын RDF хадгалалтууд хаана байрладаг вэ? Би ингэж хариулна: тэнд ч, энд ч үгүй. Тэдгээр нь юунд зориулагдсан болохыг харуулахын тулд гурав дахь товчлол хэрэгтэй. Сонголт болгон би санал болгож байна OLIP - Онлайн оюуны боловсруулалт.
Гэсэн хэдий ч:
- GraphDB-д хэрэгжсэн MongoDB-тэй нэгтгэх механизмууд нь багагүй юм
зорилготой гүйцэтгэлийн асуудлуудыг бичих; - Stardog бүр цаашлаад бүрэн дүүрэн явдаг
дахин бичдэг хөдөлгүүр, дахин бичлэгийн гүйцэтгэлийг сайжруулах зорилготой.
Одоо би зах зээлд шинэ тоглогч танилцуулъя. IBM Netezza болон Amazon Redshift-ийн бүтээгчдээс -
SELECT ?month (COUNT(?event) OVER (PARTITION BY ?month) AS ?events) WHERE { … }
IV. RocksDB
Аль хэдийн өндөр
Нэгдүгээрт, дүгнэж үзвэл
Хоёрдугаарт, RocksDB дээр холбогдох сэдвээр төслүүдийг (бүтээгдэхүүн биш) бүтээдэг.
Жишээлбэл, eBay нь RocksDB-г ашигладаг
Өөр нэг жишээ - хэдэн сарын өмнө гарч ирсэн
V. LPG-ийн дэмжлэг
LPG график ба RDF графикийн гол ялгааг танд сануулъя.
LPG-д скаляр шинж чанаруудыг ирмэгийн тохиолдлуудад оноож болдог бол RDF-д тэдгээрийг зөвхөн ирмэгийн "төрөл"-д (гэхдээ зөвхөн скаляр шинж чанарууд биш, бас энгийн холболтуудад) оноож болно. LPG-тэй харьцуулахад RDF-ийн энэ хязгаарлалт
Мэдээжийн хэрэг, "LPG дэмжих" ажил нь хоёр хэсэгт хуваагдана.
- RDF загварт LPG-ийн бүтцийг дуурайх боломжтой өөрчлөлт хийх;
- Энэхүү өөрчлөгдсөн загварт өгөгдөлд хандах боломжтой RDF асуулгын хэлэнд өөрчлөлт оруулах, эсвэл түгээмэл LPG асуулгын хэлээр энэ загварт асуулга хийх боломжийг хэрэгжүүлэх.
V.1. Өгөгдлийн загвар
Энд хэд хэдэн боломжит аргууд байдаг.
V.1.1. Singleton Property
RDF болон LPG-ийг уялдуулах хамгийн бодит арга нь магадгүй юм
- Жишээлбэл, угтвар үгийн оронд
:isMarriedTo
предикатуудыг ашигладаг:isMarriedTo1
,:isMarriedTo2
гэх мэт. - Дараа нь эдгээр предикатууд шинэ гурвалсан хүүхдийн субьект болно:
:isMarriedTo1 :since "2013-09-13"^^xsd:date
болон бусад. - Эдгээр предикатын тохиолдлуудын нийтлэг предикаттай холболтыг хэлбэрийн гурвалсан хэлбэрээр тогтоодог
:isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo
. - Мэдээжийн хэрэг
rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type
, гэхдээ яагаад зүгээр л бичиж болохгүй гэж бодож үзээрэй:isMarriedTo1 rdf:type :isMarriedTo
.
"LPG-ийн дэмжлэг" -ийн асуудлыг энд RDFS түвшинд шийддэг. Ийм шийдвэр нь зохих хэсэгт оруулахыг шаарддаг
V.1.2. Тохижилт зөв хийгдсэн
Бага гэнэн хандлагууд нь өмчийн тохиолдлуудыг гурвалсан байдлаар бүрэн гүйцэд хийх боломжтой гэдгийг ухаарсанаас үүдэлтэй. Гурван ихэр хүүхдийн талаар ямар нэг зүйл хэлэх боломжтой бол бид өмчийн тохиолдлын талаар ярих боломжтой болно.
Эдгээр аргуудаас хамгийн найдвартай нь
<<:bob :isMarriedTo :alice>> :since "2013-09-13"^^xsd:date .
V.1.3. Бусад хандлага
Та албан ёсны семантикийн талаар санаа зовох хэрэггүй, гэхдээ зүгээр л гурвалсанууд нь тодорхой тодорхойлогчтой, мэдээжийн хэрэг URI-ууд бөгөөд эдгээр URI-уудаар шинэ гурвалсануудыг үүсгэдэг гэж төсөөлөөд үз дээ. Үлдсэн зүйл бол SPARQL дээрх эдгээр URI-д хандах боломжийг олгох явдал юм. Тэгэхээр
Аллегрограф дээр
:bob :marriedTo :alice {"since" : "2013-09-13"}
V.2. Асуулгын хэлүүд
Загварын түвшинд LPG-ийг ямар нэг байдлаар дэмжсэний дараа та ийм загварт байгаа өгөгдөлд асуулга хийх боломжтой болгох хэрэгтэй.
- RDF* асуулгад зориулсан Blazegraph дэмждэг
SPARQL* иГремлин . SPARQL* асуулга дараах байдалтай байна.
SELECT * { <<:bob :isMarriedTo ?wife>> :since ?since }
- Анзограф бас дэмждэг
SPARQL* мөн дэмжих болноCypher , Neo4j дахь асуулгын хэл. - Stardog нь өөрөө дэмждэг
тэлэлт SPARQL болондахин Гремлин. Та SPARQL дээрх гурвалсан URI болон "мета-мэдээлэл"-ийг дараах байдлаар авч болно.
SELECT * {
BIND (stardog:identifier(:bob, :isMarriedTo, ?wife) AS ?id)
?id :since ?since
}
- Аллегрограф нь мөн өөрийн гэсэн дүгнэлтийг дэмждэг
тэлэлт SPARQL:
SELECT * { ("since" ?since) franz:attributesNameValue ( :bob :marriedTo ?wife ) }
Дашрамд дурдахад, GraphDB нэг удаа LPG-ийг дэмжихгүйгээр Tinkerpop/Gremlin-ийг дэмждэг байсан ч энэ нь 8.0 эсвэл 8.1 хувилбар дээр зогссон.
VI. Лицензийг чангатгах
"Гурван дэлгүүрийн сонголт" болон "нээлттэй эхийн гурвалсан дэлгүүр"-ийн уулзварт сүүлийн үед нэмэлт өөрчлөлт ороогүй байна. Шинэ нээлттэй эхийн RDF дэлгүүрүүд нь өдөр тутмын хэрэглээнд тохиромжтой сонголт байхаас хол зам бөгөөд миний ашиглахыг хүсч буй шинэ гурвалсан дэлгүүрүүд (AnzoGraph гэх мэт) хаалттай эх үүсвэр юм. Үүний оронд бид бууралтын талаар ярьж болно ...
Мэдээжийн хэрэг, өмнө нь нээлттэй эх сурвалжийг хаагаагүй ч зарим нээлттэй эхийн агуулахууд аажмаар сонгох шаардлагагүй болсон. Нээлттэй эхийн хувилбартай Virtuoso нь миний бодлоор алдаануудад живж байна. Blazegraph-ийг AWS худалдаж авсан бөгөөд Amazon Далай вангийн үндэс суурийг тавьсан; Одоо дор хаяж нэг хувилбар гарах эсэх нь тодорхойгүй байна. Зөвхөн Жена л үлдлээ...
Хэрэв нээлттэй эх сурвалж тийм ч чухал биш, гэхдээ та зүгээр л туршиж үзэхийг хүсч байвал бүх зүйл өмнөхөөсөө арай бага байна. Жишээлбэл:
- Оддын нохой
зогсдог үнэгүй хувилбарыг түгээх (гэхдээ ердийн хувилбарын туршилтын хугацаа хоёр дахин нэмэгдсэн); - в
GraphDB Cloud , Та өмнө нь үнэ төлбөргүй үндсэн багцыг сонгох боломжтой байсан бол шинэ хэрэглэгчийн бүртгэлийг түр зогсоосон.
Ерөнхийдөө МТ-ийн дундаж хүний хувьд орон зай улам бүр хүртээмжгүй болж, түүний хөгжил нь олон корпорациуд болж байна.
Эх сурвалж: www.habr.com