«Грамотность» Elasticsearch

предисловие

Только лысая голова может стать сильнее.

Текст был включен в мою избранную статью на GitHub, Welcome Star:GitHub.com/Zhongf UC очень…

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

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

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

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

Elasticsearch is a real-time, distributed storage, search, and analytics engine

Elasticsearch — этов реальном времениизРаспределенное хранение, поиск, анализдвигатель.

Во введении есть несколько ключевых слов:

• в реальном времени
• распределенный
• поиск
• анализировать

Итак, мы должны знать, как работает Elasticsearch в реальном времени и какова архитектура Elasticsearch (распределенного). Хранение, поиск и анализ (вам нужно знать, как Elasticsearch хранит, ищет и анализирует)

Эти вопросы будут рассмотрены в данной статье.

Я написал более 200 оригинальных технических статей, и в будущем я напишу еще больше.Большие данныеДля связанных статей, если вы хотите прочитать другие мои статьи, пожалуйста, следуйте за мной.Общедоступный номер: Java3y

Если вы считаете, что моя статья хороша и полезна для вас,Не скупитесь на похвалу!

Зачем использовать Elasticsearch

Прежде чем изучать технологию, вы должны сначала понять, почему она используется. Итак, зачем использовать Elasticsearch? В нашем ежедневном развитиибаза данныхЭто тоже можно (в режиме реального времени, хранение, поиск, аналитика).

По сравнению с базами данных сила Elasticsearch заключается в том, что он можетнечеткий запрос.

Некоторые студенты могут сказать: Почему я не могу сделать нечеткий запрос в своей базе данных? ? Я напишу вам SQL наотмашь:

select * from user where name like '%公众号Java3y%'

Разве нельзя было быОфициальный аккаунт Java3yВы искали соответствующий контент?

Действительно, это возможно. Но главное понять:name like %Java3y%Такой запрос не проходитпоказательДа, никакая индексация не означает: пока ваша база данных большая (100 миллионов), ваш запрос обязательно будетвторойуровень

Если вы мало что знаете об индексах баз данных, рекомендуем ознакомиться с моими предыдущими статьями. Думаю, тогда я неплохо писал (ха-ха)

GitHubКлючевое слово для поиска: "индекс"

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

Другое дело: содержание пользовательского ввода часто не такточный, как я набрал из GoogleElastcSeach(опечатка), но Google по-прежнему может определить, что я хочу ввестиElasticsearch

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

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

Давайте узнаем, почему Elasticsearch может выполнять вышеуказанные пункты.

Структура данных эластичного поиска

Как мы все знаем, если вы хотите тратить меньше времени на запросы, вам нужно знать, какова его базовая структура данных; например:

• Сложность времени поиска по дереву обычно составляет O(logn).
• Временная сложность поиска связанного списка обычно составляет O (n)
• Сложность времени поиска в хеш-таблице обычно составляет O (1)
• ....Время, проведенное в разных структурах данных, часто различно.быстрый, вам необходимо иметь поддержку базовой структуры данных

Из вышесказанного следует, что скорость нечетких запросов Elasticsearch очень высока.Какова основная структура данных Elasticsearch? Давайте взглянем.

Мы основаны на "полное состояние", чтобы найти запись под названиемфорвардный индекс; Каталог глав нашей книги представляет собой прямой индекс, и соответствующий номер страницы можно найти по названию главы.

Сначала мы должны знать, почему Elasticsearch может достигать быстрых результатов».нечеткое соответствие"/"Запрос релевантности», что на самом деле происходит, когда вы записываете данные в ElasticsearchПричастие.

Возьмите приведенное выше изображение в качестве примера, приведенное выше изображение появляется 4 раза.алгоритм«Это слово, можем ли мы найти соответствующий каталог на основе этого слова? Elasticsearch делает именно это. Если мы сделаем это в соответствии с картинкой выше, мы получим результаты, подобные этому:

• алгоритм->2,13,42,56

Это означает, что слово «алгоритм» должно было появиться на страницах 2, 13, 42 и 56. эта основаслово(неполное условие), а затем найти соответствующую запись, называемуюПеревернутый индекс.

Взгляните на картинку ниже и получите хороший опыт:

Как мы все знаем, в мире так много языков, а как насчет Elasticsearch?Как насчет разделения этих слов?, Эластичный поисквстроенныйнекоторые токенизаторы

