我有一个网站，用户可以提交短信，死的简单数据结构......
在网站的早期版本中，它们存储在 MySQL 数据库中，该数据库非常大，有很多表，我想简化数据库。所以听说 Redis 适合简单的数据结构和非关系信息...
Redis 是处理这类数据的一个不错的选择吗？它的性能如何，内存使用量和读取时间在谈论一年超过 100,000 条记录时...
【问题讨论】：
标签： database redis data-storage
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、发布/订阅、数据超时、原子突变 (inc/dec)、惰性排序（例如在具有只读节点的客户端上）、地图映射。这很简单，不用使用名称空间，您只需在不同的端口/UNIX 套接字上启动单独的 redis 进程（如果可能的话，我的偏好）。
它的目的是取代 memcached，但它有一个非常好的后台持久化框架。
【讨论】：