2
9ノードのcassandraクラスタを作成しました。それぞれに4Coresと16G RAMが装備されています。私たちは28桁の15-25百万レコードを書いています。Cassandraマテリアライズド・ビューのパフォーマンスに関する問題
私たちが設計したデータモデルは以下の通りです（私は列の名前を変更し、簡略化のために実際のスキーマを短縮しました）。
CREATE TABLE main_table(
col1 ... col28,
PRIMARY KEY((col1,col2),col_date,col_with_some_seq_number))
WITH CLUSTERING ORDER BY (col_date DESC,col_with_some_seq_number desc) AND default_time_to_live = 5270400;
CREATE MATERIALIZED VIEW mv_for_main_table AS
SELECT [col1.. col11],
FROM main_table
WHERE col1 IS NOT NULL AND col2 IS NOT NULL AND col_date IS NOT NULL AND col_with_some_seq_number IS NOT NULL
PRIMARY KEY ((col1),col2, col_date, col_with_some_seq_number)
WITH CLUSTERING ORDER BY (col_date DESC, col_with_some_seq_number DESC, col2 DESC);
だけ にクラスタリングキーにパーティションキーのいずれかを移動する、そのマテリアライズド・ビュー。
私たちはsparkからデータをロードしており、キャッサンドラ関連の設定は変更していません。
約150万レコードを摂取した後、摂取が失敗し始め、各ノードは、突然変異の障害の多くを与えています。
マテリアライズド・ビューのパフォーマンスに問題はありますか。または私が使用した定義は効率的ではありません。
同時書き込み、スループットMBの削減など、構成の変更をほとんど試しました。すべての試行の後、我々はマテリアライズドビューをドロップし、すべてのものがうまく動作し始めた。
我々は、ビューを含めることをマテリア後にのみ書き込みが巨大なマージンだけ遅くなっていると変異がドロップなっていると結論するのに十分なテストを行っています。
私たちは、代わりに上記の構成のためのマテリアライズド・ビューの別々のテーブルを持っていることを計画している、しかし、私は、我々が使用しているマテリアライズド・ビューまたはデータモデルとの間違いがあるかどうかを知りたいです。
の画面キャプチャを投稿してください。？マテリアライズド・ビューは、毎日2,500万行をメイン・テーブルに取り込むシナリオに適していますか？私たちがMVを持っていれば、パフォーマンスは大幅に低下します。スパークジョブの出力行は、MVなしで約20Kであり、MVでは1秒あたり約1Kでさえありません – Srini
おそらく、パフォーマンスを誇張していますが、摂取障害のより重要な側面は、突然変異と突然変異の段階がnodetool tpstats指数関数的に増加している。 MVがなければ、保留中のステージは決してそこにはなく、もしあれば、2または3に制限され、次の秒にクリアされます。 – Srini