• Стандартный анализатор. Разделить по словам, слова в нижнем регистре
• Простой анализатор. Фильтр по не букве (символы отфильтровываются), строчные слова
• Анализатор пробелов. Разделить пробелом, а не строчными буквами
• ....подожди подожди подожди

Токенизатор Elasticsearch в основном состоит из трех частей:

• ‌ ‌ ‌ ‌ ‌ Фильтры символов
• Токенизатор (сегментированный в соответствии с правилами, такими как пробелы)
• TokenFilter (обработка сегментированных слов, например преобразование в нижний регистр)

Очевидно, что Elasticsearch был написан иностранцами, а встроенные токенизаторы все на английском языке.Когда наши пользователи ищут, они часто ищут на китайском языке.Сейчас наиболее часто используемые китайские токенизаторыIK.

В конце концов, какова структура данных Elasticsearch? См. рисунок ниже:

Вводим фрагмент текста, и Elasticsearch выполнит анализ нашего текста по токенизатору.Причастие(то есть Ада/Аллен/Сара... как видно на картинке), эти словари вместе называютсяTerm Dictionary, и нам нужно найти соответствующие записи с помощью сегментации слов, эти идентификаторы документов хранятся вPostingList

существуетTerm DictionaryТак как в тексте так много словСортировать, когда вы хотите найти его, вы можете пройтидве точкичтобы проверить, не нужно проходить весьTerm Dictionary

так какTerm DictionaryСлишком много слов, невозможно вставитьTerm DictionaryВсе слова размещаются в памяти, поэтому Elasticsearch также отрисовывает слой с именемTerm Index, этот слой хранит только частьпрефикс слова,Term Indexбудет храниться в памяти (извлечение будет очень быстрым)

Term Indexв памяти какFST(преобразователи конечного состояния), который характеризуетсяочень эффективное использование памяти. FST имеет два преимущества:

• 1) Маленькая площадь. За счет повторного использования префиксов и суффиксов слов в словаре пространство для хранения сжимается;
• 2) Скорость запроса высокая. O(len(str)) сложность времени запроса.

упомянутый ранееTerm Indexхранится в памяти, и Elasticsearch используетFST(преобразователи конечного состояния) в виде сохранения (экономии места в памяти).Term DictionaryВ Elasticsearch тоже по нему сортируется (удобно при поиске), на самом делеPostingListЕсть и соответствующие оптимизации.

PostingListбудет использовать систему отсчета (FOR) технология кодирования для сжатия данных внутри,Экономьте место на диске.

PostingListВ нем хранится идентификатор документа, при проверке часто требуется делать идентификатор документа.пересечение и объединениеоперации (например, в запросах с несколькими условиями),PostingListиспользоватьRoaring Bitmapsдля выполнения операции пересечения и объединения идентификаторов документов.

использоватьRoaring BitmapsПреимущество заключается в том, что он может сэкономить место и быстро получить результат пересечения и объединения.

Итак, здесь мы суммируем характеристики структуры данных Elasticsearch:

Терминология и архитектура Elasticsearch

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

Если вы мало знаете о распределении, рекомендуется прочитать мои предыдущие статьи. Думаю, тогда я неплохо писал (ха-ха)

GitHubКлючевые слова для поиска: «SpringCloud», «Zookeeper», «Kafka», «Единый вход».

Прежде чем объяснять архитектуру Elasticsearch, сначала мы должны понять некоторые общие термины Elasticsearch.

• Index: индекс Elasticsearch эквивалентен таблице базы данных
• Type: это было отменено в новой версии Elasticsearch (в предыдущей версии Elasticsearch несколько типов поддерживались в одном индексе — что-то похожее на концепцию нескольких групп в одной теме в очереди сообщений)
• Document: Документ эквивалентен ряду записей в базе данных.
• Field: понятие, эквивалентное столбцу базы данных.
• Mapping: Концепция, эквивалентная схеме базы данных
• DSL: SQL-эквивалент базы данных (дает нам API для чтения данных Elasticsearch)

Я считаю, что после прочтения приведенной выше сравнительной таблицы нетрудно понять некоторые термины Elasticsearch. Какова архитектура Elasticsearch? Давайте посмотрим ниже:

Кластер Elasticsearch будет иметь несколько узлов Elasticsearch.Так называемые узлы на самом деле являются машинами, на которых запущен процесс Elasticsearch.

Среди множества узлов будет одинMaster Node, который в основном отвечает за поддержание метаданных индекса, переключение идентификаторов первичных сегментов и сегментов реплик и т. д. (концепция сегментирования будет обсуждаться позже).Если первичный узел умирает, будет выбран новый первичный узел.

