Недавно мы переместили вторичные индексы в представление «Материализация» в Cassandra. Это произошло из-за того, что индекс SASI разрушался из-за наших частых обновлений, также мы приближались к ограничению максимум пятью записями на индекс для разреженного индекса SASI.Ранее у нас был один конкретный материализованный вид с нашей таблицей Базовый стол:
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)
Мы решили добавить еще один материализованный вид
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)
Изменение прошло гладко в течение одного дня. После этого один из узлов начал работать случайным образом.Я говорю о средней загрузке 42 в 16-ядерном компьютере с 3k IOPS.Все остальные узлы работали нормально со статистикой ~ 10 ва, кроме этого одного конкретного узла, который был в верхней части около ~ 70 ва.
Проверка панели инструментов AWS EBS Я увидел, что длина очереди EBS составляет около ~ 30, а задержки чтения и записи составляют около ~ 15 мс для этого огромного узла.Шаблон является равными частями для чтения и записи.Записи являются постоянным потоком строк, имеющих около 15 столбцов.
Это сбивает с толку, поскольку для нескольких MV выдается только один выбор.Пропускная способность чтения не должна была увеличиться.Я не могу понять, происходит ли это из-за добавления еще одного MV или какой-то другой проблемы.Чего мне не хватает?