ProHoster > blogg > internetnyheter > Vad händer med RDF-lagring nu?

Vad händer med RDF-lagring nu?

Den semantiska webben och länkade data är som yttre rymden: det finns inget liv där. Att åka dit under en mer eller mindre lång tid... Jag vet inte vad de sa till dig som barn som svar på "Jag vill bli astronaut." Men du kan observera vad som händer på jorden; Det är mycket lättare att bli amatörastronom eller till och med proffs.

Artikeln kommer att fokusera på senaste, inte äldre än flera månader, trender från världen av RDF-lagring. Metaforen i första stycket är inspirerad av den episka reklambilden under snittet.


Episk bild

Vad händer med RDF-lagring nu?

I. GraphQL för RDF-åtkomst

De sägeratt GraphQL siktar på att bli ett universellt databasåtkomstspråk. Hur är det med möjligheten att få åtkomst till RDF med GraphQL?

Den här möjligheten tillhandahålls av:

Om förvaret inte ger en sådan möjlighet kan det implementeras oberoende genom att skriva en lämplig "resolver". Så gjorde de till exempel i det franska projektet Dataturism. Eller så kan man inte längre skriva något, utan bara ta HyperGraphQL.

Ur synvinkeln för en ortodox anhängare av den semantiska webben och länkade data är allt detta naturligtvis tråkigt, eftersom det verkar designat för integrationer byggda kring nästa datasilo, och inte lämpliga plattformar (RDF-butiker, förstås) .

Intrycken från att jämföra GraphQL med SPARQL är tvåfaldiga.

  • Å ena sidan ser GraphQL ut som en avlägsen släkting till SPARQL: det löser problemen med omsampling och mångfalden av frågor som är typiska för REST - utan vilka det förmodligen inte skulle vara möjligt att överväga frågespråk, åtminstone för webben;
  • Å andra sidan är det stela schemat för GraphQL en besvikelse. Följaktligen verkar dess "introspektivitet" mycket begränsad jämfört med RDF:s fulla reflexivitet. Och det finns ingen analog av fastighetsvägar, så det är inte ens särskilt tydligt varför det är "Graph-".

II. Adaptrar för MongoDB

En trend som kompletterar den tidigare.

  • I Stardog nu kanske - i synnerhet alla på samma GraphQL - konfigurera mappningen av MongoDB-data till virtuella RDF-grafer;
  • Ontotext GraphDB har nyligen det gör infoga fragment i SPARQL på MongoDB Query.

Om vi ​​talar mer allmänt om adaptrar till JSON-källor, som tillåter mer eller mindre "on the fly" att representera JSON som lagras i dessa källor som RDF, kan vi minnas den ganska långvariga SPARQL Generera, som kan justeras, exempelvis, till Apache Jena.

För att sammanfatta de två första trenderna kan vi säga att RDF-lagringar visar full beredskap för integration och drift under förhållanden med "polyglot-beständighet". Det är dock känt att detta senare länge har gått ur mode och håller på att ersättas av kommande multimodell. Hur är det med multimodellering i en värld av RDF-lagring?

Kort sagt, inget sätt. Jag skulle vilja ägna en separat artikel till ämnet multi-modell DBMS, men för närvarande kan det noteras att det för närvarande inte finns några multi-modell DBMS "baserade" på en grafmodell (RDF kan betraktas som en typ av det) . Vissa små multimodelleringar - RDF-lagringsstöd för en alternativ LPG-grafmodell - kommer att diskuteras i avsnitt V.

III. OLTP vs. OLAP

Dock samma Gartner skriveratt multimodell är en absolut nödvändig förutsättning främst för operationssalar DBMS. Detta är förståeligt: ​​i en situation med "multivariatlagring" uppstår de största problemen med transaktionalitet.

Men var finns RDF-lagringar på OLTP-OLAP-skalan? Jag skulle svara så här: varken där eller här. För att ange vad de är avsedda för behövs någon tredje förkortning. Som ett alternativ skulle jag föreslå OLIP — Intellektuell bearbetning online.

