大容量数据库

Question

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

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

Answer 1

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

否则

• 在磁盘上：文件组、分区等
• 压缩不常用的数据
• 是否需要所有数据？ （数据保留政策）
• 行数或表格大小没有限制
• 通过临时表或临时数据库插入，清理/清理/查找键，然后刷新到主表：不要直接加载主表
• 尽可能多的 RAM。然后添加更多。
• 很少的高效索引
• 您有父表或平面数据集市吗？有 FK 但不使用它们（例如在父表中更新/删除），因此不需要索引
• 使用 SAN（更容易添加磁盘空间、更多卷等）
• 标准化

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

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

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

Answer 2

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

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

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

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

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

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

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

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

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

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

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

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

Answer 3

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