IBM Cloudant 視訊 Script 簡介

歡迎使用 IBM Cloudant 課程簡介，這是一個 17 個部分的視訊系列，提供您 IBM Cloudant 資料庫即服務的概觀。

此視訊是第 1 部分- 何謂 IBM Cloudant?

IBM Cloudant 是一個資料庫，在 IBM Cloud®中作為服務執行。 其工作是安全地儲存應用程式的資料，並讓您能夠快速且有效率地擷取它。IBM Cloudant的主要功能顯示在下列清單中:

資料庫

儲存及擷取資料。 更具體地說，它是 JSON 文件儲存庫。 JSON 來自 JavaScript，並以通用檔案格式代表簡式物件。

「文件」

IBM Cloudant中的儲存單元。 文件會全部新增、更新及刪除。

HTTP API

任何 IBM Cloudant 操作均可透過 HTTPS 實現。 HTTP 是為萬維網提供動力的通訊協定，而 IBM Cloudant 則是專為網路建立的資料庫。 大部分資料庫都隱藏在私密網路中，無法存取，但只有少數幾部機器無法存取。 IBM Cloudant 服務（主要）位於公開網路上，任何有網路連線（且有權限）的人都可以存取。

IBM Cloudant 並非完全由 IBM撰寫。 它是以 Apache CouchDB為基礎，這是 Apache Foundation 所執行的開放程式碼專案。IBM Cloudant 會運用一些 CouchDB 貢獻者，但根據 Apache的規則，他們無法獨佔其開發。

您在本課程中看到的大部分內容適用於 Apache CouchDB，因為它適用於 IBM Cloudant。 他們的 API 99% 相同-我指出它們的分歧之處。

IBM Cloudant 可以視為 CouchDB 執行 "as-a-service"。 IBM Cloudant 服務可輕鬆部署並由 IBM 工程師 24-7 管理。 服務沒有要安裝的軟體，沒有要管理的伺服器，沒有要瞭解的配置。 使用者不需要是 CouchDB 專家即可使用及管理它。

您可以確定資料層未鎖定至特定平台、雲端或供應商，因為 IBM Cloudant 是建置在真正開放程式碼基礎上。如我們所見，IBM Cloudant 可以與 CouchDB 搭配使用，以建立透過抄寫共用資料的混合式應用程式。

稍後在課程中，我們會查看 hood 下，以查看 IBM Cloudant 如何運作，但一開始我們會將 IBM Cloudant 視為「黑色方框」。

總而言之，Cloudant 是以 Apache CouchDB為基礎，這是一個開放程式碼專案。 它儲存 JSON 文件。 它使用 HTTP API 進行存取，因此網際網路上任何會說 HTTP 的裝置都能存取：應用程式碼、網頁瀏覽器、IoT網裝置或行動電話。IBM Cloudant 是一種高可用性的管理服務，能夠在多種硬體故障下持續運作。

這部分就結束了 下一個部分稱為 文件。

文件視訊 Script

歡迎使用 IBM Cloudant 課程簡介，這是一個 17 個部分的視訊系列，提供您 IBM Cloudant 資料庫即服務的概觀。

此視訊是第 2 部分- * IBM Cloudant 文件*。

在前一節中，我們看到 IBM Cloudant 是 JSON 文件儲存庫。 讓我們瞭解這在實務中的意義，以及與其他類型資料庫的比較。

大部分資料庫會將其資料儲存在稱為表格的集合中，其中每一個資料單元都是一列，每列都有相同的固定直欄。 每一個表格的綱目都已預先定義: 直欄清單及其名稱、日期類型、值限制，以及與其他表格的關係已仔細定義。 每筆新記錄都會在表格中形成一列。

IBM Cloudant 不同!

IBM Cloudant 服務包括稱為資料庫 (而非表格) 的集合，其中每一個都包含任意數目的文件。

此投影片範例顯示在傳統表狀資料庫中表示的相同資料，以及如何將相同的資料儲存在 IBM Cloudant 中作為 JSON 文件。

因此，如果您來自關聯式資料庫背景: 表格是 IBM Cloudant中的 "databases"，而列是 "documents"。

IBM Cloudant 文件必須是 JSON 物件，以大括弧開頭和結尾，且包含許多鍵值屬性。

JSON 物件必須小於 1 MB 大小，且包含任意數目的字串、數字、布林、陣列及物件。 物件內的巢狀物件可以繼續至任何深度。

所使用的金鑰可以如您所喜歡般簡短或詳細。

下列清單包括一些簡式範例文件，其中顯示如何使用每一種資料類型。

• 第一個範例顯示人員物件，儲存字串、布林及標籤陣列。
• 第二個範例顯示儲存體上要儲存的簡要屬性名稱，並代表 Web 事件，例如按一下網站。
• 最後一個範例顯示文件本身如何包含主旨。

日期的附註。 JSON 沒有原生「日期」類型，因此日期通常以 30-October-2018 或類似格式儲存。 我們晚些再回來

現在，如需第一個實際練習，請造訪 www.ibm.com/cloud。 如果您還沒有帳戶，請向 IBM Cloud登錄帳戶。

登錄之後，您可以按一下 服務，搜尋 Cloudant 資料庫，並佈建新的服務。

IBM Cloudant Lite 服務提供免費方案，可讓使用者在開發期間以有限容量試用 IBM Cloudant。 其哥哥 Standard Plan 是已付費的服務，您可以在其中為應用程式指定每秒讀取、寫入及查詢數，並為您保留該容量。 您需要為您佈建的容量及資料儲存體用量付費。

Lite 方案以類似方式運作。 它只有小的佈建容量和固定儲存體大小，但適用於測試 IBM Cloudant 服務。

IBM Cloudant 通常稱為 "schemaless" 資料庫-但我們必須小心定義該術語。

確實可以說您不需要事先在 IBM Cloudant 資料庫中定義綱目 (欄位名稱、類型、限制和關係)。 您只需將自己設計的 JSON 文件寫入資料庫即可。

開發人員喜歡此彈性，因為他們可以在其程式碼中設計其資料，將其轉換為 JSON，並將其寫入資料庫。

思考 資料的形狀仍然很重要，特別是在您要如何查詢及檢索它方面，如我們稍後所見。

仍然需要資料設計，但嚴格來說，資料庫不需要知道您的綱目。

假設我們想要建立一個美國總統的資料庫。 我們只需設計應用程式中資料的「模型」，將它轉換成 JSON，然後將它寫入資料庫。 在此情況下，我們使用一般 CouchDB 慣例:「類型」欄位指出文件的資料類型。

如果在未來決定要將更多資料新增至 "schema"，則只需要將新物件寫入資料庫，而沒有來自 IBM Cloudant的抱怨即可。 我們可以決定只將 "address" 物件新增至下列文件:

• 從現在開始建立的文件。
• 只有我們有地址的文件

換句話說，相同類型的文件可以有欄位存在或遺漏。

您資料庫的綱目可以隨著時間演進，以符合您應用程式的需求。 您不需要 (必然) 告知資料庫綱目變更-以新格式撰寫新文件。

我們甚至可以將多個文件「類型」儲存在相同的資料庫中。 在此情況下，人員、書籍及工作區位於相同的資料庫中。 我們知道哪一個是因為 "type" 欄位 (此欄位是慣例，不是 IBM Cloudant的任何意義)。

此配置的替代方案是具有三個資料庫人員、工作簿及工作區，並將每一個資料類型保留在其自己的資料庫中。 這兩種方法都很好。 如果您需要在類型之間執行查詢，或如果您需要將所有資料類型一起抄寫，則可以選擇在相同資料庫中同時具有多個類型。 否則，個別資料庫方法可能更好。

總而言之，雖然 IBM Cloudant 是 "schemaless"，但這並不表示您不需要執行詳細資料設計以取得最佳效能。

如果您有一些關聯式資料庫經驗，則這些提示特別相關。

