2012-04-04 80 views
5

我想創建一個總是由唯一鍵訪問的大型表(大約450億行)。SQL Server中的Hashset相當於

在數據庫之外,最好的結構是一個Dictionary或一個HashSet,但是當然由於數據的大小,在數據庫之外不可能這樣做。

SQL Server是否提供針對鍵值訪問進行了優化的結構?我知道聚集鍵非常快,但它仍然是一個索引,因此會有一些額外的磁盤讀取與遍歷索引頁相關聯。我想從SQL Server中獲得的是一種「本機」結構,它將數據存儲爲鍵值對,然後可以根據鍵訪問值。

換句話說,我的問題是如何在SQL Server中存儲45億行,並且無需索引,集羣或非集羣就可以高效地訪問它們,因爲讀取索引非葉頁可能會導致大量的IO,並且由於每個值都可以通過一個唯一的鍵來訪問,因此應該有一種結構,其中鍵的散列可以解析爲該值的物理位置。要獲得1個值,我們需要進行1次讀取(除非有散列衝突)。

(在Oracle中相當於散列簇)

感謝您的幫助。

回答

3

沒有這樣的事情在SQL服務器。你唯一的選擇是索引。如果您打算請求給定鍵的所有列,則應使用聚集索引。如果你只打算被請求的一個子集,你應該使用一個非聚集索引只包括你想要這樣的列:

create index IX_MyBigTable on MyBigTable(keyColumn) include (col1, col2, col3youneed); 

這將是非常有效的。

+0

遍歷一個b-tree的效率可能不如生成一個散列值那麼有效,並且在SQL Server中聚簇索引非常重要的原因是數據行存儲在葉級別。因此,爲您的索引鍵命中b樹葉的讀取也讀取該鍵的數據行 – Rick 2012-04-04 18:17:51

+0

此答案正確。中間索引級別將很小並且完全緩存。基本上,任何通過PK進入這樣的表格最多隻需要一個IO。與使用磁盤哈希表相比,您甚至可以從關鍵位置獲益。 – usr 2012-04-04 20:34:00

+0

隨機推薦 - 如果你真的真的100%只做鍵值查找,而不是任何類型的關係查詢,也許SQL不是你的答案?查看Redis - 它不可思議的快速,事務性,一致性,磁盤持久性,易於設置 - 聽起來似乎更適合。 http://redis.io – 2012-04-04 20:46:02

0

根據我的基準,最好的方法是爲密鑰創建哈希列。 Details