2017-07-17 119 views
1

我使用的是Azure DocumentDB,我在NoSql中的所有經驗都在MongoDb中。我查看了定價模型,成本是每個集合。在MongoDb中,我將爲我正在使用的用戶,公司和電子郵件創建3個集合。我注意到這種方法每月會花費24美元。同檔vs異構documentdb

我跟我一起工作的人告訴我,我做錯了。我應該將所有這些事情都存儲在一個集合中,並用一個字段來描述數據類型是什麼。每個館藏應該按照日期或地理區域相關,因此世界的一部分有一小部分要搜索。 和:

「合併不同類型的文件合併爲一個集合,並添加 現場所有他們在尋找像一個類型字段或 東西分開」

我永遠不會有夢想在Mongo中這樣做,因爲它會使索引,分片鍵和其他事情難以理順。

有可能不是這些對象之間的重疊可能字段:

我可以做這種方式(例如電子郵件和堅定的對象),但我似乎無法找到任何人做一個例子這樣 - 這表明,也許這是不對的。現在,我不需要一個例子,但是有人能夠指向某個位置來描述哪種方法是「正確」的方式嗎?或者,如果您確實爲所有數據創建了單個集合(除了Azure的定價模型),那麼這樣做的優缺點是什麼?

關於DocumentDb模式設計的任何好的文章?

+0

沒有「正確」或「錯誤」的方式(儘管你的同事告訴你)。話雖如此:人們總是將內容組合成單個集合,包括MongoDB(不知道爲什麼你不會想到這一點,或者爲什麼這會使索引變得更加困難;索引是基於每個屬性的)。藉助CosmosDB,它可以讓您進行成本優化,並允許您在單個事務中訪問異構數據。 –

+0

我不會夢想將入站電子郵件和用戶或公司放在一個集合中。我會把這個集合稱爲什麼? 「熔爐」?我的意思是,數據甚至與什麼方式有關?這些電子郵件確實有電子郵件地址,並可能映射到用戶,但它似乎不是一個好技術。另外,你會如何碎片?而且你會在兩個對象的每個字段上都有一個索引。 –

+0

此外,這個問題還有更多關於如何設計DocumentDB模式的好消息 - 顯示每個模式的優缺點,而不是專門尋找'X是正確的答案' –

回答

3

是的。爲了充分利用CosmosDb,它完全有必要考慮一個Collection是一個完整的數據庫系統,而不是一個只能容納一種類型對象的「表」。

在宇宙中分片是非常簡單。您只需指定一個可以填充所有文檔的字段,並將其選爲分區鍵。如果您只選擇一個通用值,如keypartitionKey,則可以通過選擇適當的值,輕鬆地將入站電子郵件的存儲從用戶分離出來。

class InboundEmail 
{ 
    public string Key {get; set;} = "EmailsPartition"; 
    // other properties 
} 

class User 
{ 
    public string Key {get; set;} = "UsersPartition"; 
    // other properties 
} 

什麼我展示的是仍然只是一個例子,雖然。實際上,你的分區鍵值應該更加動態。瞭解針對已知分區的查詢非常快速,這一點很重要。只要你需要掃描多個分區,你會看到更慢,更昂貴的結果。

因此,在一個攝取大量用戶數據的應用程序中。在一個分區中保持單個用戶的活動可能對該特定實體有意義。

如果您想要證明這是使用CosmosDb的適當方式,請考慮添加新的Gremlin Graph API。圖形本質上是異構的,因爲它們包含許多不同的實體和實體類型以及它們之間的關係。 Cosmos的查詢邊界處於集合級別,因此如果您嘗試將實體全部置於不同集合中,那麼Graph API或查詢都不會起作用。

編輯: 我對你說這句話And you would have an index on every field in both objects的評論注意到。 CosmosDb 確實自動索引每個文檔的每個字段。他們使用專用的基於專有路徑的索引機制,確保您的JSON樹的每個路徑都有索引。您必須特別選擇此自動索引功能的

+0

說一些「非常簡單」時請小心。尤其對於分區(分區)鍵,這不*非常簡單(甚至不簡單*),因爲這可能會對性能產生重大影響。 –

+0

我並不是指您選擇分區鍵值的過程。這當然是困難的,需要對應用程序的查詢模式進行實踐和深入理解。我正在談論分片在CosmosDb中的工作原理。你選一把鑰匙。整個分片過程然後被抽離你。作爲一名開發人員,您完全不必做任何事情,因爲它完全是PaaS,它與Mongo非常不同。 –

+0

@DavidMakogon如果您通過爲分區鍵挑選不合適的「值」來削弱您進行高效查詢的能力,這與Cosmos中的分片方式無關,也不會影響Cosmos繼續高效分片的能力。 –