Из вышеизложенного мы также узнали, что самым внешним слоем Elasticsearch является индекс (эквивалент концепции таблицы базы данных); данные индекса могут быть распределены по разным узлам для хранения.Эта операция называетсяФрагментация.

Например, в моем кластере сейчас 4 узла, и у меня теперь есть Индекс, Если я хочу хранить этот Индекс на 4 узлах, то мы можем установить его на 4 шарда. Данные этих 4 осколковвместеэто индексные данные

Почему осколок? Причина тоже очень проста:

• Если объем данных индекса слишком велик и имеется только один сегмент, он будет храниться только на одном узле.По мере роста объема данных узел может не иметь возможности хранить индекс.
• Несколько сегментов могут работать параллельно при записи или запросе (чтение и запись данных с каждого узла, повышение пропускной способности).

Теперь вопрос: если узел зависнет, будет ли эта часть данных потеряна? Очевидно, что Elasticsearch также подумает об этой проблеме, поэтому сегменты будут разделены на первичные сегменты и сегменты-реплики (для достиженияВысокая доступность)

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

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

Если узел не работает, ранее поднятыйMaster NodeСоответствующий сегмент реплики будет повышен до основного сегмента, так что даже если узел умрет, данные не будут потеряны.

Здесь мы можем кратко обобщить архитектуру Elasticsearch:

Поток написания Elasticsearch

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

Когда клиент записывает часть данных, она отправляется в кластер Elasticsearch поузелЧтобы обработать этот запрос:

Каждый узел в кластереcoordinating node(узел координатора), координирующий узел указывает, что этот узел может выполнятьмаршрутизация. НапримерУзел 1Был получен запрос, но оказалось, что данные для этого запроса должны бытьУзел 2обработки (поскольку основной осколокУзел 2), поэтому запрос будет перенаправлен наУзел 2начальство.

• координата(координация) Узел может вычислить, на каком первичном осколке он находится, с помощью алгоритма хеширования, а затеммаршрут к соответствующему узлу
• shard = hash(document_id) % (num_of_primary_shards)

При маршрутизации к соответствующему узлу и соответствующему первичному шарду он будет делать следующее:

1. записать данные в буфер памяти
2. Затем запишите данные в транслог-буфер.
3. любой другой1sДанные обновляются из буфера в FileSystemCache, и создается файл сегмента.После создания файла сегмента его можно запрашивать через индекс.
4. После обновления буфер памяти очищается.
5. любой другой5s, транслог сбрасывается из буфера на диск
6. Периодически/количественно из FileSystemCache в сочетании с транслоговым содержимымflush indexна диск.

объяснять:

• Elasticsearch сначала запишет данные в буфер памяти, а затем во все остальные.1sСбросить в буфер файловой системы (данные можно извлечь только после того, как данные будут сброшены в буфер файловой системы). Итак: данные, написанные Elasticsearch, должны1sзапросить
• Чтобы предотвратить простои узла и потерю данных в памяти, Elasticsearch запишет еще одну копию данных вжурнальный файл, но он по-прежнему записывается в буфер памяти в начале, каждый5sБуфер будет сброшен на диск. Итак: если узел Elasticsearch зависает, это может вызвать некоторые5sданных теряется.
• Он будет запущен, когда файл транслога на диске достигнет определенного размера или превысит 30 минут.commitОперация асинхронного сброса файла сегмента из памяти на диск для завершения операции сохранения.

Грубо говоря: записать буфер памяти (выбор временигенерировать сегмент, генерировать транслог), можноСделайте данные индексируемыми и постоянными. Наконец, постоянство завершается один раз коммитом.

После записи основного сегмента данные будут отправлены на узлы набора реплик параллельно и вернутся, когда все узлы будут успешно записаны.ackУзел-координатор возвращает узел-координаторackКлиенту завершить запись.

Обновление и удаление Elasticsearch

Процесс обновления и удаления Elasticsearch:

• дать соответствующийdocзапись отмечена.delОтметить, если это операция удаления, она будет отмеченаdeleteСтатус, если это операция обновления, ставьте оригинальныйdocотмечен какdelete, а затем перезаписать данные

Как упоминалось ранее, каждый1sБудет сгенерирован файл сегмента, и файлов сегментов будет все больше и больше. Elasticsearch будет иметьmergeзадача, будет несколько файлов сегментовсливатьсяв файл сегмента.

В процессе слиянияdeleteгосударствоdocдаватьфизическое удалениеТерять.

