如何构建一个非常大的表

Question

这是一个概念性问题。它的灵感来自于使用一些非常大的表，即使是简单的查询也需要很长时间（正确编制索引）。我想知道是否有一个更好的结构然后只是让桌子不断增长。

从大到大，我的意思是10,000,000条记录每天增长10,000次/天。像这样的表每2.7年会有10,000,000条额外的记录。让我们说最近的记录访问量最多，但旧的记录需要保持可用。 我有两个概念性的想法来加快它。

1）维护一个包含所有数据的主表，按日期按相反顺序编制索引。为每年创建一个单独的视图，该视图仅包含该年份的数据。然后在查询时，让我们说查询预计只会从三年的时间内拉出几条记录，我可以使用一个联合来组合三个视图并从中选择。

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

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

Answer 1

主要的RDBMS提供程序在分区表和分区视图（以及两者的组合）方面都有类似的概念

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

从RDBMS管理的角度来看，将数据划分为单独的分区允许在分区级别执行操作，备份/恢复/索引等。这有助于减少停机时间，并且只需删除整个数据就可以实现更快的归档一次分区。

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

1000万行在大型系统的规模上并不大，分区系统可以并且将保持数十亿行。

Answer 2

你的第二个想法看起来像是分区。

我不知道它有多好用，但MySQL支持分区 - 请参阅手册：Chapter 17. Partitioning

Answer 3

这个表有很好的可扩展性方法。联盟是正确的方式，但有更好的方式。

如果您的数据库引擎支持“语义分区”，那么您可以将一个表拆分为分区。每个分区将覆盖一些子范围（例如每年1个分区）。除了DDL之外，它不会影响SQL语法中的任何内容。引擎将透明地运行隐藏的联合逻辑和分区索引扫描，它具有所有并行硬件（CPU，I / O，存储）。

例如，Sybase最多允许255个分区，因为它是union的限制。但是你永远不会在查询中使用关键字“union”。

Answer 4

通常最好的计划是拥有一个表，然后使用数据库分区。

或者，您可以归档数据并为归档和组合数据创建视图，并仅保留大多数函数引用的表中的活动数据。您必须拥有良好的归档策略（这是自动化的），否则您可能会丢失数据或在移动数据时无法有效地完成任务。这通常更难维护。

Answer 5

您所谈论的是横向分区或sharding。