Недавно команда проекта поставила задачу.В проекте используется полнотекстовый поиск и Solr на основе полнотекстового поиска.Однако облачный проект Solr search нестабилен,данные нельзя запрашивать часто.Нужно полностью синхронизировать вручную , и он поддерживается другими командами, и зависимости слишком высоки.Сильно, как только сервис Solr дает сбой, наш проект в основном парализован, потому что все зависимые запросы не имеют данных о результатах. Поэтому рассмотрите возможность разработки уровня адаптации, который автоматически переключается на новый поиск — ES, если поиск Solr идет не так, как надо.

На самом деле эту проблему можно решить за счет проектирования Solr-кластера или сервисной отказоустойчивости. Но без учета рациональности собственного замысла лидеру нужно развиваться, поэтому я начал вставать на путь построения ES-сервисов, начиная с нуля, так как раньше никогда не сталкивался с ES, поэтому использую эту серию для записи мой собственный процесс разработки.

Что такое полнотекстовый поиск

Что такое полнотекстовый поиск?

Определение в энциклопедии Baidu: Полнотекстовые поисковые системы в настоящее время широко используются в основных поисковых системах. Принцип ее работы заключается в том, что компьютерная программа индексирования создает индекс для каждого слова, сканируя каждое слово в статье, указывая номер и позицию слова в статье.Когда пользователь запрашивает, программа поиска будет основываться на предварительно установленный индекс Поиск и возврат результатов поиска в метод поиска пользователя. Этот процесс аналогичен процессу поиска слов в списке поисковых слов в словаре.

Из определения мы уже можем примерно понять идею полнотекстового поиска, Для более подробного объяснения начнем с данных в жизни.

Данные в нашей жизни обычно делятся на две категории:структурированные данныеинеструктурированные данные.

структурированные данные: Относится к данным фиксированного формата или ограниченной длины, таким как базы данных, метаданные и т. д.
неструктурированные данные: неструктурированные данные также могут называться полнотекстовыми данными, которые относятся к данным неопределенной длины или без фиксированного формата, таким как электронные письма, текстовые документы и т. д.

Конечно, местами будет и третий тип:полуструктурированные данные, такие как XML, HTML и т. д., при необходимости их можно обрабатывать как структурированные данные, а обычный текст также можно извлекать и обрабатывать как неструктурированные данные.

В соответствии с двумя классификациями данных поиск соответственно делится на два типа: поиск по структурированным данным и поиск по неструктурированным данным.

Для структурированных данных мы обычно можем хранить и искать в таблице реляционных баз данных (mysql, oracle и т. д.), а также можем создавать индексы. Для неструктурированных данных, то есть поиска полнотекстовых данных, есть два основных метода:метод последовательного сканирования,Полнотекстовый поиск.

Последовательное сканирование: Вы также можете узнать об общем методе поиска через текстовое имя, то есть запрашивать определенные ключевые слова в последовательном сканировании. Например, дайте вам газету и позвольте вам найти, где в газете появляются слова «ГСЧ». Обязательно нужно отсканировать газету от корки до корки и отметить, где встречается ключевое слово и где оно встречается.

Этот способ, несомненно, самый трудоемкий и наименее эффективный.Если набор газеты небольшой, а разделов много или даже несколько газет, то после сканирования глаз будет почти то же самое.

исследовать все: Последовательное сканирование неструктурированных данных работает медленно, можем ли мы его оптимизировать? Разве мы не можем просто найти способ сделать наши неструктурированные данные определенной структурой? Извлеките часть информации из неструктурированных данных, реорганизуйте их, чтобы они имели определенную структуру, а затем выполните поиск данных с определенной структурой, чтобы достичь цели относительно быстрого поиска. Этот метод составляет основную идею полнотекстового поиска. Эту часть информации, извлеченную из неструктурированных данных и затем реорганизованную, мы называемпоказатель.

Взяв за пример чтение газет, мы хотим обратить внимание на новости о недавнем глобальном финале League of Legends S8.Если мы все фанаты ГСЧ, как нам быстро найти газеты и разделы новостей ГСЧ? Метод полнотекстового поиска заключается в извлечении ключевых слов из всех разделов всех газет, таких как «EDG», «RNG», «FW», «Команда», «League of Legends» и т. д. Затем проиндексируйте эти ключевые слова, и с помощью индексации мы сможем соответствовать газетам и разделам, в которых появляются ключевые слова. Обратите внимание на разницуПоисковая система каталога.

Зачем использовать полнотекстовый поиск

