select count (*) запускает проблемы с таймаутом в Cassandra

Question

select count (*) запускает проблемы с таймаутом в Cassandra

Возможно, это глупый вопрос, но я не могу определить размер стола в Кассандре.

Вот что я попробовал:

select count(*) from articles;

Это прекрасно работает, если таблица мала, но как только она заполняется, я всегда сталкиваюсь с проблемами таймаута:

Cqlsh:

OperationTimedOut: errors= {}, last_host=127.0.0.1

DBeaver:

запуск 1: 225 000 (7477 МС)

запуск 2: 233 637 (8265 МС)

Бег 3: 216,595 (7269 ms)

Я предполагаю, что он попадает в некоторый тайм-аут и просто прерывается. Фактическое число записей в таблице, вероятно, намного выше.

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

Есть ли способ надежно подсчитать количество записей в таблице Кассандры?

Я использую Кассандру 2.1.13.

581 7

cassandra cql

7 ответов:

Comments

Ничего не найдено.

Oleksandr Petrenko · Accepted Answer · 2016-04-21 14:04:58

Насколько я вижу, ваша проблема связана с таймаутом cqlsh : OperationTimedOut: errors= {}, last_host=127.0.0.1

Вы можете просто увеличить его с помощью опций:
 --connect-timeout=CONNECT_TIMEOUT
                       Specify the connection timeout in seconds (default: 5
                       seconds).
 --request-timeout=REQUEST_TIMEOUT
                       Specify the default request timeout in seconds
                       (default: 10 seconds).

doanduyhai · Accepted Answer · 2016-04-20 16:26:21

Есть ли способ надежно подсчитать количество записей в таблице Кассандры?

Простой ответ - Нет . Это не ограничениеКассандры , а трудная задача дляраспределенных систем надежно рассчитывать уникальные элементы.

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

Philipp Claßen · Accepted Answer · 2016-04-20 16:21:50

Вот мой текущий обходной путь:
COPY articles TO '/dev/null';
...
3568068 rows exported to 1 files in 2 minutes and 16.606 seconds.
Фон: Кассандра поддерживает экспорт таблицы в текстовый файл , например:
COPY articles TO '/tmp/data.csv';
Output: 3568068 rows exported to 1 files in 2 minutes and 25.559 seconds
, что также соответствует количеству строк в сгенерированном файле:
$ wc -l /tmp/data.csv
3568068

Kat · Accepted Answer · 2017-06-10 03:34:24

Это хорошая утилита для подсчета строк, которая позволяет избежать проблем с таймаутом, возникающих при запуске большого COUNT(*) в Cassandra:

Https://github.com/brianmhess/cassandra-count

darky · Accepted Answer · 2017-06-23 17:27:51

Вы можете использовать Cassandra nodetool:

nodetool tablestats <keyspaceName>.<tableName>

И получить в ответ:

количество ключей (оценка): count

Citrullin · Accepted Answer · 2017-06-10 03:32:08

Причина проста:

Когда вы используете:
SELECT count(*) FROM articles;
Он оказывает такое же воздействие на базу данных, как и:
SELECT * FROM articles;
Вы должны выполнить запрос по всем вашим узлам. Кассандра просто попадает в тайм-аут.

Вы можете изменить тайм-аут, но это не очень хорошее решение. (На один раз это нормально, но не используйте его в своих регулярных запросах.)

Есть лучшее решение: заставьте вашего клиента считать ваши строки. Вы можете создать приложение java, где вы подсчитываете свои строки, когда вставляете их, и вставить результат, используя столбец счетчика в таблице Кассандры.

Shubham · Accepted Answer · 2018-08-23 14:56:50

Вы можете использовать copy, чтобы избежать Cassandra timeout обычно происходит на count (*)

Используйте этот Баш

cqlsh -e "copy keyspace.table_name (first_partition_key_name) to '/dev/null'" | sed -n 5p | sed 's/ .*//'