內嵌或參考資料的時機

  • 2 分鐘

在上一個單元中，我們已將客戶地址和密碼資料內嵌至新的客戶文件。 該動作會減少要求數目，進而改善效能並降低成本。 不過，您無法一直內嵌資料。 當您應該將資料內嵌在文件中，而不是在不同的資料列中參考該資料時，會有一些規則。

何時應該內嵌資料？

當下列準則適用於您的資料時，請將資料內嵌在文件中：

  • 一起讀取或更新：一起讀取或更新的資料幾乎一律會模型化為單一文件。 這可減少要求數目，這是我們有效率的目標。 在我們的情節中，所有的客戶實體都會一起讀取或寫入。
  • 1 對 1 關聯性：例如，Customer 和 CustomerPassword 有 1 對 1 關聯性。
  • 1 對少關聯性：在 NoSQL 資料庫中，必須將 1 對多關聯性區分為限定或未限定。 Customer 和 CustomerAddress 有限定的 1 對多關聯性，因為電子商務應用程式中的客戶通常只會有少數的寄貨地址。 當關聯性為限定時，這是 1 對少關聯性。

何時應該參考資料？

當下列準則適用於您的資料時，請以個別文件的形式參考資料：

  • 獨立讀取或更新：此功能特別適用於合併會產生大型檔案的實體。 Azure Cosmos DB 中的更新需要取代整個項目。 如果文件有數個屬性會經常隨大量靜態屬性更新，則將文件分割成兩份會更有效率。 然後，一份文件包含較小的一組屬性，這些屬性會經常更新。 另一份文件則包含靜態且不變的值。

  • 1 對多關聯性：如果關聯性為未限定，則更是如此。 如果您的文件大小會增加未知或無限的次數，這些更新的成本和延遲將會持續增加。 這是因為更新的大小增加會耗用更多的 RU/秒，而會通過網路的承載本身，也效率不佳。

  • 多對多關聯性：我們將在後面的單元中利用具產品標籤探索此關聯性的範例。

    區隔這些屬性可降低輸送量取用量，以提高效率。 其也會降低延遲，以獲得更好的效能。