Elastic Search vs porównanie Sunspot na funkcjach

Question

Nie można znaleźć żadnych porównywalnych pytań dotyczących plam słonecznych (Solr) do Elastic Search (Lucene) Jakie byłyby pro i con's w obu wyszukiwarkach?

Widziałem inne pytania VS, aby uzyskać lepszą jakość w porównaniu z 2 klejnotami, więc mam nadzieję, że pozwoli to uzyskać lepszy wgląd w oba silniki dla początkujących (jak ja). Spojrzałem już na plamę słoneczną, ale mam z nią pewne problemy. Więc szukałem

• http://www.elasticsearch.org/guide/reference/api/

vs

• http://sunspot.github.com/

Answer 1

myślę, że należy szukać porównania Solr i elastycznego wyszukiwania. W rzeczywistości plama słoneczna opiera się na Solr, a zarówno Solr, jak i elastyczne wyszukiwanie oparte są na Lucene. Są to dwa różne projekty o podobnych celach, oba zbudowane na bazie Lucene.

Oto dwa porównania:

ElasticSearch, Sphinx, Lucene, Solr, Xapian. Which fits for which usage?

http://www.findbestopensource.com/article-detail/solr-vs-elasticsearch

Answer 2

zacząłem pracować nad projektem, który potrzebny wyszukiwanie pełnotekstowe w Ruby tak naturalnie zacząłem z Solr + Sunspot, ale nie mogłem zmusić go do działania. To był ból, tylko je połączyć, a następnie próbował dowiedzieć się, czy dokument poprawnie indeksowane, dowiedzieć się klasy classpath, dzięki czemu można dodać dodatkowe klasy analizator/tokenizer, edycja config.xml/schema.xml itp. Solr numer wyraźnie powiedział, że otrzymał i zindeksował je, ale nie mogłem uzyskać żadnych wyników zapytań. Po kilku dniach zrezygnowałem, to było coś w rodzaju konfiguracji piekła.

ElasticSearch + Tire był przewiewny, aby go uruchomić, działa od godziny.

Lucene jest po prostu biblioteką do wyszukiwania w Javie, stąd Solr został opracowany jako aplikacja do wyszukiwania pełnego serwisu, ale Solr nadal posiada wszystkie zalety typowej aplikacji webowej Java: zbyt skomplikowane konfiguracje XML, schematy - ciężkie, oczekiwanie dokumentów XML dla indeksowanie, wymaga kontenera serwletu Java (Jetty lub Tomcat), który stał się dla mnie zbyt dużym punktem awarii.

ElasticSearch jest również oparty na Lucene, ma wbudowany kontener serwletu, więc po prostu uruchom go jak demon, używaj bardzo prostego API JSON + REST, więc jest świetny do testowania i bardziej naturalny dla Rubiego. To jest bezużyteczne i zadziałało dla mnie, nawet bez edytowania pliku konfiguracyjnego. Wszystko działało pięknie.

Tym, czego naprawdę potrzebowałem, było wyszukiwanie w języku chińskim, a ElasticSearch już spakowane narzędzie SmartChineseAnalyzer Luecene jako wtyczkę. Nie wiesz, jak trudne będzie dostosowanie łańcucha analizatora/tokenizera, jeśli potrzebujesz takiego dostosowania. Dokumentacja dla ElasticSearch i Tire są na najwyższym poziomie.

opon (biblioteka Ruby dla ElasticSearch)

https://github.com/karmi/tire

Można wypróbować demo, to będzie zainstalować searchapp szynach pobrać ElasticSearch binarny i uruchom go, a następnie rozpocznij WEBrick automatycznie.

$ rails new searchapp -m https://raw.github.com/karmi/tire/master/examples/rails-application-template.rb 

W moim systemie to narzekali nie posiadające silnik JavaScript (Rails 3.2 nie obejmują thereubyracer gem domyślnie?), Więc musiałem:

$ wget https://raw.github.com/karmi/tire/master/examples/rails-application-template.rb 
$ nano rails-application-template.rb 

dodać gem 'therubyracer' w file (poszukaj gem „opona” a gem „will_paginate”), a następnie ...

$ rails new searchapp -m rails-application-template.rb 

dla rozwija własną aplikację, po prostu downladed archiwum ElasticSearch i uruchomić na pierwszym planie z przełącznikiem -f (tak Mogę z łatwością st op go przez Ctrl-C)

$ bin/elasticsearch -f 

Można zainstalować wtyczkę eleasticsearch-głowy, aby uzyskać interfejs WWW administratora

https://github.com/mobz/elasticsearch-head

też coś się dowiedziałem: jeśli masz jedno-to- wiele modeli relacji, Tyre nie rozwiąże ich w wynikach wyszukiwania, po prostu zwraca kolekcję płaską. Twoje związki has_many i belongs_to będą po prostu identyfikatorami obiektów w kolekcji, a nie pełnymi obiektami.