ProHoster > blog > berita internet > Apa yang terjadi dengan penyimpanan RDF sekarang?

Apa yang terjadi dengan penyimpanan RDF sekarang?

Web Semantik dan Data Tertaut seperti luar angkasa: tidak ada kehidupan di sana. Untuk pergi ke sana untuk jangka waktu yang kurang lebih lama... Saya tidak tahu apa yang mereka katakan kepada Anda sebagai seorang anak sebagai tanggapan terhadap "Saya ingin menjadi astronot". Tapi Anda bisa mengamati apa yang terjadi saat berada di Bumi; Jauh lebih mudah untuk menjadi astronom amatir atau bahkan profesional.

Artikel ini akan berfokus pada tren terkini, tidak lebih dari beberapa bulan, dari dunia penyimpanan RDF. Metafora pada paragraf pertama terinspirasi oleh gambar iklan berukuran epik yang sedang dipotong.


Gambar epik

Apa yang terjadi dengan penyimpanan RDF sekarang?

I. GraphQL untuk akses RDF

Mereka bilangbahwa GraphQL bertujuan untuk menjadi bahasa akses database universal. Bagaimana dengan kemampuan mengakses RDF menggunakan GraphQL?

Di luar kotak, peluang ini disediakan oleh:

Jika repositori tidak memberikan kesempatan seperti itu, maka dapat diimplementasikan secara mandiri dengan menulis “resolver” yang sesuai. Inilah yang mereka lakukan, misalnya, dalam proyek Perancis Pariwisata Data. Atau Anda tidak bisa lagi menulis apa pun, tetapi ambil saja HyperGraphQL.

Dari sudut pandang penganut ortodoks Web Semantik dan Data Tertaut, semua ini, tentu saja, menyedihkan, karena tampaknya dirancang untuk integrasi yang dibangun di sekitar silo data berikutnya, dan bukan platform yang sesuai (tentu saja penyimpanan RDF) .

Kesan dari membandingkan GraphQL dengan SPARQL ada dua.

  • Di satu sisi, GraphQL terlihat seperti kerabat jauh SPARQL: ia memecahkan masalah pengambilan sampel ulang dan banyaknya kueri yang khas untuk REST - yang tanpanya, mungkin, tidak mungkin untuk mempertimbangkannya. bahasa kueri, setidaknya untuk web;
  • Di sisi lain, skema GraphQL yang kaku mengecewakan. Oleh karena itu, “introspeksi”-nya tampaknya sangat terbatas dibandingkan dengan refleksivitas penuh RDF. Dan tidak ada analogi jalur properti, jadi tidak begitu jelas mengapa ini adalah "Grafik-".

II. Adaptor untuk MongoDB

Sebuah tren yang melengkapi tren sebelumnya.

  • Di Stardog sekarang mungkin - khususnya, semuanya dalam GraphQL yang sama - konfigurasikan pemetaan data MongoDB ke dalam grafik RDF virtual;
  • Ontotext GraphDB baru-baru ini memungkinkan masukkan fragmen ke SPARQL pada MongoDB Query.

Jika kita berbicara lebih luas tentang adaptor ke sumber JSON, yang memungkinkan lebih atau kurang "on the fly" untuk mewakili JSON yang disimpan dalam sumber-sumber ini sebagai RDF, kita dapat mengingat kembali masa lalu yang cukup lama. Hasilkan SPARQL, yang dapat disesuaikan, misalnya, ke Apache Jena.

Meringkas dua tren pertama, kita dapat mengatakan bahwa penyimpanan RDF menunjukkan kesiapan penuh untuk integrasi dan pengoperasian dalam kondisi “persistensi poliglot”. Namun diketahui bahwa yang terakhir ini sudah lama ketinggalan zaman, dan digantikan oleh datang multi-model. Bagaimana dengan multi-pemodelan di dunia penyimpanan RDF?

Singkatnya, tidak mungkin. Saya ingin mendedikasikan artikel terpisah untuk topik DBMS multi-model, tetapi untuk saat ini dapat dicatat bahwa saat ini tidak ada DBMS multi-model yang “berdasarkan” model grafik (RDF dapat dianggap sebagai salah satu jenisnya) . Beberapa multi-pemodelan kecil - dukungan penyimpanan RDF untuk model grafik LPG alternatif - akan dibahas di bagian V.

AKU AKU AKU. OLTP vs. OLAP

Namun, Gartner yang sama menulismultimodel itu adalah kondisi sine qua non yang utama ruang operasi DBMS. Hal ini dapat dimengerti: dalam situasi “penyimpanan multivariat”, masalah utama muncul dengan transaksionalitas.

Namun di manakah lokasi penyimpanan RDF pada skala OLTP-OLAP? Saya akan menjawab seperti ini: tidak di sana atau di sini. Untuk menunjukkan tujuannya, diperlukan singkatan ketiga. Sebagai opsi, saya sarankan OLIP — Pemrosesan Intelektual Online.

Namun, tetap saja:

  • mekanisme integrasi dengan MongoDB yang diterapkan di GraphDB juga tidak kalah pentingnya disengaja untuk mengatasi masalah kinerja penulisan;
  • Stardog melangkah lebih jauh dan sepenuhnya menulis ulang mesin, sekali lagi dengan tujuan meningkatkan kinerja perekaman.

Sekarang izinkan saya memperkenalkan pemain baru ke pasar. Dari pencipta IBM Netezza dan Amazon Redshift - AnzoGraph™. Gambar dari iklan suatu produk berdasarkan itu diposting di awal artikel. AnzoGraph memposisikan dirinya sebagai solusi GOLAP. Bagaimana Anda menyukai SPARQL dengan fungsi jendela? —

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

IV. BatuDB

Sudah lebih tinggi ada tautan hingga pengumuman Stardog 7 Beta, yang mengatakan bahwa Stardog akan menggunakan RocksDB sebagai sistem penyimpanan yang mendasarinya - penyimpanan nilai kunci, cabang Facebook dari LevelDB Google. Mengapa penting membicarakan tren tertentu?

Pertama, dilihat dari artikel Wikipedia, tidak hanya penyimpanan RDF yang “ditransplantasikan” ke RocksDB. Ada proyek untuk menggunakan RocksDB sebagai mesin penyimpanan di ArangoDB, MongoDB, MySQL dan MariaDB, Cassandra.

Kedua, proyek (yaitu, bukan produk) dengan topik relevan dibuat di RocksDB.

Misalnya, eBay menggunakan RocksDB di dalamnya peron untuk "grafik pengetahuan" Anda. Ngomong-ngomong, lucu sekali membaca: bahasa kueri dimulai sebagai format yang dikembangkan sendiri, namun belakangan ini telah bertransisi menjadi lebih mirip SPARQL. Seperti dalam lelucon: tidak peduli berapa banyak grafik pengetahuan yang kita buat, kita tetap mendapatkan RDF.

Contoh lainnya adalah yang muncul beberapa bulan lalu Layanan Kueri Riwayat Wikidata. Sebelum diperkenalkan, informasi sejarah Wikidata harus diakses melalui MWAPI ke API Mediawiki standar. Sekarang banyak hal dapat dilakukan dengan SPARQL murni. “Di balik terpal” ada juga RocksDB. Omong-omong, WDHQS tampaknya dibuat oleh orang yang mengimpor Freebase ke Grafik Pengetahuan Google.

V.Dukungan LPG

Izinkan saya mengingatkan Anda tentang perbedaan utama antara grafik LPG dan grafik RDF.

Di LPG, properti skalar dapat ditetapkan ke instance tepi, sedangkan di RDF properti tersebut hanya dapat ditetapkan ke “tipe” tepi (tetapi tidak hanya properti skalar, tetapi juga koneksi biasa). Keterbatasan RDF dibandingkan dengan LPG mengatasi satu atau beberapa teknik pemodelan. Keterbatasan LPG dibandingkan dengan RDF lebih sulit untuk diatasi, namun grafik LPG lebih mirip gambar dari buku teks Harari dibandingkan grafik RDF, itulah sebabnya orang menginginkannya.

Jelasnya, tugas “dukungan LPG” terbagi menjadi dua bagian:

  1. melakukan perubahan pada model RDF yang memungkinkan dilakukannya simulasi struktur LPG di dalamnya;
  2. membuat perubahan pada bahasa kueri RDF yang memungkinkan untuk mengakses data dalam model yang dimodifikasi ini, atau menerapkan kemampuan untuk membuat kueri ke model ini dalam bahasa kueri LPG yang populer.

V.1. Model data

Ada beberapa kemungkinan pendekatan di sini.

V.1.1. Properti Tunggal

Pendekatan yang paling literal untuk menyelaraskan RDF dan LPG mungkin adalah properti tunggal:

  • Daripada, misalnya, predikat :isMarriedTo predikat digunakan :isMarriedTo1, :isMarriedTo2 dan t. d.
  • Predikat berikut kemudian menjadi subjek si kembar tiga baru: :isMarriedTo1 :since "2013-09-13"^^xsd:date dan lain-lain
  • Hubungan contoh-contoh predikat ini dengan predikat umum ditentukan oleh bentuk kembar tiga :isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo.
  • Jelas, rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type, tetapi pikirkan mengapa Anda tidak boleh menulis saja :isMarriedTo1 rdf:type :isMarriedTo.

