0

最近、セカンダリ インデックスを Cassandra のマテリアライズド ビューに移動しました。これは、頻繁な更新のために SASI インデックスが崩壊していたためでした。また、SASI スパース インデックスのインデックスあたり最大 5 エントリの制限に移行していました。前に、私たちのテーブルで特定のマテリアライズド ビューが 1 つありました。ベース テーブル:

CREATE TABLE IF NOT EXISTS chats (
    user_id bigint,
    peer_id bigint,
    msg_id text,
    text text,
    timestamp timestamp,
    updated_at timestamp,
    PRIMARY KEY (user_id, peer_id, msg_id)
) WITH CLUSTERING ORDER BY (msg_id ASC)

および具体化されたビュー:

CREATE MATERIALIZED VIEW IF NOT EXISTS chats_by_updated AS
    SELECT * FROM chats
    WHERE user_id IS NOT NULL AND updated_at IS NOT NULL
    PRIMARY KEY (user_id, updated_at, peer_id, msg_id)
    WITH CLUSTERING ORDER BY (updated_at ASC, peer_id ASC, msg_id ASC)

マテリアライズド ビューをもう 1 つ追加することにしました

 CREATE MATERIALIZED VIEW IF NOT EXISTS chats_by_updated AS
    SELECT * FROM chats
    WHERE user_id IS NOT NULL AND updated_at IS NOT NULL
    PRIMARY KEY (user_id, peer_id, updated_at, msg_id)
    WITH CLUSTERING ORDER BY (updated_at ASC, peer_id ASC, msg_id ASC)

変更は 1 日スムーズに機能し、その後、ノードの 1 つがランダムに動作し始めました。3k IOPS の 16 コア マシンで 42 負荷平均について話しています。他のすべてのノードは、約 10 WA の統計で正常に動作していましたが、この特定のノードは約 70 WA でした。

AWS EBS ダッシュボードを確認すると、この巨大なノードの EBS キューの長さは約 30 ミリ秒、読み取りと書き込みのレイテンシーは約 15 ミリ秒であることがわかりました。パターンは、読み取りと書き込みが等しい部分です。書き込みは、約 15 列の行の一定のストリームです。

複数の MV に対して 1 つの選択しか発行されないため、これは混乱を招きます。読み取りスループットは増加していないはずです。これが MV をもう 1 つ追加したためなのか、それとも他の問題によるものなのか、私にはわかりません。何が欠けていますか？

4

0 に答える 0