@maks15m

Как оптимизировать частые запросы на запись в mongodb?

Все привет. На сайте имеется сбор минимальной аналитики — просмотры страниц. При каждом запросе страницы js отправляет запрос к api, где в коллекцию mongodb кладётся запись вида:

{
    model: "book" (string),
    key: 42 (integer),
    date: "2020-10-21 09:37:00" (string),
}


Коллекция имеет индексы:

{
   "v" : 2,
   "key" : {
      "_id" : 1
   },
   "name" : "_id_"
},
{
   "v" : 2,
   "key" : {
      "key" : 1,
      "model" : 1,
      "date" : 1
   },
   "name" : "key_1_model_1_date_1"
}


Model и key нужны для идентификации страницы. Каждый час эти данные обрабатываются воркером, вычисляется статистика просмотров для каждой нужной страницы, но не суть.

Запрос на запись в mongo выполняется за 0.008 секунд, однако в целом работа mongodb загружает процессор в несколько раз больше, чем запросы самих страниц от пользователей.

Как можно оптимизировать работу mongo? Даст ли прирост производительности, если записывать в date значение timestamp вместо string? Или ещё вариант, для идентификации страницы (model, key) при её создании назначать для неё уникальное int значение (сам контент меняется редко), тогда model и key заменяем на page_id: (int).

Дадут ли эти изменения хоть что-нибудь? Какие существуют ещё варианты?

Для хранение контента сайта используется Mysql. Сайт находится на одном сервере, используется apache-itk, nginx для статики.
  • Вопрос задан
  • 102 просмотра
Решения вопроса 1
zoonman
@zoonman
⋆⋆⋆⋆⋆
date нужно изменить на ISODate() или timestamp() в зависимости от того, насколько это удобно. Для правильных аггрегаций лучше ISODate.

Если есть возможность, делать batch insert, тогда индекс не будет перестраиваться для каждого документа, а только после вставки группы. Если у вас неплохая посещаемость, то складывайте данные массив и вставляйте в базу группами по 100 записей. Если посещаемость не очень высокая, до вставляйте по таймеру раз в секунду.

Делать составной индекс по всем полям не имеет смысла. Разберитесь, что именно вам нужно, стройте по этому индекс. Решение по использованию численного pageId мне нравится. Такой индекс будет компактнее.

По поводу архитектуры - держите сайт и статистику на разных сервисах (серверах). Для MongoDB используйте SSD.
Ответ написан
Комментировать
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы