mysql - 如何构建一个非常大的表

Question

这更像是一个概念性问题。它的灵感来自于使用一些非常大的表，即使是一个简单的查询也需要很长时间(正确索引)。我想知道是否有比让表格不断增长更好的结构。

总的来说，我的意思是 10,000,000 多条记录每天增长大约 10,000 条/天。像这样的表每 2.7 年就会增加 10,000,000 条记录。可以说最近的记录访问次数最多，但较旧的记录需要保持可用。我有两个概念性想法可以加快速度。

1) 维护一个包含所有数据的主表，按日期倒序索引。为每年创建一个单独的 View ，仅包含该年的数据。然后在查询时，假设查询预计只从三年跨度中提取几条记录，我可以使用联合来组合三个 View 并从中进行选择。

2) 另一种选择是为每年创建一个单独的表。然后，在查询时再次使用联合将它们组合起来。

还有其他人有任何其他想法或概念吗？我知道这是 Facebook 面临的一个问题，那么你认为他们是如何处理的？我怀疑他们有一个包含 100,000,000,000 条记录的表 (status_updates)。

Answer 1

主要的 RDBMS 提供者在分区表和分区 View (以及两者的组合)方面都有相似的概念

有一个直接的好处，因为数据现在被拆分到多个概念表中，因此任何在查询中包含分区键的查询都可以自动忽略键不在其中的任何分区。

从 RDBMS 管理的角度来看，将数据划分为单独的分区允许在分区级别执行操作、备份/恢复/索引等。这有助于减少停机时间，并通过仅删除整个一次分区。

也有非关系存储机制，如 nosql、map reduce 等，但最终如何使用、加载和归档数据成为决定使用结构的驱动因素。

1000 万行在大型系统的规模上并不算大，分区系统可以而且将会容纳数十亿行。