如何解决cassandra 在不同的 GCP 中读取查询需要时间[印度和 GCP 美国]
我们正在从 GCP US 迁移到 GCP INDIA。我们在印度创建了 3 个节点集群，在 GCP US 中有 3 个节点集群。在将一些读取查询传输到 GCP INDIA 时。我们正面临着在 GCP US 中运行的同一查询的高读取响应（30 毫秒）低于 15 毫秒。
目前，GCP US (API) --> 读取自 -->GCP cassandra (US) --> time 10 -15 ms 。 新的迁移案例是 GCP INDIA (API) ---> 从 GCP cassandra (INDIA) 读取--> 时间 30 毫秒。
同时检查读取查询跟踪计划。使用 local_quorum。
---------------------------------------------------------------------------------------------------+----------------------------+
Execute CQL3 query | 2021-07-13 11:39:26.806000 |
to_serv,eto_glusr_pref_loc FROM glusr_usr WHERE glusr_usr_id =12530; [Native-Transport-Requests-3] | 2021-07-13 11:39:26.807000 |
Preparing statement [Native-Transport-Requests-3] | 2021-07-13 11:39:26.808000 |
reading digest from /XX.XX.XX.XX [Native-Transport-Requests-3] | 2021-07-13 11:39:26.809000 |
Row cache miss [ReadStage-2] | 2021-07-13 11:39:26.809000 |
Row cache miss [ReadStage-2] | 2021-07-13 11:39:26.811000 | XX
Partition index with 0 entries found for sstable 139241 [ReadStage-2] | 2021-07-13 11:39:26.811000 |
Row cache miss [ReadStage-2] | 2021-07-13 11:39:26.811000 |
Executing single-partition query on glusr_usr [ReadStage-2] | 2021-07-13 11:39:26.811000 |
Executing single-partition query on glusr_usr [ReadStage-2] | 2021-07-13 11:39:26.811000 |
Acquiring sstable references [ReadStage-2] | 2021-07-13 11:39:26.811000 |
Acquiring sstable references [ReadStage-2] | 2021-07-13 11:39:26.811000 |
Skipped 0/13 non-slice-intersecting sstables,included 0 due to tombstones [ReadStage-2] | 2021-07-13 11:39:26.811000 |
Skipped 0/13 non-slice-intersecting sstables,included 0 due to tombstones [ReadStage-2] | 2021-07-13 11:39:26.811000 |
Partition index with 0 entries found for sstable 138332 [ReadStage-2] | 2021-07-13 11:39:26.811000 |
Partition index with 0 entries found for sstable 138620 [ReadStage-2] | 2021-07-13 11:39:26.813000 |
Partition index with 0 entries found for sstable 138331 [ReadStage-2] | 2021-07-13 11:39:26.815000 |
Partition index with 0 entries found for sstable 139240 [ReadStage-2] | 2021-07-13 11:39:26.815000 |
Partition index with 0 entries found for sstable 138783 [ReadStage-2] | 2021-07-13 11:39:26.817000 |
Partition index with 0 entries found for sstable 139719 [ReadStage-2] | 2021-07-13 11:39:26.817000 |
Partition index with 0 entries found for sstable 138621 [ReadStage-2] | 2021-07-13 11:39:26.817000 |
Partition index with 0 entries found for sstable 139855 [ReadStage-2] | 2021-07-13 11:39:26.819000 |
Partition index with 0 entries found for sstable 138950 [ReadStage-2] | 2021-07-13 11:39:26.820000 |
Partition index with 0 entries found for sstable 139096 [ReadStage-2] | 2021-07-13 11:39:26.820000 |
Bloom filter allows skipping sstable 139878 [ReadStage-2] | 2021-07-13 11:39:26.821000 |
Bloom filter allows skipping sstable 140774 [ReadStage-2] | 2021-07-13 11:39:26.821000 |
Bloom filter allows skipping sstable 139883 [ReadStage-2] | 2021-07-13 11:39:26.821000 |
Bloom filter allows skipping sstable 140789 [ReadStage-2] | 2021-07-13 11:39:26.821000 |
Bloom filter allows skipping sstable 139888 [ReadStage-2] | 2021-07-13 11:39:26.821000 |
Bloom filter allows skipping sstable 140794 [ReadStage-2] | 2021-07-13 11:39:26.821000 |
Bloom filter allows skipping sstable 139893 [ReadStage-2] | 2021-07-13 11:39:26.821000 |
Partition index with 0 entries found for sstable 140831 [ReadStage-2] | 2021-07-13 11:39:26.821000 |
Bloom filter allows skipping sstable 141000 [ReadStage-2] | 2021-07-13 11:39:26.821000 |
Bloom filter allows skipping sstable 141037 [ReadStage-2] | 2021-07-13 11:39:26.821000 |
Caching 1 rows [ReadStage-2] | 2021-07-13 11:39:26.821001 |
Partition index with 0 entries found for sstable 139987 [ReadStage-2] | 2021-07-13 11:39:26.822000 |
Merged data from memtables and 5 sstables [ReadStage-2] | 2021-07-13 11:39:26.822000 |
Bloom filter allows skipping sstable 140052 [ReadStage-2] | 2021-07-13 11:39:26.822000 |
Bloom filter allows skipping sstable 140097 [ReadStage-2] | 2021-07-13 11:39:26.822000 |
Bloom filter allows skipping sstable 140134 [ReadStage-2] | 2021-07-13 11:39:26.822001 |
Bloom filter allows skipping sstable 140135 [ReadStage-2] | 2021-07-13 11:39:26.822001 |
Caching 1 rows [ReadStage-2] | 2021-07-13 11:39:26.822001 |
Merged data from memtables and 5 sstables [ReadStage-2] | 2021-07-13 11:39:26.823000 |
Read 1 live rows and 0 tombstone cells [ReadStage-2] | 2021-07-13 11:39:26.823000 |
Partition index with 0 entries found for sstable 140137 [ReadStage-2] | 2021-07-13 11:39:26.823000 |
Read 1 live rows and 0 tombstone cells [ReadStage-2] | 2021-07-13 11:39:26.823000 |
Enqueuing response to /XX.XX.XX.XX [ReadStage-2] | 2021-07-13 11:39:26.823000 |
Sending REQUEST_RESPONSE message to /XX.XX.XX.XX [MessagingService-Outgoing-/XX.XX.XX.XX-Large] | 2021-07-13 11:39:26.824000 | X
REQUEST_RESPONSE message received from /XX.XX.XX.XX [MessagingService-Incoming-/XX.XX.XX.XX] | 2021-07-13 11:39:26.825000 | X
Bloom filter allows skipping sstable 140140 [ReadStage-2] | 2021-07-13 11:39:26.825000 |
Processing response from /XX.XX.XX.XX [RequestResponseStage-2] | 2021-07-13 11:39:26.825000 |
我的节点工具信息
Key Cache : entries 52837,size 5.21 MiB,capacity 500 MiB,14109 hits,49400 requests,0.286 recent hit rate,14400 save period in seconds
Row Cache : entries 232,size 20.91 MiB,capacity 4.09 GiB,78 hits,540 requests,0.144 recent hit rate,0 save period in seconds
所以我的问题是：如何减少这 30 毫秒的时间以及它为什么会发生。
请告诉我。
解决方法
乍一看，我会说您有太多的 SSTable，您几乎要花费 12 毫秒来查找其中的数据。我建议使用 nodetool tablehistograms 检查在两个 DC 中读取了多少 SSTable。
但根据trace，返回答案只用了19ms。如果您看到 30 毫秒的响应时间，那么您可能需要从驱动程序端捕获执行指标，并确保您有从驱动程序到 Cassandra 节点的快速链接。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
