ProHoster > Blog > internetes hírek > Mi történik most az RDF tárolóval?

Mi történik most az RDF tárolóval?

A szemantikus web és a linkelt adatok olyanok, mint a világűr: ott nincs élet. Elmenni oda többé-kevésbé hosszú időre... Nem tudom, mit mondtak neked gyerekkorodban, hogy „űrhajós akarok lenni”. De megfigyelheted, mi történik a Földön; Sokkal könnyebb amatőr csillagásznak vagy akár profinak lenni.

A cikk az RDF-tárolás világának legújabb, néhány hónapnál nem régebbi trendjeire összpontosít. Az első bekezdés metaforáját a vágás alatti epikus méretű reklámkép ihlette.


Epikus kép

Mi történik most az RDF tárolóval?

I. GraphQL az RDF hozzáféréshez

Azt mondjákhogy a GraphQL univerzális adatbázis-elérési nyelvvé kíván válni. Mi a helyzet az RDF-hez való hozzáférés lehetőségével a GraphQL használatával?

A dobozból ezt a lehetőséget a következők biztosítják:

Ha a repository nem biztosít ilyen lehetőséget, akkor az önállóan is megvalósítható megfelelő „feloldó” írásával. Ezt tették például a francia projektben DataTourisme. Vagy már nem tudsz írni semmit, hanem csak venni HyperGraphQL.

A szemantikus web és a linkelt adatok ortodox híve szemszögéből mindez persze szomorú, hiszen úgy tűnik, a következő adatsiló köré épülő integrációkra tervezték, és nem megfelelő platformokra (természetesen RDF-áruházak) .

A GraphQL és a SPARQL összehasonlítása kettős benyomást kelt.

  • Egyrészt a GraphQL a SPARQL távoli rokonaként néz ki: megoldja a REST-re jellemző újramintavételezési és lekérdezések többszörösségének problémáit - ami nélkül valószínűleg nem is lehetne megfontolni. lekérdezési nyelv, legalábbis a weben;
  • Másrészt a GraphQL merev sémája kiábrándító. Ennek megfelelően az „introspektivitása” nagyon korlátozottnak tűnik az RDF teljes reflexivitásához képest. A tulajdonságútvonalaknak pedig nincs analógja, így nem is nagyon világos, hogy miért „Graph-”.

II. Adapterek a MongoDB-hez

Az előzőt kiegészítő trend.

  • Most a Stardogban lehetséges - különösen mind ugyanazon a GraphQL-n - konfigurálja a MongoDB adatok virtuális RDF gráfokba való leképezését;
  • Az Ontotext GraphDB nemrég lehetővé teszi beillesztheti a töredékeket a SPARQL-be ​​a MongoDB Queryben.

Ha tágabban beszélünk a JSON-forrásokhoz való adapterekről, amelyek többé-kevésbé „menet közben” teszik lehetővé az ezekben a forrásokban tárolt JSON RDF-ként való megjelenítését, akkor felidézhetjük a meglehetősen régóta fennálló SPARQL generálás, amely állítható, például, Apache Jena-nak.

Az első két trendet összefoglalva elmondható, hogy az RDF tárolók teljes integrációs készséget mutatnak és a „poliglot-perzisztencia” körülményei között működnek. Köztudott azonban, hogy ez utóbbi már régóta kiment a divatból, és felváltja eljövetel több modell. Mi a helyzet a multimodellezéssel az RDF-tárolás világában?

Röviden, dehogy. Külön cikket szeretnék szentelni a többmodelles DBMS-ek témájának, de egyelőre megjegyezhető, hogy jelenleg nem léteznek gráfmodellre (az RDF ennek egy típusának tekinthető) „alapú” többmodelles DBMS-ek. . Néhány kisebb multimodellezésről – egy alternatív LPG-gráfmodell RDF tárolási támogatásáról – lesz szó V. szakasz.

III. OLTP vs. OLAP

Azonban ugyanaz a Gartner írásokhogy a multimodell sine qua non feltétel elsősorban annak műtők DBMS. Ez érthető: a „többváltozós tárolás” helyzetében a fő problémák a tranzakciós teljesítménnyel adódnak.

De hol vannak az RDF tárolók az OLTP-OLAP skálán? Én így válaszolnék: se ott, se itt. Ahhoz, hogy jelezzük, mire szánják, szükség van egy harmadik rövidítésre. Opcióként javaslom OLIP — Online szellemi feldolgozás.

