问题描述
|
我们正在创建一个数据库，用于存储大量记录。我们估计一张表中有几百万条记录（几年后为数十亿美元），并且我们始终会插入并且很少会更新或删除任何记录。它是一种存档系统，我们每天都在其中插入历史记录。我们会根据用户要求在此历史记录上生成不同类型的报告，因此我们有些担忧，需要您提供技术方面的帮助：
管理此类表和数据库的最佳方法是什么？
我们将来对于超大桌子会看到什么影响？
一个表中的记录数或表的大小是否有限制？
我们如何假设从不同来源（主要是从Excel工作表）插入批量记录？
索引大型数据表的最佳方法是什么？
在此项目中，我们应该使用哪种最佳的ORM（对象关系映射）？
解决方法
您最后的陈述总结了一下。没有ORM可以很好地处理这种数据量和报告查询：请聘请SQL专家为您做。您首先在这里听到。
除此以外
在磁盘上：文件组，分区等
压缩较少使用的数据
是否需要所有数据？ （数据保留政策）
行数或表大小无限制
通过登台表或登台数据库，清理/清理/查找键插入，然后刷新到主表：请勿直接加载主表
您可以购买尽可能多的RAM。然后添加更多。
很少有有效的索引
您是否有父表或平面数据集市？有FK但不使用它们（例如，父表中的bene更新/删除），因此不需要索引
使用SAN（更容易添加磁盘空间，更多卷等）
归一化
其中一些是基于我们在30个月内通过其中一个系统进行的大约100亿行的经验，峰值为每秒4万行以上。
对于大容量系统，也请参见：从35K tps汲取10堂课
摘要：正确执行或根本不执行...
, 管理此类表和数据库的最佳方法是什么？
如果您打算存储数十亿条记录，那么您将需要大量的磁盘空间，我建议您使用运行SQL 2008 R2的64位操作系统以及尽可能多的RAM和HD空间。根据您需要的性能，我很想研究SSD。
我们将来对于超大桌子会看到什么影响？
如果您拥有正确的硬件，并且具有正确的索引表和正确的规范化，则您应该注意的唯一事情是报告将开始运行得更慢。随着索引文件变大，插入内容可能会略微减慢，您只需要注意它即可。
一个表中的记录数或表的大小是否有限制？
在上面我描述的正确设置上，没有。它仅受磁盘空间限制。
我们如何假设从不同来源（主要是从Excel工作表）插入批量记录？
我在运行大型SQL查询时遇到了问题，但是我从未尝试过从非常大的平面文件中导入。
索引大型数据表的最佳方法是什么？
索引尽可能少的字段，并将其保留为仅数字字段。
在此项目中，我们应该使用哪种最佳的ORM（对象关系映射）？
抱歉，不能在这里建议。
, “几年”中的数十亿行并不是特别大的数量。 SQL Server应该可以很好地应对它-假设您的设计和实现是适当的。表的大小没有特别限制。坚持坚实的设计原则：规范化表，仔细选择键和数据类型，并具有合适的分区和索引策略。