標籤: cassandra

Cassandra 叢集狀態的計算機

網路上看到的一個Cassandra的簡易計算機，作者還有的提供原始碼在Github 上，所以如果有需要的話也可以自己fork一份自己架在自己的網頁上。

這個計算機的功能也很簡單，主要是提供使用者可以快速顯示在不同的cluster狀態下，根據keyspace的read/write 設定對於叢集的影響，像是：

  • 可以容忍多少個節點失效而不遺失資料。
  • 每個節點的資料分佈比例。
  • 每次寫入會連接到的節點數量。
  • 每次讀取時會連接到的節點數量。

reference:

  • https://github.com/jalkanen/cassandracalculator
  • https://www.ecyrd.com/cassandracalculator/

Cassandra 4.0

在Scylla Blog上看到的Cassandra 4.0 vs Cassandra 3.11的相關測試文章，沒想到會去測試Cassandra不同版本間的效能比較，還蠻意外的XD

從測試的數據來看，Cassandra 4.0的效能幾乎在各個測試情境下，都比Cassandra 3.11要好不少，看起來平均有20-30%的效能改進；等之後有機會再看看是否有更多相關的測試數據出來XDD

reference:

Cassandra用來刪table的指令

雖然說CQL很像SQL，但在Cassandra中，用來刪table指令也是有差異的，在stackoverflow上找到下面可以用下面的指令來刪除…

TRUNCATE keyspace_name.table_name;

或是用

TRUNCATE table_name;

值得注意的是，在stackoverflow中有提到，刪table前，Cassandra預設會先對要刪的table建立一分snapshot，所以有刪table的動作的話，可能要定時清理一下舊的snoapshot。

reference:

測試Cassandra

最近公司的某個專案可能會用到Cassandra，所以在真的用之前還是先來做個簡易的Benchmark，來看看它是否真的能符合我們的需求(主要是write heavey的情境)。

測試#1

測試情境

  • cluster nodes: AWS EC2 i3.large * 3
  • benchmark node: AWS EC2 c5.2xlarge.

測試 Query如下：

INSERT INTO status (id1 id2, id3, succeed) VALUES ($id1, $id2, $id3, false)

測試程式會不停的隨機產生上述Query，並寫進Cassandra cluster中，並觀察throughput如何：

測試結果

結果蠻不如預期的，目前在concurrent connection = 500的情況下，也只達到9xx左右的qps

Next

目前初步檢視了目前的cluster 設定，發現先前的測試EC2 node主要還是使用EBS gp2，其IOPS感覺只能到100 IOPS左右，再參考了這篇AWS的文章後，感覺可以照著這樣的設定再來測試一次看看。

測試#2

測試情境

沿續上次的測試，但重新設定Cluster 使用EC2 i3.large * 3，但這次則是mount了 NVME SSD (local instance store) 到Cassandra data folder ，並使用了一樣的測試程式與Query。

測試結果

一樣不如預期，qps 也還是只能打到9xx 左右，不過這次有觀察到Cassandra node的cpu 在測試期間都滿載。

Next

從上次的測試來看，cpu cores 必須要加大了，感覺目前是卡在cpu這邊。

測試#3

測試情境

沿續上次的測試，但重新設定Cluster 使用EC2 c5.4xlarge * 3，但這次則是mount了 NVME SSD(EBS io2) 到Cassandra data folder ，並使用了一樣的測試程式與Query。

CREATE INDEX succeed ON status (succeed);

測試結果

若沒有index 的情況下，insert qps 目前可以到 11xxx 左右；若加了index，則insert qps 目前可以到8xxx左右。

測試#4

測試情境

沿續上次的測試，但重新設定Cluster 使用EC2 c5.4xlarge * 8，但這次則是mount了 NVME SSD(EBS io2, iops=5000) 到Cassandra data folder ，並使用了一樣的測試程式與Query與測試#3中的index。

測試結果

加了index，則insert qps 目前可以到14xxx左右，這次觀察到cluster cpu 大概只有跑到50%左右，看來benchmark client 必須要升級了。

測試#5

測試情境

沿續上次的測試，這次升級了Benchmark client 使用c5a.8xlarge，測試cluster的部分則是使用前面測試所留下來的EC2 c5a.4xlarge * 8.

測試結果

這次觀察到即使在使用concurrent connection = 2000的情況下，cluster cpu 大概只有跑到70%左右，而整體的qps約在16xxx；

從這邊來看感覺又是卡在IOPS=5000的部分，目前每個cluster node 可以設定的EBS 為io2, IOPS=5000，IOPS設太高的話會在一開始無法同時開8個EC2 c5a.4xlarge。

測試#6

測試情境

沿續上次的測試，這次試著再加了3 台 c5a.4xlarge到Cassandra cluster中，即是最後的cluster node 數量為

c5a.4xlarge * 10

測試結果

這次觀察在同一台機器，並且開啟2個benchmark 程式並使用concurrent connection = 2000的情況下，cluster cpu 大概只有跑到70%左右，而整體的qps約在20xxx；