我目前正在设计一个基于MSSQL 2016的平台,以处理将超过PetaByte级别的数据集(OLTP )。它将用于特定类型的分析,需要使用各种方法和工具来发现趋势。r)。将有各种来源在“实时”的基础上输入数据库(S),以及批量摄入的数据。由于大量事务、预计的并发用户数量(>250)以及用户使用数据的方式(稍后更多),我们需要该解决方案具有高性能和可伸缩性。显然,数据需要在几个级别上进行分区,以支持数据使用者。
用户将在每日、每周、每月和多年范围内运行趋势分析类型的工作量。大多数数据将提供日期字段,但客户名称、帐号和交易类型也在进行趋势分析的范围内。
我向大家提出的问题如下:您的策略是如何设计适当的分区解决方案?你会问什么问题,你会在答案中寻找什么?你怎么处理索引的维护之类的..。你会在设计中考虑什么?
哦,把所有的东西都放到一个数据蛋糕(读:沼泽)或去一个不同的平台不是一种选择。此外,我没有自由讨论项目的细节或所涉及的数据,所以请不要问。只要知道这是高度机密的财务和个人数据,我们将进行法医分析(使用R,PowerBI和/或其他BI工具),以符合对我们的合法要求。我不会再分享任何其他细节了,对不起。
发布于 2017-01-23 11:56:18
我建议您阅读本文,描述OLTP数据库的一些重要先决条件和建议。
http://nerdtechies.com/2016/12/05/improve-write-performance-sql-server-database/
对于加载过程,使用BULK INSERT和普通插入用户WITH(ROWLOCK)。
https://technet.microsoft.com/en-us/library/dd425070.aspx
分区
你需要知道的。
--我在2TB表上有经验,每天增长50 TB,一个月的生产数据在WH上。因此相应地建议。
如果每天使用70%-80%的基础分析报告。我建议每天进行基础分区,因为会有大量的数据。它将执行得更快,但要生成每周、每月和年度报告,您将有冗长的查询。
如果在每日、每周和每月分析之间有50到50的比率,那么就进行月划分。在这种情况下,Daily和Weekly的执行速度将比日基分区慢,因为从这个月开始有很多记录要过滤。但您将有相当简单的查询。
通过考虑在线数据的保留来进行分区使归档策略更容易。
索引
由于表将被分区,您应该在table.To创建分区索引上创建分区索引,您需要在索引中包括分区基列。除非您不在分区表上创建分区索引,否则您将无法获得性能上的好处。
在单独的文件组上创建索引将为报表带来良好的性能。因此,在单独的文件组上为与为表创建的索引相同的索引创建单独的分区方案和函数。
最好选择Index_Partition_Scheme上的列存储索引(Index_Partition_Scheme、客户名称、帐号、交易类型、财务栏)。
用FILLFACTOR=80创建索引
创建分区索引使索引维护变得更容易。与重建或重新组织完整索引不同,您可以对索引的特定分区执行维护任务,这将最大限度地减少大型表的维护时间。
为此,您可以跟踪分区的索引、分段和行计数。它将帮助您找到应该在哪个分区上重新构建的索引。
维护计划取决于数据大小、执行维护活动的时间长短以及Server完成任务所需的时间。最好先用相同数量的数据测试您在测试环境上的维护计划,然后如果它在空闲时间内完成,则转移到生产中。
谢谢
https://dba.stackexchange.com/questions/161934
复制相似问题