ストレージエンジン
Cassandraは、書き込みの即時ログ記録から始まり、ディスクへのデータ書き込みで終わる、書き込みパス上のいくつかの段階でデータを処理します。
-
コミットログへのデータのログ記録
-
memtableへのデータの書き込み
-
memtableからのデータのフラッシュ
-
SSTableへのディスクへのデータの保存
コミットログへの書き込みのログ記録
書き込みが発生すると、Cassandraはデータをローカルの追記専用cassandra.apache.org//glossary.html#commit-log)[コミットログ]に書き込みます。この操作により、Cassandraノードに行われたすべての書き込みをログに記録することで、設定可能な耐久性が提供されます。予期しないシャットダウンが発生した場合、コミットログはデータの永続的な耐久性のある書き込みを提供します。起動時に、コミットログ内のすべての変更はcassandra.apache.org//glossary.html#memtable)[memtable]に適用されます。コミットログはテーブル間で共有されます。
すべての変更は、コミットログセグメントのストレージで書き込みが最適化され、ディスクへの書き込みに必要なシーク数が削減されます。コミットログセグメントは、commitlog_segment_size
オプションによって制限されます。定義されたサイズに達すると、新しいコミットログセグメントが作成されます。すべてのデータがSSTableにフラッシュされると、コミットログセグメントはアーカイブ、削除、またはリサイクルできます。Cassandraが特定の時点よりも古いデータをSSTableに書き込んだ場合、コミットログセグメントは切り捨てられます。nodetool drain
をCassandraを停止する前に実行すると、memtable内のすべてのデータがSSTableに書き込まれ、起動時のコミットログとの同期が不要になります。
-
commitlog_segment_size
:デフォルトサイズは32MiBで、ほとんどの場合問題ありませんが、コミットログセグメントをアーカイブしている場合(commitlog_archiving.propertiesを参照)、アーカイブの粒度を細かくする必要がある場合があります。8または16MiBが妥当です。commitlog_segment_size
は、cassandra.yaml
のmax_mutation_size
のデフォルト値も決定します。デフォルトでは、max_mutation_size
はcommitlog_segment_size
の半分です。
|
-
commitlog_sync
:periodicまたはbatchのいずれかになります。-
batch
:バッチモードでは、コミットログがディスクにfsyncされるまで、Cassandraは書き込みを承認しません。 -
periodic
:定期モードでは、書き込みはすぐに確認され、コミットログは単に「commitlog_sync_period」ミリ秒ごとに同期されます。-
commitlog_sync_period
:「periodic」fsync間の待機時間 *デフォルト値*:10000ms
-
-
デフォルト値:batch
予期しないシャットダウンが発生した場合、同期が遅れていると、Cassandraは同期期間以上を失う可能性があります。 |
-
commitlog_directory
:このオプションはデフォルトでコメントアウトされています。磁気HDDで実行している場合は、これはデータディレクトリとは別のスピンドルにする必要があります。設定されていない場合、デフォルトのディレクトリは$CASSANDRA_HOME/data/commitlog
です。
デフォルト値:/var/lib/cassandra/commitlog
-
commitlog_compression
:コミットログに適用する圧縮。省略した場合は、コミットログは圧縮されずに書き込まれます。LZ4、Snappy、Deflate、Zstd圧縮がサポートされています。
デフォルト値:(複雑なオプション)
# - class_name: LZ4Compressor
# parameters:
-
commitlog_total_space
:ディスク上のコミットログに使用する合計容量。このオプションはデフォルトでコメントアウトされています。容量がこの値を超えると、Cassandraは最も古いセグメントのすべてのダーティテーブルをフラッシュして削除します。したがって、コミットログの容量が小さいと、アクティブでないテーブルでフラッシュアクティビティが増える傾向があります。デフォルト値は、8192とコミットログボリュームの総容量の1/4の小さい方です。
デフォルト値:8192MiB
Memtable
書き込みが発生すると、Cassandraはデータをmemtableにも書き込みます。memtableは、Cassandraが書き込みをバッファリングするインメモリ構造です。一般的に、テーブルごとに1つのアクティブなmemtableがあります。memtableは、Cassandraがキーで検索するデータパーティションのライトバックキャッシュです。memtable_allocation_type
に応じて、memtableは完全にオンヒープ、または部分的にオフヒープに格納できます。
memtableは、設定可能な制限に達するまで、書き込みをソートされた順序で格納します。制限に達すると、memtableはディスクにフラッシュされ、変更不可能なSSTableになります。フラッシュはいくつかの方法でトリガーできます。
-
memtableのメモリ使用量が設定されたしきい値を超えた場合(
memtable_cleanup_threshold
を参照) -
コミットログ
が最大サイズに近づき、コミットログセグメントを解放するためにmemtableのフラッシュを強制します。
トリガーイベントが発生すると、memtableはディスクにフラッシュされるキューに入れられます。フラッシュは、memtableでソートされた順序でデータをディスクに書き込みます。トークンをディスク上の場所へマッピングするパーティションインデックスもディスク上に作成されます。
キューは、cassandra.yaml
ファイルのmemtable_heap_space
またはmemtable_offheap_space
設定を使用して設定できます。フラッシュするデータがmemtable_cleanup_threshold
を超えると、次のフラッシュが成功するまで、Cassandraは書き込みをブロックします。nodetool flush
またはnodetool drain
(他のノードへの接続を待機せずにmemtableをフラッシュします)を使用して、テーブルを手動でフラッシュできます。コミットログの再生時間を短縮するために、ノードを再起動する前にmemtableをフラッシュすることをお勧めします。ノードが動作を停止した場合、コミットログの再生により、停止前に存在していたmemtableへの書き込みが復元されます。
memtable内の対応するデータがディスク上のSSTableにフラッシュされると、コミットログ内のデータはパージされます。
SSTable
SSTableは、Cassandraがディスクにデータを永続的に保存するために使用する変更不可能なデータファイルです。SSTableはテーブルごとに保持されます。SSTableは変更不可能であり、memtableがフラッシュされた後は二度と書き込まれません。したがって、データの追加または変更に応じて、パーティションは通常複数のSSTableファイルに格納されます。
各SSTableは、個別のファイルに格納されている複数のコンポーネントで構成されています。
Data.db
-
実際のデータ、つまり行の内容。
Partitions.db
-
パーティションインデックスファイルは、装飾されたパーティションキーの一意のプレフィックスをデータファイルの場所、または行インデックスファイルでインデックス付けされたワイドパーティションの場合、行インデックスファイル内の場所へマッピングします。
Rows.db
-
行インデックスファイルには、2行以上を含むパーティション、かつインデックスブロック1つより大きいパーティションのエントリのみが含まれています。そのようなパーティションすべてについて、パーティションキーのコピー、パーティションヘッダー、および行ブロックセパレータのインデックスを格納します。このインデックスは、各行キーを、等しいかそれ以上の行キーを持つコンテンツが存在する最初のブロックにマッピングします。
Index.db
-
Data.db
ファイル内の位置へのパーティションキーのインデックスです。ワイドパーティションの場合、パーティション内の行へのインデックスも含まれる場合があります。 Summary.db
-
Index.db
ファイル内の(デフォルトでは)128番目のエントリごとのサンプリングです。 Filter.db
-
SSTable内のパーティションキーのブルームフィルターです。
CompressionInfo.db
-
Data.db
ファイル内の圧縮チャンクのオフセットと長さに関するメタデータです。 Statistics.db
-
タイムスタンプ、墓石、クラスタリングキー、コンパクション、修復、圧縮、TTLなどに関する情報を含む、SSTableに関するメタデータを格納します。
Digest.crc32
-
Data.db
ファイルのCRC-32ダイジェストです。 TOC.txt
-
SSTableのコンポーネントファイルのプレーンテキストリストです。
SAI*.db
-
ストレージアタッチドインデックスのインデックス情報です。テーブルでSAIが有効になっている場合のみ存在します。
|
Data.db
ファイル内では、行はパーティション別に整理されています。これらのパーティションはトークン順(つまり、デフォルトのパーティショナーであるMurmur3Partition
を使用する場合、パーティションキーのハッシュによる)でソートされています。パーティション内では、行はクラスタリングキーの順序で格納されます。
SSTableは、オプションでブロックベースの圧縮を使用して圧縮できます。
SSTableがmemtables
からディスクにフラッシュされるか、他のノードからストリーミングされると、Cassandraはコンパクションをトリガーして複数のSSTableを1つに結合します。新しいSSTableが書き込まれると、古いSSTableは削除できます。
SSTableバージョン
(BigFormat#BigVersionより)。
これまでに使用されているバージョン番号は次のとおりです。
バージョン0
-
b (0.7.0): sstableファイル名にバージョンを追加
-
c (0.7.0): ブルームフィルターコンポーネントが、文字列ではなく生のキーバイトでハッシュを計算
-
d (0.7.0): データコンポーネントの行サイズがintからlongに変更
-
e (0.7.0): データコンポーネントとインデックスコンポーネントに装飾されていないキーを格納
-
f (0.7.0): データコンポーネントのブルームフィルターの実装を切り替え
-
g (0.8): メタデータコンポーネントにフラッシュされたコンテキストを追跡
バージョン1
-
h (1.0): メタデータコンポーネントに最大クライアントタイムスタンプを追跡
-
hb (1.0.3): メタデータコンポーネントに圧縮率を記録
-
hc (1.0.4): メタデータコンポーネントにパーティショナーを記録
-
hd (1.0.10): maxtimestampに行の墓石を含める
-
he (1.1.3): メタデータコンポーネントに祖先の世代を含める
-
hf (1.1.6): 再生位置が1.1.5以降のミリ秒ベースのIDに対応することを示すマーカー(CASSANDRA-4782を参照)
-
ia (1.2.0)
-
列インデックスがインデックスファイルに昇格
-
墓石の削除時間の推定ヒストグラムを記録
-
ブルームフィルター(キーと列)がMurmur3にアップグレード
-
-
ib (1.2.1): メタデータコンポーネントに最小クライアントタイムスタンプを追跡
-
ic (1.2.5): 列名の行ごとのブルームフィルターを省略
バージョン2
-
ja (2.0.0)
-
スーパー列が複合体としてシリアル化される(実際にはフォーマットの変更はありません。これは主にスーパー列を期待するかどうかを知るためのマーカーです。ただし、この新しいフォーマットにスーパー列のストリーミングを許可すべきではないため、メジャーバージョンの増分が必要です)
-
SSTableメタデータに最大ローカル削除時間を追跡
-
メタデータコンポーネントにbloom_filter_fp_chanceを記録
-
データファイルからデータサイズと列数を削除(CASSANDRA-4180)
-
最大/最小列値を追跡(コンパレーターによる)
-
-
jb (2.0.1)
-
圧縮チェックサムにcrc32からadler32に変更
-
圧縮データをチェックサム
-
-
ka (2.1.0)
-
新しいStatistics.dbファイルフォーマット
-
インデックスサマリーはダウンサンプリングでき、サンプリングレベルは永続化される
-
非圧縮チェックサムをadler32に変更
-
レガシー(ローカルとリモート)カウンターシャードの存在を追跡
-
-
la (2.2.0): 新しいファイル名フォーマット
-
lb (2.2.7): コミットログの下限が含まれる
バージョン3
-
ma (3.0.0)
-
bfハッシュ順序の入れ替え
-
ネイティブに行を格納
-
-
mb (3.0.7, 3.7): コミットログの下限が含まれる
-
mc (3.0.8, 3.9): コミットログ間隔が含まれる
-
md (3.0.18, 3.11.4): sstable最小/最大クラスタリングを修正
-
me (3.0.25, 3.11.11): sstableの由来ノードのhostIdを追加
TrieインデックスベースのSSTableバージョン(BTI)
Cassandra 5.0では、Trieインデックス付きSSTableの新しいSSTableフォーマットであるBTIが導入されました。BTIフォーマットを使用するには、cassandra.yaml
で設定します。
sstable:
selected_format: bti
バージョンは(BtiFormat#BtiVersionより)。
実装ドキュメントについては、(BtiFormat.mdを参照してください。