Mengapa Anda harus menggunakan database grafik

Jeff Carpenter adalah penginjil teknis di DataStax.

Ada banyak hype baru-baru ini tentang database grafik. Meskipun database grafik seperti DataStax Enterprise Graph (berdasarkan Titan DB), Neo4, dan IBM Graph telah ada selama beberapa tahun, pengumuman terbaru tentang layanan cloud terkelola seperti AWS Neptune dan penambahan kemampuan grafik Microsoft ke Azure Cosmos DB menunjukkan bahwa database grafik telah memasuki arus utama. Dengan semua kepentingan ini, bagaimana Anda menentukan apakah database grafik tepat untuk aplikasi Anda?

Apa itu database grafik?

Sebelum melangkah lebih jauh, mari kita tentukan beberapa terminologi. Apa itu database grafik? Anggap saja dalam model data. Model data grafik terdiri dari simpul yang mewakili entitas dalam domain, dan tepi yang mewakili hubungan antar entitas ini. Karena simpul dan sisi dapat memiliki pasangan nama-nilai tambahan yang disebut properti , model data ini secara resmi dikenal sebagai grafik properti . Beberapa basis data grafik mengharuskan Anda untuk menentukan skema untuk grafik Anda — yaitu menentukan label atau nama untuk simpul, tepi, dan properti Anda sebelum mengisi data apa pun — sementara basis data lain memungkinkan Anda untuk beroperasi tanpa skema tetap.

Seperti yang mungkin telah Anda ketahui, tidak ada informasi baru dalam model data grafik yang tidak dapat kami tangkap dalam model data relasional tradisional. Bagaimanapun, itu sederhana untuk menggambarkan hubungan antar tabel menggunakan kunci asing, atau kita bisa mendeskripsikan properti hubungan dengan tabel gabungan. Perbedaan utama antara model data ini adalah cara data diatur dan diakses. Pengakuan edge sebagai "warga kelas satu" bersama dengan simpul dalam model data grafik memungkinkan mesin database yang mendasarinya untuk melakukan iterasi dengan sangat cepat ke segala arah melalui jaringan simpul dan tepi untuk memenuhi permintaan aplikasi, sebuah proses yang dikenal sebagai traversal .

Fleksibilitas model data grafik merupakan faktor kunci yang mendorong lonjakan popularitas database grafik baru-baru ini. Persyaratan yang sama untuk ketersediaan dan skala besar yang mendorong pengembangan dan adopsi berbagai penawaran NoSQL selama 10 tahun terakhir terus membuahkan hasil dalam tren grafik baru-baru ini.

Bagaimana mengetahui kapan Anda membutuhkan database grafik

Namun, seperti halnya teknologi populer lainnya, mungkin ada kecenderungan untuk menerapkan basis data grafik untuk setiap masalah. Penting untuk memastikan bahwa Anda memiliki kasus penggunaan yang sesuai. Misalnya, grafik sering diterapkan pada domain masalah seperti:

  • Jaringan sosial
  • Rekomendasi dan personalisasi
  • Pelanggan 360, termasuk resolusi entitas (menghubungkan data pengguna dari berbagai sumber)
  • Deteksi penipuan
  • Manajemen aset

