yang db
1.0.0
https://www.yangdb.org/
wiki
Info Versi
Rilis.catatan
Lior Perry
Margolis Romawi
Moti Cohen
Elad Wies
Shimon Benoshti
Sebuah Postingan yang memperkenalkan inisiatif Open source baru kami untuk membangun DB Grafik Terdistribusi yang Dapat Diskalakan Melalui Opensearch https://www.linkedin.com/pulse/making-db-lior-perry/
Penggunaan lain Opensearch sebagai DB grafik https://medium.com/@imriqwe/elasticsearch-as-a-graph-database-bc0eee7f7622
Dunia database grafik telah memberikan dampak yang luar biasa selama beberapa tahun terakhir, khususnya yang berkaitan dengan jejaring sosial dan pengaruhnya terhadap aktivitas kita sehari-hari.
RDBMS yang tadinya perkasa (dan sepi) kini berkewajiban memberi ruang bagi mitra baru dan semakin penting dalam pusat data: database grafik.
Twitter menggunakannya, Facebook menggunakannya, bahkan situs kencan online pun menggunakannya; mereka menggunakan grafik hubungan. Bagaimanapun, sosial adalah sosial, dan pada akhirnya, ini semua tentang hubungan.
Ada dua elemen utama yang membedakan teknologi grafik: penyimpanan dan pemrosesan.
Penyimpanan grafik biasanya mengacu pada struktur database yang berisi data grafik.
Penyimpanan grafik tersebut dioptimalkan untuk grafik dalam banyak aspek, memastikan bahwa data disimpan secara efisien, menjaga node dan hubungan tetap dekat satu sama lain di lapisan fisik sebenarnya.
Penyimpanan grafik diklasifikasikan sebagai non-asli jika penyimpanan berasal dari sumber luar, seperti database relasional, kolom, atau jenis database lainnya (dalam banyak kasus, penyimpanan NoSQL lebih disukai)
Basis data grafik non-asli biasanya terdiri dari penyimpanan nilai relasional, dokumen, dan kunci yang sudah ada, yang disesuaikan untuk skenario kueri model data grafik.
Pemrosesan Grafik mencakup mengakses grafik, melintasi simpul & tepi, dan mengumpulkan hasilnya.
Traversal adalah cara Anda membuat kueri grafik, bernavigasi dari node awal ke node terkait, mengikuti hubungan berdasarkan beberapa aturan.
menemukan jawaban atas pertanyaan seperti "musik apa yang disukai teman-teman saya yang belum saya miliki?"
Salah satu model yang lebih populer untuk merepresentasikan grafik adalah Model Properti.
Model ini berisi entitas terhubung (node) yang dapat menampung sejumlah atribut (pasangan nilai kunci).
Node memiliki id unik dan daftar atribut yang mewakili fitur dan kontennya.
Node dapat ditandai dengan label yang mewakili peran berbeda-beda di domain Anda. Selain properti hubungan, label juga dapat menyajikan metadata pada elemen grafik.
Node sering digunakan untuk mewakili entitas tetapi bergantung pada hubungan domainnya, node juga dapat digunakan untuk tujuan tersebut.
Hubungan diwakili oleh node sumber dan target yang dihubungkan dan jika ada beberapa koneksi antara simpul yang sama – label properti tambahan untuk membedakan (jenis hubungan)
Relasi mengatur titik-titik ke dalam struktur-struktur yang berubah-ubah, sehingga grafik dapat menyerupai daftar, pohon, peta, atau entitas gabungan — yang mana pun dapat digabungkan menjadi struktur yang lebih kompleks.
Mirip sekali dengan kunci asing antar tabel pada model DB relasional, pada model graf relasi menggambarkan relasi antar simpul.
Salah satu perbedaan utama dalam model ini (dibandingkan dengan skema relasional ketat) adalah bahwa struktur tanpa skema ini memungkinkan penambahan/penghapusan hubungan antar simpul tanpa batasan apa pun.
Model grafik tambahan adalah model Resource Description Framework (RDF).
Kasus penggunaan kami berada dalam domain jejaring sosial. Grafik sosial yang sangat besar yang harus sering diperbarui dan tersedia untuk keduanya:
pencarian sederhana (kebanyakan tekstual).
kueri berbasis grafik.
Semua proses baca & tulis dilakukan secara bersamaan dengan waktu respons yang wajar dan throughput yang terus meningkat.
Persyaratan pertama dipenuhi dengan menggunakan Opensearch – mesin pencari dan penyimpanan dokumen NoSql yang terkenal dan mapan yang mampu memuat data dalam jumlah sangat besar.
Untuk persyaratan kedua , kami memutuskan bahwa solusi terbaik kami adalah menggunakan Opensearch sebagai lapisan penyimpanan DB grafik non-asli .
Seperti disebutkan sebelumnya, lapisan penyimpanan graph-DB dapat diimplementasikan menggunakan penyimpanan non-asli seperti penyimpanan NoSql.
Dalam diskusi selanjutnya saya akan menjelaskan secara rinci mengapa alternatif komunitas paling populer untuk graph-DB – Neo4J, tidak sesuai dengan kebutuhan kita.
Masalah pertama yang harus kita hadapi adalah merancang model data yang mewakili grafik, sebagai kumpulan simpul dan tepi.
Dengan Opensearch kita dapat memanfaatkan kemampuan pencariannya yang kuat untuk mengambil dokumen node & relasi secara efisien sesuai dengan filter kueri.
Dalam Opensearch setiap indeks dapat digambarkan sebagai tabel untuk skema tertentu, indeks itu sendiri dipartisi menjadi berbagi yang memungkinkan skala dan redundansi (dengan replika) di seluruh cluster.
Sebuah dokumen dirutekan ke pecahan tertentu dalam indeks menggunakan rumus berikut:
shard_num = hash(_routing) % num_primary_shards
Setiap indeks memiliki skema (disebut tipe di Opensearch) yang mendefinisikan struktur dokumen (disebut pemetaan di Opensearch). Setiap indeks hanya dapat menampung satu jenis pemetaan (sejak Opensearch 6)
Indeks simpul akan berisi dokumen simpul dengan propertinya, indeks tepi akan berisi dokumen tepi dengan propertinya.
Cara kami menjelaskan cara melintasi grafik (sumber data)
Ada beberapa bahasa kueri berorientasi grafik:
Cypher adalah bahasa kueri untuk database grafik Neo4j (lihat initatif openCypher)
Gremlin adalah bahasa traversal grafik Apache Software Foundation untuk sistem grafik OLTP dan OLAP.
SPARQL adalah bahasa kueri untuk grafik RDF.
Beberapa bahasa lebih berbasis pola dan deklaratif, ada pula yang lebih penting – semuanya menggambarkan cara logis dalam melintasi data.
Mari kita pertimbangkan Cypher - bahasa deklaratif yang terinspirasi SQL untuk mendeskripsikan pola dalam grafik secara visual menggunakan sintaksis ascii-art.
Hal ini memungkinkan kita untuk menyatakan apa yang ingin kita pilih, sisipkan, perbarui atau hapus dari data grafik kita tanpa mengharuskan kita untuk menjelaskan secara tepat bagaimana melakukannya.
Setelah kueri logis diberikan, kita perlu menerjemahkannya ke lapisan fisik penyimpanan data yaitu Opensearch.
Opensearch memiliki kueri DSL yang berfokus pada penelusuran dan agregasi – bukan pada penelusuran, kami memerlukan fase penerjemahan tambahan yang akan mempertimbangkan struktur skema grafik (dan indeks yang mendasarinya).
Terjemahan kueri logis ke fisik adalah proses yang melibatkan beberapa langkah:
memvalidasi kueri terhadap skema
menerjemahkan label menjadi entitas skema nyata (indeks)
membuat kueri Opensearch fisik
Ini adalah proses dalam tinjauan tingkat tinggi, dalam praktiknya - akan ada lebih banyak tahapan yang mengoptimalkan kueri logis; dalam beberapa kasus dimungkinkan untuk membuat beberapa rencana fisik (rencana eksekusi) dan memeringkatnya berdasarkan beberapa strategi efisiensi (biaya) seperti jumlah elemen yang diperlukan untuk mengambil...
Kami mulai dengan membahas tujuan DB grafik dalam kasus penggunaan bisnis saat ini dan meninjau berbagai model untuk merepresentasikan grafik. Memahami blok bangunan logis mendasar yang harus terdiri dari grafik DB potensial dan mendiskusikan kandidat NoSql yang ada untuk memenuhi persyaratan lapisan penyimpanan.
Setelah kami memilih Opensearch sebagai lapisan penyimpanan, kami mengambil model grafik Tolok Ukur Jaringan Sosial LDBC dan menyederhanakannya agar dioptimalkan dalam penyimpanan spesifik tersebut. Kami membahas skema penyimpanan aktual dengan properti redundan dan meninjau bahasa sandi untuk menanyakan penyimpanan dalam bahasa pola grafik mirip sql.
Kami terus melihat transformasi sebenarnya dari kueri sandi menjadi kueri eksekusi fisik yang akan dijalankan oleh Opensearch.
Di bagian terakhir kami mengambil kueri grafik sederhana dan menelusuri detail strategi eksekusi dan mekanisme bulking.
Tutorial instalasi:
Tutorial pembuatan skema:
Tutorial Memuat Data:
Kueri tutorial Grafik:
Tutorial materialisasi & penghitungan proyeksi:
