sql-server - SQL Server - 是基于 GUID 的 PK，支持基于租户的水平分区的最佳实践

Question

我正在尝试找出设计 future 需要水平分区的 Multi-Tenancy 数据库架构时的最佳方法。

数据库中的一些粗略数字..

租户总数约为10,000人。每个租户存储的数据量在 500MB -> 3GB 之间变化。租户数量一开始会很小，几年后会增长到 10,000 个，因此最初我们可以从单个 Multi-Tenancy 数据库开始，但从长远来看，这将需要水平扩展以提高性能原因。

更新 - 一个复杂的因素是有时租户(公司)可以合并在一起，我也需要支持这一点......，

Multi-Tenancy 将使用本文 http://msdn.microsoft.com/en-us/library/aa479086.aspx 中描述的共享数据库、共享架构架构来实现。

考虑到我们将来将面临水平分区，并且在事情稳定下来之前我们可能会多次将客户端从一个数据库移动到另一个数据库，我认为最好使用 GUID 作为主键每个表上都有一个唯一的tenantID 列。

我知道使用 GUID 作为主键会带来性能开销，但这是否是我需要接受的权衡？以后有没有其他的方式来设计水平分区？？

这是一个例子 - 假设我想在未来合并租户为 100 和 200 的公司，如果 PK 是一个整数，当我将行从数据库 2 复制到数据库 1 时可能会发生冲突，使用 {guids} 我保证不会发生冲突...

数据库1 数据库2租户ID、ID、描述 租户ID、ID、描述100 ,1 ,'富' 200 ,1 ,'xxx'100 ,2 , '嘘' 200 ,2 , 'yyy'

数据库1 数据库2租户ID、ID、描述 租户ID、ID、描述100 ,{aaa} , 'foo' 200 ,{ccc} , 'xxx'100 ,{bbb} , '嘘' 200 ,{ddd} , 'yyy'

Answer 1

GUID 似乎是主键的自然选择 - 如果您确实必须这样做，您可能会争论将其用作表的主键。我强烈建议不要这样做，即使用 GUID 列作为聚集键，这是 SQL Server 默认执行的操作，除非您明确告诉它不要这样做。 p>

您确实需要分开两个问题:

1) 主键是一个逻辑结构 - 唯一且可靠地标识表中每一行的候选键之一。这实际上可以是任何东西 - INT、GUID、字符串 - 选择最适合您的场景的内容。

2) 聚集键(定义表上“聚集索引”的一列或多列) - 这是一个物理与存储相关的东西，在这里，小型、稳定、不断增加的数据类型是您的最佳选择 - INT 或 BIGINT 作为您的默认选项。

默认情况下，SQL Server 表上的主键也用作聚簇键 - 但不必如此!我个人看到，将以前基于 GUID 的主键/聚集键分解为两个单独的键 - GUID 上的主(逻辑)键和单独的 INT IDENTITY(1, 1)专栏。

如Kimberly Tripp - 索引女王 - 和其他人已经说过很多次 - GUID 作为集群键并不是最佳的，因为由于它的随机性，它将导致大量页面和索引碎片以及通常较差的性能。

是的，我知道 - SQL Server 2005 及更高版本中有 newsequentialid() - 但即便如此，它也不是真正且完全顺序的，因此也会遇到与 GUID 相同的问题 - 只是有一点点不太明显。

然后还有另一个问题需要考虑:表上的聚集键也将添加到表上每个非聚集索引的每个条目中 - 因此您确实希望确保它尽可能小。通常，具有 2+ 十亿行的 INT 对于绝大多数表来说应该足够了 - 与作为集群键的 GUID 相比，您可以在磁盘和服务器内存中节省数百兆字节的存储空间。

快速计算 - 使用 INT 与 GUID 作为主键和聚类键:

• 具有 1'000'000 行的基表(3.8 MB 与 15.26 MB)
• 6 个非聚集索引(22.89 MB 与 91.55 MB)

总计:25 MB 与 106 MB - 而且这只是在一个表上!

还有一些值得深思的东西 - Kimberly Tripp 写的很棒的东西 - 读它，再读它，消化它!这确实是 SQL Server 索引福音。

• GUIDs as PRIMARY KEY and/or clustered key
• The clustered index debate continues
• Ever-increasing clustering key - the Clustered Index Debate..........again!
• Disk space is cheap - that's not the point!

马克