hierarchyid是否適合頻繁插入葉節點的大樹？

我們有一個模型樹的數據庫。這些數據可能會變得相當龐大，也就是說可能有數百萬行。（主鍵實際上是bigint，所以我想我們可能會支持數十億行，儘管這可能永遠不會發生）。hierarchyid是否適合頻繁插入葉節點的大樹？

單個節點可以有非常大量的直接子元素，更可能是層次結構中的較高層級。我們對葉子的實際最大深度沒有特別的限制，即有多少個節點必須經過才能到達根部，但實際上這可能通常最多不會超過幾百個。通常情況下，它可能低於20.

此表中的插入非常頻繁，需要高性能。插入插入節點始終是葉節點，並始終在最後一個兄弟節點之後。節點永遠不會移動。刪除總是作爲整個子樹。查找子樹是在這張桌子上做的其他操作。它沒有相同的性能要求，但我們當然希望它儘可能快。

今天，這是用父/子模型建模的，這對於插入是有效的，但是對於找到子樹是很痛苦的。當表變大時，這變得非常緩慢，找到一個子樹可能需要幾分鐘時間。

所以我想轉換這可能使用SQL Server中的新的hierarchyid類型。但是我有麻煩找出這是否合適。正如我對它所做的那樣，對於我們在這種情況下執行的操作，這樣的樹會是一個好主意。（如果我在這裏錯了，請糾正我）。

但它也表明hierarchyid的最大大小是892字節。但是，我無法找到任何關於這在實踐中意味着什麼的信息。 hierarchyid是如何編碼的？我是否會耗盡hierarchyids，如果是的話，何時？

來源

2013-10-16 DeCaf

所以我做了一些測試，來到有些關於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

我會去水平在我發現錯誤之前。由於我對每個級別使用的值爲1，因此應該是最緊湊的樹，從中得出結論，我永遠無法創建超過級別的樹。

不過，如果我使用例如99999999999999每個級別（例如：/99999999999999/99999999999999/99999999999999/...，已經在水平出現錯誤很深。這也似乎14位是在每個級別的ID最大，因爲它失敗因此，如果我只使用整數標識符（即不要在其他節點之間插入節點等），我應該能夠保證最多至少100個在任何時候我都不能超過1400多個級別。

來源

2013-10-19 20:13:06 DeCaf

892字節聽起來不太多，但層次結構id似乎非常有效，空間明智。從http://technet.microsoft.com/en-us/library/bb677290.aspx：

所需要的表示在樹中的節點與n個節點的位的平均數量取決於平均扇出（一個節點的子節點的平均數量）。對於小扇出（0-7），大小約爲6 * logAn位，其中A是平均扇出。在平均扇出6級的10萬人的組織層級中的節點大約需要38位。這被四捨五入爲40位或5個字節用於存儲。

給出的計算結果表明它只適用於小扇出（0-7），這使得很難推斷更大的扇出。你說'最多有幾百個孩子'。這（極端）情況聽起來很危險。我不知道hierarchy_id的規範，但是更多的節點在任何一個級別上，在這些892字節內樹中應該能夠擁有的深度越小。

我確實在這裏看到風險，因爲你（因此是問題）。做一些測試。評估目標。你從哪裏搬來？你爲什麼要搬家？簡單或性能？

這個問題不適合Sql。也許你應該考慮這部分程序的其他選項？

來源

2013-10-18 22:38:58

其實892字節是相當多的，考慮到8字節用於代表表格中的主鍵。 ;）但是我真的在尋找一些有關hierarchyid類型的編碼的事實，以找出這些限制。如果我做的任何測試都沒有失敗，那並不能證明它不會因另一種（類似的）情況而失敗。引入hierarchyids的原因絕對是出於性能原因。但是，離開SQL不是目前的選擇。 – DeCaf

hierarchyid是否適合頻繁插入葉節點的大樹？

回答

相關問題