2021 - Руководство по собеседованию с Java Backend Engineer - (Elasticsearch)

Elasticsearch

предисловие

Текст был включен в мой репозиторий GitHub, добро пожаловать, звезда:GitHub.com/bin39232820…
Лучшее время посадить дерево было десять лет назад, затем сейчас

Tips

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

woohoo.process on.com/view/lincoln/6…

Выше указан адрес карты мозга.

слухи

Посмотрите на elasticsearch сегодня Затем следует краткое изложение предыдущих статей.

Es на самом деле много полезного, и если у вас тело большего размера, вам в принципе нужно его использовать, поэтому его еще необходимо освоить, поэтому давайте посмотрим

Разговор о том, что такое Elasticsearch

  • Elasticsearch, основанный на lucene Распределенный механизм поиска и анализа Restful в реальном времени (в реальном времени)
  • Распределенное хранилище файлов в реальном времени, каждое поле индексируется и доступно для поиска
  • Высокая масштабируемость, масштабируемость до сотен серверов, обработка структурированных или неструктурированных данных уровня PB
  • Elasticsearch для полнотекстового поиска, структурированного поиска, использования анализа/слияния

Расскажите об особенностях Elasticsearch:

  • Elasticsearch не имеет транзакций в обычном смысле (без транзакций)
  • Elasticsearch — это документно-ориентированная база данных.
  • Elasticsearch не предоставляет функции авторизации и аутентификации.

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

Полнотекстовый поиск, инвертированный индекс

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

lucene

Lucene представляет собой пакет jar, который содержит различные упакованные инвертированные индексы и поисковые коды, включая различные алгоритмы. Когда мы используем Java для разработки, мы можем ввести lucene jar, а затем разработать его на основе API lucene.

Затем вы рассказываете об основных концепциях Elasticsearch, которые мы часто используем.

почти в реальном времени

Почти в реальном времени, два значения, есть небольшая задержка (около 1 секунды) между записью данных и возможностью поиска данных; выполнение поиска и анализа на основе es может достигать второго уровня.

Кластер

Кластер содержит несколько узлов, и к какому кластеру принадлежит каждый узел, определяется конфигурацией (имя кластера, elasticsearch по умолчанию).Для приложений малого и среднего размера нормально иметь один узел в начале кластера.

Узел

Узел в кластере, узел также имеет имя (по умолчанию назначается случайным образом), имя узла очень важно (при выполнении операций управления эксплуатацией и обслуживанием), узел по умолчанию присоединится к кластеру с именем «elasticsearch», если вы запустите сразу кучу узлов, тогда они автоматически сформируют кластер elasticsearch, конечно, нода также может сформировать кластер elasticsearch.

Индекс (индекс - база данных)

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

Тип (таблица типов)

У каждого индекса может быть один или несколько типов. Тип — это логическая классификация данных в индексе. Документы одного типа имеют одинаковые поля. Например, в системе блогов есть индекс, который может определять типы пользовательских данных, тип данных блога, данные комментариев тип.

Документ (строка документа)

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

Поле (поле-столбец)

Поле — это наименьшая единица Elasticsearch. В документе есть несколько полей, и каждое поле является полем данных.

shard

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

replica

Любой сервер может выйти из строя в любое время, а шард в это время может быть потерян, поэтому для каждого шарда можно создать несколько реплик. Реплики могут предоставлять службы резервного копирования в случае сбоя сегмента, чтобы гарантировать, что данные не будут потеряны.Множественные реплики также могут повысить пропускную способность и производительность операций поиска. основной сегмент (устанавливается сразу при создании индекса, не может быть изменен, по умолчанию 5), сегмент реплики (изменяется в любое время, по умолчанию 1), по умолчанию 10 сегментов на индекс, 5 основных сегментов, 5 сегментов реплик, минимальная высота Доступно конфигурация, есть 2 сервера.

Разговор об оптимистическом управлении параллелизмом Elasticsearch

