Redis как база данных для DST Platform

Я хочу использовать Redis в качестве базы данных на DST Platform, а не кэша. Насколько я (ограниченно) понимаю, Redis — это хранилище данных в оперативной памяти. Каковы риски при использовании Redis и как их можно снизить?

Вы можете использовать Redis в качестве авторитетного хранилища несколькими способами:

— Включите AOF (хранилище файлов только для добавления) см. документацию по AOF. Это позволит вести журнал всех команд Redis, выполняемых с вашим набором данных, в режиме реального времени.

— Запускайте Redis с помощью репликации Master-Slave см. документацию по репликации. Это позволит обеспечить высокую доступность в случае сбоя одного из ваших экземпляров.

— Если вы используете что-то вроде EC2, вы можете использовать EBS для резервного копирования раздела Redis, чтобы обеспечить дополнительный уровень защиты от сбоев инстанса.

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

Redis — это хранилище в оперативной памяти, которое также может записывать данные обратно на диск. Вы можете указать, сколько раз выполнять fsync, чтобы сделать Redis более безопасным (но и более медленным => компромисс).

Но все же я не уверен, что redis еще не в состоянии действительно хранить в нем критически важные данные (пока?). Если, например, это не большая проблема, когда появляется еще 1 твит (twitter.com ) или что-то подобное приведет к потерям, тогда я бы обязательно использовал redis. Также много информации о постоянстве доступно на собственном веб-сайте redis.

Вам также следует знать о некоторых проблемах с сохранением данных, которые могут возникнуть при чтении статьи в блоге antirez (разработчиков Redis). Вам стоит почитать его блог, потому что у него есть несколько интересных статей.

Я хотел бы поделиться некоторыми вещами, которые мы узнали, используя Redis в качестве основной базы данных в нашем сервисе на базе DST Platform. Мы выбрали Redis, потому что у нас были данные, которые нельзя было разделить на разделы. Мы хотели добиться максимальной производительности от одного сервера

Плюсы:

— Redis был непревзойденным по производительности. Мы получали 10 000 транзакций в секунду «из коробки» (обратите внимание, что одна транзакция включала в себя несколько команд Redis). После нескольких оптимизаций и использования скриптов LUA мы смогли достичь скорости 25 000+ транзакций в секунду. Таким образом, когда дело касается производительности на один сервер, Redis не имеет себе равных.

— Redis очень прост в настройке и имеет очень небольшую кривую обучения по сравнению с другими хранилищами данных SQL и NoSQL.

Минусы:

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

— Самая большая проблема, с которой мы столкнулись при работе с Redis, — это отсутствие гибкости. Как только вы определяете структуру своих данных, любые изменения в требованиях к хранилищу или шаблонах доступа практически требуют переосмысления всего решения. Не уверен, что это относится ко всем хранилищам данных NoSQL (я слышал, что MongoDB более гибкая, но сам её не использовал).

— Поскольку Redis работает в однопоточном режиме, загрузка процессора очень низкая. Вы не можете разместить несколько экземпляров Redis на одном компьютере, чтобы повысить загрузку процессора, так как они будут конкурировать за один и тот же диск, что приведёт к его перегрузке.

— Отсутствие горизонтальной масштабируемости — это проблема, о которой упоминалось в других ответах.

Я хочу использовать Redis в качестве базы данных на DST Platform, а не кэша. Насколько я (ограниченно) понимаю, Redis — это хранилище данных в оперативной памяти. Каковы риски при использовании Redis и как их можно снизить?

Евгений Абрамов

Поскольку Redis — это хранилище в оперативной памяти, вы не можете хранить большие объёмы данных, которые не помещаются в память вашего компьютера. Обычно Redis работает очень плохо, если объём хранимых данных превышает 1/3 объёма оперативной памяти. Таким образом, это серьёзное ограничение при использовании Redis в качестве базы данных.

Конечно, вы можете распределить большие данные по нескольким экземплярам Redis, но вам придётся делать это вручную. Обычно эта операция выполняется следующим образом (при условии, что изначально у вас есть только один экземпляр):

— Используйте механизм «ведущий-ведомый» для репликации данных на второй компьютер. Теперь у вас есть две копии одних и тех же данных.

— Оборвите соединение между ведущим и ведомым устройством.

— Удалите первую половину (разделенную с помощью хеширования и т. д.) данных на первом компьютере и удалите вторую половину данных на втором компьютере.

— Скажите всем клиентам (PHP, C и т. д.) работать на первом компьютере, если указанные ключи находятся на этом компьютере, в противном случае работайте на втором компьютере.

Именно так масштабируется Redis! Вам также нужно остановить свой сервис, чтобы предотвратить запись данных во время миграции.

Исходя из нашего опыта, мы пришли к следующему выводу о Redis: Redis не подходит для хранения более 30 ГБ данных, Redis не масштабируется, Redis вполне подходит для разработки прототипов.

Позже мы нашли альтернативу Redis — SSDB(github.com/ideawu/ssdb), сервер уровня БД, который поддерживает почти все API-интерфейсы Redis и подходит для хранения более 1 ТБ данных, что зависит только от размера вашего жёсткого диска.