Azonban továbbra is:

  • a GraphDB-ben implementált MongoDB-vel való integrációs mechanizmusok nem utolsó sorban szándékolt az írási teljesítménnyel kapcsolatos problémák megkerülése;
  • A Stardog még tovább megy és teljesen átírja motor, ismét azzal a céllal, hogy javítsa a felvételi teljesítményt.

Hadd mutassak be egy új szereplőt a piacra. Az IBM Netezza és az Amazon Redshift alkotóitól - AnzoGraph™. A cikk elejére felkerült egy kép az alapján készült termék hirdetéséből. Az AnzoGraph GOLAP megoldásként pozicionálja magát. Hogy tetszik az ablakfunkciós SPARQL? —

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

IV. RocksDB

Már magasabban volt link a Stardog 7 Beta bejelentésére, amely szerint a Stardog a RocksDB-t fogja használni mögöttes tárolórendszerként – kulcs-értéktárolóként, a Google LevelDB-jének Facebook-elágazásaként. Miért érdemes egy bizonyos trendről beszélni?

Először is, abból ítélve Wikipédia cikk, nem csak az RDF tárolókat „ültetik át” a RocksDB-be. Vannak olyan projektek, amelyek a RocksDB-t tárolómotorként használják az ArangoDB-ben, a MongoDB-ben, a MySQL-ben és a MariaDB-ben, Cassandra-ban.

Másodszor, a RocksDB-n projektek (vagyis nem termékek) jönnek létre a releváns témákban.

Például az eBay a RocksDB-t használja emelvény a „tudásgráfodhoz”. Egyébként vicces olvasni: a lekérdező nyelv otthoni formátumként indult, de az utóbbi időben sokkal inkább a SPARQL-hez hasonlított. Mint a viccben: akármekkora tudásgráfot készítünk, mégis az RDF-hez jutunk.

Egy másik példa - amely néhány hónappal ezelőtt jelent meg Wikidata History Query Service. Bevezetése előtt a Wikidata történeti információihoz kellett hozzáférni MWAPI a szabványos Mediawiki API-hoz. Most sok minden lehetséges a tiszta SPARQL-lel. „A motorháztető alatt” ott van a RocksDB is. A WDHQS-t egyébként úgy tűnik, az a személy készítette, aki a Freebase-t importálta a Google Tudásgráfba.

V. LPG támogatás

Hadd emlékeztesselek az LPG-grafikonok és az RDF-grafikonok közötti fő különbségre.

Az LPG-ben a skaláris tulajdonságok az élpéldányokhoz rendelhetők, míg az RDF-ben csak az éltípusokhoz (de nem csak a skaláris tulajdonságokhoz, hanem a hétköznapi kapcsolatokhoz is). Az RDF ezen korlátozása az LPG-hez képest legyőzni egyik vagy másik modellezési technika. Az LPG korlátait az RDF-hez képest nehezebb leküzdeni, de az LPG grafikonok inkább hasonlítanak egy Harari tankönyv képeihez, mint az RDF grafikonokhoz, ezért az emberek ezt szeretnék.

Nyilvánvalóan az „LPG-támogatás” feladata két részre oszlik:

  1. olyan változtatások elvégzése az RDF modellen, amelyek lehetővé teszik az LPG szerkezetek szimulálását benne;
  2. olyan változtatások végrehajtása az RDF lekérdezési nyelven, amelyek lehetővé teszik az adatok elérését ebben a módosított modellben, vagy a modell lekérdezésének lehetőségét a népszerű LPG lekérdezési nyelveken.

V.1. Adatmodell

Itt több megközelítés is lehetséges.

V.1.1. Singleton ingatlan

Az RDF és LPG harmonizálásának legszó szerintibb megközelítése valószínűleg az singleton ingatlan:

  • Például az állítmány helyett :isMarriedTo predikátumokat használnak :isMarriedTo1, :isMarriedTo2 stb
  • Ezek a predikátumok ezután új hármasok alanyaivá válnak: :isMarriedTo1 :since "2013-09-13"^^xsd:date stb
  • Ezen predikátum-példányok kapcsolatát egy közös predikátummal az alak hármasai határozzák meg :isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo.
  • Nyilvánvaló, hogy rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type, de gondold át, miért ne írhatnál egyszerűen :isMarriedTo1 rdf:type :isMarriedTo.

