Solr vs. ElasticSearch [закрито]

Які основні архітектурні відмінності між цими технологіями?

Крім того, які випадки використання, як правило, більше підходять для кожного?

Оновлення

Тепер, коли сфера питання була виправлена, я можу додати щось і в цьому плані:

Існує багато порівнянь між Apache Solr та ElasticSearch , тому я посилаюсь на ті, кого я вважав найбільш корисними, тобто висвітлював найважливіші аспекти:

• Боб Йоплайт вже пов’язав відповідь кімчі на ElasticSearch, Sphinx, Lucene, Solr, Xapian. Що підходить для якого використання? , який узагальнює причини, чому він пішов вперед і створив ElasticSearch , який, на його думку, забезпечує набагато чудову розподілену модель та простоту використання порівняно з Solr.

• Пошук в реальному часі Райана Сонека : Solr vs Elasticsearch забезпечує глибокий аналіз / порівняння і пояснює, чому він перейшов з Solr в ElasticSeach, незважаючи на те, що він уже був щасливим користувачем Solr - він підсумовує це наступним чином:

  Solr може бути зброєю вибору при створенні стандартних пошукових програм , але Elasticsearch піднімає її на наступний рівень з архітектурою для створення сучасних додатків пошуку в режимі реального часу . Перколяція - це захоплююча та новаторська особливість, яка одноосібно продуває Солра прямо з води. Еластичний пошук є масштабним, швидким та мріє інтегруватися . Adios Solr, приємно було тебе знати. [акцент мій]

• У статті Вікіпедії про ElasticSearch цитується порівняння відомого німецького журналу iX, в якому перераховані переваги та недоліки, які в значній мірі узагальнюють сказане вище:

  Переваги :

  • ElasticSearch поширюється. Не потрібно окремого проекту. Репліки теж майже в режимі реального часу, що називається "Push repplication".
  • ElasticSearch повністю підтримує пошук в режимі реального часу Apache Lucene.
  • Поводження з багатосторонністю не є спеціальною конфігурацією, де для Solr необхідні більш вдосконалені налаштування.
  • ElasticSearch представляє концепцію шлюзу, що полегшує повне резервне копіювання.

  Недоліки :

  • Лише один головний розробник [більше не застосовується згідно з поточною організацією GitHub , але крім того, в першу чергу має досить активну базу даних]
  • Немає функції автоматичного утеплення [більше не застосовується відповідно до нового API Warmup API ]

Початковий відповідь

Це абсолютно різні технології, що стосуються абсолютно різних випадків використання, тому їх не можна порівняти взагалі жодним змістовно:

• Apache Solr - Apache Solr пропонує можливості Lucene у простому у користуванні, швидкому сервері пошуку з додатковими функціями, такими як облицювання, масштабованість та багато іншого

• Amazon ElastiCache - Amazon ElastiCache - це веб-сервіс, який дозволяє легко розгортати, керувати та масштабувати кеш пам'яті в хмарі.

  • Зверніть увагу, що Amazon ElastiCache відповідає протоколу Memcached, широко прийнятій системі кешування об'єктів пам’яті, тому код, додатки та популярні інструменти, якими ви користуєтесь сьогодні в існуючих середовищах Memcached, будуть безперебійно працювати з сервісом (детальніше див. Memcached ).

[акцент мій]

Можливо, це так чи інакше було переплутано з наступними двома пов'язаними технологіями:

• ElasticSearch - це відкритий код (Apache 2), розповсюджений, RESTful, пошуковий механізм, побудований на вершині Aceche Lucene.

• Amazon CloudSearch - Amazon CloudSearch - це повністю керована послуга пошуку у хмарі, яка дозволяє клієнтам легко інтегрувати швидкі та високомасштабні функції пошуку у свої програми.

Пропозиції Solr та ElasticSearch на перший погляд звучать разюче схоже, і обидва використовують одну і ту ж пошукову систему, а саме Apache Lucene .

