資料建模

「資料建模」文件是系列中的第一個最佳作法文件。 它會顯示下列最佳作法:

  • 您需要瞭解 API 的相關資訊。
  • 如何建模您的資料。
  • 您必須使用的文件大小。
  • 要避免的事
  • 如何配置資料庫。

如需相關資訊，請參閱 檢索及查詢 或 實際中的 IBM Cloudant。

此文件中的內容最初由 Stefan Kruger 撰寫為 2019 年 11 月 21 日的 Best and best practice 部落格文章。

瞭解您的目標 API

您可以使用 Java™、Python、Go或 Node.js 或某些其他使用案例特定的語言或平台。 其中一種語言很可能隨附便利的用戶端程式庫，可整合 IBM Cloudant 存取權，並遵循您預期的工具使用慣例。 這些語言很適合程式設計師效率，但它們也會從視圖中隱藏 API。

這個抽象化是您想要的，使用用戶端程式庫的整個原因是為了節省您自己重複、冗長的鍋爐電鍍。 不過，在疑難排解和報告問題時，您必須瞭解基礎 API 很重要。 當您向 IBM Cloudant報告可疑問題時，如果您可以提供方法讓我們重新產生問題，它會協助我們協助您。

此要求並不表示將應用程式的 Java™ 大量程式碼逐項剪下並貼到支援問題單中，因為我們可能無法建置它。 此外，您的用戶端程式碼也會造成不確定問題所在，即您的端或我們端?

相反地，IBM Cloudant支援團隊通常會要求一組 API 呼叫，最好是作為他們可以執行的一組 curl 指令來示範問題。 採用此疑難排解方法作為規則，也可讓您更容易精確找出問題失敗的位置。 如果程式碼的行為非預期，請嘗試只使用 API 的直接存取權來重新產生問題。

如果無法，問題不是 IBM Cloudant 服務本身。

如果您正在調查效能問題，請參閱 IBM Cloud®提供的日誌。 如果日誌顯示您的要求由 IBM Cloudant快速處理，但您的應用程式速度緩慢，則該問題的根源在於您的用戶端應用程式碼。 請參閱 記載及監視 的相關規則。

如果您懷疑正式支援的用戶端程式庫有問題，請嘗試建構一個小型自行包含的程式碼範例來示範問題。 在這個自行包含的程式碼範例中，請儘可能使用較少的其他相依關係。 如果您使用 Java™，如果您可以使用最小的 測試控制工具 來強調顯示程式庫問題，對我們很有幫助。

有時，IBM Cloudant 會收到支援問題單，指出「IBM Cloudant 已中斷，因為我的應用程式速度緩慢」，沒有支援證明。 幾乎一律可以追溯到用戶端應用程式碼中的問題，或關於 IBM Cloudant 如何運作的誤解。

不總是，但幾乎總是。

透過更好地瞭解 API，您也可以獲得 IBM Cloudant 行為的經驗，特別是在效能方面。 如果您使用的是用戶端函式庫，您的目標至少要知道如何找出特定函式呼叫所產生的 HTTP 請求。 如需更多資訊，請參閱以下網站：

文件必須將大部分變更的資料分組在一起

當您開始建立資料模型時，遲早會遇到文件建構方式的問題。 現在您知道 IBM Cloudant 未施行任何正規化，且它沒有您習慣從 Postgres開始的交易類型。 誘惑可能是在每份文件中塞入盡可能多的內容，這樣也可以節省 HTTP 的使用量。

這種做法往往是一個壞主意。

如果您的模型將未一起變更的資訊分組在一起，則更有可能發生更新衝突。

請考量您有使用者的狀況，每一個使用者都有一組相關聯的訂單。 一種方法可能是在使用者文件中以陣列來代表訂單:

{ // DON'T DO THIS
  "customer_id": 65522389,
  "orders": [
    {
      "order_id": 887865,
      "items": [
        {
          "item_id": 9982,
          "item_name": "Iron sprocket",
          "cost": 53.0
        },
        {
          "item_id": 2932,
          "item_name": "Rubber wedge",
          "cost": 3.0
        }
      ]
    }
  ]
}

若要新增訂單，我需要提取完整文件，解除配置 JSON，新增項目，配置新的 JSON，並將它作為更新傳回。 如果我是唯一一個這樣做的人，它可能會有一段時間。 如果同時更新或抄寫文件，我們可能會看到更新衝突。

相反地，請將訂單當成自己的文件類型來分開，並參照客戶 ID。 現在模型是不可變的。 如果要新增訂單，我在資料庫中建立新的訂單文件，這無法產生衝突。

為了能夠擷取特定客戶的所有訂單，我們可以採用稍後涵蓋的視圖。

盡可能避免建構依賴現有文件的部分更新。 在正式作業之後，通常很難變更不當的資料模型。

您可以使用分割的資料庫來有效地解決先前的型樣，稍後會更詳細地說明這些資料庫。

如需相關資訊，請參閱下列文件：

保持文件小

IBM Cloudant 強制文件大小上限為 1 MB。 此限制並不表示 close-to-1-MB 文件大小是好主意。 相反地，如果您發現所建立的文件超過單位數 KB，則可能需要重新造訪您的模型。 隨著文件增長，IBM Cloudant 中的一些事物變得效能變差。 例如，JSON 解碼成本高昂。

讓我們查看下列區段: 文件必須將大部分變更的資料分組在一起 及 保持文件小。 值得強調的是，依賴更新項目的模型最大容量限制為 1 MB，文件大小的臨界值。 這尺寸不是你想要的

