ProHoster > Blog > internet haberleri > RDF depolamada şu anda neler oluyor?

RDF depolamada şu anda neler oluyor?

Anlamsal Web ve Bağlantılı Veriler uzay gibidir: orada yaşam yoktur. Aşağı yukarı uzun bir süre oraya gitmek... Çocukken “Astronot olmak istiyorum” cevabına ne derlerdi bilmiyorum. Ama Dünya'dayken neler olduğunu gözlemleyebilirsiniz; Amatör bir gökbilimci, hatta profesyonel olmak çok daha kolaydır.

Makale, RDF depolama dünyasındaki son birkaç aydan eski olmayan trendlere odaklanacak. İlk paragraftaki metafor, kesimin altındaki epik boyutlu reklam görselinden esinlenilmiştir.


Epik resim

RDF depolamada şu anda neler oluyor?

I. RDF erişimi için GraphQL

Diyorlar kiGraphQL'in evrensel bir veritabanı erişim dili olmayı hedeflediği. GraphQL kullanarak RDF'ye erişme yeteneği ne olacak?

Kutunun dışında bu fırsat şu şekilde sağlanır:

Eğer repository böyle bir imkan sağlamıyorsa uygun bir “resolver” yazılarak bağımsız olarak hayata geçirilebilir. Örneğin Fransız projesinde yaptıkları buydu. DataTurisme. Veya artık hiçbir şey yazamazsınız, sadece alın HyperGraphQL.

Anlamsal Web ve Bağlantılı Verilerin ortodoks bir taraftarı açısından bakıldığında, tüm bunlar elbette üzücü, çünkü bir sonraki veri silosu etrafında inşa edilen entegrasyonlar için tasarlanmış gibi görünüyor ve uygun platformlar (elbette RDF mağazaları) değil. .

GraphQL'i SPARQL ile karşılaştırmanın izlenimleri iki yönlüdür.

  • Bir yandan GraphQL, SPARQL'in uzak bir akrabası gibi görünüyor: REST için tipik olan yeniden örnekleme ve sorgu çokluğu sorunlarını çözüyor - bu olmadan muhtemelen dikkate alınması mümkün olmazdı. sorgu dilien azından web için;
  • Öte yandan GraphQL'in katı şeması hayal kırıklığı yaratıyor. Buna göre, RDF'nin tam dönüşlülüğüyle karşılaştırıldığında "içebakışlılığı" çok sınırlı görünüyor. Ve mülkiyet yollarının bir benzeri yok, bu yüzden neden "Grafik-" olduğu bile çok açık değil.

II. MongoDB için adaptörler

Bir öncekini tamamlayan bir trend.

  • Artık Stardog'da belki - özellikle hepsi aynı GraphQL üzerinde - MongoDB verilerinin sanal RDF grafiklerine eşlenmesini yapılandırın;
  • Ontotext GraphDB yakın zamanda verir MongoDB Sorgusunda SPARQL'e parçalar ekleyin.

JSON kaynaklarına yönelik, bu kaynaklarda depolanan JSON'u az çok "anında" RDF olarak temsil etmeye izin veren bağdaştırıcılar hakkında daha geniş konuşursak, oldukça uzun süredir devam eden bağdaştırıcıları hatırlayabiliriz. SPARQL Oluşturayarlanabilir, örneğin, Apache Jena'ya.

İlk iki eğilimi özetlersek, RDF depolarının “çok dilli kalıcılık” koşullarında entegrasyon ve operasyon için tam hazırlık gösterdiğini söyleyebiliriz. Ancak bu ikincisinin uzun süredir modası geçmiş olduğu ve yerini yeni bir modaya bıraktığı biliniyor. geliyor çoklu model. RDF depolama dünyasında çoklu modellemeye ne dersiniz?

Kısacası hiçbir şekilde. Çok modelli DBMS konusuna ayrı bir makale ayırmak isterim, ancak şimdilik şunu belirtmek isterim ki, şu anda bir grafik modeline "tabanlı" çok modelli DBMS yoktur (RDF bunun bir türü olarak kabul edilebilir) . Bazı küçük çoklu modellemeler - alternatif bir LPG grafik modeli için RDF depolama desteği - bu bölümde tartışılacaktır. Bölüm V.

III. OLTP vs. OLAP

Ancak aynı Gartner yazarçoklu modelin öncelikle olmazsa olmaz bir koşul olduğu ameliyathaneler DBMS. Bu anlaşılabilir bir durumdur: "Çok değişkenli depolama" durumunda, temel sorunlar işlemsellikle ortaya çıkar.

Peki RDF depoları OLTP-OLAP ölçeğinde nerede bulunur? Şu şekilde cevap vereceğim: ne orada ne de burada. Ne amaçla kullanıldıklarını belirtmek için üçüncü bir kısaltmaya ihtiyaç vardır. Bir seçenek olarak önereceğim OLİP — Çevrimiçi Fikri İşleme.

