რა ხდება ახლა RDF საცავთან?

სემანტიკური ქსელი და დაკავშირებული მონაცემები გარე სივრცეს ჰგავს: იქ სიცოცხლე არ არის. იქ წასვლა მეტ-ნაკლებად დიდი ხნის განმავლობაში... არ ვიცი, რა გითხრეს ბავშვობაში „მინდა გავხდე ასტრონავტი“. მაგრამ თქვენ შეგიძლიათ დააკვირდეთ რა ხდება დედამიწაზე ყოფნისას; გაცილებით ადვილია გახდე მოყვარული ასტრონომი ან თუნდაც პროფესიონალი.

სტატია ყურადღებას გაამახვილებს ბოლო, არაუმეტეს რამდენიმე თვისა, ტენდენციებზე RDF შენახვის სამყაროდან. პირველ აბზაცში მოცემული მეტაფორა შთაგონებულია ეპიკური ზომის სარეკლამო იმიჯით ჭრილის ქვეშ.

ეპიკური სურათი

I. GraphQL RDF წვდომისთვის

Ისინი ამბობენრომ GraphQL მიზნად ისახავს გახდეს მონაცემთა ბაზაში წვდომის უნივერსალური ენა. რაც შეეხება RDF-ზე წვდომის შესაძლებლობას GraphQL-ის გამოყენებით?

ყუთიდან ეს შესაძლებლობა მოცემულია:

• ვარსკვლავური ძაღლი (წაკითხვა, დოკუმენტაცია);
• TopQuadrant პროდუქტები (webinar, დოკუმენტაცია).

თუ საცავი არ იძლევა ასეთ შესაძლებლობას, მისი დამოუკიდებლად განხორციელება შესაძლებელია შესაბამისი „გამხსნელის“ დაწერით. ასე გააკეთეს, მაგალითად, ფრანგულ პროექტში DataTourisme. ან ვეღარაფერს დაწერ, უბრალოდ აიღე HyperGraphQL.

სემანტიკური ვებსა და დაკავშირებული მონაცემების მართლმადიდებლური მიმდევრის თვალსაზრისით, ეს ყველაფერი, რა თქმა უნდა, სამწუხაროა, რადგან ის, როგორც ჩანს, შექმნილია შემდეგი მონაცემთა სილოს გარშემო აგებული ინტეგრაციისთვის და არა შესაფერისი პლატფორმებისთვის (RDF მაღაზიები, რა თქმა უნდა) .

GraphQL SPARQL-თან შედარების შთაბეჭდილებები ორმაგია.

• ერთის მხრივ, GraphQL ჰგავს SPARQL-ის შორეულ ნათესავს: ის წყვეტს REST-ისთვის დამახასიათებელ ხელახალი შერჩევისა და მრავალი მოთხოვნის პრობლემებს - რომლის გარეშეც, ალბათ, შეუძლებელი იქნებოდა განხილვა. შეკითხვის ენა, ყოველ შემთხვევაში ვებისთვის;
• მეორეს მხრივ, GraphQL-ის ხისტი სქემა იმედგაცრუებულია. შესაბამისად, მისი „ინტროსპექტიულობა“ ძალიან შეზღუდული ჩანს RDF-ის სრულ რეფლექსურობასთან შედარებით. და არ არსებობს საკუთრების ბილიკების ანალოგი, ასე რომ, არც კი არის ნათელი, რატომ არის ეს "გრაფიკი".

II. ადაპტერები MongoDB-სთვის

წინა ტენდენციას ავსებს.

• Stardog-ში ახლა ალბათ - კერძოდ, ყველა ერთსა და იმავე GraphQL-ზე - დააკონფიგურიროთ MongoDB მონაცემების რუკება ვირტუალურ RDF გრაფიკებში;
• Ontotext GraphDB ახლახანს საშუალებას აძლევს ჩადეთ ფრაგმენტები SPARQL-ში MongoDB Query-ზე.

თუ უფრო ფართოდ ვისაუბრებთ JSON წყაროების ადაპტერებზე, რომლებიც საშუალებას აძლევს მეტ-ნაკლებად „ფრენაში“ წარმოადგინონ ამ წყაროებში შენახული JSON, როგორც RDF, შეგვიძლია გავიხსენოთ საკმაოდ დიდი ხნის განმავლობაში. SPARQL გენერირება, რომელიც შეიძლება დარეგულირდეს, მაგალითად, აპაჩი იენას.

