本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 遷移至 Amazon Keyspaces （適用於 Apache Cassandra) 遷移至 Amazon Keyspaces （適用於 Apache Cassandra) 可為企業和組織帶來一系列令人信服的好處。以下是讓 Amazon Keyspaces 成為遷移之吸引人選擇的一些主要優勢。 + **可擴展性** – Amazon Keyspaces 旨在處理大量工作負載並無縫擴展，以適應不斷增長的資料磁碟區和流量。使用傳統 Cassandra，擴展不會隨需執行，需要規劃未來的尖峰。使用 Amazon Keyspaces，您可以根據需求輕鬆擴展或縮減資料表，確保您的應用程式可以在不影響效能的情況下處理流量突然激增的情況。 + **效能** – Amazon Keyspaces 提供低延遲的資料存取，讓應用程式能夠以卓越的速度擷取和處理資料。其分散式架構可確保讀取和寫入操作分散在多個節點，即使在高請求率下也能提供一致的單一位數毫秒回應時間。 + **全受**管 – Amazon Keyspaces 是由 提供的全受管服務 AWS。這表示 會 AWS 處理資料庫管理的操作層面，包括佈建、組態、修補、備份和擴展。這可讓您更專注於開發應用程式，而非資料庫管理任務。 + **無伺服器架構** – Amazon Keyspaces 是無伺服器。您只需為消耗的容量付費，而不需要預先佈建容量。您沒有要管理的伺服器或要選擇的執行個體。此pay-per-request模式提供成本效益和最低的營運開銷，因為您只需支付使用的資源，而不需要佈建和監控容量。 + **具有結構描述的 NoSQL 彈性** – Amazon Keyspaces 遵循 NoSQL 資料模型，在結構描述設計中提供彈性。使用 Amazon Keyspaces，您可以存放結構化、半結構化和非結構化資料，使其非常適合處理多樣化和不斷變化的資料類型。此外，Amazon Keyspaces 會在寫入時執行結構描述驗證，以便集中演進資料模型。這種靈活性可加快開發週期，並更輕鬆地適應不斷變化的業務需求。 + **高可用性和耐久性** – Amazon Keyspaces 會跨 中的多個[可用區域](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/)複寫資料 AWS 區域，以確保高可用性和資料耐久性。它會自動處理複寫、容錯移轉和復原，將資料遺失或服務中斷的風險降至最低。Amazon Keyspaces 提供高達 99.999% 的可用性 SLA。如需更多彈性和低延遲本機讀取，Amazon Keyspaces 提供[多區域複寫](multiRegion-replication.md)。 + **安全性與合規** – Amazon Keyspaces 與 整合， AWS Identity and Access Management 以進行精細存取控制。它提供靜態和傳輸中的加密，有助於提高資料的安全性。第三方稽核人員已評估 Amazon Keyspaces 對特定計劃的安全性和合規性，包括 HIPAA、PCI DSS 和 SOC，讓您能夠符合法規要求。如需詳細資訊，請參閱[Amazon Keyspaces 的合規驗證 （適用於 Apache Cassandra)](Keyspaces-compliance.md)。 + **與 AWS 生態系統整合** – 作為生態系統的一部分 AWS ，Amazon Keyspaces 與其他 無縫整合 AWS 服務，例如 AWS CloudFormation Amazon CloudWatch 和 AWS CloudTrail。此整合可讓您建置無伺服器架構、利用基礎設施做為程式碼，以及建立即時資料驅動型應用程式。如需詳細資訊，請參閱[監控 Amazon Keyspaces （適用於 Apache Cassandra)](monitoring-overview.md)。 **Topics** + [建立遷移計畫，以從 Apache Cassandra 遷移至 Amazon Keyspaces](migrating-cassandra.md) + [如何選取正確的工具，將資料大量上傳或遷移至 Amazon Keyspaces](migrating-tools.md) # 建立遷移計畫，以從 Apache Cassandra 遷移至 Amazon Keyspaces 若要成功從 Apache Cassandra 遷移至 Amazon Keyspaces，建議您檢閱適用的遷移概念和最佳實務，以及可用選項的比較。 本主題概述遷移程序如何運作，方法是介紹幾個關鍵概念，以及您可以使用的工具和技術。您可以評估不同的遷移策略，以選取最符合您需求的遷移策略。 **Topics** + [功能相容性](#migrating-cassandra-compatibility) + [預估 Amazon Keyspaces 定價](#migrating-cassandra-sizing) + [選擇遷移策略](#migrating-cassandra-strategy) + [線上遷移至 Amazon Keyspaces：策略和最佳實務](migrating-online.md) + [離線遷移程序：Apache Cassandra 到 Amazon Keyspaces](migrating-offline.md) + [使用混合遷移解決方案：Apache Cassandra 到 Amazon Keyspaces](migrating-hybrid.md) ## 功能相容性 在遷移之前，請仔細考慮 Apache Cassandra 和 Amazon Keyspaces 之間的功能差異。Amazon Keyspaces 支援所有常用的 Cassandra 資料平面操作，例如建立金鑰空間和資料表、讀取資料和寫入資料。 不過，Amazon Keyspaces 不支援一些 Cassandra APIs。如需支援 APIs的詳細資訊，請參閱 [支援的 Cassandra APIs、操作、函數和資料類型](cassandra-apis.md)。如需 Amazon Keyspaces 和 Apache Cassandra 之間所有功能差異的概觀，請參閱 [功能差異：Amazon Keyspaces 與 Apache Cassandra](functional-differences.md)。 若要比較您使用的 Cassandra APIs 和結構描述與 Amazon Keyspaces 中支援的功能，您可以執行 [GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/toolkit-compat-tool.py) 上的 Amazon Keyspaces 工具組中提供的相容性指令碼。 **如何使用相容性指令碼** 1. 從 [GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/toolkit-compat-tool.py) 下載相容性 Python 指令碼，並將其移至可存取現有 Apache Cassandra 叢集的位置。 1. 相容性指令碼使用與 類似的參數`CQLSH`。針對 `--host`和`--port`輸入 IP 地址，以及您用來連接和執行查詢到叢集中其中一個 Cassandra 節點的連接埠。 如果您的 Cassandra 叢集使用身分驗證，您也需要提供 `-username`和 `-password`。若要執行相容性指令碼，您可以使用下列命令。 ``` python toolkit-compat-tool.py --host hostname or IP -u "username" -p "password" --port native transport port ``` ## 預估 Amazon Keyspaces 定價 本節提供從 Apache Cassandra 資料表收集所需資訊的概觀，以計算 Amazon Keyspaces 的預估成本。每個資料表都需要不同的資料類型、需要支援不同的 CQL 查詢，並維護獨特的讀取/寫入流量。 根據資料表來考慮您的需求，符合 Amazon Keyspaces 資料表層級的資源隔離和[讀取/寫入輸送量容量模式](ReadWriteCapacityMode.md)。使用 Amazon Keyspaces，您可以獨立定義資料表的讀取/寫入容量和[自動擴展政策](autoscaling.md)。 了解資料表需求可協助您根據功能、成本和遷移工作來排定遷移資料表的優先順序。 在遷移之前收集下列 Cassandra 資料表指標。此資訊有助於估算 Amazon Keyspaces 上的工作負載成本。 + **資料表名稱** – 完整金鑰空間和資料表名稱的名稱。 + **描述** – 資料表的描述，例如其使用方式，或其中存放的資料類型。 + **每秒平均讀取**次數 – 在大型時間間隔內，相對於資料表的平均座標層級讀取次數。 + **每秒平均寫入**次數 – 在大量時間間隔內，資料表的座標層級寫入平均次數。 + 以**位元組為單位的平均資料列大小** – 以位元組為單位的平均資料列大小。 + **以 GBs為單位的儲存體**大小 – 資料表的原始儲存體大小。 + **讀取一致性明細** – 使用最終一致性 (`LOCAL_ONE` 或 `ONE`) 與強式一致性 () 的讀取百分比`LOCAL_QUORUM`。 此資料表顯示您在規劃遷移時需要彙整的資料表相關資訊範例。 **** | 資料表名稱 | Description | 每秒平均讀取數 | 每秒平均寫入數 | 平均資料列大小，以位元組為單位 | 儲存體大小，以 GBs為單位 | 讀取一致性明細 | | --- | --- | --- | --- | --- | --- | --- | | mykeyspace.mytable | 用來存放購物車歷史記錄 | 10,000 | 5,000 | 2，200 | 2,000 | 100% `LOCAL_ONE` | | mykeyspace.mytable2 | 用來存放最新的設定檔資訊 | 20,000 | 1,000 | 850 | 1,000 | 25% `LOCAL_QUORUM` 75% `LOCAL_ONE` | ### 如何收集資料表指標 本節提供如何從現有 Cassandra 叢集收集必要資料表指標的逐步說明。這些指標包括資料列大小、資料表大小和每秒讀取/寫入請求數 (RPS)。它們可讓您評估 Amazon Keyspaces 資料表的輸送量容量需求，並預估定價。 **如何在 Cassandra 來源資料表上收集資料表指標** 1. 判斷資料列大小 資料列大小對於判斷 Amazon Keyspaces 中的讀取容量和寫入容量使用率非常重要。下圖顯示 Cassandra 字符範圍內的典型資料分佈。 ![\[圖表顯示使用murmur3分割區的 Cassandra 字符範圍的一般資料分佈。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/migration/migration-data-distribution.png) 您可以使用 [GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/row-size-sampler.sh) 上可用的資料列大小採樣器指令碼，收集 Cassandra 叢集中每個資料表的資料列大小指標。 指令碼會使用 `cqlsh`和 從 Apache Cassandra 匯出資料表資料，`awk`以計算資料列大小與可設定之資料表資料範例集之間的最小、最大、平均和標準差。資料列大小取樣器會將引數傳遞至 `cqlsh`，因此相同的參數可用於連接和讀取 Cassandra 叢集。 下列陳述式為範例。 ``` ./row-size-sampler.sh 10.22.33.44 9142 \\ -u "username" -p "password" --ssl ``` 如需如何在 Amazon Keyspaces 中計算資料列大小的詳細資訊，請參閱 [估計 Amazon Keyspaces 中的資料列大小](calculating-row-size.md)。 1. 決定資料表大小 使用 Amazon Keyspaces，您不需要預先佈建儲存體。Amazon Keyspaces 會持續監控資料表的計費大小，以判斷您的儲存費用。儲存空間按 GB 月計費。Amazon Keyspaces 資料表大小是根據單一複本的原始大小 （未壓縮）。 若要監控 Amazon Keyspaces 中的資料表大小，您可以使用指標 `BillableTableSizeInBytes`，該指標會針對 中的每個資料表顯示AWS 管理主控台。 若要預估 Amazon Keyspaces 資料表的計費大小，您可以使用下列兩種方法之一： + 使用平均資料列大小，並乘以數字或資料列。 您可以將平均資料列大小乘以 Cassandra 來源資料表中的資料列數，以估計 Amazon Keyspaces 資料表的大小。使用上一節的資料列大小範例指令碼來擷取平均的資料列大小。若要擷取資料列計數，您可以使用 等工具`dsbulk count`來判斷來源資料表中的資料列總數。 + 使用 `nodetool`收集資料表中繼資料。 `Nodetool` 是 Apache Cassandra 分佈中提供的管理工具，可讓您深入了解 Cassandra 程序的狀態並傳回資料表中繼資料。您可以使用 `nodetool`來取樣資料表大小的中繼資料，並使用 來推斷 Amazon Keyspaces 中的資料表大小。 要使用的命令是 `nodetool tablestats`。Tablestats 會傳回資料表的大小和壓縮比。資料表的大小會儲存為資料表`tablelivespace`的 ，您可以將其除以 `compression ratio`。然後，將此大小值乘以節點數量。最後除以複寫係數 （通常是三個）。 這是計算的完整公式，您可以用來評估資料表大小。 ``` ((tablelivespace / compression ratio) * (total number of nodes))/ (replication factor) ``` 假設您的 Cassandra 叢集有 12 個節點。執行 `nodetool tablestats`命令會傳回 `tablelivespace` 200 GB 的 和 0.5 `compression ratio`的 。金鑰空間的複寫係數為 3。 這是此範例的計算方式。 ``` (200 GB / 0.5) * (12 nodes)/ (replication factor of 3) = 4,800 GB / 3 = 1,600 GB is the table size estimate for Amazon Keyspaces ``` 1. 擷取讀取和寫入次數 若要判斷 Amazon Keyspaces 資料表的容量和擴展需求，請在遷移之前擷取 Cassandra 資料表的讀取和寫入請求率。 Amazon Keyspaces 是無伺服器，您只需為使用量付費。一般而言，Amazon Keyspaces 中的讀取/寫入輸送量價格取決於請求的數量和大小。 Amazon Keyspaces 有兩種容量模式： + [隨需](ReadWriteCapacityMode.OnDemand.md) – 這是一個靈活的計費選項，能夠每秒處理數千個請求，而無需進行容量規劃。它提供讀取和寫入請求pay-per-request定價，因此您只需支付使用量的費用。 + [佈建](ReadWriteCapacityMode.Provisioned.md) – 如果您選擇佈建輸送量容量模式，您可以指定應用程式所需的每秒讀取和寫入次數。這可協助您管理 Amazon Keyspaces 用量，以維持或低於定義的請求率，以維持可預測性。 佈建模式提供[自動擴展](autoscaling.md)功能，可自動調整佈建速率以擴展或縮減規模，以提升營運效率。如需無伺服器資源管理的詳細資訊，請參閱 [在 Amazon Keyspaces 中管理無伺服器資源 （適用於 Apache Cassandra)](serverless_resource_management.md)。 由於您在 Amazon Keyspaces 中分別佈建讀取和寫入輸送量容量，因此您需要獨立測量現有資料表中讀取和寫入的請求率。 若要從現有的 Cassandra 叢集收集最準確的使用率指標，請針對在單一資料中心所有節點上彙總的資料表，擷取長時間內協調器層級讀取和寫入操作的平均每秒請求數 (RPS)。 擷取至少數週內的平均 RPS 會擷取流量模式中的尖峰和山谷，如下圖所示。 ![\[顯示兩週內每天每秒請求平均速率的圖表。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/migration/migration-rps.png) 您有兩個選項可判斷 Cassandra 資料表的讀取和寫入請求率。 + 使用現有的 Cassandra 監控 您可以使用下表所示的指標來觀察讀取和寫入請求。請注意，指標名稱可能會根據您使用的監控工具而變更。 **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/migrating-cassandra.html) + 使用 `nodetool` 使用 `nodetool tablestats`和 從資料表`nodetool info`擷取平均讀取和寫入操作。 會`tablestats`傳回節點啟動後的總讀取和寫入計數。 會以秒為單位`nodetool info`提供節點的執行時間。 若要接收讀取和寫入的每秒平均值，請將讀取和寫入計數除以節點正常執行時間，以秒為單位。然後，對於讀取，您將除以一致性層級廣告，對於寫入，您將除以複寫係數。這些計算會以下列公式表示。 每秒平均讀取的公式： ``` ((number of reads * number of nodes in cluster) / read consistency quorum (2)) / uptime ``` 每秒平均寫入的公式： ``` ((number of writes * number of nodes in cluster) / replication factor of 3) / uptime ``` 假設我們有 12 個節點叢集，已持續運作 4 週。 會`nodetool info`傳回 2，419，200 秒的正常運作時間，並`nodetool tablestats`傳回 10 億筆寫入和 20 億筆讀取。此範例將導致以下計算。 ``` ((2 billion reads * 12 in cluster) / read consistency quorum (2)) / 2,419,200 seconds = 12 billion reads / 2,419,200 seconds = 4,960 read request per second ((1 billion writes * 12 in cluster) / replication factor of 3) / 2,419,200 seconds = 4 billion writes / 2,419,200 seconds = 1,653 write request per second ``` 1. 判斷資料表的容量使用率 若要估計平均容量使用率，請從平均請求率和 Cassandra 來源資料表的平均資料列大小開始。 Amazon Keyspaces 使用*讀取容量單位* RCUs) 和*寫入容量單位* WCUs) 來測量資料表讀取和寫入的佈建輸送量容量。在此預估中，我們會使用這些單位來計算遷移後新 Amazon Keyspaces 資料表的讀取和寫入容量需求。 本主題稍後將討論佈建容量模式和隨需容量模式之間的選擇如何影響帳單。但是在此範例中，對於容量使用率的預估，我們假設資料表處於佈建模式。 + **讀取** – 一個 RCU 代表最大 4 KB 的資料列一個`LOCAL_QUORUM`讀取請求或兩個`LOCAL_ONE`讀取請求。如果您需要讀取大於 4 KB 的資料列，則讀取操作會使用其他 RCUs。所需的 RCUs 總數取決於資料列大小，以及您是否要使用或`LOCAL_QUORUM``LOCAL_ONE`讀取一致性。 例如，讀取 8 KB 資料列需要 2 個使用`LOCAL_QUORUM`讀取一致性RCUs，如果您選擇`LOCAL_ONE`讀取一致性，則需要 1 個 RCU。 + **寫入** – 一個 WCU 代表大小上限為 1 KB 的資料列一個寫入。所有寫入都使用`LOCAL_QUORUM`一致性，而且使用輕量型交易 (LWTs) 無需額外付費。 所需的 WCUs 總數取決於資料列大小。如果您需要寫入大於 1 KB 的資料列，則寫入操作會使用其他 WCUs。例如，如果您的資料列大小為 2 KB，則需要 2 WCUs 來執行一個寫入請求。 下列公式可用來預估所需的 RCUs 和 WCUs。 + **RCUs中的讀取容量**可以透過將每秒讀取數乘以每個讀取的讀取資料列數乘以平均資料列大小除以 4KB 並四捨五入至最接近的整數來判斷。 + **WCUs中的寫入容量**可以透過將請求數量乘以平均資料列大小除以 1KB 並四捨五入至最接近的整數來決定。 這在下列公式中表示。 ``` Read requests per second * ROUNDUP((Average Row Size)/4096 per unit) = RCUs per second Write requests per second * ROUNDUP(Average Row Size/1024 per unit) = WCUs per second ``` 例如，如果您在 Cassandra 資料表上執行的資料列大小為 2.5KB 的 4，960 個讀取請求，則需要 Amazon Keyspaces 中的 4，960 RCUs。如果您目前在 Cassandra 資料表上執行每秒 1，653 個寫入請求，且資料列大小為 2.5KB，則 Amazon Keyspaces 中需要每秒 4，959 個 WCUs。 此範例以下列公式表示。 ``` 4,960 read requests per second * ROUNDUP( 2.5KB /4KB bytes per unit) = 4,960 read requests per second * 1 RCU = 4,960 RCUs 1,653 write requests per second * ROUNDUP(2.5KB/1KB per unit) = 1,653 requests per second * 3 WCUs = 4,959 WCUs ``` 使用 `eventual consistency`可讓您在每個讀取請求上儲存高達輸送量容量的一半。每個最終一致讀取最多可耗用 8KB。您可以計算最終一致性讀取，方法是將先前的計算乘以 0.5，如下列公式所示。 ``` 4,960 read requests per second * ROUNDUP( 2.5KB /4KB per unit) * .5 = 2,480 read request per second * 1 RCU = 2,480 RCUs ``` 1. 計算 Amazon Keyspaces 的每月定價預估 若要根據讀取/寫入容量輸送量預估資料表的每月帳單，您可以使用不同的公式計算隨需和佈建模式的定價，並比較資料表的選項。 **佈建模式** – 讀取和寫入容量消耗會根據每秒容量單位的每小時費率計費。首先，將該速率除以 0.7，表示預設自動擴展目標使用率為 70%。然後乘以 30 個日曆天、每天 24 小時，以及區域費率定價。 此計算摘要於下列公式中。 ``` (read capacity per second / .7) * 24 hours * 30 days * regional rate (write capacity per second / .7) * 24 hours * 30 days * regional rate ``` **隨需模式** – 讀取和寫入容量是以每個請求速率計費。首先，將請求率乘以 30 個日曆天和每天 24 小時。然後除以一百萬個請求單位。最後，將 乘以區域費率。 此計算摘要於下列公式中。 ``` ((read capacity per second * 30 * 24 * 60 * 60) / 1 Million read request units) * regional rate ((write capacity per second * 30 * 24 * 60 * 60) / 1 Million write request units) * regional rate ``` ## 選擇遷移策略 從 Apache Cassandra 遷移至 Amazon Keyspaces 時，您可以選擇下列遷移策略： + **線上** – 這是使用雙寫入開始同時將新資料寫入 Amazon Keyspaces 和 Cassandra 叢集的即時遷移。對於在遷移期間需要零停機時間並在寫入一致性後讀取的應用程式，建議使用此遷移類型。 如需如何規劃和實作線上遷移策略的詳細資訊，請參閱 [線上遷移至 Amazon Keyspaces：策略和最佳實務](migrating-online.md)。 + **離線** – 此遷移技術涉及在停機時間期間將資料集從 Cassandra 複製到 Amazon Keyspaces。離線遷移可以簡化遷移程序，因為它不需要變更您的應用程式，或在歷史資料和新寫入之間解決衝突。 如需如何規劃離線遷移的詳細資訊，請參閱 [離線遷移程序：Apache Cassandra 到 Amazon Keyspaces](migrating-offline.md)。 + **混合** – 此遷移技術允許近乎即時地將變更複寫至 Amazon Keyspaces，但在寫入一致性後無需讀取。 如需如何規劃混合遷移的詳細資訊，請參閱 [使用混合遷移解決方案：Apache Cassandra 到 Amazon Keyspaces](migrating-hybrid.md)。 檢閱本主題中討論的遷移技術和最佳實務後，您可以在決策樹中放置可用的選項，以根據您的需求和可用的資源設計遷移策略。 # 線上遷移至 Amazon Keyspaces：策略和最佳實務 如果您需要在從 Apache Cassandra 遷移至 Amazon Keyspaces 期間維持應用程式的可用性，您可以實作本主題討論的關鍵元件，以準備自訂線上遷移策略。透過遵循線上遷移的這些最佳實務，您可以確保在整個遷移過程中維持應用程式可用性和read-after-write一致性，將對使用者的影響降至最低。 設計從 Apache Cassandra 到 Amazon Keyspaces 的線上遷移策略時，您需要考慮下列關鍵步驟。 1. **寫入新資料** + **Amazon Keyspaces 遷移的 ZDM Dual Write Proxy** – 使用 [Github](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) 上提供的 ZDM Dual Write Proxy，從 Apache Cassandra 到 Amazon Keyspaces 執行零停機時間遷移。ZDM Proxy 執行雙寫入，無需重構現有應用程式，並執行雙讀取以進行查詢驗證。 + 應用程式雙寫入：您可以使用現有的 Cassandra 用戶端程式庫和驅動程式，在應用程式中實作雙寫入。指定一個資料庫做為領導者，另一個資料庫做為跟隨者。對跟隨者資料庫的寫入失敗會記錄在[無效字母佇列 (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) 中進行分析。 + 訊息層雙寫入：或者，您可以設定現有的訊息平台，使用其他取用者將寫入傳送至 Cassandra 和 Amazon Keyspaces。這會在兩個資料庫之間建立最終一致的檢視。 1. **遷移歷史資料** + 複製歷史資料：您可以使用 AWS Glue或自訂擷取、轉換和載入 (ETL) 指令碼，將歷史資料從 Cassandra 遷移到 Amazon Keyspaces。使用輕量型交易或時間戳記等技術來處理雙寫入和大量載入之間的衝突解決。 + 使用Time-To-Live(TTL)：對於較短的資料保留期間，您可以在 Cassandra 和 Amazon Keyspaces 中使用 TTL，以避免上傳不必要的歷史資料。隨著 Cassandra 中的舊資料過期，並透過雙寫入寫入新資料，Amazon Keyspaces 最終會追上進度。 1. **驗證資料** + 雙重讀取：實作來自 Cassandra （主要） 和 Amazon Keyspaces （次要） 資料庫的雙重讀取，以非同步方式比較結果。差異會記錄或傳送至 DLQ。 + 範例讀取：使用 Λ 函數定期取樣和比較兩個系統的資料，將任何差異記錄到 DLQ。 1. **遷移應用程式** + 藍綠策略：切換您的應用程式，在單一步驟中將 Amazon Keyspaces 視為主要資料存放區，並將 Cassandra 視為次要資料存放區。監控效能，並在發生問題時轉返。 + Canary 部署：先逐步將遷移推展到一部分的使用者，逐步增加 Amazon Keyspaces 作為主要使用者的流量，直到完全遷移為止。 1. **停用 Cassandra** 一旦應用程式完全遷移至 Amazon Keyspaces 並驗證資料一致性，您就可以根據資料保留政策計劃停用 Cassandra 叢集。 透過利用這些元件規劃線上遷移策略，您可以順暢地轉換到全受管 Amazon Keyspaces 服務，並將停機時間或中斷降至最低。以下各節會更詳細地介紹每個元件。 **Topics** + [在線上遷移期間撰寫新資料](migration-online-dw.md) + [在線上遷移期間上傳歷史資料](migration-online-historical.md) + [驗證線上遷移期間的資料一致性](migration-online-validation.md) + [在線上遷移期間遷移應用程式](migration-online-app-migration.md) + [線上遷移後停用 Cassandra](migration-online-decommission.md) # 在線上遷移期間撰寫新資料 線上遷移計畫的第一步是確保應用程式寫入的任何新資料都存放在兩個資料庫、您現有的 Cassandra 叢集和 Amazon Keyspaces 中。目標是跨兩個資料存放區提供一致的檢視。您可以將所有新的寫入套用至兩個資料庫來執行此操作。若要實作雙寫入，請考慮下列三個選項之一。 + **ZDM Dual Write Proxy for Amazon Keyspaces Migration** – 使用 [Github](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) 上提供的 ZDM Proxy for Amazon Keyspaces，您可以將 Apache Cassandra 工作負載遷移至 Amazon Keyspaces，而不會造成應用程式停機。此增強型解決方案實作AWS最佳實務，並擴展官方 ZDM Proxy 功能。 + 在 Apache Cassandra 和 Amazon Keyspaces 之間執行線上遷移。 + 在不重構應用程式的情況下，同時將資料寫入來源和目標資料表。 + 透過雙讀取操作驗證查詢。 解決方案提供下列增強功能，以使用 AWS和 Amazon Keyspaces。 + **容器部署** – 使用來自 Amazon Elastic Container Registry (Amazon ECR) 的預先設定 Docker 映像進行 VPC 可存取的部署。 + **基礎設施即程式碼** – 使用 AWS CloudFormation範本部署以自動設定AWS Fargate。 + **Amazon Keyspaces 相容性** – 使用 Amazon Keyspaces 的自訂調整來存取系統資料表。 解決方案透過 Fargate 在 Amazon ECS 上執行，根據您的工作負載需求提供無伺服器可擴展性。網路負載平衡器會將傳入的應用程式流量分散到多個 Amazon ECS 任務，以獲得高可用性。 ![\[實作 ZDM 雙寫入代理，將資料從 Apache Cassandra 遷移至 Amazon Keyspaces。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/migration/online-migration-zdm.png) + **應用程式雙重寫入** – 您可以利用現有的 Cassandra 用戶端程式庫和驅動程式，在應用程式程式碼變更最少的情況下實作雙重寫入。您可以在現有應用程式中實作雙寫入，或在架構中建立新的 layer 來處理雙寫入。如需詳細資訊，以及顯示如何在現有應用程式中實作雙重寫入的客戶案例研究，請參閱 [Cassandra 遷移案例研究](https://aws.amazon.com/solutions/case-studies/intuit-apache-migration-case-study/)。 實作雙重寫入時，您可以將一個資料庫指定為領導者，將另一個資料庫指定為跟隨者。這可讓您繼續寫入原始來源或領導資料庫，而不會讓後續的寫入失敗，或目的地資料庫中斷應用程式的關鍵路徑。 您可以使用 Amazon Simple Queue Service 在[無效字母佇列 (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) 中記錄失敗的寫入，而不是重試失敗的寫入至追隨者。DLQ 可讓您分析對追隨者的失敗寫入，並判斷為什麼在目的地資料庫中處理未成功。 如需更複雜的雙寫入實作，您可以遵循使用 [saga 模式](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/saga.html)設計一系列本機交易的AWS最佳實務。saga 模式可確保如果交易失敗，saga 會執行補償性交易，以還原先前交易所做的資料庫變更。 使用雙寫入進行線上遷移時，您可以依照 saga 模式設定雙寫入，以便每次寫入都是本機交易，以確保異質資料庫之間的原子操作。如需使用建議的 設計模式來設計分散式應用程式的詳細資訊AWS 雲端，請參閱[雲端設計模式、架構和實作](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/introduction)。 ![\[從 Apache Cassandra 遷移至 Amazon Keyspaces 時，在應用程式層實作雙寫入。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/migration/online-migration-dual-writes.png) + **訊息層雙重寫入** – 您可以使用現有的訊息層對 Cassandra 和 Amazon Keyspaces 執行雙重寫入，而不是在應用程式層實作雙重寫入。 若要這樣做，您可以將其他消費者設定為您的簡訊平台，將寫入傳送至這兩個資料存放區。此方法使用訊息層提供簡單的低程式碼策略，在兩個資料庫之間建立兩個最終一致的檢視。 # 在線上遷移期間上傳歷史資料 實作雙重寫入以確保即時將新資料寫入兩個資料存放區後，遷移計劃的下一個步驟是評估您需要多少歷史資料才能從 Cassandra 複製或大量上傳至 Amazon Keyspaces。這可確保在您遷移應用程式之前，新資料和歷史資料都可以在新的 Amazon Keyspaces 資料庫中使用。 根據您的資料保留需求，例如，您需要根據組織政策保留多少歷史資料，您可以考慮以下兩個選項之一。 + **大量上傳歷史資料** – 歷史資料從現有 Cassandra 部署遷移到 Amazon Keyspaces 可以透過各種技術實現，例如使用 AWS Glue或自訂指令碼來擷取、轉換和載入 (ETL) 資料。如需使用 AWS Glue上傳歷史資料的詳細資訊，請參閱 [離線遷移程序：Apache Cassandra 到 Amazon Keyspaces](migrating-offline.md)。 規劃大量上傳歷史資料時，您需要考慮如何解決新寫入嘗試更新上傳過程中相同資料時可能發生的衝突。大量上傳預期最終會一致，這表示資料最終將到達所有節點。 如果因為新的寫入而同時發生相同資料的更新，您希望確保不會被歷史資料上傳覆寫。為了確保即使在大量匯入期間仍能保留資料的最新更新，您必須將衝突解決方法新增至大量上傳指令碼或應用程式邏輯中，以進行雙重寫入。 例如，您可以使用 [輕量型交易](functional-differences.md#functional-differences.light-transactions)(LWT) 來比較和設定操作。若要這樣做，您可以將代表修改或狀態時間的額外欄位新增至資料模型。 此外，Amazon Keyspaces 支援 Cassandra `WRITETIME`時間戳記函數。您可以使用 Amazon Keyspaces 用戶端時間戳記來保留來源資料庫時間戳記，並實作last-writer-wins衝突解決方案。如需詳細資訊，請參閱[Amazon Keyspaces 中的用戶端時間戳記](client-side-timestamps.md)。 + **使用Time-to-Live(TTL)** – 對於少於 30、60 或 90 天的資料保留期，您可以在遷移期間在 Cassandra 和 Amazon Keyspaces 中使用 TTL，以避免將不必要的歷史資料上傳到 Amazon Keyspaces。TTL 可讓您設定一段時間，之後資料會自動從資料庫移除。 在遷移階段，您可以設定 TTL 設定，讓歷史資料在舊系統 (Cassandra) 中自動過期，同時僅使用雙寫入方法將新寫入套用至 Amazon Keyspaces。隨著時間的推移，使用舊資料持續在 Cassandra 叢集中過期，並使用雙寫入方法寫入的新資料，Amazon Keyspaces 會自動追上 ，以包含與 Cassandra 相同的資料。 這種方法可以大幅減少要遷移的資料量，進而產生更有效率且簡化的遷移程序。您可以在處理具有不同資料保留需求的大型資料集時考慮此方法。如需 TTL 的詳細資訊，請參閱 [使用 Amazon Keyspaces 的存留時間 (TTL) 過期資料 （適用於 Apache Cassandra)](TTL.md)。 請考慮下列使用 TTL 資料過期從 Cassandra 遷移至 Amazon Keyspaces 的範例。在此範例中，我們將兩個資料庫的 TTL 設定為 60 天，並顯示遷移程序在 90 天期間如何進行。在此期間，兩個資料庫都會使用雙寫入方法來接收相同的新寫入資料。我們將查看遷移的三個不同階段，每個階段為期 30 天。 遷移程序在每個階段的運作方式會顯示在下列影像中。 ![\[從 Apache Cassandra 遷移至 Amazon Keyspaces 時，使用 TTL 使歷史資料過期。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/migration/online-migration-TTL.png) 1. 在前 30 天之後，Cassandra 叢集和 Amazon Keyspaces 一直收到新的寫入。Cassandra 叢集也包含尚未達到 60 天保留的歷史資料，由叢集中 50% 的資料組成。 超過 60 天的資料會在 Cassandra 叢集中使用 TTL 自動刪除。此時，Amazon Keyspaces 包含存放在 Cassandra 叢集中的 50% 資料，由新寫入減去歷史資料組成。 1. 60 天後，Cassandra 叢集和 Amazon Keyspaces 都包含過去 60 天內寫入的相同資料。 1. 在 90 天內，Cassandra 和 Amazon Keyspaces 都包含相同的資料，並以相同的速率過期資料。 此範例說明如何使用過期日期設定為 60 天的 TTL 來避免上傳歷史資料的步驟。 # 驗證線上遷移期間的資料一致性 線上遷移程序的下一個步驟是資料驗證。雙重寫入正在將新資料新增至 Amazon Keyspaces 資料庫，而且您已完成使用大量上傳或資料過期搭配 TTL 遷移歷史資料。 現在，您可以使用驗證階段來確認兩個資料存放區實際上都包含相同的資料，並傳回相同的讀取結果。您可以選擇以下兩個選項之一，以驗證兩個資料庫都包含相同的資料。 + **雙重讀取** – 若要驗證來源和目的地資料庫是否包含相同的一組新寫入和歷史資料，您可以實作雙重讀取。若要這樣做，您會從主要 Cassandra 和次要 Amazon Keyspaces 資料庫讀取，類似於雙重寫入方法，並以非同步方式比較結果。 來自主要資料庫的結果會傳回給用戶端，而來自次要資料庫的結果會用來驗證主要結果集。找到的差異可以記錄或傳送至[無效字母佇列 (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) 以供日後調校。 在下圖中，應用程式正在從主要資料存放區 Cassandra 執行同步讀取），並從次要資料存放區 Amazon Keyspaces 執行非同步讀取。 ![\[在從 Apache Cassandra 線上遷移至 Amazon Keyspaces 期間，使用雙重讀取來驗證資料一致性。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/migration/online-migration-dual-reads.png) + **範例讀取** – 不需要變更應用程式程式碼的替代解決方案是使用 AWS Lambda函數，定期並隨機從來源 Cassandra 叢集和目的地 Amazon Keyspaces 資料庫取樣資料。 這些 Lambda 函數可設定為定期執行。Lambda 函數會從來源和目的地系統擷取資料的隨機子集，然後執行取樣資料的比較。兩個資料集之間的任何差異或不相符都可以記錄並傳送到專用[無效字母佇列 (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) 以供日後調校。 下表說明此程序。 ![\[使用範例讀取來驗證從 Apache Cassandra 到 Amazon Keyspaces 的 和線上遷移期間的資料一致性。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/migration/online-migration-sample-reads.png) # 在線上遷移期間遷移應用程式 在線上遷移的第四階段中，您要遷移應用程式，並轉換為 Amazon Keyspaces 做為主要資料存放區。這表示您將應用程式切換為直接從 Amazon Keyspaces 讀取和寫入。為了確保對使用者的干擾降到最低，這應該是妥善規劃和協調的程序。 提供兩種不同的應用程式遷移建議解決方案：藍色綠色切入策略和金絲雀切入策略。下列各節會更詳細地概述這些策略。 + **藍色綠色策略** – 使用此方法，您可以切換應用程式，將 Amazon Keyspaces 視為主要資料存放區，並在單一步驟中將 Cassandra 視為次要資料存放區。您可以使用AWS AppConfig功能旗標來控制整個應用程式執行個體中主要和次要資料存放區的選擇。如需特徵標記的詳細資訊，請參閱在 [中建立特徵標記組態描述AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-creating-configuration-and-profile-feature-flags.html)檔。 讓 Amazon Keyspaces 成為主要資料存放區後，您可以監控應用程式的行為和效能，確保 Amazon Keyspaces 符合您的需求，且遷移成功。 例如，如果您為應用程式實作雙讀取，在應用程式遷移階段，您將主要讀取從 Cassandra 轉換為 Amazon Keyspaces，次要讀取從 Amazon Keyspaces 轉換為 Cassandra。轉換後，您可以繼續監控和比較[資料驗證](migration-online-validation.md)一節中所述的結果，以確保在停用 Cassandra 之前兩個資料庫之間的一致性。 如果您偵測到任何問題，您可以透過還原至 Cassandra 做為主要資料存放區，快速復原至先前的狀態。只有在 Amazon Keyspaces 符合您作為主要資料存放區的所有需求時，您才能繼續遷移的停用階段。 ![\[使用藍色綠色策略，將應用程式從 Apache Cassandra 遷移至 Amazon Keyspaces。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/migration/online-migration-switch.png) + **Canary 策略** – 在此方法中，您會逐步將遷移推展到使用者或流量的子集。最初，您應用程式流量的一小部分，例如 5% 的所有流量會使用 Amazon Keyspaces 做為主要資料存放區路由至版本，而其餘流量則會繼續使用 Cassandra 做為主要資料存放區。 這可讓您使用實際流量徹底測試遷移的版本，並監控其效能、穩定性和調查潛在問題。如果您未偵測到任何問題，您可以逐步增加路由到 Amazon Keyspaces 的流量百分比，直到它成為所有使用者和流量的主要資料存放區為止。 此階段推展可將廣泛服務中斷的風險降至最低，並允許更受控制的遷移程序。如果在 Canary 部署期間發生任何重大問題，您可以使用 Cassandra 作為受影響流量區段的主要資料存放區，快速復原至先前的版本。只有在您驗證 Amazon Keyspaces 可如預期處理 100% 的使用者和流量之後，您才能繼續遷移的解除委任階段。 下圖說明 Canary 策略的個別步驟。 ![\[使用 Canary 策略將應用程式從 Apache Cassandra 遷移至 Amazon Keyspaces。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/migration/online-migration-canary.png) # 線上遷移後停用 Cassandra 應用程式遷移完成後，您的應用程式會在 Amazon Keyspaces 上完全執行，而且您已驗證一段時間的資料一致性，您可以計劃停用 Cassandra 叢集。在此階段，您可以評估 Cassandra 叢集中剩餘的資料是否需要封存或可以刪除。這取決於您組織的資料處理和保留政策。 透過遵循此策略，並在規劃從 Cassandra 到 Amazon Keyspaces 的線上遷移時考慮本主題中描述的建議最佳實務，您可以確保無縫轉換至 Amazon Keyspaces，同時保持應用程式的read-after-write一致性和可用性。 從 Apache Cassandra 遷移到 Amazon Keyspaces 可以提供許多好處，包括降低營運開銷、自動擴展、改善安全性，以及協助您實現合規目標的架構。透過規劃具有雙重寫入、歷史資料上傳、資料驗證和漸進推展的線上遷移策略，您可以確保順暢的轉換，並將對應用程式及其使用者的干擾降至最低。 實作本主題中討論的線上遷移策略，可讓您驗證遷移結果、識別和解決任何問題，最終停用現有的 Cassandra 部署，以享有全受管 Amazon Keyspaces 服務。 # 離線遷移程序：Apache Cassandra 到 Amazon Keyspaces 當您可以負擔執行遷移的停機時間時，離線遷移是合適的。企業之間通常會有修補、大型版本或停機時間的維護時段，以進行硬體升級或主要升級。離線遷移可以使用此視窗來複製資料，並將應用程式流量從 Apache Cassandra 切換到 Amazon Keyspaces。 離線遷移可減少對應用程式的修改，因為它不需要同時與 Cassandra 和 Amazon Keyspaces 通訊。此外，在資料流程暫停的情況下，可以在不維護變動的情況下複製確切狀態。 在此範例中，我們使用 Amazon Simple Storage Service (Amazon S3) 做為離線遷移期間資料的預備區域，將停機時間降至最低。您可以使用 Spark Cassandra 連接器 和 ，將您以 Parquet 格式存放在 Amazon S3 中的資料自動匯入 Amazon Keyspaces 資料表AWS Glue。下一節將展示程序的高階概觀。您可以在 [Github](https://github.com/aws-samples/amazon-keyspaces-examples/tree/main/scala/datastax-v4/aws-glue) 上找到此程序的程式碼範例。 使用 Amazon S3 從 Apache Cassandra 到 Amazon Keyspaces 的離線遷移程序，AWS Glue需要下列AWS Glue任務。 1. 擷取和轉換 CQL 資料並將其存放在 Amazon S3 儲存貯體的 ETL 任務。 1. 將資料從儲存貯體匯入 Amazon Keyspaces 的第二個任務。 1. 匯入增量資料的第三個任務。 **如何在 Amazon Virtual Private Cloud 中從在 Amazon EC2 上執行的 Cassandra 執行離線遷移至 Amazon Keyspaces Amazon Virtual Private Cloud** 1. 首先，使用 從 Cassandra 以 Parquet 格式AWS Glue匯出資料表資料，並將其儲存至 Amazon S3 儲存貯體。您需要使用連接至執行 Cassandra 之 Amazon EC2 執行個體所在 VPC 的AWS Glue連接器來執行AWS Glue任務。然後，使用 Amazon S3 私有端點，您可以將資料儲存到 Amazon S3 儲存貯體。 下圖說明這些步驟。 ![\[使用 從 VPC 中執行的 Amazon EC2 將 Apache Cassandra 資料遷移至 Amazon S3 儲存貯體AWS Glue。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/migration/migration-export.png) 1. 隨機播放 Amazon S3 儲存貯體中的資料，以改善資料隨機化。平均匯入的資料允許目標資料表中的更多分散式流量。 從具有大型分割區 （超過 1000 個資料列的分割區） 的 Cassandra 匯出資料時需要此步驟，以避免將資料插入 Amazon Keyspaces 時出現熱鍵模式。熱鍵問題會在 Amazon Keyspaces `WriteThrottleEvents`中造成，並導致載入時間增加。 ![\[AWS Glue任務會從 Amazon S3 儲存貯體隨機播放資料，並將其傳回至另一個 Amazon S3 儲存貯體。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/migration/migration-shuffle.png) 1. 使用另一個AWS Glue任務將資料從 Amazon S3 儲存貯體匯入 Amazon Keyspaces。Amazon S3 儲存貯體中的隨機資料會以 Parquet 格式儲存。 ![\[AWS Glue匯入任務會從 Amazon S3 儲存貯體取得隨機資料，並將其移至 Amazon Keyspaces 資料表。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/migration/migration-import.png) 如需離線遷移程序的詳細資訊，請參閱研討會 [ Amazon Keyspaces withAWS Glue](https://catalog.workshops.aws/unlocking-amazonkeyspaces/en-US/keyspaces-with-glue) # 使用混合遷移解決方案：Apache Cassandra 到 Amazon Keyspaces 下列遷移解決方案可視為線上和離線遷移之間的混合。透過這種混合方法，資料會以近乎即時的方式寫入目的地資料庫，而不會在寫入一致性後提供讀取。這表示新寫入的資料不會立即可用，且預期會發生延遲。如果您需要寫入一致性後的讀取，請參閱 [線上遷移至 Amazon Keyspaces：策略和最佳實務](migrating-online.md)。 若要從 Apache Cassandra 近乎即時地遷移至 Amazon Keyspaces，您可以選擇兩種可用的方法。 + **CQLReplicator** – （建議） CQLReplicator 是 [Github](https://github.com/aws-samples/cql-replicator) 上提供的開放原始碼公用程式，可協助您近乎即時地將資料從 Apache Cassandra 遷移至 Amazon Keyspaces。 為了判斷要傳播到目的地資料庫的寫入和更新，CQLReplicator 會掃描 Apache Cassandra 字符範圍，並使用 AWS Glue任務來移除重複的事件，並直接將寫入和更新套用至 Amazon Keyspaces。 + **變更資料擷取 (CDC)** – 如果您熟悉 Cassandra CDC，則透過將遞交日誌複製到單獨的 CDC 目錄來允許擷取變更的 Apache Cassandra 內建 CDC 功能是實作混合遷移的另一個選項。 您可以將資料變更複寫至 Amazon Keyspaces，讓 CDC 成為資料遷移案例的替代選項。 如果您在寫入一致性後不需要讀取，則可以使用 CQLReplicator 或 CDC 管道，根據您的偏好和對工具的熟悉程度，將資料從 Apache Cassandra 遷移到 Amazon KeyspacesAWS 服務。使用這些方法來近乎即時地遷移資料，可視為遷移的混合方法，提供線上遷移的替代方案。 此策略被視為混合式方法，因為除了本主題中概述的選項之外，您還必須實作線上遷移進度的一些步驟，例如歷史資料複製和[線上遷移主題中討論的應用程式遷移](migrating-online.md)策略。 以下章節會詳細說明混合遷移選項。 **Topics** + [使用 CQLReplicator 遷移資料](migration-hybrid-cql-rep.md) + [使用變更資料擷取 (CDC) 遷移資料](migration-hybrid-cdc.md) # 使用 CQLReplicator 遷移資料 使用 [CQLReplicator](https://github.com/aws-samples/cql-replicator)，您可以使用 CQL 查詢智慧掃描 Cassandra 字符環，近乎即時地從 Apache Cassandra 讀取資料。CQLReplicator 不使用 Cassandra CDC，而是實作快取策略，以減少完整掃描的效能懲罰。 為了減少目的地的寫入次數，CQLReplicator 會自動移除重複的複寫事件。使用 CQLReplicator，您可以調整從來源資料庫到目的地資料庫的變更複寫，以便近乎即時地將資料從 Apache Cassandra 遷移到 Amazon Keyspaces。 下圖顯示 CQLReplicator 任務使用的一般架構AWS Glue。 1. 若要允許存取在私有 VPC 中執行的 Apache Cassandra，請設定與AWS Glue連線類型 **Network** 的連線。 1. 若要使用 CQLReplicator 任務移除重複項目並啟用金鑰快取，請設定 Amazon Simple Storage Service (Amazon S3)。 1. CQLReplicator 任務會將已驗證的來源資料庫直接變更為 Amazon Keyspaces。 ![\[使用 CQLReplicator 將資料從 Apache Cassandra 遷移至 Amazon Keyspaces。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/migration/hybrid-migration-CQLRep.png) 如需使用 CQLReplicator 遷移程序的詳細資訊，請參閱下列文章：AWS資料庫部落格[使用 CQLReplicator 將 Cassandra 工作負載遷移至 Amazon Keyspaces](https://aws.amazon.com/blogs/database/migrate-cassandra-workloads-to-amazon-keyspaces-using-cqlreplicator/)，AWS以及[使用 將 Apache Cassandra 工作負載遷移至 Amazon KeyspacesAWS Glue](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-apache-cassandra-workloads-to-amazon-keyspaces-using-aws-glue.html) 的規範指引。 # 使用變更資料擷取 (CDC) 遷移資料 如果您已經熟悉使用 [Debezium](https://debezium.io/) 設定變更資料擷取 (CDC) 管道，您可以使用此選項將資料遷移到 Amazon Keyspaces，作為使用 CQLReplicator 的替代方案。Debezium 是 CDC 的開放原始碼分散式平台，旨在監控資料庫並可靠地擷取資料列層級的變更。 [Apache Cassandra 的 Debezium 連接器](https://debezium.io/documentation/reference/stable/connectors/cassandra.html)會將變更上傳至 Amazon Managed Streaming for Apache Kafka (Amazon MSK)，讓下游消費者可以取用和處理這些變更，進而將資料寫入 Amazon Keyspaces。如需詳細資訊，請參閱[從 Apache Cassandra 到 Amazon Keyspaces 的持續資料遷移指南](https://aws.amazon.com/solutions/guidance/continuous-data-migration-from-apache-cassandra-to-amazon-keyspaces/)。 若要解決任何潛在的資料一致性問題，您可以使用 Amazon MSK 實作程序，其中取用者會將 Cassandra 中的金鑰或分割區與 Amazon Keyspaces 中的金鑰或分割區進行比較。 若要成功實作此解決方案，建議您考慮下列事項。 + 如何剖析 CDC 遞交日誌，例如如何移除重複的事件。 + 如何維護 CDC 目錄，例如如何刪除舊日誌。 + 如何處理 Apache Cassandra 中的部分故障，例如，如果寫入在三個複本中只有一個成功。 + 如何處理資源配置，例如增加執行個體的大小，以考量節點上 CDC 程序的額外 CPU、記憶體、DIK 和 IO 需求。 此模式會將來自 Cassandra 的變更視為「提示」，表示金鑰可能已從先前的狀態變更。若要判斷是否有變更要傳播到目的地資料庫，您必須先使用 `LOCAL_QUORUM`操作從來源 Cassandra 叢集讀取，以接收最新的記錄，然後將其寫入 Amazon Keyspaces。 在範圍刪除或範圍更新的情況下，您可能需要對整個分割區執行比較，以判斷哪些寫入或更新事件需要寫入目的地資料庫。 如果寫入不等冪，您也需要在寫入 Amazon Keyspaces 之前，將寫入與目的地資料庫中已存在的寫入進行比較。 下圖顯示使用 Debezium 和 Amazon MSK 的 CDC 管道典型架構。 ![\[使用變更資料擷取管道，將資料從 Apache Cassandra 遷移至 Amazon Keyspaces。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/migration/hybrid-migration-CDC.png) # 如何選取正確的工具，將資料大量上傳或遷移至 Amazon Keyspaces 在本節中，您可以檢閱可用來大量上傳資料或將資料遷移至 Amazon Keyspaces 的不同工具，並了解如何根據您的需求選取正確的工具。此外，本節提供可用step-by-step教學課程的概觀和使用案例，示範如何將資料匯入 Amazon Keyspaces。 若要檢閱將工作負載從 Apache Cassandra 遷移至 Amazon Keyspaces 的可用策略，請參閱 [建立遷移計畫，以從 Apache Cassandra 遷移至 Amazon Keyspaces](migrating-cassandra.md)。 + **遷移工具** + 透過 Github 上提供的 [Amazon Keyspaces （適用於 Apache Cassandra) 定價計算器](https://aws-samples.github.io/sample-pricing-calculator-for-keyspaces/#cassandra)，您可以根據現有的 Apache Cassandra 工作負載預估 Amazon Keyspaces 的每月成本。輸入來自 Cassandra 節點工具狀態輸出的指標和 Amazon Keyspaces 的預期無伺服器組態，以比較兩個解決方案之間的直接成本。請注意，相較於現有的 Cassandra 部署，此計算器僅著重於 Amazon Keyspaces 的操作成本。它不包括基礎設施維護、營運開銷或 Cassandra 支援成本等總體擁有成本 (TCO) 因素。 + **ZDM Dual Write Proxy for Amazon Keyspaces Migration** – [Github](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) 上提供的 ZDM Dual Write Proxy 支援從 Apache Cassandra 到 Amazon Keyspaces 的零停機時間遷移。 + **CQLReplicator** – CQLReplicator 是 [Github](https://github.com/aws-samples/cql-replicator) 上提供的開放原始碼公用程式，可協助您近乎即時地將資料從 Apache Cassandra 遷移至 Amazon Keyspaces。 如需詳細資訊，請參閱[使用 CQLReplicator 遷移資料](migration-hybrid-cql-rep.md)。 + 若要進一步了解如何使用 Amazon Managed Streaming for Apache Kafka 透過雙寫入實作[線上遷移](migrating-online.md)程序，請參閱[從 Apache Cassandra 到 Amazon Keyspaces 的持續資料遷移指南](https://aws.amazon.com/solutions/guidance/continuous-data-migration-from-apache-cassandra-to-amazon-keyspaces/)。 + 對於大型遷移，請考慮使用擷取、轉換和載入 (ETL) 工具。您可以使用 AWS Glue 快速且有效地執行資料轉換遷移。如需詳細資訊，請參閱[離線遷移程序：Apache Cassandra 到 Amazon Keyspaces](migrating-offline.md)。 + 若要了解如何使用 Apache Cassandra Spark 連接器將資料寫入 Amazon Keyspaces，請參閱 [教學課程：與 Apache Spark 整合以匯入或匯出資料](spark-integrating.md)。 + 使用 cqlsh `COPY FROM`命令快速開始將資料載入 Amazon Keyspaces。cqlsh 隨附於 Apache Cassandra，最適合載入小型資料集或測試資料。如需逐步說明，請參閱 [教學課程：使用 cqlsh 將資料載入 Amazon Keyspaces](bulk-upload.md)。 + 您也可以使用 DataStax Bulk Loader for Apache Cassandra，使用 `dsbulk`命令將資料載入 Amazon Keyspaces。DSBulk 提供比 cqlsh 更強大的匯入功能，可從 [GitHub 儲存庫](https://github.com/datastax/dsbulk)取得。如需逐步說明，請參閱 [教學課程：使用 DSBulk 將資料載入 Amazon Keyspaces](dsbulk-upload.md)。 資料上傳至 Amazon Keyspaces 的一般考量事項 + **將資料上傳細分為較小的元件。** 請考慮以下遷移單位及其在原始資料大小方面的潛在足跡。在一或多個階段上傳較少量的資料，可能有助於簡化遷移。 + **依叢集**：一次遷移所有 Cassandra 資料。此方法對於較小的叢集可能沒問題。 + **依金鑰空間或資料表** – 將您的遷移分成金鑰空間或資料表群組。此方法可協助您根據每個工作負載的需求分階段遷移資料。 + **依資料** – 考慮遷移特定使用者或產品群組的資料，以進一步縮減資料大小。 + **根據簡單性優先上傳哪些資料。** 考慮您是否有可先更輕鬆地遷移的資料，例如，在特定時間不會變更的資料、夜間批次工作的資料、離線時間未使用的資料，或內部應用程式的資料。 **Topics** + [教學課程：使用 cqlsh 將資料載入 Amazon Keyspaces](bulk-upload.md) + [教學課程：使用 DSBulk 將資料載入 Amazon Keyspaces](dsbulk-upload.md) # 教學課程：使用 cqlsh 將資料載入 Amazon Keyspaces 本教學課程將引導您使用 `cqlsh COPY FROM`命令，將資料從 Apache Cassandra 遷移至 Amazon Keyspaces。`cqlsh COPY FROM` 命令有助於快速且輕鬆地將小型資料集上傳至 Amazon Keyspaces，以供學術或測試之用。如需如何遷移生產工作負載的詳細資訊，請參閱 [離線遷移程序：Apache Cassandra 到 Amazon Keyspaces](migrating-offline.md)。在本教學課程中，您將完成下列步驟： 先決條件 – 設定具有登入資料的 AWS 帳戶、建立憑證的 JKS 信任存放區檔案，以及設定 `cqlsh` 以連線至 Amazon Keyspaces。 1. **建立來源 CSV 和目標資料表** – 準備 CSV 檔案做為來源資料，並在 Amazon Keyspaces 中建立目標金鑰空間和資料表。 1. **準備資料** – 隨機化 CSV 檔案中的資料並加以分析，以判斷平均和最大資料列大小。 1. **設定輸送量容量** – 根據資料大小和所需的載入時間計算所需的寫入容量單位 (WCUs)，並設定資料表的佈建容量。 1. **設定 cqlsh 參數** – 決定`cqlsh COPY FROM`參數的最佳值`NUMPROCESSES`，例如 `INGESTRATE`、`MAXBATCHSIZE`、 和 `CHUNKSIZE`，以平均分配工作負載。 1. **執行 `cqlsh COPY FROM`命令 ** – 執行 `cqlsh COPY FROM`命令，將資料從 CSV 檔案上傳至 Amazon Keyspaces 資料表，並監控進度。 故障診斷 – 在資料上傳過程中解決常見問題，例如無效請求、剖析器錯誤、容量錯誤和 cqlsh 錯誤。 **Topics** + [先決條件：使用 上傳資料之前要完成的步驟 `cqlsh COPY FROM`](bulk-upload-prequs.md) + [步驟 1：建立來源 CSV 檔案和目標資料表以進行資料上傳](bulk-upload-source.md) + [步驟 2：準備來源資料以成功上傳資料](bulk-upload-prepare-data.md) + [步驟 3：設定資料表的輸送量容量](bulk-upload-capacity.md) + [步驟 4：設定`cqlsh COPY FROM`設定](bulk-upload-config.md) + [步驟 5：執行 `cqlsh COPY FROM`命令，將資料從 CSV 檔案上傳至目標資料表](bulk-upload-run.md) + [疑難排解](bulk-upload-troubleshooting.md) # 先決條件：使用 上傳資料之前要完成的步驟 `cqlsh COPY FROM` 您必須先完成下列任務，才能開始本教學課程。 1. 如果您尚未這麼做， AWS 帳戶 請依照 中的步驟註冊 [設定 AWS Identity and Access Management](accessing.md#SettingUp.IAM)。 1. 遵循 中的步驟建立服務特定的登入資料[建立服務特定的登入資料，以程式設計方式存取 Amazon Keyspaces](programmatic.credentials.ssc.md)。 1. 設定 Cassandra Query Language Shell (cqlsh) 連線，並依照 中的步驟確認您可以連線至 Amazon Keyspaces[使用 `cqlsh` 連線至 Amazon Keyspaces](programmatic.cqlsh.md)。 # 步驟 1：建立來源 CSV 檔案和目標資料表以進行資料上傳 在本教學課程中，我們使用逗號分隔值 (CSV) 檔案，其名稱`keyspaces_sample_table.csv`為資料遷移的來源檔案。提供的範例檔案包含名稱為 之資料表的幾列資料`book_awards`。 1. 建立來源檔案。您可以選擇下列其中一個選項： + 下載下列封存檔案 [samplemigration.zip](samples/samplemigration.zip) 中包含的範例 CSV 檔案 (`keyspaces_sample_table.csv`)。解壓縮封存，並記下 的路徑`keyspaces_sample_table.csv`。 + 若要使用存放在 Apache Cassandra 資料庫中的自有資料填入 CSV 檔案，您可以使用 `cqlsh``COPY TO`陳述式填入來源 CSV 檔案，如下列範例所示。 ``` cqlsh localhost 9042 -u "username" -p "password" --execute "COPY mykeyspace.mytable TO 'keyspaces_sample_table.csv' WITH HEADER=true"; ``` 請確定您建立的 CSV 檔案符合下列要求： + 第一列包含資料欄名稱。 + 來源 CSV 檔案中的資料欄名稱符合目標資料表中的資料欄名稱。 + 資料以逗號分隔。 + 所有資料值都是有效的 Amazon Keyspaces 資料類型。請參閱 [資料類型](cql.elements.md#cql.data-types)。 1. 在 Amazon Keyspaces 中建立目標金鑰空間和資料表。 1. 使用 連線至 Amazon Keyspaces`cqlsh`，將下列範例中的服務端點、使用者名稱和密碼取代為您自己的值。 ``` cqlsh cassandra.us-east-1.amazonaws.com 9142 -u "111122223333" -p "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" --ssl ``` 1. 建立名稱為 的新金鑰空間`catalog`，如下列範例所示。 ``` CREATE KEYSPACE catalog WITH REPLICATION = {'class': 'SingleRegionStrategy'}; ``` 1. 當新的金鑰空間可用時，請使用下列程式碼來建立目標資料表 `book_awards`。 ``` CREATE TABLE "catalog.book_awards" ( year int, award text, rank int, category text, book_title text, author text, publisher text, PRIMARY KEY ((year, award), category, rank) ); ``` 如果 Apache Cassandra 是原始資料來源，建立具有相符標頭的 Amazon Keyspaces 目標資料表的簡單方法是從來源資料表產生`CREATE TABLE`陳述式，如下列陳述式所示。 ``` cqlsh localhost 9042 -u "username" -p "password" --execute "DESCRIBE TABLE mykeyspace.mytable;" ``` 然後，使用與 Cassandra 來源資料表描述相符的資料欄名稱和資料類型，在 Amazon Keyspaces 中建立目標資料表。 # 步驟 2：準備來源資料以成功上傳資料 準備來源資料以進行有效率的傳輸是兩個步驟。首先，您將資料隨機化。在第二個步驟中，您會分析資料，以判斷適當的`cqlsh`參數值和所需的資料表設定，以確保資料上傳成功。 **隨機化資料** `cqlsh COPY FROM` 命令會以 CSV 檔案中顯示的相同順序讀取和寫入資料。如果您使用 `cqlsh COPY TO`命令來建立來源檔案，資料會以 CSV 中的金鑰排序順序寫入。在內部，Amazon Keyspaces 會使用分割區索引鍵分割資料。雖然 Amazon Keyspaces 具有內建邏輯，可協助負載平衡相同分割區索引鍵的請求，但如果您隨機排列順序，則載入資料會更快且更有效率。這是因為您可以利用 Amazon Keyspaces 寫入不同分割區時發生的內建負載平衡。 若要將寫入平均分散到分割區，您必須隨機化來源檔案中的資料。您可以撰寫應用程式來執行此操作，或使用開放原始碼工具，例如 [Shuf](https://en.wikipedia.org/wiki/Shuf)。Shuf 可在 Linux 發行版本、macOS （透過在 [homebrew](https://brew.sh) 中安裝 coreutils) 和 Windows （透過使用適用於 Linux 的 Windows 子系統 (WSL)) 上免費使用。需要額外的步驟，以防止具有資料欄名稱的標頭列在此步驟中隨機播放。 若要在保留 標頭時隨機化來源檔案，請輸入下列程式碼。 ``` tail -n +2 keyspaces_sample_table.csv | shuf -o keyspace.table.csv && (head -1 keyspaces_sample_table.csv && cat keyspace.table.csv ) > keyspace.table.csv1 && mv keyspace.table.csv1 keyspace.table.csv ``` Shuf 會將資料重寫至名為 的新 CSV 檔案`keyspace.table.csv`。您現在可以刪除`keyspaces_sample_table.csv`檔案 - 您不再需要它。 **分析資料** 透過分析資料來判斷平均和最大資料列大小。 您這樣做的原因如下： + 平均資料列大小有助於預估要傳輸的資料總量。 + 您需要平均資料列大小來佈建資料上傳所需的寫入容量。 + 您可以確保每個資料列的大小小於 1 MB，這是 Amazon Keyspaces 中的資料列大小上限。 **注意** 此配額是指資料列大小，而非分割區大小。與 Apache Cassandra 分割區不同，Amazon Keyspaces 分割區的大小幾乎沒有限制。分割區索引鍵和叢集資料欄需要額外的中繼資料儲存空間，您必須將其新增至資料列的原始大小。如需詳細資訊，請參閱[估計 Amazon Keyspaces 中的資料列大小](calculating-row-size.md)。 下列程式碼使用 [AWK](https://en.wikipedia.org/wiki/AWK) 來分析 CSV 檔案，並列印平均和最大資料列大小。 ``` awk -F, 'BEGIN {samp=10000;max=-1;}{if(NR>1){len=length($0);t+=len;avg=t/NR;max=(len>max ? len : max)}}NR==samp{exit}END{printf("{lines: %d, average: %d bytes, max: %d bytes}\n",NR,avg,max);}' keyspace.table.csv ``` 執行此程式碼會產生下列輸出。 ``` using 10,000 samples: {lines: 10000, avg: 123 bytes, max: 225 bytes} ``` 您可以在本教學課程的下一個步驟中使用平均資料列大小來佈建資料表的寫入容量。 # 步驟 3：設定資料表的輸送量容量 本教學課程說明如何調校 cqlsh，以在設定的時間範圍內載入資料。由於您知道預先執行的讀取和寫入數量，請使用佈建容量模式。完成資料傳輸後，您應該設定資料表的容量模式，以符合應用程式的流量模式。若要進一步了解容量管理，請參閱 [在 Amazon Keyspaces 中管理無伺服器資源 （適用於 Apache Cassandra)](serverless_resource_management.md)。 使用佈建容量模式時，您可以指定要預先佈建至資料表的讀取和寫入容量。寫入容量會以每小時計費，並以寫入容量單位 (WCUs計量。每個 WCU 都有足夠的寫入容量，可支援每秒寫入 1 KB 的資料。當您載入資料時，寫入速率必須低於目標資料表上設定的最大 WCUs（參數：`write_capacity_units`)。 根據預設，您最多可以將 40，000 WCUs 佈建到 資料表，並在您帳戶中所有資料表中佈建 80，000 WCUs。如果您需要額外的容量，您可以在 [ Service Quotas](https://console.aws.amazon.com/servicequotas/home#!/services/cassandra/quotas) 主控台中請求增加配額。如需配額的詳細資訊，請參閱 [Amazon Keyspaces 配額 （適用於 Apache Cassandra)](quotas.md)。 **計算插入所需的 WCUs平均數量** 每秒插入 1 KB 的資料需要 1 個 WCU。如果您的 CSV 檔案有 360，000 個資料列，而且您想要在 1 小時內載入所有資料，則必須每秒寫入 100 個資料列 (360，000 個資料列/60 分鐘/60 秒 = 每秒 100 個資料列）。如果每一列最多有 1 KB 的資料，若要每秒插入 100 列，您必須將 100 WCUs 佈建到您的資料表。如果每個資料列有 1.5 KB 的資料，您需要兩個 WCUs才能每秒插入一個資料列。因此，若要每秒插入 100 個資料列，您必須佈建 200 WCUs。 若要判斷每秒需要插入一列的 WCUs 數量，請將平均資料列大小以位元組為單位除以 1024，然後四捨五入至最接近的整數。 例如，如果平均資料列大小為 3000 位元組，您需要三個 WCUs才能每秒插入一個資料列。 ``` ROUNDUP(3000 / 1024) = ROUNDUP(2.93) = 3 WCUs ``` **計算資料載入時間和容量** 現在您已知道 CSV 檔案中的平均大小和資料列數，您可以計算在指定時間內載入資料所需的 WCUs 數量，以及使用不同的 WCU 設定載入 CSV 檔案中所有資料所需的大約時間。 例如，如果檔案中的每一列都是 1 KB，而 CSV 檔案中有 1，000，000 列，若要在 1 小時內載入資料，您需要在該小時內佈建至少 278 個 WCUs 到您的資料表。 ``` 1,000,000 rows * 1 KBs = 1,000,000 KBs 1,000,000 KBs / 3600 seconds =277.8 KBs / second = 278 WCUs ``` **設定佈建的容量設定** 您可以在建立資料表或使用 `ALTER TABLE` CQL 命令時設定資料表的寫入容量設定。以下是使用 `ALTER TABLE` CQL 陳述式修改資料表佈建容量設定的語法。 ``` ALTER TABLE mykeyspace.mytable WITH custom_properties={'capacity_mode':{'throughput_mode': 'PROVISIONED', 'read_capacity_units': 100, 'write_capacity_units': 278}} ; ``` 如需完整的語言參考，請參閱 [ALTER TABLE](cql.ddl.table.md#cql.ddl.table.alter)。 # 步驟 4：設定`cqlsh COPY FROM`設定 本節概述如何判斷 的參數值`cqlsh COPY FROM`。`cqlsh COPY FROM` 命令會讀取您先前準備的 CSV 檔案，並使用 CQL 將資料插入 Amazon Keyspaces。命令會分割資料列，並在一組工作者之間分配`INSERT`操作。每個工作者都會與 Amazon Keyspaces 建立連線，並沿著此頻道傳送`INSERT`請求。 `cqlsh COPY` 命令沒有內部邏輯，可在其工作者之間平均分配工作。不過，您可以手動設定它，以確保工作均勻分佈。首先檢閱這些金鑰 cqlsh 參數： + **DELIMITER** – 如果您使用逗號以外的分隔符號，您可以設定此參數，預設為逗號。 + **輸入** – `cqlsh COPY FROM`每秒嘗試處理的列數目標。如果取消設定，則預設為 100，000。 + **NUMPROCESSES** – cqlsh 為`COPY FROM`任務建立的子工作者程序數目。此設定的最大值為 16，預設值為 `num_cores - 1`，其中 `num_cores`是執行 cqlsh 之主機上的處理核心數目。 + **MAXBATCHSIZE** – 批次大小決定單一批次中插入目的地資料表的資料列數目上限。如果取消設定，cqlsh 會使用 20 個插入資料列的批次。 + **CHUNKSIZE** – 傳遞給子工作者的工作單位大小。根據預設，它會設定為 5，000。 + **MAXATTEMPTS** – 重試失敗工作者區塊的次數上限。達到嘗試次數上限後，失敗的記錄會寫入新的 CSV 檔案，您可以在調查失敗之後再次執行。 `INGESTRATE` 根據您佈建至目標目的地資料表的 WCUs 數目來設定 。`cqlsh COPY FROM` 命令`INGESTRATE`的 不是限制，而是目標平均值。這表示它可以 （且通常可以） 爆量超過您設定的數字。若要允許爆量，並確保有足夠的容量來處理資料載入請求，請將 `INGESTRATE` 設為資料表寫入容量的 90%。 ``` INGESTRATE = WCUs * .90 ``` 接著，將 `NUMPROCESSES` 參數設定為比系統上的核心數目少一個。若要了解系統的核心數量，您可以執行下列程式碼。 ``` python -c "import multiprocessing; print(multiprocessing.cpu_count())" ``` 在本教學課程中，我們使用下列值。 ``` NUMPROCESSES = 4 ``` 每個程序都會建立工作者，而且每個工作者都會建立與 Amazon Keyspaces 的連線。Amazon Keyspaces 在每個連線上每秒最多可支援 3，000 個 CQL 請求。這表示您必須確保每個工作者每秒處理少於 3，000 個請求。 如同 `INGESTRATE`，工作者通常會爆量超過您設定的數字，不受時鐘秒的限制。因此，若要考慮爆量，請將 cqlsh 參數設定為以每個工作者為目標，每秒處理 2，500 個請求。若要計算分配給工作者的工作量，請使用下列準則。 + `INGESTRATE` 除以 `NUMPROCESSES`。 + 如果 `INGESTRATE` / `NUMPROCESSES` > 2，500，請降低 `INGESTRATE`使此公式成為 true。 ``` INGESTRATE / NUMPROCESSES <= 2,500 ``` 在您設定設定以最佳化上傳我們的範例資料之前，讓我們檢閱`cqlsh`預設設定，並了解使用它們如何影響資料上傳程序。由於 `cqlsh COPY FROM`使用 `CHUNKSIZE`來建立工作區塊 (`INSERT` 陳述式） 以分發給工作者，因此工作不會自動平均分發。有些工作者可能會閒置，視 `INGESTRATE` 設定而定。 若要在工作者之間平均分配工作，並將每個工作者保持在最佳每秒 2，500 個請求速率，您必須變更輸入參數`INGESTRATE`來設定 `MAXBATCHSIZE`、 `CHUNKSIZE`和 。若要在資料載入期間最佳化網路流量使用率，請選擇`MAXBATCHSIZE`接近最大值 30 的值。透過將 `CHUNKSIZE`變更為 100 和 `MAXBATCHSIZE` 25，10，000 個資料列平均分散在四個工作者之間 (10，000 / 2500 = 4)。 下列程式碼範例說明了這一點。 ``` INGESTRATE = 10,000 NUMPROCESSES = 4 CHUNKSIZE = 100 MAXBATCHSIZE. = 25 Work Distribution: Connection 1 / Worker 1 : 2,500 Requests per second Connection 2 / Worker 2 : 2,500 Requests per second Connection 3 / Worker 3 : 2,500 Requests per second Connection 4 / Worker 4 : 2,500 Requests per second ``` 若要摘要，請在設定`cqlsh COPY FROM`參數時使用下列公式： + **INGESTRATE** = write\$1capacity\$1units \$1 .90 + **NUMPROCESSES** = num\$1cores -1 （預設） + **擷取/NUMPROCESSES** = 2，500 （這必須是 true 陳述式。) + **MAXBATCHSIZE** = 30 （預設為 20。 Amazon Keyspaces 接受最多 30 個批次。) + **區塊大小** = （擷取 / NUMPROCESSES) / MAXBATCHSIZE 現在您已計算 `NUMPROCESSES`、 `INGESTRATE`和 `CHUNKSIZE`，您已準備好載入資料。 # 步驟 5：執行 `cqlsh COPY FROM`命令，將資料從 CSV 檔案上傳至目標資料表 若要執行 `cqlsh COPY FROM`命令，請完成下列步驟。 1. 使用 cqlsh 連線至 Amazon Keyspaces。 1. 使用下列程式碼選擇您的金鑰空間。 ``` USE catalog; ``` 1. 將寫入一致性設定為 `LOCAL_QUORUM`。為了確保資料耐久性，Amazon Keyspaces 不允許其他寫入一致性設定。請參閱下列程式碼。 ``` CONSISTENCY LOCAL_QUORUM; ``` 1. 使用以下程式碼範例準備`cqlsh COPY FROM`語法。 ``` COPY book_awards FROM './keyspace.table.csv' WITH HEADER=true AND INGESTRATE=calculated ingestrate AND NUMPROCESSES=calculated numprocess AND MAXBATCHSIZE=20 AND CHUNKSIZE=calculated chunksize; ``` 1. 執行上一個步驟中準備的陳述式。cqlsh 會回傳您已設定的所有設定。 1. 請確定設定符合您的輸入。請參閱以下範例。 ``` Reading options from the command line: {'chunksize': '120', 'header': 'true', 'ingestrate': '36000', 'numprocesses': '15', 'maxbatchsize': '20'} Using 15 child processes ``` 1. 檢閱傳輸的資料列數和目前的平均速率，如下列範例所示。 ``` Processed: 57834 rows; Rate: 6561 rows/s; Avg. rate: 31751 rows/s ``` 1. 當 cqlsh 完成上傳資料時，請檢閱資料載入統計資料的摘要 （讀取、執行時間和略過的資料列數），如下列範例所示。 ``` 15556824 rows imported from 1 files in 8 minutes and 8.321 seconds (0 skipped). ``` 在教學課程的最後一個步驟中，您已將資料上傳至 Amazon Keyspaces。 **重要** 現在您已傳輸資料，請調整目標資料表的容量模式設定，以符合應用程式的一般流量模式。在您變更佈建容量之前，會按小時費率產生費用。 # 疑難排解 資料上傳完成後，請檢查資料列是否已略過。若要這樣做，請導覽至來源 CSV 檔案的來源目錄，並搜尋具有下列名稱的檔案。 ``` import_yourcsvfilename.err.timestamp.csv ``` cqlsh 會將任何略過的資料列寫入具有該名稱的檔案中。如果檔案存在於來源目錄中，且其中有資料，則這些資料列不會上傳至 Amazon Keyspaces。若要重試這些資料列，請先檢查上傳期間遇到的任何錯誤，並相應地調整資料。若要重試這些資料列，您可以重新執行程序。 **常見錯誤** 未載入資料列的最常見原因是容量錯誤和剖析錯誤。 **將資料上傳至 Amazon Keyspaces 時發生無效的請求錯誤** 在下列範例中，來源資料表包含計數器資料欄，從 cqlsh `COPY`命令產生記錄的批次呼叫。Amazon Keyspaces 不支援已記錄的批次呼叫。 ``` Failed to import 10 rows: InvalidRequest - Error from server: code=2200 [Invalid query] message=“Only UNLOGGED Batches are supported at this time.“, will retry later, attempt 22 of 25 ``` 若要解決此錯誤，請使用 DSBulk 遷移資料。如需詳細資訊，請參閱[教學課程：使用 DSBulk 將資料載入 Amazon Keyspaces](dsbulk-upload.md)。 **將資料上傳至 Amazon Keyspaces 時發生剖析器錯誤** 下列範例顯示由於 而略過的資料列`ParseError`。 ``` Failed to import 1 rows: ParseError - Invalid ... – ``` 若要解決此錯誤，您需要確定要匯入的資料符合 Amazon Keyspaces 中的資料表結構描述。檢閱匯入檔案是否有剖析錯誤。您可以使用 `INSERT`陳述式嘗試使用單一資料列來隔離錯誤。 **將資料上傳至 Amazon Keyspaces 時發生容量錯誤** ``` Failed to import 1 rows: WriteTimeout - Error from server: code=1100 [Coordinator node timed out waiting for replica nodes' responses] message="Operation timed out - received only 0 responses." info={'received_responses': 0, 'required_responses': 2, 'write_type': 'SIMPLE', 'consistency': 'LOCAL_QUORUM'}, will retry later, attempt 1 of 100 ``` Amazon Keyspaces 使用 `ReadTimeout`和 `WriteTimeout`例外狀況來指示寫入請求何時因輸送量容量不足而失敗。為了協助診斷容量不足的例外狀況，Amazon Keyspaces 會在 Amazon CloudWatch 中發佈 `WriteThrottleEvents`和 `ReadThrottledEvents`指標。如需詳細資訊，請參閱[使用 Amazon CloudWatch 監控 Amazon Keyspaces](monitoring-cloudwatch.md)。 **將資料上傳至 Amazon Keyspaces 時的 cqlsh 錯誤** 為了協助對 cqlsh 錯誤進行疑難排解，請使用 `--debug`旗標重新執行失敗命令。 使用不相容的 cqlsh 版本時，您會看到下列錯誤。 ``` AttributeError: 'NoneType' object has no attribute 'is_up' Failed to import 3 rows: AttributeError - 'NoneType' object has no attribute 'is_up', given up after 1 attempts ``` 執行下列命令，確認已安裝正確的 cqlsh 版本。 ``` cqlsh --version ``` 您應該會看到類似以下內容的輸出。 ``` cqlsh 5.0.1 ``` 如果您使用的是 Windows，請將 的所有執行個體取代`cqlsh`為 `cqlsh.bat`。例如，若要在 Windows 中檢查 cqlsh 的版本，請執行下列命令。 ``` cqlsh.bat --version ``` cqlsh 用戶端從伺服器收到任何類型的連續三次錯誤後，與 Amazon Keyspaces 的連線會失敗。cqlsh 用戶端失敗，並顯示下列訊息。 ``` Failed to import 1 rows: NoHostAvailable - , will retry later, attempt 3 of 100 ``` 若要解決此錯誤，您需要確定要匯入的資料符合 Amazon Keyspaces 中的資料表結構描述。檢閱匯入檔案是否有剖析錯誤。您可以使用 INSERT 陳述式來隔離錯誤，嘗試使用單一資料列。 用戶端會自動嘗試重新建立連線。 # 教學課程：使用 DSBulk 將資料載入 Amazon Keyspaces 本step-by-step教學課程將引導您使用 [GitHub](https://github.com/datastax/dsbulk.git) 上提供的 DataStax 大量載入器 (DSBulk)，將資料從 Apache Cassandra 遷移至 Amazon Keyspaces。使用 DSBulk 有助於將資料集上傳至 Amazon Keyspaces 以供學術或測試之用。如需如何遷移生產工作負載的詳細資訊，請參閱 [離線遷移程序：Apache Cassandra 到 Amazon Keyspaces](migrating-offline.md)。在本教學課程中，您會完成下列步驟。 先決條件 – 使用登入資料設定 AWS 帳戶、為憑證建立 JKS 信任存放區檔案、設定 `cqlsh`、下載並安裝 DSBulk，以及設定 `application.conf` 檔案。 1. **建立來源 CSV 和目標資料表** – 準備 CSV 檔案做為來源資料，並在 Amazon Keyspaces 中建立目標金鑰空間和資料表。 1. **準備資料** – 隨機化 CSV 檔案中的資料並加以分析，以判斷平均和最大資料列大小。 1. **設定輸送量容量** – 根據資料大小和所需的載入時間計算所需的寫入容量單位 (WCUs)，並設定資料表的佈建容量。 1. **設定 DSBulk 設定** – 使用身分驗證、SSL/TLS、一致性層級和連線集區大小等設定建立 DSBulk 組態檔案。 1. **執行 DSBulk 載入命令** – 執行 DSBulk 載入命令，將 CSV 檔案的資料上傳至 Amazon Keyspaces 資料表，並監控進度。 **Topics** + [先決條件：您必須先完成的步驟，才能使用 DSBulk 上傳資料](dsbulk-upload-prequs.md) + [步驟 1：使用 DSBulk 建立來源 CSV 檔案和資料上傳的目標資料表](dsbulk-upload-source.md) + [步驟 2：使用 DSBulk 準備要上傳的資料](dsbulk-upload-prepare-data.md) + [步驟 3：設定目標資料表的輸送量容量](dsbulk-upload-capacity.md) + [步驟 4：設定將資料從 CSV 檔案上傳至目標資料表`DSBulk`的設定](dsbulk-upload-config.md) + [步驟 5：執行 DSBulk `load`命令，將 CSV 檔案的資料上傳至目標資料表](dsbulk-upload-run.md) # 先決條件：您必須先完成的步驟，才能使用 DSBulk 上傳資料 您必須完成下列任務，才能開始本教學課程。 1. 如果您尚未這麼做，請依照 中的步驟註冊 AWS 帳戶[設定 AWS Identity and Access Management](accessing.md#SettingUp.IAM)。 1. 遵循 中的步驟建立登入資料[建立和設定 Amazon Keyspaces 的 AWS 登入資料](access.credentials.md)。 1. 建立 JKS 信任存放區檔案。 1. 下載下列數位憑證，並將檔案儲存在本機或您的主目錄中。 1. AmazonRootCA1 1. AmazonRootCA2 1. AmazonRootCA3 1. AmazonRootCA4 1. Starfield Class 2 根目錄 （選用 – 用於回溯相容性） 若要下載憑證，您可以使用下列命令。 ``` curl -O https://www.amazontrust.com/repository/AmazonRootCA1.pem curl -O https://www.amazontrust.com/repository/AmazonRootCA2.pem curl -O https://www.amazontrust.com/repository/AmazonRootCA3.pem curl -O https://www.amazontrust.com/repository/AmazonRootCA4.pem curl -O https://certs.secureserver.net/repository/sf-class2-root.crt ``` **注意** Amazon Keyspaces 先前使用錨定至 Starfield 類別 2 CA 的 TLS 憑證。 AWS 正在將所有 遷移 AWS 區域 至根據 Amazon Trust Services (Amazon 根 CAs 發行的憑證。在此轉換期間，請將用戶端設定為信任 Amazon 根 CAs1–4 和 Starfield 根，以確保所有區域的相容性。 1. 將數位憑證轉換為 trustStore 檔案，並將其新增至金鑰存放區。 ``` openssl x509 -outform der -in AmazonRootCA1.pem -out temp_file.der keytool -import -alias amazon-root-ca-1 -keystore cassandra_truststore.jks -file temp_file.der openssl x509 -outform der -in AmazonRootCA2.pem -out temp_file.der keytool -import -alias amazon-root-ca-2 -keystore cassandra_truststore.jks -file temp_file.der openssl x509 -outform der -in AmazonRootCA3.pem -out temp_file.der keytool -import -alias amazon-root-ca-3 -keystore cassandra_truststore.jks -file temp_file.der openssl x509 -outform der -in AmazonRootCA4.pem -out temp_file.der keytool -import -alias amazon-root-ca-4 -keystore cassandra_truststore.jks -file temp_file.der openssl x509 -outform der -in sf-class2-root.crt -out temp_file.der keytool -import -alias cassandra -keystore cassandra_truststore.jks -file temp_file.der ``` 在最後一個步驟中，您需要為金鑰存放區建立密碼，並信任每個憑證。互動式命令看起來像這樣。 ``` Enter keystore password: Re-enter new password: Owner: CN=Amazon Root CA 1, O=Amazon, C=US Issuer: CN=Amazon Root CA 1, O=Amazon, C=US Serial number: 66c9fcf99bf8c0a39e2f0788a43e696365bca Valid from: Tue May 26 00:00:00 UTC 2015 until: Sun Jan 17 00:00:00 UTC 2038 Certificate fingerprints: SHA1: 8D:A7:F9:65:EC:5E:FC:37:91:0F:1C:6E:59:FD:C1:CC:6A:6E:DE:16 SHA256: 8E:CD:E6:88:4F:3D:87:B1:12:5B:A3:1A:C3:FC:B1:3D:70:16:DE:7F:57:CC:90:4F:E1:CB:97:C6:AE:98:19:6E Signature algorithm name: SHA256withRSA Subject Public Key Algorithm: 2048-bit RSA key Version: 3 Extensions: #1: ObjectId: 2.5.29.19 Criticality=true BasicConstraints:[ CA:true PathLen:2147483647 ] #2: ObjectId: 2.5.29.15 Criticality=true KeyUsage [ DigitalSignature Key_CertSign Crl_Sign ] #3: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: 84 18 CC 85 34 EC BC 0C 94 94 2E 08 59 9C C7 B2 ....4.......Y... 0010: 10 4E 0A 08 .N.. ] ] Trust this certificate? [no]: yes Certificate was added to keystore Enter keystore password: Owner: CN=Amazon Root CA 2, O=Amazon, C=US Issuer: CN=Amazon Root CA 2, O=Amazon, C=US Serial number: 66c9fd29635869f0a0fe58678f85b26bb8a37 Valid from: Tue May 26 00:00:00 UTC 2015 until: Sat May 26 00:00:00 UTC 2040 Certificate fingerprints: SHA1: 5A:8C:EF:45:D7:A6:98:59:76:7A:8C:8B:44:96:B5:78:CF:47:4B:1A SHA256: 1B:A5:B2:AA:8C:65:40:1A:82:96:01:18:F8:0B:EC:4F:62:30:4D:83:CE:C4:71:3A:19:C3:9C:01:1E:A4:6D:B4 Signature algorithm name: SHA384withRSA Subject Public Key Algorithm: 4096-bit RSA key Version: 3 Extensions: #1: ObjectId: 2.5.29.19 Criticality=true BasicConstraints:[ CA:true PathLen:2147483647 ] #2: ObjectId: 2.5.29.15 Criticality=true KeyUsage [ DigitalSignature Key_CertSign Crl_Sign ] #3: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: B0 0C F0 4C 30 F4 05 58 02 48 FD 33 E5 52 AF 4B ...L0..X.H.3.R.K 0010: 84 E3 66 52 ..fR ] ] Trust this certificate? [no]: yes Certificate was added to keystore Enter keystore password: Owner: CN=Amazon Root CA 3, O=Amazon, C=US Issuer: CN=Amazon Root CA 3, O=Amazon, C=US Serial number: 66c9fd5749736663f3b0b9ad9e89e7603f24a Valid from: Tue May 26 00:00:00 UTC 2015 until: Sat May 26 00:00:00 UTC 2040 Certificate fingerprints: SHA1: 0D:44:DD:8C:3C:8C:1A:1A:58:75:64:81:E9:0F:2E:2A:FF:B3:D2:6E SHA256: 18:CE:6C:FE:7B:F1:4E:60:B2:E3:47:B8:DF:E8:68:CB:31:D0:2E:BB:3A:DA:27:15:69:F5:03:43:B4:6D:B3:A4 Signature algorithm name: SHA256withECDSA Subject Public Key Algorithm: 256-bit EC (secp256r1) key Version: 3 Extensions: #1: ObjectId: 2.5.29.19 Criticality=true BasicConstraints:[ CA:true PathLen:2147483647 ] #2: ObjectId: 2.5.29.15 Criticality=true KeyUsage [ DigitalSignature Key_CertSign Crl_Sign ] #3: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: AB B6 DB D7 06 9E 37 AC 30 86 07 91 70 C7 9C C4 ......7.0...p... 0010: 19 B1 78 C0 ..x. ] ] Trust this certificate? [no]: yes Certificate was added to keystore Enter keystore password: Owner: CN=Amazon Root CA 4, O=Amazon, C=US Issuer: CN=Amazon Root CA 4, O=Amazon, C=US Serial number: 66c9fd7c1bb104c2943e5717b7b2cc81ac10e Valid from: Tue May 26 00:00:00 UTC 2015 until: Sat May 26 00:00:00 UTC 2040 Certificate fingerprints: SHA1: F6:10:84:07:D6:F8:BB:67:98:0C:C2:E2:44:C2:EB:AE:1C:EF:63:BE SHA256: E3:5D:28:41:9E:D0:20:25:CF:A6:90:38:CD:62:39:62:45:8D:A5:C6:95:FB:DE:A3:C2:2B:0B:FB:25:89:70:92 Signature algorithm name: SHA384withECDSA Subject Public Key Algorithm: 384-bit EC (secp384r1) key Version: 3 Extensions: #1: ObjectId: 2.5.29.19 Criticality=true BasicConstraints:[ CA:true PathLen:2147483647 ] #2: ObjectId: 2.5.29.15 Criticality=true KeyUsage [ DigitalSignature Key_CertSign Crl_Sign ] #3: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: D3 EC C7 3A 65 6E CC E1 DA 76 9A 56 FB 9C F3 86 ...:en...v.V.... 0010: 6D 57 E5 81 mW.. ] ] Trust this certificate? [no]: yes Certificate was added to keystore Enter keystore password: Owner: OU=Starfield Class 2 Certification Authority, O="Starfield Technologies, Inc.", C=US Issuer: OU=Starfield Class 2 Certification Authority, O="Starfield Technologies, Inc.", C=US Serial number: 0 Valid from: Tue Jun 29 17:39:16 UTC 2004 until: Thu Jun 29 17:39:16 UTC 2034 Certificate fingerprints: SHA1: AD:7E:1C:28:B0:64:EF:8F:60:03:40:20:14:C3:D0:E3:37:0E:B5:8A SHA256: 14:65:FA:20:53:97:B8:76:FA:A6:F0:A9:95:8E:55:90:E4:0F:CC:7F:AA:4F:B7:C2:C8:67:75:21:FB:5F:B6:58 Signature algorithm name: SHA1withRSA (weak) Subject Public Key Algorithm: 2048-bit RSA key Version: 3 Extensions: #1: ObjectId: 2.5.29.35 Criticality=false AuthorityKeyIdentifier [ KeyIdentifier [ 0000: BF 5F B7 D1 CE DD 1F 86 F4 5B 55 AC DC D7 10 C2 ._.......[U..... 0010: 0E A9 88 E7 .... ] [OU=Starfield Class 2 Certification Authority, O="Starfield Technologies, Inc.", C=US] SerialNumber: [ 00] ] #2: ObjectId: 2.5.29.19 Criticality=false BasicConstraints:[ CA:true PathLen:2147483647 ] #3: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: BF 5F B7 D1 CE DD 1F 86 F4 5B 55 AC DC D7 10 C2 ._.......[U..... 0010: 0E A9 88 E7 .... ] ] Warning: The input uses the SHA1withRSA signature algorithm which is considered a security risk. This algorithm will be disabled in a future update. Trust this certificate? [no]: yes Certificate was added to keystore ``` 1. 設定 Cassandra Query Language shell (cqlsh) 連線，並依照 中的步驟確認您可以連線至 Amazon Keyspaces[使用 `cqlsh` 連線至 Amazon Keyspaces](programmatic.cqlsh.md)。 1. 下載並安裝 DSBulk。 **注意** 本教學課程中顯示的版本可能不是最新版本。下載 DSBulk 之前，請檢查 [DataStax Bulk Loader 下載頁面](https://downloads.datastax.com/#bulk-loader)以取得最新版本，並相應地更新下列命令中的版本編號。 1. 若要下載 DSBulk，您可以使用下列程式碼。 ``` curl -OL https://downloads.datastax.com/dsbulk/dsbulk-1.8.0.tar.gz ``` 1. 然後解壓縮 tar 檔案，並將 DSBulk 新增至您的 `PATH`，如下列範例所示。 ``` tar -zxvf dsbulk-1.8.0.tar.gz # add the DSBulk directory to the path export PATH=$PATH:./dsbulk-1.8.0/bin ``` 1. 建立 `application.conf` 檔案以存放 DSBulk 要使用的設定。您可以將下列範例儲存為 `./dsbulk_keyspaces.conf`。如果您不在本機節點上，請將 `localhost`取代為本機 Cassandra 叢集的聯絡點，例如 DNS 名稱或 IP 地址。請記下檔案名稱和路徑，因為您稍後需要在 `dsbulk load`命令中指定此項目。 ``` datastax-java-driver { basic.contact-points = [ "localhost"] advanced.auth-provider { class = software.aws.mcs.auth.SigV4AuthProvider aws-region = us-east-1 } } ``` 1. 若要啟用 SigV4 支援，請從 [GitHub](https://github.com/aws/aws-sigv4-auth-cassandra-java-driver-plugin/releases/) 下載著色`jar`檔案，並將其放在 DSBulk `lib` 資料夾中，如下列範例所示。 ``` curl -O -L https://github.com/aws/aws-sigv4-auth-cassandra-java-driver-plugin/releases/download/4.0.6-shaded-v2/aws-sigv4-auth-cassandra-java-driver-plugin-4.0.6-shaded.jar ``` # 步驟 1：使用 DSBulk 建立來源 CSV 檔案和資料上傳的目標資料表 在本教學課程中，我們使用逗號分隔值 (CSV) 檔案，其名稱`keyspaces_sample_table.csv`為資料遷移的來源檔案。提供的範例檔案包含名稱為 之資料表的幾列資料`book_awards`。 1. 建立來源檔案。您可以選擇下列其中一個選項： + 下載下列封存檔案 [samplemigration.zip](samples/samplemigration.zip) 中包含的範例 CSV 檔案 (`keyspaces_sample_table.csv`)。解壓縮封存，並記下 的路徑`keyspaces_sample_table.csv`。 + 若要使用存放在 Apache Cassandra 資料庫中的自有資料填入 CSV 檔案，您可以使用 填入來源 CSV 檔案`dsbulk unload`，如下列範例所示。 ``` dsbulk unload -k mykeyspace -t mytable -f ./my_application.conf > keyspaces_sample_table.csv ``` 請確定您建立的 CSV 檔案符合下列要求： + 第一列包含資料欄名稱。 + 來源 CSV 檔案中的資料欄名稱符合目標資料表中的資料欄名稱。 + 資料以逗號分隔。 + 所有資料值都是有效的 Amazon Keyspaces 資料類型。請參閱 [資料類型](cql.elements.md#cql.data-types)。 1. 在 Amazon Keyspaces 中建立目標金鑰空間和資料表。 1. 使用 連線至 Amazon Keyspaces`cqlsh`，將下列範例中的服務端點、使用者名稱和密碼取代為您自己的值。 ``` cqlsh cassandra.us-east-1.amazonaws.com 9142 -u "111122223333" -p "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" --ssl ``` 1. 建立名稱為 的新金鑰空間`catalog`，如下列範例所示。 ``` CREATE KEYSPACE catalog WITH REPLICATION = {'class': 'SingleRegionStrategy'}; ``` 1. 在新的金鑰空間狀態為可用之後，請使用下列程式碼來建立目標資料表 `book_awards`。若要進一步了解非同步資源建立以及如何檢查資源是否可用，請參閱 [檢查 Amazon Keyspaces 中的金鑰空間建立狀態](keyspaces-create.md)。 ``` CREATE TABLE catalog.book_awards ( year int, award text, rank int, category text, book_title text, author text, publisher text, PRIMARY KEY ((year, award), category, rank) ); ``` 如果 Apache Cassandra 是原始資料來源，使用相符的標頭建立 Amazon Keyspaces 目標資料表的簡單方法是從來源資料表產生`CREATE TABLE`陳述式，如下列陳述式所示。 ``` cqlsh localhost 9042 -u "username" -p "password" --execute "DESCRIBE TABLE mykeyspace.mytable;" ``` 然後使用與 Cassandra 來源資料表中的描述相符的資料欄名稱和資料類型，在 Amazon Keyspaces 中建立目標資料表。 # 步驟 2：使用 DSBulk 準備要上傳的資料 準備來源資料以進行有效率的傳輸是兩個步驟。首先，您將資料隨機化。在第二個步驟中，您會分析資料，以判斷適當的`dsbulk`參數值和所需的資料表設定。 **隨機化資料** `dsbulk` 命令會以 CSV 檔案中顯示的相同順序讀取和寫入資料。如果您使用 `dsbulk`命令來建立來源檔案，資料會以 CSV 中的金鑰排序順序寫入。在內部，Amazon Keyspaces 會使用分割區索引鍵分割資料。雖然 Amazon Keyspaces 具有內建邏輯，可協助負載平衡相同分割區索引鍵的請求，但如果您隨機排列順序，則載入資料會更快、更有效率。這是因為您可以利用 Amazon Keyspaces 寫入不同分割區時發生的內建負載平衡。 若要將寫入平均分散到分割區，您必須隨機化來源檔案中的資料。您可以撰寫應用程式來執行此操作，或使用開放原始碼工具，例如 [Shuf](https://en.wikipedia.org/wiki/Shuf)。Shuf 可在 Linux 發行版本、macOS （透過在 [homebrew](https://brew.sh) 中安裝 coreutils) 和 Windows （透過使用適用於 Linux 的 Windows 子系統 (WSL)) 上免費使用。需要額外的步驟，以防止具有資料欄名稱的標頭列在此步驟中隨機播放。 若要在保留 標頭時隨機化來源檔案，請輸入下列程式碼。 ``` tail -n +2 keyspaces_sample_table.csv | shuf -o keyspace.table.csv && (head -1 keyspaces_sample_table.csv && cat keyspace.table.csv ) > keyspace.table.csv1 && mv keyspace.table.csv1 keyspace.table.csv ``` Shuf 會將資料重寫至名為 的新 CSV 檔案`keyspace.table.csv`。您現在可以刪除`keyspaces_sample_table.csv`檔案 - 您不再需要它。 **分析資料** 透過分析資料來判斷平均和最大資料列大小。 您這樣做的原因如下： + 平均資料列大小有助於預估要傳輸的資料總量。 + 您需要平均資料列大小來佈建資料上傳所需的寫入容量。 + 您可以確保每個資料列的大小小於 1 MB，這是 Amazon Keyspaces 中的資料列大小上限。 **注意** 此配額是指資料列大小，而不是分割區大小。與 Apache Cassandra 分割區不同，Amazon Keyspaces 分割區的大小幾乎沒有限制。分割區索引鍵和叢集資料欄需要額外的中繼資料儲存空間，您必須將其新增至資料列的原始大小。如需詳細資訊，請參閱[估計 Amazon Keyspaces 中的資料列大小](calculating-row-size.md)。 下列程式碼使用 [AWK](https://en.wikipedia.org/wiki/AWK) 來分析 CSV 檔案，並列印平均和最大資料列大小。 ``` awk -F, 'BEGIN {samp=10000;max=-1;}{if(NR>1){len=length($0);t+=len;avg=t/NR;max=(len>max ? len : max)}}NR==samp{exit}END{printf("{lines: %d, average: %d bytes, max: %d bytes}\n",NR,avg,max);}' keyspace.table.csv ``` 執行此程式碼會產生下列輸出。 ``` using 10,000 samples: {lines: 10000, avg: 123 bytes, max: 225 bytes} ``` 請確定您的資料列大小上限不超過 1 MB。如果是這樣，您必須分解資料列或壓縮資料，使資料列大小低於 1 MB。在本教學課程的下一個步驟中，您會使用平均資料列大小來佈建資料表的寫入容量。 # 步驟 3：設定目標資料表的輸送量容量 本教學課程說明如何調校 DSBulk，以在設定的時間範圍內載入資料。由於您知道預先執行的讀取和寫入數量，請使用佈建的容量模式。完成資料傳輸後，您應該設定資料表的容量模式，以符合應用程式的流量模式。若要進一步了解容量管理，請參閱 [在 Amazon Keyspaces 中管理無伺服器資源 （適用於 Apache Cassandra)](serverless_resource_management.md)。 使用佈建容量模式時，您可以指定要預先佈建至資料表的讀取和寫入容量。寫入容量會以每小時計費，並以寫入容量單位 (WCUs計量。每個 WCU 都有足夠的寫入容量，可支援每秒寫入 1 KB 的資料。當您載入資料時，寫入速率必須低於目標資料表上設定的最大 WCUs（參數：`write_capacity_units`)。 根據預設，您最多可以將 40，000 WCUs 佈建到 資料表，並在您帳戶中所有資料表中佈建 80，000 WCUs。如果您需要額外的容量，您可以在 [ Service Quotas](https://console.aws.amazon.com/servicequotas/home#!/services/cassandra/quotas) 主控台中請求增加配額。如需配額的詳細資訊，請參閱 [Amazon Keyspaces 配額 （適用於 Apache Cassandra)](quotas.md)。 **計算插入所需的 WCUs平均數量** 每秒插入 1 KB 的資料需要 1 個 WCU。如果您的 CSV 檔案有 360，000 個資料列，而且您想要在 1 小時內載入所有資料，則必須每秒寫入 100 個資料列 (360，000 個資料列/60 分鐘/60 秒 = 每秒 100 個資料列）。如果每一列最多有 1 KB 的資料，若要每秒插入 100 列，您必須將 100 WCUs 佈建到您的資料表。如果每個資料列有 1.5 KB 的資料，您需要兩個 WCUs才能每秒插入一個資料列。因此，若要每秒插入 100 個資料列，您必須佈建 200 WCUs。 若要判斷每秒需要插入一列的 WCUs 數量，請將平均資料列大小以位元組為單位除以 1024，然後四捨五入至最接近的整數。 例如，如果平均資料列大小為 3000 位元組，您需要三個 WCUs才能每秒插入一個資料列。 ``` ROUNDUP(3000 / 1024) = ROUNDUP(2.93) = 3 WCUs ``` **計算資料載入時間和容量** 現在您已知道 CSV 檔案中的平均大小和資料列數，您可以計算在指定時間內需要載入資料的 WCUs 數量，以及使用不同的 WCU 設定載入 CSV 檔案中所有資料所需的大約時間。 例如，如果檔案中的每一列都是 1 KB，而且 CSV 檔案中有 1，000，000 列，若要在 1 小時內載入資料，您需要在該小時內將至少 278 WCUs 佈建至資料表。 ``` 1,000,000 rows * 1 KBs = 1,000,000 KBs 1,000,000 KBs / 3600 seconds =277.8 KBs / second = 278 WCUs ``` **設定佈建的容量設定** 您可以在建立資料表或使用 `ALTER TABLE`命令時設定資料表的寫入容量設定。以下是使用 `ALTER TABLE`命令修改資料表佈建容量設定的語法。 ``` ALTER TABLE catalog.book_awards WITH custom_properties={'capacity_mode':{'throughput_mode': 'PROVISIONED', 'read_capacity_units': 100, 'write_capacity_units': 278}} ; ``` 如需完整的語言參考，請參閱 [CREATE TABLE](cql.ddl.table.md#cql.ddl.table.create)和 [ALTER TABLE](cql.ddl.table.md#cql.ddl.table.alter)。 # 步驟 4：設定將資料從 CSV 檔案上傳至目標資料表`DSBulk`的設定 本節概述設定 DSBulk 以將資料上傳至 Amazon Keyspaces 所需的步驟。您可以使用組態檔案來設定 DSBulk。您直接從命令列指定組態檔案。 1. 建立 DSBulk 組態檔案以遷移至 Amazon Keyspaces，在此範例中，我們使用檔案名稱 `dsbulk_keyspaces.conf`。在 DSBulk 組態檔案中指定下列設定。 1. *`PlainTextAuthProvider`* – 使用 `PlainTextAuthProvider`類別建立身分驗證提供者。 `ServiceUserName`和 `ServicePassword`應符合您在產生服務特定登入資料時，依照 中的步驟取得的使用者名稱和密碼[建立 Amazon Keyspaces 的程式設計存取憑證](programmatic.credentials.md)。 1. *`local-datacenter`* – 將 的值`local-datacenter`設定為您要連線 AWS 區域 的 。例如，如果應用程式正在連線至 `cassandra.us-east-1.amazonaws.com`，請將本機資料中心設定為 `us-east-1`。如需所有可用的 AWS 區域，請參閱 [Amazon Keyspaces 的服務端點](programmatic.endpoints.md)。若要避免複本，請將 `slow-replica-avoidance`設定為 `false`。 1. *`SSLEngineFactory`* – 若要設定 SSL/TLS，`SSLEngineFactory`請在組態檔案中新增區段以使用 指定類別的單行來初始化 `class = DefaultSslEngineFactory`。提供 的路徑`cassandra_truststore.jks`和您先前建立的密碼。 1. *`consistency`* – 將一致性層級設定為 `LOCAL QUORUM`。不支援其他寫入一致性層級，如需詳細資訊，請參閱 [支援的 Apache Cassandra 讀取和寫入一致性層級和相關成本](consistency.md)。 1. 每個集區的連線數可在 Java 驅動程式中設定。在此範例中，將 `advanced.connection.pool.local.size` 設定為 3。 以下是完整的範例組態檔案。 ``` datastax-java-driver { basic.contact-points = [ "cassandra.us-east-1.amazonaws.com:9142"] advanced.auth-provider { class = PlainTextAuthProvider username = "ServiceUserName" password = "ServicePassword" } basic.load-balancing-policy { local-datacenter = "us-east-1" slow-replica-avoidance = false } basic.request { consistency = LOCAL_QUORUM default-idempotence = true } advanced.ssl-engine-factory { class = DefaultSslEngineFactory truststore-path = "./cassandra_truststore.jks" truststore-password = "my_password" hostname-validation = false } advanced.connection.pool.local.size = 3 } ``` 1. 檢閱 DSBulk `load`命令的參數。 1. *`executor.maxPerSecond`* – 負載命令每秒嘗試同時處理的列數上限。如果取消設定，則會使用 -1 停用此設定。 `executor.maxPerSecond` 根據您佈建至目標目的地資料表的 WCUs 數目來設定 。`load` 命令`executor.maxPerSecond`的 不是限制，而是目標平均值。這表示它可以 （且通常可以） 爆量超過您設定的數字。若要允許爆量，並確保有足夠的容量來處理資料載入請求，請將 `executor.maxPerSecond` 設為資料表寫入容量的 90%。 ``` executor.maxPerSecond = WCUs * .90 ``` 在本教學課程中，我們會將 `executor.maxPerSecond`設定為 5。 **注意** 如果您使用的是 DSBulk 1.6.0 或更高版本，則可以`dsbulk.engine.maxConcurrentQueries`改用 。 1. 為 DSBulk `load`命令設定這些額外參數。 + *`batch-mode`* – 此參數會告知系統依分割區索引鍵將操作分組。建議您停用批次模式，因為它可能會導致快速鍵案例並導致 `WriteThrottleEvents`。 + *`driver.advanced.retry-policy-max-retries`* – 這會決定重試失敗查詢的次數。如果取消設定，則預設值為 10。您可以視需要調整此值。 + *`driver.basic.request.timeout`* – 系統等待查詢傳回的時間，以分鐘為單位。如果取消設定，則預設值為「5 分鐘」。您可以視需要調整此值。 # 步驟 5：執行 DSBulk `load`命令，將 CSV 檔案的資料上傳至目標資料表 在本教學課程的最後一個步驟中，您會將資料上傳至 Amazon Keyspaces。 若要執行 DSBulk `load`命令，請完成下列步驟。 1. 執行下列程式碼，將資料從 csv 檔案上傳至 Amazon Keyspaces 資料表。請務必更新您先前建立之應用程式組態檔案的路徑。 ``` dsbulk load -f ./dsbulk_keyspaces.conf --connector.csv.url keyspace.table.csv -header true --batch.mode DISABLED --executor.maxPerSecond 5 --driver.basic.request.timeout "5 minutes" --driver.advanced.retry-policy.max-retries 10 -k catalog -t book_awards ``` 1. 輸出包含日誌檔案的位置，其中會詳細說明成功和失敗的操作。檔案會存放在下列目錄中。 ``` Operation directory: /home/user_name/logs/UNLOAD_20210308-202317-801911 ``` 1. 日誌檔案項目將包含指標，如下列範例所示。檢查以確保資料列數目與 csv 檔案中的資料列數目一致。 ``` total | failed | rows/s | p50ms | p99ms | p999ms 200 | 0 | 200 | 21.63 | 21.89 | 21.89 ``` **重要** 現在您已傳輸資料，請調整目標資料表的容量模式設定，以符合應用程式的一般流量模式。在您變更佈建容量之前，會依每小時費率產生費用。如需詳細資訊，請參閱[在 Amazon Keyspaces 中設定讀取/寫入容量模式](ReadWriteCapacityMode.md)。