RDF хадгалах санд одоо юу болж байна вэ?

Семаль вэб болон холбосон өгөгдөл нь сансар огторгуйтай адил: тэнд амьдрал байхгүй. Тэнд удаан хугацаагаар явахын тулд... Тэд хүүхэд байхдаа “Би сансрын нисгэгч болмоор байна” гэсэн хариуд юу гэж хэлснийг мэдэхгүй. Гэхдээ та дэлхий дээр юу болж байгааг ажиглаж болно; Сонирхогч одон орон судлаач эсвэл бүр мэргэжлийн хүн болох нь илүү хялбар байдаг.

Нийтлэл нь сүүлийн үеийн, хэдэн сараас илүүгүй, RDF хадгалалтын ертөнцийн чиг хандлагуудад анхаарлаа хандуулах болно. Эхний догол мөрөнд байгаа зүйрлэл нь захын доорх баатарлаг хэмжээтэй сурталчилгааны зургаас санаа авсан болно.


Эпик зураг

RDF хадгалах санд одоо юу болж байна вэ?

I. RDF хандалтад зориулсан GraphQL

Тэд хэлэхдээGraphQL нь бүх нийтийн мэдээллийн санд нэвтрэх хэл болох зорилготой. GraphQL ашиглан RDF-д хандах боломжийн талаар юу хэлэх вэ?

Энэхүү боломжийг дараах байдлаар олгож байна.

Хэрэв репозитор ийм боломжийг олгохгүй бол зохих "шийдвэрлэгч" бичиж бие даан хэрэгжүүлж болно. Жишээлбэл, Францын төсөл дээр тэд ийм зүйл хийсэн DataTourisme. Эсвэл та юу ч бичихээ больж, зүгээр л ав HyperGraphQL.

Семаль вэб ба холбосон өгөгдлийн үнэн алдартны үзэл баримтлалаас харахад энэ бүхэн харамсалтай нь мэдээжийн хэрэг, дараагийн өгөгдлийн сило дээр баригдсан интеграцчлалд зориулагдсан мэт санагдахаас гадна тохирох платформууд биш юм (Мэдээж RDF дэлгүүрүүд) .

GraphQL-ийг SPARQL-тэй харьцуулсан сэтгэгдэл хоёр талтай.

  • Нэг талаараа, GraphQL нь SPARQL-ийн алс холын хамаатан мэт харагддаг: энэ нь REST-ийн хувьд ердийн асуултуудын түүвэрлэлт, олон тооны асуултуудыг шийддэг - үүнгүйгээр үүнийг авч үзэх боломжгүй юм. асуулгын хэл, наад зах нь вэб;
  • Нөгөө талаас, GraphQL-ийн хатуу схем нь сэтгэл дундуур байна. Иймээс түүний "дотоод харах чадвар" нь RDF-ийн бүрэн рефлекстэй харьцуулахад маш хязгаарлагдмал юм шиг санагддаг. Мөн өмчийн замын аналог байхгүй тул яагаад "График" болох нь тодорхойгүй байна.

II. MongoDB-д зориулсан адаптерууд

Өмнөх чиг хандлагатай нэмэлт.

  • Одоо Stardog-д магадгүй - ялангуяа бүгд ижил GraphQL дээр - MongoDB-ийн өгөгдлийг виртуал RDF графикт буулгах тохиргоог хийх;
  • Ontotext GraphDB саяхан бий болсон Энэ нь олгодог MongoDB Query дээр SPARQL руу фрагмент оруулах.

Хэрэв бид эдгээр эх сурвалжуудад хадгалагдсан JSON-г RDF хэлбэрээр илэрхийлэх боломжийг олгодог JSON эх сурвалжийн адаптеруудын талаар илүү өргөн хүрээтэй ярих юм бол бид нэлээд удаан хугацаанд хадгалагдаж ирсэн JSON-г эргэн санах болно. SPARQL үүсгэхтохируулах боломжтой, Жишээ нь, Апачи Жена руу.

Эхний хоёр чиг хандлагыг нэгтгэн дүгнэвэл RDF-ийн агуулахууд нь "полиглотын тууштай байдал" -ын нөхцөлд нэгтгэх, ажиллахад бүрэн бэлэн байгааг харуулж байна гэж хэлж болно. Гэсэн хэдий ч энэ нь удаан хугацааны туршид моодноос гарч, солигдож байгаа нь мэдэгдэж байна ирж байна олон загвар. RDF хадгалах ертөнцөд олон загварчлалын талаар юу хэлэх вэ?

Товчхондоо бол ямар ч боломжгүй. Би олон загварт DBMS-ийн сэдэвт тусдаа өгүүллийг зориулахыг хүсч байна, гэхдээ одоогоор график загвар дээр суурилсан олон загварт DBMS байхгүй байгааг тэмдэглэж болно (RDF-ийг түүний төрөл гэж үзэж болно) . Зарим жижиг олон загварчлал - өөр LPG график загварт зориулсан RDF хадгалалтын дэмжлэг - энэ хэсэгт хэлэлцэх болно V хэсэг.

III. OLTP vs. OLAP

Гэсэн хэдий ч ижил Gartner Тэр бичдэгЭнэ олон загвар нь үндсэндээ зайлшгүй шаардлагатай нөхцөл юм мэс заслын өрөөнүүд DBMS. Энэ нь ойлгомжтой: "олон хувилбарт хадгалах" нөхцөлд гүйлгээ хийх гол асуудал үүсдэг.

Гэхдээ OLTP-OLAP масштабын RDF хадгалалтууд хаана байрладаг вэ? Би ингэж хариулна: тэнд ч, энд ч үгүй. Тэдгээр нь юунд зориулагдсан болохыг харуулахын тулд гурав дахь товчлол хэрэгтэй. Сонголт болгон би санал болгож байна OLIP - Онлайн оюуны боловсруулалт.

Гэсэн хэдий ч:

  • GraphDB-д хэрэгжсэн MongoDB-тэй нэгтгэх механизмууд нь багагүй юм зорилготой гүйцэтгэлийн асуудлуудыг бичих;
  • Stardog бүр цаашлаад бүрэн дүүрэн явдаг дахин бичдэг хөдөлгүүр, дахин бичлэгийн гүйцэтгэлийг сайжруулах зорилготой.

Одоо би зах зээлд шинэ тоглогч танилцуулъя. IBM Netezza болон Amazon Redshift-ийн бүтээгчдээс - AnzoGraph™. Түүнд суурилсан бүтээгдэхүүний сурталчилгааны зургийг нийтлэлийн эхэнд байрлуулсан. AnzoGraph нь өөрийгөө GOLAP шийдэл гэж үздэг. Цонхны функцтэй SPARQL танд хэр таалагдаж байна вэ? -

SELECT ?month (COUNT(?event) OVER (PARTITION BY ?month) AS ?events) WHERE {  …  }

IV. RocksDB

Аль хэдийн өндөр холбоос байсан Stardog 7 Beta-ийн зарлал дээр Stardog нь RocksDB-ийг үндсэн хадгалалтын систем буюу Google-ийн LevelDB-ийн Facebook-ийн сэрээ болох түлхүүрийн үнэ цэнийг хадгалах систем болгон ашиглах гэж байна. Яагаад тодорхой чиг хандлагын талаар ярих нь зүйтэй вэ?

Нэгдүгээрт, дүгнэж үзвэл Википедийн нийтлэл, зөвхөн RDF-ийн агуулахуудыг RocksDB-д "шилжүүлээгүй". RocksDB-г ArangoDB, MongoDB, MySQL болон MariaDB, Cassandra дээр хадгалах хөдөлгүүр болгон ашиглах төслүүд бий.

Хоёрдугаарт, RocksDB дээр холбогдох сэдвээр төслүүдийг (бүтээгдэхүүн биш) бүтээдэг.

Жишээлбэл, eBay нь RocksDB-г ашигладаг платформ Таны "мэдлэгийн график"-ийн хувьд. Дашрамд хэлэхэд, уншихад инээдтэй юм: Асуулгын хэл нь гэрийн форматаар эхэлсэн боловч сүүлийн үед SPARQL-тэй илүү төстэй болж шилжиж байна.. Хошигнол дээрх шиг: бид хичнээн их мэдлэгийн график хийсэн ч гэсэн бид RDF-тэй хэвээр байна.

Өөр нэг жишээ - хэдэн сарын өмнө гарч ирсэн Wikidata History Query Service. Үүнийг танилцуулахаас өмнө Викидатагийн түүхэн мэдээлэлд хандах шаардлагатай байсан MWAPI стандарт Mediawiki API руу. Одоо цэвэр SPARQL-ээр их зүйл боломжтой болсон. "Нүцгэн дор" бас RocksDB байдаг. Дашрамд хэлэхэд, WDHQS-ийг Freebase-г Google Knowledge Graph руу оруулсан хүн хийсэн бололтой.

