Приавильно ли кешировать данные в обычных переменных node.js проекта?

Question

[frontendo]

Для приложения списка задач, в котором можно назначать исполнителей и проверяющих заранее продумываю как правильно закешировать данные всех пользователей приложения, так как они будут многократно нужны при запросе списков задач. Когда отображаем список, можно увидеть, кто создал задачу, кто исполнители, кто проверяющий. В списке может быть к примеру 20 задач и к каждой задаче может относится по 3 субъекта. Идею доставать информацию о субъектах из бд (я использую mysql) я откинул сразу, посмотрел на REDIS, но мне нужно многоуровневое хранилище (так как неплохо было бы сохранить для каждого пользователя и проекты, в которых он участвует, его роли в каждом проекте и тд, мб в будущем что-то еще), отдельно необходимо закешировать массив ролей в каждом проекте с их привилегиями. И Вот смотрю я на REDIS и в силу своего поверхностного знакомства с ним мне кажется, что многоуровневые данные хранить и изменять в нем будет затруднительно. Сохранять же и читать данные путем сериализации и парсинга JSON мне почему-то тоже не нравится. В идеале бы подходил вариант "mongo-db in ram" или что-то попроще, но с тем же смыслом.

Пока пробую реализовать просто путем создания кастомного объекта-хранилища. Конечно, если нода падает, то при перезапуске мы снова выбираем всех пользователей из базы и заливаем в объект, при изменении информации какого-то пользователя просто перезаписываем инфу по идентификатору типа cache.users[id] = {...new data...}
В таком подходе каких-то критических минусов не заметил, скорее всего по своей неопытности конечно

По оперативе, при сохранении в переменную 10000 юзеров с тремя полями, одно из которых с вложенностью

{ 
   name: 'hj1505238475597',
   avatar: 'avatar21505238475597',
   projectRoles:  {
      '2': [  4, 6 ] 
   }
}

съедает дополнительно 15мб озу, 100 000 юзеров - 60мб, но это наверное такая малая цифра из-за како-то оптимизации самой нодой структур своих данных

Comments

[Илья Шатохин]

Лучше не в переменных, а нормальном кэше - https://www.npmjs.com/package/lru-cache

Answer 1

[Илья Герасимов]

Сама суть кешировать данные в переменных нормальна, но не для таких данных или по крайней мере не так, мы не можем контролировать память и объемы данных, т.к задач и пользователей может быть я так понимаю неизвестное число, значит наша память в опасности, база легко справится с запросом и парочкой JOIN в нем

Comments

[frontendo]

ну парочка запросов - это как ни крути, процессорное время, а иногда и доступ к дискам. Там хватает запросов к бд и без этих данных

[RidgeA]

frontendo, неужели такой хайлоад, что это имеет какое-то существенное значение? был бы такой хайлод - таких бы вопросов не было.
Если жалко ходить в оперативку в redis и нет желания шарить данные между экземплярами сервиса - можно пробовать встраиваемые бд типа https://github.com/louischatriot/nedb (сам с ней не работал)
Но это все преждевременная оптимизация.

Answer 2

[Airat Galiullin]

Вариант 1. Reddis.
Преимущества:
1. Быстрый доступ к объектам
2. Изолирован от node процессов
3. Поддерживает сжатие и как следствие кушает мало памяти
Вариант 2. MongoDB
Преимущества:
1. Простое сохранение и загрузка объектов
2. Изолирован от node процессов
Вариант 3. Файлы и переменные
Использование файлов и переменных крайне не рекоменду, как было сказано выше может привести к серьезной утечке памяти или к потере данных, если приложение крашентся.

Судя по вашей задаче быстрота получения данных не так критична, поэтому советую вам выбрать MongoDB

Answer 3

[kwolfy]

Хранить данные в памяти можно, но вот стоит ли. Основная проблема в том, что при хранении в памяти нет возможности шаринга данных между процессами, что приводит к невозможности масштабирования. Т.е. если один процесс перестанет справляется с нагрузкой, то при добавлении дополнительных процессов кеш будет дублироваться и при изменении данных кеши будут конфликтовать.
В итоге, вам нужно определиться какую нагрузку ожидаете. Если вы считаете, что один процесс справится с ней - то не вижу проблем хранить всё в памяти