jesterj
1.0.0
Очень гибкая, масштабируемая, отказоустойчивая система приема документов, предназначенная для поиска.
Сборки выполняются на инфраструктуре, любезно предоставленной
Часто проекты поиска начинаются с ручной подачи нескольких документов в поисковую систему, часто с помощью «только для тестирования», встроенных в Solr функций обработки, таких как SolrCell или post.jar. Эти функции задокументированы и включены, чтобы помочь пользователю понять, что он может делать с Solr с минимальной трудоемкой настройкой.
Это хорошо, и так должно быть при первых исследованиях. К сожалению, это также потенциальная ловушка.
Слишком часто пользователи, которые не знают ничего лучшего и, возможно, введены в заблуждение тем фактом, что эти интерфейсы задокументированы в справочном руководстве (и предполагают, что все задокументированное должно быть «правильным» способом) продолжают развивать свою поисковую систему. путем автоматизации использования тех же интерфейсов. Справедливости ради стоит отметить, что некоторые старые версии руководства Solr Ref не смогли определить характер интерфейса «только для тестирования», иногда потому, что сообществу требовалось время, чтобы осознать связанные с ним подводные камни.
К сожалению, крупномасштабный прием документов для поиска является нетривиальной задачей, и эти интерфейсы индексирования не предназначены для производственного использования. Обычно в результате он работает «нормально» для небольшого тестового корпуса, а затем становится нестабильным в более крупном производственном корпусе. Код, написанный для таких интерфейсов, часто необходимо повторять для нескольких типов документов или для различных форматов документов, что может легко привести к дублированию и копированию общих функций. Кроме того, после значительных инвестиций в разработку, чтобы заставить такие решения работать на большом массиве данных, следующее, что они обнаружили, — это то, что у них нет возможности восстановиться, если индексирование завершится неудачно. В худших случаях сбой связан с размером корпуса, и сбои становятся все более распространенными по мере роста корпуса до тех пор, пока вероятность завершения и запуска индексации не станет малой, и система в конечном итоге вообще не сможет быть проиндексирована или обновлена, если проблема разрешена. гноиться. Результатом является ужасная, болезненная и потенциально дорогостоящая проблема роста.
JesterJ стремится облегчить начало работы с помощью надежной полнофункциональной инфраструктуры индексирования, чтобы вам не приходилось изобретать велосипед заново. JesterJ задуман как система, от которой вам не придется отказываться, пока вы не начнете работать с чрезвычайно большим количеством документов (и, будем надеяться, к этому моменту вы уже получаете хорошую прибыль, которая может окупить большое индивидуальное решение!). Предоставляются различные повторно используемые компоненты обработки, а написать свои собственные процессоры так же просто, как реализовать интерфейс из 4 методов, следуя некоторым простым рекомендациям.
Часто первая версия системы индексации документов в Solr или другой поисковой системе довольно линейна и понятна, но с течением времени функции и улучшения часто усложняют систему. В других случаях система сложна с самого начала, возможно, потому, что поиск добавляется к существующей системе. JesterJ предназначен для обработки сложных сценариев индексирования. Рассмотрим следующий гипотетический рабочий процесс индексирования:
JesterJ обрабатывает такие сценарии с помощью единого централизованного плана обработки и гарантирует, что в случае отключения системы вы не получите второго сообщения о полученном заказе. Режим по умолчанию для JesterJ обеспечивает не более одного раза доставку шагов, которые не помечены как безопасные или идемпотентные. Безопасные шаги не имеют внешних эффектов, а идемпотентные шаги могут повторяться по пути к конечной точке обработки.
Дополнительную информацию см. на веб-сайте и в документации.
Пожалуйста, ознакомьтесь с документацией в вики.
Текущая версия : 1.0-Beta3. Это лучшая версия для использования, и она должна быть в основном функциональной. (известная проблема: № 189)
Следующий выпуск: 1.0-Beta4 будет опубликована в ближайшее время, если не будет обнаружено серьезных проблем, в течение двух недель. Будет выпущена версия 1.0.
ПРИМЕЧАНИЕ. Текущий код и предстоящая версия 1.0 предназначены для любой конструкции и нагрузки, которые могут обслуживаться одной машиной. JesterJ специально разработан для использования машин с множеством процессоров. Вы можете разработать свой план, используя дубликаты самого медленного шага, чтобы устранить узкие места. Каждый дубликат подразумевает дополнительный поток, работающий на этом этапе. Автоматическое масштабирование потоков запланировано в версии 1.1, а масштабирование на многих машинах является ключевым приоритетом для версий 2.x. Как всегда, если вы хотите получить эти функции раньше, начните обсуждение и, если можете, поделитесь своим мнением!
В настоящее время регулярно тестируется только JDK 11. Любой дистрибутив JDK 11 должен работать. Поддержка Java 17 и будущих версий LTS запланирована в будущих выпусках.
Обсуждайте функции, задавайте вопросы и т. д. в Discord: https://discord.gg/RmdTYvpXr9
В этом выпуске у нас есть следующие функции
~/.jj/cassandraВерсия 1.0 предназначена для использования в одноузловых системах и, следовательно, пригодна для использования в проектах малого и среднего размера (десятки миллионов или, возможно, несколько сотен миллионов документов).
Лучшее предположение о том, что будет в будущих выпусках, можно получить с помощью фильтров этапов на нашей странице проблем.