Apakah kasus penggunaan Anda cocok dengan salah satu domain tersebut atau tidak, ada beberapa faktor lain yang harus Anda pertimbangkan yang dapat membantu menentukan apakah database grafik tepat untuk Anda:

  • Hubungan banyak ke banyak. Dalam bukunya "Designing Data Intensive Applications" (O'Reilly), Martin Kleppmann menyarankan bahwa seringnya hubungan banyak-ke-banyak dalam domain masalah Anda merupakan indikator yang baik untuk penggunaan grafik, karena database relasional cenderung kesulitan untuk menavigasi hubungan ini secara efisien.
  • Nilai hubungan yang tinggi. Heuristik lain yang sering saya dengar: jika hubungan antara elemen data Anda sama pentingnya atau lebih penting daripada elemen itu sendiri, Anda harus mempertimbangkan untuk menggunakan grafik.
  • Latensi rendah dalam skala besar. Menambahkan database lain ke dalam aplikasi Anda juga menambah kerumitan pada aplikasi Anda. Kemampuan database grafik untuk menavigasi melalui hubungan yang direpresentasikan dalam kumpulan data besar lebih cepat daripada jenis database lain yang membenarkan kompleksitas tambahan ini. Hal ini terutama berlaku dalam kasus di mana kueri gabungan relasional yang kompleks tidak lagi berfungsi dan tidak ada keuntungan pengoptimalan tambahan yang harus dibuat untuk kueri atau struktur relasional.

Mendefinisikan skema grafik dan query dengan Gremlin

Mari kita lihat cara mulai menggunakan database grafik menggunakan contoh nyata, sistem pemberi rekomendasi yang baru-baru ini kami tambahkan ke KillrVideo. KillrVideo adalah aplikasi referensi untuk berbagi dan menonton video yang kami buat untuk membantu pengembang mempelajari cara menggunakan DataStax Enterprise, termasuk DataStax Enterprise Graph, database grafik yang dibangun di atas teknologi data yang sangat skalabel termasuk Apache Cassandra dan Apache Spark.

Bahasa yang digunakan untuk mendeskripsikan dan berinteraksi dengan grafik di DataStax Enterprise Graph adalah Gremlin, yang merupakan bagian dari proyek Apache TinkerPop. Gremlin dikenal sebagai bahasa masuk untuk mendeskripsikan traversal grafik karena fleksibilitas, ekstensibilitasnya, dan dukungannya untuk kueri deklaratif dan imperatif. Gremlin didasarkan pada bahasa Groovy, dan driver tersedia dalam berbagai bahasa. Yang terpenting, Gremlin didukung oleh database grafik paling populer termasuk DataStax Enterprise Graph, Neo4j, AWS Neptune, dan Azure Cosmos DB.

Kami merancang algoritme rekomendasi untuk mengidentifikasi data yang kami perlukan sebagai input. Pendekatannya adalah menghasilkan rekomendasi untuk pengguna tertentu berdasarkan video yang disukai oleh pengguna serupa. Tujuan kami adalah untuk menghasilkan rekomendasi secara real-time saat pengguna berinteraksi dengan aplikasi KillrVideo, yaitu sebagai interaksi OLTP.

Untuk menentukan skema, kami mengidentifikasi subset dari data yang dikelola oleh KillrVideo yang kami perlukan untuk grafik kami. Ini termasuk pengguna, video, peringkat, dan tag, serta properti item ini yang mungkin kami rujuk dalam algoritme atau disajikan dalam hasil rekomendasi. Kami kemudian membuat skema grafik di GREMLIN yang terlihat seperti ini:

// buat label titik

schema.vertexLabel ("user"). partitionKey ('userId').

  properti ("userId", "email", "added_date"). ifNotExists (). create ();

schema.vertexLabel ("video"). partitionKey ('videoId').

  properti ("videoId", "name", "description", "added_date",

preview_image_location ”). ifNotExists (). create ();

schema.vertexLabel ("tag"). partitionKey ('name').

  properti ("nama", "tanggal_tag"). ifNotExists (). create ();

// buat label tepi

schema.edgeLabel ("rated"). multiple (). properties ("rating").

  koneksi ("pengguna", "video"). ifNotExists (). create ();

schema.edgeLabel ("diupload"). single (). properties ("added_date").

  koneksi ("pengguna", "video"). ifNotExists (). create ();

schema.edgeLabel ("taggedWith"). single ().

  koneksi ("video", "tag"). ifNotExists (). create ();

Kami memilih untuk membuat model pengguna, video, dan tag sebagai simpul, dan menggunakan tepi untuk mengidentifikasi pengguna mana yang mengunggah video mana, peringkat video pengguna, dan tag yang terkait dengan setiap video. Kami menetapkan properti ke simpul dan tepi yang direferensikan dalam kueri atau disertakan dalam hasil. Skema yang dihasilkan terlihat seperti ini di DataStax Studio, alat pengembang bergaya notebook untuk mengembangkan dan menjalankan kueri di CQL dan Gremlin.

Berdasarkan skema ini, kami menentukan kueri yang mengisi data ke dalam grafik dan kueri yang mengambil data dari grafik. Mari kita lihat kueri grafik yang menghasilkan rekomendasi. Berikut alur dasarnya: Untuk pengguna tertentu, identifikasi pengguna serupa yang menyukai video yang disukai pengguna tertentu, pilih video yang juga disukai pengguna serupa, kecualikan video yang telah ditonton pengguna tertentu, urutkan video tersebut berdasarkan popularitas, dan berikan hasil.

def numRatingsToSample = 1000

def localUserRatingsToSample = 10

def minPositiveRating = 4

def userID = ...

gV (). has ("user", "userId", userID) .as ("^ currentUser")

    // dapatkan semua video yang ditonton pengguna dan simpan

    .map (out ('rated'). dedup (). fold ()). as (“^ watchingVideos”)

    // kembali ke pengguna saat ini

    .select (“^ currentUser”)

    // identifikasi video yang dinilai tinggi oleh pengguna

    .outE ('rated'). has ('rating', gte (minPositiveRating)). inV ()

    // apa yang dinilai tinggi pengguna lain untuk video tersebut?

    .inE ('rated']. has ('rating', gte (minPositiveRating))

    // batasi jumlah hasil sehingga ini akan berfungsi sebagai kueri OLTP

    .sample (numRatingsToSample)

    // urutkan menurut peringkat untuk mendukung pengguna yang memberi peringkat tertinggi untuk video tersebut

    .by ('rating'). outV ()

    // hilangkan pengguna saat ini

    .where (neq (“^ currentUser”))

Mari kita berhenti sejenak untuk mengatur napas. Sejauh ini dalam traversal ini kami telah mengidentifikasi pengguna yang serupa. Bagian kedua dari traversal mengambil pengguna yang serupa, mengambil sejumlah video yang disukai pengguna serupa, menghapus video yang telah ditonton pengguna, dan menghasilkan kumpulan hasil yang diurutkan berdasarkan popularitas.

    // pilih video berperingkat tinggi dalam jumlah terbatas dari setiap pengguna serupa

   .local (outE ('rated'). has ('rating', gte (minPositiveRating)). limit (localUserRatingsToSample)). sack (assign) .by ('rating'). inV ()

     // kecualikan video yang telah ditonton pengguna

    .not (di mana (dalam (“^ watchingVideos”)))

    // identifikasi video paling populer dengan jumlah dari semua peringkat

    .group (). by (). by (sack (). sum ())

    // Sekarang kita memiliki peta besar [video: score], pesanlah

    .order (local) .by (values, decr) .limit (local, 100) .select (keys) .unfold ()

    // Keluarkan video yang direkomendasikan termasuk pengguna yang mengupload setiap video

    .project ('video', 'user')

        .oleh()

        .by (__. in ('uploaded'))

Meskipun traversal ini terlihat rumit, perlu diingat bahwa ini adalah logika bisnis keseluruhan dari algoritme rekomendasi. Kami tidak akan menggali setiap langkah traversal ini secara mendetail di sini, tetapi referensi bahasa adalah sumber daya yang bagus, dan tersedia kursus pelatihan berkualitas tinggi.

Saya merekomendasikan mengembangkan traversal secara interaktif melalui kumpulan data perwakilan menggunakan alat seperti DataStax Studio atau konsol Gremlin dari Apache TinkerPop. Ini memungkinkan Anda untuk dengan cepat mengulangi dan menyempurnakan traversal Anda. DataStax Studio adalah lingkungan berbasis web yang menyediakan berbagai cara untuk memvisualisasikan hasil traversal sebagai jaringan node dan edge, seperti yang ditunjukkan pada gambar di bawah ini. Tampilan lain yang didukung termasuk tabel, bagan dan grafik, serta penelusuran kinerja.

DataStax

Memasukkan database grafik ke dalam arsitektur Anda

Setelah Anda mendesain skema grafik dan kueri, saatnya untuk mengintegrasikan grafik ke dalam aplikasi Anda. Inilah cara kami mengintegrasikan Grafik Perusahaan DataStax ke KillrVideo. Arsitektur multi-tingkat KillrVideo terdiri dari aplikasi web yang berada di atas serangkaian layanan mikro yang mengelola pengguna, video (termasuk tag), dan peringkat. Layanan ini memanfaatkan database DataStax Enterprise Graph (dibangun di atas Apache Cassandra) untuk penyimpanan data dan mengakses data menggunakan CQL.

Kami menerapkan mesin rekomendasi kami sebagai bagian dari Layanan Video yang Disarankan, seperti yang ditunjukkan di bawah ini. Layanan ini menghasilkan daftar rekomendasi yang diberi ID pengguna. Untuk mengimplementasikan mesin rekomendasi, kami menerjemahkan Gremlin traversal yang dijelaskan di atas ke dalam kode Java.

DataStax

Arsitektur ini menyoroti tantangan yang sering muncul dalam arsitektur layanan mikro — kebutuhan untuk berinteraksi dengan data yang dimiliki oleh beberapa layanan. Seperti yang ditunjukkan di atas, grafik yang digunakan untuk menghasilkan rekomendasi bergantung pada data dari Layanan User Management, Katalog Video, dan Rating.

Kami mempertahankan kepemilikan data dari layanan kami yang ada dengan menggunakan perpesanan asinkron. Layanan Pengelolaan Pengguna, Katalog Video, dan Peringkat memublikasikan peristiwa pada perubahan data. Layanan Video yang Disarankan berlangganan acara ini dan melakukan pembaruan yang sesuai pada grafik. Pengorbanan yang kami buat di sini adalah tipikal aplikasi yang menggunakan pendekatan multi-model, topik yang saya bahas di artikel saya sebelumnya.

Menerapkan traversal GREMLIN di Java

Driver Java DataStax menyediakan API yang ramah dan lancar untuk mengimplementasikan traversal Gremlin dengan DataStax Enterprise Graph. API mempermudah migrasi kueri berbasis Groovy yang kami buat di DataStax Studio ke dalam kode Java.

Kami kemudian dapat membuat kode Java kami lebih mudah dibaca dan dipelihara dengan menggunakan fitur GREMLIN yang dikenal sebagai DSL, bahasa khusus domain. DSL adalah perpanjangan dari GREMLIN ke dalam domain tertentu. Untuk KillrVideo, kami membuat DSL untuk memperluas implementasi traversal Gremlin dengan istilah yang relevan dengan domain video. The KillrVideoTraversalDslkelas mendefinisikan permintaan operasi seperti u ser(), yang menempatkan titik dalam grafik dengan UUID yang disediakan, dan recommendByUserRating(), yang menghasilkan rekomendasi untuk pengguna disediakan berdasarkan parameter seperti rating minimum dan sejumlah yang diminta dari rekomendasi.

Menggunakan DSL menyederhanakan implementasi Layanan Video yang Disarankan ke sesuatu seperti contoh di bawah ini, yang membuat video GraphStatementyang kemudian kami jalankan menggunakan Driver Java DataStax:

GraphStatement gStatement = DseGraph.statementFromTraversal (killr.users (userIdString)

       .recommendByUserRating (100, 4, 500, 10)

);

Menggunakan DSL memungkinkan kami menyembunyikan beberapa kompleksitas interaksi grafik kami dalam fungsi yang dapat digunakan kembali, yang kemudian dapat digabungkan sesuai kebutuhan untuk membentuk traversal yang lebih kompleks. Ini akan memungkinkan kita untuk mengimplementasikan mesin rekomendasi tambahan yang dimulai dari simpul pengguna yang dipilih yang disediakan oleh user()metode dan memungkinkan aplikasi untuk bertukar di antara implementasi yang berbeda.

Contoh grafik kerja

Anda dapat melihat hasil integrasi DataStax Enterprise Graph ke KillrVideo di bagian "Direkomendasikan untuk Anda" dari aplikasi web yang ditunjukkan di bawah ini. Cobalah sendiri di //www.killrvideo.com dengan membuat akun dan menilai beberapa video.

DataStax

Saya harap artikel ini memberi Anda beberapa ide bagus tentang bagaimana database grafik mungkin masuk akal untuk aplikasi Anda, dan bagaimana memulai dengan Gremlin dan DataStax Enterprise Graph.

Jeff Carpenter adalah penginjil teknis di DataStax, di mana ia memanfaatkan latar belakangnya dalam arsitektur sistem, layanan mikro, dan Apache Cassandra untuk membantu memberdayakan pengembang dan insinyur operasi membangun sistem terdistribusi yang dapat diskalakan, andal, dan aman. Jeff adalah penulis Cassandra: The Definitive Guide, Edisi ke-2.

-

Forum Teknologi Baru menyediakan tempat untuk mengeksplorasi dan mendiskusikan teknologi perusahaan yang sedang berkembang secara mendalam dan luas. Pemilihan ini subjektif, berdasarkan pilihan teknologi yang kami yakini penting dan paling menarik bagi pembaca. tidak menerima jaminan pemasaran untuk publikasi dan berhak untuk mengedit semua konten yang dikontribusikan. Kirim semua pertanyaan ke  [email protected] .