Кратко

  • В Atlas Core с отдельными Search Nodes пауза удаляет данные этих узлов. При возобновлении создаются новые узлы и индексы; во время перестроения $search и $vectorSearch недоступны.
  • Метрики поиска, накопленные до паузы, не сохраняются. Для сравнения покупателю нужны собственные записи, сделанные заранее.
  • Приостановленный кластер оплачивает только хранение. Выгода зависит также от частоты перезапусков, подготовки к работе и фактического счёта за ресурсы.

Возобновить — глагол с дополнительной работой

У кнопки паузы удобная репутация. Нажал, сэкономил, вернулся к прежнему занятию. В MongoDB Atlas за этим коротким сюжетом может стоять повторная сборка поиска. Данные есть где хранить; механизм, который помогает их находить, предстоит приготовить заново.

Документация MongoDB описывает конкретную конфигурацию: Atlas Core с отдельно развёрнутыми Search Nodes. При паузе данные поисковых узлов удаляются. После возобновления платформа создаёт новые узлы и перестраивает индексы. Пока идёт перестроение, стадии $search и $vectorSearch недоступны. В публичной предварительной версии Atlas Infinite такие узлы не поддерживаются; речь здесь идёт о Core.

Автоматическое восстановление поискового хозяйства снимает с клиента работу по его сборке. Оно всё же оставляет клиенту календарь. Пользователи приходят к назначенному часу, а не к тому моменту, когда инженеру удобно объявить очередной этап готовым.

Представим показ каталога товаров как сценарий для закупки. Соединение с базой установлено, приложение открывается, но индекс ещё строится. Проверяющий соединение видит успешный запуск. Участнику показа нужен результат поиска товара. Если компания считает эти два события одним, пауза получает слишком короткое описание и слишком оптимистичный график возврата.

За сон платят меньше, за готовность отвечают утром

У решения есть настоящая ценовая основа. По правилам стоимости кластера во время паузы Atlas берёт плату только за хранение, включая стандартный объём. Для редко используемой среды разработки возможность убрать постоянную работу вычислительных ресурсов имеет очевидную ценность.

Но простой легко измерить, а подготовку к возобновлению легко раздать другим людям. Один сотрудник показывает сокращённые часы потребления. Другой заранее запускает среду. Третий проверяет индексы, четвёртый — запросы для показа. Компания оплачивает весь этот круг, даже если в отчёт об экономии попала только первая строка.

Поисковые узлы тарифицируются почасово, причём часть часа оплачивается как полный час. На стоимость влияют число узлов, их конфигурация и обмен данными с узлами базы. Поэтому фактический счёт нужно сопоставлять с хронологией возвращения поиска в работу. Тариф описывает ресурсы; из него нельзя вывести отдельное обещание начинать оплату лишь после успешной проверки прикладного запроса.

Одна подготовка после долгого перерыва может удобно помещаться в расписание. Частые короткие паузы превращают её в регулярную обязанность. У среды, которую бронируют под эксперимент, есть запас времени. У среды, которую надо показать по первому звонку, готовность сама по себе составляет часть купленной услуги.

Новый график не помнит старого темпа

Пауза меняет и доказательства, которыми клиент оценивает решение. Согласно описанию метрик поиска, после возобновления доступны только показатели новых поисковых узлов. Метрики до остановки Atlas не сохраняет. У восстановленного сервиса появляется новая наблюдаемая история.

Покупателю полезно заранее зафиксировать собственные контрольные запросы, ожидаемые результаты и время ответа. Вместе с ними нужны условия: объём данных, определения индексов и конфигурация. Если между опытами что-то поменялось, это следует записать. Иначе улучшение от другого набора данных легко торжественно приписать политике остановок.

Собственная запись соединяет три разных взгляда. Финансы видят расходы, эксплуатация — процесс запуска, продуктовая команда — пригодность поиска. Без общей временной линии один отдел предъявляет новый график, а другой вспоминает, как было прежде. Это может быть оживлённое совещание. Проверяемым сравнением оно становится только после появления общего материала.

При обычной замене старый индекс остаётся на посту

MongoDB предусматривает иной порядок для обычного изменения определения индекса. Руководство по управлению индексами говорит, что новый индекс строится в фоне, пока старый продолжает обслуживать запросы. При изменении поисковой топологии новые узлы готовятся до удаления старых. Работающая смена дожидается замены.

Возобновление после паузы начинается уже без данных прежних отдельных поисковых узлов. Обещание непрерывности из процедуры обновления нельзя переносить в этот график. Разделение операций — паузы, смены определения и смены топологии — помогает увидеть, какая способность обслуживать пользователей сохраняется во время перехода.

Проверка тоже может быть точной. Метод getSearchIndexes() возвращает статус и поле queryable, показывающее возможность запросов к индексу. Следом нужен прикладной тест: находит ли поиск нужные записи и укладывается ли ответ в допустимое для работы время? Два этапа дают больше смысла, чем один общий сигнал «всё запущено».

Не хватает клиентских измерений, связывающих длительность перестроения, пригодный поиск и счёт; короткий предсказуемый возврат усилил бы выгоду частых пауз. Сама сделка уже понятна: покупатель снижает потребление в период отдыха, уступает готовое поисковое состояние и получает его автоматическую реконструкцию. Считать экономию следует после того, как реконструкция снова позволяет выполнить обещанную работу.