2

我有一个非常大的 MySQL 表，它太大而无法频繁查询（500m+ 行）。我所做的是将我需要的结果缓存在另一个名为“最近”的表中。

在“最近”表中，架构看起来像这样

用户身份

PAGE_ID

显示顺序

我在 USER_ID 和 DISPLAY_ORDER 上放置了一个唯一索引，因为我只想在此表中为每个用户存储最多 64 条记录。因此，DISPLAY_ORDER 只是一个最多可达 64 的 int。使用 REPLACE INTO 更新行。

这是一个好方法吗？或者，一旦用户点击超过 64 行，我应该定期从表中删除数据。我需要考虑性能。在接下来的几个月里，5 亿的主表将增长到 10 亿，每个用户有 64 行，这意味着“最近”表也将非常大......

谢谢你的帮助。

4

2 回答 2

0

如果我是你，我会认真考虑迁移到大数据 NoSQL 数据库。像 Cassandra 或 HBase 这样的东西，它们在处理大量数据时都具有非常好的性能。让 5-10 个集群节点使用 MapReduce 为您完成工作，而不是一个巨大的单片服务器试图扫描和查找那么多记录。

于 2014-04-24T20:33:14.563 回答
0

我同意 Eggyal 和 Todd Nakamura 的观点。

eggyal : 对数据进行分区
在处理如此大的数据集时，您确实需要对数据进行分区，这样您就有机会在数据的子集上运行查询而不是对整个数据进行查询。

Todd Nakamura：研究一种不同的数据库技术。
这个问题看起来确实像 NoSQL 数据存储会是一个很好的解决方案。它将允许非常大的数据集，以及使用 Map/Reduce (Hadoop) 来并行化查询的能力。

于 2014-04-24T20:54:58.570 回答