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

Question

Фон

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

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

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

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

Предполагается, что наша новая система будет иметь данные за 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 ГБ (что, в соответствии с этим, нормально), но, чтобы быть в безопасности, вам, вероятно, следует увеличить до 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 сегментов, то один узел на самом деле не идеален.

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

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

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

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

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

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

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

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