NoSQL (MongoDB) vs Lucene (atau Solr) sebagai basis data Anda

280

Dengan gerakan NoSQL yang tumbuh berdasarkan pada basis data berbasis dokumen, saya telah melihat MongoDB belakangan ini. Saya telah melihat kesamaan yang mencolok dengan cara memperlakukan item sebagai "Dokumen", seperti halnya Lucene (dan pengguna Solr).

Jadi, pertanyaannya: Mengapa Anda ingin menggunakan NoSQL (MongoDB, Cassandra, CouchDB, dll) di atas Lucene (atau Solr) sebagai "basis data" Anda?

Apa yang saya (dan saya yakin orang lain) cari dalam jawaban adalah beberapa perbandingan mendalam dari mereka. Mari kita lewati semua diskusi basis data relasional, karena mereka melayani tujuan yang berbeda.

Lucene memberikan beberapa keuntungan serius, seperti sistem pencarian dan berat yang kuat. Belum lagi aspek dalam Solr (yang Solr sedang diintegrasikan ke dalam Lucene segera, yay!). Anda dapat menggunakan dokumen Lucene untuk menyimpan ID, dan mengakses dokumen seperti itu seperti MongoDB. Campur dengan Solr, dan Anda sekarang mendapatkan solusi load-based berbasis WebService.

Anda bahkan dapat membandingkan penyedia cache out-of-proc seperti Velocity atau MemCached ketika berbicara tentang penyimpanan data yang serupa dan skalabilitas MongoDB.

Pembatasan seputar MongoDB mengingatkan saya untuk menggunakan MemCached, tetapi saya dapat menggunakan Microsoft Velocity dan memiliki lebih banyak pengelompokan dan daftar kekuatan pengumpulan atas MongoDB (saya pikir). Tidak bisa mendapatkan yang lebih cepat atau scalable dari caching data di memori. Bahkan Lucene memiliki penyedia memori.

MongoDB (dan lainnya) memang memiliki beberapa kelebihan, seperti kemudahan penggunaan API mereka. Baru membuat dokumen, membuat id, dan menyimpannya. Selesai Baik dan mudah.

mongodb  solr  lucene  memcached  nosql 
— eduncan911
sumber
8
— bajafresh4life
4
Terima kasih, tetapi itu tidak menjawab pertanyaan saya: yaitu, mengapa saya menggunakan MongoDB bukan Lucene untuk basis data saya? Mereka berdua menangani dokumen, tetapi Lucene memiliki beberapa opsi pencarian yang sangat kuat. +1 meskipun untuk benar-benar menemukan pertanyaan terkait. Saya mencari beberapa kali di Stackoverflow, dan tidak muncul dengan perbandingan dekat.
— eduncan911
Bagaimana Anda menggunakan Lucene yang menyediakan fungsionalitas yang mirip dengan MongoDB? Apakah Anda mengikatnya ke DB relasional untuk penyimpanan?
— Philip Tinney
1
@ Pilip: Ini pertanyaan hipotetis. Mengapa tidak menggunakan Lucene sebagai penyimpanan dokumen Anda? Anda mendapatkan lebih banyak kekuatan pencarian dan skalabilitas (ketika dicampur dengan Solr, membuat Lucene lebih mudah digunakan).
— eduncan911

Jawaban:

250

Ini adalah pertanyaan yang bagus, sesuatu yang telah saya renungkan sedikit. Saya akan meringkas pelajaran yang saya pelajari:

  1. Anda dapat dengan mudah menggunakan Lucene / Solr sebagai pengganti MongoDB untuk hampir semua situasi, tetapi tidak sebaliknya. Pos Grant Ingersoll merangkumnya di sini.

  2. MongoDB dll. Tampaknya melayani tujuan di mana tidak ada persyaratan untuk mencari dan / atau faceting. Tampaknya menjadi transisi yang lebih sederhana dan bisa dibilang lebih mudah bagi para programmer yang melakukan detoks dari dunia RDBMS. Kecuali seseorang terbiasa, Lucene & Solr memiliki kurva belajar yang lebih curam.

  3. Tidak ada banyak contoh menggunakan Lucene / Solr sebagai datastore, tetapi Guardian telah membuat beberapa kemajuan dan meringkas ini dalam slide-deck yang sangat baik , tetapi mereka juga tidak berkomitmen untuk benar-benar melompat pada kereta musik Solr dan "menyelidiki" menggabungkan Solr dengan CouchDB.

  4. Akhirnya, saya akan menawarkan pengalaman kami, sayangnya tidak dapat mengungkapkan banyak tentang kasus bisnis. Kami bekerja pada skala beberapa TB data, aplikasi waktu nyata yang dekat. Setelah menyelidiki berbagai kombinasi, memutuskan untuk tetap menggunakan Solr. Tidak ada penyesalan sejauh ini (6 bulan & terus bertambah) dan tidak melihat alasan untuk beralih ke yang lain.

