Solr vs. ElasticSearch [ditutup]

Apa perbedaan arsitektur inti antara teknologi ini?

Juga, kasus penggunaan apa yang umumnya lebih sesuai untuk masing-masing kasus?

Memperbarui

Sekarang ruang lingkup pertanyaan telah diperbaiki, saya dapat menambahkan sesuatu dalam hal ini juga:

Ada banyak perbandingan antara Apache Solr dan ElasticSearch yang tersedia, jadi saya akan merujuk sendiri yang menurut saya paling berguna, yaitu mencakup aspek yang paling penting:

• Bob Yoplait sudah menghubungkan jawaban kimchy dengan ElasticSearch, Sphinx, Lucene, Solr, Xapian. Yang cocok untuk penggunaan mana? , yang merangkum alasan mengapa ia terus maju dan menciptakan ElasticSearch , yang menurutnya memberikan model terdistribusi yang jauh lebih unggul dan kemudahan penggunaan dibandingkan dengan Solr.

• Pencarian Realtime Ryan Sonnek : Solr vs Elasticsearch memberikan analisis / perbandingan yang mendalam dan menjelaskan mengapa ia beralih dari Solr ke ElasticSeach, meskipun sudah menjadi pengguna Solr yang bahagia - ia merangkum ini sebagai berikut:

  Solr mungkin menjadi senjata pilihan ketika membangun aplikasi pencarian standar , tetapi Elasticsearch membawanya ke tingkat berikutnya dengan arsitektur untuk membuat aplikasi pencarian realtime modern . Perkolasi adalah fitur yang menarik dan inovatif yang sendirian meniup Solr keluar dari air. Elasticsearch scalable, cepat dan impian untuk diintegrasikan . Adios Solr, senang mengenal Anda. [penekanan milikku]

• Artikel Wikipedia tentang ElasticSearch mengutip perbandingan dari majalah iX Jerman yang terkenal, yang berisi daftar keuntungan dan kerugian, yang cukup meringkas apa yang telah dikatakan di atas:

  Keuntungan :

  • ElasticSearch didistribusikan. Tidak diperlukan proyek terpisah. Replika juga hampir real-time, yang disebut "Push replikasi".
  • ElasticSearch sepenuhnya mendukung pencarian waktu dekat Apache Lucene.
  • Menangani multitenancy bukan konfigurasi khusus, di mana dengan Solr diperlukan pengaturan yang lebih lanjut.
  • ElasticSearch memperkenalkan konsep Gateway, yang membuat backup penuh lebih mudah.

  Kekurangan :

  • Hanya satu pengembang utama [tidak berlaku lagi menurut organisasi GitHub elasticsearch saat ini , di samping memiliki basis committer yang cukup aktif]
  • Tidak ada fitur autowarming [tidak berlaku lagi sesuai dengan Indeks Pemanasan Indeks yang baru ]

Jawaban awal

Mereka adalah teknologi yang sama sekali berbeda menangani kasus penggunaan yang sama sekali berbeda, sehingga tidak dapat dibandingkan sama sekali dengan cara yang bermakna:

• Apache Solr - Apache Solr menawarkan kemampuan Lucene dalam server pencarian cepat dan mudah digunakan dengan fitur-fitur tambahan seperti faceting, skalabilitas, dan banyak lagi

• Amazon ElastiCache - Amazon ElastiCache adalah layanan web yang membuatnya mudah digunakan, dioperasikan, dan skala cache dalam -memori di cloud.

  • Harap dicatat bahwa Amazon ElastiCache sesuai dengan protokol dengan Memcached, sistem caching objek memori yang diadopsi secara luas, sehingga kode, aplikasi, dan alat populer yang Anda gunakan hari ini dengan lingkungan Memcached yang ada akan bekerja secara mulus dengan layanan (lihat Memcached untuk detailnya).

[penekanan milikku]

Mungkin ini telah dikacaukan dengan dua teknologi terkait berikut ini satu atau lain cara:

• ElasticSearch - Ini adalah Open Source (Apache 2), Terdistribusi, Tenang, Mesin Pencari yang dibangun di atas Apache Lucene.

• Amazon CloudSearch - Amazon CloudSearch adalah layanan pencarian yang dikelola sepenuhnya di cloud yang memungkinkan pelanggan untuk dengan mudah mengintegrasikan fungsionalitas pencarian yang cepat dan sangat skalabel ke dalam aplikasi mereka.

Penawaran Solr dan ElasticSearch terdengar sangat mirip pada pandangan pertama, dan keduanya menggunakan mesin pencari backend yang sama, yaitu Apache Lucene .

