Снижение затрат на поисковые операции как никогда актуально. Оптимизация системы Elasticsearch может привести к значительной экономии расходов на оборудование.
Как снизить затраты в Elasticsearch
Планирование хранения данных
Тщательно настройте ILM и переместите старые данные в холодное/замороженное хранилище, чтобы уменьшить объем данных, хранящихся на дорогих "горячих" узлах, и использовать более дешевое хранилище для редко используемых данных. Это поможет сократить расходы на оборудование и особенно полезно для журналов и данных временных рядов.
Пропуск уровней данных, например, переход непосредственно с горячего на холодный или с горячего на моментальный снимок, также может быть эффективной стратегией снижения стоимости работы Elasticsearch.
Одновременное наличие горячего, теплого и холодного уровней может оказаться слишком большим, поскольку данные должны перемещаться между всеми уровнями. Граница между "теплым" и "холодным" уровнями очень узкая, и если не используются снимки с возможностью поиска, то обычно не стоит иметь "холодный" уровень, если только он действительно не использует более дешевое оборудование. Это не так, например, в Elastic cloud, где холодные узлы имеют те же характеристики, что и теплые.
Кроме того, при использовании горячих узлов они не обязательно должны быть самыми дорогими из имеющегося оборудования. Хотя новейшее и наиболее совершенное оборудование работает быстрее, можно продолжать использовать обычные SSD, если они достаточно хороши для выполнения SLA по вводу/поиску.
Старайтесь придерживаться последних версий Elasticsearch
Каждая новая версия содержит оптимизации, которые могут помочь снизить затраты. Обновление до новой версии может обеспечить различные улучшения производительности, исправление ошибок и новые возможности, которые позволяют повысить производительность кластера и снизить требования к аппаратному обеспечению. Это, в свою очередь, позволяет снизить затраты на эксплуатацию кластера за счет отсутствия необходимости инвестировать в дополнительное оборудование и сокращения времени на обслуживание и устранение неисправностей.
Оптимизация отображений и шаблонов индексов
Оптимизация отображений и шаблонов индексов позволяет уменьшить объем хранимых и индексируемых данных, что способствует снижению требований к хранению данных и соответствующих затрат. Например, можно отказаться от индексирования и хранения ненужных полей, удалить сложные анализаторы, чтобы максимально упростить индексирование, и использовать ключевые слова вместо полнотекстового поиска, где это возможно. Кроме того, отказавшись от хранения поля _source, можно еще больше снизить требования и затраты на хранение.
Денормализация данных
Денормализация данных в Elasticsearch может повлиять на стоимость работы кластера за счет снижения сложности отношений между данными и повышения производительности запросов. В частности, следует избегать родительских и вложенных отношений, которые создают сложные структуры данных.
Денормализация предполагает хранение избыточных данных в нескольких документах, чтобы избежать сложных отношений между документами. Это позволяет повысить производительность запросов за счет сокращения количества запросов, необходимых для получения данных, и исключения дорогостоящих операций объединения.
Кроме того, обращение к Elasticsearch как к реляционной базе данных может создать излишнюю сложность и потребовать больше ресурсов для выполнения запросов. Elasticsearch разработан как распределенная поисковая система, и его производительность и масштабируемость выигрывает от документоориентированного подхода, позволяющего избежать использования сложных связей между документами.
Оптимизация запросов
Отказ от определенных действий в Elasticsearch, таких как вложенные запросы и вложенные агрегации, просмотр слишком большого количества данных и выполнение агрегаций по нерелевантным данным, может повлиять на стоимость работы кластера за счет снижения количества ресурсов CPU/RAM, необходимых для выполнения запросов.
Оптимизация размера хранилища
Оптимизация размера хранилища в Elasticsearch может повлиять на стоимость работы кластера за счет повышения скорости выполнения запросов и индексирования и предотвращения образования "горячих точек" в кластере. Размер хранилища должен находиться в пределах 10-50 ГБ. Слишком большие или слишком маленькие шарды могут создавать "горячие точки" в кластере, заставляя некоторые узлы работать интенсивнее, чем другие. Это может снизить скорость выполнения запросов и индексирования, что приведет к необходимости добавления дополнительных узлов в кластер. Однако это временное решение, которое приводит к дополнительным затратам.
Для минимизации затрат и использования возможностей распределенной системы размеры шардов могут быть оптимизированы.
Мониторинг использования ресурсов и соответствующая настройка оборудования
Снизить затраты можно, обеспечив эффективное использование ресурсов и избежав лишних расходов на аппаратное обеспечение. Например, если вы заметили, что некоторые узлы постоянно простаивают или недостаточно используются, вы можете сократить аппаратные ресурсы для этих узлов без ущерба для производительности. Убедитесь, что загрузка дисков эффективна (не пуста, но и не слишком заполнена), что процессоры и загрузка кластера показывают, что узлы работают, и т.д. Если кластер используется недостаточно эффективно, можно уменьшить аппаратные ресурсы узлов или удалить некоторые узлы.
Удаление неиспользуемых типов узлов
Удаление неиспользуемых типов узлов в Elasticsearch может повлиять на стоимость работы кластера за счет сокращения количества необходимых узлов и соответствующих аппаратных затрат. Не для каждого случая использования требуется отдельный мастер-узел, ML-узел и т.д.
Клиентские узлы, т.е. `ingest` и `coordinating`, используются слишком часто и очень часто не нужны. Роль "ingest" предназначена для тяжелых случаев ингестирования, когда пользователи используют конвейеры `ingest` вместо Logstash. В остальном каждый узел является `координирующим` узлом. Единственный случай, когда могут потребоваться выделенные координирующие узлы, - это случаи использования с тяжелыми вложенными агрегациями ведер, но даже в этом случае это обычно не является проблемой.
Базовый кластер из 3 узлов должен стать для всех отправной точкой для HA, но все роли должны быть разделены до тех пор, пока не возникнет необходимость в разделении.
Следите за соотношением удаленных документов
Использование принудительного слияния с удалением в Elasticsearch может помочь уменьшить размер индекса, что означает, что для хранения данных потребуется меньше дискового пространства, а это, в свою очередь, может снизить стоимость работы кластера. В конечном итоге это может позволить сократить количество узлов данных, если это не повлияет на надежность и доступность данных.
Минимизация межузловых взаимодействий
Межузловая связь - это процесс обмена данными между узлами в кластере Elasticsearch. Такой обмен данными важен для обеспечения согласованности и надежности данных кластера. Однако чрезмерное количество межузловых взаимодействий может привести к увеличению сетевого трафика, потенциальным проблемам с производительностью и увеличению затрат на передачу данных.
Эти затраты могут варьироваться в зависимости от используемого облачного провайдера или хостинга, объема передаваемых данных и места их передачи.
Чтобы минимизировать межузловое взаимодействие и снизить затраты на передачу данных в Elasticsearch, можно перейти к развертыванию в одной зоне доступности (Single-AZ) - если позволяет соответствие нормативным требованиям и имеется возможность использовать различные процессы восстановления данных, развертывание Elasticsearch в одной зоне доступности может помочь снизить межузловое взаимодействие и затраты на передачу данных. Это также возможно, если ваш кластер не является критически важным.
Обобщение старых данных
Rollup API в Elasticsearch позволяют обобщать большие объемы данных и хранить их в более компактном виде. Складывая данные в один сводный документ, можно уменьшить объем памяти, необходимый для хранения данных. Это позволяет освободить дисковое пространство, снизить требования к аппаратному обеспечению и уменьшить сопутствующие расходы на эксплуатацию кластера.
Общение старых данных также позволяет повысить производительность запросов за счет уменьшения объема данных, по которым необходимо выполнять поиск. Поскольку свернутые данные представляют собой краткое изложение информации, запросы к ним выполняются быстрее, чем к исходным данным, что позволяет увеличить время отклика на запрос и снизить требования к аппаратному обеспечению.
После обобщения и сворачивания данных можно архивировать или удалять исходные данные, чтобы освободить место для хранения и снизить затраты. Это может быть особенно полезно для данных временных рядов, когда старые данные могут быть больше не нужны для анализа или отчетности.
Обращайтесь за долгосрочными скидками
Поставщики облачных хранилищ часто предлагают долгосрочные скидки для клиентов, заключивших длительные контракты. Заключение долгосрочных контрактов позволяет получить значительные скидки и зафиксировать более низкие тарифы, что снижает общую стоимость услуг облачного хранения данных. Это может быть особенно полезно для тех клиентов, которые нуждаются в облачных хранилищах в течение длительного времени и уверены в своем поставщике.