Ala*_*Dee 7 mysql sql database data-structures
这是一个概念性问题.它的灵感来自于使用一些非常大的表,即使是简单的查询也需要很长时间(正确索引).我想知道是否有一个更好的结构然后只是让桌子不断增长.
从大到大,我的意思是10,000,000条记录,每天增长10,000次/天.像这样的表每2.7年会有10,000,000条额外的记录.让我们说最近的记录访问量最多,但旧的记录需要保持可用.我有两个概念性的想法来加快它.
1)维护一个包含所有数据的主表,按日期按相反顺序编制索引.为每年创建一个单独的视图,该视图仅包含该年份的数据.然后在查询时,让我们说查询预计只会从三年跨度中提取几条记录,我可以使用联合来组合三个视图并从中进行选择.
2)另一种选择是为每年创建一个单独的表.然后,在查询时再次使用union来组合它们.
还有其他人有任何其他想法或概念吗？我知道这是Facebook面临的一个问题,那么您认为他们如何处理呢？我怀疑他们有一个包含100,000,000,000条记录的表(status_updates).
主要的 RDBMS 提供商在分区表和分区视图（以及两者的组合）方面都有相似的概念
有一个直接的好处，因为数据现在被分割到多个概念表中，因此任何在查询中包含分区键的查询都可以自动忽略该键不存在的任何分区。
从 RDBMS 管理的角度来看，将数据划分为单独的分区允许在分区级别执行操作、备份/恢复/索引等。这有助于减少停机时间，并且只需在某个位置删除整个分区即可实现更快的归档速度。时间。
还有非关系型存储机制，例如nosql、mapreduce等，但最终如何使用、加载和归档数据成为决定使用结构的驱动因素。
对于大型系统来说，1000 万行并不算大，分区系统可以并且将会容纳数十亿行。