建立遷移計畫，以從 Apache Cassandra 遷移至 Amazon Keyspaces

從 GitHub 下載相容性 Python 指令碼，並將其移至可存取現有 Apache Cassandra 叢集的位置。

相容性指令碼使用與 類似的參數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 中的讀取容量和寫入容量使用率非常重要。下圖顯示 Cassandra 字符範圍內的典型資料分佈。

您可以使用 GitHub 上可用的資料列大小採樣器指令碼，收集 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 中的資料列大小。

決定資料表大小

使用 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

擷取讀取和寫入次數

若要判斷 Amazon Keyspaces 資料表的容量和擴展需求，請在遷移之前擷取 Cassandra 資料表的讀取和寫入請求率。

Amazon Keyspaces 是無伺服器，您只需為使用量付費。一般而言，Amazon Keyspaces 中的讀取/寫入輸送量價格取決於請求的數量和大小。

Amazon Keyspaces 有兩種容量模式：

由於您在 Amazon Keyspaces 中分別佈建讀取和寫入輸送量容量，因此您需要獨立測量現有資料表中讀取和寫入的請求率。

若要從現有的 Cassandra 叢集收集最準確的使用率指標，請針對在單一資料中心所有節點上彙總的資料表，擷取長時間內協調器層級讀取和寫入操作的平均每秒請求數 (RPS)。

擷取至少數週內的平均 RPS 會擷取流量模式中的尖峰和山谷，如下圖所示。

您有兩個選項可判斷 Cassandra 資料表的讀取和寫入請求率。

• 使用現有的 Cassandra 監控

  您可以使用下表所示的指標來觀察讀取和寫入請求。請注意，指標名稱可能會根據您使用的監控工具而變更。

  維度	Cassandra JMX 指標
  寫入	org.apache.cassandra.metrics:type=ClientRequest, scope=Write,name=Latency#Count
  讀取	org.apache.cassandra.metrics:type=ClientRequest, scope=Read,name=Latency#Count

• 使用 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

判斷資料表的容量使用率

若要估計平均容量使用率，請從平均請求率和 Cassandra 來源資料表的平均資料列大小開始。

Amazon Keyspaces 使用讀取容量單位 RCUs) 和寫入容量單位 WCUs) 來測量資料表讀取和寫入的佈建輸送量容量。在此預估中，我們會使用這些單位來計算遷移後新 Amazon Keyspaces 資料表的讀取和寫入容量需求。

本主題稍後將討論佈建容量模式和隨需容量模式之間的選擇如何影響帳單。但是在此範例中，對於容量使用率的預估，我們假設資料表處於佈建模式。

下列公式可用來預估所需的 RCUs 和 WCUs。

這在下列公式中表示。

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

計算 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