Хоча Solr старший, досить універсальний і зрілий і відповідно використовується широко, ElasticSearch був розроблений спеціально для вирішення недоліків Solr із вимогами до масштабованості в сучасних хмарних середовищах, які важко (помилково) вирішити з Solr .

Як такий, можливо, було б найкорисніше порівняти ElasticSearch з нещодавно введеним Amazon CloudSearch (див. Вступний пост Початок пошуку за одну годину менше $ 100 / місяць ), оскільки обидва в принципі заявляють, що стосуються одних і тих же випадків використання.

Я бачу, що деякі з наведених відповідей зараз трохи застаріли. З моєї точки зору, і я щодня працюю з Solr (Cloud та non-Cloud) та ElasticSearch, ось кілька цікавих відмінностей:

• Спільнота: у Solr є більше, зріліші користувачі, розробники та спільноти користувачів. ES має меншу, але активну спільноту користувачів та зростаючу спільноту учасників
• Зрілість: Solr є більш зрілим, але ES швидко зростає, і я вважаю це стабільним
• Продуктивність: важко судити. Я / ми не зробили прямих орієнтирів ефективності. Людина в LinkedIn один раз порівнював Solr проти ES проти Sensei, але початкові результати слід ігнорувати, оскільки вони використовували неекспертне налаштування як для Solr, так і для ES.
• Дизайн: Люди люблять Solr. Java API є дещо багатослівним, але людям подобається, як він складається. На жаль, Solr-код не завжди дуже гарний. Крім того, ES має вбудовану різкості, реплікацію в режимі реального часу, документування та маршрутизацію. Хоча щось із цього існує і в Солрі, це трохи схоже на задум.
• Підтримка: Є компанії, які надають технічну та консалтингову підтримку як для Solr, так і для ElasticSearch. Я думаю, що єдиною компанією, яка надає підтримку обом, є Sematext (розкриття: Я засновник Sematext)
• Масштабованість: обидва можна масштабувати до дуже великих скупчень. ES легше масштабувати, ніж до Solr 4.0 версії Solr, але з Solr 4.0 це вже не так.

Для більш ретельного висвітлення теми Solr vs. ElasticSearch дивіться https://sematext.com/blog/solr-vs-elasticsearch-part-1-overview/ . Це перша публікація в серії публікацій Sematext, що робить пряме та нейтральне порівняння Solr з ElasticSearch. Розкриття інформації: Я працюю в Sematext.

Я бачу, що багато людей тут відповіли на це питання ElasticSearch vs Solr з точки зору особливостей та функціональності, але я не бачу багато дискусій тут (або в іншому місці) щодо того, як вони порівнюються за показниками продуктивності.

Саме тому я вирішив провести власне розслідування . Я взяв уже кодовану гетерогенну мікропослугу джерела даних, яка вже використовувала Solr для пошуку термінів. Я вимкнув Solr для ElasticSearch, тоді я запустив обидві версії на AWS з уже кодованим додатком для тестування навантаження та захопив показники продуктивності для подальшого аналізу.

Ось що я знайшов. ElasticSearch мав 13% вищу пропускну здатність, коли справа стосувалася індексації документів, але Солр був у десять разів швидшим. Якщо мова зайшла про запити документів, Солр мав п’ять разів більше пропускної здатності і був у п’ять разів швидшим, ніж ElasticSearch.

Оскільки довга історія Apache Solr, я думаю, що однією із сил Солра є його екосистема . Існує багато плагінів Solr для різних типів даних та цілей.

Шукайте платформу в наступних шарах знизу вгору:

• Дані
  • Призначення: представляти різні типи даних та джерела
• Будівництво документів
  • Призначення: побудувати інформацію про документ для індексації
• Індексація та пошук
  • Призначення: побудова та запит покажчика документа
• Вдосконалення логіки
  • Призначення: додаткова логіка для обробки пошукових запитів та результатів
• Сервіс пошуку платформи
  • Мета: Додайте додаткові функціональні можливості ядра пошукової системи для надання сервісної платформи.
