2017-06-22 12 views
1

私はprestoを使ってCassandraの記録を検索していますが、結果には約8分かかります。応答時間を改善する必要があります。Presto Cassandra遅い遅い

プレスト構成下記

coordinator=true 
    node-scheduler.include-coordinator=false 
    http-server.http.port=8080 
    query.max-memory=5GB 
    query.max-memory-per-node=3GB 
    discovery-server.enabled=true 
    discovery.uri=http://URL:8080 
    task.max-worker-threads=10 
    task.concurrency=32 

    Worker : 4 

    coordinator=false 
    http-server.http.port=8080 
    query.max-memory=5GB 
    query.max-memory-per-node=2GB 
    discovery.uri=http://URL:8080 
    task.max-worker-threads=16 
    task.concurrency=32 

    Cassandra : 4 NODE 

フラグメント2 コスト:CPUの1.98メートル、入力:17833912行(1.49ギガバイト)、出力:13089502行(1.31ギガバイト)
ScanFilterProject [表=カサンドラ:カサンドラ:rasapp:raslog、originalConstraint =(( "bucketid" = CAST( '2017062113' コスト:96.12パーセント、入力:23169736行(22.10メガバイト)、出力:17833912行(1.49ギガバイト)、濾過:23.03パーセント

どのようにpretoの応答時間を改善するには、私はまだパーティションキーを使用している約2300万レコード?

CREATE TABLE TEST.TEST_LOG (
    bucketId    varchar, 
    id     timeuuid, 
    transaction_id  varchar, 
    ras_transaction_id varchar, 
    msg_seq_id   int, 
    host_name    varchar, 
    matip_channel_id  varchar, 
    hth_id    varchar, 
    mq_id     varchar, 
    log_point    varchar, 
    entry_time   timestamp, 
    exit_time    timestamp, 
    source_carrier  varchar, 
    destination_carrier varchar, 
    source_dcs   varchar, 
    destination_dcs  varchar, 
    message_type   varchar, 
    message_direction  int, 
    error_code_business varchar, 
    exception_code  varchar, 
    exception_description varchar, 
    scenario    varchar, 
    created_date   timestamp, 
    huborcar    varchar, 
    noof_fanout   varchar, 
    flight_date   timestamp, 
    route_origin   varchar, 
    route_destination  varchar, 
    class_service   varchar, 
    no_of_seats   varchar, 
    ras_host    varchar, 
    cp_host    varchar, 
    PRIMARY KEY(bucketid, created_date, msg_seq_id,message_direction,scenario,source_dcs,exception_code,log_point,transaction_id,id) 
) WITH default_time_to_live = 2851200 and CLUSTERING ORDER BY (created_date ASC, msg_seq_id ASC,message_direction ASC,scenario ASC,source_dcs ASC,exception_code ASC,log_point ASC,transaction_id ASC,id ASC); 

クエリ取ら

select 
transaction_id, 
message_direction, 
message_type, 
max(exception_code) as exception_code, 
min(entry_time) as min_entry, 
max(entry_time) as max_entry, 
min(exit_time) as min_exit, 
max(exit_time) as max_exit 
from TEST.TEST_LOG 
where bucketid='2017062113' 
and (
((msg_seq_id<=2 and message_type='PAOREQ' ) or 
(msg_seq_id>2 and message_type='PAORES' ))) 
group by transaction_id, 
message_direction, 
message_type 

時間:8分

+0

Cassandraのみを使用している場合、クエリはどのくらい時間がかかりますか?実行しているクエリとテーブルスキーマ(パーティション/クラスタリングキーの列を含む)は何ですか? –

+0

確認してください、更新された投稿 – Augustin

+0

カサンドラだけではどのくらいの時間がかかりますか? –

答えて

0

2つのこと

おかげで、:プレストの0.180リリースはされますが、クラスタ化キーに不等式述語のプッシュダウンが含まれますあなたの質問を助けてください。また、実行しているクエリではスキーマがうまく動作しません。 Cassandraでは、a)特定のパーティションの問合せ(およびCassandraが使用するソート順序であるため)を使用する順序でクラスタリング・キーの述語を使用することが最善です。主キー(bucketid、message_type、msg_seq_id、...)を持っていると、より良いパフォーマンスが得られるでしょう。

また、Prestoは集約をCassandra(または任意のコネクタ)にプッシュしません。集約しているデータ量が多く、フェデレーションクエリにPrestoが必要ない場合は、 Cassandraでクエリを実行するほうが速くなります。