Cassandra timeout cqlsh запрашивает большой (ish) объем данных

Я выполняю студенческий проект, связанный с построением и запросом кластера данных Cassandra.

Когда загрузка моего кластера была небольшой (около 30 ГБ), мои запросы выполнялись без проблем, но теперь, когда она немного больше (1/2 ТБ), мои запросы истекают по тайм-ауту.

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

request_timeout_in_ms (по умолчанию: 10000) Тайм-аут по умолчанию для других, разных операций.

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

Моя цель для генерации данных - 2 ТБ. Как мне запросить этот большой объем без таймаутов?

запросы:

SELECT  huntpilotdn 
FROM    project.t1 
WHERE   (currentroutingreason, orignodeid, origspan,  
        origvideocap_bandwidth, datetimeorigination)
        > (1,1,1,1,1)
AND      (currentroutingreason, orignodeid, origspan,    
         origvideocap_bandwidth, datetimeorigination)
         < (1000,1000,1000,1000,1000)
LIMIT 10000
ALLOW FILTERING;

SELECT  destcause_location, destipaddr
FROM    project.t2
WHERE   datetimeorigination = 110
AND     num >= 11612484378506
AND     num <= 45880092667983
LIMIT 10000;


SELECT  origdevicename, duration
FROM    project.t3
WHERE   destdevicename IN ('a','f', 'g')
LIMIT 10000
ALLOW FILTERING;

У меня есть демонстрационное пространство ключей с теми же схемами, но с гораздо меньшим размером данных (~ 10 ГБ), и эти запросы отлично работают в этом пространстве ключей.

Все запрашиваемые таблицы содержат миллионы строк и около 30 столбцов в каждой строке.


person slmyers    schedule 03.04.2015    source источник
comment
Можете ли вы опубликовать пример вашего запроса?   -  person Aaron    schedule 03.04.2015


Ответы (4)


Я собираюсь предположить, что вы также используете вторичные индексы. Вы из первых рук узнаете, почему запросы вторичного индекса и запросы РАЗРЕШЕНИЯ ФИЛЬТРАЦИИ не рекомендуются ... потому что этот тип шаблонов проектирования не масштабируется для больших наборов данных. Перестройте свою модель с помощью таблиц запросов, которые поддерживают поиск по первичному ключу, так как Cassandra предназначена для работы именно так.

Изменить

«Ограниченные переменные - это ключи кластера».

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

Изменить 20190731

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

Поскольку этот вопрос продолжает увеличивать количество просмотров страниц, я чувствую себя обязанным обратиться к аспекту увеличения тайм-аута. Я не собираюсь голосовать против чьих-либо ответов, поскольку с точки зрения голосования это выглядело бы как "кислый виноград". Но я могу сформулировать почему, мне кажется, это ничего не решает.

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

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

Во-вторых, посмотрите, что на самом деле пытается сделать OP:

Моя цель для генерации данных - 2 ТБ. Как мне запросить этот большой объем без таймаутов?

Эти ограничения времени ожидания запроса предназначены для защиты вашего кластера. Если бы вы запустили сканирование всей таблицы (что означает сканирование всего кластера до Cassandra) через 2 ТБ данных, то порог тайм-аута был бы довольно большим. Фактически, если вам удастся найти правильный номер, позволяющий это сделать, ваш узел координатора опрокинется LONG до того, как большая часть данных будет собрана в результирующий набор.

Таким образом, увеличение тайм-аутов запросов:

  1. Создает видимость «помощи», заставляя Cassandra работать против того, как она была спроектирована.

  2. Потенциально может привести к сбою узла, что поставит под угрозу стабильность базового кластера.

Таким образом, увеличение тайм-аутов запросов - ужасная, УЖАСНАЯ ИДЕЯ.

