使用 IBM Cloudant 變更資訊來源常見問題 (FAQ)

IBM Cloudant 資料庫變更資訊來源的主要使用案例是將資料從來源抄寫至目標資料庫。 IBM Cloudant 抄寫器已建置來處理 changes 資訊來源，並執行必要的檢查，以確保將資料正確複製到其目的地。

IBM Cloudant 具有原始 變更資訊來源 API，可用來耗用單一資料庫的變更，但必須小心使用。

_changes API 端點可以數種方式使用，並可以各種格式輸出資料。 但在這裡，我們著重於最佳作法，以及當您針對 _changes API 進行開發時如何避免某些陷阱。

如何使用變更資訊來源?

給定單一資料庫 orders，我可以向資料庫要求變更清單，在此情況下，使用 ?limit=5 將結果集限制為五個變更:

GET /orders/_changes?limit=5
{
  "results": [
    {
      "seq": "1-g1AAAAB5eJzLYWBg",
      "id": "00002Sc12XI8HD0YIBJ92n9ozC0Z7TaO",
      "changes": [
        {
          "rev": "1-3ef45fdbb0a5245634dc31be69db35f7"
        }
      ]
    },
    ....
  ],
  "last_seq": "5-g1AAAAB5eJzLYWBg"
}

API 呼叫會傳回下列變更:

results
變更陣列。
last_seq
可在後續 API 呼叫中提供給變更端點以取得下一批次變更的記號。

請參閱下列範例中的如何提取下一批次變更:

GET /orders/_changes?limit=5&since=5-g1AAAAB5eJzLYWBg
{
  "results": [ ...],
  "last_seq": "10-g1AAAACbeJzLY"
}

since 參數用來定義您要在 changes 資訊來源中開始的位置:

since=0
changes 資訊來源的開頭。
since=now
changes 資訊來源的結尾。
since=<a last seq token>
從 changes 資訊來源中的已知位置。

在臉部值時，遵循 changes 資訊來源似乎很簡單，就像一起鏈結 _changes API 呼叫一樣。 然後，IBM Cloudant 會將 last_seq 從一個 changes feed 回應傳遞至下一個要求的 since 參數。 但這些變化的微妙之處需要進一步討論。

為何變更資訊來源至少交付一次變更?

IBM Cloudant 標準變更資訊來源保證 _至少一次_會傳回每一份文件，這與承諾只傳回每一份文件 _一次_不同。 另一種方式是，changes feed 的消費者可以再次看到相同的變更，或實際上看到一組重複的變更。

changes 資訊來源的消費者必須 _等冪_處理變更。 實際上，在從變更觸發動作之前，您必須記住是否已處理變更。 單純變更資訊來源消費者可能會在收到每一項變更時，將訊息傳送至智慧型手機。 但是，如果在重播變更發生時未等冪處理變更，則使用者可能會收到重複的文字訊息。

通常這些變化的「倒轉」是很短的，只會重播幾個變化。 但在某些情況下，要求可能會看到已重播數千項變更的回應-可能從時間開始所有變更。 rewinds 的可能性會使 changes feed 不適用於預期佇列類似行為的應用程式。

為了重申，IBM Cloudant的變更資訊來源承諾在變更資訊來源中 至少一次 遞送文件，並且不保證在多個要求之間重複值。

changes 資訊來源是否「即時」運作?

changes 資訊來源不保證送入變更對耗用 changes 資訊來源的用戶端顯示的速度。 開發應用程式時不得假設資料插入、更新及刪除會立即延伸到變更讀取器。

為何所有個別文件變更都不會出現在 changes 資訊來源中?

如果在變更資訊來源呼叫之間多次更新文件，則變更資訊來源可能僅反映這些變更中的最新變更。 用戶端不會收到每一份文件的每一項變更。

IBM Cloudant changes 資訊來源不是包含依時間順序發生之每個事件的 交易日誌。

我可以使用已過濾的變更資訊來源來進行作業查詢嗎?

過濾 changes 資訊來源，並依延伸，執行已過濾的抄寫有其用途:

  • 正在將資料從來源複製到目標，但忽略已刪除的文件。
  • 複製資料但沒有索引定義 (設計文件)。

此 部落格文章 說明在抄寫期間提供 selector 如何使這些使用案例的工作順利執行。

附帶 selector 參數的 changes 資訊來源 不是 例行從資料庫擷取資料截塊的方式。 不得使用它作為對資料庫執行作業查詢的方法。 過濾的變更緩慢 (過濾器會輪流套用至每一個變更的文件，而不需要索引的協助)。 此處理程序比建立次要索引 (例如 MapReduce 視圖) 及查詢該視圖慢很多。

feed=continuous 變更資訊來源會繼續無限期地執行嗎?

否，IBM Cloudant 不保證連續變更資訊來源的連線持續時間。 伺服器可能會因為各種原因 (包括維護、安全或網路錯誤) 而定期中斷連線。 使用 changes 資訊來源的程式碼必須設計成使用最近儲存的序列 ID 作為 since 值，以在發生錯誤或斷線之後提出新要求來回復 changes 資訊來源。

為何變更資訊來源無法保證訂購時間?

如果使用案例是根據下列陳述式，則無法使用 IBM Cloudant 變更資訊來源來達成此結果。

"Fetch me every document that has changed since a known date, in the order they were written."

IBM Cloudant 資料庫未記錄寫入每一個文件變更的時間。 Changes 資訊來源對資訊來源中的變更排序沒有任何保證-不保證它們會按照傳送至資料庫的順序。

不過，您可以將變更日期儲存在文件內文中，以達到此使用案例:

{
  "_id": "2657",
  "type": "order",
  "customer": "bob@aol.com",
  "order_date": "2022-01-05T10:40:00",
  "status": "dispatched",
  "last_edit_date": "2022-01-14T19:17:20"
}

而且您可以建立 MapReduce 視圖，並以 last_edit_date 作為索引鍵:

function(doc) {
  emit(doc.last_edit_date, null)
}

可以查詢此視圖，以傳回在提供的日期和時間或之後修改的任何文件:

/orders/_design/query/_view/by_last_edit?startkey="2022-01-13T00:00:00"

此技術會以高效能及可重複的方式產生一組沒有重複值的時間排序結果。 此資料的消費者 不 需要以等冪方式管理資料，使開發處理程序更簡單。

目前哪些 IBM Cloudant 變更資訊來源良好?

IBM Cloudant 變更資訊來源適用於下列作業:

  • 正在開啟 IBM Cloudant 抄寫的電源，可選擇性地使用選取器來過濾部分變更。
  • 用戶端會以批次方式使用變更資訊來源，但會以等冪方式處理每一個變更，而不關心排序，並預期會看到一些變更不只一次。

IBM Cloudant changes 資訊來源不適用於下列元件:

  • 訊息佇列。 如需相關資訊，請參閱 IBM Messages for RabbitMQ 以管理佇列。
  • 訊息分配管理系統。 如需詳細資訊，請參閱 IBM Event Streams 處理可擴充、有時序的事件串流。
  • 即時發佈和訂閱系統。 如需相關資訊，請參閱 IBM Databases for Redis 以處理發佈和訂閱主題。
  • 交易日誌。 部分資料庫會將每一項變更儲存在交易日誌中，但 IBM Cloudant 的分散式最終一致本質表示不存在明確的依時間排序交易日誌。
  • 查詢機制。 如需相關資訊，請參閱 MapReduce 視圖，以建立依您選擇的索引鍵排序的資料視圖。