Мы начнем работать с передовыми практиками, которым следует следовать с Elasticsearch, и какие проблемы он может создать, если мы избегаем эти точки. Приступим.
Всегда определяйте сопоставления ES
Одна вещь, которую ES точно может сделать, — это работать без сопоставлений. Итак, когда вы начнете вводить данные JSON в свой индекс ES, он будет перебирать поля данных и создавать подходящее сопоставление. Это кажется прямым и простым, поскольку ES выбирает тип данных сам. Исходя из ваших данных, вам может потребоваться, чтобы поле было определенного типа данных.
Например, предположим, что вы индексируете следующий документ:
«id»: 1,
«title»: «Установить ElasticSearch в Ubuntu»,
«link»: «https://linuxhint.com/install-elasticsearch -ubuntu/»,
» date «:» 2018-03-25 «
}
Таким образом, Elasticsearch отметит« дату » поле типа «дата». Но когда вы индексируете следующий документ:
«id»: 1,
«title»: «Рекомендации и производительность ES» ,
«date»: «Pending»
}
На этот раз тип поля даты был изменен, и ES выдаст ошибку и не позволит проиндексировать ваш документ. Чтобы упростить задачу, вы можете проиндексировать несколько документов, посмотреть, какие поля проиндексированы ES, и получить сопоставление с этого URL-адреса:
Таким образом, вам также не придется создавать полное отображение.
Флаги производства
Кластер по умолчанию имя, которое запускает ES, называется elasticsearch . Когда у вас много узлов в кластере, рекомендуется поддерживать как можно более согласованные флаги именования, например:
node.name: app_es_node_001
Помимо этого, настройки восстановления для узлов также имеют большое значение. Предположим, что некоторые узлы в кластере перезапускаются из-за сбоя, а некоторые узлы перезапускаются немного позже других узлов. Чтобы сохранить согласованность данных между всеми этими узлами, нам нужно будет запустить программу согласования, которая будет поддерживать все кластеры в согласованном состоянии.
Также полезно заранее сообщить кластеру, сколько узлов будет присутствовать в кластере и сколько времени им потребуется для восстановления:
gateway.recover_after_time: 7m
При правильной конфигурации восстановление, которое заняло бы часы, может занять всего минуту и можно сэкономить много денег любой компании.
Обеспечение емкости
Важно знать, сколько места будут занимать ваши данные и с какой скоростью они поступают в Elasticsearch, потому что от этого зависит объем оперативной памяти. вам понадобится и на каждом из узлов кластера, и на главном узле.
Конечно, нет никаких конкретных рекомендаций для достижения необходимых чисел, но мы можем предпринять некоторые шаги, которые предоставят нам хорошая идея. Одним из шагов будет имитация варианта использования. Создайте кластер ES и загрузите в него данные почти с той же скоростью, которую вы ожидаете от своей производственной установки. Концепция начать с большого и уменьшить также может помочь вам быть последовательным в том, сколько места требуется.
Большие шаблоны
Когда вы определяете индексированные большие шаблоны, вы всегда будете сталкиваться с проблемами, связанными с синхронизацией шаблона между вашими различными узлами кластера. Всегда помните, что шаблон придется переопределять всякий раз, когда происходит изменение модели данных. Гораздо лучше сохранить шаблоны как динамические . Динамические шаблоны автоматически обновляют сопоставления полей на основе сопоставлений, которые мы определили ранее, и новых полей. Обратите внимание, что ничто не может заменить шаблоны как можно меньшего размера.
2Использование mlockall на серверах Ubuntu
Linux использует процесс подкачки, когда ему требуется память для новых страниц. Своппинг замедляет работу, поскольку диски медленнее, чем память. Свойство mlockall в конфигурации ES указывает ES не выгружать свои страницы из памяти, даже если они сейчас не требуются. Это свойство можно установить в файле YAML:
В версиях ES v5.x +, это свойство изменено на:
Если вы используете это свойство, просто убедитесь, что вы предоставляете ES с достаточно большой памятью кучи, используя параметр или ES_HEAP_SIZE .
Минимизация обновлений сопоставления
Производительность кластера незначительно снижается всякий раз, когда вы делаете запросы на обновление сопоставления в кластере ES. Если вы не можете контролировать это и по-прежнему хотите обновлять сопоставления, вы можете использовать свойство в файле конфигурации ES YAML:
Когда запрос обновления модели находится в очереди ожидания для главного узла и отправляет данные со старым отображением на узлы, он также должен позже отправить запрос на обновление всем узлам. Это может замедлить работу. Когда мы устанавливаем для вышеуказанного свойства значение false, это дает основную информацию о том, что было выполнено обновление сопоставления, и оно не отправляет запрос на обновление узлам. Обратите внимание, что это полезно только в том случае, если вы регулярно вносите много изменений в свои сопоставления.
Оптимизированный пул потоков
Узлы ES имеют много пулов потоков для улучшения как потоки управляются внутри узла. Но есть ограничения на то, сколько данных может обрабатывать каждый поток. Чтобы отслеживать это значение, мы можем использовать свойство ES:
Это информирует ES — количество запросов в осколке, которые могут быть поставлены в очередь для выполнения на узле, когда нет потока, доступного для обработки запроса. Если количество задач превышает это значение, вы получите RemoteTransportException . Чем выше это значение, тем больший объем кучи потребуется на вашем узловом компьютере, а также будет использоваться куча JVM. Кроме того, вы должны держать свой код готовым на случай возникновения этого исключения.
Заключение
В этом уроке мы рассмотрели, как мы можем улучшить производительность Elasticsearch, избегая распространенных и не очень распространенные ошибки, которые совершают люди. Прочтите больше статей об Elasticsearch на LinuxHint.
