从redis切换到Mysql。好主意？

我们正在使用Rails为餐馆构建SaaS后端。我们直接与POS机集成，因此每个POS机都会不断发送客户订单，我们会将这些订单存储起来以备日后处理。我们在大约1000个地点进行POS集成，每月向我们发送大约300万个客户订单。 对于这个写得很重的应用程序，我们将所有订单存储在redis中，它工作得很好。我们正以惊人的速度增长，我们不断增加新的餐厅，数百个地点不断向我们发送大量数据。但有一个问题——redis每个月都会耗尽内存！作为一个例子，所有不需要在内存中的东西都在内存中

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

  used_memory_human:39.83G 
  dbsize: 34706870

以下是我们在redis中存储为哈希的内容：

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（或任何其他传统数据库）就足够了，那么您首先为什么选择Redis
• “我们储存以备日后处理”是含糊不清的。你能详细说明一下吗？我假设，后面的处理是一种分析活动，对于这种活动来说，延迟并不真正重要，只有吞吐量才重要，对吗？如果真是这样的话，Redis是一个滥杀滥伤，你不觉得吗
你考虑在把数据压缩到ReIIS之前压缩数据吗？< /LI>

我从你的问题中了解到，你的数据总是结构化的，你的读取是非实时的，“持久性”对你来说比延迟更重要。如果所有这些假设都是正确的，那么mysql是一个安全的选择。如果遇到写瓶颈，可以考虑切分

这条线会给你一个公平的想法。

---

请始终记住，大多数NoSQL解决方案（包括Redis）都是快速的，因为它们以酸性特性换取速度。但就你的情况而言，据我所知，酸性物质的性质更为重要。

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

随着数据量或通信量的增加，您会发现几乎每一个数量级的增长都需要对体系结构进行更改来处理。也许你可以领先一点，但不是永远。你也无法提前预测瓶颈会在哪里

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

您可以废弃当前代码，将所有内容移动到MySQL或其他数据存储中，但要记住两件事：

• 没有一个数据库会允许您忽略扩展策略。您可以使用MySQL、PostgreSQL、MongoDB、Hadoop或其他任何工具，但仍然存在数据增长速度快于单个服务器上单个数据库所能处理的问题

• 出于更高效的开发或操作的内部原因，从头重写应用程序通常不划算（请阅读）

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

---

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

随着Redis即将推出的3.0，集群功能将可以投入生产。请看一看以获得概述。这对不断增长的数据量没有直接帮助，但我认为这会使您的设置更容易进行缩放/分片

你还可以考虑将“旧”数据从ReDIS移到另一个系统，例如在ReISIS河的帮助下进行弹性搜索：

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

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

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

除了redis，还有哪些数据库（关系数据库或非关系数据库）适合此用例

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

迁移到关系数据库时需要注意的一个权衡是，您可能会有更多的wor