Альтернатива пакетным операторам в Кассандре для операции Atom c, чтобы избежать влияния на производительность - PullRequest
Новая
       67

Альтернатива пакетным операторам в Кассандре для операции Atom c, чтобы избежать влияния на производительность

4 голосов
/ 23 февраля 2020

У нас есть приложение, которое использует Cassandra в качестве хранилища данных. Для удобства доступа одни и те же данные должны храниться в нескольких таблицах с разными ключами секционирования. Для хранения данных в нескольких таблицах используются BatchStatements. Причина использования пакетного оператора заключается в том, что данные записываются для всех или для всех.

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

Ссылки:

Причиной, по-видимому, является большая нагрузка на узлы-ординаторы и в свою очередь вызывают задержки. Была возможность увеличить write_request_timeout_in_ms в cassandra.yaml до более высокого значения, чем 5 с по умолчанию. Мы пытались это сделать, но запросы все равно не были выполнены. Поэтому мы обновили этот набор и теперь используем executeAsyn c. При этом исключения WriteTimeout полностью исчезли.

Но теперь возникает вопрос - как мы справляемся с атомарностью? Ниже приведен обновленный код для использования executeAsyn c. Является ли использование executeAsyn c правильной альтернативой использованию пакетных операторов? Есть ли способ обработки откатов в блоке исключений? 

try {
    for (ListenableFuture<ResultSet> futureItem : futureItems) {
        futureItem.get();
    }
} catch (Exception e) {
    // need to handle rollback ?
}

Ответы [ 2 ]

0 голосов
/ 03 марта 2020

Нет SQL Базы данных, специально созданные для высокой доступности и допуска разделов (AP of CAP), не созданы для обеспечения высокой ссылочной целостности. Скорее они предназначены для чтения и записи с высокой пропускной способностью и низкой задержкой. Сама Кассандра не имеет понятия ссылочной целостности в таблицах.

Пакетные вставки и LWT хороши, пока они не используются в масштабе. Для вашего случая использования вам необходимо пересмотреть, как вы собираетесь использовать Cassandra и как вы можете спроектировать свои конвейеры обработки данных, чтобы обеспечить упругую запись во все таблицы.

Подумайте о том, чтобы отделить все эти записи таблицы и сделать их параллельными эластичные конвейеры, использующие что-то вроде kafka, а затем сохраняющие данные в таблицах Cassandra. Вы можете создать ровно один раз конвейеры данных и, следовательно, обеспечить ссылочную целостность данных. Кассандра поддерживает Kafka Connector

https://www.datastax.com/blog/2018/12/introducing-datastax-apache-kafkatm-connector

0 голосов
/ 28 февраля 2020

В конечном счете, то, что вы просите, не существует - по замыслу.

  • Для атомарности записей вы нашли решение с пакетной обработкой. Для альтернативной атомарности записей, в конечном счете, ее нет.

  • Для жесткой согласованности данных - которая включает в себя запись и чтение, вы можете установить уровни согласованности записи и чтения, чтобы обеспечить жесткую согласованность (W C: Local_Quorum, R C: Local_Quorum)

Многие новые пользователи / команды разработчиков часто пытаются навязать правила реляционного типа на Cassandra, но со временем они используют Cassandra. обычно приносит веру в его конструкцию, позволяющую настраиваемую согласованность, сокращенное время простоя и масштабируемость.

...