Sementara Solr lebih tua, cukup fleksibel dan matang serta banyak digunakan, ElasticSearch telah dikembangkan secara khusus untuk mengatasi kekurangan Solr dengan persyaratan skalabilitas di lingkungan cloud modern, yang sulit untuk diatasi dengan Solr .

Karena itu mungkin akan sangat berguna untuk membandingkan ElasticSearch dengan Amazon CloudSearch yang baru diperkenalkan (lihat posting pengantar Mulai Pencarian dalam Satu Jam dengan Kurang dari $ 100 / Bulan ), karena keduanya mengklaim untuk menutup kasus penggunaan yang sama pada prinsipnya.

Saya melihat beberapa jawaban di atas sekarang agak ketinggalan zaman. Dari sudut pandang saya, dan saya bekerja dengan Solr (Cloud dan non-Cloud) dan ElasticSearch setiap hari, berikut adalah beberapa perbedaan yang menarik:

• Komunitas: Solr memiliki komunitas pengguna, pengembang, dan kontributor yang lebih besar, lebih dewasa. ES memiliki komunitas pengguna yang lebih kecil namun aktif dan komunitas kontributor yang terus bertambah
• Kedewasaan: Solr lebih dewasa, tetapi ES telah tumbuh dengan cepat dan saya menganggapnya stabil
• Kinerja: sulit dinilai. Saya / kami belum melakukan tolok ukur kinerja langsung. Seseorang di LinkedIn pernah membandingkan Solr vs ES vs Sensei, tetapi hasil awal harus diabaikan karena mereka menggunakan pengaturan non-ahli untuk Solr dan ES.
• Desain: Orang menyukai Solr. Java API agak bertele-tele, tetapi orang-orang suka bagaimana disatukan. Sayangnya, kode solr tidak selalu sangat cantik. ES juga memiliki sharding, replikasi real-time, dokumen dan routing bawaan. Sementara beberapa di antaranya ada di Solr, rasanya agak seperti sebuah pikiran.
• Dukungan: ada perusahaan yang menyediakan dukungan teknis dan konsultasi untuk Solr dan ElasticSearch. Saya pikir satu-satunya perusahaan yang menyediakan dukungan untuk keduanya adalah Sematext (pengungkapan: Saya pendiri Sematext)
• Skalabilitas: keduanya dapat diskalakan ke kluster yang sangat besar. ES lebih mudah untuk diukur daripada versi Solr 4.0 Solr sebelumnya, tetapi dengan Solr 4.0 itu tidak lagi menjadi masalah.

Untuk cakupan yang lebih menyeluruh tentang topik Solr vs. ElasticSearch, lihat di https://sematext.com/blog/solr-vs-elasticsearch-part-1-overview/ . Ini adalah posting pertama dalam rangkaian posting dari Sematext yang melakukan perbandingan Solr vs ElasticSearch langsung dan netral. Pengungkapan: Saya bekerja di Sematext.

Saya melihat bahwa banyak orang di sini telah menjawab pertanyaan ElasticSearch vs Solr ini dalam hal fitur dan fungsionalitas, tetapi saya tidak melihat banyak diskusi di sini (atau di tempat lain) mengenai bagaimana mereka membandingkan dalam hal kinerja.

Itu sebabnya saya memutuskan untuk melakukan penyelidikan sendiri . Saya mengambil layanan data mikro sumber heterogen yang sudah dikodekan yang sudah menggunakan Solr untuk pencarian istilah. Saya mengganti Solr untuk ElasticSearch kemudian saya menjalankan kedua versi pada AWS dengan aplikasi uji beban yang sudah dikodekan dan menangkap metrik kinerja untuk analisis selanjutnya.

Inilah yang saya temukan. ElasticSearch memiliki 13% lebih tinggi throughput ketika datang untuk mengindeks dokumen tetapi Solr sepuluh kali lebih cepat. Ketika datang untuk menanyakan dokumen, Solr memiliki throughput lima kali lebih banyak dan lima kali lebih cepat daripada ElasticSearch.

Karena sejarah panjang Apache Solr, saya pikir salah satu kekuatan Solr adalah ekosistemnya . Ada banyak plugin Solr untuk berbagai jenis data dan keperluan.

Cari platform di lapisan berikut dari bawah ke atas:

• Data
  • Tujuan: Menampilkan berbagai tipe dan sumber data
• Bangunan dokumen
  • Tujuan: Membangun informasi dokumen untuk pengindeksan
• Pengindeksan dan pencarian
  • Tujuan: Membuat dan meminta indeks dokumen
• Peningkatan logika
  • Tujuan: Logika tambahan untuk memproses kueri dan hasil pencarian
• Layanan platform pencarian
  • Tujuan: Tambahkan fungsi tambahan inti mesin pencari untuk menyediakan platform layanan.
• Aplikasi UI
  • Tujuan: Antarmuka pencarian pengguna akhir atau aplikasi