• 避免在結合中思考- IBM Cloudant 文件必須包含該物件所需的一切，以便可以在一個 API 呼叫中擷取它。
• 正規化會離開 JSON 儲存庫中的視窗，如果它讓資料擷取更有效率，則可以容忍部分重複值。
• 雖然我們對文件大小有 1 MB 的限制，但您的文件必須要小很多-通常只有幾 KB。
• 如果您的應用程式可以接受「僅寫入」* 設計型樣，其中資料只會新增至資料庫，則它可以讓您的生活更輕鬆。 您必須絕對避免在小時間範圍內重複更新相同文件的型樣。

這部分就結束了 下一個部分稱為 文件 ID。

_id 視訊 Script

歡迎使用 IBM Cloudant 課程簡介，這是一個 17 個部分的視訊系列，提供您 IBM Cloudant 資料庫即服務的概觀。

此視訊是第 3 部分- 文件 _id。

在前一節中，我們看到資料如何儲存在 IBM Cloudant 文件中，您的應用程式如何彈性地將 JSON 物件儲存在 IBM Cloudant 資料庫中。 不過，也有一些硬性的規則。

一個規則是每個文件都必須包含稱為 _id 的唯一 ID，這是一個字串。 相同資料庫中的兩份文件可以有相同的 _id 欄位。 在其他資料庫中，您指定哪個直欄是唯一 ID，但在 IBM Cloudant中，它一律是 _id 且無法變更。

此外，與關聯式資料庫不同，IBM Cloudant 沒有 "auto-incrementing IDs"，即從 1 開始的 ID 欄位，並針對新增的每一個文件進行增量。

IBM Cloudant' s _id 欄位是下列其中一個字串:

• 由 IBM Cloudant產生的 32 個字元字串。 ID 是一個無意義的數字和字母序列，保證是唯一的。
• 由您定義的字串 (如果您知道資料的唯一資訊)。

下列範例顯示如何提供您自己的文件 _id:

使用它來儲存您知道的唯一項目，即使用者的電子郵件位址。 您的登錄機制可以施行單一使用者每封電子郵件位址原則。 部分使用者選擇將 _id 中的文件類型編碼，例如 user:56、book:55。 最後一個範例顯示 32 位數字串 (在應用程式中產生)，設計為依大約日期和時間順序排序。 此方法可讓您在沒有次要索引的情況下，輕鬆從資料庫擷取最新文件。

IBM Cloudant 會取得您的文件 _ids 並將它們儲存在索引中 (類似於書籍的內容頁面)。 此主要索引是依 _id 順序，用來容許 IBM Cloudant 依其 _id 來擷取文件-因此行為類似於鍵值儲存庫。

透過仔細設計 _id 欄位，您可以讓它使用主要索引，將在主要索引中有意義的資料保存在一起。 此方法可讓稍後更快擷取該資料。 我們看到使用時間排序 _ids 表示可以依大約日期和時間順序擷取資料。

稍後在擷取文件 ID 範圍時，我們會看到一個範例。

最後，每一個文件在資料庫中都必須具有唯一的 _id 欄位。 它可以由 IBM Cloudant自動產生，也可以由應用程式提供，在此情況下，您必須負責 _id 欄位的唯一性。

_id 欄位是資料庫主要索引的基礎，如稍後所見，可用於索引鍵值查閱及範圍查詢。

這部分就結束了 下一個組件稱為 修訂記號。

rev 記號視訊 Script

歡迎使用 IBM Cloudant 課程簡介，這是一個 17 個部分的視訊系列，提供您 IBM Cloudant 資料庫即服務的概觀。

此視訊是第 4 部分- 修訂記號。

第二個基本 IBM Cloudant 規則是每個文件修訂都有自己的唯一修訂記號。 讓我們看看它是什麼意思。

您永不需要產生修訂記號-當您新增、更新或刪除使用 API 的文件時，會為您建立一個修訂記號。

修訂記號由兩個部分組成:

數字 1、2、3 等，以及文件主體的加密雜湊。 (對於未起始的，雜湊是部分資料的數位「指紋」。 如果資料變更，則指紋會變更。 沒有 2 個指紋相同，亦即，沒有 2 個具有不同內容的文件可以具有相同的雜湊。)

您可以從畫面上的範例看到我們的文件有一個修訂記號 (索引鍵以 _rev 開頭) 以 1 開頭，後面接著橫線。 指出此修訂是文件的第一個修訂。 以 04aa8... 開頭的數字是文件的加密雜湊。

如果我們遵循文件的生命週期，它會從 revision 1 開始。 稍後修改時，它會取得 revision 2 等。 隨著每一個遞增修訂號碼，雜湊會變更，因為文件內容也在修改中。

文件可以有多個相同號碼的修訂。 在此情況下，存在兩個 revision 3s。 此實務範例稱為 衝突，在某些情況下是「正常」。 我們瞭解課程中稍後的原因，但目前我們可以假設每次更新文件時都會增加修訂號碼。

讓我們遵循範例 IBM Cloudant 文件的生命週期:

建立新文件時 (無論使用自動產生的 _id 或使用者提供的 _id)，都會配置 revision 1。 在對 API 要求的回應中，會將記號傳送給您。 通常，您可以捨棄修訂 (除非您打算很快修改文件)。

當我們修改其 _rev 位於 revision 1 的文件時，會儲存文件，並在 API 回應中產生 revision 2 記號並傳回給您。 請注意，我們將文件中的名稱從 Liz 變更為 Elizabeth。

到目前為止都很簡單

如果稍後刪除文件，則會建立 revision 3。

與幾乎任何其他資料庫不同，IBM Cloudant 會保留已刪除文件的參照。 刪除只是另一個文件修訂，這是 _deleted: true 取代文件內文的特殊修訂。

事實上，文件的最近修訂歷程 (修訂樹狀結構-請記住，我們可以在每一個修訂號碼中有多個修訂)-會保留下來。

您無法使用 IBM Cloudant的修訂樹狀結構作為版本控制系統來擷取或 回復 至較舊的修訂。 在取代修訂之後，會刪除較舊修訂的文件主體，並在稱為 壓縮的處理程序中回復其磁碟空間。 壓縮在 IBM Cloudant中自動發生，因此無法安全地假設可擷取舊修訂。

總而言之，資料庫會在新增、編輯及刪除時產生修訂記號。 (您永不需要建立自己的修訂記號。) 一般而言，修訂數目會每次增加一個，但可能更複雜的實務範例 (我們稍後會涵蓋這些實務範例)。 會捨棄或壓縮較舊的文件主體 (請不要依賴能夠取回它們)。 所有變更文件的 IBM Cloudant 作業都需要文件的 _id 及其 _rev (此實務範例與大部分資料庫不同)。

這部分就結束了 下一個部分稱為 鑑別。

鑑別視訊 Script

歡迎使用 IBM Cloudant 課程簡介，這是一個 17 個部分的視訊系列，提供您 IBM Cloudant 資料庫即服務的概觀。

此視訊是第 5 部分- 鑑別。

我們先前指出 IBM Cloudant 是公用網際網路上的 Web 型服務。 我們如何確定我們的資料是安全的，且只有我們的程式碼才能存取它? 此實務範例是進行鑑別的情況。

IBM Cloudant 支援兩種類型的鑑別。

傳統驗證會在每次使用 HTTP Basic 驗證的請求中提供使用者名稱或 api-key 及密碼，或交換使用一次性會話 API 呼叫的 cookie。 階段作業 Cookie 會定期循環，因此您的用戶端程式碼需要擷取重新整理的 Cookie，並儲存它以進行後續要求。 IAM 認證是存取管理系統，是所有 IBM Cloud 服務的基礎。 若要使用 IAM 進行驗證，您需要 IAM API 金鑰和 IBM Cloudant 服務的主機名稱。 API 金鑰會透過 IAM API 交換為承載令牌，而承載令牌會在每次請求時傳給 IBM Cloudant。 載送記號僅持續一個小時，因此必須定期使用 IAM 服務更新。 當提供 IBM Cloudant 服務時，您可以只產生 IAM 憑證，或同時產生 IAM 和傳統憑證 - 由您決定。

如何產生認證?

