爲類似的數據結構選擇MongoDB集合結構

在MongoDB中存儲類似結構的更好方法是什麼？爲每個結構選擇一個集合還是一個集合？有一個/幾個的好處？爲類似的數據結構選擇MongoDB集合結構

例如，我必須存儲一些日誌，以便進一步分析。沒有爲每個結構和一些具體的一些統計類型，如數據共用部分：

{ 
    timestamp: ..., 
    client: { ... }, 
    type: 'stats_for_item1', 
    data: { 
    id: ObjectId('xxx'), 
    field1: 1, 
    field2: 2 
    } 
}, 
{ 
    timestamp: ..., 
    client: { ... }, 
    type: 'stats_for_item2', 
    data: { 
    id: ObjectId('zzz'), 
    field3: 3, 
    field4: { 
     field5: [5, 1] 
    } 
    } 
}

正如你看到的，我們有共同的部分，並data現場，與item1和item2幾個不同的領域。

似乎只有timestamp和type字段將被索引（當然_id）。而且這些物品的數量有限，總共有3種物品類型。會有很多的寫入和少量的讀取

那麼，我的問題，如何組織這樣的結構？使用一個大集合stats並存儲所有內容？不創造少量收藏品stats_item1,stats_item2和stats_item3。什麼是最佳？有什麼好處？從Mongo的角度來看，分片/索引/查詢/鎖定/等？

來源

2012-02-07 Igor Artamonov

我可能會保留一個集合。如果您稍後獲得另一個統計類型，則無需重新構建您需要添加的新集合的代碼。您可以通過在「類型」上創建索引來專門搜索具有特定類型的項目，但是您也可以通過所有項目進行搜索，因爲您將它們全部放入具有「時間戳」索引的集合中。（請注意，MongoDB還會爲每個文檔添加一個_id字段，並且該字段也會添加一個索引）。

對於分片，您需要爲每個集合選擇一個密鑰。我不知道你的讀寫比率是多少，以及你打算如何讀取數據，但是我懷疑你之後正在做某種記錄和一些分析。在這種情況下，「客戶端」上的分片鍵可能是最有意義的。時間戳可能會是一個糟糕的選擇，因爲它會迫使所有寫入一個碎片。

鎖定的一個或三個集合之間的區別並沒有太大的區別，因爲現在mongoDB不會爲每個集合執行鎖定（只是每個服務器實例的鎖定在2.0中產生，而每個DB在鎖定在即將到來的2.2中產生）。

歡呼聲，

德里克

來源

2012-02-07 08:58:32 Derick

爲類似的數據結構選擇MongoDB集合結構

回答

相關問題