Использование Redis для кэширования данных, которые используются в одностраничном приложении реального времени.

У меня есть веб-приложение, оно имеет обычные функции, пользовательские настройки и т. д., все они хранятся в MYSQL с пользователем и т. д......

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

Я хотел бы сделать эту таблицу в реальном времени для нескольких пользователей. Т.е. несколько пользователей могут открывать страницу редактирования данных и видеть изменения в режиме реального времени, сделанные другими пользователями, редактирующими таблицу.

Я думаю, что нужно кэшировать данные для таблицы в Redis, а затем выполнить все действия в Redis, например, поддерживать всех клиентов в актуальном состоянии.

После закрытия всех соединений для конкретной таблицы сохраните данные обратно в mysql для сохранения, я знаю, что Redis можно использовать в качестве постоянной базы данных NoSQL, но поскольку ОЗУ ограничено, а все мои другие данные хранятся в MYSQL, mysql кажется лучшим вариантом .

Это правильный вариант использования Redis? Правильно ли мое мышление?


mysql laravel redis real-time ioredis
person Snewedon    schedule 28.05.2016    source источник
comment
как это прошло для вас? можете поделиться историями о реализации?   -  person briancaffey    schedule 13.11.2019
comment
Я думаю, что принятый ответ хорошо объясняет плюсы и минусы, и Redis послужил моей цели, однако это было для личного проекта. Из-за администрации в отношении горизонтально масштабируемых экземпляров Redis при высокой нагрузке я решил использовать Google Firebase, поскольку он решает все проблемы масштабирования за вас. Мои требования или, по крайней мере, моя реализация требовали, чтобы все активные данные загружались в Redis, используя pub sub для взаимодействия с браузером через веб-сокет. Все это было обработано Firebase из коробки (у AWS есть аналогичные сервисы). Извините, если вы искали военные магазины коммерческого производства.   -  person Snewedon    schedule 14.11.2019
comment
Если я правильно помню, я использовал конечные точки PHP для сохранения данных в Redis, и он просто взял на себя роль сервера публикации/подписки с очень быстрыми ответами, распространяемыми на подключенных клиентов без необходимости опроса сервера.   -  person Snewedon    schedule 14.11.2019
comment
Эти проблемы с масштабированием, возможно, можно было бы автоматизировать с помощью контейнеров и Kubernetes, но лично я еще не дошел до Kubernetes.   -  person Snewedon    schedule 14.11.2019

Ответы (1)


arrow_upward
3
arrow_downward

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

Я расскажу о плюсах и минусах использования Redis. Решение зависит от вас.

Преимущества использования Redis:

    1) It can handle heavy writes and reads in comparison with MYSQL
    2) It has flexible structures (hashmap, sorted set etc) which can 
localise your writes instead of blocking the whole table.
    3) Read queries will be much faster as it is served from cache.

Недостатки использования Redis:

    1) Maintaining transactions. What happens if both users try to access a 
    particular cell at a time? Do you have a right data structure in redis to 
    handle this case?
    2) What if the data is huge? It will exceed the memory limit. 
    3) What happens if there is a outage?
    4) If you plan for persistence of redis. Say using RDB or AOF. Will you 
    handle those 5-10 seconds of downtime?

Вещи, на которых следует сосредоточиться:

1) С каким объемом данных вы собираетесь иметь дело? Предположим, что для таблицы из 10000 строк с 10 столбцами в Redis требуется 1 ГБ памяти (просто предположение, что фактическая память будет намного меньше). Если ваш кластер Redis имеет размер 10 ГБ, вы можете обрабатывать только 10 таких таблиц. Посчитайте, сколько rows * column * live tables вы собираетесь работать, и сколько памяти они потребляют.

2) Redis использует сжатие данных в диапазоне http://redis.io/topics/memory-optimization. Допустим, вы решили сохранить таблицу с хэш-картой, у вас есть два варианта: для каждого столбца у вас может быть хэш-карта или для каждой строки у вас может быть хэш-карта. Второй вариант будет оптимальным. потому что хранение 1000 (хэш-карты -> строки) * 20 (записей в каждой хэш-карте -> столбцы) займет в 10 раз меньше памяти, чем хранение другим способом. Также таким образом, если ячейка изменена, вы можете локализовать в хэш-карте не более 20 значений.

3) Загрузка данных обратно в ваш MYSQL. как часто это будет происходить? Если ваша рабочая нагрузка высока, то MYSQL начинает хуже работать для других операций.

4) Как вы собираетесь работать с несколькими клиентами при уведомлении об изменениях? Будете ли вы загружать всю таблицу или часть, которая изменяется? Загрузка измененной детали будет оптимальной. В этом случае, где вы будете хранить список ячеек, которые были изменены?

Оцените свою систему, ответив на эти вопросы, и вы поймете, осуществима она или нет.

person Karthikeyan Gopall    schedule 29.05.2016