避免使用附件

IBM Cloudant 支援將附件與文件一起儲存，這是它繼承自 CouchDB的長期特性。 如果您使用 IBM Cloudant 作為 Web 應用程式的後端，則也可以使用資料來儲存小型圖示及其他靜態資產，例如 CSS 及 JavaScript 檔案。

在今天使用 IBM Cloudant 中的附件之前，您必須考量一些事項，特別是如果您正在查看影像和視訊之類的較大資產:

  1. IBM Cloudant 作為區塊儲存庫很貴。
  2. IBM Cloudant的內部實作在處理大量二進位資料時無效。

所以，緩慢且昂貴。

IBM Cloudant 適用於小型資產及偶爾使用。 一般而言，如果您需要將二進位資料與 IBM Cloudant 文件一起儲存，最好使用更適合此用途的個別解決方案。 您只需要將附件 metadata 儲存在 IBM Cloudant 文件中。 是，這表示您需要撰寫一些額外的程式碼，以將附件上傳至您選擇的適當區塊儲存庫。 在 IBM Cloudant 文件中儲存標記或 URL 到附件之前，請驗證是否成功。

您的資料庫更小、更便宜、更快速且更容易抄寫。 如需更多資訊，請參閱以下網站：

資料庫越少越好

如果可以，請將每個 IBM Cloudant 帳戶的資料庫數目限制為 500 或更少。 雖然此特定數字不是神奇的 (IBM Cloudant 可以安全地處理更多)，但存在數個使用案例，這些使用案例會受到帳戶中大量資料庫的負面影響。

抄寫器排程器準備執行的同時抄寫工作數目有限。 隨著資料庫數目增加，如果您嘗試抄寫帳戶中包含的所有項目，抄寫延遲可能會增加。

同一硬幣的反面是作業層面: IBM Cloudant的作業團隊也依賴抄寫來移動帳戶。 透過減少資料庫數目，如果您需要將帳戶從一個位置移至另一個位置，您可以協助我們協助您。

因此，您何時必須使用單一資料庫，並使用視圖來區分不同的文件類型，以及何時必須使用多個資料庫來建立資料模型? IBM Cloudant 無法跨多個資料庫聯合視圖。 如果您具有永不「結合」或查詢在一起的不相關資料，則該資料可以成為跨多個資料庫分割的候選項。

如果您有不斷成長的資料集 (例如日誌、感應器讀數或其他類型的時間序列)，則建立單一、不斷成長的龐大資料庫也不是好主意。 這類使用案例需要時間拳擊，稍後我們會更詳細地說明。

避免 每個使用者的資料庫 反型樣，例如鼠疫

如果您要在 IBM Cloudant上建置多使用者服務，很容易讓每一個使用者將其資料儲存在應用程式帳戶下的個別資料庫中。 如果使用者數量很少的話，這就很有效果。

現在新增衍生跨使用者分析的需求。 您的作法是將所有使用者資料庫抄寫至單一分析資料庫。 好的 此應用程式突然變得成功，使用者數目在 150-20,000 範圍內增加。 您有 20,000 個抄寫只是為了讓分析資料庫保持最新。 如果您也想要在主動-主動災難回復設定中執行，請新增另外 20,000 個抄寫，系統會停止運作。

相反地，請將使用者資料多工處理成較少的資料庫，或將使用者多工處理成一組資料庫或帳戶，或兩者兼而有之。 如此一來，您就不需要抄寫來提供分析資料庫，但鑑別會變得更複雜，因為 IBM Cloudant 只提供資料庫層次的鑑別。

值得指出的是，"database-per-user" 方法很吸引人，因為 IBM Cloudant 許可權是 "per database"，但此型樣出現並非真的使用者的錯誤。

避免撰寫自訂 JavaScript 減少函數

IBM Cloudant 中的 MapReduce 視圖很棒。 然而，強大的力量帶來了巨大的責任。 MapReduce 視圖的對映部分會漸進式建置，因此對映中的低劣程式碼只會影響檢索時間，不會影響查詢時間。 不幸的是，減少部分在查詢時執行。IBM Cloudant 提供一組內建縮減函數，可在 Erlang內部實作。 這些函數會大規模地執行，而您手動製作的 JavaScript 則不會減少。

如果您發現自己撰寫 reduce 函數，請停止並考量您是否可以重組資料，以便不需要撰寫 reduce 函數。 或者，您可以依賴內建縮減器。

分割資料庫上的視圖不支援自訂減少，這是導致大幅加速查詢的因素之一，只有此類視圖才能提供。

如需相關資訊，請參閱 減少上的 IBM Cloudant 文件。

使用時間框式資料庫來處理不斷成長的資料集

一般而言，在 IBM Cloudant中擁有不斷成長的資料庫 不是 好主意。 大型資料庫可能難以備份，需要「重新共用」以在成長時保持良好的效能，並承受較長的索引建置時間。

減少此問題的一種方法是改為具有數個較小的資料庫，具有一般型樣 時間框資料庫: 大型資料集分割成較小的資料庫，每一個資料庫代表一個時間範圍 (例如，一個月)。

  • orders_2019_01
  • orders_2019_02
  • orders_2019_02

新資料會寫入本月的資料庫，歷程資料的查詢可以導向前幾個月的資料庫。 當一個月的資料不再感興趣時，它可以保存至 Object Storage、刪除每月 IBM Cloudant 資料庫，以及回復磁碟空間。 如需更多資訊，請參閱以下網站。