在 IBM Cloudant 服務下的「IBM Cloud 儀表板」中，按一下 服務認證 標籤中的 新建認證。 即會建立 JSON 文件，其中包含 IAM 金鑰、基本鑑別使用者名稱及密碼，以及 IBM Cloudant 主機名稱。

請參閱認證集範例:

對於 IAM，您需要 API 金鑰和主機。 對於 Legacy 或 Basic-Auth 或兩者，您都需要 URL (其中包含嵌入 URL 的使用者名稱和密碼)。

IBM Cloudant 有三個正式用戶端程式庫: Java™、Node.js及 Python。

這三個都會自動處理鑑別。 您不需要擔心它如何交換階段作業記號的 API 金鑰，或 IAM 鑑別如何運作-會為您處理。

當我們在文件中討論 API 時，為了方便起見，我們使用「基本鑑別」。 不過，我們建議您儘可能使用 IAM 鑑別，因為它容許與 IBM Cloud 平台及更精細的許可權進行更好的整合。

下一次練習的時間到了

登入 IBM Cloud，並找到前次建立的 IBM Cloudant Lite 服務。 在 服務認證 標籤中，按一下 新建認證 按鈕以產生一組 IAM+Legacy 認證。 請記下它所傳回的 JSON-我們在下一次練習時將需要該 JSON。

然後，造訪憑證 JSON 中指定的 URL- 您會看到什麼？

總而言之，會從 IBM Cloud 儀表板產生認證。 您可以具有 IAM 及/或 IAM + 舊式認證。 這兩種鑑別方法都涉及交換您的認證以取得有時間限制的記號 (鑑別)-當您使用服務時，記號會定期更新。 官方圖書館會為您處理所有這些作業。

這部分就結束了 下一個部分稱為 儀表板。

儀表板視訊 Script

歡迎使用 IBM Cloudant 課程簡介，這是一個 17 個部分的視訊系列，提供您 IBM Cloudant 資料庫即服務的概觀。

此視訊是第 6 部分- 儀表板。

開始、建立資料庫及新增文件最簡單的方法是使用 IBM Cloudant 儀表板。

IBM Cloudant 儀表板是內建在服務中的 Web 應用程式。 它容許透過圖形使用者介面執行基本資料操作: 可以建立及刪除資料庫。 管理新增、更新、刪除及抄寫工作的文件。 它也是執行一次性查詢及設定次要索引 (如我們稍後所見) 的便利地方。

它也包含一些簡單的監視工具，可視覺化要求率。

請務必注意，在 IBM Cloudant 儀表板中可實現的任何任務也可以使用 IBM Cloudant HTTP API 來完成。 事實上，IBM Cloudant Dashboard 本身只是在進行標準的 API 呼叫。

若要開啟 IBM Cloudant 服務的「儀表板」，請登入 IBM Cloud，尋找您的 IBM Cloudant 服務，然後按一下 啟動 IBM Cloudant 儀表板 按鈕。 即會開啟新視窗，讓您登入 IBM Cloudant 儀表板。

如果您讓儀表板視窗保持自動式一段時間，則會發現您已登出 (基於安全目的)，且必須再次按一下 啟動。

儀表板具有數個標籤。 其預設標籤 資料庫會列出您在 20 個群組中建立的資料庫。 每一個資料庫都會顯示其儲存的文件數，以及使用的磁碟空間量。 按一下資料庫名稱以檢查其內容。

若要建立資料庫，請按一下 建立資料庫，並提供要建立的資料庫名稱。

我們現在有一個新的空資料庫。 這裡會依 ID 順序列出資料庫的文件。 不過，由於此資料庫是新的，因此不存在任何文件。 若要新增文件，請按一下 建立文件。

IBM Cloudant 儀表板已使用預先產生的 _id 為您建立範本文件。 自行完成其餘屬性以完成 JSON 文件，然後按一下 建立文件 以儲存。

現在是做另一個練習的時候了 建立稱為 books 的資料庫，並在該資料庫中建立三個以上具有下列欄位的文件: 標題、作者、日期、發佈者及 ISBN-每一個都代表您選擇的書籍。

建立之後，請編輯其中一個文件，並修改發佈日期。

然後，刪除其中一個文件。

總而言之，IBM Cloudant「儀表板」是內建於 IBM Cloudant 服務的 Web 應用程式，並且是 CouchDB 開放程式碼供應項目的一部分。 它用來管理資料庫、文件、索引、查詢及抄寫工作。 它也可以用來監視服務傳輸量。 Dashboard 只是一個 API 用戶端 - 您可以使用 HTTP API 來編寫任何可以透過 Dashboard 實現的腳本。

這部分就結束了 下一部分稱為 HTTP API 基本知識。

HTTP API 基礎視訊腳本

歡迎使用 IBM Cloudant 課程簡介，這是一個 17 個部分的視訊系列，提供您 IBM Cloudant 資料庫即服務的概觀。

本影片為第 7 部分 - HTTP API 基礎。

在上一部分中，我們看到了 IBM Cloudant 儀表板，它是一個對 IBM Cloudant 的 API 進行 HTTP 呼叫的 Web 應用程式。 在這個步驟中，我們使用命令列提出 HTTP 請求，並嘗試從中新增、編輯和刪除一些文件。

即使您打算使用較高階的用戶端函式庫，也值得從第一原理瞭解 HTTP API。

具有 HTTP API 的資料庫的優勢在於，只要您願意，網際網路上的任何裝置都可以讀寫資料。 不需要特殊軟體。 沒有可使用自訂通訊協定的驅動程式。 只是標準的 HTTP 函式庫。 例如，所有東西都會說 HTTP：

• Web 瀏覽器
• 任何程式設計語言
• 可用來從指令行撰寫 Script 的工具，例如 curl
• 行動式裝置

我們將透過使用 curl 來學習 API，curl 是一個免費的開放原始碼命令列工具，可以派遣 HTTP 請求。 Curl 已預先安裝在大多數 Mac 和類 Unix 作業系統上。 如果您的電腦上沒有此軟體，請 Google curl，並依照安裝指示操作。

讓我們先使用 curl 來提取網頁- Google的首頁。

1. 在指令行終端機中，鍵入 curl https://www.google.com。

   您會在回覆中取得 HTML 的頁面。
   如果此方法有效，則會安裝 curl，且您可以繼續進行後續作業。 現在，我們不想每次都輸入 IBM Cloudant 服務的 URL，因此讓我們將 IBM Cloudant URL 保存在名為的環境變數中URL。

2. 執行 export URL 指令以建立稱為 URL 的變數，稍後我們可以存取該變數。

   export URL=https://username:password@host

3. 建立 alias。

   alias acurl="curl -sgH 'Content-type: application/json'"

   此 alias 是稱為 acurl 的捷徑，可讓我們進一步鍵入。 此 acurl 指令是 curl 的別名，但具有 JSON 內容類型標頭及一些有用的指令行參數。

4. 透過提取 acurl $URL/ 來測試 alias。 我們從 IBM Cloudant取得一些 JSON。

   您已完成第一個 IBM Cloudant API 呼叫。 現在，已設定我們的 acurl 別名。 我們可以開始探索 API。 讓我們從 _all_dbs 端點開始，它會傳回資料庫清單。

5. 鍵入 acurl $URL/_all_dbs 以查看資料庫陣列。

這裡有一個快速附註，說明如何在指令行上格式化 JSON。 我們可以將 acurl 指令的輸出傳送至另一個工具，以在終端機上妥善格式化資料。 以下工具可供您使用：

• Jq 可從頁面上的 URL 取得，它不只是一個 JSON 格式化器 - 它也允許 JSON 被解析、查詢和操作。
• 如果電腦上已安裝 Python，則 python -m json.tool 是簡式 JSON 格式製作程式。

因此 acurl $URL/_all_dbs | jq 表示 將 acurl 的輸出輸入至 jq，而您看到的是正確格式化的彩色輸出。

IBM Cloudant API 路徑是階層式路徑，具有提供服務相關資訊的第一個層次，然後每一個資料庫位於其下的一個層次。

