修士論文のために Cassandra の負荷テストを実行しています。実際のテストに適した値を決定するためのテストの 1 つは、各行に格納する必要がある測定値の数をテストしたものです (これを時間幅と呼びます)。
長い話を短くするために、結果は間違いなく私が期待したものではありません. 2 セットのテストを実行します。1 つは 1 行あたり 100,000 個の値を保存し、もう 1 つは 1 行あたり 10,000 個の値を保存します。これら 2 つの時間幅のそれぞれについて、異なる範囲で範囲クエリを発行しました。範囲とは、各クエリで要求される値の数を意味します。範囲は 3600 ～ 10000 です。
私が期待していたのは、多くの値 (50,000 と 100,000) を要求するクエリでは 100,000 の時間幅の方がパフォーマンスが高く、10,000 の時間幅では 10,000 の時間幅の方がパフォーマンスが良いということでした。ただし、以下の表でわかるように、すべてのケースで 100,000 時間幅の方が優れたパフォーマンスを示しました。これらのメトリックは OpsCenter に記録されました。
時間幅 100,000
平均操作数/秒: 18167.56 (範囲 3600) | 5097.61 (範囲 10000)
平均レイテンシ/秒 (ミリ秒) : 1.24 (範囲 3600) | 2.16 (範囲 10000)
時間幅 10,000
平均操作数/秒: 4186.35 (範囲 3600) | 587.78 (範囲 10000)
平均遅延/秒 (ミリ秒) : 4.85 (範囲 3600) | 48.63 (範囲 10000)
Cassandra に詳しい人が、これらの結果を解釈するのを手伝ってくれませんか? ちなみに、これらのテストを再度実行しているクラスターは、非常に強力なマシンを備えた 6 ノードのクラスターです。仕様を提供することはできますが、それほど関連性はないと思います。これら 2 つのテストのパフォーマンスに大きな違いがある理由に興味があります。テストでは、Hector を使用したカスタム プログラムを使用しています。クライアントの合計 60 インスタンスを実行し、Cassandra に対して可能な限り高速にクエリを実行します (何らかの制限はありません)。Cassandra 1.2 datastax エディションを使用しています。
EDIT：確かに、使用されているデータスキーマは私の悪いことに言及されているはずです。ここに情報があります。まず、センサー データ (タイムスタンプと値のペア) を保存します。各行の行キーは、行の識別子 (実際の測定値、シミュレーション 1、予測 1 など) と、この行の開始タイムスタンプです。したがって、行キーは次のようになります。この行内の各キーと値のペアで、タイムスタンプを行キーとして保存し、値部分の実際の測定値を保存します。
これらに加えて、同じ列ファミリー内に手動インデックス行も保持します。そのインデックス行に identfier_meta (simulation1_meta など) を格納し、この行の各キーと値のペアに、開始タイムスタンプを列キーとして格納し、それぞれの測定値を含む行キーを値として格納します。
そのため、読み取りごとに、最初に関連する行を特定し (インデックスをクエリして)、必要な実際のデータをフェッチします。セカンダリ インデックスについては、現時点では使用していません。さらに詳しい情報が必要な場合は、お気軽にお問い合わせください。