Заметки об исследовании Elasticsearch

предисловие

• Почему запросы и агрегация выполняются так быстро? Какова базовая реализация?
• Как данные хранятся в кластере ES? Как сделать автоматическую раздачу?
• Почему нельзя настроить количество первичных шардов ES после установки, но можно настроить количество шардов-реплик?
• Как оптимизировать метод индексации и метод запроса, эффективно использовать кеш и повысить эффективность запросов?
• Если есть гарантия, что сервер не остановится, можно ли его плавно обновить или расширить?
• Как оптимизировать эффективность запросов?

Я считаю, что после прочтения этой книги окончательное руководство по Elasticsearch, все вопросы будут даны ответы

1. Основные понятия

1. Sharding

• Наименьшая единица работы, которая содержит часть данных в индексе. Является экземпляром Lucene, который сам по себе является полноценной поисковой системой. Но приложения не взаимодействуют напрямую с шардами.
• Его можно представить как контейнер, а миграция данных между узлами осуществляется в единицах осколков.
• Делится на основной и вторичный сегменты (копия основного сегмента).
• При создании индекса количество первичных осколков фиксируется, но количество осколков реплик можно регулировать.
• По умолчанию для индекса выделяется 5 первичных осколков.
• После того, как основное подразделение повешено, переизберите первичный узел и обновите часть подразделения до основного фрагмента.
• После перезапуска узкого узла во время отказа синхронизации не будет синхронизирована к данным

2. Документация

• Корневой объект сериализуется в объект json.
• При каждой операции с документом (включая модификацию, удаление) _версия будет увеличиваться на единицу.
• Документы не подлежат изменению. update сначала удалить, а потом создать новый
• Удаленные документы не удаляются сразу, они просто помечаются на удаление. Очистить позже
• Настройте свою версию документа: добавьте version_type = внешние параметры

3. Разрешение конфликтов

• Реализуйте оптимистическую блокировку для разрешения конфликтов с помощью номеров версий.

4. Метаданные документа

• _index, где хранится документ
• Класс объекта, представленный документом _type (версия 7.x удалит _type)
• _id Уникальный идентификатор документа. Может быть установлен вручную или сгенерирован автоматически (длиной 22 бита)

5. Схема архитектуры кластера

Рендеринг двух узлов, три первичных осколка и один вторичный осколок

Развернуть до трех узлов для рендеринга

6. Статус кластера

Состояние кластера — это структура данных, и состояние кластера существует в каждом клиенте. Сохраните следующую информацию

• Настройки уровня
• узел кластера
• Индексы и связанные сопоставления, псевдонимы и т. д.
• Осколки индекса и назначенные узлы

статус-статус кластера

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

2. Принцип работы кластера

1. Как данные хранятся в распределенной системе

• Документы направляются в шарды
• Номер шарда при сохранении документа получается по следующему алгоритму

  shard = hash(routing) % number_of_primary_shards
  

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

2. Как взаимодействуют основные сегменты и реплицированные сегменты?

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

2.1 операции записи (создание, удаление, индексация)

последовательные шаги

• Клиент отправляет запрос (создать, удалить, индексировать) узлу node1
• Узел использует алгоритм HASH для рисования фрагмента с номером 0, поскольку фрагментация 0 находится в узле 3, и перенаправляет запрос на узел 3.
• node3 успешно сохраняет данные в первичный шард, в случае успеха перенаправляет запрос на node1 и node2 на вторичный узел
• Все узлы репликации завершаются успешно, отправляют успешный ответ запрашивающему узлу 1, а узел 1 возвращает клиенту

регулируемые параметры

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

  int((primary[总是1] + number_of_replicas) /2 + 1)
  

• тайм-аут: время ожидания, когда не хватает осколков. По умолчанию 1 мин.

2.2 операция чтения

• Клиент отправляет запрос на получение node1
• Узел использует хеш-алгоритм для получения осколка 0, к которому относится документ, к основному осколку.
• Узлы, в которых находятся вторичные осколки осколка 0, это node1, node2, node3.
• Выберите узел подшарда с помощью определенной стратегии, например node2.
• узел2 возвращает документ узлу1
• Затем node1 возвращается к клиенту