person Aaron    schedule 03.04.2015
comment
Я вообще не использую secondary indexes. Ограниченные переменные: cluster keys. Когда я устанавливаю limit ‹5, запрос завершается. Есть ли у вас еще какие-либо мысли о том, что я могу сделать, чтобы запрос был завершен с ограничениями больше 5? edit: я использую cqlsh для запроса моей базы данных. Как вы думаете, мне следует написать приложение для обработки запросов? - person slmyers; 03.04.2015
comment
@slmyers Ограниченные переменные являются ключами кластера. Верно ... это означает, что они не являются ключами разделов. Не ограничивая ключ (ключи) раздела, вы в основном просматриваете всю таблицу, поскольку ключи кластеризации только кластеризуют данные в пределах своего ключа раздела. - person Aaron; 04.04.2015

Если вы используете Datastax cqlsh, вы можете указать время ожидания клиента в секундах в качестве аргумента командной строки. По умолчанию 10.

$ cqlsh --request-timeout=3600

Документация по Datastax

person gcarvelli    schedule 14.10.2016
comment
Даже с этим параметром запрос count(*), похоже, не работает в read_request_timeout_in_ms, определенном в cassandra.yml, независимо от параметров cli - person xref; 04.06.2019
comment
Это не относится к запросам SELECT, см. документы. datastax.com/en/dse/5.1/cql/cql/cql_reference/ - person adinas; 21.02.2021

Чтобы изменить ограничение времени ожидания клиента в Apache Cassandra, есть два метода:

Техника 1: Это хорошая техника:

1. Navigate to the following hidden directory under the home folder: (Create the hidden directory if not available)

    $ pwd
    ~/.cassandra


2. Modify the file cqlshrc in it to an appropriate time in seconds: (Create the file if not available)

    Original Setting:

        $ more cqlshrc
        [connection]
        client_timeout = 10
        # Can also be set to None to disable:
        # client_timeout = None
        $

    New Setting:

        $ vi cqlshrc
        $ more cqlshrc
        [connection]
        client_timeout = 3600
        # Can also be set to None to disable:
        # client_timeout = None
        $

    Note: Here time is in seconds. Since, we wanted to increase the timeout to one hour. Hence, we have set it to 3600 seconds.

Метод 2: Это не лучший метод, поскольку вы меняете настройку в самой клиентской программе (cqlsh). Примечание. Если вы уже вносили изменения, используя метод 1, тогда он переопределит время, указанное с помощью метода 2. Поскольку настройки профиля имеют наивысший приоритет.

1. Navigate to the path where cqlsh program is located. This you can find using the which command:

    $ which cqlsh
    /opt/apache-cassandra-2.1.9/bin/cqlsh
    $ pwd
    /opt/apache-cassandra-2.1.9/bin
    $ ls -lrt cqlsh
    -rwxr-xr-x 1 abc abc 93002 Nov  5 12:54 cqlsh


2. Open the program cqlsh and modify the time specified using the client_timeout variable. Note that time is specified in seconds.
$ vi cqlsh

In __init__ function:
    def __init__(self, hostname, port, color=False,
                 username=None, password=None, encoding=None, stdin=None, tty=True,
                 completekey=DEFAULT_COMPLETEKEY, use_conn=None,
                 cqlver=DEFAULT_CQLVER, keyspace=None,
                 tracing_enabled=False, expand_enabled=False,
                 display_time_format=DEFAULT_TIME_FORMAT,
                 display_float_precision=DEFAULT_FLOAT_PRECISION,
                 max_trace_wait=DEFAULT_MAX_TRACE_WAIT,
                 ssl=False,
                 single_statement=None,
                 client_timeout=10,
                 connect_timeout=DEFAULT_CONNECT_TIMEOUT_SECONDS):

In options.client_timeout setting:
    options.client_timeout = option_with_default(configs.get, 'connection', 'client_timeout', '10')

You can modify at both these places. The second line picks up client_timeout information from the cqlshrc file.
person Sashank Bhogu    schedule 05.11.2015

  1. Увеличьте read_request_timeout_in_sec в файле cassandra.yaml

  2. Измените программу cqlsh.py и измените значение переменных вместо изменения функции. DEFAULT_REQUEST_TIMEOUT_SECONDS = 100 DEFAULT_CONNECT_TIMEOUT_SECONDS = 100

Это точно работает

person Nithin GB    schedule 10.02.2020