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

Ответ 1

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

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

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

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

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

Ответ 4

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

Плюсы:

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

Минусы:

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