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