Ringkasan: jika Anda tidak memiliki persyaratan pencarian, Mongo menawarkan pendekatan yang sederhana & kuat. Namun jika pencarian adalah kunci dari penawaran Anda, Anda mungkin lebih baik tetap berpegang pada satu teknologi (Solr / Lucene) dan mengoptimalkan heck keluar darinya - bagian bergerak lebih sedikit.

2 sen saya, harapan yang membantu.

— Mikos
sumber
10
Solr tidak memiliki fungsi pengurangan peta. Karena itu pelaporan, statistik, perhitungan skor dll tidak mungkin! Gunakan Solr hanya jika Anda memiliki / dapat mengancam data Anda sebagai data teks
— Roland Kofler
8
Solr tidak memiliki built-in pengurangan peta, tetapi Anda dapat menggabungkan dengan Hadoop. architects.dzone.com/articles/solr-hadoop-big-data-love
— Mikos
6
Pengurangan-peta tidak, tetapi memang memiliki kemampuan untuk menjalankan kueri secara paralel di beberapa server solr dan menggabungkan hasil-hasil itu. Jadi, meskipun tidak memiliki tujuan umum, pengurangan peta telah menulis apa yang akan Anda tulis dengan pengurangan peta yang merupakan kueri penelusuran paralel.
— chubbsondubs
@ Ro: Apakah itu menjadi pilihan untuk menggunakan Lucene sebagai DB utama dan membuat indeks agregat dengan MongoDB? Atau tidakkah itu masuk akal? Dan Mikos: jawaban yang bagus dan +1 untuk penyebutan pengalaman di dunia nyata.
— Meringis Putus Asa
2
from solr6 mendukung fungsi pengurangan peta dengan ekspresi paralel
— Divyang Shah
36

Anda tidak dapat memperbarui sebagian dokumen dalam solr. Anda harus memposting ulang semua bidang untuk memperbarui dokumen.

Dan masalah kinerja. Jika Anda tidak berkomitmen, perubahan Anda untuk solr tidak berlaku, jika Anda berkomitmen setiap waktu, kinerja akan terganggu.

Tidak ada transaksi dalam solr.

Karena solr memiliki kekurangan ini, beberapa kali nosql adalah pilihan yang lebih baik.

— Peter Long
sumber
13
MongoDB tidak memiliki transaksi juga.
— user183037
1
Solr atau Lucene melakukan pencarian waktu nyata, jadi melakukan itu bukan masalah.
— mihaicc
1
@ user183037 dalam MongoDB setiap pembaruan dalam suatu dokumen adalah Atomic. Dan FYI, Lucene juga tidak memiliki transaksi (dalam pengertian Anda)
— Aravind Yarram
48
Jawaban ini menjadi salah. Solr 4+ mendukung pembaruan parsial, dan soft commit / near real time menyingkirkan sebagian besar masalah Solr "gaya lama".
— Mauricio Scheffer
1
Mereka menambahkan dukungan untuk transaksi pada MongoDB 4.
— Jonas
26

Kami menggunakan MongoDB dan Solr bersama-sama dan mereka bekerja dengan baik. Anda dapat menemukan posting blog saya di sini di mana saya menjelaskan bagaimana kami menggunakan teknologi ini bersama-sama. Berikut ini kutipannya:

