> Это что, секта Свидетелей Поха? Не зашкварно одного из самых ноющих желчегонных кадров всея опеннета выгораживать? Ну и стыдоба.С одной стороны, а какая вообще разница КТО говорит, если человек говорит правильные вещи? https://en.wikipedia.org/wiki/Ad_hominem
С другой стороны, я стараюсь толерантно относиться к местным в надежде, что там не всё потеряно, но даже меня иногда зло берет от непроходимой невежественности, грубости и заносчивости некоторых комментаторов.
Своими оскорблениями и неудовлетворенным желанием продемонстрировать чувство собственного превосходства, ты мало отличаешься от любого другого "желчегонного кадра всея опеннет" и вот несмотря на это тебе, пытаются объяснить, что гвоздить нужно забивать молотком, а дрель она чтобы делать дырки. Я просто научился игнорировать местные манеры, можете продолжать хамить друг другу, но я в этой конкретной ситуации на стороне поха, потому что он просто чисто технически прав, а ты нет.
> требовал Zookeeper для кластера
А в чем собственно проблема Apache Zookeeper? Для подобных сервисов вам нужен централизированный сервис координации распределенных транзакций. Особенно, когда дело касается развертывания геораспределенного гиперкластерного развертывания со сложной цепочкой репликации и восстановления после сбоя (облачный сценарий). И что же по вашему использует Elastic Cloud решения для такой координации? Вы мне возможно не поверите, но это Apache Zookeeper в связке с Apache Curator.
Да, Elasticsearch не требует Zookeeper для малого развертывания. Для большого без него нельзя. При этом в связке с Elasticsearh Zookeeper не примет на себя ни очереди, ни распределенную файловую систему, но используется для всего остального.
> имел единый кэш для всего шарда, а не сегмента. Не знаю, как там сейчас.
Да, имел, имеет и будет иметь, потому что в этом и есть ключевое отличие Elastic от Solr. Именно поэтому я и пишу, что вы используете неправильный инструмент для работы. Solr - статическая система, которая проектируется под статические данные. А ваша номенклатура - это статика. Она не расширяется по 100 записей в секунду, а лишь изредка изменяется, когда карточки редактируют, через то приложение, в которых их у вас редактируют. Единственное чему Solr научился - автоскейлингу при добавлению ноды, и в свежих версиях снизил порог вхождения, стал более дружественной к начинающим, к девопсам, и прочим низкоквалифицированным кадрам.
Вся суть в том, что Shard-ы Solr находятся в ваших руках, вы формируете _схему_ коллекции, а сегменты Lucene находятся под ними и вы от них абстрагированы. В Elastic с точностью до наоборот. И это не хорошо и не плохо. Это тюнинг архитектуры на базе Lucene под 2 разные задачи:
- Solr - работа с НСИ
- Elastic - работа с логами
Elastic и Solr не конкуренты, потому что используются для разных вещей и построены на базе одной и той же библиотеки. Они дополняют друг друга.
> тут уже разрабов с каким бэкграундом будет проще и быстрее схантить, на том и будет
Если нет башковитого архитектора, то обычно такие вещи отдают специализированному подрядчику, потому что косорылым баранам, пихающим везде где не надо Elastic, которых надо еще и нянчить по ТК без должной мат. ответственности с их стороны, нельзя доверить проектирование архитектуры полнотекстового поиска. Они безответственные и неграмотные, они не разбираются в нюансах Lucene и её аналогичных решений для поиска. Есть риск что номенклатуру засунут в NoSQL, тогда как ей место в RDBMS, и неучи даже не знают почему так. Максимум что от них требуется - вызывать веб сервисы, которые для них заботливо сделали и настроили умные дяденьки.