Раньше коллега спрашивал меня, зачем пользоваться поисковиком? Все наши данные находятся в базе данных, а Oracle, SQL Server и другие базы данных также могут предоставлять функции извлечения запросов или кластерного анализа.Разве мы не можем делать запросы непосредственно через базу данных? Действительно, большинство наших функций запросов можно получить через запросы к базе данных.Если эффективность запросов низкая, мы также можем повысить эффективность, построив индексы базы данных, оптимизировав SQL и т. д., и даже ускорив возврат данных, внедрив кэширование. Если объем данных больше, вы можете разделить базу данных и таблицу, чтобы разделить давление запросов.

Так зачем возиться с полнотекстовой поисковой системой? В основном мы анализируем следующие причины:

тип данныхПолнотекстовый индексный поиск поддерживает поиск в неструктурированных данных, что позволяет лучше и быстрее искать в неструктурированном тексте любое слово или группу слов, существующих в больших количествах. Например, поиск Google, Baidu и других веб-сайтов, все они генерируют индексы на основе ключевых слов на веб-страницах.Когда мы вводим ключевые слова при поиске, они возвращают все страницы, соответствующие ключевому слову, то есть индекс, есть также общие элементы Поиск в логах приложений и т.д. Для этих неструктурированных текстов данных поиск в реляционной базе данных плохо поддерживается.
обслуживание индексаВ общем, традиционные базы данных и полнотекстовый поиск очень безвкусны, потому что обычно никто не использует текстовые поля инвентаризации данных. Полнотекстовый поиск должен сканировать всю таблицу, если объем данных большой, даже если синтаксис SQL оптимизирован, это мало что даст. Индекс установлен, но его также очень сложно поддерживать, и индекс будет перестроен как для операций вставки, так и для операций обновления.

Когда использовать полнотекстовый поиск:

Искомый объект данных представляет собой большой объем неструктурированных текстовых данных.
Файловые записи исчисляются сотнями тысяч, миллионами и более.
Поддерживает большое количество интерактивных текстовых запросов.
Полнотекстовые поисковые запросы с очень гибкими требованиями.
Существует особая потребность в очень релевантных результатах поиска, которой не может удовлетворить ни одна доступная реляционная база данных.
Потребность в различных типах записей, манипулировании нетекстовыми данными или безопасной обработке транзакций возникает относительно редко.

Lucene, Solr, ElasticSearch?

Сейчас основными поисковыми системами, вероятно, являются: Lucene, Solr, ElasticSearch.

Их индексация основана наПеревернутый индексКак сгенерировать индекс, что такое инвертированный индекс?

Википедия Инвертированный индекс (англ. Inverted index), также часто называемый инвертированным индексом, файлом ввода или обратным файлом, представляет собой метод индексации, используемый для хранения слова в документе или группы карт мест хранения в документе. Это наиболее часто используемая структура данных в системах поиска документов.

Lucene

Lucene — полнотекстовая поисковая система Java, полностью написанная на Java. Lucene — это не законченное приложение, а кодовая база и API, которые можно легко использовать для добавления в приложение функции поиска.

Lucene предоставляет мощную функциональность через простой API:

Масштабируемое, высокопроизводительное индексирование

Более 150 ГБ/час на современном оборудовании
Небольшое требование к оперативной памяти - всего 1 МБ кучи
Инкрементальное индексирование выполняется так же быстро, как массовое индексирование.
Размер указателя составляет около 20-30% от размера текста указателя.

Мощный, точный и эффективный алгоритм поиска

Ранжированный поиск — сначала выдает лучшие результаты
Множество мощных типов запросов: фразовые запросы, запросы с подстановочными знаками, запросы близости, запросы диапазона и т. д.
Поиск по сайту (например, по названию, автору, содержанию)
Сортировать по любому полю
Многоиндексный поиск с объединенными результатами
Разрешить одновременное обновление и поиск
Гибкое фасетирование, выделение, объединение и группировка результатов
Быстрые, эффективные с точки зрения использования памяти и устойчивые к ошибкам советы
Подключаемые модели ранжирования, включая модели векторного пространства и Okapi BM25.
Настраиваемый механизм хранения (кодек)

Кроссплатформенные решения

Доступно как программное обеспечение с открытым исходным кодом по лицензии Apache, что позволяет использовать Lucene в коммерческих программах и программах с открытым исходным кодом.
100% - чистая Java
Доступные реализации на других языках программирования совместимы с индексами