[...] Namun kami mengamati bahwa kinerja permintaan Solr berkurang ketika ukuran indeks meningkat. Kami menyadari bahwa solusi terbaik adalah menggunakan Solr dan Mongo DB secara bersamaan. Kemudian, kami mengintegrasikan Solr dengan MongoDB dengan menyimpan konten ke dalam MongoDB dan membuat indeks menggunakan Solr untuk pencarian teks lengkap. Kami hanya menyimpan id unik untuk setiap dokumen dalam indeks Solr dan mengambil konten aktual dari MongoDB setelah mencari di Solr. Mendapatkan dokumen dari MongoDB lebih cepat daripada Solr karena tidak ada analisa, penilaian dll. [...]

— Parvin Gasimzade
sumber
3
Posting blog yang bagus. Ya, inilah tepatnya cara saya menggunakan Lucene di masa lalu dengan SQL dan MySql datastores yang lebih lama (menyimpan ID di Lucene, dan mengambil tipe kompleks dari datastore). Namun secara teknis, pertanyaan ini adalah untuk mengeksplorasi perbedaan antara keduanya - tidak persis bagaimana menggunakan "yang terbaik dari kedua dunia." +1 untuk menggunakannya seperti itu, karena ini benar-benar satu-satunya cara nyata untuk menggunakan data dalam jumlah besar.
— eduncan911
Terimakasih atas tanggapan Anda. Saya tahu bahwa pertanyaannya adalah tentang memilih Nosql daripada Lucene, tetapi di sini saya ingin menunjukkan bahwa, alih-alih memilih Nosql lebih dari yang lain, menggunakannya dengan cara hybrid akan memberikan hasil yang lebih baik.
— Parvin Gasimzade
2
Apakah Anda ingat (sekarang 1,5 tahun kemudian) kira-kira ukuran basis data Solr ketika kinerja kueri menurun sangat banyak sehingga Anda mulai berpikir tentang menambahkan MongoDB? (Apakah 10.000 dokumen atau 10.000 dokumen?)
— KajMagnus
Sangat membantu. Saya bekerja di GIS dan dapat menggabungkan teks lengkap dengan pencarian spasial dengan cara ini sangat menarik. Kami sudah menggunakan MongoDB dan Postgres, dan saya sudah memikirkan Solr untuk sementara waktu.
— John Powell
2
@ParvinGasimzade tautan posting blog tidak berfungsi. Bisakah Anda memberikan tautan atau sumber lain?
— terlupakan
24

Juga harap dicatat bahwa beberapa orang telah mengintegrasikan Solr / Lucene ke dalam Mongo dengan meminta agar semua indeks disimpan di Solr dan juga memantau operasi oplog dan membagi pembaruan yang relevan ke dalam Solr.

Dengan pendekatan hybrid ini Anda benar-benar dapat memiliki yang terbaik dari kedua dunia dengan kemampuan seperti pencarian teks lengkap dan membaca cepat dengan datastore yang andal yang juga dapat memiliki kecepatan menulis yang sangat tinggi.

Agak teknis untuk setup tetapi ada banyak tailer oplog yang dapat diintegrasikan ke dalam solr. Lihat rentang apa yang dilakukan di artikel ini.

http://denormalised.com/home/mongodb-pub-sub-using-the-replication-oplog.html

— Prasith Govin
sumber
Jika saya mengerti Anda dengan benar, alasan Anda menggunakan MongoDB (selain Solr), apakah MongoDB memiliki kecepatan penyisipan + baca yang lebih cepat? Apakah Anda juga menunjukkan bahwa MongoDB memiliki datastore yang lebih andal? (Atau apakah Anda mengacu pada Solr?) - Apa yang Anda mulai dengan awalnya? Hanya MongoDB, hanya Solr, atau keduanya Mongo + Solr?
— KajMagnus
12

Dari pengalaman saya dengan keduanya, Mongo sangat bagus untuk penggunaan yang sederhana dan mudah. Kerugian utama Mongo yang kami alami adalah kinerja yang buruk pada kueri yang tidak diantisipasi (Anda tidak dapat membuat indeks mongo untuk semua kemungkinan kombinasi filter / sortir, Anda tidak bisa).