因此，acurl $URL/books 會提供我們先前建立之書籍資料庫的相關資訊。

您可以查看它有多少文件、有多少已刪除文件，以及它佔用多少磁碟空間的相關資訊。

請不要忘記將輸出以管道方式輸入至 jq 或 Python，以取得更漂亮的輸出。

如果我們想要查看資料庫中包含的文件，可以使用 _all_docs 端點。

因此，acurl $URL/books/_all_docs 表示從所提供 URL 的 IBM Cloudant 服務取得書籍資料庫中的所有文件。

此指令的結果會傳回每一個文件的 _id 及 _rev 值清單。 如果您也想要文件內文，請將 ?include_docs=true 新增至 API 呼叫。

如果我們要從資料庫擷取單一文件，那麼在 URL 的層級結構中，文件會比資料庫低一層。

因此 acurl $URL/books/id 表示「從所提供 URL 的 IBM Cloudant 服務的資料庫 books 取得文件 ID」。

請注意階層: 服務、資料庫及文件。

到目前為止，我們只使用 GET HTTP 方法，這是 curl 的預設方法，也是您在網頁瀏覽器中輸入 URL 時使用的方法。

IBM Cloudant 的 API 通常使用 HTTP 方法作為 verb 來描述要求資料庫執行的動作：GET 用於取得資料。

使用 curl，我們可以指定要與 -X 指令行選項搭配使用的方法。

因此，若要將新的文件寫入使用 API 的 books 資料庫，我們會使用 POST 方法，將文件當成 HTTP 請求的正文。

acurl -X POST 指定我們正在使用 POSTHTTP 方法。-d 指定我們要寫入的文檔，該文檔作為請求正文發送，最後，我們要寫入的 URL 是 $URL/books- 書籍資料庫。

或者，如果我們要提供所撰寫文件的 ID，則可以使用 PUT 方法。 URL 變成 $URL/books/，接著是我們要寫的 ID。

這兩種寫入方法都會產生相同的回應。OK: True，表示寫入成功。 ID 是寫入的文件 ID，rev 是資料庫所產生的修訂記號。

要修改一個文件，我們可以使用 PUT 方法將新的正文寫入指向我們要覆蓋的文件 ID 的 URL。-d 提供新的文件正文，而 URL 不僅包含資料庫和文件 ID，還重要的是包含 rev - 我們打算變更的文件的版本。

如果我們忘記並省略 rev 參數，則會收到錯誤回應。

HTTP 回應代碼顯示請求是否成功。 200 範圍內的回應成功。 400 範圍內的回應是使用者錯誤 (例如，無效參數)，而 500 範圍內的回應是伺服器端錯誤。 此外，您還可以透過 -v 命令列選項查看完整的 HTTP 請求與回應，選項為 curl/acurl。

此外，文件的更新也會全部進行或完全不進行。 不存在可修改文件組件的 API 建構。 必須提供整個文件才能改寫前一個修訂。

最後，若要刪除文件，我們使用 DELETE 方法，因此是 -X DELETE。 我們將請求指向 URL，其中包括資料庫名稱和要刪除的文件，關鍵的是，我們還要提供 rev - 要刪除文件的修訂版本。

如果我們省略修訂記號，則會傳回錯誤，且要求會失敗。

總而言之，瞭解 HTTP API 有助於您掌握程式碼與 IBM Cloudant 服務之間的關係。

URL 是階層式: service/database/document 或 service/database/endpoint。

HTTP 方法作為 verbs 定義要執行的動作。

所有動作都可以透過簡單的 HTTP API 呼叫、指令列或程式碼來觸發，因此可以輕鬆編寫腳本。

這部分就結束了 下一個組件稱為 大量 API。

大量 API 視訊 Script

歡迎使用 IBM Cloudant 課程簡介，這是一個 17 個部分的視訊系列，提供您 IBM Cloudant 資料庫即服務的概觀。

此視訊是第 8 部分- Bulk API。

在上一部分，我們看到如何使用 IBM Cloudant 來輕鬆地單獨新增、更新和刪除文件。HTTP API。 在本部分中，我們將看到如何使用兩個 API 呼叫來實現所有基本的 IBM Cloudant 操作。 新增的好處是每個 API 呼叫能夠處理多個文件。

我們已討論 _all_docs 端點。 我們使用它來提取資料庫中所有文件的清單，但它也具有其他特性。

key 參數可用來指定要提取的單一文件，使其等同於 GET /db/id API 呼叫。 同樣地，keys 參數會採用文件 ID 陣列並全部傳回。 startkey 和 endkey 參數會在所提供的限制之間提取主要索引的截塊。 新增 include_docs=true 會指示 IBM Cloudant 也提供文件內文。 而且 limit 指定在一個 API 呼叫中要傳回多少文件。

_bulk_docs 端點容許在一個 API 呼叫中執行多個插入、更新及刪除作業。 它預期包含 docs 陣列的物件-該陣列的每一個元素都是要在單一文件上執行的作業。 要求內文會公佈至 IBM Cloudant，容許將許多作業包裝成單一 API 呼叫。

在此範例中，第一個文件是插入，因為未提供修訂記號。 第二個文件是對文件的更新，因為修訂記號隨新的文件主體一起提供。 第三個文件是刪除。 已提供修訂記號，但內文只是 _deleted: true，它告訴 IBM Cloudant 將文件標示為已刪除。

請務必注意，此實務範例不像關聯式資料庫中的交易-所有這些作業都可能個別成功或失敗。 此要求的回應資料會依序顯示每一個作業的回應。

總之，透過兩個 API 呼叫 _bulk_docs 及 _all_docs，我們可以對 IBM Cloudant 文件執行所有建立、讀取、更新及刪除作業，也可以大量執行這些作業。_all_docs 會依 _id 或 ID 範圍來擷取文件。_bulk_docs 會大量建立、更新及刪除文件。 通常，我們建議批量寫入以 500 個批次執行; 對於小型文件則更多，而對於大型文件則更少。

請從指令行終端機查看使用 IBM Cloudant 的畫面擷取:

這部分就結束了 下一個組件稱為 以程式化方式存取 IBM Cloudant。

存取 IBM Cloudant Programmatically 視訊 Script

歡迎使用 IBM Cloudant 課程簡介，這是一個 17 個部分的視訊系列，提供您 IBM Cloudant 資料庫即服務的概觀。

此視訊是第 9 部分- 存取 IBM Cloudant 以程式化方式。

到目前為止，我們的 API 互動是由儀表板或從指令行使用 curl 所觸發。 在下一節中，我們看到如何以程式化方式存取 IBM Cloudant。

這些範例使用 Node.js，因此如果您想要自行嘗試程式碼，則需要從 nodejs.org安裝節點及 npm。

然後，我們可以使用 npm install @cloudant/cloudant 來安裝正式 IBM Cloudant Node.js 程式庫。 (Npm 是 Node.js 隨附的套件管理程式-可讓您存取數千個開放程式碼專案，並免費將它們建置到您的應用程式中)。

安裝 IBM Cloudant 程式庫之後，我們可以建置一些原始碼。 讓我們逐行逐一瀏覽這個程式碼 Snippet:

IBM Cloudant 服務 URL 是從我們之前建立的環境變數中取得。

@cloudant/cloudant 程式庫已載入至具有內建必要函數的 Node.js 應用程式。 然後，我們會建立程式庫的實例，並以我們在第一行中儲存的認證來配置該程式庫。 我們使用 IBM Cloudant 物件來取得 books 資料庫的參照，並將它儲存在變數資料庫中。 我們尚未進行任何 API 呼叫-只建立儲存認證的資料結構，以及我們正在處理的資料庫。 main 函數會呼叫 db.list，它會對映 1-1 與先前看到的 _all_docs 端點。 傳遞至 db.list 的參數必須很熟悉，因為 _all_docs 預期會限制結果集並傳回每一個 ID 的文件主體。

請參閱另一個撰寫文件的程式碼 Snippet。

您可以從第一行看到標準 JavaScript 物件可以在程式碼中使用，並傳送至 IBM Cloudant 而不進行轉換，因為它們在 JavaScript中原生變成 JSON。

