Mengapa pengembang harus menggunakan database grafik

Dua puluh tahun yang lalu, tim pengembangan saya membangun mesin pemrosesan bahasa alami yang memindai pekerjaan, otomotif, dan iklan real estat untuk kategori yang dapat ditelusuri. Saya tahu bahwa kami memiliki tantangan pengelolaan data yang sulit. Data di beberapa jenis iklan relatif mudah, seperti mengidentifikasi merek dan model mobil, tetapi yang lain membutuhkan lebih banyak kesimpulan, seperti mengidentifikasi kategori pekerjaan berdasarkan daftar keahlian.

Kami mengembangkan model metadata yang menangkap semua istilah yang dapat ditelusuri, tetapi mesin pengolah bahasa natural memerlukan model tersebut untuk mengekspos hubungan metadata yang signifikan. Kami tahu mendesain model metadata dengan koneksi arbitrer antara titik data dalam database relasional itu rumit, jadi kami menjelajahi menggunakan database objek untuk mengelola model.

Apa yang kami coba capai saat itu dengan database objek dapat dilakukan lebih baik hari ini dengan database grafik. Database grafik menyimpan informasi sebagai node dan data yang menentukan hubungannya dengan node lain. Mereka adalah arsitektur yang terbukti untuk menyimpan data dengan hubungan yang kompleks.

Penggunaan database grafik telah berkembang selama dekade terakhir karena perusahaan mempertimbangkan teknologi NoSQL dan big data lainnya. Pasar database grafik global diperkirakan mencapai $ 651 juta pada tahun 2018 dan diperkirakan akan tumbuh menjadi $ 3,73 miliar pada tahun 2026. Tetapi banyak teknologi manajemen data besar lainnya, termasuk Hadoop, Spark, dan lainnya, telah melihat pertumbuhan yang jauh lebih signifikan dalam popularitas, adopsi keterampilan, dan kasus penggunaan produksi dibandingkan dengan database grafik. Sebagai perbandingan, ukuran pasar teknologi data besar diperkirakan mencapai $ 36,8 miliar pada tahun 2018 dan diperkirakan akan tumbuh menjadi $ 104,3 miliar pada tahun 2026.

Saya ingin memahami mengapa lebih banyak organisasi tidak mempertimbangkan database grafik. Pengembang berpikir dalam objek dan menggunakan representasi data hierarki dalam XML dan JSON secara teratur. Ahli teknologi dan pemangku kepentingan bisnis secara intrinsik memahami grafik karena Internet adalah grafik yang saling berhubungan melalui hyperlink dan konsep seperti teman dan teman dari teman dari jejaring sosial. Lalu mengapa tidak lebih banyak tim pengembangan yang menggunakan database grafik dalam aplikasi mereka?

Mempelajari bahasa kueri dari database grafik

Meskipun mungkin relatif mudah untuk memahami pemodelan node dan hubungan yang digunakan dalam database grafik, menanyakannya memerlukan pembelajaran praktik dan keterampilan baru.

Mari kita lihat contoh komputasi daftar teman dan teman dari teman. Lima belas tahun yang lalu, saya menjadi salah satu pendiri jejaring sosial perjalanan dan memutuskan untuk membuat model datanya tetap sederhana dengan menyimpan semuanya di MySQL. Tabel yang menyimpan daftar pengguna telah bergabung sendiri untuk mewakili teman, dan mengekstrak daftar teman merupakan kueri yang relatif mudah. Tetapi mendapatkan teman dari daftar teman membutuhkan kueri yang sangat rumit yang berfungsi tetapi tidak berfungsi dengan baik ketika pengguna memiliki jaringan yang luas.

Saya berbicara dengan Jim Webber, kepala ilmuwan di Neo4j, salah satu database grafik mapan yang tersedia, tentang cara membuat kueri teman dari teman. Pengembang dapat meminta database grafik Neo4j menggunakan RDF (Resource Description Framework) dan Gremlin, tetapi Webber memberi tahu saya bahwa lebih dari 90 persen pelanggan menggunakan Cypher. Beginilah tampilan kueri di Cypher untuk mengekstrak teman dan teman dari teman:

MATCH (me:Person {name:'Rosa'})-[:FRIEND*1..2]->(f:Person)

WHERE me f

RETURN f

Berikut cara memahami kueri ini:

  • Temukan pola di mana ada node dengan label Person dan nama properti: 'Rosa', dan ikat ke variabel "me". Kueri menentukan bahwa "saya" memiliki hubungan FRIEND keluar pada kedalaman 1 atau 2 ke node lain dengan label Person, dan mengikat kecocokan tersebut ke variabel "f".
  • Pastikan "saya" tidak sama dengan "f", karena saya adalah teman dari teman saya!
  • Kembalikan semua teman dan teman dari teman

