ProHoster > Blog > berita internet > Apakah yang berlaku dengan storan RDF sekarang?

Apakah yang berlaku dengan storan RDF sekarang?

Web Semantik dan Data Terpaut adalah seperti angkasa lepas: tiada kehidupan di sana. Untuk pergi ke sana untuk tempoh masa yang lebih kurang panjang... Saya tidak tahu apa yang mereka beritahu anda semasa kecil sebagai tindak balas kepada "Saya mahu menjadi angkasawan." Tetapi anda boleh memerhatikan apa yang berlaku semasa di Bumi; Lebih mudah untuk menjadi ahli astronomi amatur atau profesional.

Artikel ini akan memberi tumpuan kepada trend terkini, tidak lebih daripada beberapa bulan, daripada dunia storan RDF. Metafora dalam perenggan pertama diilhamkan oleh imej pengiklanan bersaiz epik di bawah potongan.


Gambar epik

Apakah yang berlaku dengan storan RDF sekarang?

I. GraphQL untuk akses RDF

Mereka katabahawa GraphQL bertujuan untuk menjadi bahasa capaian pangkalan data universal. Bagaimana pula dengan keupayaan untuk mengakses RDF menggunakan GraphQL?

Di luar kotak peluang ini disediakan oleh:

Jika repositori tidak memberikan peluang sedemikian, ia boleh dilaksanakan secara bebas dengan menulis "penyelesai" yang sesuai. Inilah yang mereka lakukan, sebagai contoh, dalam projek Perancis DataTourisme. Atau anda tidak lagi boleh menulis apa-apa, tetapi ambil sahaja HyperGraphQL.

Dari sudut pandangan penganut ortodoks Web Semantik dan Data Terpaut, semua ini, tentu saja, menyedihkan, kerana ia kelihatan direka untuk penyepaduan yang dibina di sekitar silo data seterusnya, dan bukan platform yang sesuai (kedai RDF, sudah tentu) .

Kesan daripada membandingkan GraphQL dengan SPARQL adalah dua kali ganda.

  • Di satu pihak, GraphQL kelihatan seperti saudara jauh SPARQL: ia menyelesaikan masalah pensampelan semula dan kepelbagaian pertanyaan yang biasa untuk REST - tanpanya, mungkin, ia tidak mungkin untuk dipertimbangkan bahasa pertanyaan, sekurang-kurangnya untuk web;
  • Sebaliknya, skema tegar GraphQL mengecewakan. Sehubungan itu, "introspektif"nya kelihatan sangat terhad berbanding dengan kelenturan penuh RDF. Dan tiada analog laluan harta benda, jadi ia tidak begitu jelas mengapa ia "Graf-".

II. Penyesuai untuk MongoDB

Trend pelengkap kepada yang sebelumnya.

  • Di Stardog sekarang mungkin - khususnya, semua pada GraphQL yang sama - konfigurasikan pemetaan data MongoDB ke dalam graf RDF maya;
  • Ontotext GraphDB baru-baru ini membolehkan masukkan serpihan ke dalam SPARQL pada MongoDB Query.

Jika kita bercakap dengan lebih meluas tentang penyesuai kepada sumber JSON, yang membenarkan lebih kurang "dengan cepat" untuk mewakili JSON yang disimpan dalam sumber ini sebagai RDF, kita boleh mengingati yang agak lama SPARQL Menjana, yang boleh dilaraskan, sebagai contoh, kepada Apache Jena.

Merumuskan dua aliran pertama, kita boleh mengatakan bahawa storan RDF menunjukkan kesediaan penuh untuk penyepaduan dan operasi dalam keadaan "kegigihan poliglot". Walau bagaimanapun, diketahui bahawa yang terakhir ini telah lama ketinggalan zaman, dan sedang digantikan oleh akan datang pelbagai model. Bagaimana pula dengan pemodelan berbilang dalam dunia storan RDF?

Pendek kata, tidak mungkin. Saya ingin mendedikasikan artikel berasingan kepada topik DBMS berbilang model, tetapi buat masa ini boleh diperhatikan bahawa pada masa ini tiada DBMS berbilang model "berasaskan" pada model graf (RDF boleh dianggap sebagai sejenisnya) . Beberapa pemodelan berbilang kecil - sokongan storan RDF untuk model graf LPG alternatif - akan dibincangkan dalam bahagian V.

III. OLTP lwn. OLAP

Walau bagaimanapun, Gartner yang sama menulismultimodel itu adalah syarat sine qua non terutamanya untuk bilik bedah DBMS. Ini boleh difahami: dalam situasi "storan berbilang", masalah utama timbul dengan transaksi.

