Cassandraで多量のデータを扱う場合の注意点

このページではcassandraで大きなデータ集合を扱う場合に考慮すべき事項について幾つかの助言を述べます。
ここでは相互に関連する話題を一箇所にまとめることを目的としており、独自の手法について解説する意図はありません。
この話題について理解を深めるには他のWikiページを参照することを強くお勧めします。

このページは依然として作業中の状態です。もし情報的に古い内容を見つけたら、あなた自身で更新するか、cassandra-userメーリングリストに投稿してください。

ここで触れる話題はCassandra特有のものばかりではありません。例えば、どんなストレージシステムにおいてもアクティブなデータセットの大きさに対するキャッシュのサイズとIOPSの間にはトレードオフの関係があります。なぜなら、IOPSはキャッシュミスの比率に強く影響されるからです。

特に触れない限り、ここではCassandra 0.7以降を前提とします。

  • Cassandraのディスク使用率は時間経過に伴って急激に変動する場合があります。使用可能なディスク容量に比べて扱うデータ量が顕著に大きい場合、言い換えるとディスク容量に対してデータサイズが無視出来ないほど大きい場合は、次のようなことについて考慮したほうが良いでしょう。
    • カラムファミリのCompactionには、最大そのカラムファミリと同じ大きさのディスク容量が必要になります。（削除がない場合にmajor compactionが実行された場合）あなたのデータが単一、もしくは限られた少数のカラムファミリに格納されている場合、CFと同じ大きさの領域をCompactionに使用すると言うことは、ディスク使用量の観点からは看過できないかもしれません。
    • リペア操作にはある程度のディスク容量が必要です。（0.6では特に顕著です。0.7ではそれほどでもありません。TODO: 具体的な最大値、依存するパラメータを明示すること。）
  • データ量が多くなるにつれ、ディスクIO操作を避けるためにキャッシュへの依存が強まります。キャバシティに関するプランニングとテストの際には以下のことを考慮すべきです。
    • Cassandra の行キャッシュはJVMのヒープ上に存在し、compactionやrepairの影響を受けません。
    • 0.6.8以前はキーキャッシュはcompactionによって影響を受けます。それらのバージョンではキーキャッシュはsstable単位で管理されているため、compactionによってデータが新しいsstableにコピーされると古いキャッシュが無効になります。
      • この動作は0.6.9 及び0.7.0で改善されています。CASSANDRA-1878

    • OSのページキャッシュはcompaction及びrepair操作の影響を受けます。アクティブなデータをメモリ上に保つ手段としてページキャッシュに依存している場合、compaction及びrepair操作に連動して顕著な性能劣化が起きるでしょう。

  • bloom filterの最大サイズの実装上の制限により、14300万以上の行キーを格納しているカラムファミリでは、bloom filterの偽陽性率が増加することが予想されます。bloom filterがどのように使用されているかについてはArchitectureInternalsを参照してください。この制限に抵触した場合、行数の増加に従ってreadごとに追加のseekが発生するようになります。bloom filterの制限はsstable単位であるため、上記の影響は最後にcompactionが実行された時間に依存することに注意してください。major compactionの後ではカラムファミリの全データが単一のsstableに格納されるため、これはカラムファミリ単位の問題です。
  • Compactionは現在は並列化されていません。即ちある瞬間に実行されるCompactionは一つのみです。これは大きなcompactionsの実行中にsstable数が増大することを意味します。大きなcompactionsの実行中は複数の小さなsstableに書き込む必要があるためです。この状態ではreadに追加のseekが必要です。
  • ファイルシステムの選択について:巨大なファイルの削除は、例えばext2/ext3では恐ろしく遅く、多量のseekを要します。xfsまたはext4fsの使用を検討してください。これは恒常的に生じるsstableのバックグラウンドでのunlinkに影響します。また起動速度にも影響します。(起動時に削除待機中のsstableがある場合、起動プロセスの一環としてそれらを削除します。これは数TBのsstableを削除するような場合は有害でしょう。)
  • 各ノードが多量のデータを格納している場合、ノードの追加には時間がかかります。システムがぎりぎりまで逼迫する前にノードを増設した方がいいでしょう。
  • Cassandraは起動時にstable indexファイルを読みます。これは「indexサンプリング」と呼ばれています。indexサンプリングによりキーのサブセット（デフォルトでは100分の1）とディスク上の位置がメモリ上のインデックスに保持されます（ArchitectureInternals参照）。これはインデックスファイルが大きくなるにつれ、サンプリングに要する時間が長くなることを意味します。従って、キーを多量に含む巨大なインデックスが存在する場合、起動時のindexサンプリングが問題になる可能性があります。
  • 行キャッシュを大きくした場合のデメリットは起動に要する時間です。行キャッシュの情報を定期的に保存する際には、キャッシュされているキー値のみが保存されます。キーに対応するデータは起動時にプリフェッチされていなければなりません。巨大なデータセットではこれには多量のseekを要し、行キャッシュが使用可能になるまでの時間は行キャッシュサイズに比例します。（seek IOがディスク最適化の影響を受けておらず、かつ十分に大きなデータセットを扱う場合）
    • 将来的な改善方法については以下のリンクで議論されています: CASSANDRA-1625

https://c.statcounter.com/9397521/0/fe557aad/1/|stats

  • No labels