索引大數據：分佈式數據庫中的全局索引與本地索引

毫無疑問，大數據的索引和查詢是至關具備挑戰性的。大數據的特色以高速、價值、多樣和大量！100KS更新每秒的速度和TBs的數據掃描，讓你不能這樣作實時，除非你有堅實的索引！想象一下這些應用程序：

• 旅遊應用程序，能讓你看到全部航班和酒店的訂價和記錄！
• 在線遊戲，能顯示頂級球員的準確記分牌！
• 欺詐檢測應用程序，須要看你最近的動態來決定進行信用卡交易是否合法！

這些都是使用狀況的查詢，須要處理高攝取數據，但不能妥協毫秒的響應時間！若是你不能提供旅遊路線、記分牌，或應對實時的詐騙行爲，全部的都會關閉！好吧，這聽起來好像不太可能，而且你會問：「如何索引和查詢這類型的實時數據呢？」

全局索引和本地索引

分佈式系統提供兩種類型的索引模型：

• 本地索引：在集羣中，每一個節點索引的數據在本地上進行。這爲快速索引進行了優化。然而隨着數據攝取的增長，本地索引維護與傳入的工做量，以及集羣變大(節點)分散收集的點擊查詢延遲。想象一下這個查詢：「找到8月份十大最活躍用戶」

#SQL would look something like this

SELECT customer_name, total_logins.jan_2015 

FROM customer_bucket 

WHERE type=「customer_profile」 

ORDER BY total_logins.jan_2015 DESC 

LIMIT 10;

#index for the query would look something like this

INDEX ON Customer_bucket(customer_name, total_logins.jan_2015) 

WHERE type=「customer_profile」;

這裏是在與本地索引羣集上執行查詢的步驟：

1. 沒有一個節點知道答案！所以，分散是須要找出「前10名」在本地的每一個節點上使用的本地索引。
2. 收集得到「前10名」返回到協調節點。　　
3. 最後一步是從新排序，找出真正的前10的活躍用戶，結合全部節點的結果，並將結果發送回客戶端。

咱們假設這樣作超過100節點，你添加了第101個節點！沒有得到更快的執行此查詢。每一個節點仍然作一樣的工做，包括新節點。事實上，損害了101節點查詢的延遲!

順便說一下，許多NoSQL數據庫像Couchbase服務器或MongoDB作本地索引。關於本地索引詳細信息，可參見Couchbase服務器地圖，點這裏。

• 全局索引：該指數是獨立分區，並放置在節點上的數據。它能夠跟上突變的挑戰，做爲索引的數據須要一個網絡訪問，而且很是適合查詢。想象一下上面相同的查詢。該指數如今位於一個節點或兩個。

#index for the query would look something like this

INDEX ON Customer_bucket(customer_name, total_logins.jan_2015) 

WHERE type=「customer_profile」

AND continent="Europe";

INDEX ON Customer_bucket(customer_name, total_logins.jan_2015) 

WHERE type=「customer_profile」

AND continent="America";

INDEX ON Customer_bucket(customer_name, total_logins.jan_2015) 

WHERE type=「customer_profile」

AND continent="Asia";

如下是在一個全局索引的羣集上執行查詢的步驟：　 
　　 
1. 如今咱們知道答案全局索引上的一個節點！因此，不須要分散在這裏！咱們只需從索引中檢索頂部登陸數 
2. 最後一步是將結果發送回客戶端。　 
　　　 
不像前面的例子中的100個節點，你的第101節點如今能夠作真正的工做！查詢延遲快不少！

全局索引在分佈式數據庫中不多出現(NoSQL或其餘)。MongoDB和Cassandra都沒有全局索引。然而，能夠在Couchbase服務器下的全局二級索引看到全局索引。Couchbase 服務器GSIS也能夠獨立部署到集羣中的一個單獨的區域使用索引服務。這意味着數據服務節點正在作的核心數據操做（插入/更新/刪除）不須要在集羣的其餘部分進行索引。這個部署拓撲稱爲MDS，你能夠在這裏瞭解更多。

在分佈式數據庫的世界裏，重要的是選擇索引。不然，查詢的延遲多是不可預測的，大數據能夠實時查詢到不可能的東西！你能夠在Couchbase服務器上查看一些添加索引的選項。