Men fortfarande:

  • integrationsmekanismerna med MongoDB implementerade i GraphDB är inte minst avsedd att komma runt skrivprestandaproblem;
  • Stardog går ännu längre och fullständigt skriver om motor, återigen med målet att förbättra inspelningsprestandan.

Låt mig nu introducera en ny aktör på marknaden. Från skaparna av IBM Netezza och Amazon Redshift - AnzoGraph™. En bild från en annons för en produkt baserad på den lades upp i början av artikeln. AnzoGraph positionerar sig som en GOLAP-lösning. Hur gillar du SPARQL med fönsterfunktioner? —

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

IV. RocksDB

Redan högre det fanns en länk till tillkännagivandet av Stardog 7 Beta, som sa att Stardog skulle använda RocksDB som ett underliggande lagringssystem - en nyckel-värde butik, en Facebook-gaffel av Googles LevelDB. Varför är det värt att prata om en viss trend?

För det första att döma av Wikipedia-artikel, inte bara RDF-lagringar "transplanteras" till RocksDB. Det finns projekt för att använda RocksDB som lagringsmotor i ArangoDB, MongoDB, MySQL och MariaDB, Cassandra.

För det andra skapas projekt (det vill säga inte produkter) om relevanta ämnen på RocksDB.

Till exempel använder eBay RocksDB i plattform för din "kunskapsgraf". Förresten, det är roligt att läsa: frågespråket började som ett inhemskt format, men på senare tid har det övergått till att bli mycket mer likt SPARQL. Som i skämtet: oavsett hur mycket kunskapsgraf vi gör, så hamnar vi fortfarande på RDF.

Ett annat exempel - ett som dök upp för några månader sedan Wikidata History Query Service. Innan den introducerades behövde Wikidatas historiska information nås via MWAPI till Mediawikis standard-API. Nu är mycket möjligt med ren SPARQL. "Under huven" finns även RocksDB. Förresten, WDHQS gjordes, verkar det som, av personen som importerade Freebase till Google Knowledge Graph.

V. LPG-stöd

Låt mig påminna dig om huvudskillnaden mellan LPG-grafer och RDF-grafer.

I LPG kan skalära egenskaper tilldelas kantinstanser, medan de i RDF bara kan tilldelas kant-”typer” (men inte bara skalära egenskaper, utan även vanliga anslutningar). Denna begränsning av RDF jämfört med gasol betagen en eller annan modelleringsteknik. Begränsningarna för LPG jämfört med RDF är svårare att övervinna, men LPG-grafer är mer som bilder från en Harari-lärobok än RDF-grafer, vilket är anledningen till att folk vill ha dem.

Uppenbarligen delas uppgiften med "LPG-stöd" i två delar:

  1. göra ändringar i RDF-modellen som gör det möjligt att simulera LPG-strukturer i den;
  2. göra ändringar i RDF-frågespråket som gör det möjligt att komma åt data i denna modifierade modell, eller implementera möjligheten att göra frågor till denna modell i populära LPG-frågespråk.

V.1. Datamodell

Det finns flera möjliga tillvägagångssätt här.

V.1.1. Singleton Property

Det mest bokstavliga sättet att harmonisera RDF och LPG är förmodligen singelfastighet:

  • Istället för till exempel predikatet :isMarriedTo predikat används :isMarriedTo1, :isMarriedTo2 och t. d.
  • Dessa predikat blir sedan föremål för nya trillingar: :isMarriedTo1 :since "2013-09-13"^^xsd:date etc.
  • Kopplingen av dessa förekomster av predikat med ett gemensamt predikat etableras av formens tripletter :isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo.
  • Det är uppenbart att rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type, men tänk på varför du inte bara ska skriva :isMarriedTo1 rdf:type :isMarriedTo.