2.3 Операция ОБНОВЛЕНИЯ

последовательные шаги

• Клиент отправляет запрос на обновление на node1
• Получите местоположение основного сегмента с помощью хеш-алгоритма и перенаправьте запрос на node3.
• Node3 извлекает документ, изменяет поле _source на документ json и перестраивает индекс. Если другой процесс изменяет документ, он повторяет этот шаг количество раз, установленное параметром retry_on_conflict, и прекращает работу в случае неудачи.
• Если узел 3 успешно обновлен, он отправит весь новый документ (не запрос на изменение) узлам-репликам узла 1 и узла 2 для перестроения индекса.В случае успеха он будет возвращен узлу 1, а затем возвращен клиенту.

2.4 Многодокументный режим

mget чтение нескольких документов

• Клиент отправляет запрос mget на node1
• node1 формирует запрос для каждого сегмента и перенаправляет его на узел, где находится соответствующий сегмент.
• Когда все ответы получены, node1 объединяет эти ответы и возвращает их клиенту.

массовая запись нескольких документов

• Клиент отправляет запрос на node1
• node1 формирует пакетные запросы для каждого сегмента и перенаправляет их на эти основные сегменты.
• Мастер-слайс последовательно выполняется после каждого завершения, он отправляется в суб-слайс
• Все операции завершаются после того, как ответ узла о завершении возвращается клиенту.

3. Как создается индекс

3.1 Основные понятия

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

3.2 Анализ

процесс анализа

• Анализ делает анализатор
• Процесс анализа сначала помечает фрагмент текста как отдельное слово (элемент).
• Затем нормализуйте (например, все строчные буквы) элементы, чтобы улучшить возможность поиска.
• Подробности анализа можно просмотреть через _analyze API.

Компоненты, входящие в состав анализатора

es предоставляет множество компонентов, которые можно использовать напрямую, которые можно использовать в пользовательских комбинациях.

• Фильтр символов (фильтр символов): через него проходит строка для выполнения некоторых операций фильтрации.
• Tokenizer: разделите текст на слова, такие как пробелы, запятые и т. д. Китайцы могут использовать специальный токенизатор
• Фильтр токенов: измените слова, такие как строчные буквы, удалите модальные частицы и добавьте синонимы.

Встроенный анализатор

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

режим запроса

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

Указать анализатор вручную

• При добавлении строки в es, es автоматически использует стандартный анализатор для сегментации слов, но некоторые символы могут быть обычными полями типа id, label и т.д., анализ не требуется, а сопоставление можно задать вручную

Порядок поиска анализаторов при создании индекса

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

Порядок, в котором анализаторы просматриваются при поиске индекса

• анализатор в параметрах запроса
• анализатор для указанных полей в файле сопоставления
• Анализатор типа, указанного в файле сопоставления
• Глобальный анализатор по умолчанию в файле сопоставления
• Анализатор по умолчанию на уровне узла
• standard analyzer

3.3 Отображение

эффект

Определите тип поля, тип данных поля и то, как он обрабатывается es.

Поддерживаемые типы полей

тип	Представленный тип данных
String	string
Whole Number	byte short integer long
Floating point	float double
Boolean	boolean
Date	date

Если для нового поля не настроено сопоставление, es автоматически определит тип поля.

Чего можно достичь с помощью пользовательского сопоставления полей

• Различают полнотекстовую строку (требуется слово) и точные строки (без слов слов)
• Использовать языковые анализаторы
• Оптимизация полей частичного соответствия
• Укажите пользовательский формат даты

Карта содержит параметры

• свойства: список сопоставлений для каждого поля, которое может быть включено
• Поля метаданных: _type, _id, _source
• динамический: определите стратегию при добавлении поля (_source всегда будет сохранен)
  • автоматически добавляется
  • ложные поля игнорирования
  • строгий выдает исключение