Фонд программного обеспечения ApacheApache Software Foundation предоставляет проекты программного обеспечения с открытым исходным кодом при поддержке сообщества Apache.

Но Lucene — это всего лишь фреймворк, чтобы в полной мере воспользоваться его функциями, нужно использовать JAVA и интегрировать Lucene в программу. Чтобы понять, как это работает, нужно много учиться, а овладеть Lucene действительно сложно.

Solr

Apache Solr — это поисковая платформа с открытым исходным кодом, построенная на библиотеке Java под названием Lucene. Он предоставляет функции поиска Apache Lucene в удобной для пользователя форме. Как отраслевой игрок на протяжении почти десяти лет, это зрелый продукт с сильным и широким сообществом пользователей. Он обеспечивает распределенное индексирование, репликацию, запросы балансировки нагрузки, а также автоматический переход на другой ресурс и восстановление. Если она правильно развернута и хорошо управляется, она может быть очень надежной, масштабируемой и отказоустойчивой поисковой системой. Многие интернет-гиганты, такие как Netflix, eBay, Instagram и Amazon (CloudSearch), используют Solr из-за его способности индексировать и искать несколько сайтов.

В список ключевых особенностей входят:

исследовать все
высовываться
Фасетный поиск
индекс в реальном времени
Динамический кластер
Интеграция с базой данных
Возможности NoSQL и расширенная обработка документов (например, файлы Word и PDF)

ElasticSearch

Elasticsearch — это поисковая система с открытым исходным кодом (лицензия Apache 2) и RESTful, построенная на основе библиотеки Apache Lucene.

Elasticsearch был запущен через несколько лет после Solr. Он предоставляет распределенную, многопользовательскую полнотекстовую поисковую систему с веб-интерфейсом HTTP (REST) и документами JSON без схемы. Официальная клиентская библиотека для Elasticsearch доступна на Java, Groovy, PHP, Ruby, Perl, Python, .NET и Javascript.

Распределенная поисковая система включает в себя индекс, который можно разделить на сегменты, и каждый сегмент может иметь несколько реплик. Каждый узел Elasticsearch может иметь один или несколько сегментов, а его движок также может действовать как координатор, делегируя операции правильному сегменту.

Elasticsearch масштабируется с поиском почти в реальном времени. Одной из его основных особенностей является мультиарендность.

В список ключевых особенностей входят:

распределенный поиск
мульти аренды
Аналитический поиск
Группировка и агрегация

Выбор Elasticsearch против Solr

Из-за сложности Lucene его редко рассматривают как лучший выбор для поиска, за исключением некоторых компаний, которым необходимо разработать собственную структуру поиска, а нижний уровень должен полагаться на Lucene. Итак, здесь мы сосредоточимся на Elasticsearch и Solr.

Elasticsearch против Solr. Какой лучше? Насколько они разные? Какой из них вы должны использовать?

историческое сравнение

Apache Solr — это зрелый проект с большим и активным сообществом разработчиков и пользователей, а также с брендом Apache. Solr, впервые выпущенный с открытым исходным кодом в 2006 году, долгое время доминировал в пространстве поисковых систем и является предпочтительным механизмом для всех, кому нужны функции поиска. Его зрелость выражается в богатой функциональности, выходящей за рамки простого текстового индексирования и поиска, таких как фасетирование, группировка, мощная фильтрация, подключаемая обработка документов, подключаемые компоненты цепочки поиска, определение языка и т. д.

Solr уже много лет доминирует в поисковом пространстве. Затем, примерно в 2010 году, Elasticsearch стал еще одним вариантом на рынке. В то время он был далеко не так стабилен, как Solr, без функциональной глубины Solr, без обмена идеями, брендинга и т. д.

Elasticsearch, хотя и молодой, имеет свои собственные преимущества. Elasticsearch построен на более современных принципах, нацелен на более современные варианты использования и создан для более легкой обработки больших индексов и высокой скорости запросов. Кроме того, поскольку сообщество слишком молодо, чтобы сотрудничать с ним, можно свободно двигаться вперед без какого-либо консенсуса или сотрудничества с другими (пользователями или разработчиками), обычно приходится иметь дело с обратной совместимостью или любым другим более зрелым программным обеспечением.

Таким образом, он представил некоторые очень популярные функции (например, поиск почти в реальном времени, по-английски: поиск почти в реальном времени) задолго до Solr. Технически мощь поиска NRT исходит от Lucene, базовой библиотеки поиска, используемой Solr и Elasticsearch. По иронии судьбы, люди связывают поиск NRT с Elasticsearch, потому что Elasticsearch впервые представил поиск NRT, хотя и Solr, и Lucene являются частью одного и того же проекта Apache, поэтому можно было бы ожидать, что Solr будет настолько требовательным в первую очередь к функциям.