Az „LPG támogatás” problémája itt RDFS szinten megoldott. Egy ilyen döntés megköveteli a megfelelő стандарт. Bizonyos változtatásokra lehet szükség a következmények csatolását támogató RDF-tárolóknál, de egyelőre a Singleton Property egy újabb modellezési technikának tekinthető.

V.1.2. A reifikáció helyesen megtörtént

A kevésbé naiv megközelítések abból a felismerésből fakadnak, hogy a tulajdonságpéldányok teljesen példányosíthatók hármasokkal. Azáltal, hogy tudunk valamit mondani a hármasikrekről, képesek leszünk beszélni az ingatlanok eseteiről.

E megközelítések közül a legerősebb az RDF*, más néven RDR, született a Blazegraph mélyén. A kezdetektől fogva megválasztott magadnak és az AnzoGraphnak. A szemlélet szilárdságát meghatározza, hogy keretei között felajánlott megfelelő változásokat RDF szemantika. A lényeg azonban rendkívül egyszerű. Az RDF Turtle szerializálásában most valami ilyesmit írhat:

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

V.1.3. Más megközelítések

Nem foglalkozhat formális szemantikával, hanem egyszerűen feltételezheti, hogy a hármasok bizonyos azonosítókkal rendelkeznek, amelyek természetesen URI-k, és ezekkel az URI-kkel új hármasokat hoznak létre. Már csak hozzáférést kell biztosítani ezekhez az URI-khoz a SPARQL-ben. Így érkezik Stardog.

In Allegrograph ment köztes módon. Ismeretes, hogy az Allegrograph hármasazonosítói van, de a hármas attribútumok implementálásakor nem tűnnek ki. A formális szemantikától azonban még mindig nagyon távol áll. Figyelemre méltó, hogy a triplet attribútumok nem URI-k, és ezen attribútumok értékei is csak literálok lehetnek. Az LPG-t követők pontosan azt kapják, amit akartak. A speciálisan kitalált NQX formátumban a fentihez hasonló példa az RDF* esetében így néz ki:

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

V.2. Lekérdezési nyelvek

Miután a modell szintjén ilyen vagy olyan módon támogatta az LPG-t, lehetővé kell tennie az adatok lekérdezését egy ilyen modellben.

  • A Blazegraph az RDF* lekérdezésekhez támogatja SPARQL* и Gonosz szellem. Egy SPARQL* lekérdezés így néz ki:

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

  • Az Anzograph is támogatja SPARQL* és támogatni fogja Titkosírás, egy lekérdezési nyelv a Neo4j-ben.
  • A Stardog támogatja a sajátját kiterjesztés SPARQL és újra Gonosz szellem. A triplet URI-t és a „metainformációkat” a SPARQL-ben a következőképpen kaphatja meg:

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

  • Az Allegrograph szintén támogatja a sajátját kiterjesztés SPARQL:

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

Egyébként a GraphDB egy időben támogatta a Tinkerpop/Gremlin-t az LPG támogatása nélkül, de ez a 8.0 vagy 8.1 verzióban megszűnt.

VI. Az engedélyek szigorítása

A közelmúltban nem került sor a „választható triplestore” és a „nyílt forráskódú triplestore” készletek metszéspontjára. Az új nyílt forráskódú RDF tárolók nagyon messze vannak attól, hogy jó választások legyenek a mindennapi használatra, az új hármas tárolók pedig, amelyeket szeretnék használni (például az AnzoGraph), zárt forráskódúak. Inkább csökkenésről beszélhetünk...

Természetesen a nyílt forráskódot korábban nem zárták le, de néhány nyílt forráskódú adattárat lassan már nem érdemes választani. A Virtuoso, amelynek nyílt forráskódú kiadása van, véleményem szerint fuldoklik a hibákban. A Blazegraphot az AWS vásárolta meg, és az Amazon Neptune alapját képezte; most nem világos, hogy lesz-e még legalább egy kiadás. Csak Jéna maradt...

Ha a nyílt forráskód nem túl fontos, de csak szeretnéd kipróbálni, akkor minden kevésbé rózsás, mint korábban. Például:

  • Stardog megszűnik az ingyenes verzió terjesztése (a normál verzió próbaidőszaka azonban megduplázódott);
  • в GraphDB felhő, ahol korábban ingyenes alapcsomagot lehetett választani, az új felhasználók regisztrációját felfüggesztettük.

Általánosságban elmondható, hogy az átlagos informatikus számára a tér egyre megközelíthetetlenebbé válik, fejlesztése a vállalatok dolga.

Forrás: will.com

Hozzászólás