V. LPG-ийн дэмжлэг

LPG график ба RDF графикийн гол ялгааг танд сануулъя.

LPG-д скаляр шинж чанаруудыг ирмэгийн тохиолдлуудад оноож болдог бол RDF-д тэдгээрийг зөвхөн ирмэгийн "төрөл"-д (гэхдээ зөвхөн скаляр шинж чанарууд биш, бас энгийн холболтуудад) оноож болно. LPG-тэй харьцуулахад RDF-ийн энэ хязгаарлалт даван туулах нэг буюу өөр загварчлалын техник. RDF-тэй харьцуулахад LPG-ийн хязгаарлалтыг даван туулахад илүү хэцүү байдаг ч LPG графикууд нь RDF графикаас илүү Харарийн сурах бичгийн зургуудтай төстэй байдаг тул хүмүүс үүнийг хүсдэг.

Мэдээжийн хэрэг, "LPG дэмжих" ажил нь хоёр хэсэгт хуваагдана.

  1. RDF загварт LPG-ийн бүтцийг дуурайх боломжтой өөрчлөлт хийх;
  2. Энэхүү өөрчлөгдсөн загварт өгөгдөлд хандах боломжтой 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 түвшинд шийддэг. Ийм шийдвэр нь зохих хэсэгт оруулахыг шаарддаг Стандарт. Хавсаргах үр дагаврыг дэмждэг RDF дэлгүүрүүдэд зарим өөрчлөлтүүд шаардлагатай байж болох ч одоогоор Singleton Property-ийг загварчлалын өөр нэг арга гэж үзэж болно.

V.1.2. Тохижилт зөв хийгдсэн

Бага гэнэн хандлагууд нь өмчийн тохиолдлуудыг гурвалсан байдлаар бүрэн гүйцэд хийх боломжтой гэдгийг ухаарсанаас үүдэлтэй. Гурван ихэр хүүхдийн талаар ямар нэг зүйл хэлэх боломжтой бол бид өмчийн тохиолдлын талаар ярих боломжтой болно.

Эдгээр аргуудаас хамгийн найдвартай нь RDF*, өөрөөр хэлбэл RDR, төрсөн Блазеграфын гүнд. Энэ бол анхнаасаа л сонгогдсон өөртөө болон AnzoGraph-д зориулсан. Арга барилын хатуу байдал нь түүний хүрээнд байгаагаар тодорхойлогддог санал болгож байна холбогдох өөрчлөлтүүд RDF семантик. Гэсэн хэдий ч гол зүйл бол маш энгийн. RDF-ийн яст мэлхийн цуваа дээр та одоо иймэрхүү зүйлийг бичиж болно:

<<:bob :isMarriedTo :alice>> :since "2013-09-13"^^xsd:date .

V.1.3. Бусад хандлага

Та албан ёсны семантикийн талаар санаа зовох хэрэггүй, гэхдээ зүгээр л гурвалсанууд нь тодорхой тодорхойлогчтой, мэдээжийн хэрэг URI-ууд бөгөөд эдгээр URI-уудаар шинэ гурвалсануудыг үүсгэдэг гэж төсөөлөөд үз дээ. Үлдсэн зүйл бол SPARQL дээрх эдгээр URI-д хандах боломжийг олгох явдал юм. Тэгэхээр ирдэг Оддын нохой.

Аллегрограф дээр явлаа завсрын аргаар. Аллегрограф дахь гурвалсан тодорхойлогч гэдгийг мэддэг байна, гэхдээ гурвалсан шинж чанаруудыг хэрэгжүүлэхэд тэдгээр нь наалддаггүй. Гэсэн хэдий ч энэ нь албан ёсны семантикаас маш хол хэвээр байна. Гурвалсан шинж чанарууд нь URI биш бөгөөд эдгээр шинж чанаруудын утга нь зөвхөн шууд утгаараа байж болох нь анхаарал татаж байна. LPG-ийг дэмжигчид яг хүссэн зүйлээ авдаг. Тусгайлан зохион бүтээсэн NQX форматын хувьд RDF*-ийн дээрхтэй төстэй жишээ дараах байдалтай байна.

: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

сэтгэгдэл нэмэх