Ancak yine de:

  • GraphDB'de uygulanan MongoDB ile entegrasyon mekanizmaları en azından istenilen yazma performansı sorunlarını çözmek;
  • Stardog daha da ileri ve tamamen gidiyor yeniden yazar motor, yine kayıt performansını iyileştirme hedefiyle.

Şimdi piyasaya yeni bir oyuncuyu tanıtayım. IBM Netezza ve Amazon Redshift'in yaratıcılarından - AnzoGraph™. Makalenin başında buna dayalı bir ürünün reklamından bir resim yayınlandı. AnzoGraph kendisini bir GOLAP çözümü olarak konumlandırıyor. Pencere fonksiyonlarına sahip SPARQL'i nasıl buldunuz? —

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

IV. RocksDB

Zaten daha yüksek bir bağlantı vardı Stardog'un temel depolama sistemi olarak RocksDB'yi (bir anahtar-değer deposu, Google'ın LevelDB'sinin bir Facebook çatalı) kullanacağını söyleyen Stardog 7 Beta'nın duyurusuna. Neden belirli bir trend hakkında konuşmaya değer?

İlk olarak, yargılamak Vikipedi makalesiRocksDB'ye yalnızca RDF depoları "aktarılmaz". ArangoDB, MongoDB, MySQL ve MariaDB, Cassandra'da RocksDB'yi depolama motoru olarak kullanmaya yönelik projeler var.

İkinci olarak RocksDB'de ilgili konularda projeler (yani ürünler değil) oluşturulur.

Örneğin, eBay RocksDB'yi kullanıyor platform “bilgi grafiğiniz” için. Bu arada, okumak komik: Sorgu dili evde yetiştirilen bir format olarak başladı, ancak son zamanlarda SPARQL'e çok daha fazla benzeyecek şekilde geçiş yapıyor. Şakada olduğu gibi: Ne kadar bilgi grafiği yaparsak yapalım, yine de RDF ile karşılaşıyoruz.

Başka bir örnek, birkaç ay önce ortaya çıkan bir örnek Vikiveri Geçmişi Sorgulama Hizmeti. Tanıtılmadan önce, Vikiveri tarihi bilgilerine şu adresten erişilmesi gerekiyordu: MWAPI standart Mediawiki API'sine. Artık saf SPARQL ile çok şey mümkün. “Başlığın altında” ayrıca RocksDB var. Bu arada WDHQS, Freebase'i Google Bilgi Grafiği'ne aktaran kişi tarafından yapılmış gibi görünüyor.

V.LPG desteği

LPG grafikleri ile RDF grafikleri arasındaki temel farkı hatırlatayım.

LPG'de skaler özellikler kenar örneklerine atanabilirken, RDF'de bunlar yalnızca kenar "tiplerine" atanabilir (ancak yalnızca skaler özellikler değil, aynı zamanda sıradan bağlantılar da). LPG ile karşılaştırıldığında RDF'nin bu sınırlaması üstesinden gelmek şu veya bu modelleme tekniği. LPG'nin RDF'ye kıyasla sınırlamalarının üstesinden gelmek daha zordur, ancak LPG grafikleri RDF grafiklerinden çok Harari ders kitabındaki resimlere benzer, bu yüzden insanlar onları ister.

Açıkçası, “LPG desteğinin” görevi iki bölümden oluşuyor:

  1. RDF modelinde, içindeki LPG yapılarının simüle edilmesini mümkün kılan değişiklikler yapılması;
  2. Bu değiştirilmiş modeldeki verilere erişimi mümkün kılan RDF sorgulama dilinde değişiklikler yapılması veya bu modele popüler LPG sorgulama dillerinde sorgulama yeteneğinin uygulanması.

V.1. Veri örneği

Burada birkaç olası yaklaşım var.

V.1.1. Singleton Özelliği

RDF ve LPG'nin uyumlaştırılmasına yönelik en gerçek yaklaşım muhtemelen tekil özellik:

  • Örneğin yüklem yerine :isMarriedTo yüklemler kullanılır :isMarriedTo1, :isMarriedTo2 vb
  • Bu yüklemler daha sonra yeni üçlülerin konusu haline gelir: :isMarriedTo1 :since "2013-09-13"^^xsd:date vb
  • Bu yüklem örneklerinin ortak bir yüklemle bağlantısı, formun üçlüleri ile kurulur. :isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo.
  • Açıktır ki, rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type, ama neden sadece yazmamanız gerektiğini düşünün :isMarriedTo1 rdf:type :isMarriedTo.