撰寫文件只是呼叫 db.insert 的問題，它會對映至 PUT/POST API 呼叫或 _bulk_docs。

總而言之，IBM Cloudant 的官方程式庫是 Java™、Python和 Nodejs。 它們是 IBM Cloudant 的薄型包裝。HTTP API - 因此值得瞭解底層 API，以瞭解所有參數。

程式庫會為您處理兩件事，這很有用:

鑑別

交換記號的金鑰，不論是舊式鑑別或 IAM。

重試邏輯

程式庫可以配置為重試超出佈建容量的 API 呼叫。 如果以這種方式配置，則他們會使用指數回復來暫停並重新嘗試 API 呼叫多次。

如果您在資料流量中具有暫時且非預期的提升，則重試此類 API 呼叫是明智的。 如果您經常超出佈建的容量，則沒有任何重試量可完成資料庫工作-您需要更多容量!

這部分就結束了 下一個組件稱為 查詢。

查詢視訊 Script

歡迎使用 IBM Cloudant 課程簡介，這是一個 17 個部分的視訊系列，提供您 IBM Cloudant 資料庫即服務的概觀。

此視訊是第 10 部分- 查詢。

到目前為止，我們已從指令行、儀表板及程式碼執行 CRUD (建立、擷取、更新及刪除) 作業。 這些作業使用文件的 _id:

• 由 _id 提取文件。
• 更新其 _id = 'x' 的文件。
• 刪除其 _id = 'x' 的文件。
• 取得 _id 範圍 'a' 至 'z' 內的文件。

這些作業是資料庫的建置區塊，但它們目前只會讓您取得。 如果您需要傳回文件中符合欄位的文件子集，該怎麼辦? 一個人的出生日期? 書的標題? 訂單的價值?

這裡是查詢。

IBM Cloudant 有數個方法可查詢資料。 我們第一個查看稱為 IBM Cloudant 查詢。

IBM Cloudant 查詢語言受到 MongoDB 查詢語言的啟發。 查詢以 JSON 表示，其中 selector 屬性說明要傳回的資料子集。 查詢 JSON 會公佈至資料庫的 _find 端點，以執行查詢。

最簡單的查詢形式是尋找屬性具有固定值的文件，例如，其中 author == J Smith。

第二個範例顯示查詢中的兩個子句。 必須滿足這兩個條款，文件才能進入搜尋結果，例如，其中 isbn === 6725252 AND date = 2018-01-01。

第三個範例顯示如何新增邏輯運算子。 $gt 作業表示 greater than (您也可以使用 gte 代表大於或等於，而 lt/lte 代表小於比較運算子的對等項目)。 $or 運算子是 OR 作業，因此相符文件的日期必須大於查詢中的日期，亦即 J Smith 或「謀殺」標題的作者。

如果您需要存取文件內的物件，您可以使用標準帶點表示法 (例如，address.zipcode ) 來存取地址物件內的郵遞區號字串。

我們也可以新增下列參數:

欄位

指定我們要傳回的文件屬性 (預設值是整個文件)。

排序

定義如何排序資料。 排序是一個陣列，容許在多個屬性上計算排序。

限制

要傳回的文件數量。

如果您來自關聯式資料庫背景，則此查詢相等於最後一個 IBM Cloudant 查詢範例的 SQL 查詢。

WHERE 子句相當於 IBM Cloudant 查詢中的 SELECTOR。ORDER 和 LIMIT 完全相等，而 IBM Cloudant 查詢 FIELDS 清單相當於 SELECT 關鍵字後面以逗點區隔的屬性清單。

JSON 語法可能需要一些習慣，但 MongoDB 使用者可能會發現它很熟悉。

IBM Cloudant 查詢可以在 IBM Cloudant 儀表板中執行。 選取您正在使用的資料庫，例如 books，然後選擇「查詢」標籤。

在提供的方框中輸入 IBM Cloudant 查詢 JSON，並在備妥時按一下 執行查詢。 結果集會出現在頁面上。

「解譯」按鈕用來提供資料庫如何解譯所提供查詢的說明。 當我們在下一個部分開始檢索時，這個解釋變得更加重要。

也可以從 curl 觸發查詢。 在此情況下，「查詢 JSON」會儲存在檔案中，我們使用 -d@ command-line 語法 POST 至 _find 端點。

Node.js 程式碼類似。 「查詢」是標準 JavaScript 物件，它會代表您將 POSTs 傳給 _find 端點的 db.find 函數。

現在是練習的時候了 設計您自己的 IBM Cloudant 查詢，以尋找在 20th 世紀撰寫的書籍標題。 如果您需要，IBM Cloudant 查詢文件位於螢幕上的 URL。

如果您不想知道答案，請暫停這裡的簡報 ...

請參閱一個解決方案:

我使用 $and 運算子來結合日期屬性上的兩個子句。 一個子句，尋找其日期為 >= 1900 的文件，另一個子句，尋找其日期為 < the year 2000 的文件。 這兩個條款都必須為 true 才能選取文件。 因為我們只需要相符書籍的標題，所以可以提供欄位屬性，而不是傳回整個文件。

總而言之，IBM Cloudant 查詢是受 MongoDB 啟發的查詢語言，其中語法以 JSON 形式表示。

查詢會使用對文件內資料執行操作的子句，從資料庫中選取文件子集，而不只是文件的 _id。

查詢會以程式化方式、使用 curl 或使用「儀表板」來傳送至資料庫的 _find 端點。

查詢的選取元會決定需要哪些資料剪下，

這部分就結束了 下一個部分稱為 檢索。

檢索視訊 Script

歡迎使用 IBM Cloudant 課程簡介，這是一個 17 個部分的視訊系列，提供您 IBM Cloudant 資料庫即服務的概觀。

此視訊是第 11 部分- 檢索。

我們在前一部分中執行的查詢不是最佳的: 若要取得答案，IBM Cloudant 必須輪流排存資料庫中的每一份文件，以查看它是否符合搜尋準則。

若要建立以高效能及可調式方式執行的查詢，我們需要 檢索。

使用 IBM Cloudant，您可以指定任意數目的 索引 (或索引)。

索引是從文件清單建置的次要資料結構。 它包含依您指定的欄位排序的資料，例如，依日期和標題排序的書籍。 如果您執行查詢來要求符合文件日期和標題的資料，則可以使用索引資料結構來加速查詢程序。 IBM Cloudant 可以跳至索引的相關部分 (例如，20th 書籍上的小節)，並更快速地擷取資料。

IBM Cloudant 查詢索引包括兩種類型的索引: type=json 和 type=text。 這些索引是由我們在本課程後續部分中所符合的兩種基礎索引技術所支援。

當您 POST 某個 JSON 至資料庫的 _index 端點時，會定義索引。

索引物件包含欄位陣列，指定要檢索的文件屬性。 通常，需要檢索的欄位相當於您要用來擷取資料之查詢的 selector 中所使用的屬性。 也就是說，如果您需要依日期欄位來查詢，我們需要為日期欄位編製索引。

雖然索引的 name 是選用的，但這是良好的作法，我們遵循此慣例。 最好詢問 IBM Cloudant 問題，並指定您想要使用的索引名稱。 此作法可讓 IBM Cloudant 不必從可用的索引中選擇要使用的索引，而且可讓您輕鬆記住哪一個索引。

讓我們從儀表板在 books 資料庫上建立索引。 選取資料庫，然後從功能表中選擇 設計文件 標籤及 查詢索引。

任何現有的索引都會列在端面上: 根據文件的 _id，special 索引必須存在代表主要索引。

使用 JSON 完成索引定義:

完成後按一下建立索引。

按一下按鈕會將 POST 要求傳送至 _index 端點 (其他 API 呼叫可用來更新及刪除現有索引)。

索引由 IBM Cloudant 在背景中非同步建置。 對於大型資料庫，第一次建構索引可能需要 IBM Cloudant 一些時間。 在該起始建置備妥之前，索引無法使用資料庫。

