Как и с при помощи чего правильно кешировать ответы сервера?

Question

[Fengol]

Далек от backend разработки, но для саморазвития начал писать для себя домашний проект и специально для этого выбрал очень непростую задачу. Её сложность кроется в хранении данных в БД, чья структура очень далека от той структуры, которая требуется на клиенте. Очень большой объем данных в БД хранится в нормализованном виде, а на клиенте требуется отдавать в виде очень сложных деревьев или даже графов, чтобы визуализировать с помощью графиков. Вот и получается, что просто бессмысленно на каждый запрос генерировать упомянутые структры в json и легче отдавать на каждый запрос его закешированную версию. Но я не знаю, как правильно хешировать и где его хранить. Сервер будет на nodejs, но пока точно незнаю какой. БД пока mondodb + mongoose.

Надеюсь что информации достаточно. Также повторю ещё раз - я совершенно не знаю что и как делать, поэтому прошу объяснить не по словам взятым из вопроса в ка, кочестве ключевых, а так как делают в реальных проектах. Возможно нужно задействовать nginx, какие-то другие БД, возможно и сервера на nodejs достаточно, а возможно его нужно использовать в совокупности.. Объясните подробно.

Comments

[sim3x]

Монга не предназначена для хранения нормализованных данных - используйте постгрес

Хеширование != кеширование

Вы не можете подготовится заранее к хайлоаду - пока вы не понимаете, что клиенты будут запрашивать

Answer 1

[sim3x]

Проще всего кешировать на nginx
Дальше memcached/redis
Потом все зависит от стека и тонкостей

Answer 2

[rPman]

Хорошенько проанализируйте какие именно данные меняются и как часто.

Например иногда очень удачно получается так что в проекте основной объем данных на клиенте - значения справочников, т.е. фактически на клиентскую сторону от сервера нужно передавать только id записей в таблицах-справочниках, которые изменяются очень редко, точнее это не основной поток изменений.

А значит необходимо от сервера к клиенту пустить поток на синхронизацию таблиц-справочников (т.е. в вебсокет канале у вас будут сообщения вида add/remove/modify table_name id,value) и все объекты передавать в виде набора id (даже если это нормализованная табличка, описывающая граф, из тысяч строчек - будет не страшно, так как там будет много повторений и пустых ячеек).

Будьте осторожны, даже упакованный набор id, сериализованный в виде json - не эффективен (из-за наименований полей, либо их тоже надо кодировать) и возможно вам лучше использовать бинарный сериализатор структур, не передающий эти имена в принципе, таким является google protobuf для примера, поддержка кучи языков позволяет и в веб его использовать.

p.s. справочники можно первично на клиент передавать статичными файлами, если редко меняются, или последовательностью из лога их изменений (файл на дату в прошлом и несколько файлов с дампом истории изменений, как часто обновлять файлы - вопрос статистики). В этом случае файлы будут закешированы штатным кешем браузера.
Иначе вам придется хранить данные в отдельном хранилище браузера (само собой с версией, и запрашивать при подключении историю изменений на дату), это немного неудобно но дает больше контроля по управлению кешем.