毫無疑問，目前大資料的索引和查詢是相當具有挑戰性的。大資料的特點有高速、價值、多樣和大資料量！100ks每秒更新的速度和tbs的資料掃瞄，讓你不能很好的做實時，除非你有堅實的索引！想象一下這些應用程式：
這些都是使用情況的查詢，需要處理高攝取資料，但不能妥協毫秒的響應時間！如果你不能提供旅遊路線、記分牌，或應對實時的詐騙行為，所有的都會關閉！好吧，這聽起來好像不太可能，並且你會問：「如何索引和查詢這型別的實時資料呢？」
全域性索引和本地索引
分布式系統提供兩種型別的索引模型：
#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」;
沒有乙個節點能獲得答案！因此，分散是需要找出「前10名」在本地的每個節點上使用的本地索引。
收集獲得「前10名」返回到協調節點。
最後一步是重新排序，找出真正的前10的活躍使用者，結合所有節點的結果，並將結果傳送回客戶端。
我們假設這樣做超過100節點，你新增了第101個節點！沒有獲得更快的執行此查詢。每個節點仍然做同樣的工作，包括新節點。事實上，損害了101節點查詢會延遲!
順便說一下，許多nosql資料庫像couchbase伺服器或mongodb做本地索引。關於本地索引詳細資訊，可參見couchbase伺服器地圖，點這裡。
以下是在乙個全域性索引的群集上執行查詢的步驟：
1. 現在我們知道全域性索引上的乙個節點！所以，不需要分散在這裡！我們只需從索引中檢索頂部登入數。
2. 最後一步是將結果傳送回客戶端。
不像前面的例子中的100個節點，你的第101節點現在可以做真正的工作！查詢會快很多！
在分布式資料庫的世界裡，重要的是選擇索引。否則，查詢的延遲可能是不可**的，大資料可以實時查詢到不可能的東西！你可以在couchbase伺服器上檢視一些新增索引的選項。
原文：indexing big data: global vs. local indexes in distributed databases
分布式資料庫
網路選課系統中分布式資料庫設計 何翠雙王巧雲張麗麗 摘要 關鍵字 選課 分布式 資料庫 distributed system of on line course choosing abstract key words course choosing distributed database 隨著學校...
分布式資料庫
1 背景 我們知道資料是乙個公司的命脈，隨著業務越做越大，資料量也會越來越大，計算也會越來越複雜，效能，可靠性，可擴充套件性的需求就會越來越強烈，這個時候乙個集中式的資料庫顯然已經滿足不了需求了。對於技術決策者來說有兩條路可以走，第一 按照現有的大型資料庫的解決方案，比如sql server clu...
分布式資料庫
一 分布式資料庫的出現的場景 網際網路 軟體國產化 o2o 五新 新零售 新製造，新金融 新資源 新技術 等主題接連提出來，並且在各個行業落地，給資料庫帶來了巨大機會，具體包含3個方向 1.遠超單機資料庫容量的資料儲存和訪問峰值 2.實時資料分析檢索 oltp兼顧olap 3.更高階別的容災需求。這...