Ի՞նչ է կատարվում այժմ RDF պահեստների հետ:

Սեմանտիկ ցանցը և կապակցված տվյալները նման են մոտակա տիեզերքին. այնտեղ կյանք չկա։ Այնտեղ գնալ ավելի կամ պակաս երկար ժամանակահատվածով… լավ, չգիտեմ, թե մանկության տարիներին ինչ էին ասում՝ ի պատասխան «Ես ուզում եմ տիեզերագնաց դառնալ» հարցին։ Բայց դուք կարող եք դիտարկել, թե ինչ է կատարվում Երկրի վրա լինելիս. շատ ավելի հեշտ է դառնալ սիրողական կամ նույնիսկ պրոֆեսիոնալ աստղագետ։

Հոդվածում կքննարկվեն RDF պահեստավորման աշխարհի թարմ, ոչ ավելի, քան մի քանի ամսվա միտումները: Առաջին պարբերության մեջ փոխաբերությունը ոգեշնչված է կտրվածքի տակ գտնվող էպիկական չափերի գովազդային պատկերից:

Էպիկական պատկեր

I. GraphQL RDF մուտքի համար

Ասում ենոր GraphQL-ը նպատակ ունի դառնալ տվյալների բազայի հասանելիության համընդհանուր լեզու: Ի՞նչ կասեք GraphQL-ի միջոցով RDF մուտք գործելու հնարավորության մասին:

Տուփից դուրս այս հնարավորությունը տրվում է.

• Աստղային շուն (Օրագիր, փաստաթղթերը);
• TopQuadrant արտադրանք (վեբինար, փաստաթղթերը).

Եթե ​​շտեմարանը նման հնարավորություն չի տալիս, ապա այն կարող է իրականացվել ինքնուրույն՝ գրելով համապատասխան «լուծիչ»։ Ահա թե ինչ արեցին, օրինակ, ֆրանսիական նախագծում DataTourisme. Կամ դուք այլևս ոչինչ չեք կարող գրել, այլ պարզապես վերցնել HyperGraphQL.

Իմաստային ցանցի և կապակցված տվյալների ուղղափառ հետևորդի տեսանկյունից այս ամենը, իհարկե, տխուր է, քանի որ այն կարծես թե նախատեսված է հաջորդ տվյալների սիլոսի շուրջ կառուցված ինտեգրումների և ոչ հարմար հարթակների համար (RDF խանութներ, իհարկե) .

GraphQL-ը SPARQL-ի հետ համեմատելուց տպավորությունները կրկնակի են:

• Մի կողմից, GraphQL-ը կարծես SPARQL-ի հեռավոր ազգականն է. այն լուծում է REST-ին բնորոշ կրկնօրինակման և բազմաթիվ հարցումների խնդիրները, առանց որոնց, հավանաբար, հնարավոր չէր լինի դիտարկել: հարցման լեզու, գոնե համացանցի համար;
• Մյուս կողմից, GraphQL-ի կոշտ սխեման հիասթափեցնող է: Համապատասխանաբար, նրա «ներհայեցողականությունը» շատ սահմանափակ է թվում՝ համեմատած RDF-ի ամբողջական ռեֆլեքսիվության հետ: Եվ սեփականության ուղիների անալոգը չկա, ուստի նույնիսկ պարզ չէ, թե ինչու է այն «Գրաֆիկ-»:

II. Adapters MongoDB-ի համար

Մի միտում, որը լրացնում է նախորդին:

• հիմա Stardog-ում գուցե - մասնավորապես, բոլորը նույն GraphQL-ի վրա - կարգավորել MongoDB տվյալների քարտեզագրումը վիրտուալ RDF գրաֆիկների մեջ.
• GraphDB-ն վերջերս թույլ է տալիս տեղադրեք հատվածներ SPARQL-ի մեջ MongoDB Query-ում:

Եթե ​​մենք ավելի լայնորեն խոսենք JSON աղբյուրների ադապտերների մասին, որոնք թույլ են տալիս քիչ թե շատ «թռիչքում» ներկայացնել այս աղբյուրներում պահվող JSON-ը որպես RDF, մենք կարող ենք հիշել բավականին երկար ժամանակ գոյություն ունեցող SPARQL Ստեղծեք, որը կարող է ճշգրտվել, օրինակ, Ապաչի Յենային։