• Элемент настройки: например, анализатор
• другие настройки

Примечания по сопоставлению настраиваемых полей

• Параметр поля для сопоставления - это тип, за исключением строки, он редко необходим для отображения других типов
• Поле индекса строкового поля управления элементами управления, как строка проиндексирована.

  ценность	значение
  analyzed	индекс причастия
  not_analyzed	бессловесный указатель
  no	не индексировать

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

Свойства полей документа

• type
• index
• analyzer
• ip
• geo_point
• geo_shape

поле metadata_source

• Роль: используется для сохранения исходного поля json.
• зачем нужно
  • Результаты поиска полной документации
  • Отсутствует, запросы на частичное обновление не работают
  • При обновлении файла сопоставления вы можете напрямую получить содержимое
  • Легче устранять ошибки
• Как отключить: включено: false
• Использование: при поиске можно указать только какие столбцы возвращать через _source

поле metadata_all

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

Динамические шаблоны

dynamic_templates настроен на динамическое сопоставление различных сопоставлений по имени или типу поля.

• Тип данных, используемый шаблоном match_mapping_type
• Имя поля, используемое шаблоном сопоставления
• Полный путь к полю, используемому шаблоном пути (вложенный json)

3. Язык структурированных запросов

1. Фильтр

Обзор

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

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

Важные операторы фильтра

• термин: точное совпадение
• термины: точное совпадение нескольких условий
• диапазон: фильтрация диапазона
• EXISTS: Содержите ли вы указанное поле?
• Отсутствует: нет поля
• bool: объединить несколько отфильтрованных результатов запроса
  • должен: и
  • must_not: нет
  • следует: или

порядок фильтрации

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

2. Запрос

Кратко

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

важный запрос

• math_all: запросить все документы
• match: стандартный запрос, поддерживается как полный текст, так и точный

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

• multi_match: одновременный поиск по нескольким полям, поддержка подстановочных знаков
• bool: фильтровать так же, как bool, но больше для вычисления _score

3. Рейтинг релевантности

Сортировать по

• _score: метод сортировки по умолчанию, обратный порядок по умолчанию

• Сортировка полей: _score не нужно вычислять, по умолчанию используется положительный порядок

• Многоуровневая сортировка: можно указать несколько полей. Сначала отсортируйте по первому полю, затем отсортируйте по второму, если первое совпадает

• Порядок строковых параметров:

  Принудительная сортировка анализируемых полей потребляет много памяти

Введение в релевантность

Алгоритм подобия: TF/IDF (частота поиска/обратная частота документа)

• TF: частота слова, чем больше раз оно встречается в текущем документе, тем выше релевантность
• IDF: инвертированная частота документа, количество всех документов и файлов отображается в процентах от слова, слово появляется, чем больше частота, тем меньше IDF
• Из-за проблем с производительностью каждый сегмент будет вычислять IDF только внутри этого сегмента, а не для всех документов.
• Параметр boost может установить вес

4. Как выполняется распределенный поиск

Обзор

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

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

Запрос

• Клиент отправляет поиск на node3, создавая пустую очередь с приоритетом from+size

• Распространяйте запрос на каждый сегмент, каждый сегмент выполняет запрос локально и помещает его в локальную очередь с приоритетом размера от + размер

• Каждый узел возвращает результаты запроса (id и _score) узлу3, а узел3 сортирует результаты глобально.

  • Множественные запросы будут опрашивать все копии сегментов для балансировки нагрузки и повышения пропускной способности системы.
  • Рабочий механизм мультииндекса аналогичен механизму одиночного индекса, но с большим количеством осколков.
  • Глубокое разбиение по страницам приведет к тому, что процесс сортировки будет очень тяжелым, занимая огромные ресурсы ЦП и пропускной способности.

принести

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

параметры поиска (необязательный параметр)

