web-dev-qa-db-ja.com

Cassandra timeout cqlsh query large（ish）amount of data

Cassandra=データクラスターの構築とクエリを含む学生プロジェクトを行っています。

クラスターの負荷が軽い（約30GB）場合、クエリは問題なく実行されましたが、今ではかなり大きく（1/2TB）クエリがタイムアウトしています。

この問題が発生する可能性があると考えたため、テストデータの生成と読み込みを開始する前に、cassandra.yamlファイルでこの値を変更しました。

request_timeout_in_ms（デフォルト：10000）その他のさまざまな操作のデフォルトのタイムアウト。

ただし、その値を1000000のように変更すると、cassandra=起動時にハングしたように見えますが、それは職場での大きなタイムアウトである可能性があります。

データ生成の私の目標は2TBです。タイムアウトに陥ることなく、その大きなスペースをクエリするにはどうすればよいですか？

クエリ：

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;

同じスキーマのデモキースペースがありますが、データサイズがはるかに小さく（〜10GB）、これらのクエリはそのキースペースで正常に実行されます。

照会されるこれらすべてのテーブルには、数百万の行と各行に約30の列があります。

cassandratimeoutcqlsh
18
slmyers

セカンダリインデックスも使用していると思います。セカンダリインデックスクエリとALLOW FILTERINGクエリが推奨されない理由を直接見つけています。これらのタイプの設計パターンは、大規模なデータセットに対応できないためです。 Cassandraは機能するように設計されているため、プライマリキールックアップをサポートするクエリテーブルを使用してモデルを再構築します。

編集

「制約される変数はクラスターキーです。」

正しい...つまり、パーティションキーではありません。クラスタリングキーはパーティションキー内でのみ有効（クラスターデータ）であるため、パーティションキーを制約することなく、基本的にテーブル全体をスキャンします。

編集20190731

したがって、「受け入れられた」答えがありますが、ここにはさらに3つの答えがあることがわかります。それらはすべてクエリタイムアウトの変更に重点を置いており、そのうち2つは私の回答よりもかなり高い（1つはかなり）。

この質問がページビューを増やし続けているので、タイムアウトを増やすという側面に対処する必要があります。今、私は投票の観点から「酸っぱいブドウ」のように見えるので、誰かの答えをdownvoteしようとはしていません。しかし、私は明確にすることができますなぜそれは何も解決しないと感じています。

まず、クエリがタイムアウトするという事実は、symptomです。主な問題ではありません。したがって、クエリタイムアウトを増やすことは、主な問題を曖昧にするだけで、ただの解決策です。

もちろん、主な問題は、OPが基になるデータモデルと一致しないクエリをクラスターに強制的にサポートさせようとしていることです。この問題が無視され、回避策の対象となる限り（直接対処されるのではなく）、この問題は引き続き現れます。

次に、OPが実際に何をしようとしているのかを見てください。

データ生成の私の目標は2TBです。タイムアウトに陥ることなく、その大きなスペースをクエリするにはどうすればよいですか？

これらのクエリタイムアウト制限は、クラスターをprotectするためのものです。 2TBのデータを介してフルテーブルスキャン（Cassandraへのフルクラスタースキャンを意味する）を実行すると、そのタイムアウトしきい値は非常に大きくなります。実際、それを可能にする適切な番号を見つけることができた場合、コーディネーターノードは[〜＃〜] long [〜＃〜]を転倒してから、ほとんどのデータが結果に組み込まれます。セット。

要約すると、クエリタイムアウトの増加：

  1. forcingCassandra=それが設計された方法に対して動作するようにすることによって、「助け」の外観を与えます。

  2. 潜在的にノードをクラッシュさせ、基になるクラスターの安定性を危険にさらす可能性があります。

したがって、クエリのタイムアウトを増やすのはひどいですTERRIBLE IDEA。

6
Aaron

Datastax cqlshを使用している場合は、コマンドライン引数としてクライアントタイムアウト秒を指定できます。デフォルトは10。

$ cqlsh --request-timeout=3600

Datastax Documentation

49
gcarvelli

Apache Cassandraでクライアントのタイムアウト制限を変更するには、2つの手法があります。

テクニック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.
8
Sashank Bhogu