• Застосування інтерфейсу користувача
  • Призначення: пошуковий інтерфейс або програми для кінцевих користувачів

Довідкова стаття: Пошук підприємств

Я створив таблицю основних розбіжностей між гумовим пошуком і Solr та спілком, ви можете використовувати його як оновлення 2016 року:

Я працюю як над solr, так і з еластичним пошуком програм .Net. Головна різниця, з чим я стикався, - це

Еластичний пошук:

• Більше коду та менша конфігурація, однак є можливість змінити api, але все-таки є зміна коду
• для складних типів введіть типи, тобто вкладені типи (не вдалося досягти в solr)

Solr:

• менше коду і більше конфігурації, а отже, менше обслуговування
• для групування результатів під час запитів (багато роботи, яку потрібно досягти в еластичному пошуку, коротко, не прямо)

Незважаючи на те, що всі вищезазначені посилання мають заслугу і приносили мені велику користь у минулому, як лінгвіст "піддався" дії різних люценових пошукових систем протягом останніх 15 років, я мушу сказати, що розвиток еластичного пошуку в Python дуже швидкий. Однак, частина коду для мене почувалася неінтуїтивно зрозумілою. Отже, я звернувся до одного компонента стека ELK, Kibana, з точки зору відкритого коду, і виявив, що в Кібані я можу створити дещо криптовалютний код еластичного пошуку. Також я можу перетягнути запити Chrome Sense es у Кібану. Якщо ви використовуєте Kibana для оцінки es, це ще більше прискорить вашу оцінку. На те, щоб запустити години на інших платформах, було запущено та запущено в JSON в Sense поверх еластичного пошуку (інтерфейс RESTful) у найгіршому випадку (найбільший набір даних); в кращому випадку в секундах Документація для еластичного пошуку, хоча 700 і більше сторінок, не відповідала на запитання, які, як правило, вирішувались у SOLR чи іншій луцькій документації, на що, очевидно, знадобилося більше часу для аналізу. Крім того, ви можете поглянути на Агрегати в еластичному пошуку, які вивели Faceting на новий рівень.

Більша картина: якщо ви займаєтесь інформацією про дані, аналітикою тексту чи обчислювальною лінгвістикою, то в еластичному дослідженні є кілька алгоритмів ранжування, які, схоже, добре впроваджують інновації в області пошуку інформації. Якщо ви використовуєте будь-які алгоритми TF / IDF, частоту тексту / зворотну частоту документа, еластичне дослідження поглибить алгоритм цього 1960 року на новий рівень, навіть використовуючи алгоритми BM25, Best Match 25 та інші алгоритми релевантності. Отже, якщо ви оцінюєте або класифікуєте слова, фрази чи пропозиції, еластичний пошук робить це підрахунком на ходу, без великих витрат інших підходів до аналізу даних, які займають години - ще одна еластична економія часу. Завдяки es, поєднуючи деякі переваги збору в результаті агрегації з оцінкою рейтингу релевантності даних JSON в реальному часі, ви можете знайти виграшну комбінацію,

Примітка: чи бачили подібну дискусію щодо агрегацій вище, але не про підсумовування агрегацій та відповідності - мої вибачення за будь-яке перекриття. Розкриття: Я не працюю на еластичні і не зможу отримати вигоду в найближчому майбутньому від їх чудової роботи через інший архітектурний шлях, якщо тільки я не проведу якусь благодійну роботу з еластичним пошуком, що не буде поганою ідеєю

Уявіть випадок використання:

1. Багато (100+) невеликих (10Mb-100Mb, 1000-100000 документів) пошукових індексів.
2. Вони використовуються безліччю додатків (мікросервісів)
3. Кожна програма може використовувати більше одного індексу
4. Малий за розміром індекс, так. Але величезне навантаження (сотні пошукових запитів в секунду) і запитів є складними (кілька агрегацій, умови тощо)
5. Час простою не допускається
6. Все це працює років і постійно зростає.

Ідея мати індивідуальний екземпляр ES для кожного індексу - це величезні витрати в цьому випадку.