Elasticsearch распространяется. Когда документ создается, обновляется или удаляется, новая версия документа реплицируется на другие узлы в кластере. Elasticsearch является как синхронным, так и асинхронным, что означает, что эти запросы на репликацию отправляются параллельно и достигают места назначения не по порядку. Для этого требуется способ гарантировать, что более старые версии документов никогда не перезапишут более новые версии. Когда мы упомянули запросы index, get, delete выше, мы указали, что каждый документ имеет номер _version, который увеличивается на единицу при изменении документа. Elasticsearch использует эту _version, чтобы убедиться, что все модификации упорядочены правильно. Когда старая версия появляется после новой версии, она просто игнорируется. Мы используем это преимущество _version, чтобы гарантировать, что данные не будут потеряны из-за конфликтующих изменений. Мы можем указать версию документа, чтобы внести нужные изменения. Если этот номер версии не актуален, наш запрос завершается ошибкой. Используйте версию, чтобы обеспечить параллельную последовательную согласованность

Расскажите о разнице между текстом и типами ключевых слов.

  • text: Когда поле должно быть найдено в полном тексте, таком как содержимое электронной почты, описание продукта, следует использовать текстовый тип. После установки типа текста содержимое поля будет проанализировано, и строка будет разбита на термины анализатором перед генерацией инвертированного индекса. Поля текстового типа не используются для сортировки и редко используются для агрегирования.
  • ключевое слово: тип ключевого слова подходит для индексации структурированных полей, таких как адреса электронной почты, имена хостов, коды состояния и метки. Если поле необходимо отфильтровать (например, найти статьи, атрибут статуса которых опубликован в опубликованном блоге), сортировать и объединять. Поля типа ключевое слово можно искать только по точному значению.

Затем вы говорите об основном содержимом, возвращаемом запросом API.

hits

Самая важная часть ответа — это совпадения, которые содержат общее поле для указания общего количества совпадающих документов, а массив совпадений также содержит первые 10 сопоставленных данных. Каждый результат в массиве совпадений содержит поля _index, _type и _id документа, которые добавляются к полю _source, что означает, что мы сможем использовать все документы непосредственно в результатах поиска. Это не похоже на другие поисковые системы, которые возвращают только идентификатор документа, что требует, чтобы вы извлекали документ отдельно. У каждого узла есть поле _score, которое является оценкой релевантности, которая измеряет, насколько хорошо документ соответствует запросу. По умолчанию наиболее релевантные документы возвращаются первыми, это означает, что они отсортированы по _score в порядке убывания. В данном случае мы не указывали никакого запроса, поэтому релевантность всех документов одинакова, поэтому _score всех результатов является промежуточным значением 1. max_score относится к максимальному значению _score во всех запросах на сопоставление документов.

took

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

shards

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

timeout

time_out значение тайм-аута запроса говорит нам или нет. Как правило, поисковый запрос не истекает по времени. Если скорость ответа важнее, чем полный результат, вы можете определить параметр тайм-аута 10 или 10 мс (10 мс), или 1 с (1 сек)

Разговор о механизме shard&replica

  • индекс содержит несколько осколков
  • Каждый шард — это минимальная единица работы, несущая часть данных, экземпляры lucene, полную индексацию и обработку запросов.
  • При добавлении или удалении узлов шард автоматически распределяет нагрузку между узлами.
  • Для основного сегмента и сегмента реплики каждый документ должен существовать только в одном основном сегменте и соответствующем сегменте реплики и не может существовать в нескольких основных сегментах.
  • Шард-реплика — это копия основного шарда, отвечающая за отказоустойчивость и нагрузку запросов на чтение.
  • Количество первичных сегментов фиксируется при создании индекса, а количество сегментов реплик можно изменить в любое время.
  • Количество основных сегментов по умолчанию — 5, а количество реплик по умолчанию — 1. По умолчанию существует 10 сегментов, 5 основных сегментов и 5 сегментов реплик.
  • Первичный осколок нельзя размещать на том же узле, что и его собственный осколок реплики (иначе узел выйдет из строя, первичный осколок и реплика будут потеряны, а отказоустойчивость не может быть достигнута), но его можно разместить на том же узле. узел как осколок реплики других первичных осколков

