大容量数据库

Posted 2023-04-12

【中文标题】大容量数据库

【英文标题】：Large Volume Database

【发布时间】：2011-06-01 06:21:12

【问题描述】：

我们正在创建一个存储大量记录的数据库。我们估计一张表中有数百万（几年后数十亿）的记录，我们总是插入并且很少更新或删除任何记录。它是一种存档系统，我们每天都会在其中插入历史记录。我们将根据用户请求生成有关此历史记录的不同类型的报告，因此我们有一些顾虑并需要您提供技术意见：

管理这种表和数据库的最佳方法是什么？ 对于超大表，我们将来会看到什么影响？ 一张表的记录数或表的大小是否有限制？ 我们假设如何插入来自不同来源（主要来自 Excel 工作表）的批量记录？ 索引大型数据表的最佳方法是什么？ 我们应该在这个项目中使用哪种最好的 ORM（对象关系映射）？

【问题讨论】：

一篇文章中有很多问题 - 并非所有问题都与“”相关 - 您最好将其中一些问题拆分出来并提供更多信息。

这已经在dba.se关闭，因为它太宽泛了

您需要的是一名数据库专家，最好在大容量系统方面拥有至少十年的经验。

【参考方案1】：

你最后的陈述总结了它。没有 ORM 可以很好地处理如此大量的数据和报告查询：聘请 SQL 专家为您完成。你先在这里听到的。

否则

在磁盘上：文件组、分区等 压缩不常用的数据 是否需要所有数据？ （数据保留政策） 行数或表格大小没有限制 通过临时表或临时数据库插入，清理/清理/查找键，然后刷新到主表：

不要

直接加载主表 尽可能多的 RAM。然后添加更多。 很少的高效索引 您有父表或平面数据集市吗？有 FK 但不使用它们（例如在父表中更新/删除），因此不需要索引 使用 SAN（更容易添加磁盘空间、更多卷等） 标准化

其中一些基于我们在 30 个月内通过我们的一个系统处理大约 100 亿行的经验，峰值为每秒 40k 以上。

对于高容量系统也可以查看此内容：10 lessons from 35K tps

总结：做对了还是不做……

【讨论】：

当然，如果您打算拥有一个大容量系统，请聘请专家来设计它。

【参考方案2】：

管理这种表和数据库的最佳方法是什么？

如果您计划存储数十亿条记录，那么您将需要大量磁盘空间，我建议您使用运行 SQL 2008 R2 的 64 位操作系统以及尽可能多的 RAM 和 HD 空间。根据您需要的性能，我很想研究 SSD。

未来我们可能会看到超大表会产生什么影响？

如果您拥有正确的硬件、正确索引的表并正确规范化，那么您应该注意到的唯一一件事是报告的运行速度将开始变慢。随着索引文件变大，插入可能会稍微变慢，您只需要留意它。

一张表的记录数或表的大小是否有限制？

在我上面描述的正确设置上，不。它仅受磁盘空间的限制。

我们假设如何插入来自不同来源（主要来自 Excel 工作表）的批量记录？

我在运行大型 SQL 查询时遇到了问题，但我从未尝试从非常大的平面文件中导入。

索引大型数据表的最佳方法是什么？

根据需要索引尽可能少的字段，并将它们保留为数字字段。

我们应该在这个项目中使用哪种最好的 ORM（对象关系映射）？

很抱歉，这里不能提供建议。

【参考方案3】：

“几年”中的数十亿行并不是一个特别大的数量。 SQL Server 应该可以很好地应对它——假设您的设计和实现是适当的。对表的大小没有特别限制。坚持可靠的设计原则：规范化您的表，仔细选择键和数据类型，并制定合适的分区和索引策略。