Bu teknolojiler arasındaki temel mimari farklılıklar nelerdir?
Ayrıca, hangi kullanım durumları genellikle her biri için daha uygundur?
Şimdi soru kapsamı düzeltildikten sonra, bu konuda da bir şeyler ekleyebilirim:
Bob Yoplait kimchy'nin cevabını ElasticSearch, Sphinx, Lucene, Solr, Xapian ile ilişkilendirdi. Hangisi hangi kullanıma uygun? , neden Solri'ye kıyasla ileri gitti ve ElasticSearch oluşturdu nedenlerini özetliyor; bu da çok daha iyi dağıtılmış bir model sağlar ve kullanım kolaylığı sağlar.
Ryan Sonnek'in Gerçek Zamanlı Araması: Solr vs Elasticsearch , anlayışlı bir analiz/karşılaştırma sunar ve neden Solr'dan ElasticSeach'e geçtiğini açıklar, bunun için mutlu bir Solr kullanıcısı olmasına rağmen - şu şekilde özetler:
Solr standart arama uygulamaları oluştururken tercih edilen silah olabilir , fakat Elasticsearch modern gerçek zamanlı arama oluşturmak için bir mimarisi ile bir sonraki seviyeye götürür uygulamalar . Percolation, Solr'u sudan tek elle çeken heyecan verici ve yenilikçi bir özelliktir. Elasticsearch ölçeklenebilir, hızlı ve ile bütünleşecek bir rüya. Adios Solr, seni tanımak güzeldi. [benim vurgularım]
ElasticSearch hakkındaki Wikipedia makalesi, tanınmış Alman iX dergisinden bir karşılaştırmadan alıntı yaparak yukarıda belirtilenleri hemen hemen özetleyen avantajları ve dezavantajları listeliyor:
Avantajlar :
- ElasticSearch dağıtılır. Ayrı proje gerekmez. Kopyalar da gerçek zamanlıya yakındır, buna "Push replication" adı verilir.
- ElasticSearch, Apache Lucene'in neredeyse gerçek zamanlı aramasını tamamen destekler.
- Çoklu kiralama yönetimi, Solr ile daha gelişmiş bir kurulumun gerekli olduğu özel bir yapılandırma değildir.
- ElasticSearch, tam yedeklemeleri kolaylaştıran Gateway kavramını sunar.
Dezavantajlar :
Sadece bir ana geliştirici[mevcut elasticsearch GitHub organizasyonuna göre artık geçerli değil , ilk etapta oldukça aktif bir üretici tabanına sahip olmanın yanı sıra] Otomatik ısınma özelliği yok[yeni Index Warmup API'sine göre artık uygulanamaz]
Tamamen farklı kullanım durumlarını ele alan tamamen farklı teknolojilerdir, dolayısıyla hiçbir şekilde anlamlı bir şekilde karşılaştırılamazlar:
Apache Solr - Apache Solr, kullanımı kolay, hızlı arama sunucusu faceting, ölçeklenebilirlik ve çok daha fazlası gibi ek özelliklerle Lucene'nin yeteneklerini sunar
Amazon ElastiCache - Amazon ElastiCache, bir bellekteki önbelleği bulutta dağıtmayı, çalıştırmayı ve ölçeklendirmeyi kolaylaştıran bir web hizmetidir.
[benim vurgularım]
Belki de bu, aşağıdaki iki ilgili teknolojiyle bir şekilde veya daha fazlası ile karıştırılmıştır:
ElasticSearch - Açık Kaynaktır (Apache 2), Dağıtılmış, RESTful, Apache Lucene üzerine kurulu Arama Motoru.
Amazon CloudSearch - Amazon CloudSearch, bulutta müşterilerin hızlı ve yüksek ölçeklenebilir arama işlevlerini uygulamalarına kolayca entegre etmelerini sağlayan tamamen yönetilen bir arama hizmetidir.
Solr ve ElasticSearch teklifleri ilk bakışta dikkat çekici bir şekilde benzerdir ve her ikisi de aynı arka uç arama motorunu kullanır, yani Apache Lucene .
Solr daha eskiyken, oldukça çok yönlü ve olgun ve buna göre yaygın olarak kullanılırken ElasticSearch, özellikle modern bulut ortamlarında ölçeklenebilirlik gereksinimlerine sahip Solr eksikliklerini gidermek için özel olarak geliştirilmiştir. Solr ile adreslenmesi zordur (er).
Bu nedenle, ElasticSearch ile en son tanıtılan Amazon CloudSearch ile karşılaştırmak en faydalı olacaktır. (Tanıtım yazılarına bakın Bir Saatte 100 $/Ay'dan Az Bir Saatte Aramaya Başlayın ) , çünkü her ikisi de aynı kullanım durumlarını prensipte kapsadığını iddia eder.
Görüyorum ki yukarıdaki cevapların bazıları artık güncel değil. Benim bakış açıma göre, hem Solr (Cloud ve Cloud olmayan) hem de ElasticSearch ile günlük olarak çalışıyorum, işte bazı ilginç farklılıklar:
Solr ve ElasticSearch konusunun daha kapsamlı kapsama almak için https://sematext.com/blog/solr-vs-elasticsearch-part-1-overview/ 'a bakınız. Bu, Sematext'ten doğrudan ve nötr Solr'e karşı ElasticSearch karşılaştırması yapan mesaj dizisindeki ilk yazıdır. Açıklama: Sematext'te çalışıyorum.
Buradaki birçok insanın, bu ElasticSearch-Solr sorusunu özellikler ve işlevsellik açısından cevapladığını görüyorum ama burada (veya başka bir yerde) performans açısından nasıl karşılaştırıldıklarına ilişkin fazla tartışma göremiyorum.
Bu yüzden kendi soruşturmam . Terim araması için zaten Solr kullanılan, kodlanmış heterojen bir veri kaynağı mikro hizmeti aldım. ElasticSearch için Solr'ı değiştirdim, sonra her iki versiyonu da zaten kodlanmış bir yük testi uygulaması ile AWS'de çalıştırdım ve sonraki analizler için performans ölçütlerini aldım.
İşte ne buldum. ElasticSearch, dokümanları endeksleme konusunda% 13 daha fazla verim elde etti, ancak Solr on kat daha hızlıydı. Dokümanları sorgulamaya gelince, Solr beş kat fazla çıktı ve ElasticSearch'ten beş kat daha hızlıydı.
Apache Solr'un uzun geçmişinden beri, Solr'un bir gücünün onun ekosistem olduğunu düşünüyorum. Farklı veri türleri ve amaçları için birçok Solr eklentisi vardır.
Aşağıdaki katmanlarda alttan üste arama platformu:
Referans makale: Kurumsal arama
Net uygulamaları için hem solr, hem de esnek arama üzerinde çalışıyorum. Karşılaştığım en büyük fark
Elastik arama:
Solr:
Yukarıdaki bağlantıların hepsi hak eder ve geçmişte bana büyük faydalar sağlasa da, son 15 yıldır çeşitli Lucene arama motorlarına "maruz bırakılmış" bir dilbilimci olarak Python'da elastik arama geliştirmenin çok hızlı olduğunu söylemeliyim. Olduğu söyleniyor, bazı kodlar bana sezgisel değildi. Böylece, ELK yığınının bir bileşenine, Kibana'ya, açık kaynak bakış açısıyla baktım ve Kibana'da çok kolay bir şekilde şifreli elasticsearch kodunu üretebileceğimi öğrendim. Ayrıca, Chrome Sense es sorgularını Kibana'ya da çekebilirim. Kibana'yı değerlendirmek için kullanırsanız, değerlendirmenizi daha da hızlandıracaktır. Diğer platformlarda çalışmak saatler sürdü, JSON'da SENS in elasticsearch'ün (RESTful arayüzü) en kötüsünde (en büyük veri setleri) birkaç dakika içinde çalışıyordu; en iyi ihtimalle saniyeler içinde. Elasticsearch dokümantasyonu, 700'den fazla sayfa olmasına rağmen, normalde SOLR veya diğer Lucene dokümantasyonlarında çözülecek olan soruları cevaplamadı, ki bu analizin daha fazla zaman aldığını açıkça gösteriyor. Ayrıca, Faceting'i yeni bir seviyeye çıkaran elastik aramadaki Agregalara bakmak isteyebilirsiniz.
Daha büyük resim: veri bilimi, metin analitiği veya hesaplamalı dilbilimi yapıyorsanız, elasticsearch'ün bilgi alma alanında iyi yenilikler yapan bazı sıralama algoritmaları vardır. Herhangi bir TF/IDF algoritması, Metin Frekansı/Ters Doküman Frekansı kullanıyorsanız, elasticsearch, bu 1960 algoritmasını BM25, En İyi Eşleşme 25 ve diğer Alaka Sıralaması algoritmalarını kullanarak bile yeni bir seviyeye çıkarır. Yani, kelimeleri, cümleleri veya cümleleri puanlıyor veya sıralıyorsanız, elasticsearch bu puanlamayı anında gerçekleştirir, saatlerce süren diğer veri analitiği yaklaşımlarının büyük bir yükü olmadan başka bir elasticsearch zaman tasarrufu sağlar. Toplamaların bazı güçlü yanlarını gerçek zamanlı JSON veri alaka düzeyi puanlaması ve sıralamasıyla birleştiren es ile, çevik (hikayeler) veya mimari (kullanım durumları) yaklaşımınıza bağlı olarak kazanan bir kombinasyon bulabilirsiniz.
Not: Yukarıdaki toplanmalar üzerinde benzer bir tartışma gördük, ancak toplanmalar ve alaka düzeyi puanlaması üzerinde değil - herhangi bir çakışma için özür dilerim. Açıklama: Esneklik için çalışmıyorum ve yakın gelecekte, farklı bir mimari yol nedeniyle mükemmel çalışmalarından faydalanamayacağım, elasticsearch ile kötü bir fikir olmazsa bazı hayır işleri yapmazsam
Kullanım durumunu düşünün:
Her bir dizin için ayrı ES örneğine sahip olma fikri - bu durumda genel gider.
Tecrübelerime dayanarak, bu tür bir kullanım durumu Elasticsearch ile desteklemek için çok karmaşık.
Niye ya?
İLK.
Asıl sorun temel sırt uyumluluğu konusundaki ihmaldir.
Değişen değişiklikler çok güzel! (Not: tüm SQL deyimlerinizde küçük değişiklikler yapmanızı gerektiren SQL sunucusunu hayal edin, yükseltildiğinde ... hayal bile edemez. Ancak ES için normaldir)
Bir sonraki ana sürümde düşecek olan mahrumiyetler çok seksi! (Not: Biliyorsun ki, Java 20 yaşından büyük fakat hala gerçek Java sürümünde çalışan bazı kısıtlamalar içeriyor ...)
Ve yalnızca bu değil, bazen belgelenen hiçbir yere belgeleyen bir şey bile yoktur (kişisel olarak yalnızca bir kez karşılaşıldı ama ...)
Yani. ES'yi yükseltmek istiyorsanız (çünkü bazı uygulamalar için yeni özelliklere ihtiyacınız var veya hata düzeltmeleri almak istiyorsanız) - cehennemdesiniz. Özellikle büyük sürüm yükseltme ile ilgili ise.
Müşteri API’sı geri uyumlu olmayacak. Dizin ayarları uyumlu olmayacak. Ve ES yükseltme ile tüm uygulama/hizmetleri aynı anda yükseltme gerçekçi değildir.
Ama zaman zaman yapmalısın. Başka yol yok.
Mevcut dizinler otomatik olarak yükseltiliyor mu? - Evet. Ancak bazı eski dizin ayarlarını değiştirmeniz gerektiğinde size yardımcı olmaz.
Bununla yaşamak için, ES'nin gelecekteki sürümleriyle uygulamalarınızın/hizmetlerinin uyumluluğunu geliştirmek için sürekli olarak çok fazla güce yatırım yapmanız gerekir. Veya, uygulamanız/hizmetleriniz ile ES arasında uyumlu istemci API'sini geri sağlayan bir tür ara katman geliştirmeniz (ve yine de desteklemesi) gerekir. (Ve Transport Client'ı kullanamazsınız (çünkü her küçük sürüm ES yükseltmesi için jar yükseltmesi gerekir) ve bu gerçek hayatınızı kolaylaştırmaz)
Basit ve ucuz görünüyor mu? Hayır değil. Ne münasebet. ES'ye dayanan karmaşık altyapının sürekli bakımı, tüm olası duyumlarda pahalıya mal olur.
İKİNCİ. Basit API? Şey ... hayır gerçekten. Gerçekten karmaşık koşullar ve toplamalardan birini kullanıyorsanız .... 5 iç içe seviyeli JSON isteği her neyse, ancak basit değildir.
Ne yazık ki, SOLR konusunda hiçbir tecrübem yok, bu konuda hiçbir şey söyleyemem.
Ancak Sphinxsearch, bu senaryoda çok daha iyidir, tamamen uyumlu SphinxQL.
Not: Sphinxsearch/Manticore gerçekten ilginçtir. Lucine tabanlı değil ve sonuçta ciddi şekilde farklı. ES'nin sahip olmadığı ve küçük/orta boy indekslerle çılgınca hızlı çektiği eşsiz özellikleri içerir.
Elasticsearch'ü 3 yıl ve Solr'ı yaklaşık bir ay kullanıyorum, elasticsearch kümesinin Solr kurulumuna kıyasla kurulumu oldukça kolay olduğunu düşünüyorum. Elasticsearch'ün harika açıklamaları olan bir yardım belgeleri havuzu vardır. Kullanım durumundan biri, ES'de bulunan ancak Solr'da bulunmayan Histogram Agregasyonu ile sıkışıp kaldım.
Zaten SOLR kullanıyorsanız, buna bağlı kalın. Başlıyorsanız, Elastik arama için gidin.
SOLR'da maksimum ana sorun giderildi ve oldukça olgunlaştı.
Ben sadece elastik arama yapıyorum. Solr'ı bulduğumdan beri başlamak çok zor. Elastik aramanın özellikleri:
Solr içine iç içe bir belge ekleyin çok karmaşık ve iç içe veri araması da çok karmaşık. ancak Elastik Arama, iç içe geçmiş belge ve arama eklemek için kolay