Question

我们正在为使用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是个好主意？从长远来看，它将如何影响我们，因为我们需要不断更新我们的索引＆amp;分区方案以满足巨大的需求。
除了redis之外，还有哪些其他数据库（关系数据库或非关系数据库）适用于此用例？
或者我们都错了，因为redis用于存储此类数据。所以，我们只是继续使用redis＆amp;每月升级我们的机器？

Answer 1

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

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

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

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

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

我建议您保留Redis应用，但请尝试将历史数据移至其他数据存储区。

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

Answer 2

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

如果您因为必须将所有数据保存在内存中而担心托管成本，那么我的投票离开Redis可能是一个好主意。这并不一定要涉及从Redis移出所有数据，也许只是历史性的＆＃34;更冷的＆＃34;您不太关心延迟的数据。将Red数据移出Redis的另一个好处是，迁移过程中发现的任何错误都可能产生的影响不大。

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

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

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

Answer 3

如果mysql（或任何其他传统数据库）就足够了你为什么要首先使用Redis？
“我们为以后的处理存储”是模糊的。你能详细说明一下吗？我假设，后来的处理是一种分析类型的活动，延迟并不重要，只有吞吐量很重要，对吧？如果是这种情况，Redis是一个矫枉过正的你不觉得吗？
您是否考虑在将数据转储到Redis之前压缩数据。

根据我的理解，您的数据始终是结构化的，您的READ是非实时的，“耐久性”对您而言比延迟更重要。如果所有这些假设都是正确的，那么mysql是一个安全的选择。如果你曾经遇到过WRITE瓶颈，你可以考虑一下Sharding。

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

请记住，大多数NoSQL解决方案（包括Redis）都很快，因为它们交换ACID属性以提高速度。但就你的情况而言，根据我的理解，ACID属性更重要。

Answer 4

随着即将推出的Redis 3.0，集群功能将为生产做好准备。看一下http://redis.io/topics/cluster-tutorial即可获得概述。这对于不断增长的数据量没有直接帮助，但我认为这可以使您的设置更容易缩放/分片。

你还可以考虑移动＆＃34; old＆＃34;从Redis到另一个系统的数据，例如在Redis River的帮助下的ElasticSearch：

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

使用MessagePack进行压缩也可以是一个选项：

从redis切换到Mysql。好主意？

4 个答案: