大容量数据库

如何解决大容量数据库

| 我们正在创建一个数据库，用于存储大量记录。我们估计一张表中有几百万条记录（几年后为数十亿美元），并且我们始终会插入并且很少会更新或删除任何记录。它是一种存档系统，我们每天都在其中插入历史记录。我们会根据用户要求在此历史记录上生成不同类型的报告，因此我们有些担忧，需要您提供技术方面的帮助： 管理此类表和数据库的最佳方法是什么？ 我们将来对于超大桌子会看到什么影响？ 一个表中的记录数或表的大小是否有限制？ 我们如何假设从不同来源（主要是从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应该可以很好地应对它-假设您的设计和实现是适当的。表的大小没有特别限制。坚持坚实的设计原则：规范化表，仔细选择键和数据类型，并具有合适的分区和索引策略。