Ամփոփելով առաջին երկու միտումները՝ կարելի է ասել, որ RDF պահեստները ցուցաբերում են ամբողջական պատրաստակամություն ինտեգրվելու և գործելու «պոլիգլոտի կայունության» պայմաններում։ Հայտնի է, սակայն, որ այս վերջինը վաղուց դուրս է եկել նորաձեւությունից և փոխարինվում է գալիս է բազմամոդել. Ինչ վերաբերում է բազմամոդելավորմանը RDF պահեստավորման աշխարհում:

Մի խոսքով, ոչ մի կերպ։ Ես կցանկանայի առանձին հոդված նվիրել բազմամոդելային DBMS-ների թեմային, բայց առայժմ կարելի է նշել, որ ներկայումս գրաֆիկական մոդելի վրա «հիմնված» բազմամոդել DBMS-ներ չկան (RDF-ն կարելի է համարել դրա տեսակը): . Որոշ փոքր բազմամոդելավորում՝ RDF պահեստավորման աջակցություն այլընտրանքային LPG գրաֆիկական մոդելի համար, կքննարկվեն այստեղ բաժին V.

III. OLTP ընդդեմ. OLAP

Այնուամենայնիվ, նույն Gartner գրումայդ մուլտիմոդելը հիմնականում սինուս qua non պայման է վիրահատարաններ DBMS. Սա հասկանալի է. «բազմաչափ պահեստավորման» իրավիճակում հիմնական խնդիրները առաջանում են գործարքների հետ:

Բայց որտեղ են գտնվում RDF պահեստները OLTP-OLAP սանդղակի վրա: Ես այսպես կպատասխանեի՝ ոչ այնտեղ, ոչ այստեղ։ Նշելու համար, թե ինչի համար են դրանք նախատեսված, անհրաժեշտ է երրորդ հապավումը։ Որպես տարբերակ ես կառաջարկեի ՕԼԻՊ — Առցանց ինտելեկտուալ մշակում:

Այնուամենայնիվ, դեռ.

• GraphDB-ում ներդրված MongoDB-ի հետ ինտեգրման մեխանիզմները ոչ պակաս կարևոր են նախատեսված են աշխատել գրելու կատարողական խնդիրների շուրջ;
• Stardog-ը գնում է նույնիսկ ավելի հեռու և ամբողջությամբ վերաշարադրում է շարժիչ՝ կրկին ձայնագրման կատարողականությունը բարելավելու նպատակով:

Հիմա թույլ տվեք ներկայացնել շուկայի նոր խաղացողի՝ IBM Netezza-ի և Amazon Redshift-ի ստեղծողներից։ ԱնզոԳրաֆ. Հոդվածի սկզբում տեղադրվել է դրա հիման վրա ստեղծված ապրանքի գովազդից նկար։ AnzoGraph-ը իրեն ներկայացնում է որպես GOLAP լուծում: Ինչպե՞ս է ձեզ դուր գալիս SPARQL-ը պատուհանի գործառույթներով: —

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

IV. RocksDB

Արդեն ավելի բարձր հղում կար Stardog 7 Beta-ի հայտարարությանը, որտեղ ասվում էր, որ Stardog-ը պատրաստվում է օգտագործել RocksDB-ն որպես հիմքում ընկած պահեստավորման համակարգ՝ առանցքային արժեքների խանութ, Google-ի LevelDB-ի Facebook-ի պատառաքաղ: Ինչու՞ արժե խոսել որոշակի միտումի մասին:

Նախ, դատելով Վիքիպեդիայի հոդված, RocksDB-ին «փոխպատվաստված» են ոչ միայն RDF պահեստները: Կան նախագծեր՝ 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 գրաֆիկներն ավելի շատ նման են Harari դասագրքի նկարների, քան RDF գրաֆիկների, այդ իսկ պատճառով մարդիկ ցանկանում են դրանք:

Ակնհայտ է, որ «LPG աջակցության» խնդիրը բաժանվում է երկու մասի.

1. RDF մոդելում փոփոխություններ կատարելը, որոնք հնարավորություն են տալիս մոդելավորել դրա մեջ LPG կառուցվածքները.
2. փոփոխություններ կատարել RDF հարցումների լեզվում, որոնք հնարավորություն են տալիս մուտք գործել տվյալներ այս փոփոխված մոդելում, կամ կիրառելով այս մոդելին հարցումներ կատարելու հնարավորությունը LPG հարցումների հանրաճանաչ լեզուներով:

V.1. Տվյալների մոդել

Այստեղ մի քանի հնարավոր մոտեցումներ կան.

