MySQL产品存储-架构

Question

我需要为应用程序制定架构。它专为销售产品而设计。

系统每天将接受大约 30-40k 的新产品。它将导致在表 product 中创建新记录。

系统应保留价格历史记录。用户应该能够看到产品 A 的价格在去年发生了怎样的变化。

所以我有两个选择:

1. 当新产品出现时，我将旧产品移动(复制并删除)到另一个表。我们将其命名为 product_history 。所以 product 表只包含目前正在销售的产品。结果我将需要重写查询，因为来自产品的行可以在表 product 或表 product_history 中(如果客户想查看销售历史、统计信息等)。

2. 没有任何东西被删除。我将旧产品放在同一张表中，并使用某些属性(“is_old”)将它们标记为旧产品。新记录由 Redis 索引。

解决方案 2 使代码更简单，但我担心表会变得太大。 优点是没有数据复制。没有搞乱删除。

方案一对系统的支持度更高。事件表 product 将始终保持较小。但是总是玩两张 table 比玩一张 table 更难。

有一点需要注意，与问题无关，但这让事情变得有点复杂:每个产品最多可以有 12 个不同的价格(将来可能会更多)。因此字段价格存储为 json 并已被 Redis 索引。

哪种解决方案将来会带来更少的痛苦？你会选择哪一个？

Answer 1

我的选择是:1. 选择选项#2，它更干净，选项#1 的迁移部分增加了写入负载和复杂性。

1. 为每个产品项目使用“事件”标志，默认情况下为 1 或 true。

2. 根据事件标志对表进行分区，以便事件项目(唯一查询的项目)位于单个分区中，而非事件项目位于其他分区中。

3. 对于定价，不要将 json 存储为 varchar/text，使用 native JSON field ( mysql 5.7+)，它将允许您在 JSON 中进行更丰富的查询。

4. 对于 redis 同步，我还建议探索 debezium将 mysql 更改流式传输到 redis。