Artikel referensi: Pencarian perusahaan

Saya telah membuat tabel perbedaan besar antara elasticsearch dan Solr dan splunk, Anda dapat menggunakannya sebagai pembaruan 2016:

Saya telah bekerja pada pencarian solr dan elastis untuk aplikasi .Net. Perbedaan utama yang saya hadapi adalah

Pencarian elastis:

• Lebih banyak kode dan lebih sedikit konfigurasi, namun ada api yang harus diubah tetapi masih ada perubahan kode
• untuk tipe kompleks, ketik dalam tipe yaitu tipe bersarang (tidak dapat dicapai dalam solr)

Solr:

• kode lebih sedikit dan lebih banyak konfigurasi dan karenanya lebih sedikit pemeliharaan
• untuk pengelompokan hasil selama kueri (banyak pekerjaan yang harus dicapai dalam pencarian elastis dalam waktu singkat dan tidak langsung)

Walaupun semua tautan di atas memiliki manfaat, dan telah sangat bermanfaat bagi saya di masa lalu, sebagai ahli bahasa yang "terpapar" ke berbagai mesin pencari Lucene selama 15 tahun terakhir, saya harus mengatakan bahwa pengembangan pencarian elastis sangat cepat dengan Python. Meski begitu, beberapa kode terasa tidak intuitif bagi saya. Jadi, saya menjangkau ke salah satu komponen tumpukan ELK, Kibana, dari perspektif open source, dan menemukan bahwa saya dapat membuat kode elastics cryptic dengan mudah di Kibana. Juga, saya bisa menarik pertanyaan Chrome Sense ke Kibana juga. Jika Anda menggunakan Kibana untuk mengevaluasi, itu akan semakin mempercepat evaluasi Anda. Apa yang memakan waktu berjam-jam untuk berjalan di platform lain sudah berjalan dan berjalan di JSON di Sense di atas elasticsearch (antarmuka RESTful) dalam beberapa menit paling buruk (set data terbesar); paling cepat dalam hitungan detik. Dokumentasi untuk elasticsearch, sementara 700+ halaman, tidak menjawab pertanyaan yang saya miliki yang biasanya akan diselesaikan dalam SOLR atau dokumentasi Lucene lainnya, yang jelas membutuhkan lebih banyak waktu untuk menganalisis. Juga, Anda mungkin ingin melihat Agregat di pencarian elastis, yang telah membawa Faceting ke tingkat yang baru.

Gambaran yang lebih besar: jika Anda melakukan ilmu data, analisis teks, atau linguistik komputasi, elasticsearch memiliki beberapa algoritma peringkat yang tampaknya berinovasi dengan baik di bidang pencarian informasi. Jika Anda menggunakan algoritma TF / IDF, Frekuensi Teks / Frekuensi Dokumen Balik, elasticsearch memperluas algoritme 1960-an ini ke tingkat yang baru, bahkan menggunakan BM25, Best Match 25, dan algoritme Relevancy Ranking lainnya. Jadi, jika Anda membuat skor atau meranking kata, frasa atau kalimat, elasticsearch melakukan penilaian ini dengan cepat, tanpa biaya besar dari pendekatan analisis data lainnya yang membutuhkan waktu berjam-jam - penghematan waktu elasticsearch lainnya. Dengan es, menggabungkan beberapa kekuatan penyatuan dari agregasi dengan penilaian dan peringkat relevansi data JSON waktu nyata, Anda dapat menemukan kombinasi yang unggul,

Catatan: memang melihat diskusi serupa tentang agregasi di atas, tetapi tidak pada agregasi dan penilaian relevansi - permintaan maaf saya untuk tumpang tindih. Pengungkapan: Saya tidak bekerja untuk elastis dan tidak akan bisa mendapatkan keuntungan dalam waktu dekat dari karya bagus mereka karena jalur arsitektur yang berbeda, kecuali saya melakukan pekerjaan amal dengan elasticsearch, yang tidak akan menjadi ide yang buruk

Bayangkan use case:

1. Banyak (100+) indeks pencarian kecil (10Mb-100Mb, 1000-100000 dokumen).
2. Mereka menggunakan banyak aplikasi (layanan microser)
3. Setiap aplikasi dapat menggunakan lebih dari satu indeks
4. Kecil dengan indeks ukuran, ya. Tetapi pemuatan yang besar (ratusan permintaan pencarian per detik) dan permintaan itu kompleks (banyak agregasi, kondisi, dan sebagainya)
5. Waktu henti tidak diizinkan
6. Semua itu bekerja bertahun-tahun, dan terus berkembang.

Gagasan untuk memiliki instance ES individual per setiap indeks - adalah biaya overhead yang besar dalam kasus ini.

