ProHoster > Blogi > netin uutisia > Mitä RDF-tallennustilalle tapahtuu nyt?

Mitä RDF-tallennustilalle tapahtuu nyt?

Semanttinen verkko ja linkitetty data ovat kuin ulkoavaruutta: siellä ei ole elämää. Mennä sinne enemmän tai vähemmän pitkäksi aikaa... En tiedä, mitä he sanoivat sinulle lapsena vastauksena "Haluan tulla astronautiksi". Mutta voit tarkkailla mitä tapahtuu maan päällä ollessasi; On paljon helpompaa tulla amatööritähtitieteilijäksi tai jopa ammattilaiseksi.

Artikkeli keskittyy viimeaikaisiin, korkeintaan useita kuukausia vanhempiin trendeihin RDF-tallennusmaailmasta. Ensimmäisen kappaleen metafora on saanut inspiraationsa leikkauksen alla olevasta eeppisen kokoisesta mainoskuvasta.


Eeppinen kuva

Mitä RDF-tallennustilalle tapahtuu nyt?

I. GraphQL RDF-käyttöä varten

He sanovatettä GraphQL pyrkii olemaan yleinen tietokantakäyttökieli. Entä kyky käyttää RDF:ää GraphQL:n avulla?

Paketista tämän mahdollisuuden tarjoavat:

Jos arkisto ei tarjoa tällaista mahdollisuutta, se voidaan toteuttaa itsenäisesti kirjoittamalla sopiva "resolver". Näin he tekivät esimerkiksi ranskalaisessa hankkeessa DataTourisme. Tai et voi enää kirjoittaa mitään, vaan vain ottaa HyperGraphQL.

Semanttisen verkon ja linkitetyn datan ortodoksisen kannattajan näkökulmasta tämä kaikki on tietysti surullista, koska se näyttää olevan suunniteltu seuraavan tietosiilon ympärille rakennetuille integroinneille, eikä sopiville alustoille (tietenkin RDF-myymälät) .

GraphQL:n ja SPARQL:n vertailusta saadut vaikutelmat ovat kaksijakoiset.

  • Toisaalta GraphQL näyttää SPARQL:n kaukaiselta sukulaiselta: se ratkaisee REST:lle tyypilliset uudelleennäytteenotto- ja kyselyiden moninaisuusongelmat - jota ilman sitä ei luultavasti olisi mahdollista harkita. kyselyn kieli, ainakin verkossa;
  • Toisaalta GraphQL:n jäykkä kaava on pettymys. Näin ollen sen "introspektiivisuus" näyttää hyvin rajalliselta verrattuna RDF:n täyteen refleksiivisuuteen. Ja ominaisuuspoluille ei ole analogia, joten ei ole edes kovin selvää, miksi se on "Graph-".

II. Sovittimet MongoDB:lle

Trendi, joka täydentää edellistä.

  • Stardogissa nyt ehkä - erityisesti kaikki samassa GraphQL:ssä - konfiguroi MongoDB-tietojen kartoitus virtuaalisiksi RDF-kaavioiksi;
  • Ontotext GraphDB on äskettäin sen avulla lisää fragmentteja SPARQL:iin MongoDB Queryssa.

Jos puhumme laajemmin JSON-lähteiden sovittimista, jotka sallivat enemmän tai vähemmän "lennossa" edustaa näihin lähteisiin tallennetun JSONin RDF-muodossa, voimme muistaa melko pitkäaikaisen SPARQL Luo, jota voidaan säätää, esimerkiksi, Apache Jenalle.

Yhteenvetona kahdesta ensimmäisestä suuntauksesta voidaan sanoa, että RDF-varastot osoittavat täydellistä valmiutta integraatioon ja toimintaan "polyglotin pysyvyyden" olosuhteissa. Tiedetään kuitenkin, että tämä jälkimmäinen on ollut pitkään poissa muodista, ja se korvataan on tulossa monimalli. Entä monimallinnus RDF-tallennusmaailmassa?

Lyhyesti sanottuna ei mitenkään. Haluaisin omistaa erillisen artikkelin usean mallin DBMS-aiheelle, mutta toistaiseksi voidaan todeta, että tällä hetkellä ei ole olemassa graafimalliin "pohjaisia" monimallipohjaisia ​​DBMS-järjestelmiä (RDF:ää voidaan pitää sen tyyppinä) . Joitakin pieniä multimallinnuksia - RDF-tallennustuki vaihtoehtoiselle nestekaasukaaviomallille - käsitellään tässä jakso V.

III. OLTP vs. OLAP

Kuitenkin sama Gartner kirjoittaaettä monimalli on ehdoton ehto ensisijaisesti leikkaussalit DBMS. Tämä on ymmärrettävää: "monimuuttujavaraston" tilanteessa suurimmat ongelmat syntyvät transaktioiden kanssa.

