Увеличение операций ввода-вывода после создания материализованного представления

#amazon-web-services #cassandra #provisioned-iops

#amazon-веб-сервисы #кассандра #подготовлено -iops

Вопрос:

Недавно мы перенесли вторичные индексы в Materialized view в Cassandra.Это было связано с тем, что индекс SASI падал из-за наших частых обновлений, а также с ограничением максимум пяти записей на индекс для индекса SASI sparse. Ранее было одно конкретное материализованное представление с нашей таблицей базовой таблицей:

 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-ядерном компьютере с 3 тыс. операций ввода-вывода. Все остальные узлы работали нормально со статистикой ~ 10 wa, за исключением этого конкретного узла, который был около ~ 70 wa в верхней части.

Проверяя AWS EBS dashboard, я увидел, что длина очереди EBS составляет около ~ 30, а задержки чтения и записи составляют около ~ 15 мс для этого узла, что является огромным. Шаблон состоит из равных частей чтения и записи. Записи представляют собой постоянный поток строк, содержащий около ~ 15 столбцов.

Это сбивает с толку, потому что для нескольких MV выдается только один select. Пропускная способность чтения не должна была увеличиваться. Я не могу понять, происходит ли это из-за добавления еще одного MV или какой-либо другой проблемы. Чего мне не хватает?

Комментарии:

1. Неясно, что делает ваша рабочая нагрузка. Выполняет ли он записи? Считывает? Оба? Сколько из каждого? Являются ли записи «интерактивными» (выполняются спорадически на основе запросов клиентов) или «пакетными» (какой-то клиентский код хочет записать кучу новых данных и выполняет это в цикле)?

2. @Nadavhar’El отредактировано для ясности