Сравнение различий функций

Обе эти поисковые системы являются популярными продвинутыми поисковыми системами с открытым исходным кодом. Оба они построены на базе основной библиотеки поиска — Lucene, но они разные. Как и все, у каждого есть свои плюсы и минусы, и каждый может быть лучше или хуже в зависимости от ваших потребностей и ожиданий. И Solr, и Elasticsearch быстро развиваются, поэтому, без лишних слов, вот список их отличий:

особенность	Solr/SolrCloud	Elasticsearch
Сообщество и разработчики	Apache Software Foundation и поддержка сообщества	Единый хозяйствующий субъект и его работники
Обнаружение узла	Apache Zookeeper, зрелый и проверенный в многочисленных проектах	Zen встроен в сам Elasticsearch и требует выделенного главного узла для защиты от разделения мозгов.
Размещение фрагмента	Статичны по своей природе, требуют ручной работы для переноса сегментов, поскольку Solr 7 — Autoscaling API позволяет выполнять некоторые динамические операции.	Динамический, сегменты можно перемещать по требованию в зависимости от состояния кластера.
тайник	Глобально, каждое изменение сегмента не влияет	за абзац, больше подходит для динамически изменяющихся данных
Анализировать работу двигателя	Статические данные идеально подходят для точных расчетов	Точность результатов зависит от размещения данных
Функция полнотекстового поиска	Анализ языка на основе Lucene, несколько предложений, проверка орфографии, богатая поддержка подсветки	Анализ языка на основе Lucene, реализация API с одним предложением, выделение пересчета
Поддержка DevOps	Еще не совсем, но скоро	очень хороший API
непланарная обработка данных	Вложенные документы и поддержка родитель-потомок	Естественная поддержка вложенности и типов объектов обеспечивает практически неограниченную вложенность и поддержку родитель-потомок.
Запрос DSL	JSON (ограничено), XML (ограничено) или параметры URL	JSON
Управление индексацией/сбором выноски	Контроль размещения лидеров и перебалансировка лидеров могут загружаться даже на узлы	невозможно
машинное обучение	Встроенный — поверх агрегации потоков, с упором на логистическую регрессию и обучение ранжированию модулей вклада	Коммерческие функции с упором на выбросы и выбросы и данные временных рядов

Узнайте больше здесь.

Всестороннее сравнение

Кроме того, мы анализируем со следующих аспектов:

Тенденции последних лет Давайте посмотрим на тенденции поиска Google для обоих продуктов. Google Trends показывает, что Elasticsearch имеет большую популярность по сравнению с Solr, но это не означает, что Apache Solr мертв. Хотя некоторые могут так не думать, Solr по-прежнему остается одной из самых популярных поисковых систем с сильным сообществом и поддержкой открытого исходного кода.

Установить и настроить По сравнению с Solr, Elasticsearch прост в установке и очень легкий. Кроме того, вы можете установить и запустить Elasticsearch за считанные минуты. Однако эта простота развертывания и использования может стать проблемой, если Elasticsearch не управляется должным образом. Конфигурация на основе JSON проста, но если вы хотите указать комментарий для каждой конфигурации в файле, то это не для вас. В целом, если ваше приложение использует JSON, Elasticsearch — лучший выбор. В противном случае используйте Solr, так как его файлы schema.xml и solrconfig.xml хорошо документированы.
Сообщество У Solr более обширное и зрелое сообщество пользователей, разработчиков и участников. ES имеет небольшое, но активное сообщество пользователей и растущее сообщество участников. Solr — это действительно открытый исходный код сообщества. Любой может внести свой вклад в Solr, и новые разработчики Solr (также называемые коммиттерами) избираются по заслугам. Elasticsearch технически является открытым исходным кодом, но не столько духовно. Любой может видеть исходный код, любой может изменить его и внести свой вклад, но только сотрудники Elasticsearch могут вносить изменения в Elasticsearch. Участники и коммиттеры Solr представляют множество разных организаций, а коммиттеры Elasticsearch — представители одной компании.
зрелость Solr более зрелый, но ES быстро растет, и я думаю, что он стабилен.
Документация Solr набирает здесь высокие баллы. Это очень хорошо документированный продукт с четкими примерами и сценариями использования API. Документация Elasticsearch хорошо организована, но в ней отсутствуют хорошие примеры и четкие инструкции по настройке.

