一、QQ這種大型數據庫是怎么實現數據瞬間查詢的

不要總覺得大型互聯網公司的數據存儲結構會有多復雜。實際上簡單得很，大部分都比你在大學 SQL 課上創建的數據庫還要簡單。越核心的數據，其存儲結構越簡單。簡單的才可靠。

像 QQ 這種，最核心的數據，一是用戶信息，二是好友關系。我可以打包票，它們的存儲結構只會是最簡單的 key-value 格式，不會有第二種選擇。

至于 key-value 怎么保存在內存或者硬盤上，倒是可以有多種選擇，哈希表或者樹狀結構或者你想搞 LSM tree 什么的都可以，但是都不會超過大二的知識點。

舉個例子，根據 QQ 號查用戶信息。Key 是 QQ 號、value 是用戶信息，就完了。

什么，你說還要按昵稱查詢、按郵箱查詢？簡單，每種查詢條件再來一個 key，用 key-value 格式再保存一個 “昵稱–>QQ號” “郵箱–>QQ號”的映射。這些核心數據都是讀量遠大于寫量，所以不會在乎寫的時候多寫幾個 key，要的是讀快。

再比如說，好友關系。這也好說，每個用戶一個 key，value 就是他的好友 ID 列表（排好序）。查好友的時候直接按用戶拉出他的好友列表。查共同好友？把兩個用戶的好友列表都拉出來做交集，都是排好序的，取交集也就是 O(n) 的復雜度。

加好友的時候怎么辦？往兩邊用戶的 key 都寫啊。讀量遠大于寫量，寫不怕麻煩，只要讀快就行。

（公眾號、微博這種帶有 B2C 特性的關系鏈會復雜一點，因為關注者數量無上限。）

好了，存儲格式定下來了，再說怎么查。

畢竟查詢量巨大，一臺機器扛不住，那就分多臺。把 key 分一下段、或者哈希一下，分散到多臺機器上，每臺機器只保存全量數據的一部分。

基本原理就是這樣，沒有什么特別玄乎的東西。

實際工程上的努力，基本都在保證可用性和一致性上面。

可用性：機器多了，總有機器會死機，有硬盤會壞，有機房會掉電，有光纜會被挖斷。怎么辦？每份數據都存多份，放到多臺機器上。保存相同數據的機器分布到多個機房甚至多個城市，不可能大家一起壞。當然， 這樣寫的時候會麻煩點，別忘了，大多數數據都是讀多寫少的，寫不怕麻煩。

一致性：同一份數據在多機保存了多份以后，就得保證不能出現不一致的數據。這個才是最難的。

在互聯網公司里，要想見到復雜的表結構、復雜的 JOIN、FOREIGN KEY 等，最可能的是在內部系統里面。內部系統的開發，在互聯網的工程師里面是處于鄙視鏈比較低端的……

延伸閱讀：

二、數據庫的查詢功能實現原理

數據庫查詢是數據庫的最主要功能之一。我們都希望查詢數據的速度能盡可能的快，因此數據庫系統的設計者會從查詢算法的角度進行優化。最基本的查詢算法當然是順序查找（linear search），這種復雜度為O(n)的算法在數據量很大時顯然是糟糕的，好在計算機科學的發展提供了很多更優異的查找算法，例如二分查找（binary search）、二叉樹查找（binary tree search）等。如果稍微分析一下會發現，每種查找算法都只能應用于特定的數據結構之上，例如二分查找要求被檢索數據有序，而二叉樹查找只能應用于二叉查找樹上，但是數據本身的組織結構不可能完全滿足各種數據結構（例如，理論上不可能同時將兩列都按順序進行組織），所以，在數據之外，數據庫系統還維護著滿足特定查找算法的數據結構，這些數據結構以某種方式引用（指向）數據，這樣就可以在這些數據結構上實現高級查找算法。這種數據結構，就是索引。