当前位置: 首页 > 知识库问答 >
问题:

Presto Cassandra慢性能慢

欧阳睿范
2023-03-14

我正在使用presto查询Cassandra记录,它需要大约8分钟来响应结果。需要提高响应时间。

Presto配置如下:

   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.98M,输入:17833912行(1.49GB),输出:13089502行(1.31GB)
ScanFilterProject[table=cassandra:cassandra:rasapp:raslog,originalConstraint=((“BucketID”=CAST('2017062113'成本:96.12%,Input:23169736行(22.10MB),Output:17833912行(1.49GB),Filtered:23.03%)

如何提高presto中的响应时间仍然使用分区键,它有大约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分钟

谢谢,

共有1个答案

南宫云
2023-03-14

两件事:Presto的0.180版本将包括对聚类键的不等式谓词的下推,这将有助于您的查询。此外,您的架构不能很好地与您正在运行的查询一起工作。在Cassandra中,最好是对特定分区进行)查询(您确实这样做了),并且按照使用集群键的顺序在集群键上使用谓词(因为这是Cassandra使用的排序顺序)。如果主键为(bucketid、message_type、msg_seq_id、...),性能可能会更好。

此外,Presto不会将聚合下推到Cassandra(或任何连接器),因此如果您正在聚合大量数据,并且联邦查询不需要Presto,那么只在Cassandra中执行查询可能会更快。

 类似资料:
  • 我安装了Redis来评估是否可以使用它来缓存对象集合;每个密钥包含一个更新的时间序列,每个更新是一个字节[5000]。我对我运行的一个简单测试的结果感到惊讶--我插入了1000个数组;每个都是一个字节[5000]。在本地读取计算机上运行LRANGE的完整列表需要20秒才能完成。我通过改变我检索到的Byte[5000]对象的数量进行了测试,并且检索的时间与所请求的数据大小成比例o(n),正如预期的那

  • 问题内容: 我正在尝试解决回文分割问题。您可以在https://leetcode.com/problems/palindrome- partitioning/中 找到问题。 我想出了解决方案: 但是性能很差。超过时间限制。 但是Python实现的相同想法可以通过: 这让我想知道如何改进swift的实现以及为什么swift的实现比python慢​​。 问题答案: Swift 是的集合,并且a 表示单

  • 我在Select query where条件下执行了带有自定义配置单元UDF函数的配置单元SQL脚本,它已经运行了两天多。我想知道这里到底有什么问题?调用java需要很多时间,还是查询执行本身需要很多时间? 我的数据集如下,A表有200万条记录,B表有100万条记录,

  • 我正在处理一个需要JDBC调用Oracle数据库的项目。我已经设置了UCP池化来与SpringJDBC一起工作。我有一个相当简单的查询,我正在执行如下... 我的java代码来设置这个查询看起来像下面... 只要数组中只有一个id,这一切都可以正常运行。当我添加第二个ID时,查询需要将近5分钟的时间运行。如果我获取精确的查询并在SQLDeveloper中执行它,则需要.093秒。 我的代码或配置一

  • 我有一个非常基本的Spring Boot应用程序,它公开了一个非常简单的实体的CRUD Rest API。使用JMeter运行性能测试显示响应时间很差 约束:id PK自动增量 设置: 线程数:100 4个API,用于执行以下功能 我试图用可视化虚拟机查看原因。似乎存储库函数花费了太多时间。我假设是数据库导致了这个问题。 连接池设置:因为我没有设置任何内容,假设我的应用程序使用HikariCP,默

  • 我遇到了一个奇怪的问题,我向你保证我已经谷歌了很多次。 谢谢