Mutta missä RDF-tallennustilat sijaitsevat OLTP-OLAP-asteikolla? Vastaisin näin: ei siellä eikä täällä. Kolmas lyhenne tarvitaan osoittamaan, mihin ne on tarkoitettu. Vaihtoehtona suosittelen OLIP — Online henkinen käsittely.

Silti kuitenkin:

  • GraphDB:ssä toteutetut MongoDB:n integrointimekanismit eivät ole vähäisimpiä tarkoitettu kiertää kirjoitussuorituskykyongelmia;
  • Stardog menee vielä pidemmälle ja täydellisesti kirjoittaa uudelleen moottori, jälleen tavoitteena parantaa tallennussuorituskykyä.

Nyt esittelen markkinoille uuden toimijan. IBM Netezzan ja Amazon Redshiftin luojilta - AnzoGraph™. Kuva siihen perustuvan tuotteen mainoksesta julkaistiin artikkelin alussa. AnzoGraph asettuu GOLAP-ratkaisuksi. Mitä pidät SPARQLista, jossa on ikkunatoimintoja? —

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

IV. RocksDB

Jo korkeammalle siellä oli linkki Stardog 7 Betan ilmoitukseen, jossa sanottiin, että Stardog aikoo käyttää RocksDB:tä taustalla olevana tallennusjärjestelmänä - avainarvovarastona, Googlen LevelDB:n Facebook-haarukkana. Miksi tietystä trendistä kannattaa puhua?

Ensinnäkin, päätellen Wikipedian artikkeli, ei vain RDF-varastoja "siirretä" RocksDB:hen. RocksDB:n käyttämiseksi tallennusmoottorina on projekteja ArangoDB:ssä, MongoDB:ssä, MySQL:ssä ja MariaDB:ssä, Cassandrassa.

Toiseksi RocksDB:ssä luodaan projekteja (eli ei tuotteita) relevanteista aiheista.

Esimerkiksi eBay käyttää RocksDB:tä foorumi "tietokaaviollesi". On muuten hauska lukea: kyselykieli alkoi kotona kasvatettuna muodossa, mutta viime aikoina se on muuttunut paljon enemmän SPARQL:n kaltaiseksi. Kuten vitsissä: riippumatta siitä, kuinka paljon tietokaaviota teemme, päädymme silti RDF:ään.

Toinen esimerkki - joka ilmestyi muutama kuukausi sitten Wikidatan historiakyselypalvelu. Ennen sen käyttöönottoa Wikidatan historiatietoihin oli päästävä läpi MWAPI tavalliseen Mediawiki API:hen. Nyt paljon on mahdollista puhtaalla SPARQL:lla. "Under the hood" on myös RocksDB. Muuten, WDHQS:n teki ilmeisesti henkilö, joka toi Freebasen Google Knowledge Graphiin.

V. Nestekaasun tuki

Haluan muistuttaa sinua tärkeimmistä eroista LPG- ja RDF-kaavioiden välillä.

LPG:ssä skalaariominaisuudet voidaan määrittää reunainstanssiin, kun taas RDF:ssä ne voidaan määrittää vain reunan "tyypeille" (mutta ei vain skalaariominaisuuksia, vaan myös tavallisia yhteyksiä). Tämä RDF:n rajoitus nestekaasuun verrattuna voittaa yksi tai toinen mallinnustekniikka. LPG:n rajoitukset RDF:ään verrattuna on vaikeampi voittaa, mutta LPG-kaaviot ovat enemmän kuin Hararin oppikirjan kuvia kuin RDF-kaavioita, minkä vuoksi ihmiset haluavat niitä.

Ilmeisesti "LPG-tuen" tehtävä jakautuu kahteen osaan:

  1. tehdä RDF-malliin muutoksia, jotka mahdollistavat nestekaasurakenteiden simuloinnin siinä;
  2. tekemällä RDF-kyselykieleen muutoksia, jotka mahdollistavat tietojen käytön tässä muokatussa mallissa, tai toteuttamalla mahdollisuuden tehdä kyselyitä tähän malliin suosituilla LPG-kyselykielillä.

V.1. Tietomalli

Tässä on useita mahdollisia lähestymistapoja.

V.1.1. Singletonin omaisuus

Kirjaimellisin lähestymistapa RDF:n ja nestekaasun yhdenmukaistamiseen on luultavasti singleton omaisuutta:

  • Esimerkiksi predikaatin sijaan :isMarriedTo predikaatteja käytetään :isMarriedTo1, :isMarriedTo2 ja t. d.
  • Näistä predikaateista tulee sitten uusien kolmosten aiheita: :isMarriedTo1 :since "2013-09-13"^^xsd:date jne.
  • Näiden predikaattiesiintymien yhteys yhteiseen predikaattiin muodostetaan muodon triplettien avulla :isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo.
  • On selvää, että rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type, mutta mieti, miksi sinun ei pitäisi vain kirjoittaa :isMarriedTo1 rdf:type :isMarriedTo.