Эластичный поисковый запрос

Самый простой способ обратиться к нам можно разделить на два типа:

• Запросить документ по идентификатору
• В соответствии с запросом (поисковым термином) для запроса соответствующего документа

public TopDocs search(Query query, int n);
public Document doc(int docID);

в соответствии сIDПроцесс запроса конкретного документа:

• Получить файлы Translog из памяти
• Получить файлы Translog с жесткого диска
• Получить файлы сегментов с жесткого диска

в соответствии сqueryПроцесс сопоставления документа:

• Перейти к просмотру файлов сегментов памяти и жесткого диска одновременно

Из процесса написания, упомянутого выше, мы можем узнать: Получить (проверка документа через идентификатор происходит в режиме реального времени), запрос (сопоставление документа через запрос почти в режиме реального времени)

• Поскольку файл сегмента генерируется каждую секунду

Запрос Elasticsearch можно разделить на три этапа:

• QUERY_AND_FETCH (вернуть все содержимое документа после запроса)

• QUERY_THEN_FETCH (сначала запросить соответствующий идентификатор документа, а затем сопоставить соответствующий документ в соответствии с идентификатором документа)

• DFS_QUERY_THEN_FETCH (сначала подсчитать баллы, а затем запросить)

  • «Точки здесь относятся кЧастота слов и частота документов(Частота термина, Частота документа) Как мы все знаем, чем выше частота, тем сильнее корреляция».

Как правило, мы используем наиболееQUERY_THEN_FETCH, первый тип запроса, который возвращает все содержимое документа (QUERY_AND_FETCH), подходит только для запросов, которым нужно проверить только один сегмент.

QUERY_THEN_FETCHОбщая схема процесса примерно такая:

• Клиентские запросы отправляются на узел в кластере. Каждый узел в кластере является координационным узлом
• Затем координирующий узел перенаправляет поисковый запрос нана всех осколках(будут работать как первичные, так и реплицированные осколки)
• Каждый осколок будет искать свои собственные результаты(doc id)Он возвращается узлу-координатору, и узел-координатор выполняет объединение данных, сортировку, разбиение по страницам и другие операции для получения окончательного результата.
• Затем координирующим узлом согласноdoc idк каждому узлувытащить фактическийизdocumentДанные, наконец, возвращаются клиенту.

Фаза запросаЧто делает узел времени:

• Координирующий узел отправляет команду запроса целевому сегменту (пересылая запрос на основной сегмент или сегмент реплики).
• Узлы данных (фильтрация, сортировка и т. д. в каждом шарде), возвратdoc idкоординатору

Фаза выборкиЧто делает узел времени:

• Узел-координатор получает данные, возвращенные узлом данных.doc id, для этихdoc idВыполните агрегацию, а затем отправьте команду захвата целевому сегменту данных (надейтесь получить всю запись документа)
• Узлы данных отправляются узлом-координаторомdoc id, извлеките действительно необходимые данные и верните их координирующему узлу

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

Просто Elasticsearch делает всю эту работу, и мы не воспринимаем ее, когда используем.

Наконец

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

Если статья неверна, добро пожаловатьдружелюбноПравильное общение. В ближайшие несколько лет я продолжу обновлять вводные статьи, связанные с большими данными.Если вам интересно, обратите внимание на мой паблик-аккаунт.Я думаю, что эта статья в порядке, вы можете поставить мне лайк👍

Использованная литература:

• Расскажите об инвертированном индексе Elasticsearch.
• Зачем вам нужен Elasticsearch
• Принцип реализации словаря lucene - FST
• Оптимизация производительности Elasticsearch
• Углубленный анализ процесса написания Elastic Search
• Анализ ядра Elasticsearch — запрос

если ты хочешьв реальном времениЕсли вы обратите внимание на мои обновленные статьи и галантерейные товары, которыми я делюсь, вы можете подписаться на мой публичный аккаунт "Java3y".

• 🔥Огромные видеоресурсы
• 🔥Java красивая карта мозга
• 🔥Маршрут обучения Java
• 🔥Разработка общих инструментов
• 🔥Красиво организованные электронные книги в формате PDF

Ответить под публичным аккаунтом"888», чтобы получить его! !

Эта книга была включена в мои избранные статьи на GitHub, добро пожаловать, звезда:GitHub.com/Zhongf UC очень…

попросить лайк Пожалуйста, следите за ️ поделитесь пожалуйста 👥 Спросите сообщение 💬верно для меняочень полезно! ! !