我們可以重複查詢 20th 世紀的書籍。 這次我們以 use_index 欄位來指定索引名稱。 答案會傳回-這次是由我們的索引所提供。 您可能不會注意到小型資料庫的速度改善，但隨著您的資料大小和查詢量成長，肯定會感受到好處。 檢索可協助您在應用程式調整時保持查詢效能。

當您告訴 IBM Cloudant 建立次要索引時，它會啟動背景作業，依序查看所有文件，並在磁碟上建立新的資料結構: 索引。 索引是平衡樹狀結構，它會將索引鍵 (您需要檢索的屬性) 與它們來自的文件 _id 配對。

索引可用來有效地查閱已知索引鍵及索引鍵範圍，而無需重新掃描整個資料庫。

您可以在索引時間使用的另一個技巧是局部過濾器。 您可以選擇性地在索引定義中提供局部過濾器。 此 IBM Cloudant 查詢選取元會在索引時執行，以決定哪些文件的資料會成為索引，哪些會被忽略。

在此範例中，採用的選取器只容許位於週末的日期進入索引。 較小的索引更快速且更有效率。 如果您的使用案例只需要要編製索引的資料子集，則索引時間的局部過濾器選取器有助於使索引更小且更有效率。 例如，您可能只想檢索已完成的訂單，或只檢索過期的帳戶，或只檢索已發佈的部落格文章。

總而言之，_index 端點是用來定義索引，而且可以在查詢時套用選用的局部過濾器，以建立較小的稀疏索引。

這部分就結束了 下一個組件稱為 MapReduce。

MapReduce 視訊 Script

歡迎使用 IBM Cloudant 課程簡介，這是一個 17 個部分的視訊系列，提供您 IBM Cloudant 資料庫即服務的概觀。

此視訊是第 12 部分- MapReduce。

我們看到 _find 和 _index 端點的組合如何容許對 JSON 文件的內容執行查詢。 它們由次要索引支援，可讓查詢隨您的應用程式成長而擴充。

在此部分中，我們引進另一種方法來配置稱為 MapReduce的次要索引。

MapReduce 過去是在 CouchDB 中配置次要索引的唯一方式，而且仍然是從文件主體內查詢資料的熱門方式。

若要建立 MapReduce 索引，您需要提供 JavaScript 函數，該函數包裝在特殊文件中，稱為 IBM Cloudant的設計文件。 設計文件的 _id 欄位以 _design/ 開頭，例如 _design/mydesigndoc。

當 IBM Cloudant 收到設計文件時，它會設定背景檢索作業，並依序將每一份文件從資料庫傳遞至 JavaScript 函數。 JavaScript 函數發出的索引鍵值會形成持續保存的索引基準。

讓我們查看一些範例 JavaScript 函數。

此函數接受一個參數-由 IBM Cloudant 檢索程式傳遞給它的文件。 每次您的函數呼叫會發出您從索引鍵值傳遞的參數。

第一個範例會發出 doc.name 索引鍵，因此在此情況下，它是依名稱欄位查閱的索引。 值沒有任何 (空值)。

第二個範例會在發出之前預先處理資料。 此預先處理是整理字串、修整空格、小寫及大寫文字、將預設值套用至遺漏資料，或將值限制在特定範圍等有用的方法。

第三個範例新增邏輯: 只有 published 的文件才會成為索引。 此邏輯相當於我們使用 IBM Cloudant Query 看到的局部過濾器選取器。

索引會以非同步方式建置，且在完成建置之前無法使用。 建置之後，它們可以用於依索引鍵、索引鍵清單、索引鍵範圍及資料聚集進行選取。 例如，尋找兩個日期之間的訂單，並計算訂單的總值 (依月份分組)。

IBM Cloudant 包含四個內建縮減器 (如果您計算 none，則為五個)。

_count

為了數數的東西

_sum

用於總計值。

_stats

用於提供適用於計算平均數、變異數和標準差的計數和總計。

_approx_count_distinct

用於索引鍵唯一值的近似計數。

將 doc 傳遞給設計文件的 MAP 函數-在資料庫中，每個文件會呼叫一次該函數。 emit 來自 MAP 函數的任何鍵值組都會建立索引。

KEY 是您要 select 開啟的事物 (或事物) (例如，日期)。

VALUE 是您需要報告的事物 (例如，總銷售額)。

「減量器」是 _sum，因此 VALUE 會以相符索引鍵 (例如，相同日期的訂單) 來計算總計。

請在 IBM Cloudant 儀表板中查看定義 MapReduce 的內容。

建置 MapReduce 視圖時，可以查詢它以查看儲存在索引中的每一個 KEY-VALUE 配對。

或者，如果開啟減速器，則可以根據每個鍵的值對結果集進行分組。 在此情況下，我們會對每一天的銷售進行總計。

視圖可以查詢個別索引鍵 (例如，特定日期的銷售)、所有索引鍵或索引鍵範圍 (例如，兩個日期之間)。

MapReduce 視圖以非同步方式建置，可能需要一些時間才能備妥用於大型資料集。

請參閱一些提示:

在 JavaScript 中使用邏輯，只包含有意義的資料，例如，只將已完成的訂單總計。 索引鍵不必是字串。 一般型樣是使用陣列索引鍵，例如年、月、日的陣列。 這些索引鍵容許依陣列中的元素進行查詢時間分組。 例如，您可以依年份分組訂單，依年份和月份分組訂單，依年份和月份和日期分組訂單。 適用於可讓使用者往下探查詳細資料的摘要報告。 該值可以是字串、數字，有時也可以是包含文件子集的小型物件。 可以使用該物件，而不新增 include_docs=true，這也會在結果集中傳回文件的主體。

總而言之，MapReduce 是定義容許選取及聚集資料之索引的低階方法。

使用 JavaScript 邏輯來決定哪些資料會成為索引。 選擇如何透過發出鍵值來形成索引。

使用內建縮減器來彙總資料。 有效率地從大量資料產生簡要報告。

MapReduce 非常適用於應用程式需要反覆執行的樣板查詢。 不適用於資料探索的一次性特定查詢。

這部分就結束了 下一個部分稱為 日期。

日期視訊 Script

歡迎使用 IBM Cloudant 課程簡介，這是一個 17 個部分的視訊系列，提供您 IBM Cloudant 資料庫即服務的概觀。

此視訊是第 13 部分- 日期。

在本課程之前，我們看到 JSON 只原生對字串、數字、布林、物件及陣列進行建模。 一般使用案例是將日期或日期和時間值儲存在資料庫中。 請參閱如何使用 IBM Cloudant達成此目標的一些構想。

代表時間的 ISO-8601 字串格式由 y-m-dTh:m:s.msTIMEZONE 年、月、日、' T' 字元、小時、分鐘、秒、毫秒及時區組成。

我一律建議將日期儲存在 UTC 時區，即使您從不同地理位置收集資料也一樣。 儲存在此表單中的日期可以輕鬆地轉換為前端的當地時區。 通常重要的是將每一個使用者的資料儲存在「相同單元」中。

此字串格式依日期和時間順序排序 (因為最重要的日期單位位於字串前面)，並且可以在 MapReduce 函數中輕鬆剖析。

另一個選項是儲存 01-January-1970以來的毫秒數。 這個選項也是代表日期和時間的標準機器可讀方式。

它也可以在 MapReduce 函數中剖析，而且很方便用來比較兩個日期: 只需從另一個日期取得一個時間戳記。

總而言之，JSON 中不存在任何原生日期格式，因此您可以按喜歡的方式儲存日期和時間。 ISO-8601 精簡、可讀取且妥善地排序，如同時間戳記 (自 1970 年以來的毫秒數)。

如果您需要對其中一個元件組件使用 IBM Cloudant 查詢，則需要在文件中明確細分。

這部分就結束了 下一個部分稱為 抄寫。

抄寫視訊 Script

歡迎使用 IBM Cloudant 課程簡介，這是一個 17 個部分的視訊系列，提供您 IBM Cloudant 資料庫即服務的概觀。

此視訊是第 14 部分- 抄寫。

