了解从 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
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' 只会 return 将数据发送给协调器,因为从 173960939250606057 到 239923324758894350 的值由节点 172.30.56.60 处理。 注:这是我的理解
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 读取所有数据?
2) Coordinator是不是在收到coordinator中所有的100K entries后,会进行100K的聚合,如果是,是否将所有的100K entry都保存在172.30.56.61的内存中?
SELECT Max(readiops) FROM nodedata WHERE nodeip = '172.30.56.60';
有一个名为 CQL TRACING 的好工具可以帮助您理解和查看执行 SELECT 查询后的事件流。
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
和 运行 相同的查询。
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 > 1
和CL=ONE
),它将收到来自1个副本的回复,但是如果(RF > 1
和 CL > 1
),它需要从多个副本接收回复并比较答案,所以协调器端也完成了编排。
它实际完成的方式是向最快的副本(使用告密者)发出数据请求,并向满足 CL 所需的其他副本发出摘要请求。
然后协调器需要对来自数据和摘要请求的响应进行哈希处理并进行比较。
如果分区被哈希到一个特定的节点,它将驻留在该节点(假设 RF=1)并且信息将只从该节点读取。
客户端随查询一起发送页面大小,因此回复本身会批量返回(默认=5000),这可以从客户端设置。
我建议在 Cassandra 读取路径上观看此 youtube 剪辑以了解更多详细信息。
我有一个 3 节点设置,Node1 (172.30.56.60)、Node2 (172.30.56.61) 和 Node3 (172.30.56.62),
单分区数据100K,分区由nodeip分格
请找到 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' 只会 return 将数据发送给协调器,因为从 173960939250606057 到 239923324758894350 的值由节点 172.30.56.60 处理。 注:这是我的理解
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 读取所有数据?
2) Coordinator是不是在收到coordinator中所有的100K entries后,会进行100K的聚合,如果是,是否将所有的100K entry都保存在172.30.56.61的内存中?
SELECT Max(readiops) FROM nodedata WHERE nodeip = '172.30.56.60';
有一个名为 CQL TRACING 的好工具可以帮助您理解和查看执行 SELECT 查询后的事件流。
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
和 运行 相同的查询。
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 > 1
和CL=ONE
),它将收到来自1个副本的回复,但是如果(RF > 1
和CL > 1
),它需要从多个副本接收回复并比较答案,所以协调器端也完成了编排。 它实际完成的方式是向最快的副本(使用告密者)发出数据请求,并向满足 CL 所需的其他副本发出摘要请求。 然后协调器需要对来自数据和摘要请求的响应进行哈希处理并进行比较。 如果分区被哈希到一个特定的节点,它将驻留在该节点(假设 RF=1)并且信息将只从该节点读取。客户端随查询一起发送页面大小,因此回复本身会批量返回(默认=5000),这可以从客户端设置。
我建议在 Cassandra 读取路径上观看此 youtube 剪辑以了解更多详细信息。