Сбой чтения в Кассандре - PullRequest
Новая
       15

Сбой чтения в Кассандре

0 голосов
/ 17 сентября 2018

У меня есть один узел настройки кассандры. Я получаю следующую ошибку в cassandra cqlsh при выполнении запроса select count(*) where к таблице:

Полный запрос: 

SELECT count(*) FROM casb.o365_activity_log_by_date WHERE
creation_time > '2018-09-16 00:00:00' and creation_time < '2018-09-16 23:59:59' 
ALLOW FILTERING;

Ответное сообщение: 

ReadFailure: Error from server: code=1300 [Replica(s) failed to execute read] 
message="Operation failed - received 0 responses and 1 failures" 
info={'failures': 1, 'received_responses': 0, 'required_responses': 1, 'consistency': 'ONE'}

Схема таблицы: 

CREATE TABLE IF NOT EXISTS casb.o365_activity_log_by_date (
    current_date date,
    creation_time timestamp,
    insertion_time timestamp,
    id text,
    client_ip text,
    workload text,
    operation text,
    user_id text,
    object_id text,
    activity_detail text,
    PRIMARY KEY ((current_date), insertion_time, id)
    )
) WITH CLUSTERING ORDER BY (insertion_time DESC, id DESC)
    AND bloom_filter_fp_chance = 0.01
    AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
    AND comment = ''
    AND compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 'max_threshold': '32', 'min_threshold': '4'}
    AND compression = {'chunk_length_in_kb': '64', 'class': 'org.apache.cassandra.io.compress.LZ4Compressor'}
    AND crc_check_chance = 1.0
    AND dclocal_read_repair_chance = 0.1
    AND default_time_to_live = 0
    AND gc_grace_seconds = 864000
    AND max_index_interval = 2048
    AND memtable_flush_period_in_ms = 0
    AND min_index_interval = 128
    AND read_repair_chance = 0.0
    AND speculative_retry = '99PERCENTILE';

У меня есть другое приложение на основе Python, которое читает из этой таблицы, и работа, похоже, застряла.

Логи:

В /var/log/cassandra/system.log

WARN  [ReadStage-2] 2018-09-16 22:06:48,803 ReadCommand.java:533 - Read 58545 live rows and 100001 tombstone cells for query SELECT * FROM casb.o365_activity_log_by_date WHERE creation_time > 2018-09-16 00:00Z AND creation_time < 2018-09-16 23:59Z LIMIT 100 (see tombstone_warn_threshold)
ERROR [ReadStage-2] 2018-09-16 22:06:48,804 StorageProxy.java:1906 - Scanned over 100001 tombstones during query 'SELECT * FROM casb.o365_activity_log_by_date WHERE creation_time > 2018-09-16 00:00Z AND creation_time < 2018-09-16 23:59Z LIMIT 100' (last scanned row partion key was ((2018-09-15), 2018-09-15 08:09Z, 72160ee4-5310-4941-af92-d27ced9c9ca8)); query aborted
WARN  [Native-Transport-Requests-1] 2018-09-16 22:07:02,937 SelectStatement.java:430 - Aggregation query used without partition key
WARN  [Native-Transport-Requests-1] 2018-09-16 22:07:45,946 SelectStatement.java:430 - Aggregation query used without partition key
WARN  [ReadStage-2] 2018-09-16 22:07:47,200 ReadCommand.java:533 - Read 58545 live rows and 100001 tombstone cells for query SELECT * FROM casb.o365_activity_log_by_date WHERE creation_time > 2018-09-16 00:00Z AND creation_time < 2018-09-16 23:59Z LIMIT 100 (see tombstone_warn_threshold)
ERROR [ReadStage-2] 2018-09-16 22:07:47,200 StorageProxy.java:1906 - Scanned over 100001 tombstones during query 'SELECT * FROM casb.o365_activity_log_by_date WHERE creation_time > 2018-09-16 00:00Z AND creation_time < 2018-09-16 23:59Z LIMIT 100' (last scanned row partion key was ((2018-09-15), 2018-09-15 08:09Z, 72160ee4-5310-4941-af92-d27ced9c9ca8)); query aborted
WARN  [Native-Transport-Requests-1] 2018-09-16 22:17:52,810 SelectStatement.java:430 - Aggregation query used without partition key
WARN  [ReadStage-2] 2018-09-16 22:17:54,513 ReadCommand.java:533 - Read 58545 live rows and 100001 tombstone cells for query SELECT * FROM casb.o365_activity_log_by_date WHERE creation_time > 2018-09-17 00:00Z AND creation_time < 2018-09-17 23:59Z LIMIT 100 (see tombstone_warn_threshold)
ERROR [ReadStage-2] 2018-09-16 22:17:54,513 StorageProxy.java:1906 - Scanned over 100001 tombstones during query 'SELECT * FROM casb.o365_activity_log_by_date WHERE creation_time > 2018-09-17 00:00Z AND creation_time < 2018-09-17 23:59Z LIMIT 100' (last scanned row partion key was ((2018-09-15), 2018-09-15 08:09Z, 72160ee4-5310-4941-af92-d27ced9c9ca8)); query aborted
WARN  [Native-Transport-Requests-3] 2018-09-16 22:18:09,541 SelectStatement.java:430 - Aggregation query used without partition key
INFO  [ScheduledTasks:1] 2018-09-16 22:18:17,143 NoSpamLogger.java:91 - Some operations were slow, details available at debug level (debug.log)
WARN  [Native-Transport-Requests-1] 2018-09-16 22:18:28,160 SelectStatement.java:430 - Aggregation query used without partition key
WARN  [Native-Transport-Requests-1] 2018-09-16 22:18:47,943 SelectStatement.java:430 - Aggregation query used without partition key
INFO  [CompactionExecutor:75] 2018-09-16 22:28:26,738 AutoSavingCache.java:394 - Saved KeyCache (48 items) in 250 ms
INFO  [IndexSummaryManager:1] 2018-09-16 22:29:27,992 IndexSummaryRedistribution.java:75 - Redistributing index summaries

Подробнее:

Я могу выполнить следующий запрос к той же таблице без ошибок:

SELECT * FROM casb.o365_activity_log_by_date;

Запустив вышеуказанный запрос, я вижу, что есть несколько столбцов с нулевыми значениями. Видя это и из журналов, я предполагаю, что это как-то связано с надгробиями в Кассандре.

Что мне здесь делать? Я посмотрел на этот ответ , так что я должен очистить надгробия? Я не уверен.

1 Ответ

0 голосов
/ 19 сентября 2018

Ваш запрос использует два анти-паттерна для Кассандры.

Сначала вы пытаетесь сосчитать все ключи во всей вашей базе данных. Это приведет к чтению всех ваших данных на диске в Cassandra, так как нет никаких индексов, как в RDBMS, которые могли бы быстро ответить на ваш вопрос. Будьте обеспокоены тем, что SELECT * FROM foo; или SELECT count(*) FROM bar; всегда будут медленными в Кассандре.

Во-вторых, вы проигнорировали предупреждение Кассандры о таких действиях - ALLOW FILTERING должно быть написано явно. Имейте в виду, что это предназначено для защиты вас от чтения всего кластера. Ваш оператор выбора фильтрует creation_time, который не является частью вашего первичного ключа.

Так что я бы поспорил, что вы выбрасываете таймауты во время выполнения вашего запроса. Взгляните на свой system.log от Cassandra, часто встречающийся в /var/log/cassandra/system.log при установке из пакетов.

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

...