პირველი ორი ტენდენციის შეჯამებით, შეგვიძლია ვთქვათ, რომ RDF საცავები აჩვენებს სრულ მზადყოფნას ინტეგრაციისთვის და ფუნქციონირებისთვის „პოლიგლოტური მდგრადობის“ პირობებში. თუმცა ცნობილია, რომ ეს უკანასკნელი დიდი ხანია მოდიდან გავიდა და მისი ჩანაცვლება ხდება მოდის მრავალ მოდელი. რაც შეეხება მრავალმოდელირებას RDF შენახვის სამყაროში?

მოკლედ, არავითარ შემთხვევაში. მსურს ცალკე სტატია მივუძღვნა მრავალმოდელური DBMS-ების თემას, მაგრამ ამ დროისთვის შეიძლება აღინიშნოს, რომ ამჟამად არ არსებობს მრავალმოდელური DBMS-ები, რომლებიც „დაფუძნებულია“ გრაფიკულ მოდელზე (RDF შეიძლება ჩაითვალოს მის ტიპად). . რამდენიმე მცირე მრავალ მოდელირება - RDF შენახვის მხარდაჭერა ალტერნატიული LPG გრაფიკის მოდელისთვის - განხილული იქნება განყოფილება V.

III. OLTP vs. OLAP

თუმცა, იგივე Gartner წერსრომ მულტიმოდელი არის sine qua non პირობა, პირველ რიგში საოპერაციო ოთახები DBMS. ეს გასაგებია: "მრავალვარიატიული შენახვის" ვითარებაში, ძირითადი პრობლემები წარმოიქმნება ტრანზაქციულობასთან.

მაგრამ სად მდებარეობს RDF საცავები OLTP-OLAP მასშტაბით? მე ასე გიპასუხებდი: არც იქ და არც აქ. იმის მითითებისთვის, თუ რისთვის არის განკუთვნილი, საჭიროა მესამე აბრევიატურა. როგორც ვარიანტს მე შემოგთავაზებდი 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-ს მივაღწევთ.

კიდევ ერთი მაგალითი - ის, რომელიც რამდენიმე თვის წინ გამოჩნდა ვიკიმონაცემების ისტორიის შეკითხვის სერვისი. მის დანერგვამდე ვიკიმონაცემების ისტორიული ინფორმაცია უნდა ყოფილიყო წვდომა MWAPI სტანდარტულ Mediawiki API-ზე. ახლა ბევრი რამ არის შესაძლებელი სუფთა SPARQL-ით. "ქუდის ქვეშ" ასევე არის RocksDB. სხვათა შორის, WDHQS შეიქმნა, როგორც ჩანს, იმ პირის მიერ, ვინც შემოიტანა Freebase Google Knowledge Graph-ში.

V. LPG მხარდაჭერა

ნება მომეცით შეგახსენოთ მთავარი განსხვავება LPG გრაფიკებსა და RDF გრაფიკებს შორის.

LPG-ში სკალარული თვისებები შეიძლება მიენიჭოს კიდეების ინსტანციებს, ხოლო RDF-ში მათი მინიჭება შესაძლებელია მხოლოდ კიდეების „ტიპებზე“ (მაგრამ არა მხოლოდ სკალარული თვისებები, არამედ ჩვეულებრივი კავშირებიც). RDF-ის ეს შეზღუდვა LPG-თან შედარებით გადალახოს მოდელირების ამა თუ იმ ტექნიკას. LPG-ის შეზღუდვები RDF-თან შედარებით უფრო რთული დასაძლევია, მაგრამ LPG გრაფიკები უფრო ჰგავს ჰარარის სახელმძღვანელოს სურათებს, ვიდრე RDF გრაფიკებს, რის გამოც ადამიანებს სურთ ისინი.

ცხადია, "LPG მხარდაჭერის" ამოცანა ორ ნაწილად იყოფა:

1. RDF მოდელში ცვლილებების შეტანა, რაც შესაძლებელს ხდის მასში LPG სტრუქტურების სიმულაციას;
2. ცვლილებების შეტანა RDF შეკითხვის ენაში, რაც შესაძლებელს ხდის ამ შეცვლილ მოდელში მონაცემებზე წვდომას, ან ამ მოდელზე მოთხოვნების დაყენების შესაძლებლობის დანერგვა LPG-ის მოთხოვნის პოპულარულ ენებზე.

