Тайм-аут запроса Cassandra

Мы получаем данные примерно с 20-25 датчиков промышленных двигателей, и данные хранятся в базе данных Cassandra. В настоящее время Cassandra работает в одном узле.

Ниже представлена ​​структура таблицы

CREATE TABLE cisonpremdemo.machine_data (
    id uuid PRIMARY KEY,
    data_temperature bigint,
    data_current bigint,
    data_timestamp timestamp,
    deviceid text,
    
) WITH bloom_filter_fp_chance = 0.01
    AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
    AND default_time_to_live = 7884000
    AND gc_grace_seconds = 100;
	
CREATE INDEX deviceid_idx ON db.machine_data (deviceid);
CREATE INDEX data_timestamp_idx ON db.machine_data (data_timestamp);

Данные собираются в этой таблице в течение нескольких месяцев, например, каждые 5 секунд в течение почти 24 часов, так что объем данных довольно большой.

Я пытаюсь выполнить запрос на основе диапазона дат с использованием java и dotnet, и в обоих случаях я получаю ошибки тайм-аута (сбой Cassandra во время запроса на чтение при согласованности LocalOne (0 реплик ответили, более 1 требуется))

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

1) увеличен тайм-аут запроса. 2) уменьшено значение gc_grace_seconds до 100 (временно), чтобы устранить любые надгробия.

Запрос использован

SELECT data_temperature AS "DATA_TEMP",data_current AS "DATA_CURRENT" FROM machine_data 
WHERE DATA_TIMESTAMP>=1517402474699 
AND DATA_TIMESTAMP<=1517402774699 
AND DEVICEID='BP_100' ALLOW FILTERING;

Не уверен, что структура таблицы (первичный ключ) выбрана неправильно. должно быть и deviceid, и timestamp ??


cassandra cassandra-jdbc
person Ramesh Kumar R    schedule 31.01.2018    source источник
comment
Моделирование данных Cassandra предлагает одну таблицу для каждого запроса. В вашем случае я бы определенно создал другую таблицу с deviceid и timestamp в качестве составных ключей. Кроме того, воздержитесь от использования РАЗРЕШЕНИЯ ФИЛЬТРАЦИИ, это большой удар по производительности.   -  person Bigby    schedule 31.01.2018

Ответы (1)


arrow_upward
2
arrow_downward

Вторичные индексы почти наверняка выйдут из строя. Они должны иметь мощность "не слишком низкую, не слишком высокую" (которая зависит от количества узлов в кольце). Это очень сложно сделать правильно, и вам действительно следует просто избегать его использования, если в нем нет сильной необходимости и данные не подходят (согласованность между таблицами невозможна с денормализованной таблицей).

Еще одна вещь, которую вы никогда не должны использовать, - это allow filtering, она предназначена только для отладки / разработки и больших искровых заданий, которые читают весь набор данных. Это ужасно дорого и почти всегда приводит к длительным перерывам в работе.

Вместо этого вы должны создавать новые таблицы, а также разбивать их по времени, чтобы разделы не становились слишком большими. т.е.

CREATE TABLE cisonpremdemo.machine_data_by_time (
    id uuid PRIMARY KEY,
    data_temperature bigint,
    data_current bigint,
    data_timestamp timestamp,
    yymm text,
    deviceid text,
    PRIMARY KEY ((deviceid, yymm), data_timestamp)
) WITH CLUSTERING ORDER BY (data_timestamp DESC);

Когда вы вставляете свои данные, пишите в оба. По сути, вы должны создать таблицу для каждого типа вашего запроса, чтобы данные были в нужном вам формате. Не моделируйте свою таблицу в зависимости от того, как выглядят данные. Если вам не нужен прямой поиск сообщений с помощью uuid, вообще не создавайте machine_data таблицу, как указано выше, поскольку это не то, как вы ее запрашиваете.

person Chris Lohfink    schedule 31.01.2018