大容量数据库

Question

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

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

Answer 1

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

否则

• 在磁盘上：文件组，分区等
• 压缩使用较少的数据
• 是否需要所有数据？ （数据保留政策）
• 行号或表格大小没有限制
• 通过登台表或登台数据库INSERT，清理/清理/查找键，然后刷新到主表：不要直接加载主表
• 尽可能多的RAM。然后添加更多。
• 很少有效的索引
• 您有父表或平面数据集市吗？有FK但不使用它们（例如父表中的bene update / delete）因此不需要索引
• 使用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应该很好地应对它 - 假设您的设计和实现是合适的。表的大小没有特别限制。坚持坚实的设计原则：规范化表格，仔细选择密钥和数据类型，并采用合适的分区和索引策略。