• предпочтение: определяет, какой сегмент или узел используется для обработки запроса.
• Тайм-аут: координационный узел, чтобы ждать долго, чтобы отказаться от результатов других узлов
• маршрутизация: ограничивает только сегменты для поиска, полезно для крупномасштабных систем.
• search_type: query_then_fetch — это тип поиска по умолчанию.
  • count: когда результат не нужен, нужен только номер
  • query_and_fetch: запрос и извлечение
  • dfs_query_and_fetch, dfs_query_then_fetch
  • scan: сканирование, используется с прокруткой. Можно эффективно извлекать большие объемы данных. Отключить реализацию сортировки

Сканируй и пролистывай

scroll

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

scan

Без сортировки, возврат до тех пор, пока есть результаты

4. Внутренние принципы фрагментации

1. Принцип динамического обновления индекса

1.1 Перевернутый индекс — гарантийные документы с возможностью поиска

1.2 Перевернутый индекс контента неизменен

1.3 Динамически добавляя сегменты во время неизмеренного

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

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

1.4 Удалить и обновить

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

1.5 Поиск почти в реальном времени

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

1.6 Обновить

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

1.7 Изменение стойкости

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

1.8 Объединение сегментов

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

1.9 Optimize API

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

2. Кэш

Обзор

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

Не кешируется

• Фильтр скриптов, скрипты непрозрачны для es
• ГЕО (адресные) фильтры не будут использоваться повторно
• Диапазоны дат с точностью до миллисекунд не кэшируются, кэшируются целые числа

Рекомендации по использованию временных диапазонов фильтра

• Для запросов со временем с точностью до миллисекунд его можно разбить на два условия фильтра: дата + дата и время, первое будет кешироваться и порядок не должен меняться.

V. Полнотекстовый поиск

1. Полнотекстовый поиск включает в себя два аспекта

• Релевантность: TF/IDF, географическая близость, нечеткое сходство или другие алгоритмы.
• Анализ: сегментация слов, создание инвертированного индекса

2. Классификация полнотекстовых запросов

• Низкоуровневый запрос: терм-запрос. Нет стадии синтаксического анализа, будут соответствовать точные фразы
• Полнотекстовый поиск: match, query_string и другие запросы. Есть этап анализа.
  • дата, целочисленный тип: точный запрос
  • Строковый тип not_analyzed: анализировать слова запроса (например, в нижнем регистре), выполнять запрос с одной фразой.
  • Тип анализируемой строки: сначала проанализируйте оператор запроса, чтобы сгенерировать список фраз. После запроса объединить результаты запроса

6. Агрегация

Основная концепция

ведра

Совокупность документов, соответствующих определенным критериям. Аналогично группировке в sql

показатели

Статистические расчеты выполняются по документам в корзине. Аналогично подсчету, сумме, максимуму и другим статистическим методам в sql.

2. Приблизительное агрегирование

2.1 Обзор

• Распределенные алгоритмы могут выбрать только трех факторную модель при удовлетворении двух: точных, в режиме реального времени, большие данные
• ea выбирает большие данные и режим реального времени. Дает точные, но не на 100% точные результаты за счет небольшой ошибки оценки в обмен на высокую эффективность выполнения и минимальное потребление памяти.
• Два алгоритма аппроксимации: кардинальность, процентили

2.2 Мера мощности

• sql-подобный отдельный
• приблизительный алгоритм. На основе алгоритма HyperLogLot++ (HLL). HLL сначала выполняет хэш-операцию на входе и получает мощность путем оценки вероятности на основе битов в недостатке хэш-операции.бумага ГНС
• Характеристики алгоритма
  • Настраиваемая точность: параметр precision_threshold (более высокая точность = больше памяти).
  • Диапазон precision_threshold — от 0 до 4000, а память, используемая структурой данных, — это: precision_threshold * 8
  • Если установлено значение 100, это может гарантировать, что ошибка объема данных на уровне миллиона останется в пределах 5%.
  • Очень высокая точность для небольших наборов данных
  • Настраиваемый объем используемой фиксированной памяти
