了解从 Cassandra 中的单个分区读取 [英] Understanding read from a single partition in Cassandra
问题描述
我有一个 3 节点设置，Node1 (172.30.56.60)、Node2 (172.30.56.61) 和 Node3 (172.30.56.62)，单分区数据100K，分区由nodeip框架.
请找到 nodeip 的令牌/分区值 - 172.30.56.60
I have a 3 node setup, Node1 (172.30.56.60), Node2 (172.30.56.61) and Node3 (172.30.56.62),
It has the single partition data of 100K, the partition is framed by nodeip.
Please find the token / partition value for the nodeip - 172.30.56.60
cqlsh:qnapstat> SELECT token(nodeip) FROM nodedata WHERE nodeip = '172.30.56.60' LIMIT 5;
system.token(nodeip)
----------------------
222567180698744628
222567180698744628
222567180698744628
222567180698744628
222567180698744628
根据下面提供的 ./nodetool 环值，'172.30.56.60' 只会将数据返回给协调器，因为从 173960939250606057 到 239923324758894350 的值是在节点 1762.600.30.30 处处理的.注意:这是我的理解
As per the ./nodetool ring value provided below, '172.30.56.60' only will return the data to the coordinator since the value from 173960939250606057 to 239923324758894350 is handled bu the node 172.30.56.60. Note : This is my understanding
172.30.56.60 rack1 Up Normal 32.72 MiB 100.00% 173960939250606057
172.30.56.62 rack1 Up Normal 32.88 MiB 100.00% 239923324758894351
172.30.56.61 rack1 Up Normal 32.84 MiB 100.00% 253117576269706963
172.30.56.60 rack1 Up Normal 32.72 MiB 100.00% 273249439554531014
172.30.56.61 rack1 Up Normal 32.84 MiB 100.00% 295635292275517104
172.30.56.62 rack1 Up Normal 32.88 MiB 100.00% 301162927966816823
我有两个问题，
1) 当我尝试执行以下查询时，是否意味着协调器(比如 172.30.56.61)从 172.30.56.60 读取所有数据?
1) When I try to execute the following query, Does it mean that Coordinator (say 172.30.56.61) reads all the data from the 172.30.56.60?
2) Coordinator 接收到所有 100K 条目后，Coordinator 会进行 100K 的聚合，如果是这样，它会将所有 100K 条目保存在 172.30.56.61 的内存中吗?
2) Is that after receiving all the 100 K entries in the coordinator, Coordinator will perform the aggregation for 100K, If so does it keeps all 100K entries in memory in 172.30.56.61?
SELECT Max(readiops) FROM nodedata WHERE nodeip = '172.30.56.60';
推荐答案
有一个名为 CQL TRACING 的好工具，可以帮助您在执行 SELECT 查询后理解和查看事件流.
There is nice tool called CQL TRACING that can help you understand and see the flow of events once a SELECT query is executed.
cqlsh> INSERT INTO test.nodedata (nodeip, readiops) VALUES (1, 10);
cqlsh> INSERT INTO test.nodedata (nodeip, readiops) VALUES (1, 20);
cqlsh> INSERT INTO test.nodedata (nodeip, readiops) VALUES (1, 30);
cqlsh> select * from test.nodedata ;
nodeip | readiops
--------+-----------
1 | 10
1 | 20
1 | 30
(3 rows)
cqlsh> SELECT MAX(readiops) FROM test.nodedata WHERE nodeip = 1;
system.max(readiops)
-----------------------
30
(1 rows)
现在让我们设置cqlsh>；TRACING ON 并再次运行相同的查询.
Now let's set cqlsh> TRACING ON and run the same query again.
cqlsh> TRACING ON
Now Tracing is enabled
cqlsh> SELECT MAX(readiops) FROM test.nodedata WHERE nodeip = 1;
system.max(readiops)
----------------------
30
(1 rows)
Tracing session: 4d7bf970-eada-11e7-a79d-000000000003
activity | timestamp | source | source_elapsed
-----------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------+--------------+----------------
Execute CQL3 query | 2017-12-27 07:48:44.404000 | 172.16.0.128 | 0
read_data: message received from /172.16.0.128 [shard 4] | 2017-12-27 07:48:44.385109 | 172.16.0.48 | 9
read_data handling is done, sending a response to /172.16.0.128 [shard 4] | 2017-12-27 07:48:44.385322 | 172.16.0.48 | 222
Parsing a statement [shard 1] | 2017-12-27 07:48:44.404821 | 172.16.0.128 | --
Processing a statement [shard 1] | 2017-12-27 07:48:44.404913 | 172.16.0.128 | 93
Creating read executor for token 6292367497774912474 with all: {172.16.0.128, 172.16.0.48, 172.16.0.115} targets: {172.16.0.48} repair decision: NONE [shard 1] | 2017-12-27 07:48:44.404966 | 172.16.0.128 | 146
read_data: sending a message to /172.16.0.48 [shard 1] | 2017-12-27 07:48:44.404972 | 172.16.0.128 | 152
read_data: got response from /172.16.0.48 [shard 1] | 2017-12-27 07:48:44.405497 | 172.16.0.128 | 676
Done processing - preparing a result [shard 1] | 2017-12-27 07:48:44.405535 | 172.16.0.128 | 715
Request complete | 2017-12-27 07:48:44.404722 | 172.16.0.128 | 722
至于你的问题:
如果
RF = 1或 (RF > 1andCL=ONE)，那么它将收到来自 1 个副本的回复，但是如果 (RF > 1和CL > 1)，那么它需要接收来自多个副本的回复，并且比较答案，因此协调器端也进行了编排.它实际完成的方式是对最快副本(使用 snitch)的数据请求和对满足 CL 所需的其他副本的摘要请求.然后协调器需要散列来自数据和摘要请求的响应并比较它们.如果分区被散列到特定节点中，它将驻留在该节点中(假设 RF=1)并且信息将仅从该节点读取.
The Coordinator passes the query to the replica, if
RF = 1or (RF > 1andCL=ONE), than it will receive the reply from 1 replica, but if (RF > 1andCL > 1), than it needs to receive replies from multiple replicas and compare the answers, so there's also orchestration done on the Coordinator side. The way it is actually done is a data request to the fastest replica (using the snitch) and a digest request to the other replicas needed to satisfy the CL. And then the coordinator need to hash the responses from the data and digest requests and compare them. If the partition is hashed into a specific node, it will reside in that node (assuming RF=1) and information will be read only from that node.
客户端随查询发送页面大小，因此回复本身是批量返回的(默认值=5000)，可以从客户端设置.
The Client sends with the query the page size, so the reply itself is returned in bulks (default=5000), which can be set from the client side.
我建议在 Cassandra 上观看此 youtube 剪辑阅读路径了解更多详情.
I recommend watching this youtube clip on Cassandra read path for more details.
这篇关于了解从 Cassandra 中的单个分区读取的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