Суммировать

Итак, Solr или Elasticsearch? Иногда трудно найти четкий ответ. Независимо от того, выберете ли вы Solr или Elasticsearch, вам сначала нужно понять правильный вариант использования и будущие требования. Обобщите каждое из их свойств.

Помните:

Elasticsearch более популярен среди новых разработчиков из-за простоты использования. Однако, если вы привыкли работать с Solr, используйте его, так как особых преимуществ перехода на Elasticsearch нет.
Если вам нужно обрабатывать аналитические запросы в дополнение к поиску текста, Elasticsearch — лучший выбор.
Если вам нужно распределенное индексирование, вам нужно выбрать Elasticsearch. Elasticsearch — лучший выбор для облачных и распределенных сред, требующих хорошей масштабируемости и производительности.
Оба имеют хорошую коммерческую поддержку (консультации, поддержка производства, интеграция и т. д.)
У обоих есть отличные операционные инструменты, хотя Elasticsearch больше нравится толпе DevOps из-за его простого в использовании API, поэтому вокруг него может быть создана более динамичная экосистема инструментов.
Elasticsearch доминирует в случае управления журналами с открытым исходным кодом, и многие организации индексируют свои журналы в Elasticsearch, чтобы сделать их доступными для поиска. Хотя Solr теперь также можно использовать для этой цели, он просто упускает из виду эту идею.
Solr все же больше ориентирован на текстовый поиск. Elasticsearch, с другой стороны, часто используется для фильтрации и группировки — рабочих нагрузок аналитических запросов — и не обязательно для текстового поиска. Разработчики Elasticsearch приложили много усилий, чтобы сделать такие запросы более эффективными (меньший объем памяти и использование ЦП) на уровне Lucene и Elasticsearch. Таким образом, Elasticsearch — лучший выбор для приложений, которым требуется не только текстовый поиск, но и сложная агрегация времени поиска.
С Elasticsearch проще начать работу, одна загрузка и одна команда для запуска всего. Solr традиционно требовал больше работы и знаний, но недавно Solr добился огромных успехов в устранении этого, и теперь ему просто нужно работать над изменением своей репутации.
По производительности они примерно одинаковые. Я говорю «примерно», потому что никто не проводил всеобъемлющего и беспристрастного теста. Для 95% вариантов использования любой вариант будет хорош с точки зрения производительности, для оставшихся 5% необходимо протестировать оба решения со своими специфическими данными и специфическими шаблонами доступа.
С точки зрения эксплуатации Elasticsearch относительно прост в использовании — у него всего один процесс. Solr использует Apache ZooKeeper в своей модели полностью распределенного развертывания SolrCloud, похожей на Elasticsearch. ZooKeeper очень развит, широко используется и т. д., но это еще одна активная часть. Тем не менее, если вы используете Hadoop, HBase, Spark, Kafka или какое-либо другое новое распределенное программное обеспечение, возможно, ZooKeeper уже запущен где-то в вашей организации.
В то время как Elasticsearch имеет компонент, подобный ZooKeeper, встроенный в Xen, ZooKeeper лучше предотвращает страшную проблему разделения мозгов, которая иногда возникает в кластерах Elasticsearch. Честно говоря, разработчики Elasticsearch знают об этой проблеме и работают над улучшением этого аспекта Elasticsearch.
Если вы любите мониторинг и метрики, то с Elasticsearch вы будете на небесах. У этой штуки больше показателей, чем кто-либо может втиснуть на Таймс-сквер в канун Нового года! Solr предоставляет ключевые показатели, но не так много, как Elasticsearch.

В заключение, обе являются многофункциональными поисковыми системами, которые при правильном проектировании и реализации обеспечивают более или менее одинаковую производительность. Общее содержание этой статьи примерно таково, картинка сделана садовникомReyCGТщательно нарисовано и предоставлено.

Ссылаться на:

Woohoo. Разговор о Ami.com/2015/01/22/…
blog.CSDN.net/хороший смех0626/art…
www.elastic.co/cn/
В log.IO/blog/so hunter-V…
Сема text.com/blog/so hunter-v…

Личный общедоступный номер: JaJian

Добро пожаловать, нажмите и удерживайте изображение, чтобы подписаться на общедоступный номер: JaJian!

Регулярно предоставлять вам пояснения и анализ связанных технологий первоклассных интернет-компаний, таких как распределенные и микросервисы.