Оптимизация API для сокращения сегментов и устранения неработающих удаленных документов ES

Question

Это продолжение моего предыдущего вопроса Влияет ли огромное количество удаленных * c на производительность запроса ES * , связанных с удаленными документами в моем индексе ES.

Как указано в ответ, я использовал optimize API , так как я использую версию ES 1.X, где API принудительного слияния недоступен, но после прочтения о ссылке оптимизации github API (предоставленной ранее, поскольку не удалось найти его на сайте ES) Сэй Бэннон (Say Bannon), основатель elasti c, похоже, делает то же самое.

Я получил сообщение об успешном завершении индекса после запуска API оптимизации, но я не вижу общее количество удаленных документов уменьшается, и я обеспокоен тем, что когда я проверял сегменты моего индекса с помощью сегментов API , я вижу, что для каждого шарда имеется более 25 сегментов, и каждый шард содержит 250-1 ГБ данные в памяти и почти 500 тыс. документов, в то время как я вижу, что есть несколько осколков, где мало удаленных документов.

Итак, мой вопрос:

1. Мой индекс имеет m ультипульные осколки по нескольким узлам данных, и когда я запустил оптимизацию API, используя только URL-адрес одного узла, он объединяет только сегменты на этом узле? в то время как я использую плагин KOPF и имею собственные имена для своих узлов данных, как я могу связать это имя узла crypti c с моим читаемым человеком именем узла, чтобы определить, является ли утверждение 1 правильным или нет?
2. Как Документация по API оптимизации недоступна. Возможно ли объединить сегменты всех сегментов всех узлов за один раз? и нужно ли делать индекс доступным только для чтения перед его применением?

Answer 1

@ Нирмал ответил на ваши первые два вопроса, поэтому:

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

Есть документация, доступная для 1.x: https://www.elastic.co/guide/en/elasticsearch/reference/1.7/indices-optimize.html. Вероятно, вы ищете такие вызовы:

• GET <index_pattern>/_cat/segments: список всех сегментов во всех сегментах (может быть тысяч). Также перечислены удаленные документы.
• POST <index_pattern>/_optimize?max_num_segments=1: принудительное объединение всех сегментов в 1 отдельный сегмент на шард. Делайте это, когда индекс больше не записывается в. Это помогает снизить нагрузку на ЦП / ОЗУ на узлах данных.
• POST <index_pattern>/_optimize?only_expunge_deletes=true: удалять только удаленные документы

Наконец, вы можете использовать * как <index_pattern> для просто делайте все индексы на всем кластере.

Answer 2

1. Объединяет сегмент на основе состояния, размера и других параметров сегмента, а также объединяет сегменты всех сегментов индекса. Похоже, что в вашем примере у вас есть огромное количество сегментов, которые не подобраны, оптимизируют API, что заставляет вас думать, что слияние работает с осколком конкретного узла. Вы можете задать дополнительный запрос param max_num_segments = {желаемое количество сегментов} и увидеть, что он должен уменьшить сегменты сегмента до указанного числа.
2. Идентификатор узла, который вы можете найти, используя API с http: //: 9200 / _cat / node? v & h = id, ip, name, выводит в следующем формате

id ip name
SEax 10.10.10.94 foo
f2hs 10.10.10.95 bar

Here ids in the first column are what you are seeing as cryptic in the segment  
API response, its not completed in above API but initial four character are 
unique and you can find them in segment API result.

Да, можно объединить сегменты на всех сегментах по всем узлам за один раз. Как упоминалось в моем первом пункте, просто упомяните {желаемое количество сегментов} как 1. Кроме того, рекомендуется сделать индекс доступным для чтения. только чтобы избежать удаления удаленных документов в огромных сегментах, ie более 5 ГБ, которые никогда не собираются оптимизировать API, и эти удаленные документы никогда не будут очищены, как объяснено в https://www.elastic.co/guide/en/elasticsearch/reference/6.8/indices-forcemerge.html. Если ваш общий размер индекса невелик, и вы уверены, что размер 1 сегмента никогда не будет превышать 5 ГБ, нет необходимости переводить индекс в режим только для чтения, если вы согласны с некоторым снижением производительности, поскольку объединение сегментов является дорогостоящей операцией. Но когда-нибудь остановить live traffi c (индексирование) не вариант, поэтому советую выполнять его при минимальной нагрузке в кластере.

Answer 3

вызов force_merge или optimize применяется ко всему индексу, вам не нужно делать это на уровне узла.

Вы можете использовать _cat api , чтобы узнать nodeid: отображение Ip. В случае ваша версия не поддерживает _cat api (<1.0), <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-state.html" rel="nofollow noreferrer"> использовать состояние кластера api