NoSQLのCassandraの大量データロードのチューニング(1ノードで)

前回の検証の振り返り

前回のブログで、Cassandraへの大量データのロードと全件検索の性能をPostgreSQLと比較して検証しました。

1ノード構成ではありますが、この時のCassandra側の性能が、PostgreSQLに比べると圧倒的に遅いことがわかりました。

以下は前回のブログで検証した結果です。
CassandraもPostgreSQLもパラメータチューニングなしです。

100万件のロードの所要時間

  • PostgreSQL:約3秒
  • Cassandra:タイムアウト頻発、約5分30秒

100万件の全件カウント検索の所要時間

  • PostgreSQL:1秒未満
  • Cassandra:タイムアウト発生で検索できず。タイムアウトしないように設定して約30秒

今回は、大量データロード時のCassandraのタイムアウトを抑止して、処理時間を短縮した方法と検証結果を紹介します。
検索の方は、次回のブログで書きます。

100万件のロードのタイムアウトを解決し、ロード時間を短縮した方法

何度かロードを繰り返していると、そのうちに、5分30秒どころか、タイムアウト頻発で終わらなくなりました。

vmstatを見ていると、スワップが頻発していることに気づきます。

JVMの起動オプション「-Xms」を確認すると、ヒープサイズが496Mと設定されていることがわかりました。
スワップが発生していた原因は、jvmのヒープサイズのデフォルト値496Mに対して、OSのメモリ1GBが少なすぎたことでした。

CassandraのJVMヒープサイズデフォルト値の計算ロジック

max(min(1/2 ram, 1024 megabytes), min(1/4 ram, 32765 megabytes))

引用元:https://docs.datastax.com/en/dse/6.7/dse-admin/datastax_enterprise/operations/opsConHeapSize.html#opsConHeapSize__jvmoptions

そこで、OSのメモリを1GB→2GBに増やして再度ロードしてみました。

2分42秒で終わりました。
スワップは発生しなくなり、タイムアウトも抑止できました。
Cassandra側のパラメータは何も変更していません。

PostgreSQLで同じことをすると約3秒で終わりました。
もっと早くできないでしょか?

Cassandraの書き込みアーキテクチャHow is data written?を参照し、書き込み処理を早くする方法として思いつくものを洗い出してみました。

  1. 書き込みのプロセス数を増やす
  2. メモリ領域(memtable)を増やして、ディスク(sstable)へのフラッシュ頻度を減らす
  3. ロード中にcommitlogへの書き込みを中止する
  4. GCの回数を減らす

vmstatではrunqueの数も多かったので、1.の方法を試すこととし、CPUを増やして複数プロセスで処理することでロード時間を短縮できないかを検証してみました。
2~4の方法は、次回以降で調査してみて、いい方法があれば検証してみます。

さて、copyコマンドを複数プロセスで実行する方法を調べたところ、

numprocesses

というオプションがありました。
これは使えそうです。
CPUを10個に増やして2プロセスで実行すると、処理速度はほぼ倍の1分25秒になりました。

numprocessesの値を増やしてcopyコマンドを実行した結果です。

表 numprocesseの値1~9までの処理時間と処理行数

グラフ

CPU10個に対してプロセス数は7で処理性能が頭打ちとなりましたが、処理時間を20秒まで短縮できました。
PostgreSQLだと3秒で終わったので、かなり不満ですが。。。

それは置いといて、1ノードでもCPUを増やすと速度を向上させることができたことがわかりました。
ノードを増やすとどうなるのだろうか。。

>> 雑誌等の執筆依頼を受付しております。
   ご希望の方はお気軽にお問い合わせください!

ご覧いただきありがとうございます! この投稿はお役に立ちましたか?

役に立った 役に立たなかった

0人がこの投稿は役に立ったと言っています。

コメント投稿

メールアドレスは表示されません。


*