Apa itu database grafik? Cara yang lebih baik untuk menyimpan data yang terhubung

Nilai-kunci, berorientasi dokumen, kelompok kolom, grafik, relasional ... Hari ini kita tampaknya memiliki banyak jenis database seperti jumlah jenis data. Meskipun hal ini mungkin mempersulit pemilihan database, hal ini membuat pemilihan  database yang tepat menjadi lebih mudah. Tentu saja, itu membutuhkan pekerjaan rumah Anda. Anda harus mengetahui database Anda. 

Salah satu jenis database yang paling tidak dipahami di luar sana adalah database grafik. Didesain untuk bekerja dengan data yang sangat saling berhubungan, database grafik mungkin digambarkan lebih "relasional" daripada database relasional. Database grafik bersinar ketika tujuannya adalah untuk menangkap hubungan yang kompleks dalam jaringan informasi yang luas. 

Berikut ini adalah pandangan yang lebih dekat tentang apa itu database grafik, mengapa mereka tidak seperti database lain, dan jenis masalah data apa yang mereka bangun untuk diselesaikan.

Grafik database vs database relasional

Dalam database relasional atau SQL tradisional, data diatur ke dalam tabel. Setiap tabel mencatat data dalam format tertentu dengan jumlah kolom tetap, setiap kolom dengan tipe datanya sendiri (bilangan bulat, waktu / tanggal, teks bentuk bebas, dll.).

Model ini bekerja paling baik ketika Anda berurusan terutama dengan data dari satu tabel. Ini juga tidak berfungsi terlalu buruk saat Anda menggabungkan data yang disimpan di beberapa tabel. Tetapi perilaku itu memiliki beberapa batasan penting.

Pertimbangkan database musik, dengan album, band, label, dan artis. Jika Anda ingin melaporkan semua pemain yang tampil di ini album dengan yang Band dirilis pada ini label-empat yang berbeda tabel-Anda harus secara eksplisit menggambarkan hubungan mereka. Dengan database relasional, Anda melakukannya dengan cara kolom data baru (untuk hubungan satu-ke-satu atau satu-ke-banyak), atau tabel baru (untuk hubungan banyak-ke-banyak).

Ini praktis selama Anda mengelola sejumlah kecil hubungan. Jika Anda berurusan dengan jutaan atau bahkan milyaran hubungan — teman dari teman dari teman, misalnya — kueri tersebut tidak berkembang dengan baik.

Singkatnya, jika  hubungan antara data , bukan datanya sendiri, yang menjadi perhatian utama Anda, maka jenis database yang berbeda — database grafik — akan diatur.

Fitur database grafik

Istilah "grafik" berasal dari penggunaan kata dalam matematika. Di sana digunakan untuk mendeskripsikan kumpulan node (atau simpul ), masing-masing berisi informasi ( properti ), dan dengan hubungan berlabel (atau tepi ) antara node.

