Apa kasus penggunaan Databases berbasis Grafik (http://neo4j.org/)? [Tutup]

129

Saya telah menggunakan banyak DB Relasional dan memutuskan untuk keluar pada jenis lain yang tersedia.

Produk khusus ini terlihat bagus dan menjanjikan: http://neo4j.org/

Adakah yang menggunakan basis data berbasis grafik? Apa pro dan kontra dari prespektif kegunaan?

Sudahkah Anda menggunakannya di lingkungan produksi? Apa persyaratan yang mendorong Anda untuk menggunakannya?

Khangharoth
sumber
Neo4j memiliki berbagai kegunaan saat ini di perusahaan internasional. Neo Technology memiliki beberapa kertas putih yang menganalisis masing-masing kegunaan ini: 1. Deteksi penipuan 2. Rekomendasi waktu nyata dan jejaring sosial 3. Manajemen pusat data Lebih detail: bbvaopen4u.com/en/actualidad/…
Chirag Maliwal

Jawaban:

187

Saya menggunakan basis data grafik dalam pekerjaan sebelumnya. Kami tidak menggunakan neo4j, itu adalah in-house yang dibangun di atas Berkeley DB, tetapi serupa. Itu digunakan dalam produksi (masih).

Alasan kami menggunakan basis data grafik adalah karena data disimpan oleh sistem dan operasi yang dilakukan sistem dengan data tersebut adalah titik lemah dari basis data relasional dan merupakan titik kuat dari basis data grafik. Sistem yang diperlukan untuk menyimpan koleksi objek yang tidak memiliki skema tetap dan dihubungkan bersama oleh hubungan. Untuk alasan tentang data, sistem perlu melakukan banyak operasi yang akan menjadi beberapa traversal dalam database grafik, tetapi itu akan menjadi pertanyaan yang cukup kompleks dalam SQL.

Keuntungan utama dari model grafik adalah waktu pengembangan yang cepat dan fleksibilitas. Kami dapat dengan cepat menambahkan fungsionalitas baru tanpa memengaruhi penyebaran yang ada. Jika pelanggan potensial ingin mengimpor beberapa data mereka sendiri dan mencangkokkannya di atas model kami, biasanya dapat dilakukan di situs oleh tenaga penjualan. Fleksibilitas juga membantu ketika kami merancang fitur baru, menyelamatkan kami dari upaya memeras data baru menjadi model data yang kaku.

Memiliki basis data yang aneh, mari kita bangun banyak teknologi aneh lainnya, memberi kita banyak saus rahasia untuk membedakan produk kita dengan yang dimiliki pesaing kita.

Kerugian utama adalah bahwa kami tidak menggunakan teknologi database relasional standar, yang bisa menjadi masalah ketika pelanggan Anda bersikap tegas. Pelanggan kami akan bertanya mengapa kami tidak bisa hanya meng-host data kami di cluster Oracle raksasa mereka (pelanggan kami biasanya memiliki pusat data besar). Salah satu tim sebenarnya menulis ulang lapisan database untuk menggunakan Oracle (atau PostgreSQL, atau MySQL), tetapi itu sedikit lebih lambat daripada yang asli. Setidaknya satu perusahaan besar bahkan memiliki kebijakan khusus Oracle, tetapi untungnya Oracle membeli Berkeley DB. Kami juga harus menulis banyak alat tambahan - kami tidak bisa hanya menggunakan Crystal Reports misalnya.

Kerugian lain dari basis data grafik kami adalah bahwa kami membangunnya sendiri, yang berarti ketika kami menemukan masalah (biasanya dengan skalabilitas) kami harus menyelesaikannya sendiri. Jika kami menggunakan basis data relasional, vendor akan sudah memecahkan masalah sepuluh tahun yang lalu.

Jika Anda sedang membangun produk untuk pelanggan perusahaan dan data Anda cocok dengan model relasional, gunakan database relasional jika Anda bisa. Jika aplikasi Anda tidak sesuai dengan model relasional tetapi tidak sesuai dengan model grafik, gunakan basis data grafik. Jika hanya cocok untuk sesuatu yang lain, gunakan itu.

Jika aplikasi Anda tidak perlu masuk ke arsitektur blub saat ini, gunakan basis data grafik, atau CouchDB, atau BigTable, atau apa pun yang cocok dengan aplikasi Anda dan Anda anggap keren. Mungkin memberi Anda keuntungan, dan menyenangkan untuk mencoba hal-hal baru.

Apa pun yang Anda pilih, cobalah untuk tidak membuat sendiri mesin basis data kecuali Anda memang suka membangun mesin basis data.

Will Harris
sumber
66
Jawaban yang bagus, dan +1 untuk "cobalah untuk tidak membangun mesin basis data sendiri kecuali Anda benar-benar suka membangun mesin basis data", rotfl
Michał Chaniewski
32

Kami telah bekerja dengan tim Neo selama lebih dari satu tahun sekarang dan sangat bahagia. Kami memodelkan artefak ilmiah dan hubungannya, yang tepat untuk grafik db, dan menjalankan algoritme rekomendasi melalui jaringan.

Jika Anda sudah bekerja di Jawa, saya pikir pemodelan menggunakan Neo4j sangat mudah dan memiliki kinerja yang paling cepat / tercepat untuk R / W dari solusi lain yang kami coba.

Sejujurnya, saya sulit untuk tidak berpikir dalam hal Grafik / Jaringan karena jauh lebih mudah daripada merancang struktur tabel yang berbelit-belit untuk menahan properti dan hubungan objek.

Yang sedang berkata, kami menyimpan beberapa informasi dalam MySQL hanya karena lebih mudah bagi pihak Bisnis untuk menjalankan query SQL cepat terhadap. Untuk melakukan fungsi yang sama dengan Neo kita perlu menulis kode yang kita tidak punya bandwidth untuk saat ini. Namun begitu kami melakukannya, saya memindahkan semua data itu ke Neo!

Semoga berhasil.

DataRiot
sumber
1
dapatkah Anda memberi tahu saya informasi seperti apa yang Anda simpan di MySQL? Saya akan membuat komunitas baru, dapatkah saya menyimpan semua informasi "biasa" seperti nama pengguna, kata sandi, nama depan & belakang dan seterusnya di neo4j atau apakah itu tidak benar-benar cocok untuk itu? : o
Muqito
3
Anda benar-benar dapat menyimpan semua informasi itu di Neo. Saya telah membangun beberapa sistem di mana semua informasi akun ada dalam grafik. Jenis informasi yang biasanya saya simpan di luar grafik adalah volume besar data deret waktu yang perlu ditanyakan untuk pelaporan.
DataRiot
1
Jika Anda bekerja dalam tumpukan .Net / Microsoft, Neo4jCLient berfungsi dengan baik.
Manuel Hernandez
23

Dua poin:

Pertama, pada data saya telah bekerja dengan 5 tahun terakhir di SQL Server, saya baru-baru ini menabrak dinding skalabilitas dengan SQL untuk jenis pertanyaan yang perlu kita jalankan (bersarang relhip ... Anda tahu ... grafik ). Saya telah bermain-main dengan neo4j, dan waktu pencarian saya beberapa kali lipat lebih cepat ketika saya membutuhkan pencarian seperti ini.

Kedua, ke titik bahwa basis data grafik sudah usang. Um ... tidak. Awalnya, ketika orang berusaha mencari cara untuk menyimpan dan mencari data secara efisien, mereka membuat dan bermain dengan grafik dan model basis data gaya jaringan. Ini dirancang sehingga model fisik mencerminkan model logis, sehingga efisiensinya tidak terlalu bagus. Jenis struktur data ini baik untuk data semi-terstruktur, tetapi tidak sebagus untuk data padat terstruktur. Jadi, dude IBM bernama Codd ini sedang meneliti cara-cara efisien untuk mengatur dan menyimpan data terstruktur dan muncul dengan ide untuk model database relasional. Dan itu bagus, dan orang-orang bahagia.

Apa yang kita punya di sini? Dua alat untuk dua tujuan berbeda. Model basis data grafik sangat baik untuk merepresentasikan data semi-terstruktur dan hubungan antar entitas (yang mungkin ada atau tidak ada). Database relasional baik untuk data terstruktur yang memiliki skema yang sangat statis, dan di mana kedalaman gabungan tidak terlalu dalam. Satu baik untuk satu jenis data, yang lain baik untuk jenis data lainnya.

Untuk koin frase, tidak ada Peluru Perak. Sangat singkat untuk mengatakan bahwa model basis data grafik sudah ketinggalan zaman dan untuk menggunakan salah satu menyerah 40 tahun kemajuan. Itu seperti mengatakan menggunakan C berarti menyerahkan semua kemajuan teknologi yang telah kami lalui untuk mendapatkan hal-hal seperti Java dan C #. Tapi itu tidak benar. C adalah alat yang dibutuhkan untuk tugas-tugas tertentu. Dan Java adalah alat untuk tugas lain.

Turbo
sumber
15

Saya telah menggunakan MySQL selama bertahun-tahun untuk mengelola data teknik, dan itu bekerja dengan baik, tetapi salah satu masalah yang kami miliki (tetapi tidak kami sadari) adalah bahwa kami selalu harus merencanakan skema di muka. Masalah lain yang kami tahu kami miliki adalah memetakan data hingga objek domain dan kembali.

Sekarang kami baru saja mulai mencoba neo4j dan sepertinya ini menyelesaikan kedua masalah bagi kami. Kemampuan untuk menambahkan properti yang berbeda untuk setiap node (dan relasi) telah memungkinkan kami untuk memikirkan kembali seluruh pendekatan kami terhadap data. Ini seperti bahasa dinamis versus statis (Ruby versus Jawa), tetapi untuk basis data. Membangun model data dalam database dapat dilakukan dengan cara yang jauh lebih gesit dan dinamis, dan itu secara dramatis menyederhanakan kode kami.

Dan karena model objek dalam kode umumnya struktur grafik, pemetaan dari database juga lebih sederhana, dengan kode lebih sedikit dan akibatnya lebih sedikit bug.

Dan sebagai bonus tambahan, kode prototipe awal kami untuk memuat data kami ke neo4j sebenarnya berkinerja lebih cepat daripada versi MySQL sebelumnya. Saya tidak memiliki angka yang kuat tentang ini (belum), tapi itu fitur tambahan yang bagus.

Tetapi pada akhirnya, pilihannya mungkin sebagian besar didasarkan pada sifat model domain Anda. Apakah ini memetakan lebih baik ke tabel atau grafik? Putuskan dengan melakukan beberapa prototipe, muat data dan mainkan. Gunakan neoclipse untuk melihat berbagai tampilan data. Setelah Anda selesai melakukannya, semoga Anda tahu apakah Anda menyukai hal yang baik atau tidak.

Craig Taverner
sumber
1
Sampai sekarang saya tidak memiliki persyaratan bisnis untuk menggunakan Db Grafis. Ini mungkin karena saya tidak memikirkan hal lain selain RDBMS. Mungkin saja sebagian besar waktu saya mungkin mencoba pasak persegi di lubang melingkar. Grafik berbasis Db benar-benar merupakan perspektif baru bagi saya. Saya telah menggunakan kerangka ketekunan berbasis Scenegraph (Java3D, Xith3D) tapi itu untuk menyimpan Aplikasi berbasis Grafik. Seluruh percakapan ini memberi saya perspektif baru. Setiap referensi aplikasi yang menggunakan Db berbasis grafik yang saya dapat melihat hal-hal dalam tindakan!
Khangharoth
4

Saya sedang membangun intranet di perusahaan saya.

Saya tertarik untuk memahami cara memuat data yang disimpan dalam tabel (Oracle, MySQL, SQL Server, Excel, Access, berbagai daftar acak) dan memuatnya ke Neo4J, atau beberapa basis data grafik lainnya. Khususnya, apa yang terjadi ketika data umum tumpang tindih dengan data yang sudah ada dalam sistem.

Ya, saya tahu beberapa data paling baik dimodelkan dalam RDBMS, tetapi saya memiliki ide ini yang membuat saya gatal, bahwa ketika Anda perlu menambahkan beberapa tabel yang berbeda, model grafik lebih baik daripada struktur tabel.

Misalnya, saya bekerja di lingkungan manufaktur. Ada proyek besar yang sedang kami kerjakan dan karena kerumitannya, setiap departemen telah membuat lembar kerja Excel terpisah yang memiliki hierarki BOM (Bill Of Material) dalam kolom di sebelah kiri dan kemudian beberapa kolom catatan dan cek yang dibuat oleh individu siapa yang membuat lembaran ini.

Jadi salah satu masalah adalah menggabungkan semua catatan ini menjadi satu "tampilan" sehingga seseorang dapat melihat semua masalah yang perlu ditangani di bagian tertentu.

Masalah kedua adalah bahwa spreadsheet Excel payah dalam merepresentasikan BOM hirarkis ketika komponen umum digunakan di lebih dari satu subassembly. Artinya, jika seseorang menulis catatan tentang relai P34 di subassembly kunci kontak, komentar yang sama harus dikaitkan dengan relay P34 yang digunakan pada subassembly driver motor. Ini tidak akan terjadi di excel spreadsheet.

Untuk intranet perusahaan, saya ingin dapat mencari apa saja dengan mudah. Seperti data yang terkait dengan nomor bagian, struktur BOM, nomor telepon, alamat email, kebijakan perusahaan, atau prosedur. Saya bahkan ingin memperluas ini untuk mengelola aset perangkat keras komputer, dan menginstal perangkat lunak.

Saya membayangkan bahwa begitu jaringan informasi mulai padat, Anda dapat mulai melakukan traversal keren seperti "Saya ingin menulis email kepada semua orang yang bekerja di proyek XYZ". Orang-orang akan dikaitkan dengan proyek karena mereka akan ditandai sebagai membuat dan memodifikasi data dalam proyek XYZ. Jadi dengan menggunakan proyek XYZ sebagai kunci pencarian, satu set besar dengan segala sesuatu yang berkaitan dengan proyek XYZ akan dibuat. Termasuk tautan ke orang yang membangun proyek XYZ. Tautan orang-orang akan terhubung ke alamat email mereka. Jadi dengan keterlibatan mereka dalam proyek XYZ, mereka akan dimasukkan dalam email saya. Ini sangat kontras dengan beberapa sekretaris yang berusaha mempertahankan daftar orang yang bekerja di proyek. Kami menghasilkan banyak daftar. Kami menghabiskan banyak waktu untuk memelihara daftar dan memastikan mereka terbaru.

Traversal keren lainnya dapat melaporkan semua komputer yang menginstal perangkat lunak tertentu, berdasarkan versi. Laporan itu dapat digunakan untuk menghasilkan tugas untuk menghapus salinan tambahan dari perangkat lunak lama dan untuk memperbarui orang yang perlu memiliki salinan terbaru. Ini juga akan berguna untuk pelacakan lisensi.

Paul Bock
sumber
@ Paul Bock: Saya pikir akan sangat cocok untuk menyelesaikan masalah seperti ini menggunakan neo4j. Jika Anda bergabung dengan milis, saya yakin Anda bisa mendapatkan banyak masukan dari komunitas: neo4j.org/community/list
nawroth
2
Saya tidak melihat bagaimana ini tidak dapat dilakukan dalam database Relasional. Apakah saya melewatkan sesuatu?
Andrew Harry
5
Saya tidak berpikir diskusi apa pun tentang fokus 'NoSQL' pada apa yang tidak dapat dilakukan dengan database relasional kecuali itu melibatkan penskalaan. Saya pikir itu sering (setidaknya bagi saya itu adalah) tentang seberapa alami solusi, seberapa efisien dalam menyelesaikan masalah Anda, dll.
Eelco
4

Berikut ini adalah artikel bagus yang membahas tentang kebutuhan yang diisi oleh database non relasional: http://www.readwriteweb.com/enterprise/2009/02/is-the-relational-database-doomed.php

Itu melakukan pekerjaan yang baik pada menunjukkan (selain dari nama) bahwa database relasional tidak cacat atau salah, hanya saja saat ini orang-orang mulai memproses lebih banyak dan lebih banyak data dalam perangkat lunak utama dan situs web, dan bahwa database relasional hanya tidak skala untuk kebutuhan ini.

Universitas Angular
sumber
3

mungkin agak terlambat, tetapi ada semakin banyak proyek menggunakan Neo4j, yang lebih dikenal di Neo4j . NeoTechnology, perusahaan di balik Neo4j, memiliki beberapa referensi di halaman pelanggan mereka

Catatan: Saya bagian dari tim Neo4j

Peter Neubauer
sumber