Berdasarkan pengalaman saya, jenis penggunaan ini sangat kompleks untuk didukung dengan Elasticsearch.

Mengapa?

PERTAMA.

Masalah utama adalah mengabaikan kompatibilitas kembali mendasar.

Memecah perubahan sangat keren! (Catatan: bayangkan SQL-server yang mengharuskan Anda melakukan perubahan kecil dalam semua pernyataan SQL Anda, ketika ditingkatkan ... tidak dapat membayangkannya. Tetapi untuk ES itu normal)

Penghentian yang akan dijatuhkan dalam rilis besar berikutnya sangat seksi! (Catatan: Anda tahu, Java mengandung beberapa penghinaan, yang berumur 20+ tahun, tetapi masih berfungsi dalam versi Java yang sebenarnya ...)

Dan tidak hanya itu, kadang-kadang Anda bahkan memiliki sesuatu yang tidak didokumentasikan (secara pribadi hanya sekali tetapi ...)

Begitu. Jika Anda ingin meningkatkan ES (karena Anda memerlukan fitur baru untuk beberapa aplikasi atau Anda ingin mendapatkan perbaikan bug) - Anda berada di neraka. Terutama jika ini tentang peningkatan versi utama.

API Klien tidak akan kembali kompatibel. Pengaturan indeks tidak akan kembali kompatibel. Dan memutakhirkan semua aplikasi / layanan saat yang sama dengan peningkatan ES tidak realistis.

Tetapi Anda harus melakukannya dari waktu ke waktu. Tidak ada jalan lain.

Indeks yang ada diperbarui secara otomatis? - Iya. Tapi itu tidak membantu Anda ketika Anda perlu mengubah beberapa pengaturan indeks lama.

Untuk mengatasinya, Anda perlu terus-menerus menginvestasikan banyak daya dalam ... meneruskan kompatibilitas aplikasi / layanan Anda dengan rilis ES yang akan datang. Atau Anda perlu membuat (dan tetap mendukung) semacam middleware antara aplikasi / layanan Anda dan ES, yang memberi Anda kembali API klien yang kompatibel. (Dan, Anda tidak dapat menggunakan Transport Client (karena itu memerlukan peningkatan jar untuk setiap upgrade ES versi kecil), dan fakta ini tidak membuat hidup Anda lebih mudah)

Apakah ini terlihat sederhana & murah? Tidak, tidak. Jauh dari itu. Pemeliharaan berkelanjutan dari infrastruktur kompleks yang berbasis ES, adalah cara yang mahal dalam semua hal yang memungkinkan.

KEDUA. API sederhana? Ya ... tidak juga. Ketika Anda benar-benar menggunakan kondisi dan agregasi yang kompleks .... JSON-request dengan 5 level bersarang adalah apa pun, tetapi tidak sederhana.

Sayangnya, saya tidak punya pengalaman dengan SOLR, tidak bisa mengatakan apa-apa tentang itu.

Tapi Sphinxsearch jauh lebih baik dalam skenario ini, karena SphinxQL yang sepenuhnya kompatibel kembali.

Catatan: Sphinxsearch / Manticore memang menarik. Ini bukan berbasis Lucine, dan akibatnya sangat berbeda. Berisi beberapa fitur unik dari kotak yang ES tidak miliki dan gila cepat dengan indeks ukuran kecil / menengah.

Jika Anda sudah menggunakan SOLR, tetap gunakan itu. Jika Anda memulai, pergi untuk pencarian elastis.

Masalah utama maksimum telah diperbaiki di SOLR dan ini cukup matang.

Saya telah menggunakan Elasticsearch selama 3 tahun dan Solr selama sekitar satu bulan, saya merasa cluster elasticsearch cukup mudah dipasang dibandingkan dengan instalasi Solr. Elasticsearch memiliki kumpulan dokumen bantuan dengan penjelasan yang luar biasa. Salah satu kasus penggunaan saya terjebak dengan Histogram Aggregation yang tersedia di ES namun tidak ditemukan di Solr.

Saya hanya menggunakan pencarian elastis. Karena saya menemukan solr sangat sulit untuk memulai. Fitur pencarian elastis:

1. Mudah untuk memulai, sangat sedikit pengaturan. Bahkan seorang pemula dapat mengatur cluster langkah demi langkah.
2. API Tenang Sederhana yang menggunakan kueri NoSQL. Dan banyak perpustakaan bahasa untuk mengakses dengan mudah.
3. Dokumen yang bagus, Anda dapat membaca buku:. Ada versi web di situs web resmi.

Tambahkan dokumen bersarang di solr sangat kompleks dan pencarian data bersarang juga sangat kompleks. tetapi Pencarian Elastis mudah untuk menambahkan dokumen dan pencarian bersarang