是Redis的好东西，我需要

Question

我有一个网站，用户可以提交短信，死简单的数据结构...

• 名称< - 少于20个字符
• 消息< - 马克斯150个字符
• 时间戳
• IP
• 隐藏< - 布尔（真或假）

在以前版本的网站上，它们存储在MySQL数据库中，这个数据库非常大，有很多表格，我想简化数据库。所以我听说Redis适用于简单的数据结构和非关系信息...

对于这类数据，Redis会是一个不错的选择，它将如何执行，在谈论100,000条记录时会如何执行内存使用和读取时间一年...

Answer 1

redis实际上只适用于内存中的问题集。它有一个页面到磁盘的功能 - 但是，那么你是在操作系统交换的摆布 - 即你的RAM将与系统缓存竞争。另外，我认为钥匙总是要装在RAM中。所以你不想存储1G +日志记录 - mysql-archive-table对此更好。

redis具有主从功能，类似于mysql。所以你可以执行各种技巧，比如在从机上排序以保持主机响应。虽然我没有使用它，但我推测对于内存数据库来说，mysql-cluster可能要高得多 - 但是会带来相应的额外复杂性/资源成本。

如果您的键值集的值较大，则可以执行客户端压缩/解压缩。无论如何，服务器没有太多的工具可以搜索这些“斑点”的值。

解决RAM限制的一种常见方法是执行客户端分片（分区）。也就是说，如果你知道你的上限，并且你没有足够的内存来解决这个问题（比如说你已经拥有64GB的内存），那么你可以根据主键进行分片。如果它是一个序列计数器，你可以取最低3位（或一些哈希函数+分区函数），并分布在4,8,16等服务器节点中。这可以线性扩展，但如果需要重新分区，那可能会很痛苦。你可以利用redis中的'slots'开始使用更少的机器。说1台带有16个插槽的机器。然后，转储7-15插槽并在不同的机器上恢复，并重新映射所有客户机以指向两台机器（具有相同的插槽编号）。等到16路分片。此时，您需要将所有数据重新映射到32路。

显然，首先要评估redis的命令集，以查看是否可以满足所有数据存储和报告需求。还有等同于“select * from foo for update”，但它们并不明显。并非所有的RDBMS查询都可以通过键值存储高效地再现。但是对于简单的自然主键记录结构来说，它应该没问题。另外，应该很容易扩展redis命令集来执行自定义操作。请记住，它是围绕不停顿的单线程执行（避免锁定/上下文切换开销）而设计的。但我真正喜欢的是FIFO，pub/sub，数据超时，原子突变（inc/dec），懒排序（例如在只读节点上的客户端），地图地图。非常简单，不是使用名称空间，而是在不同的端口/ UNIX套接字上启动单独的redis进程（如果可能，我的首选项）。

它意味着比其他任何东西都更换memcached，但有一个非常好的后台持久框架。