抄寫是 IBM Cloudant的核心特性。 它是將資料從一個資料庫 (來源) 傳送至另一個資料庫 (目標)。

來源和目標資料庫可以位於相同的 IBM Cloudant 服務上，或在地理上彼此分隔，例如，在歐洲抄寫到一個資料庫的 US IBM Cloudant 資料庫。

IBM Cloudant 抄寫通訊協定與 Apache CouchDB共用，因此，將資料從雲端型資料庫複製到其專屬位置中執行 CouchDB 的企業通常會使用抄寫。

PouchDB, JavaScript-based CouchDB 克隆，可在 Node.js 堆疊或網頁瀏覽器中執行，也可用於在 IBM Cloudant 或 CouchDB, 之間以每種方式複製資料，無論是複製到哪裡或從哪裡複製。

IBM Cloudant Sync 程式庫是原生 iOS 或 Android 應用程式，可與 IBM Cloudant 服務來回同步資料。

抄寫是從來源到目標的單向作業，它會移動所有資料 (刪除、衝突、附件及文件)，並且可以透過下列兩種方式之一來觸發:

1. 執行直到來源中的所有資料都達到目標，然後停止。
2. 與相同，但抄寫會持續持續執行，並在來源到達時將新資料從來源傳送至目標。

抄寫也可以從前次停止的位置回復。IBM Cloudant 會在抄寫方之間保留 checkpoints 的附註，以容許從其前次已知位置回復預先存在的抄寫。

IBM Cloudant 儀表板包括抄寫標籤。 透過指定包含鑑別認證的來源和目標資料庫，以及此抄寫是一次性還是連續作業，來啟動抄寫。

也可以為抄寫提供一個名稱，這對於追蹤哪一個抄寫工作是很方便的。

現在是練習的時候了

1. 移至 IBM Cloudant 儀表板。
2. 建立稱為 books2 的資料庫。
3. 啟動從 books 至 books2 的連續抄寫。
4. 請造訪 books2 資料庫，以檢查 books 中的文件現在位於 books2 中。
5. 將文件新增至 books 資料庫。
6. 驗證變更是否對 books2 資料庫進行。

抄寫可用來將資料從 IBM Cloudant 資料庫移至內部部署 CouchDB 實例。 抄寫可以由 IBM Cloudant 或 CouchDB控制。 例如，您可以要求 IBM Cloudant 將其變更傳送給 CouchDB, 也可以要求 CouchDB 從 IBM Cloudant 中拉取變更。 複製控制器必須具有兩個 HTTP API 的網路可見性。

PouchDB 也會使用相同的抄寫通訊協定，因此它可以用來與 PouchDB 及 IBM Cloudant來回傳送資料。 在此情況下，PouchDB 很可能是抄寫控制器。

PouchDB 通常用來建立離線優先應用程式。 這些應用程式即使未連接至網際網路也會收集資料，然後在它們回到線上時將資料寫入 IBM Cloudant，讓其使用者隨時可以使用服務。

無法一律需要抄寫。 如果您的應用程式需要儲存資料，然後稍後將它寫入 IBM Cloudant，則不嚴格要求抄寫。 只需要將資料儲存在裝置上，並在還原連線時將大量寫入 IBM Cloudant。

由於抄寫是單向作業，如果在不同地區的兩個 IBM Cloudant 實例之間需要主要-主要設定，則需要兩個相反方向的抄寫。

倫敦端發生的變更會傳送至達拉斯，反之亦然。

可以使用更複雜的拓蹼，資料在環中圍繞一組 IBM Cloudant 服務流動。

總而言之，IBM Cloudant 抄寫是將資料從來源資料庫複製到目標資料庫的機制。

抄寫可以是一次性或連續的，並且可以選擇性地使用 JavaScript 函數或 IBM Cloudant 查詢選取器進行過濾，並且可以從前一個抄寫停止的位置回復。

這部分就結束了 下一個組件稱為 分割的資料庫。

分割的資料庫視訊 Script

歡迎使用 IBM Cloudant 課程簡介，這是一個 17 個部分的視訊系列，提供您 IBM Cloudant 資料庫即服務的概觀。

此視訊是第 15 部分- 分割的資料庫。

IBM Cloudant 是分散式資料庫，即將進行討論。 許多儲存節點組成 IBM Cloudant 服務，資料庫的文件會分散在稱為 shards 的群組中的節點。 單一資料庫被認為是 sharded 或分成多個部分。

在一般 IBM Cloudant 資料庫中，會為文件以演算法方式配置 Shard，有效的文件會隨機分佈在 Shard 周圍。

在分割的資料庫中，您可以透過提供分割區索引鍵來定義儲存文件的 Shard。

分割的資料庫不是使用相同的 PUT /<database name> API 呼叫來建立，而是使用額外的查詢字串參數: partitioned=true。

在第一個範例中，產品資料庫建立為分割的資料庫，在第二個範例中，建立為標準未分割的資料庫。

當您將文件新增至分割的資料庫時，必須提供文件 _ID-(不存在自動產生的文件 _ID)。 文件 _id 有兩個部分，以冒號字元區隔:

分割區索引鍵

定義在哪個分割區上儲存文件的字串。

文件索引鍵

在分割區內唯一識別文件的字串。

在第一個範例中，將書籍新增至產品資料庫的書籍分割區。

然後，將另一個文件新增至 DVD 分割區，並將第三個文件新增至家用分割區。

這樣做的效果是共用分割區索引鍵的文件位於資料庫的相同 Shard 中。 相同分割區中的文件會以文件索引鍵順序一起儲存。

擷取資料時有好處。 我們可以引導 IBM Cloudant 查詢、MapReduce 要求，以及在單一分割區中搜尋。 在此範例中，IBM Cloudant 查詢選取器正在傳送至 book 分割區。 此動作表示您只練習部分 IBM Cloudant 基礎架構 (僅使用管理書籍分割區的 Shard，其餘叢集仍保持閒置)。

此實務範例提供更快速的查詢效能、更便宜的查詢成本，以及更好的可調整性。

分割查詢效能提升的索引鍵是分割鍵的選擇:

它必須是在資料集內重複的值。 例如，book 分割區中存在數個項目。 需要有多個分割區。 如果您只有幾個種類，則種類不是分割區索引鍵的正確選擇。 它必須是具有許多值的項目，例如 IoT 應用程式中的 deviceId 或電子商務系統中的 orderId。 它需要符合應用程式正在進行的查詢。 如果最常見的使用案例是在產品種類內搜尋，則依種類進行分割可能很適合。 避免熱分割區-資料流量必須平均分散在分割區中。 如果您選擇的分割區索引鍵可能會導致資料流量大幅增加，並命中少數分割區，則此實務範例會導致分割區索引鍵選擇不佳。

總而言之，分割的資料庫是使用 partitioned=true 旗標來建立，而文件具有兩部分的 ID，其中分割鍵及文件索引鍵是由冒號字元所結合。

相同分割區中的文件會以文件索引鍵順序儲存在相同的資料庫 Shard 中。 瞭解這種儲存方法，我們可以讓查詢指向執行更快速且更便宜的單一分割區。

仍然可以在分割的資料庫中跨分割區進行查詢。 當您建立次要索引時，您可以選擇其目的是針對每個分割區還是廣域範圍。

這部分就結束了 下一個組件稱為 IBM Cloudant 搜尋。

IBM Cloudant 搜尋視訊 Script

歡迎使用 IBM Cloudant 課程簡介，這是一個 17 個部分的視訊系列，提供您 IBM Cloudant 資料庫即服務的概觀。

此視訊是第 16 部分- IBM Cloudant 搜尋。

我們有另一種在 IBM Cloudant 中查詢及檢索的方法，稱為 IBM Cloudant 我們在此部分中短暫探索的搜尋。

IBM Cloudant 搜尋是以另一個開放程式碼專案 Apache Lucene 為建置基礎，該專案可加強許多產品 (包括 Elasticsearch) 的搜尋功能。