Dan di sini tempat Lucene / Solr menang, terutama dengan caching FilterQuery, Performa luar biasa.

— mjalajel
sumber
10

Karena tidak ada orang lain yang menyebutkannya, izinkan saya menambahkan bahwa MongoDB adalah skema-kurang, sedangkan Solr memberlakukan skema. Jadi, jika bidang dokumen Anda cenderung berubah, itu salah satu alasan untuk memilih MongoDB daripada Solr.

— Akuarel
sumber
6
IMHO itu tidak sepenuhnya benar. Solr memang memiliki skema seperti yang didefinisikan dalam schema.xml, TETAPI itu juga memiliki 'bidang dinamis', yaitu bidang yang jenisnya ditentukan melalui kartu liar, sehingga Anda dapat memiliki semua bidang yang cocok, misalnya, *_idiindeks sebagai bidang bilangan bulat. saat menambahkan dokumen, maka Anda dapat memiliki dokumen conaining bidang seperti count_i, foo_i, bar_iyang semuanya dipahami sebagai bidang bilangan bulat tanpa muncul di schema.xmlharfiah. skema-kurang cantik, kataku. lihat youtube.com/watch?v=WYVM6Wz-XTw untuk informasi lebih lanjut.
— mengalir
Saya harus kembali dan menabrak ini dengan +1 karena itu benar - perubahan skema di Solr selalu dalam PITA untuk tetap sinkron dengan penyimpanan data lainnya.
— eduncan911
4
Solr memiliki fitur yang mendukung skema atau tanpa skema!
— Krunal
1

Jika Anda hanya ingin menyimpan data menggunakan format nilai kunci, Lucene tidak direkomendasikan karena indeks terbalik akan membuang terlalu banyak ruang disk. Dan dengan penghematan data dalam disk, kinerjanya jauh lebih lambat daripada database NoSQL seperti redis karena redis menyimpan data dalam RAM. Keuntungan paling bagi Lucene adalah mendukung banyak permintaan, sehingga permintaan fuzzy dapat didukung.

— 张洪岩
sumber
1

Solusi pihak ketiga, seperti mongo op-log tail sangat menarik. Masih ada beberapa pemikiran atau pertanyaan tentang apakah solusi tersebut dapat diintegrasikan secara erat, dengan asumsi perspektif pengembangan / arsitektur. Saya tidak berharap melihat solusi yang terintegrasi erat untuk fitur-fitur ini karena beberapa alasan (agak spekulatif dan dapat diklarifikasi dan tidak up to date dengan upaya pengembangan):

  • mongo adalah c ++, lucene / solr adalah java
  • lucene mendukung berbagai format dokumen
    • mongo berfokus pada JSON (BSON)
  • Lucene menggunakan dokumen yang tidak dapat diubah
    • pembaruan bidang tunggal merupakan masalah, jika tersedia
  • indeks lucene tidak dapat diubah dengan operasi gabungan yang kompleks
  • pertanyaan mongo adalah javascript
  • mongo tidak memiliki penganalisa teks / tokenizers (AFAIK)
  • ukuran mongo doc terbatas, yang mungkin bertentangan dengan gandum untuk lucene
  • operasi agregasi mongo mungkin tidak memiliki tempat dalam lucene
    • Lucene memiliki opsi untuk menyimpan bidang di seluruh dokumen, tetapi itu bukan hal yang sama
    • solr entah bagaimana menyediakan permintaan agregasi / statistik dan SQL / grafik
— Darren Weber
sumber
0

MongoDB Atlas akan segera memiliki mesin pencari berbasis lucene. Pengumuman besar dibuat pada konferensi Dunia MongoDB 2019 minggu ini. Ini adalah cara yang bagus untuk mendorong lebih banyak penggunaan produk MongoDB Atlas berpenghasilan tinggi.

Saya berharap untuk melihatnya masuk ke MongoDB Enterprise versi 4.2 tetapi tidak ada berita untuk membawanya ke lini produk on-prem mereka.

Info lebih lanjut di sini: https://www.mongodb.com/atlas/full-text-search

— Gary Russo
sumber
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.