Redis как база данных

Question

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

---

Answer 3

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

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

1. Используйте механизм главный-подчиненный для репликации данных на второй компьютер. Теперь у вас есть 2 копии одинаковых данных.
2. Разорвать связь между ведущим и ведомым.
3. Удалите первую половину данных (разделенных хэшированием и т. Д.) Данных на первом компьютере и удалите вторую половину данных на втором компьютере.
4. Скажите всем клиентам (PHP, C и т. Д.), Что они должны работать на первом компьютере, если указанные ключи находятся на этом компьютере, в противном случае работать на втором компьютере.

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

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

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

Answer 4

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

Плюсы:

• Redis был непревзойденным по производительности.Мы получили 10K транзакций в секунду из коробки (обратите внимание, что одна транзакция включала несколько команд Redis).Мы смогли достичь скорости 25K + транзакций в секунду после нескольких оптимизаций вместе со скриптами LUA.Таким образом, когда речь идет о производительности на блок, Redis не имеет себе равных.
• Redis очень прост в настройке и имеет очень небольшую кривую обучения в отличие от других хранилищ данных SQL и NoSQL.

Минусы:

• Redis поддерживает только несколько примитивных структур данных, таких как хеши, наборы, списки и т. Д., И операции с этими структурами данных.Этого более чем достаточно, если вы используете Redis в качестве кэша, но если вы хотите использовать Redis в качестве полноценного основного хранилища данных, вы будете чувствовать себя ограниченным.Нам было нелегко моделировать наши требования к данным с использованием этих простых типов.
• Самой большой проблемой, с которой мы столкнулись в Redis, было отсутствие гибкости.После того как вы определили структуру своих данных, любые изменения требований к хранилищу или шаблонов доступа фактически требуют переосмысления всего решения.Не уверен, что так ли это со всеми хранилищами данных NoSQL (я слышал, что MongoDB более гибок, но сам не использовал его)
• Поскольку Redis является однопоточным, загрузка ЦП очень низкая.Вы не можете поместить несколько экземпляров Redis на одну и ту же машину, чтобы улучшить загрузку ЦП, поскольку они будут конкурировать за один и тот же диск, что делает диск узким местом.
• Отсутствие горизонтальной масштабируемости является проблемой, о которой упоминали другие ответы.