日期列上的Server分区

Question

有两个表，Doc和DocDetail：

CREATE TABLE [Doc](

[ID] [int] IDENTITY(1,1) NOT NULL,
[DocTypeId] [int] NOT NULL,
[BusinessEntityId] [int] NOT NULL,
[Created] [datetime] NOT NULL CONSTRAINT [DF_Doc_Created] DEFAULT (getdate()),
[Updated] [datetime] NULL CONSTRAINT [DF_Doc_Updated] DEFAULT (getdate()),
[Active] [bit] NOT NULL CONSTRAINT [DF_Doc_Active]  DEFAULT ((1)),
[ReadOnly] [bit] NOT NULL CONSTRAINT [DF_Doc_ReadOnly]  DEFAULT ((0)),
CONSTRAINT [PK_Doc] PRIMARY KEY CLUSTERED ([ID] ASC) ) ON [PRIMARY]

 CREATE TABLE [dbo].[DocDetail](
[ID] [int] IDENTITY(1,1) NOT NULL,
[DocId] [int] NOT NULL,
[FieldId] [int] NOT NULL,
[RowNumber] [int] NULL,
[ParentRowNumber] [int] NULL,
[vString] [varchar](4096) NULL,
[vDate] [datetime] NULL,
[vTime] [time] NULL,
[vInteger] [int] NULL,
[vNumber] [decimal](26, 7) NULL,
[vReal] [float] NULL,
 CONSTRAINT [PK_DocDetail] PRIMARY KEY CLUSTERED ([ID] ASC)) ON [PRIMARY]

DocDetail将只填充一个vXXX列。其他的都是空的。

所有对表的访问都是通过几个存储的procs和一个视图进行的。如果需要的话，我可以添加列(比如DocDetail中的一个列，它重复Doc创建的日期，通过触发器填充以进行分区)，但是我不能重写这个应用程序。

DocDetail有超过10亿行，由于新的业务，每天增加大约900万行！过去，数据是通过根据Doc表创建的列将行移动到另一个数据库来“存档”的。随着时间的推移，它们会随着行的“老化”而从DB中移除。然而，额外的外部需求使我们无法继续这样做，而且数据正在迅速堆积。服务器有256 so内存和一个很好的SAN，它有大量的存储空间(到目前为止)。我有一个很好的测试环境来验证我的解决方案。

查看分区。大约45%的OLTP用于在过去30天内创建的数据。大约25%的数据显示在60天内(即30天以上，90天以下)。其余的则会在90天内缩短至约18个月。我需要保存7年的数据，但不一定都在这个数据库中。

对分区方案有什么建议吗？

Answer 1

查看我的演示文稿，了解SQL传递的有效数据仓库存储模式。

id=880

演示文稿回顾了以下技巧来解决你的困境。它有1.2M行数据库的工作代码。

Coverage:

1 – What is horizontal partitioning?
2 – Database sharding for daily information.
3 – Working with files and file groups.
3 – Partitioned views for performance.
4 – Table and Index partitions.
5 – Row Data Compression.
6 – Page Data Compression.
7 – Programming a sliding window.
8 – What are Federations in Azure SQL?

至于该走哪条路，这取决于你。

切分视图和分区视图都可以使用Server的标准版本完成。

数据压缩和表分区可在Server的企业版中使用。

由于您正在从头构建仓库，因此可以更改数据类型以占用空间。

我能够使用压缩和分区将一个4TB数据库重新组织成500 GB。

概括地说，日期和整数都是分区键的好候选者。

在我自己的仓库中，日期维度将日期映射为整数。

在测试环境中四处游玩，了解真正的重建是如何工作的。

祝好运。