我有一个网站，用户可以在其中提交短信，非常简单的数据结构...
- 姓名 <-- 少于 20 个字符
- 消息 <-- 最多 150 个字符
- 时间戳
- 知识产权
- 隐藏 <-- Bool(真或假)
在旧版网站中，它们存储在MySQL数据库中，该数据库非常大，表很多，我想简化数据库。所以我听说 Redis 适用于简单的数据结构和非关系信息...
Redis 是处理此类数据的好选择吗？它的性能如何，涉及每年 100,000 多条记录时的内存使用和读取时间......
最佳答案
redis 实际上只适用于内存中的问题集。它确实具有页面到磁盘的功能 - 但你会受到操作系统交换器的支配 - 即你的 RAM 将与系统缓存竞争。另外，我认为按键总是必须适合 RAM。所以您不会想要存储超过 1G 的日志记录 - mysql-archive-table 对此要好得多。
redis具有主从功能，类似于mysql。因此，您可以执行各种技巧，例如对从服务器进行排序以保持主服务器响应。虽然我没有使用过它，但我推测对于内存数据库，mysql-cluster 可能要先进得多 - 但具有相应的额外复杂性/资源成本。
如果您的键值集有很大的值，您可以执行客户端压缩/解压缩。无论如何，服务器无法搜索这些“blob”的值。
绕过 RAM 限制的一种常见方法是执行客户端分片(分区)。也就是说，如果你知道你的上限，并且由于某种原因你没有足够的 RAM 来解决这个问题(比如你已经有 64GB 的 RAM)，那么你可以根据主键“分片”..如果它是一个序列计数器，你可以取底部的 3 位(或一些散列函数 + 分区函数)，并分布在 4、8、16 等服务器节点之间。这是线性扩展的，但如果您需要重新分区，那可能会很痛苦。您可以利用 redis 中的“插槽”从更少的机器开始。假设一台机器有 16 个插槽。然后，转储插槽 7-15 并在另一台机器上恢复并重新映射所有客户端以指向两台机器(具有相同的插槽号)。等等到 16 路分片。此时，您需要重新映射所有数据以转到 32 向。
显然，首先要评估 redis 的命令集，看看是否可以满足您所有的数据存储和报告需求。有等同于“select * from foo for update”，但它们并不明显。并非所有 RDBMS 查询都可以使用键值存储有效地重现。但对于简单的自然主键记录结构，它应该没问题。
此外，扩展 redis 命令集以执行自定义操作应该很容易。请记住，它是围绕无暂停单线程执行设计的(避免锁定/上下文切换开销)。
但我真正喜欢的是 FIFO、pub/sub、数据超时、原子突变(inc/dec)、惰性排序(例如在具有只读节点的客户端上)、maps of maps。这非常简单，您只需在不同的端口/UNIX 套接字(如果可能的话，我的偏好)上启动单独的 redis 进程，而不是使用 namespace 。
它的目的是取代 memcached，而不是其他任何东西，但有一个非常好的后台持久框架。
关于database - Redis 适合我需要的东西吗，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8168306/