Problemet med "LPG-stöd" löses här på RDFS-nivå. Ett sådant beslut kräver införande i lämpligt standard. Vissa förändringar kan krävas för RDF-butiker som stöder bifogade konsekvenser, men för närvarande kan Singleton Property ses som bara en annan modelleringsteknik.

V.1.2. Reifikation gjort rätt

Mindre naiva tillvägagångssätt härrör från insikten att egendomsinstanser är helt instansierbara av trillingar. Genom att kunna säga något om trillingar kommer vi att kunna prata om fastighetsinstanser.

Den mest robusta av dessa metoder är RDF*, aka RDR, född i Blazegraphs djup. Det är från första början vald för dig själv och AnzoGraph. Tillvägagångssättets soliditet bestäms av det faktum att inom dess ram erbjuds motsvarande förändringar i RDF semantik. Poängen är dock extremt enkel. I Turtle serialization of RDF kan du nu skriva något så här:

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

V.1.3. Andra tillvägagångssätt

Du kan inte bry dig om formell semantik, utan helt enkelt anta att tripletter har vissa identifierare, som naturligtvis är URI:er, och skapa nya tripletter med dessa URI:er. Allt som återstår är att ge tillgång till dessa URI:er i SPARQL. Så ankommer Stardog.

I Allegrograph åkte på ett mellanliggande sätt. Det är känt att triplettidentifierare i Allegrograph finns, men när de implementerar trippelattribut sticker de inte ut. Det är dock fortfarande väldigt långt ifrån formell semantik. Det är anmärkningsvärt att triplettattribut inte är URI:er, och värdena för dessa attribut kan också bara vara bokstavliga. LPG-anhängare får precis vad de ville ha. I det speciellt uppfunna NQX-formatet ser ett exempel liknande det ovan för RDF* ut så här:

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

V.2. Fråga språk

Efter att ha stött LPG på ett eller annat sätt på modellnivå behöver du göra det möjligt att göra förfrågningar på data i en sådan modell.

  • Blazegraph för RDF*-frågor stöder SPARQL* и Gremlin. En SPARQL*-fråga ser ut så här:

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

  • Anzograph stöder också SPARQL* och kommer att stödja Cypher, ett frågespråk i Neo4j.
  • Stardog stödjer sina egna förlängning SPARQL och igen Gremlin. Du kan få triplett-URI och "metainformation" i SPARQL med något så här:

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

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

Förresten, GraphDB stödde vid en tidpunkt Tinkerpop/Gremlin utan att stödja LPG, men detta slutade i version 8.0 eller 8.1.

VI. Skärpning av licenser

Det har inte gjorts några nya tillägg till skärningspunkten mellan "triplestore of choice" och "open source triplestore" set. De nya RDF-butikerna med öppen källkod är långt ifrån ett bra val för dagligt bruk, och de nya trippelbutikerna som jag skulle vilja använda (som AnzoGraph) är sluten källkod. Snarare kan vi prata om minskningar...

Naturligtvis har öppen källkod inte stängts av tidigare, men vissa arkiv med öppen källkod ses långsamt inte längre som värda att välja. Virtuoso, som har en öppen källkodsutgåva, drunknar enligt mig i buggar. Blazegraph köptes av AWS och utgjorde grunden för Amazon Neptune; nu är det oklart om det blir minst en release till. Bara Jena är kvar...

Om öppen källkod inte är särskilt viktigt, men du bara vill prova, så är allt också mindre rosenrött än tidigare. Till exempel:

  • Stardog stannar distribuera gratisversionen (dock har provperioden för den vanliga versionen fördubblats);
  • в GraphDB Cloud, där du tidigare kunde välja en gratis grundplan, har nya användarregistreringar stängts av.

I allmänhet, för den genomsnittlige IT-personen, blir rymden mer och mer otillgänglig, dess utveckling blir företagens lott.

Källa: will.com

Lägg en kommentar