Тайм-аут Cassandra во время запроса чтения при согласованности ОДИН (требуется 1 ответ, но ответила только 0 реплика)

Обычно, когда вы получаете ошибку тайм-аута, это означает, что вы пытаетесь сделать что-то, что плохо масштабируется в Cassandra. Часто исправление заключается в изменении вашей схемы.

Я предлагаю вам контролировать узлы во время выполнения вашего запроса, чтобы увидеть, можете ли вы определить проблемную область. Например, вы можете запустить «watch -n 1 nodetool tpstats», чтобы увидеть, выполняется ли резервное копирование или отбрасывание элементов в каких-либо очередях. См. Другие предложения по мониторингу здесь.

Одна вещь, которая может быть отключена в вашей конфигурации, - это то, что вы говорите, что у вас пять узлов Cassandra, но только 3 искровых воркера (или вы говорите, что у вас есть три искровых воркера на каждом узле Cassandra?). Вам понадобится хотя бы один искровый воркер. каждый узел Cassandra, так что загрузка данных в Spark выполняется локально на каждом узле, а не по сети.

Трудно сказать что-то большее, не видя схемы и выполняемого запроса. Вы читаете с одного раздела? Я начал получать ошибки тайм-аута около 300 000 строк при чтении из одного раздела. См. Вопрос здесь. Единственный обходной путь, который я нашел до сих пор, - это использовать хэш на стороне клиента в моем ключе раздела, чтобы разбить разделы на более мелкие фрагменты примерно по 100 тыс. Строк. До сих пор я не нашел способа сказать Кассандре, что не следует истекать тайм-аут для запроса, который, как я ожидаю, займет много времени.

Не думайте, что конфигурация является основной причиной, а проблема с моделью данных.

Было бы здорово увидеть структуру таблицы section_ks.encounters.

Рекомендуется тщательно подумать о том, какие конкретные запросы должны выполняться, прежде чем создавать структуру таблиц.

Насколько я понимаю, эти два запроса предполагают разную структуру section_ks.encounters, чтобы выполнять их с хорошей производительностью.

Давайте рассмотрим каждый предоставленный запрос и попробуем создать таблицы:

Первый:

ВЫБЕРИТЕ meet_uuid, meet_start_date FROM section_ks.encounters WHERE Patient_id = '1234' И meet_start_date> = '"+ formatted_documentation_date +"' РАЗРЕШИТЬ ФИЛЬТРАЦИЮ;

• Во-первых, если Кассандра вынуждает вас добавить РАЗРЕШЕННУЮ ФИЛЬТРАЦИЮ, это симхтом неоптимальной структуры запроса или таблицы.
• Второй момент. Основной ключ. Прекрасное объяснение что такое первичные ключи в Cassandra. Данный запрос будет работать быстро и без обязательного оператора ALLOW FILTERING, если Patient_id столбец и столбец begin_start_date образуют составной первичный ключ. Перечисление столбцов внутри оператора PRIMARY KEY () должно соответствовать порядку фильтрации в вашем запросе.
• Почему РАЗРЕШИТЬ ОБЯЗАТЕЛЬНУЮ ФИЛЬТРАЦИЮ в исходном запросе? По ключу раздела Кассандра знает, на каком узле расположены данные. В случае, когда столбец Patient_id не является ключом раздела, Cassandra должна была просканировать все 5 узлов для поиска запрошенного пациента. Когда у нас много данных на узлах, такое полное сканирование обычно не выполняется по таймауту.

Вот пример структуры таблицы, которая эффективно соответствует заданному запросу:

create table section_ks.encounters(
    patient_id bigint, 
    encounter_start_date timestamp, 
    encounter_uuid text,
    some_other_non_unique_column text,
    PRIMARY KEY (patient_id, encounter_start_date)
);

• Столбец Patient_id будет "ключом раздела". Отвечает за распространение данных по узлам Cassandra. Проще говоря (без функции репликации): разные диапазоны пациентов будут храниться на разных узлах.
• Столбец begin_start_date будет «ключом кластеризации», ответственным за сортировку данных внутри раздела.

РАЗРЕШИТЬ ФИЛЬТРАЦИЮ теперь можно убрать из запроса:

SELECT encounter_uuid, encounter_start_date 
FROM section_ks.encounters 
WHERE patient_id = '1234' AND encounter_start_date >= '2017-08-19';

Второй запрос:

ОБНОВЛЕНИЕ section_ks.encounters УСТАНОВИТЬ testproblem_uuid_set = testproblem_uuid_set + {'1256'} ГДЕ meet_uuid = 'abcd345';

Структура таблицы должна выглядеть примерно так:

create table section_ks.encounters(
    encounter_uuid text, -- partition key
    patient_id bigint,
    testproblem_uuid_set text, 
    some_other_non_unique_column text,
    PRIMARY KEY (encounter_uuid)
);

Если мы определенно хотим сделать быструю фильтрацию только по meet_uuid, ее следует определить как ключ раздела.

Хорошие статьи о проектировании эффективной модели данных:

• https://www.datastax.com/dev/blog/basic-rules-of-cassandra-data-modeling
• https://opencredo.com/cassandra-data-modelling-patterns/