它主要設計用於任意文字搜尋，其中文字區塊會在檢索之前預先處理: 移除大小寫、標點符號、一般雜訊字，以及修整一般語言特定的單字結尾，例如，農民變成農場，而農場變成農場。

此文字處理是由在查詢時搜尋的分析器選項所執行。 在此時間之前，它還容許使用稱為資料類型的技術的部分聚集功能。

提供 JavaScript 函數來建立 IBM Cloudant 搜尋索引。 它與 MapReduce, 並不相同，只是這次，emit 函式被索引函式取代，索引函式會預期欄位名稱、資料本身，以及一些選項。

在此範例中，會使用預設選項來檢索文件的名稱及標題。 種類會指定為資料類型 (聚集功能)，且 ISBN 會儲存在索引中，但不會為搜尋本身編製索引。 有時，將部分項目儲存在索引中，比在查詢時執行 include_docs=true 更有效率。

Lucene 有自己的查詢語言，可建立查詢來比對具有邏輯、模糊比對、範圍及術語提升的子句組合。

請參閱下列範例：

• 尋找其標題符合 gastby 且其作者開頭為 fitz 的文件。 請注意星號萬用字元。
• 尋找其 author 在 austen to dickens 範圍內的文件。 此範例顯示字串欄位的範圍查詢。
• 尋找其價格為 0 - 100 AND 且其年份位於 19th century 或其作者符合 charles dickens 的文件。 此範例顯示如何將邏輯建置到查詢中。

IBM Cloudant 搜尋不僅適用於任意文字搜尋。 當您知道要搜尋哪些屬性，但每次都以不同的屬性組合來改變查詢時，它也很有用。 使用固定順序 MapReduce 索引很難實作此彈性。

資料類型是聚集的一種形式。 您可以指定個別索引欄位以在索引時間進行資料類型化，並在查詢時間使用參數啟動聚集。

它有兩個用途:

計算結果集中的重複值，例如屬於結果集中每個種類的產品計數。 或者，計算數值範圍中的項目數，例如每一個價格範圍中的產品計數。 這兩種計數形式都可以呈現給前端使用者，作為進一步過濾現有搜尋以縮小搜尋範圍的方法。 例如，客戶搜尋 Fender，然後按一下 Amps，再按一下價格範圍 under $500。 所有此搜尋及過濾都可以採用 IBM Cloudant 搜尋。

總而言之，IBM Cloudant 搜尋索引是以提供的 JavaScript 函數來定義。 它們以 Apache Lucene 為建置基礎，主要用於任意文字搜尋比對，但查詢語言有助於在一組固定的索引欄位上建置彈性查詢。 它還具有一些適用於往下探查使用者介面的強大計數聚集。

IBM Cloudant 搜尋也會開啟 type=text IBM Cloudant 查詢索引的電源，因此會使用 _find API 來顯示其功能的子集。

這部分就結束了 下一個組件稱為 在機罩下。

在 hood 視訊 Script 下

歡迎使用 IBM Cloudant 課程簡介，這是一個 17 個部分的視訊系列，提供您 IBM Cloudant 資料庫即服務的概觀。

此視訊是組件 17- 在機罩下。

讓我們看看 IBM Cloudant 服務的組織方式: 此概觀適用於對映至 CouchDB 2 和 3 的 IBM Cloudant 服務。 CouchDB 4 建置在不同的技術上。

IBM Cloudant 是資料儲存在儲存節點叢集周圍的分散式資料庫。 將 IBM Cloudant 服務想像成節點環，在本例中是 12。 每個節點都可以處理送入的 API 呼叫，且每個節點都負責儲存部分資料: 叢集中存在的資料庫的 Shard 及相關聯的次要索引。

當資料寫入 IBM Cloudant時，環中的其中一個節點會處理要求: 其工作是指示將資料的三個副本儲存在三個儲存節點中。 資料會儲存在 IBM Cloudant中，因此資料庫的每一個 Shard 都會儲存多次，通常是跨地區的可用性區域。

當您發出 API 呼叫以寫入資料並取得回應時，我們會將資料寫入三個儲存節點中至少兩個。 資料會清除至磁碟-它不會快取在記憶體中以清除資料。 我們認為這種技術風險太高，容易遺失資料。

當您建立資料庫時，會建立分佈在叢集周圍的一些資料庫 Shard (依預設為 16)。 每個 Shard 有三個副本，等於 48 個 Shard 副本。

您沒有看到任何此活動。 當您建立資料庫時，會為您透通地處理活動。

如果節點關閉或需要重新開機以進行維護，會發生什麼情況? 叢集的其餘部分正常繼續。 大部分 Shard 仍有三個資料副本，但部分 Shard 只有兩個資料副本。 API 呼叫會繼續正常運作，只會寫入兩個資料副本。

即使有兩個節點關閉，大部分 Shard 仍有三個副本，有些有兩個，有些則有一個。 雖然 HTTP 回應碼反映出未達到兩個節點確認的法定人數，但寫入仍可繼續運作。

讀的故事是一樣的 服務繼續使用失敗的節點。 我們可以在一個失敗的節點中存活下來

或多個失敗節點。 如果存在每一個節點的副本，API 會繼續運作。

當節點傳回時，它會從對等節點中擷取任何遺漏的資料，然後回到服務中，處理 API 呼叫並回答資料的查詢。

此配置的本質是 IBM Cloudant 顯示最終一致性。 任何節點都可以處理要求。 資料分佈在節點周圍，沒有您在關聯式資料庫中可能看到的鎖定類型。

IBM Cloudant 支援可用性而非一致性: 它寧願啟動並回答 API 呼叫，也不願關閉，因為它無法提供一致性保證。 (關聯式資料庫通常以相反方式配置: 它以一致方式運作或完全不運作。) 開發人員最終一致性的結果是您的應用程式不得在短時間內 read its writes。 可能存在一個小視窗，其中可能會看到比您更新的文件版本更舊的文件版本。 最終，資料會在叢集周圍流動，在大部分情況下，仲裁機制會提供一致性的錯覺，但最好不要依賴它。

在 CouchDB 4 及基於該程式碼版本的 IBM Cloudant 服務中，會採用不同的一致性模型。

如果您的資料模型需要您在短時間內不斷更新文件，則可能會接受相同修訂號碼的多次寫入。 這些寫入會導致修訂樹狀結構中的分支-稱為衝突。 在此範例中，以兩種不同方式修改修訂 2，導致兩個修訂 3s。 可以以程式化方式來處理衝突，但必須避免衝突，因為它們可能會在極端情況下造成效能問題。

當您使用抄寫並以不同方式修改文件，然後使用抄寫在中合併衝突的修訂時，也會發生衝突。在此情況下，IBM Cloudant 不會丟棄資料。 已選擇 winning 修訂，但可以存取未獲勝的修訂，而且您的應用程式可以透過選取新的獲勝者、刪除不想要的修訂或您需要的任何動作來解決衝突。 衝突不是錯誤狀況。 這是具有中斷連線的資料副本的負面影響，可以在不鎖定的情況下進行修改。IBM Cloudant 選擇處理衝突，方法是不捨棄衝突變更，但將它們儲存為衝突。

若要檢查文件是否有衝突，只需將 ?conflicts=true 新增至單一文件的提取。 任何衝突的修訂都會列在 _conflicts 陣列中。

您可以使用一般 DELETE 作業，並指定您要刪除之修訂的修訂記號，來移除不想要的修訂。 大量 API 也有助於移除衝突的修訂，即使從相同文件中移除多個衝突也一樣。

總而言之，IBM Cloudant 是儲存資料庫的分散式服務，資料庫分成多個 Shard，每個 Shard 的三個副本分散在儲存節點的環。IBM Cloudant 最終會一致，偏好高可用性而不是強一致性。

避免重複寫入相同的文件，以免造成衝突。 雖然衝突有時在抄寫狀況中是不可避免的。

擁抱最終一致性-不要嘗試使 IBM Cloudant 一致。

基於 CouchDB 4 的 IBM Cloudant 產品可能具有不同的一致性模型。

這門課就結束了 如需相關資訊，請參閱 IBM Cloudant 文件 及 部落格。