V.1.1. Singleton սեփականություն

RDF-ի և LPG-ի ներդաշնակեցման առավել բառացի մոտեցումը, հավանաբար, այն է singleton սեփականություն:

• Օրինակ՝ պրեդիկատի փոխարեն :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, ծնված Blazegraph-ի խորքերում: Դա հենց սկզբից է ընտրված ձեզ և AnzoGraph-ի համար: Մոտեցման ամուրությունը որոշվում է նրանով, որ դրա շրջանակներում առաջարկվում են համապատասխան փոփոխությունները RDF իմաստաբանություն. Բանը, սակայն, չափազանց պարզ է. RDF-ի Turtle serialization-ում այժմ կարող եք գրել այսպես.

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

V.1.3. Այլ մոտեցումներ

Դուք չեք կարող անհանգստանալ ֆորմալ իմաստաբանությամբ, այլ պարզապես ենթադրել, որ եռյակներն ունեն որոշակի նույնացուցիչներ, որոնք, իհարկե, URI-ներ են, և այս URI-ներով ստեղծում են նոր եռյակներ: Մնում է SPARQL-ում այս URI-ներին հասանելիություն տալ: Այսպիսով ժամանում է Աստղային շուն.

Ալեգրոգրաֆում գնաց միջանկյալ եղանակով։ Հայտնի է, որ եռյակի նույնացուցիչները Allegrograph-ում կա, բայց եռակի ատրիբուտներ իրականացնելիս դրանք դուրս չեն մնում: Այնուամենայնիվ, այն դեռ շատ հեռու է ֆորմալ իմաստաբանությունից: Հատկանշական է, որ եռյակի ատրիբուտները URI-ներ չեն, և այդ ատրիբուտների արժեքները նույնպես կարող են լինել միայն բառացի: LPG-ի կողմնակիցները ստանում են հենց այն, ինչ ցանկանում էին: Հատուկ հորինված NQX ձևաչափում RDF*-ի համար վերը նշված օրինակը նման է հետևյալին.

:bob :marriedTo :alice {"since" : "2013-09-13"}

V.2. Հարցման լեզուներ

Մոդելի մակարդակում այս կամ այն ​​կերպ աջակցելով LPG-ին, դուք պետք է հնարավորություն ընձեռեք նման մոդելի տվյալների վերաբերյալ հարցումներ կատարել:

• Blazegraph-ը RDF* հարցումների համար աջակցում է SPARQL* и Gremlin. 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. Լիցենզիաների խստացում

Վերջերս «ընտրության եռակի խանութ» և «բաց կոդով եռակի խանութ» հավաքածուների հատման կետում որևէ լրացում չի եղել: Նոր բաց կոդով RDF խանութները հեռու են առօրյա օգտագործման համար լավ ընտրություն լինելուց, և նոր RDF խանութների սկզբնական կոդը, որը մենք կցանկանայինք օգտագործել (նույն AnzoGraph-ը), փակ է: Փոխարենը, մենք կարող ենք նույնիսկ խոսել հանումների մասին...

Իհարկե, բաց կոդով նախկինում չի փակվել, բայց որոշ բաց կոդով պահոցներ կամաց-կամաց այլևս չեն ընկալվում որպես ընտրելու արժանի: Վիրտուոզը, որն ունի opensource հրատարակություն, իմ կարծիքով խեղդվում է սխալների մեջ։ Blazegraph-ը գնվել է AWS-ի կողմից և կազմել Amazon Neptune-ի հիմքը; հիմա պարզ չէ, թե արդյոք կլինի ևս մեկ թողարկում: Մնում է միայն Յենան...

Եթե ​​բաց աղբյուրը շատ կարևոր չէ, բայց դուք պարզապես ցանկանում եք փորձել այն, ապա ամեն ինչ նույնպես ավելի քիչ վարդագույն է, քան նախկինում: Օրինակ:

• Աստղաշուն կանգառներ տարածել անվճար տարբերակը (սակայն, սովորական տարբերակի փորձաշրջանը կրկնապատկվել է);
• в GraphDB Cloud, որտեղ նախկինում կարող էիք ընտրել անվճար հիմնական պլան, կասեցրել է նոր օգտատերերի գրանցումները։

Ընդհանուր առմամբ, սովորական ՏՏ մարդու համար տիեզերքն ավելի ու ավելի անհասանելի է դառնում, դրա զարգացումը դառնում է կորպորացիաների մեծ մասը:

Source: www.habr.com