API сервера mongodb для переполнения стека
Я использую MongoDb, в котором данные меняются (обновляются) часто, — каждую минуту.
Данные взяты из стороннего API-приложения MongoDB через HTTP. Кроме того, данные API дополнительно агрегируются перед их возвратом, например подсчитывается сумма просмотров за последние X дней для страницы N.
Постоянно увеличивающийся объем данных (т. Е. Немногие из этих коллекций имеют размер от 6 до 14 ГБ) в некоторых случаях происходили с задержкой в 2-7 секунд, пока API не возвращает агрегированные данные. Упомянутая задержка для веб-приложения достаточно велика.
Я хочу как-то уменьшить эти задержки.
Какие модели используются в моих описанных ситуациях?
Может быть, в первую очередь я должен отказаться от этой идеи HTTP API и переместить всю логику API на серверную сторону?
Собственные идеи, соображения:
Может быть, должно быть два отдельных «обработчика» данных:
1) Первый «обработчик» должен выполнить все задачи агрегации и просто записать во вторую.
2) Второй «обработчик» всех данных возвращает только без каких-либо внутренних вычислений, агрегации.
Но также может возникнуть проблема с загрузкой, когда первая запись во второе хранилище данных, должна быть логика для обновления новых и старых данных, что также влияет на производительность.
Решение
Это стороннее приложение, похоже, плохо работает, поэтому вы должны его удалить. Вероятно, вы можете решить свои проблемы путем рефакторинга модели данных или с помощью лучших алгоритмов агрегирования.
Предварительные расчеты
Использование пакетного процессора и процессора реального времени звучит как хорошая идея, но я думаю, что она вам пока не понадобится (см. Ниже). Если вы все еще хотите реализовать это, вы должны прочитать о Лямбда-архитектура, потому что это решает некоторые проблемы, которые могут возникнуть у вашего подхода.
Этот подход к архитектуре пытается сбалансировать задержку, пропускную способность и отказоустойчивость, используя пакетную обработку для обеспечения всесторонних и точных предварительно вычисленных представлений, одновременно используя потоковую обработку в реальном времени для обеспечения динамических представлений. Два представления представления могут быть объединены перед представлением.
Модель данных (6 правил)
Вы говорите, что обновлений много, это красный флаг при использовании MongoDB. Некоторые обновления могут замедлить MongoDB из-за его распределенной природы. Например, попробуйте вставить вложенные документы вместо обновления полей. Но это не точная наука, поэтому я не могу помочь, не видя модель данных.
Структура агрегации
Базы данных созданы для данных, поэтому перенесите агрегирование данных в MongoDB. Карта Уменьшить медленно на MongoDB, таким образом использовать Структура агрегации.
Другие решения
Других решений пока нет …