Jejaring sosial adalah contoh grafik yang bagus. Orang-orang di jaringan akan menjadi node, atribut setiap orang (seperti nama, usia, dan sebagainya) akan menjadi properti, dan garis yang menghubungkan orang-orang (dengan label seperti "teman" atau "ibu" atau " supervisor ”) akan menunjukkan hubungan mereka. 

Dalam database konvensional, kueri tentang hubungan bisa memakan waktu lama untuk diproses. Ini karena hubungan diimplementasikan dengan kunci asing dan dikueri dengan menggabungkan tabel. Seperti yang dapat diberitahukan oleh DBA SQL kepada Anda, melakukan penggabungan itu mahal, terutama saat Anda harus menyortir objek dalam jumlah besar — ​​atau, lebih buruk lagi, saat Anda harus menggabungkan beberapa tabel untuk melakukan jenis kueri tidak langsung (misalnya "teman dari teman") database grafik yang unggul. 

Database grafik bekerja dengan menyimpan  hubungan bersama dengan data. Karena node terkait secara fisik ditautkan dalam database, mengakses hubungan tersebut secepat mengakses data itu sendiri. Dengan kata lain, alih-alih menghitung hubungan seperti yang harus dilakukan database relasional, database grafik cukup membaca hubungan dari penyimpanan. Kueri yang memuaskan adalah masalah sederhana berjalan, atau "melintasi," grafik.  

Database grafik tidak hanya menyimpan hubungan antar objek dengan cara asli, membuat kueri tentang hubungan dengan cepat dan mudah, tetapi memungkinkan Anda untuk menyertakan berbagai jenis objek dan jenis hubungan yang berbeda dalam grafik. Seperti database NoSQL lainnya, database grafik tidak memiliki skema. Jadi, dalam hal kinerja dan fleksibilitas, database grafik lebih dekat dengan database dokumen atau penyimpanan nilai kunci daripada database relasional atau berorientasi tabel.

Buat grafik kasus penggunaan database

Database grafik bekerja paling baik ketika data yang Anda kerjakan sangat terhubung dan harus ditunjukkan dengan cara menghubungkan atau merujuk ke data lain , biasanya melalui hubungan banyak-ke-banyak.

Sekali lagi, jejaring sosial adalah contoh yang berguna. Database grafik mengurangi jumlah pekerjaan yang diperlukan untuk membangun dan menampilkan tampilan data yang ditemukan di jejaring sosial, seperti umpan aktivitas, atau menentukan apakah Anda mungkin mengenal seseorang atau tidak karena kedekatannya dengan teman lain yang Anda miliki di jaringan.

Aplikasi lain untuk database grafik adalah menemukan pola koneksi dalam data grafik yang akan sulit untuk dipisahkan melalui representasi data lainnya. Sistem deteksi penipuan menggunakan database grafik untuk menjelaskan hubungan antara entitas yang mungkin sulit untuk diketahui. 

Demikian pula, database grafik adalah kesesuaian alami untuk aplikasi yang mengelola hubungan atau saling ketergantungan antar entitas. Anda akan sering menemukan database grafik di belakang mesin rekomendasi, sistem manajemen konten dan aset, sistem manajemen identitas dan akses, serta kepatuhan regulasi dan solusi manajemen risiko. 

Buat grafik kueri database

Database grafik — seperti database NoSQL lainnya — biasanya menggunakan metodologi kueri kustomnya sendiri, bukan SQL.

Satu bahasa kueri grafik yang umum digunakan adalah Cypher, awalnya dikembangkan untuk database grafik Neo4j. Sejak akhir 2015, Cypher telah dikembangkan sebagai proyek sumber terbuka terpisah, dan sejumlah vendor lain telah mengadopsinya sebagai sistem kueri untuk produk mereka (misalnya, SAP HANA).

Berikut adalah contoh kueri Cypher yang mengembalikan hasil penelusuran untuk semua orang yang merupakan teman Scott:

MATCH (a: Person {name: 'Scott'}) - [: FRIENDOF] -> (b) RETURN b 

Simbol panah ( ->) digunakan dalam kueri Cypher untuk mewakili hubungan terarah dalam grafik.

Bahasa kueri grafik umum lainnya, Gremlin, dirancang untuk kerangka kerja komputasi grafik Apache TinkerPop. Sintaks GREMLIN mirip dengan yang digunakan oleh perpustakaan akses database ORM beberapa bahasa.

Berikut adalah contoh kueri "friends of Scott" di Gremlin:

gV (). has ("name", "Scott"). out ("friendof") 

Banyak database grafik memiliki dukungan untuk Gremlin melalui pustaka, baik built-in atau pihak ketiga.

Namun bahasa kueri lainnya adalah SPARQL. Ini pada awalnya dikembangkan oleh W3C untuk meminta data yang disimpan dalam format Resource Description Framework (RDF) untuk metadata. Dengan kata lain, SPARQL tidak dirancang untuk pencarian database grafik, tetapi dapat digunakan untuk itu. Secara keseluruhan, Cypher dan GREMLIN telah diadopsi secara lebih luas.

Kueri SPARQL memiliki beberapa elemen yang mengingatkan pada SQL, yaitu  SELECTdan WHEREklausa, tetapi sintaks lainnya sangat berbeda. Jangan menganggap SPARQL sama sekali terkait dengan SQL, atau dalam hal ini dengan bahasa kueri grafik lainnya.

Database grafik populer

Karena database grafik melayani kasus penggunaan yang relatif khusus, jumlah mereka hampir tidak sebanyak database relasional. Di sisi positifnya, itu membuat produk yang menonjol lebih mudah untuk diidentifikasi dan didiskusikan.

Neo4j

Neo4j adalah database grafik yang paling matang (11 tahun dan terus bertambah) dan paling terkenal untuk penggunaan umum. Tidak seperti produk database grafik sebelumnya, ini tidak menggunakan back-end SQL. Neo4j adalah basis data grafik asli yang direkayasa dari dalam ke luar untuk mendukung struktur grafik besar, seperti dalam kueri yang mengembalikan ratusan ribu relasi dan banyak lagi.

Neo4j hadir dalam edisi perusahaan open-source dan berbayar, dengan yang terakhir tidak memiliki batasan pada ukuran kumpulan data (di antara fitur lainnya). Anda juga dapat bereksperimen dengan Neo4j online melalui Sandbox-nya, yang menyertakan beberapa contoh kumpulan data untuk berlatih.

Lihat review Neo4j untuk lebih jelasnya.

Microsoft Azure Cosmos DB

Basis data awan Azure Cosmos DB adalah proyek yang ambisius. Ini dimaksudkan untuk meniru beberapa jenis database — tabel konvensional, berorientasi dokumen, kelompok kolom, dan grafik — semuanya melalui satu layanan terpadu dengan sekumpulan API yang konsisten.

Untuk itu, database grafik hanyalah salah satu dari berbagai mode yang dapat dioperasikan Cosmos DB. Ini menggunakan bahasa kueri Gremlin dan API untuk kueri jenis grafik, dan mendukung konsol Gremlin yang dibuat untuk Apache TinkerPop sebagai antarmuka lain.

Nilai jual besar lainnya dari Cosmos DB adalah bahwa pengindeksan, penskalaan, dan replikasi geografis ditangani secara otomatis di awan Azure, tanpa memutar tombol apa pun di pihak Anda. Belum jelas bagaimana arsitektur all-in-one Microsoft mengukur database grafik asli dalam hal kinerja, tetapi Cosmos DB jelas menawarkan kombinasi fleksibilitas dan skala yang berguna.

Lihat review Azure Cosmos DB untuk lebih jelasnya.

JanusGraph

JanusGraph berasal dari proyek TitanDB, dan sekarang berada di bawah pengelolaan Linux Foundation. Ini menggunakan salah satu dari sejumlah backend yang didukung — Apache Cassandra, Apache HBase, Google Cloud Bigtable, Oracle BerkeleyDB — untuk menyimpan data grafik, mendukung bahasa kueri Gremlin (serta elemen lain dari tumpukan Apache TinkerPop), dan juga dapat menggabungkan pencarian teks lengkap melalui proyek Apache Solr, Apache Lucene, atau Elasticsearch.

IBM, salah satu pendukung proyek JanusGraph, menawarkan versi host JanusGraph di IBM Cloud, yang disebut Compose for JanusGraph. Seperti Azure Cosmos DB, Tulis untuk JanusGraph menyediakan penskalaan otomatis dan ketersediaan tinggi, dengan harga berdasarkan penggunaan sumber daya.