はじめに
この記事は何？
Apache Cassandraのテーブル数の上限に関する「覚書」
DataStax社による解説
はじめに、以下の記事から、傍線を引きながら自由に翻訳します。
Cassandra 内の多数のテーブルは、クラスターのパフォーマンスに直接影響を与える可能性があります。通常、クラスター内でアクティブに使用されるテーブルは 200 個以下にする必要があります。アクティブに使用されているテーブルが 500 個ある場合は、非効率性や障害が発生する可能性が高いため、クラスターが機能していても障害レベルとみなされます。
この問題は、すべてのテーブルがメタデータにほぼ1 MBメモリを使用するために発生します。動作するテーブルごとに、memtable 表現が割り当てられます。大量のデータを含むテーブルでは、ブルーム フィルターやその他の補助データ構造により多くのデータが保存されるため、メモリへの負荷も増大します。また、各キースペースにより、JVM メモリに追加のオーバーヘッドが発生します。これらすべての要因が Cassandra のパフォーマンスに影響を与えます。次のベンチマークは、テーブル数の増加に伴ってスループットが大幅に低下することを示しています。
関連する設定
cassandra.yaml
SLAを担保するための仕組みとして Guardrails があり、テーブル数上限の設定も可能になっています。
guardrails [Default: disabled]
テーブル数上限の設定（設定しないと上限はなし）
tables_warn_threshold [Default: -1 (disabled)]
警告が出る閾値の設定
tables_failure_threshold [Default: -1 (disabled)]
テーブルの CREATE を失敗させる閾値の設定
テーブル数上限の存在することが正当化されるべき背景に関する理解
以下は、Cassandraに限った話ではなく、一般的な考え方として。
分散データベースにおいては、複数のノード間でメタデータを共有する必要があります。
このメタデータは「常に」更新状況が監視される必要があります。
「常に」ネットワーク上を流れ続けるデータの制御を考えた場合、その単純増加要因となる管理対象（テーブル）の数に上限が存在するのは自然なことであり、そのことを意識した管理が必要になることになります。