• Оптимизация: Предварительно рассчитайте значение HASH, но узкое место производительности переносится на индекс полимером (вы должны переустановить индекс, добавить поле Hash), и вам нужно определить в соответствии с бизнес-сценой.

2.3 процентили Процентильная мера

• Показывает наблюдаемое значение выполнения в определенном проценте, часто используется для поиска аномалий.
• Также приближенный алгоритм. Использование алгоритма TDigest
• Характеристики алгоритма
  • В случае крайних процентов данные более точны. Например, 1% или 99%. Это определяется структурой данных.
  • Очень точно для небольших наборов данных

3. significant_terms

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

4. Полимерная структура данных

4.1 Doc Values

• Агрегируйте, сортируйте структуры данных, используя значения документов

• Сопоставьте документы с терминами, которые они содержат

  

• Генерируется во время индекса и инвертируется индексом одновременно. Сегментный и неизменяемый.

• Данные значений Doc хранятся на диске, не управляются jvm.

• Благодаря столбцовому хранилищу данные аккуратно упорядочиваются для удобства сжатия.

• Анализируемые поля не поддерживаются

• За исключением проанализированных строк, все поля имеют значения doc по умолчанию. Если вы никогда не будете агрегировать или сортировать некоторые поля, вы можете отключить значения документа. Может сэкономить место на диске и скорость индексации

4.2 Fielddata

• Проанализированная строка с использованием структуры данных Fielddata для поддержки агрегации, fielddata хранится в куче памяти, fielddata используется, когда в старой версии нет значений документа
• Процесс anaylzed потребляет много памяти и генерирует много токенов, что очень недружественно к агрегации.
• fieldata останется в памяти до тех пор, пока не будет вытеснено или произойдет сбой узла. Обратите внимание на его размер.
• dielddata не существует при индексировании, он создается при запросе
• index.fielddata.cache.size: процент или фактический размер. Управляет объемом кучи, выделенным для данных полей. Каждый раз, когда выполняется запрос агрегации, поле анализа будет загружаться в Fielddata.Если размер fielddata в результате запроса превышает указанный размер, другие значения будут восстановлены, чтобы получить место.
• Если для хранения полевых данных в памяти недостаточно места, Elasticsearch будет время от времени перезагружать данные с диска и освобождать другие данные, чтобы освободить место. Механизм высвобождения памяти приводит к интенсивному дисковому вводу-выводу и создает много мусора в памяти, который необходимо высвобождать позже.
• Мониторинг filddata: GET /_stats/fielddata?fields=*

5. Оптимизация агрегации

• Вложенные запросы агрегации для больших объемов данных крайне неэффективны. Метод запроса по умолчанию — поиск в глубину.
• Вы можете использовать алгоритм в ширину для обработки случаев, когда количество агрегатов намного меньше, чем общее количество групп. Параметр collect_mode: width_first

7. Географическое положение

1. Установите тип поля на географическое положение

Географические точки координат не могут быть обнаружены по полям динамического отображения, а соответствующий тип поля (параметр типа) должен быть явно объявлен как Geo_Point

2. формат гео_точки

• Строка: "40,715, -74,011", сначала размер, потом точность.
• Массив: [40,715, -74,011], сначала размерность, потом точность
• Объект: {"широта": 40.715, "долгота": -74.011}

3. Метод фильтрации

• geo_bounding_box :: координаты точек, которые попадают в указанный прямоугольный блок
• geo_distance :: к точкам на заданном расстоянии
• geo_distance_range :: точки в пределах диапазона расстояний
• geo_polygon :: точки, попадающие в полигон

4. Будьте осторожны

• Фильтр геокоординат дорог в использовании, он загружает информацию о геолокации всех документов в память, а затем вычисляет ее. Используйте с осторожностью или поместите его в конец фильтра
• Логический фильтр по умолчанию сортирует географическую информацию в последнюю очередь.
• По умолчанию не кэшируется
• Для каждой комбинации широты и долготы требуется своя память 16, формат сжатия может быть предоставлен для снижения точности и уменьшения объема памяти.
• Разумно установите точность: два параметра geohash_prefix и geohash_precision. В сочетании с геохеш-фильтром для эффективного запроса

