Redis作为数据库

Question

我想将Redis用作数据库,而不是缓存.根据我的(有限)理解,Redis是一个内存数据存储区.使用Redis有什么风险,我该如何减轻它们？

Answer 1

您可以通过多种不同方式将Redis用作权威商店:

• 打开AOF(仅附加文件存储),请参阅AOF文档.这将实时记录针对您的数据集所做的所有Redis命令.

• 使用主从复制运行Redis 请参阅复制文档.如果您的某个实例失败,这将允许您提供高可用性.

• 如果您正在运行EC2之类的东西,您可以EBS支持Redis分区,以提供另一层防止实例故障的保护.

即将推出的Redis群集 - 这是专门设计的一种以有助于提高HA和可扩展性的方式运行Redis的方法.但是,至少再过六个月左右就不会出现这种情况.

Answer 2

Redis是一个内存存储,也可以将数据写回光盘.您可以指定执行fsync的次数以使redis更安全(但也更慢=>权衡).

但是我仍然不确定redis是否处于尚未真正存储(任务)关键数据的状态(但是？).例如,当另外一条推文(twitter.com)或类似的东西丢失时,这不是一个大问题,那么我肯定会使用redis.在redis自己的网站上还有很多关于持久性的信息.

您还应该了解一些可能通过阅读antirez(redis维护者)博客文章而出现的持久性问题.你应该阅读他的博客,因为他有一些有趣的文章.

Answer 3

我想分享一些我们通过使用 Redis 作为服务中的主数据库学到的东西。我们选择Redis是因为我们有无法分区的数据。我们希望从一个盒子中获得最好的性能

优点：

• Redis 在原始性能方面是无与伦比的。我们每秒处理 10K 笔交易（请注意，一笔交易涉及多个 Redis 命令）。经过一些优化以及 LUA 脚本后，我们能够达到每秒 25K+ 事务的速率。因此，就每台机器的性能而言，Redis 是无与伦比的。
• 与其他 SQL 和 NoSQL 数据存储相比，Redis 的设置非常简单，并且学习曲线非常小。

缺点：

• Redis 仅支持少数原始数据结构，如哈希、集合、列表等以及对这些数据结构的操作。当您使用 Redis 作为缓存时，这些已经足够了，但是如果您想使用 Redis 作为成熟的主数据存储，您就会感到受到限制。我们在使用这些简单类型对数据需求进行建模时遇到了困难。
• 我们发现 Redis 最大的问题是缺乏灵活性。一旦解决了数据结构的问题，对存储要求或访问模式的任何修改实际上都需要重新考虑整个解决方案。不确定是否所有 NoSQL 数据存储都是这种情况（我听说 MongoDB 更灵活，但我自己没有使用过）
• 由于Redis是单线程的，CPU利用率很低。您不能将多个 Redis 实例放在同一台机器上来提高 CPU 利用率，因为它们会竞争同一磁盘，使磁盘成为瓶颈。
• 缺乏水平可扩展性是其他答案提到的一个问题。

Answer 4

由于Redis是内存存储，因此无法存储不适合您计算机内存大小的大数据。当Redis存储的数据大于RAM大小的1/3时，Redis通常会非常糟糕。因此，这是将Redis用作数据库的致命限制。

当然，您可以将大数据分发到多个Redis实例中，但是您必须手动完成所有操作。该操作通常是这样完成的（假设您从开始就只有1个实例）：

1. 使用其主从机制将数据复制到第二台计算机，现在您具有相同数据的2个副本。
2. 切断主机和从机之间的连接。
3. 删除第一台计算机上的数据的前半部分（通过哈希等拆分），然后删除第二台计算机上的数据的后半部分。
4. 如果指定的密钥在该计算机上，则告诉所有客户端（PHP，C等）在第一台计算机上进行操作，否则，在第二台计算机上进行操作。

这就是Redis扩展的方式！您还必须停止服务以防止在迁移期间进行任何写操作。

对于我们遇到的经验，我们对Redis得出以下结论：Redis不是存储30G以上数据的正确选择，Redis不具有可伸缩性，Redis非常适合原型开发。

后来我们找到了Redis的替代方案，即SSDB（https://github.com/ideawu/ssdb），这是一个支持几乎Redis所有API的leveldb服务器，它适合存储1TB以上的数据，取决于您的硬盘大小。