@frontendo

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

Для приложения списка задач, в котором можно назначать исполнителей и проверяющих заранее продумываю как правильно закешировать данные всех пользователей приложения, так как они будут многократно нужны при запросе списков задач. Когда отображаем список, можно увидеть, кто создал задачу, кто исполнители, кто проверяющий. В списке может быть к примеру 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мб, но это наверное такая малая цифра из-за како-то оптимизации самой нодой структур своих данных
  • Вопрос задан
  • 534 просмотра
Решения вопроса 3
Сама суть кешировать данные в переменных нормальна, но не для таких данных или по крайней мере не так, мы не можем контролировать память и объемы данных, т.к задач и пользователей может быть я так понимаю неизвестное число, значит наша память в опасности, база легко справится с запросом и парочкой JOIN в нем
Ответ написан
@agaliullin
CEO & Founder of Futureinapps, LLC
Вариант 1. Reddis.
Преимущества:
1. Быстрый доступ к объектам
2. Изолирован от node процессов
3. Поддерживает сжатие и как следствие кушает мало памяти
Вариант 2. MongoDB
Преимущества:
1. Простое сохранение и загрузка объектов
2. Изолирован от node процессов
Вариант 3. Файлы и переменные
Использование файлов и переменных крайне не рекоменду, как было сказано выше может привести к серьезной утечке памяти или к потере данных, если приложение крашентся.

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

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

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