У меня есть конвейер ETL, который отправляет записи временных рядов в MongoDB.
Мне нужно рассчитать своевременные агрегации для ежедневных, еженедельных и т. П. Я предполагал, что механизм агрегации MongoDB будет подходить, поэтому после того, как у меня были запросы агрегации для каждого разрешения, я обернул их представлениями MongoDB, такими как "daily_view", "weekly_view" и т. Д.
Существует служба REST для извлечения из MongoDB. В зависимости от того, какое разрешение периода запрашивается, оно выбирает из различных вышеупомянутых представлений, выбирая даты начала и окончания.
Время ответа довольно "плохое" для этих представлений / агрегатов. Это может быть около 10-15 секунд. Я полагаю, что этот перерыв не будет возмутительным для пакетной обработки отчета, но в моем случае службе необходимо выдавать эти запросы в режиме реального времени, чтобы обслуживать интерфейс, поэтому 10 секунд ожидания - это слишком много.
Из справки MongoDB я знаю, что Views are computed on demand during read operations, но я немного разочарован таким временем отклика, потому что одни и те же агрегации занимали доли секунды в Elasticsearch или InfluxDB, что, к сожалению, пока не подходит для меня.
Я также исчерпал результаты исследований по оптимизации запросов, и здесь нет места для большего улучшения, чем оно уже есть.
Моя интуиция подсказывает мне, что если агрегации должны выполняться через механизм агрегации, мне нужно, чтобы конвейеры выполнялись непрерывно на лету (чтобы представления имели записи уже для службы), а не запускаться каждый раз, когда Hoc.
Я пытался отбросить представления, и вместо этого есть и агрегация с последним этапом, представляющим собой $ out для реальной коллекции ... но у меня все та же проблема, ее нужно запускать "по требованию". Я скомпоновал конвейеры, используя пользовательский интерфейс Compass, и на этапе $ out он представляет кнопку для запуска агрегации.
Есть ли способ запланировать такие конвейеры / запросы агрегации ??
Я могу подумать о том, чтобы скопировать код агрегатов и превратить его в функции Javascript службы REST ... но, тем не менее, что-то должно вызывать эти функции через регулярные промежутки времени. Я знаю, что есть библиотеки, которые я могу принести в службу для планирования, но эта опция заставляет меня чувствовать себя немного смущенным с точки зрения архитектуры.
В худшем случае мой план резервного копирования состоит в том, чтобы реализовать своевременную агрегацию как часть логики начального ETL и распределить все различные разрешения по разным коллекциям, чтобы служба находила записи для выборки, уже ожидающие в агрегированном виде. коллекции. Но предполагалось использовать агрегации времени для механизма хранилища данных.
У меня сейчас немного архитектурных проблем