Виходячи з мого досвіду, такий варіант використання є дуже складним для підтримки з Elasticsearch.

Чому?

СПОЧАТКУ.

Головною проблемою є фундаментальне нехтування сумісністю.

Порушення змін настільки круто! (Примітка: уявіть собі SQL-сервер, який вимагає, щоб ви зробили невеликі зміни у всіх своїх SQL-операторах, коли оновлено ... не уявляю цього. Але для ES це нормально)

Позбавлення, які випадуть у наступному великому випуску, такі сексуальні! (Примітка. Ви знаєте, що Java містить деякі застарілі терміни, яким вже 20 років, але вони все ще працюють у фактичній версії Java ...)

І не тільки це, іноді у вас навіть є щось, що ніде не зафіксовано (особисто я натрапив лише один раз, але ...)

Тому. Якщо ви хочете оновити ES (оскільки вам потрібні нові функції для якогось додатка або ви хочете отримати виправлення помилок) - ви в пеклі. Особливо, якщо мова йде про основне оновлення версії.

API клієнта не підтримуватиме сумісність. Налаштування індексу не підтримуватимуть сумісність. І оновити всі додатки / послуги в той самий момент із оновленням ES не реально.

Але потрібно це робити час від часу. Іншого шляху немає.

Існуючі індекси автоматично оновлюються? - Так. Але це не допоможе вам, коли вам потрібно буде змінити деякі налаштування старих індексів.

Щоб жити з цим, вам потрібно постійно вкладати багато сил у ... сумісність ваших додатків / служб з майбутніми випусками ES. Або вам потрібно створити (і в будь-якому разі постійно підтримувати) якийсь проміжне програмне забезпечення між вашим додатком / послугами та ES, яке надає вам сумісний API клієнта. (І ви не можете скористатися транспортним клієнтом (оскільки для нього потрібне оновлення jar для кожної незначної версії ES-оновлення), і цей факт не полегшує ваше життя)

Це виглядає просто і дешево? Ні це не так. Далеко від цього. Постійне обслуговування складної інфраструктури, яка базується на ES, є дорогим у всіх можливих сенсах.

ДРУГИЙ. Простий API? Ну ... насправді. Коли ви справді використовуєте складні умови та агрегації .... JSON-запит з 5 вкладеними рівнями є будь-яким, але не простим.

На жаль, я не маю досвіду роботи з SOLR, не можу нічого про це сказати.

Але Sphinxsearch набагато кращий за цим сценарієм, оскільки повністю підтримує сумісний SphinxQL.

Примітка: Сфінкс-дослідження / Мантікореві справді цікаві. Це не на Lucine, і як результат серйозно відрізняється. Містить декілька унікальних функцій у вікні, яких немає у ES, і швидко божевільний з невеликими / середніми розмірами.

Якщо ви вже використовуєте SOLR, залишайтеся дотримуватися цього. Якщо ви починаєте, перейдіть на пошук Еластичний.

Максимально основні проблеми були зафіксовані в SOLR, і він досить зрілий.

Я використовую Elasticsearch протягом 3 років, а Solr - близько місяця, я вважаю, що кластер еластичного пошуку досить простий в монтажі порівняно з установкою Solr. Elasticsearch має пул довідкових документів з великим поясненням. Одним із випадків використання я був зав'язаний з агрегуванням гістограми, яке було доступне в ES, однак не знайдено в Solr.

Я використовую лише Elastic-search. Оскільки я знайшов соль, то почати дуже важко. Особливості еластичного пошуку:

1. Легкий запуск, дуже мало налаштувань. Навіть новачок може налаштувати кластер крок за кроком.
2. Простий API відпочинку, який використовує запит NoSQL. І багато мовних бібліотек для легкого доступу.
3. Хороший документ, ви можете прочитати книгу:. На офіційному веб-сайті є веб-версія.

Додайте вкладений документ у solr дуже складний, а пошук вкладених даних також дуже складний. але Еластичний пошук легко додавати вкладений документ та пошук