"LPG-tuen" ongelma on ratkaistu täällä RDFS-tasolla. Tällainen päätös edellyttää sisällyttämistä asianmukaiseen стандарт. Joitakin muutoksia voidaan tarvita RDF-varastoissa, jotka tukevat seurausten liittämistä, mutta toistaiseksi Singleton Property voidaan ajatella vain yhtenä mallinnustekniikkana.

V.1.2. Reifikaatio tehty oikein

Vähemmän naiivit lähestymistavat johtuvat oivalluksesta, että ominaisuusinstanssit ovat täysin muuttumattomia kolmosilla. Kun voimme sanoa jotain kolmosista, voimme puhua kiinteistötapauksista.

Vahvin näistä lähestymistavoista on RDF*, eli RDR, syntynyt Blazegraphin syvyyksissä. Se on aivan alusta valittu itsellesi ja AnzoGraphille. Lähestymistavan vakavuuden määrää se, että sen puitteissa tarjottu vastaavat muutokset RDF-semantiikka. Asia on kuitenkin äärimmäisen yksinkertainen. RDF:n Turtle-serialisaatiossa voit nyt kirjoittaa jotain tällaista:

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

V.1.3. Muita lähestymistapoja

Et voi vaivautua muodolliseen semantiikkaan, vaan olettaa, että tripletillä on tietyt tunnisteet, jotka ovat tietysti URI:ita, ja luoda uusia triplettejä näillä URI:illa. Jäljelle jää vain pääsy näihin URI:ihin SPARQL:ssä. Niin saapuu Tähtikoira.

Julkaisussa Allegrograph mennään välitavalla. Tiedetään, että Allegrographin kolmoistunnisteet on, mutta kolminkertaisia ​​määritteitä toteutettaessa ne eivät jää esiin. Se on kuitenkin vielä hyvin kaukana muodollisesta semantiikasta. On huomionarvoista, että triplettiattribuutit eivät ole URI:ita, ja näiden attribuuttien arvot voivat myös olla vain literaaleja. Nestekaasun kannattajat saavat juuri sen, mitä he halusivat. Erityisesti keksityssä NQX-muodossa esimerkki, joka on samanlainen kuin yllä oleva RDF*:lle, näyttää tältä:

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

V.2. Kyselykielet

Kun olet tukenut nestekaasua tavalla tai toisella mallitasolla, sinun on mahdollistettava kyselyjen tekeminen tällaisessa mallissa.

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

  • Anzograph tukee myös SPARQL* ja aikoo tukea Salakirjoitus, kyselykieli Neo4j:ssä.
  • Stardog tukee omaansa laajentaminen SPARQL ja uudelleen Gremlin. Voit saada tripletin URI:n ja "metatiedot" SPARQL:ssa käyttämällä jotain tällaista:

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

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

Muuten, GraphDB tuki aikoinaan Tinkerpop/Gremliniä ilman LPG-tukea, mutta tämä loppui versiossa 8.0 tai 8.1.

VI. Lisenssien tiukentaminen

Viime aikoina ei ole tehty lisäyksiä "triplestore of choice"- ja "open source triplestore" -sarjojen leikkauspisteeseen. Uudet avoimen lähdekoodin RDF-myymälät ovat kaukana hyvästä valinnasta jokapäiväiseen käyttöön, ja uudet kolminkertaiset myymälät, joita haluaisin käyttää (kuten AnzoGraph), ovat suljettuja lähdekoodia. Pikemminkin voidaan puhua laskuista...

Tietenkään avointa lähdekoodia ei ole suljettu aiemmin, mutta jotkin avoimen lähdekoodin tietovarastot eivät ole enää hitaasti valinnan arvoisia. Virtuoso, jolla on avoimen lähdekoodin versio, on mielestäni hukkumassa bugeihin. AWS osti Blazegraphin ja muodosti Amazon Neptunen perustan; nyt on epäselvää, tuleeko vielä ainakin yksi julkaisu. Vain Jena on jäljellä...

Jos avoin lähdekoodi ei ole kovin tärkeä, mutta haluat vain kokeilla sitä, kaikki on myös vähemmän ruusuista kuin ennen. Esimerkiksi:

  • Tähtikoira päättyy jakaa ilmaista versiota (tavallisen version kokeiluaika on kuitenkin kaksinkertaistunut);
  • в GraphDB Cloud, jossa aiemmin sai valita ilmaisen peruspaketin, uusien käyttäjien rekisteröinnit on keskeytetty.

Yleisesti ottaen keskiverto IT-ihmiselle tila on yhä vaikeampi saavuttaa, ja sen kehittäminen on tulossa yritysten armoille.

Lähde: will.com

Lisää kommentti