Как ES реализует генеральные выборы?

Предварительные условия:

  • Только узлы, которые являются кандидатами в мастера (мастер: true), могут стать мастерами.
  • Целью минимального количества мастер-нод (min_master_nodes) является предотвращение разделения мозгов.

Elasticsearch выбранный главный модуль несет ответственник ZENDISCOVERY, в основном, содержащий Ping (RPC между узлами для открытия друг друга), и одноадресный (модуль UniCast, содержит список хостов, которые необходимо контролировать Ping) две части; Получите главный узел для FindMaster Core входного входа, успешно выбирает главный узел возвращает соответствующий мастер, в противном случае возвращает NULL.

Процесс выборов примерно описывается следующим образом:

  • Шаг 1: Подтвердите, что количество мастер-узлов-кандидатов соответствует стандарту, а значение, установленное в elasticsearch.yml, равно discovery.zen.minimum_master_nodes;
  • Шаг 2: Сортировка всех кандидатов в главные узлы в соответствии со словарем nodeId.Каждый раз, когда каждый узел выбирается, он сортирует известные ему узлы, а затем выбирает первый (0-й) узел, который на данный момент считается главным узлом. .
  • Шаг 3: Если количество голосов за узел достигает определенного значения (количество узлов-кандидатов в мастера n/2+1) и узел сам выбирает себя, то этот узел является ведущим. В противном случае переизбрание производится до выполнения вышеуказанных условий.

Как решить проблему разделения мозга кластера ES

Так называемый кластерный разделенный мозг относится к ситуации, в которой 10 узлов в кластере Elasticsearch (например, всего 20) выбирают одного мастера, а остальные 10 выбирают другого мастера.

Когда кандидат Master Cluster не менее 3, мозг решается путем установки минимального голосования (Discovery.zenimum_master_nodes) более половины узла кандидата решается. Когда количество кандидатов - это два, только один главный кандидат может быть изменен только, а другой, как узел данных, избегая проблем с мозгом.

Давайте поговорим о процессе написания es

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

Каждый индекс состоит из нескольких сегментов (по умолчанию 5).Каждый сегмент имеет один главный узел и несколько узлов-реплик, а количество реплик можно настроить. Но каждый раз, когда вы пишете, запрос на запись будет сначала выбирать, на какой Shard отправить в соответствии с правилом _routing.В запросе индекса вы можете установить значение, какое Filed использовать в качестве параметра маршрутизации. Будет использоваться сопоставление Если сопоставление Если в нем нет конфигурации, используйте _id в качестве параметра маршрутизации, затем выберите шард (в классе OperationRouting) через хеш-значение _routing, и, наконец, найдите первичный узел шарда из Мета кластера.

Затем запрос будет отправлен на основной сегмент. После успешного выполнения запроса на основном сегменте запрос будет отправлен из основного сегмента на несколько сегментов реплик одновременно. После успешного выполнения запроса на нескольких репликах Shards и возвращены в Primary Shard, запрос будет записан, выполнение выполнено успешно и результат возвращен клиенту.

Затем вы говорите о конкретном процессе записи на осколке.

В каждом сегменте процесс записи делится на две части: сначала запись в Lucene, а затем запись в TransLog.

После поступления запроса на запись в шард сначала запишите файл Lucene и создайте индекс, пока индекс еще находится в памяти, затем запишите TransLog.После записи TransLog обновите данные TransLog на диск.После записи в диск прошел успешно, запрос возвращается пользователю. Вот несколько ключевых моментов:

В отличие от баз данных, базы данных сначала записывают CommitLog, а затем память, в то время как Elasticsearch сначала записывает память, а затем TransLog в последнюю очередь.Одна из возможных причин заключается в том, что запись в память Lucene будет иметь очень сложную логику, и ее легко потерпеть неудачу, например сегментация Word, длина поля превышает Лимит и т. д. относительно тяжелые.Чтобы избежать большого количества недействительных записей в TransLog, уменьшить сложность восстановления и улучшить скорость, мы поставили Lucene на первое место.