Tetapi di manakah storan RDF terletak pada skala OLTP-OLAP? Saya akan menjawab dengan cara ini: tidak di sana mahupun di sini. Untuk menunjukkan tujuannya, beberapa singkatan ketiga diperlukan. Sebagai pilihan saya akan mencadangkan OLIP β€” Pemprosesan Intelek Dalam Talian.

Walau bagaimanapun, masih:

  • mekanisme penyepaduan dengan MongoDB yang dilaksanakan dalam GraphDB tidak kurang dimaksudkan untuk menyelesaikan masalah menulis prestasi;
  • Stardog pergi lebih jauh dan sepenuhnya menulis semula enjin, sekali lagi dengan matlamat untuk meningkatkan prestasi rakaman.

Sekarang izinkan saya memperkenalkan pemain baharu kepada pasaran. Daripada pencipta IBM Netezza dan Amazon Redshift - AnzoGraphβ„’. Gambar daripada iklan untuk produk berdasarkannya telah disiarkan pada permulaan artikel. AnzoGraph meletakkan dirinya sebagai penyelesaian GOLAP. Bagaimanakah anda menyukai SPARQL dengan fungsi tetingkap? β€”

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

IV. RocksDB

Sudah lebih tinggi ada pautan kepada pengumuman Stardog 7 Beta, yang mengatakan bahawa Stardog akan menggunakan RocksDB sebagai sistem storan asas - kedai nilai kunci, garpu Facebook LevelDB Google. Mengapa patut bercakap tentang trend tertentu?

Pertama, dinilai oleh Artikel Wikipedia, bukan sahaja storan RDF "dipindahkan" ke RocksDB. Terdapat projek untuk menggunakan RocksDB sebagai enjin storan dalam ArangoDB, MongoDB, MySQL dan MariaDB, Cassandra.

Kedua, projek (iaitu, bukan produk) mengenai topik yang berkaitan dibuat di RocksDB.

Sebagai contoh, eBay menggunakan RocksDB dalam platform untuk "graf pengetahuan" anda. By the way, kelakar baca: bahasa pertanyaan bermula sebagai format buatan sendiri, tetapi baru-baru ini ia telah berubah menjadi lebih seperti SPARQL. Seperti dalam jenaka: tidak kira berapa banyak graf pengetahuan yang kita buat, kita tetap mendapat RDF.

Contoh lain - yang muncul beberapa bulan lalu Perkhidmatan Pertanyaan Sejarah Wikidata. Sebelum pengenalannya, maklumat sejarah Wikidata perlu diakses melalui MWAPI kepada API Mediawiki standard. Sekarang banyak yang boleh dilakukan dengan SPARQL tulen. "Di bawah tudung" terdapat juga RocksDB. Ngomong-ngomong, WDHQS telah dibuat, nampaknya, oleh orang yang mengimport Freebase ke dalam Graf Pengetahuan Google.

V. Sokongan LPG

Biar saya ingatkan anda tentang perbezaan utama antara graf LPG dan graf RDF.

Dalam LPG, sifat skalar boleh ditetapkan kepada contoh tepi, manakala dalam RDF ia hanya boleh ditetapkan kepada "jenis" tepi (tetapi bukan sahaja sifat skalar, tetapi juga sambungan biasa). Had RDF ini berbanding LPG diatasi satu atau teknik pemodelan yang lain. Keterbatasan LPG berbanding RDF lebih sukar untuk diatasi, tetapi graf LPG lebih seperti gambar dari buku teks Harari daripada graf RDF, itulah sebabnya orang mahukannya.

Jelas sekali, tugas "sokongan LPG" terbahagi kepada dua bahagian:

  1. membuat perubahan pada model RDF yang memungkinkan untuk mensimulasikan struktur LPG di dalamnya;
  2. membuat perubahan pada bahasa pertanyaan RDF yang memungkinkan untuk mengakses data dalam model yang diubah suai ini, atau melaksanakan keupayaan untuk membuat pertanyaan kepada model ini dalam bahasa pertanyaan LPG yang popular.

V.1. Model data

Terdapat beberapa pendekatan yang mungkin di sini.

V.1.1. Hartanah Singleton

Pendekatan yang paling literal untuk mengharmonikan RDF dan LPG mungkin harta tunggal:

  • Sebaliknya, sebagai contoh, predikat :isMarriedTo predikat digunakan :isMarriedTo1, :isMarriedTo2 dan t. d.
  • Predikat ini kemudiannya menjadi subjek kembar tiga baharu: :isMarriedTo1 :since "2013-09-13"^^xsd:date dan lain-lain
  • Sambungan kejadian predikat ini dengan predikat sepunya diwujudkan oleh kembar tiga bentuk :isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo.
  • Jelas sekali, rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type, tetapi fikirkan mengapa anda tidak sepatutnya menulis sahaja :isMarriedTo1 rdf:type :isMarriedTo.

