Если сервер на ноде чем не устраивает данные в var ?
Как я понял изменение данных довольно редкая и не накладная задача?
Основной вопрос это быстрый доступ к данным множества клиентов?

Имхо данные записываются в любую удобную БД после этого присваиваются любой var переменной где с успехом и хранятся на любой запрос от клиентов данные отдаются максимально быстро и без лишних танцев с бубном.

Единственное возможное проблемное место это целостность данных при внезапно остановке ноды но целостность легко обеспечить просто сохранив данные перед использованием(присвоение� � переменной) сохранение загрузка данных элементарна имхо все должно неплохо работать прямо из коробки и не нужно хитрых решений.

MallSerg, Данные будут весеть в ОЗУ и так просто что бы если что то дропнет или какае то другая проблема, не парсить данные заново потому что парсить там приилично, то данные будут браться из бд

Так перед тем как присвоить данные переменной или изменить просто сохрани их в базу в том виде в котором они будут использоваться при падении просто загрузи их из базы (я использую json как оч. удобный формат для почти любой платформы) .
Если падение сервера будет реже чем один раз в минуту то заметных проблем возникнуть не должно.

На все это должны писаться тесты которые эмулируют нагрузку и киляют веб сервер для проверки проблем с потерей данных.
Чем больше хороших тестов тем надежнее и быстрее пишется приложение.

А если совсем по хорошему то сначала пишутся тесты которые тестируют приложение по ТЗ а на основе этих тестов пишется приложение.

Это пока для меня слишком

Я бы сделал так: SQL, если отношения есть (или будут), и NoSQL, если их нет (и не будет).

Redis заменяется на любое другое - он для кеша

Моё имхо, пытаться делать реляции на NoSQL - это просто жесть

melky, что подразумеваеться под "отношение между сущностями" ?

на которой умею и которую знаю.

Если не знаешь, то сначала изучи их возможности и сравни с потребностями. Многие задачи можно реализовывать с помощью разных бд.

(my)sql стопудово более гибкий вариант. По сути я еще не сталкивался с задачами где, требовалась иная бд. С другой стороны нужны потребности, чтобы выбрать нужный вариант.

Короче: Реляционная база данных vs NoSQL

Выбери то, что тебе нужно, а не то, что посоветуют!

Я вот и пытаюсь понять что мне нужно)

я лишь предлагаю варианты. ничего не навязываю :)

отношения - это связи между таблицами вида "один-к-одному" , "один-ко-многим" и "многие-ко-многим"

лично для меня геморно было разруливать их на NoSQL. в (my)SQL это делают JOIN запросы, но с ними ... легче как-то, что-ли

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

тут уже оофтоп пошел )

есть CRON - тут для расписания вещь более подходит, мне кажется