После записи в память Lucene поиск невозможен. Необходимо преобразовать объект памяти в полный сегмент с помощью Обновить, а затем снова открыть его, прежде чем его можно будет найти. Обычно это время устанавливается равным 1 секунде, в результате чего документ записывается к Elasticsearch, Поиск занимает до 1 секунды, поэтому Elasticsearch представляет собой систему NRT (почти в реальном времени) в режиме, близком к реальному времени, с точки зрения поиска.

Каждый длительный период времени, например, через 30 минут, Lucene будет обновлять новый сегмент, сгенерированный в памяти, на диск.После обновления файл индекса сохраняется, и исторический TransLog будет бесполезен, а старый TransLog будет быть опустошенным. .

Данные в кеше Lucene будут генерировать файл сегмента через 1 секунду по умолчанию.Даже если файл сегмента сгенерирован, сегмент записывается в кеш страницы, а не записывается на диск в режиме реального времени, только когда он достигает определенного времени или достигает определенной суммы Принудительно сбросить диск. Если машина выйдет из строя в течение этого периода, данные в памяти будут потеряны. В этом случае данные в памяти можно восстановить из TransLog, который по умолчанию очищает диск каждые 5 секунд. Но это все равно не гарантирует сохранности данных, потому что в TransLog все равно можно потерять до 5 секунд данных. Здесь вы можете повысить надежность данных, настроив частоту сброса диска TransLog.Минимальная настройка может быть 100 мс, но это не рекомендуется, так как это сильно повлияет на производительность. В целом Elasticsearch решает эту проблему за счет механизма реплик. Даже если узел, на котором расположен первичный сегмент, выйдет из строя и потеряет данные за 5 секунд, его все равно можно будет восстановить с помощью реплики.

Подводя итог, данные сначала записываются в буфер памяти, а затем каждые 1 с, данные обновляются в кэше ОС, и данные можно искать, когда поступает кэш ОС (поэтому мы говорим, что es можно искать из записи к поиску, а посередине стоят 1). Задержка). Каждые 5 с данные записываются в файл транслога (так что, если машина не работает, данные памяти полностью теряются, и данные будут потеряны на срок до 5 с).Данные в области сбрасываются в файл сегмента файл диска.

Расскажите о процессе обновления es

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

  • После запроса на обновление прочитайте весь документ с тем же идентификатором из Segment или TransLog и запишите номер версии как V1.
  • Объедините полный документ версии V1 и некоторые поля документа в запросе в полный документ и одновременно обновите VersionMap в памяти. После получения полного документа запрос на обновление становится запросом индекса.
  • замок.
  • Прочитайте еще раз максимальный номер версии V2 идентификатора из versionMap.Если нет versionMap, прочитайте его из Segment или TransLog, который в основном будет получен из versionMap.
  • Проверьте, не конфликтуют ли версии (V1==V2).Если есть конфликт, вернитесь к началу этапа «Обновление документа» и выполните его снова. Если конфликта нет, выполняется последний запрос на добавление.
  • На этапе Index Doc сначала получите версию + 1, чтобы получить V3, а затем добавьте документ в Lucene. Lucene удалит существующий идентификатор документа с тем же идентификатором, а затем добавит новый документ. После успешной записи в Lucene обновите текущую версию V3 до versionMap.
  • Снимите блокировку, и процесс частичного обновления завершен.

Опишите подробно процесс поиска ЭП?

Поиск выполняется как двухэтапный процесс: Query Then Fetch;

Стадия запроса:

Запросы передаются на каждую копию сегмента (основную или реплику) в индексе. Каждый шард выполняет поиск локально и строит приоритетную очередь размера из документов, соответствующих размеру +. PS: при поиске будет запрашиваться кэш файловой системы, но некоторые данные все еще находятся в буфере памяти, поэтому поиск осуществляется почти в режиме реального времени. Каждый осколок возвращает идентификаторы и значения сортировки всех документов в своей собственной очереди приоритетов координатору, который объединяет эти значения в свою очередь приоритетов для получения глобально отсортированного списка результатов.