“LPG desteği” sorunu burada RDFS düzeyinde çözülüyor. Böyle bir karar, uygun bir karara dahil edilmesini gerektirir. standart. Sonuçların eklenmesini destekleyen RDF depoları için bazı değişiklikler gerekebilir ancak şimdilik Singleton Property, başka bir modelleme tekniği olarak düşünülebilir.

V.1.2. Şeyleştirme Doğru Yapıldı

Daha az naif yaklaşımlar, özellik örneklerinin üçlü olarak tamamen somutlaştırılabileceğinin farkına varılmasından kaynaklanmaktadır. Üçüzler hakkında bir şeyler söyleyebilmekle mülkiyet örneklerinden de söz edebileceğiz.

Bu yaklaşımlardan en sağlam olanı RDF*nam-ı diğer RDR, doğmak Blazegraph'ın derinliklerinde. Bu en başından beri seçildi kendiniz ve AnzoGraph için. Yaklaşımın sağlamlığı, kendi çerçevesinde teklif edilir karşılık gelen değişiklikler RDF Semantiği. Ancak mesele son derece basittir. RDF'nin Kaplumbağa serileştirmesinde artık şöyle bir şey yazabilirsiniz:

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

V.1.3. Diğer yaklaşımlar

Biçimsel anlambilimle uğraşamazsınız, ancak üçlülerin belirli tanımlayıcılara sahip olduğunu varsayalım, bunlar elbette URI'lerdir ve bu URI'lerle yeni üçlüler oluştururlar. Geriye kalan tek şey SPARQL'deki bu URI'lere erişim izni vermektir. Bu yüzden поступает Yıldız köpeği.

Allegrograph'ta hadi gidelim orta düzeyde. Allegrograph'ta üçlü tanımlayıcıların olduğu bilinmektedir. var, ancak üçlü nitelikleri uygularken öne çıkmazlar. Ancak yine de biçimsel anlambilimden çok uzaktır. Üçlü niteliklerin URI olmadığı ve bu niteliklerin değerlerinin de yalnızca değişmez değerler olabileceği dikkat çekmektedir. LPG tutkunları tam olarak istediklerini elde ediyorlar. Özel olarak icat edilen NQX formatında, RDF* için yukarıdakine benzer bir örnek şuna benzer:

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

V.2. Sorgu dilleri

LPG'yi model düzeyinde bir şekilde destekledikten sonra, böyle bir modelde veri üzerinden sorgulama yapılmasını mümkün hale getirmeniz gerekiyor.

  • RDF* sorguları için Blazegraph destekleri SPARQL* и cin. Bir SPARQL* sorgusu şuna benzer:

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

  • Anzograph da destekliyor SPARQL* ve destek olacak ŞifreNeo4j'de bir sorgu dili.
  • Stardog kendi kendisini destekliyor uzatma SPARQL ve Yeniden Gremlin. Bunun gibi bir şey kullanarak SPARQL'deki üçlü URI'yi ve "meta bilgiyi" alabilirsiniz:

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

  • Allegrograph aynı zamanda kendi uzatma -Sparql:

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

Bu arada, GraphDB bir zamanlar LPG'yi desteklemeden Tinkerpop/Gremlin'i destekliyordu, ancak bu 8.0 veya 8.1 sürümlerinde durdu.

VI. Lisansların sıkılaştırılması

“Tercih edilen üçlü mağaza” ve “açık kaynaklı üçlü mağaza” setlerinin kesişimine yakın zamanda herhangi bir ekleme yapılmadı. Yeni açık kaynaklı RDF depoları günlük kullanım için iyi bir seçim olmaktan çok uzak ve kullanmak istediğim yeni üçlü mağazalar (AnzoGraph gibi) kapalı kaynak. Daha ziyade düşüşlerden söz edebiliriz...

Elbette açık kaynak geçmişte kapatılmadı, ancak bazı açık kaynak depoları yavaş yavaş artık seçilmeye değer görülmüyor. Açık kaynak kodlu bir sürümü olan Virtuoso, bana göre böcek içinde boğuluyor. Blazegraph, AWS tarafından satın alındı ​​ve Amazon Neptune'un temelini oluşturdu; şimdi en az bir sürüm daha olup olmayacağı belli değil. Geriye sadece Jena kaldı...

Açık kaynak çok önemli değilse ve sadece denemek istiyorsanız, o zaman her şey eskisinden daha az pembe olur. Örneğin:

  • yıldız köpeği durak ücretsiz sürümü dağıtın (ancak normal sürümün deneme süresi iki katına çıktı);
  • в GraphDB BulutuDaha önce ücretsiz bir temel plan seçebildiğiniz için yeni kullanıcı kayıtları askıya alındı.

Genel olarak, ortalama bir BT çalışanı için alan giderek daha erişilemez hale geliyor; alanın geliştirilmesi birçok şirketin meselesi haline geliyor.

Kaynak: habr.com

Yorum ekle