5. geohash

• Разделите мир на 4*8=32 единицы, каждая из которых обозначается буквой или цифрой. Эти единицы далее разбиваются на 32 более мелкие единицы, которые повторяются.
• Чем больше длина, тем выше точность
• Геохэш с одинаковым префиксом, локация близка, чем длиннее общий префикс, тем ближе расстояние
• Также возможно, что в соседней позиции геохеш совсем другой.

6. Геоагрегация

• Агрегация расстояний geo_distance: сгруппируйте документы по кругу с указанным центром хранения в качестве центра
• Агрегация сетки geohash_grid: группировка документов по ячейкам геохэша для отображения на карте
• geo_bounds: Агрегация границ: прямоугольник, содержащий координатные точки

7. Геоформа (geo_shape)

• Географические фигуры рисуются с помощью единиц геохеширования.

8. Моделирование данных

1. Отношения

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

2. Вложенные объекты

дизайн

внутренняя память

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

Запрос

Используйте специальный вложенный запрос или вложенный фильтр

Сортировать

3. Отношения отца и сына

принцип

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

Преимущество

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

недостаток

• Запрос в 5-10 раз медленнее, чем вложенные типы
• Не подходит для многих родительских документов

Спроектируйте детско-родительские отношения

• Указывает, что тип документа является родительским для другого типа документа.
• Когда вы создаете родительский документ, и документ не различает обычные
• При создании дочернего документа идентификатор родительского документа должен быть указан через parent. Роль заключается в создании отношения ассоциации и обеспечении того, чтобы оно было назначено одному и тому же осколку (используя идентификатор родительского документа для вычисления хэша).
• Используйте отношения родитель-потомок как можно реже, только когда родительских документов мало.

4. Дизайн расширения

Идеи расширения

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

Настройка номера шарда

• Предполагаемый общий объем данных на основе существующего объема данных и регулярного роста
• На основе существующей информации об оборудовании установите один сегмент, 0 копий, и найдите максимальное количество документов, которые может поддерживать один сегмент при текущих аппаратных условиях.
• Количество осколков можно приблизительно оценить, используя общее/максимальное количество отдельных осколков.

Оптимизация сценария потока данных времени

• Разделить индекс по времени
• Старые данные не будут изменены, используйте API оптимизации для объединения сегментов.

• Большинство индексов содержат от 50 до 150 сегментов, даже если они содержат миллиарды документов размером в терабайт. Большое количество сегментов указывает на проблему со слиянием (например, слияние не поспевает за созданием сегментов)
• Однако слияние сегментов потребляет все ресурсы ввода-вывода на вашем узле, что может привести к зависанию кластера. Если вы хотите выполнить по индексуoptimize, вам нужно переместить индекс на безопасный узел перед его выполнением.
• Чтобы не влиять на нормальную индексацию, фон слияния сегментов ограничивает скорость чтения и записи диска до 20 МБ/с, которую можно регулировать в зависимости от реальной ситуации, например, для SSD-дисков параметр index.store.throttle. макс_байт_в_сек. Даже когда запроса нет, установите для него значение none, то есть ограничения нет, а затем измените его обратно после слияния.
• Кроме того, было бы плохой идеей оптимизировать индекс, который все еще записывает данные, потому что оптимизация будет потреблять много операций ввода-вывода на узле и затрагивать существующие индексы.
• Мы можем временно удалить осколки реплик, оптимизировать, а затем восстановить осколки реплик.
• Перед удалением копии вы можете сделать резервную копию данных через API восстановления моментальных снимков.

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

Сценарии потока данных на основе пользователей

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

9. Управление, мониторинг

1. Конфигурация важных параметров