Стадия выборки:

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

Поговорите о согласованности записи es

Когда мы отправляем любую операцию добавления, удаления и модификации, например, put /index/type/id, мы можем ввести параметр согласованности, указывающий, какую согласованность записи мы хотим? поставить /index/type/id?consistency=quorum

  • one: мы должны выполнять эту операцию записи, пока один основной шард активен и доступен.
  • all: мы обязаны выполнять эту операцию записи только в том случае, если активны все первичные осколки и осколки реплик.
  • кворум: значение по умолчанию, которое требует, чтобы большинство осколков были активны и доступны, прежде чем можно будет выполнить эту операцию записи.

Поговорите о глубоком поиске по страницам в эластичном поиске и поиске с прокруткой.

глубокий пейджинг

Глубина страниц на самом деле является глубиной поиска. Например, страница 1, страница 2, страница 10 и страница 20 являются относительно мелкими, а страницы 10 000 и 20 000 — очень глубокими. Слишком глубокий поиск может вызвать проблемы с производительностью, потреблять память и процессор. Кроме того, для повышения производительности es не поддерживает запросы на подкачку с более чем 10 000 фрагментов данных. Итак, как решить проблемы, вызванные глубоким пейджингом, мы должны избегать операций глубокого пейджинга (ограничивать количество страниц подкачки), например, можно предоставить максимум 100 страниц отображения, и оно исчезнет со страницы 101, в конце концов , пользователи не будут искать так глубоко, мы обычно ищем Taobao или JD.com, чтобы увидеть первые 10 страниц.

прокрутка поиска

Одновременный запрос более 10 000 данных часто влияет на производительность, поскольку данных слишком много. В настоящее время вы можете использовать поиск с прокруткой, то есть прокрутку 。 Поиск с прокруткой может сначала запрашивать некоторые данные, а затем, в свою очередь, запрашивать вниз. В первом запросе будет идентификатор прокрутки, который эквивалентен тегу привязки, а затем для повторной прокрутки потребуется идентификатор прокрутки предыдущего поиска, и следующий поисковый запрос будет выполнен в соответствии с этим. Каждый поиск основан на моментальном снимке исторических данных. В течение периода запроса данных, если есть какие-либо изменения данных, это не имеет отношения к поиску.

Как es повышает производительность при большом объеме данных

filesystem

Скорость запроса es самая высокая каждый раз, когда вы переходите к кешу файловой системы. Таким образом, данные для каждого запроса будут заполнены на 50 %. = емкость кэша файловой системы.

Прогрев данных

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

Горячее и холодное разделение

Подтаблица и подбиблиотека аналогичны MySQL Создайте отдельный индекс для «горячих» данных. Выделите 3 машины, чтобы сохранить только индекс «горячей» машины. Другая машина поддерживает индекс «холодных» данных, но есть проблема, заключающаяся в том, что она должна заранее знать, какие данные «горячие», а какие «холодные».

Нет глубокого пейджинга

Скажите продакт-менеджеру, что ваша система не позволяет вам так глубоко перелистывать страницы. Чем глубже вы перелистываете по умолчанию, тем хуже производительность.

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

конец

es может использоваться меньше сам, только для некоторых поисков, а не для bi, и что? Это не так подробно, я надеюсь, что это будет полезно для всех, а затем просмотрите очередь

ежедневные комплименты

Хорошо всем, вышеизложенное является полным содержанием этой статьи. Люди, которые могут видеть это здесь, всенастоящий порошок.

Творить нелегко. Ваша поддержка и признание — самая большая мотивация для моего творчества. Увидимся в следующей статье.

Поиск в WeChat "Жизнь программы шестиимпульсного Excalibur" Ответить 888 Я нашел для вас много информации

Категории