Elasticsearch - общая архитектура и вопросы об Elastic Cloud

Question

Фон

Сейчас мы разрабатываем архитектуру новой системы с использованием Elasticsearch, и мы планируем использовать Elastic Cloud на основе обзоров, сравнивающих их сервис с AWS, и самостоятельного размещения на экземпляре EC2. При разработке системы я пытаюсь извлечь уроки из небольшого тестового проекта, который моя команда развернула на Elastic Cloud 6 месяцев назад. Хотя я потратил много времени на чтение документов Elasticsearch , Elasticsearch: полное руководство и Документы Elastic Cloud , здесь есть некоторые концепции, которые я Я все еще не понимаю.

Проблемы нашего тестового проекта

В нашем тестовом проекте по умолчанию используется 5 основных сегментов и 1 фрагмент реплики на каждый основной. Он был настроен с использованием параметров развертывания по умолчанию в Elastic Cloud с одним узлом, в настоящее время с 2 ГБ памяти. Поскольку существует только один узел, и поскольку осколки реплики никогда не назначаются тому же узлу, что и их основной осколок ( причина 2 ), ни одна из реплик не назначается. Кроме того, этот проект использует основанные на времени данные и создает один индекс на учетную запись в день, в результате чего получается около 10 индексов в день (или 100 шардов), а со временем пресловутые кагиллионные осколки . Предполагалось, что эта система будет иметь только несколько месяцев данных за один раз, поэтому решение состоит в том, чтобы вручную удалять старые данные, когда память в этом развертывании заканчивается.

Новая система

Предполагается, что наша новая система будет иметь данные за 5 лет, которые, как ожидается, увеличатся до 250 ГБ. Текущая реализация использует один индекс для данных, основанных на времени, с 6 основными сегментами и 1 репликой на основной. Это решение было принято исходя из того, что один осколок должен иметь размер не более 30 ГБ.

Вопросы

1. В нашей старой системе был один узел со слишком большим количеством индексов (более 100) и слишком большим количеством шардов (более 1000), и, похоже, наша новая система разрабатывается со слишком малым числом (один индекс для данных за 5+ лет). Кажется, лучшая стратегия индексации в соответствии с данными, основанными на времени рекомендации будет заключаться в создании одного индекса в неделю или месяц? Тем не менее, согласно другому ответу на SO оптимальное количество индексов на узел равно 1, так что в чем заключается полезность при создании нескольких индексов для данных, основанных на времени, в первую очередь, если мы только выполняем на одном узле?
2. Как добавить узел в развертывание ES в Elastic Cloud? В настоящее время все узлы реплики в тестовом проекте не назначены, поскольку развертывание имеет только один узел. Есть ползунок, который позволяет вам легко выбирать память каждого узла в развертывании (от 1 ГБ до 250 ББ), однако я не вижу способа добавить несколько узлов, что сбивает с толку, потому что это похоже на базовую функциональность Elasticsearch.
3. Узел нашего тестового проекта перезагружался несколько раз, всегда, когда на узле много старых данных и, следовательно, нехватка памяти. Решение состояло в том, чтобы удалить старые данные (так как тестовый проект должен был иметь только несколько месяцев данных одновременно), но, похоже, узел не потерял данные при перезапуске. С чего бы это?
4. Наш тестовый проект не сделал снимков, которые должны автоматически выполняться в Elastic Cloud каждые 30 минут. Я спросил их поддержку об этом, но просто любопытно узнать, знает ли кто-нибудь, что может вызвать это и как решить эту проблему?

Answer 1

В нашем тестовом проекте по умолчанию используется 5 основных сегментов и 1 фрагмент реплики на основной.Он был настроен с использованием параметров развертывания по умолчанию в Elastic Cloud с одним узлом

Очевидно, что на одном узле нельзя иметь реплики.Таким образом, ваш индекс должен был быть настроен с 0 репликами, и вы можете сделать это динамически, чтобы вернуть кластеру зеленый (PUT index/_settings {"index.number_of_replicas": 0}), просто так.

Кроме того, этот проект использует данные, основанные на времени, и создает один индекс для каждой учетной записи в день, в результате чего получается около 10 индексов в день (или 100 шардов)

Я не могу сказать, было ли разумным 50 новых первичных сегментов (10 индексов) в день, потому что вы не предоставляете никакой информации относительно объема данных в вашем тестовом проекте.Но, вероятно, их слишком много.

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

Совершенно возможно иметь данные за пять лет в одном индексе, это зависит не от того, сколько лет данным, а от того, насколько они велики.Вы упомянули 250 ГБ, а также знаете, что размер сегмента не должен превышать 30 ГБ (и это опять-таки зависит от характеристик вашего оборудования, подробнее об этом позже), но поскольку у вас есть только 6 сегментов для этого индекса, это означает, что каждыйshard увеличится более чем на 40 ГБ (что в соответствии с this ), но, чтобы быть в безопасности, вам, вероятно, следует увеличить до 8-9 сегментов, или вы разделите свои данные на годовые / месячные индексы.

Ограничение 30ГБ на шард также зависит от объема кучи, которую имеют ваши узлы.Если у вас есть узлы с кучей 2 ГБ, то шарды размером 30 ГБ явно слишком велики.Поскольку вы работаете в ES Cloud и планируете иметь 250 ГБ данных, вы должны выбрать емкость узла 16 ГБ кучи + 384 ГБ хранилища (или больше).Таким образом, с кучей 16 ГБ, разумно иметь 30 ГБ, но, на мой взгляд, вам понадобится несколько узлов.Вы можете проверить, сколько у вас узлов, используя GET _cat/nodes?v.

1. При этом, согласно другому ответу на SO, оптимальное количество индексов на узел составляет 1 ...

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

1. ... так в чем же смысл создавать несколько индексов для временных данных, если мы работаем только на одном узле?

Сначала проверьте, сколько узлов у вас в кластере, используя GET _cat/nodes?v, но четко, если вам назначен один узел для 250 ГБ данных, разделенных на 6-8 сегментов, одинузел не идеален, действительно.

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

Прямо сейчас вы не можете.Однако на последней конференции Elastic {ON} Elastic объявил , что можно будет выбрать количество узлов или тип развертывания (горячий / горячий и т. Д.), Который вы хотите настроить.

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

Вам не нужны реплики в тестовом проекте, верно?

Решение состояло в том, чтобы удалить старые данные (так как тестовый проект должен был иметь только несколько месяцев данных одновременно), но, похоже, узел не потерял данные при перезапуске.Почему это так?

Как вы удалили данные?С момента, когда вы удалили данные, и до перезапуска узла, вы были свидетелем того, что данные действительно исчезли?

Наш тестовый проект не сделал снимков, которые должны автоматически выполняться в Elastic Cloud каждые 30 минут.

Это странно, поскольку в облаке ES ваш кластер обычно снимается каждые 30 минут. Что вы видите в разделе Развертывания> идентификатор кластера> Elasticsearch> Снимки? Что говорит об этом поддержка ES Cloud? Что вы получаете при запуске GET _cat/repositories?v и GET _cat/snapshots/found-snapshots?v? (обновите ваш вопрос с результатами)