非常庞大的SQL数据库:架构应该如何？

Question

我有2个文件,我想导入MS SQL.第一个文件是2.2 GB,第二个文件是24 GB的数据.(如果你很好奇:这是一个扑克相关的查找表)

将它们导入MS SQL不是问题.感谢SqlBulkCopy,我能够在10分钟内导入第一个文件.我的问题是,我不知道实际的表架构应该如何让我做一些非常快速的查询.我的第一次天真尝试看起来像这样:

CREATE TABLE [dbo].[tblFlopHands](
    [hand_id] [int] IDENTITY(1,1) NOT NULL,
    [flop_index] [smallint] NULL,
    [hand_index] [smallint] NULL,
    [hs1] [real] NULL,
    [ppot1] [real] NULL,
    [hs2] [real] NULL,
    [ppot2] [real] NULL,
    [hs3] [real] NULL,
    [ppot3] [real] NULL,
    [hs4] [real] NULL,
    [ppot4] [real] NULL,
    [hs5] [real] NULL,
    [ppot5] [real] NULL,
    [hs6] [real] NULL,
    [ppot6] [real] NULL,
    [hs7] [real] NULL,
    [ppot7] [real] NULL,
    [hs8] [real] NULL,
    [ppot8] [real] NULL,
    [hs9] [real] NULL,
    [ppot9] [real] NULL,
 CONSTRAINT [PK_tblFlopHands] PRIMARY KEY CLUSTERED 
(
    [hand_id] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

翻牌指数是1到22100之间的值(德州扑克中的前3张普通牌,52则选择3张).每个翻牌指数都有一个1到1176的hand_index(49选择2).因此,此表中总共有25,989,600行.

使用我上面的"架构"进行查询大约需要.25秒 经过一些谷歌搜索后,我发现SQL服务器正在进行表扫描,这显然是一件坏事.我运行了"数据库引擎优化顾问",它建议在flop_index列上创建一个索引(有意义).创建索引后,数据库所需的磁盘空间正好翻了一倍!(加上日志LDF文件增长了2.6 GB)但是在索引之后,查询只需要几毫秒.

现在我的问题是,我该怎么做正确的方法？我从未使用过如此庞大的数据,我之前创建的数据库是一个笑话.

需要注意的一些事项:将数据导入MS SQL后,永远不会有数据的插入或更新,只需选择.所以我想知道我是否需要一把主键？

编辑:我提供了一些更多的信息,以使我的问题更清楚:

1)我永远不会使用hand_id.我只是把它放在那里,因为很久以前有人告诉我,我应该总是为每个表创建一个主键.

2)我将使用基本上只有一个查询:

SELECT hand_index, hs1, ppot1, hs2, ppot2, hs3, ppot3, hs4, ppot4, hs5, ppot5, hs6, ppot6, hs7, ppot7, hs8, ppot8, hs9, ppot9 WHERE flop_index = 1...22100

此查询将始终返回包含我需要的数据的1176行.

EDIT2:更具体一点:是的,这是静态数据.我在二进制文件中有这些数据.我编写了一个程序,用几毫秒的时间查询我需要的数据.我想在数据库中使用这些数据的原因是我希望能够从网络中的不同计算机查询数据,而无需在每台计算机上复制25 GB.

HS意味着力量,它会告诉你当前的牌位与翻牌或转牌相结合的手牌强度.ppot意味着积极的潜力,这是你的手在下一张普通牌被处理后领先的可能性.hs1到9是1到9个对手的手势.对于ppot也是如此.动态计算ppot是非常密集的,需要花费几分钟来计算.我想创建一个扑克分析程序,它给出了一个列表,列出了每个可能的底牌组合在任何翻牌/转牌时的hs/ppot.

Answer 1

这是一个很常见的问题。创建索引时，可能会减少查询所需的时间，但会增加更新/插入所需的时间，并且还会增加每条记录所需的磁盘空间量。

您需要为每一列确定索引是否为查询提供性能提升，以及是否保证对插入/更新性能和磁盘空间利用率产生影响。

作为索引的替代方案，您也许可以使用OLAP 多维数据集。如果您的查询正在生成聚合或应用计算，那么您可能需要考虑每晚执行查询并将结果存储在不同的表中。您可以对较小的表运行更简单的查询，并获得相同的结果，同时对性能的影响较小。