sql - hierarchyid适合频繁插入叶子节点的大树吗？

Question

我们有一个对树进行建模的数据库。该数据可能会增长得相当巨大，也就是说，可能有数百万行。 (主键实际上是一个bigint，所以我想我们可能希望支持数十亿行，尽管这可能永远不会发生)。

单个节点可以有大量的直接子节点，它们在层次结构中的位置越高。我们对叶子的实际最大深度没有指定限制，即必须遍历多少个节点才能到达根，但实际上，这通常最多不会超过几百个。通常情况下它可能会低于 20。

此表中的插入非常频繁，并且需要高性能。插入的插入节点始终是叶节点，并且始终位于最后一个兄弟节点之后。节点永远不会移动。删除总是作为整个子树进行。查找子树是对该表进行的另一个操作。它没有相同的性能要求，但我们当然希望它尽可能快。

如今，这是使用父/子模型进行建模的，该模型对于插入非常有效，但对于查找子树来说却非常缓慢。当表变大时，这会变得非常慢，查找子树可能需要几分钟。

所以我正在考虑将其转换为可能使用 SQL Server 中的新的 hierarchyid 类型。但我很难确定这是否合适。据我了解，对于我们在这种情况下执行的操作，这样的树将是一个好主意。 (如果我在这里错了，请纠正我)。

但它还指出，hierarchyid 的最大大小为 892 字节。但是，我找不到任何有关这在实践中意味着什么的信息。 hierarchyid是如何编码的？我会用完hierarchyid吗？如果是的话，什么时候会用完？

Answer 1

所以我做了一些测试，并得出了关于 hierarchyid 局限性的一些结论:

如果我运行以下代码:

DECLARE @i BIGINT = 1
DECLARE @h  hierarchyId = '/'
WHILE 1=1
BEGIN
    SET @h = @h.ToString() + '1/'
    PRINT CONVERT(nvarchar(max), @i) 
    SET @i = @i+1
END

在出现错误之前，我将达到 1427 级别。由于我对每个级别使用值 1，因此这应该是最紧凑的树，从中我得出结论，我将永远无法创建超过 1427 的树 级别。

但是，如果我对每个级别使用例如99999999999999(例如/99999999999999/99999999999999/99999999999999/...，则错误已经发生在 118 级深。似乎 14 位数字是每个级别 id 的最大值，因为如果我使用 15 位数字，它会立即失败。

因此，考虑到这一点，如果我只使用整个整数标识符(即不要在其他节点之间插入节点等)，我应该能够保证在我的场景中至少有 100 层深度，而且在任何时候我能突破 1400 级以上吗？