从 redis 切换到 Mysql。好主意？答案

【问题标题】：Switching from redis to Mysql. Good idea?从 redis 切换到 Mysql。好主意？
【发布时间】：2014-12-14 15:30:51
【问题描述】：

我们正在使用 Rails 为餐厅构建 SaaS 后端。我们直接与 POS 集成，因此每个 POS 都会不断发送我们存储的客户订单以供以后处理。我们在大约 1,000 个地点进行了这种 POS 集成，每月向我们发送大约 300 万份个人客户订单。对于这个写繁重的应用程序，我们将所有订单存储在运行良好的 redis 中。我们正在以令人难以置信的速度增长，我们不断增加拥有数百个地点的新餐厅，不断向我们发送大量数据。除了有一个问题——redis 每个月都会内存不足！因为，所有不必在内存中的东西都在内存中。

这就是我们考虑切换到mysql的原因。因为我们真的不需要将所有数据都保存在内存中。这是我们当前 redis 数据库的编号：

  used_memory_human:39.83G 
  dbsize: 34706870

这是我们在 redis 中存储为 Hash 的内容：

id - integer
location_id - integer
stored_at  - timestamp
token - string
transaction_no - integer
menu_items - string(comma seprated list of all menu items that customer ordered along with their price & Qty)
order_amount - decimal
order_subtotal_amount - decimal
order_amount_payable - decimal
order_datetime - timestamp
employee_id - integer
employee_name - string
pos_type - string
post_version - string
restaurant_id - integer

所以，在以下方面寻求一些建议：

从 redis 迁移到 mysql 是个好主意吗？从长远来看，它将如何影响我们，因为我们需要不断更新索引和分区方案以满足巨大的需求。
除了 redis 之外，还有哪些其他数据库（关系型或非关系型）适合此用例？
或者我们都错了，因为 redis 是为存储这种类型的数据而设计的。所以，我们只是继续使用 redis 并每个月升级我们的机器？

【问题讨论】：

标签： mysql ruby-on-rails redis nosql

【解决方案1】：

网络上的数据必然会增长。任何长期项目都应该预见到这一点，并制定扩展策略。

随着您的数据量或流量增加，您会发现几乎每个数量级的增长都需要更改您的架构来处理它。也许你可以领先一点，但不是永远。而且您无法提前很长时间预测您的瓶颈在哪里。

您的数据的一小部分对于您的应用程序的每分钟工作都很重要，这是很常见的，您可以将这个子集保留在 Redis 中以利用您当前的代码。然后可以在另一个数据存储中使用其余数据，访问速度可能会慢一些，但更容易处理增长。

您可以废弃当前代码并将所有内容移至 MySQL 或其他数据存储，但请记住两点：

没有数据库可以让您忽略扩展策略。您可以使用 MySQL、PostgreSQL、MongoDB、Hadoop 或其他任何东西，但您仍然会遇到数据增长速度超过单个服务器上的单个数据库可以处理的问题。
出于更高效的开发或运营的内部原因，从头开始重写应用程序通常不划算（阅读Things You Should Never Do, Part I by Joel Spolsky）。

我建议保留您的 Redis 应用，但尝试将历史数据移动到另一个数据存储区。

我认为 MySQL 是一个不错的选择，我相信它能够处理您的数据。我经常与在 MySQL 中保存 TB 级数据并每秒处理数万个事务的客户合作。但由于您没有提供有关数据使用的任何详细信息，因此我无法就 MySQL 是否是最佳选择提供意见。例如，可能是 Hadoop 具有优势。

【讨论】：

【解决方案2】：

从 redis 迁移到 mysql 是个好主意吗？从长远来看，它将如何影响我们，因为我们需要不断更新索引和分区方案以满足巨大的需求。

如果您因为需要将所有数据保存在内存中而担心托管成本，那么我的投票决定放弃 Redis 可能是一个好主意。这不必涉及将所有数据移出 Redis，也许只是您不太关心延迟的历史“冷”数据。将冷数据从 Redis 中移出的另一个优点是，在迁移过程中发现的任何错误都可能产生较小的影响。

除了 redis 之外，还有哪些其他数据库（关系型或非关系型）更适合此用例？

如果没有更好地了解您的用例，这是一个很难回答的问题。也就是说，我认为任何数量的可扩展关系数据库都可能足以满足您的工作负载。在我看来，一个关键要求是能够根据需要轻松添加/删除机器以进行扩展。个人最喜欢的是 CitusDB，但有多种选择。

迁移到关系数据库时需要注意的一个权衡是，与使用 Redis 键/值存储相比，管理结构化数据时您可能需要做更多的工作。例如，添加新字段可能涉及架构更改。 PostgreSQL（和 CitusDB）支持一些半结构化数据类型，这使得这更容易，我相信还有其他具有类似功能的关系数据库。

【讨论】：

【解决方案3】：

如果 mysql（或任何其他传统数据库）就足够了，那么您为什么选择 Redis？
“我们存储以备后处理”含糊不清。你能详细说明一下吗？我假设，这个稍后的处理是一种分析类型的活动，延迟并不重要，只有吞吐量很重要，对吧？如果是这样的话，你不觉得 Redis 有点过头了吗？
您是否考虑过在将数据转储到 Redis 之前对其进行压缩。

根据我从您的问题中了解到的情况，您的数据始终是结构化的，您的 READ 是非实时的，“持久性”对您而言比延迟更重要。如果所有这些假设都是正确的，那么 mysql 是一个安全的选择。如果您遇到 WRITE 瓶颈，您可以考虑分片。

这个帖子会给你一个公平的想法。 Can redis fully replace mysql?

请始终牢记，大多数 NoSQL 解决方案（包括 Redis）速度很快，因为它们以 ACID 属性换取速度。但在你的情况下，据我了解，ACID 属性更重要。

【讨论】：

【解决方案4】：

随着即将推出的 Redis 3.0，集群功能将准备好投入生产。查看http://redis.io/topics/cluster-tutorial 以获取概览。这不会直接帮助处理不断增长的数据量，但我认为这可以使您的设置更容易进行缩放/分片。

您还可以考虑将“旧”数据从 Redis 移动到另一个系统，例如借助 Redis River 的 ElasticSearch：

https://github.com/leeadkins/elasticsearch-redis-river

也可以选择使用 MessagePack 进行压缩：

【讨论】：