mysql - 从redis 切换到Mysql。好主意？

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

因此，寻求一些建议:

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

2. 除了 Redis 之外，还有哪些其他数据库(关系型或非关系型)适合此用例？

3. 或者我们都错了，因为redis就是为存储这种类型的数据而生的。所以，我们只是继续使用 Redis 并每月升级我们的机器？

Answer 1

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

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

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

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

• 没有任何数据库可以让您忽略扩展策略。您可以使用 MySQL、PostgreSQL、MongoDB、Hadoop 或其他任何工具，但您仍然会遇到数据增长速度超过单个服务器上的单个数据库可以处理的问题。

• 出于更高效的开发或运营的内部原因，从头开始重写您的应用程序通常不符合成本效益(阅读 Things You Should Never Do, Part I by Joel Spolsky)。

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

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