Masalah “dukungan LPG” diselesaikan di sini di tingkat RDFS. Keputusan seperti itu memerlukan penyertaan dalam keputusan yang sesuai standar. Beberapa perubahan mungkin diperlukan untuk penyimpanan RDF yang mendukung pelekatan konsekuensi, namun untuk saat ini, Singleton Property dapat dianggap hanya sebagai teknik pemodelan lainnya.

V.1.2. Reifikasi Dilakukan dengan Benar

Pendekatan yang kurang naif berasal dari kesadaran bahwa contoh properti sepenuhnya dapat digunakan oleh kembar tiga. Dengan bisa mengatakan sesuatu tentang kembar tiga, kita akan bisa membicarakan tentang contoh properti.

Pendekatan yang paling kuat adalah RDF*, alias RDR, dilahirkan di kedalaman Blazegraph. Itu dari awal terpilih untuk Anda sendiri dan AnzoGraph. Soliditas pendekatan ditentukan oleh apa yang ada dalam kerangkanya ditawarkan perubahan yang sesuai dalam Semantik RDF. Namun, intinya sangatlah sederhana. Dalam serialisasi Turtle RDF Anda sekarang dapat menulis sesuatu seperti ini:

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

V.1.3. Pendekatan lain

Anda tidak dapat repot dengan semantik formal, tetapi asumsikan saja bahwa kembar tiga memiliki pengidentifikasi tertentu, yang tentu saja merupakan URI, dan buat kembar tiga baru dengan URI ini. Yang tersisa hanyalah memberikan akses ke URI ini di SPARQL. Jadi tiba anjing bintang.

Dalam Allegrograf Ayo pergi dengan cara perantara. Diketahui bahwa pengidentifikasi triplet di Allegrograph ada, tetapi saat menerapkan tiga atribut, atribut tersebut tidak menonjol. Namun, masih sangat jauh dari semantik formal. Perlu dicatat bahwa atribut triplet bukanlah URI, dan nilai atribut ini juga hanya dapat berupa literal. Penganut LPG mendapatkan apa yang mereka inginkan. Dalam format NQX yang diciptakan khusus, contoh serupa dengan yang di atas untuk RDF* terlihat seperti ini:

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

V.2. Bahasa kueri

Setelah mendukung LPG dengan satu atau lain cara pada tingkat model, Anda perlu memungkinkan pembuatan kueri pada data dalam model tersebut.

  • Blazegraph untuk kueri RDF* mendukung SPARQL* и Gremlin. Kueri SPARQL* terlihat seperti ini:

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

  • Anzograph juga mendukung SPARQL* dan akan mendukung Nol, bahasa kueri di Neo4j.
  • Stardog mendukungnya sendiri pembesaran SPARQL dan lagi Gremlin. Anda bisa mendapatkan triplet URI dan "meta-informasi" di SPARQL menggunakan sesuatu seperti ini:

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

  • Allegrograph juga mendukungnya sendiri pembesaran SPARQL:

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

Omong-omong, GraphDB pernah mendukung Tinkerpop/Gremlin tanpa mendukung LPG, tetapi ini berhenti di versi 8.0 atau 8.1.

VI. Pengetatan izin

Belum ada penambahan baru-baru ini pada persilangan rangkaian “triplestore pilihan” dan “triplestore sumber terbuka”. Penyimpanan RDF open source baru masih jauh dari pilihan yang baik untuk penggunaan sehari-hari, dan triple store baru yang ingin saya gunakan (seperti AnzoGraph) adalah sumber tertutup. Sebaliknya, kita bisa berbicara tentang penurunan...

Tentu saja, open source belum pernah ditutup sebelumnya, namun beberapa repositori open source perlahan-lahan tidak lagi dianggap layak untuk dipilih. Virtuoso yang memiliki edisi opensource menurut saya tenggelam dalam bug. Blazegraph dibeli oleh AWS dan menjadi basis Amazon Neptune; sekarang tidak jelas apakah akan ada setidaknya satu rilis lagi. Hanya Jena yang tersisa...

Jika open source tidak terlalu penting, tetapi Anda hanya ingin mencobanya, maka segalanya juga menjadi kurang menyenangkan dibandingkan sebelumnya. Misalnya:

  • anjing bintang berhenti mendistribusikan versi gratis (namun, masa uji coba versi reguler menjadi dua kali lipat);
  • в Awan GraphDB, dimana sebelumnya Anda dapat memilih paket dasar gratis, pendaftaran pengguna baru telah ditangguhkan.

Secara umum, bagi rata-rata orang TI, ruang menjadi semakin tidak dapat diakses; perkembangannya menjadi tanggung jawab perusahaan.

Sumber: www.habr.com

Tambah komentar