Kueri ini elegan dan efisien tetapi memiliki kurva pembelajaran bagi mereka yang terbiasa menulis kueri SQL. Di situlah letak tantangan pertama bagi organisasi yang bergerak menuju database grafik: SQL adalah seperangkat keterampilan yang tersebar luas, dan Cypher serta bahasa kueri grafik lainnya adalah keterampilan baru untuk dipelajari.

Mendesain hierarki yang fleksibel dengan database grafik

Katalog produk, sistem manajemen konten, aplikasi manajemen proyek, ERP dan CRM semuanya menggunakan hierarki untuk mengkategorikan dan menandai informasi. Masalahnya, tentu saja, beberapa informasi tidak benar-benar hierarkis, dan pokok bahasan harus menciptakan pendekatan yang konsisten untuk penataan arsitektur informasi. Itu bisa menjadi proses yang menyakitkan, terutama jika ada perdebatan internal tentang penataan informasi, atau ketika pengguna akhir aplikasi tidak dapat menemukan informasi yang mereka cari karena berada di bagian hierarki yang berbeda.

Database grafik tidak hanya mengaktifkan hierarki arbitrer, tetapi juga memungkinkan pengembang membuat tampilan hierarki yang berbeda untuk kebutuhan yang berbeda. Misalnya, artikel ini pada database grafik mungkin muncul di bawah hierarki dalam sistem manajemen konten untuk manajemen data, teknologi yang muncul, industri yang kemungkinan besar menggunakan database grafik, kasus penggunaan database grafik umum, atau peran teknologi. Mesin rekomendasi kemudian memiliki kumpulan data yang jauh lebih kaya untuk mencocokkan konten dengan minat pengguna.

Saya berbicara dengan Mark Klusza, salah satu pendiri Construxiv, perusahaan yang menjual teknologi ke industri konstruksi, termasuk Grit, platform penjadwalan konstruksi. Jika Anda melihat jadwal proyek konstruksi komersial, Anda akan melihat referensi ke banyak perdagangan, peralatan, suku cadang, dan referensi model. Paket kerja tunggal dapat dengan mudah memiliki ratusan tugas dengan dependensi dalam rencana proyek. Rencana ini harus mengintegrasikan data dari ERP, Pemodelan Informasi Gedung, dan rencana proyek lainnya serta menampilkan tampilan untuk penjadwal, manajer proyek, dan subkontraktor. Klusza menjelaskan, “Dengan menggunakan database grafik di Grit, kami menciptakan hubungan yang lebih kaya tentang siapa melakukan apa, kapan, di mana, dengan peralatan apa, dan dengan bahan apa. Itu memungkinkan kami mempersonalisasi tampilan dan memperkirakan konflik penjadwalan pekerjaan dengan lebih baik. ”

Untuk memanfaatkan hierarki yang fleksibel, ada baiknya merancang aplikasi dari bawah ke atas dengan database grafik. Seluruh aplikasi kemudian dirancang berdasarkan kueri grafik dan memanfaatkan node, hubungan, label, dan properti grafik.

Opsi penerapan cloud mengurangi kompleksitas operasional

Menerapkan solusi manajemen data ke pusat data bukanlah hal yang sepele. Infrastruktur dan operasi harus mempertimbangkan persyaratan keamanan; meninjau pertimbangan kinerja untuk mengukur server, penyimpanan, dan jaringan; dan juga mengoperasikan sistem yang direplikasi untuk pemulihan bencana.

Organisasi yang bereksperimen dengan database grafik sekarang memiliki beberapa opsi cloud. Engineer dapat menerapkan Neo4j ke GCP, AWS, Azure, atau memanfaatkan Aura Neo4j, database sebagai layanan. TigerGraph memiliki penawaran cloud dan starter kit untuk kasus penggunaan seperti pelanggan 360, deteksi penipuan, mesin rekomendasi, analisis jaringan sosial, dan analisis rantai pasokan. Selain itu, vendor cloud publik memiliki kemampuan database grafik, termasuk AWS Neptune, Gremlin API di Azure's CosmoDB, sumber terbuka JanusGraph di GCP, atau fitur grafik di Oracle's Cloud Database Services.

Saya kembali ke pertanyaan awal saya. Dengan semua kasus penggunaan yang menarik, tersedia platform database grafik yang matang, peluang untuk mempelajari pengembangan database grafik, dan opsi penyebaran cloud, mengapa tidak lebih banyak organisasi teknologi yang menggunakan database grafik?