• cluster.name
• node.name
• path.data
• path.logs
• path.plugins
• discovery.zen.minum_master_nodes: минимальное количество мастер-нод для предотвращения разделения мозга (несколько мастер-нод)
• Discover.zen.ping.unicast.hosts: список одноадресных рассылок кластера
• gateway.recover_after_nodes по крайней мере, сколько узлов может быть доступно кластеру
• gateway.expected_node сколько узлов ожидает кластер
• gateway.recover_fater_time сколько ждать восстановления данных
• уровень журнала logger.discovery
• index.search.slowlog.threshold.query.warn : медленный запрос «10s» и журнал предупреждений вывода 10s
• index.search.slowlog.threshold.fetch.debug: «500 мс» медленный запрос и 500 мс выходной журнал отладки
• index.indexing.slowlog.threshold.index.info: "5s запрашивает медленный и 5s выводит информационный журнал
• Index.unassigned.node_left.delayed_timeout измененное время задержки задержки
• Cluster.routing.allocation.enable»: «Нет» отключена раздача

2. Не изменяйте конфигурацию

• Не меняйте сборщик мусора, используйте CMS по умолчанию. Не заменять новым поколением G1
• Количество потоков, по умолчанию — количество ядер процессора. Операции ввода-вывода выполняются потоками Lucene, а не es.

3. Конфигурация кучи памяти

• По умолчанию используется 1G, необходимо изменить фактическую производственную среду.
• Чтобы обеспечить XMS и XMX, предотвратите размер памяти стека во время выполнения, который потребляет ресурсы.
• Слайс памяти не должен превышать половину собственной памяти. Потому что самой Lucene тоже нужны память и кеш.
• Если вам не нужно выполнять операции агрегирования при сегментации слов, память кучи можно уменьшить. Чем меньше память кучи, тем выше производительность Elasticsearch (быстрее GC) и Lucene (больше памяти для кэширования).
• Память не должна превышать 32G. Чем длиннее указатель на каждый объект, тем больше используется пропускная способность памяти ЦП, а это означает, что вы фактически теряете больше памяти. Если вы хотите сохранить его в целости и сохранности, установите для кучи значение 31 ГБ.
• Если памяти много, вы можете рассмотреть возможность выделения нескольких экземпляров es для машины, но общий объем памяти кучи не должен превышать половины. Также настройте cluster.routing.allocation.same_shard.host: true. Предотвращение того, чтобы один и тот же сегмент (первичный и вторичный) находился на одном компьютере.
• Установите bootstrap.mlockall: true, чтобы заблокировать память и предотвратить подкачку памяти.

4. ЭиТО и оптимизация

• Файлы журналов по умолчанию хранятся в файле журналов в каталоге установки. "logger.discovery": "DEBUG" может установить уровень журнала.
• Вы можете установить вывод журнала медленных запросов
• Если точность в реальном времени не требуется, измените index.refresh_interval на 30 с и установите это значение равным -1 при заливке в больших количествах и установите его обратно после завершения заливки.
• При заливке в больших количествах index.number_of_replicas устанавливается в 0, а реплика закрывается для повышения эффективности.
• Попробуйте использовать идентификатор, автоматически сгенерированный es, чтобы поиск версий не влиял на эффективность. Если вы используете свой собственный идентификатор, используйте тот, у которого хорошая производительность сжатия, и избегайте использования слишком случайного идентификатора.
• Отложенное сегментирование: предотвращает массовые проблемы с миграцией данных, вызванные отключением узлов и последующим перезапуском. Потому что данные на автономном узле могут быть полностью удалены из-за сбоя, а затем повторно реплицированы. Параметр index.unassigned.node_left.delayed_timeout.

5. Повторный перезапуск

• Обновляйте или обслуживайте каждый узел один за другим, обеспечивая непрерывную работу кластера.
• Сначала прекратите индексировать новые данные
• Размещение шардов запрещено. cluster.routing.allocation.enable" : "нет"
• Выключите один узел и выполните обслуживание обновления
• Запустите узел и дождитесь присоединения к кластеру
• Перезапустите распределение осколков. cluster.routing.allocation.enable" : "все"
• Повторите вышеуказанные шаги для других узлов.
• Восстановление данных обновления индекса