Masalah "sokongan LPG" diselesaikan di sini pada peringkat RDFS. Keputusan sedemikian memerlukan penyertaan dalam yang sesuai standard. Beberapa perubahan mungkin diperlukan untuk kedai RDF yang menyokong akibat melampirkan, tetapi buat masa ini, Singleton Property boleh dianggap sebagai teknik pemodelan lain.

V.1.2. Reifikasi Dilakukan Betul

Pendekatan yang kurang naif berpunca daripada kesedaran bahawa contoh harta boleh segera sepenuhnya oleh kembar tiga. Dengan dapat mengatakan sesuatu tentang kembar tiga, kita akan dapat bercakap tentang contoh harta benda.

Pendekatan yang paling mantap ialah RDF*, aka RDR, dilahirkan di kedalaman Blazegraph. Ia dari awal lagi dipilih untuk diri sendiri dan AnzoGraph. Kekukuhan pendekatan ditentukan oleh fakta bahawa dalam rangka kerjanya ditawarkan perubahan yang sepadan dalam Semantik RDF. Intinya, bagaimanapun, adalah sangat mudah. Dalam penyiaran Penyu RDF kini anda boleh menulis sesuatu seperti ini:

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

V.1.3. Pendekatan lain

Anda tidak boleh bersusah payah dengan semantik formal, tetapi hanya menganggap bahawa kembar tiga mempunyai pengecam tertentu, yang sudah tentu, URI, dan mencipta kembar tiga baharu dengan URI ini. Yang tinggal hanyalah memberikan akses kepada URI ini dalam SPARQL. Jadi tiba Stardog.

Dalam Allegrograph pergi secara perantaraan. Adalah diketahui bahawa pengecam triplet dalam Allegrograph ada, tetapi apabila melaksanakan atribut tiga kali ganda ia tidak kekal. Walau bagaimanapun, ia masih jauh dari semantik formal. Perlu diperhatikan bahawa atribut triplet bukan URI, dan nilai atribut ini juga boleh hanya literal. Penganut LPG mendapat apa yang mereka mahukan. Dalam format NQX yang dicipta khas, contoh yang serupa dengan yang di atas untuk RDF* kelihatan seperti ini:

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

V.2. Bahasa pertanyaan

Setelah menyokong LPG dalam satu cara atau yang lain pada peringkat model, anda perlu membolehkan anda membuat pertanyaan tentang data dalam model sedemikian.

  • Blazegraph untuk pertanyaan RDF* menyokong SPARQL* ΠΈ Gremlin. Pertanyaan SPARQL* kelihatan seperti ini:

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

  • Anzograph juga menyokong SPARQL* dan akan menyokong Memecahkan, bahasa pertanyaan dalam Neo4j.
  • Stardog menyokongnya sendiri pembesaran SPARQL dan sekali lagi Gremlin. Anda boleh mendapatkan triplet URI dan "meta-information" dalam SPARQL menggunakan sesuatu seperti ini:

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

  • Allegrograph juga menyokongnya sendiri pembesaran SPARQL:

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

Ngomong-ngomong, GraphDB pada satu masa menyokong Tinkerpop/Gremlin tanpa menyokong LPG, tetapi ini berhenti dalam versi 8.0 atau 8.1.

VI. Mengetatkan lesen

Tiada penambahan baru-baru ini pada persimpangan set "triplestore of choice" dan "open source triplestore". Kedai RDF sumber terbuka baharu adalah jauh daripada menjadi pilihan yang baik untuk kegunaan harian, dan kedai tiga kali ganda baharu yang saya ingin gunakan (seperti AnzoGraph) adalah sumber tertutup. Sebaliknya, kita boleh bercakap tentang penurunan...

Sudah tentu, sumber terbuka tidak pernah ditutup pada masa lalu, tetapi beberapa repositori sumber terbuka perlahan-lahan tidak lagi dilihat sebagai berbaloi untuk dipilih. Virtuoso, yang mempunyai edisi sumber terbuka, pada pendapat saya, tenggelam dalam pepijat. Blazegraph telah dibeli oleh AWS dan membentuk asas Amazon Neptune; kini tidak jelas sama ada akan ada sekurang-kurangnya satu keluaran lagi. Hanya tinggal Jena...

Jika sumber terbuka tidak begitu penting, tetapi anda hanya mahu mencubanya, maka semuanya juga kurang cerah daripada sebelumnya. Sebagai contoh:

  • Stardog tamat mengedarkan versi percuma (namun, tempoh percubaan versi biasa telah meningkat dua kali ganda);
  • Π² Awan GraphDB, di mana sebelum ini anda boleh memilih pelan asas percuma, pendaftaran pengguna baharu telah digantung.

Secara umum, bagi orang IT biasa, ruang semakin tidak dapat diakses; perkembangannya menjadi banyak syarikat.

Sumber: www.habr.com

Tambah komen