索引多個密鑰用於不同密鑰組合中的隨機查詢

Question

我正在構建一個存儲每個用戶大量數據的應用程序（可能以千兆字節爲單位）。

像一個請求日誌，所以讓我們說，你有對每條記錄以下字段：

customer_id 
date 
hostname 
environment 
pid 
ip 
user_agent 
account_id 
user_id 
module 
action 
id 
response code 
response time (range) 

可能更多一些。

好的是，使用將主要是隻寫，但是當有讀取 我希望能夠近乎實時地快速回答。

另一個關於使用模式的預測是，大多數時候人們會查看最近的數據，並且很少查詢過去，聚集等，所以我的猜測是工作集將會小得多 整個數據庫，即大多數用戶的近期數據和目前正在進行分析的一些用戶的歷史記錄範圍。 對於後面的情況，我想它的第一個查詢是慢的，直到它將範圍存入內存。

但問題是，林不太清楚如何有效地索引數據。

索引的開頭很清楚，它的customer_id和日期。但其餘的可以是任何組合使用的 ，我無法預測最常見的，至少沒有任何確定性。

我們目前正在用mongo進行原型設計。有沒有辦法在mongo（存儲/ CPU /成本）有效地做到這一點？

唯一想到的就是嘗試預測一些頻繁的查詢並對它們進行索引，並大量分片數據 並確保每個客戶的數據均勻分佈在分片上以允許快速表掃描查詢的其餘 的'客戶，日期'索引。

P.S.我也接受有關數據庫備選方案的建議。

Answer 1

有了這個有限數量的字段，你可能只是在它們中的每一個上都有索引，或者可能與customer_id結合使用。 MongoDB非常聰明，可以爲每種情況選擇最快的索引。如果你可以將你的整個數據集放到內存中（幾GB不是很多數據！），那麼這一切都沒有關係。

你說你有一個GB 每個用戶，但這仍然意味着你可以在字段上有一個索引，因爲只有大約十幾個。有了這麼多的數據，無論如何你很快就會在某個時刻分解。

歡呼聲， 德里克

Answer 2

我想，你的要求真的不一起拌勻。您不能擁有大量數據和即時即席查詢。

如果你使用了很多索引，那麼你的寫入速度會很慢，而你需要更多的內存來更多的。

願我的建議是：

保持客戶ID和日期索引最近的數據顯示，投放給用戶，放鬆要求，無論是實時性或聚集查詢的準確性。

如果您犧牲準確性，您將每隔一段時間發射一次map-reduce作業以預先計算查詢。用戶可能會看到稍微陳舊的數據（或者可能不會，畢竟這是歷史不變的數據）。

如果你犧牲速度，那麼你會每次運行map-reduce（現在它是計算mongodb集羣中聚合的唯一理智方式）。

希望這會有所幫助:)