V.1. მონაცემთა მოდელი

აქ რამდენიმე შესაძლო მიდგომაა.

V.1.1. სინგლტონის ქონება

RDF და LPG ჰარმონიზაციის ყველაზე პირდაპირი მიდგომა ალბათ არის სინგტონის ქონება:

• მაგალითად, პრედიკატის ნაცვლად :isMarriedTo გამოიყენება პრედიკატები :isMarriedTo1, :isMarriedTo2 i t. დ.
• ეს პრედიკატები შემდეგ ხდება ახალი სამეულის საგნები: :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-ის Turtle სერიალიზაციაში ახლა შეგიძლიათ დაწეროთ მსგავსი რამ:

<<: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-ს მხარდაჭერით, თქვენ უნდა შეგეძლოთ ასეთ მოდელში მონაცემების შეკითხვის გაკეთება.

• Blazegraph RDF* მოთხოვნებისთვის მხარს უჭერს SPARQL* и გრემინი. SPARQL* შეკითხვა ასე გამოიყურება:

 SELECT * { <<:bob :isMarriedTo ?wife>> :since ?since }

• ანზოგრაფი ასევე მხარს უჭერს SPARQL* და აპირებს მხარდაჭერას Cypher, შეკითხვის ენა Neo4j-ში.
• Stardog მხარს უჭერს საკუთარ თავს გაფართოება SPARQL და ისევ გრემლინი. თქვენ შეგიძლიათ მიიღოთ ტრიპლეტი URI და „მეტა-ინფორმაცია“ SPARQL-ში მსგავსი რამის გამოყენებით:

SELECT * {
    BIND (stardog:identifier(:bob, :isMarriedTo, ?wife) AS ?id)
    ?id :since ?since
}

• ალეგროგრაფი ასევე მხარს უჭერს საკუთარს გაფართოება SPARQL:

 SELECT * { ("since" ?since)  franz:attributesNameValue  ( :bob :marriedTo ?wife ) }

სხვათა შორის, GraphDB ერთ დროს მხარს უჭერდა Tinkerpop/Gremlin-ს LPG-ის მხარდაჭერის გარეშე, მაგრამ ეს შეჩერდა 8.0 ან 8.1 ვერსიაში.

VI. ლიცენზიების გამკაცრება

ბოლო დროს არ ყოფილა დამატებები "triplestore of Choice" და "open source triplestore" კომპლექტების კვეთაზე. ახალი ღია კოდის RDF მაღაზიები შორს არის ყოველდღიური გამოყენებისთვის კარგი არჩევანისგან, ხოლო ახალი სამმაგი მაღაზიები, რომლებიც მსურს გამოვიყენო (როგორც AnzoGraph) არის დახურული წყარო. პირიქით, შეიძლება ვისაუბროთ შემცირებაზე...

რა თქმა უნდა, ღია წყარო არ იყო დახურული წარსულში, მაგრამ ზოგიერთი ღია კოდის საცავი ნელ-ნელა აღარ არის აღქმული, როგორც არჩევის ღირსი. Virtuoso, რომელსაც აქვს opensource გამოცემა, ჩემი აზრით, იხრჩობა ბაგებში. Blazegraph შეიძინა AWS-მა და შექმნა Amazon Neptune-ის საფუძველი; ახლა გაურკვეველია იქნება თუ არა კიდევ ერთი გამოშვება. დარჩა მხოლოდ იენა...

თუ ღია წყარო არ არის ძალიან მნიშვნელოვანი, მაგრამ თქვენ უბრალოდ გსურთ სცადოთ, მაშინ ყველაფერი ასევე ნაკლებად ვარდისფერია, ვიდრე ადრე. Მაგალითად:

• ვარსკვლავური ძაღლი აჩერებს გაავრცელეთ უფასო ვერსია (თუმცა, რეგულარული ვერსიის საცდელი პერიოდი გაორმაგდა);
• в GraphDB Cloud, სადაც ადრე შეგიძლიათ აირჩიოთ უფასო ძირითადი გეგმა, ახალი მომხმარებლის რეგისტრაცია შეჩერებულია.

ზოგადად, საშუალო IT ადამიანისთვის სივრცე სულ უფრო და უფრო მიუწვდომელი ხდება, მისი განვითარება ხდება კორპორაციების უამრავი ნაწილი.

წყარო: www.habr.com