所以,这就是我所拥有的:
一个简单的表类_to_students:
|class |student|
---------------
Math Alice
Math Bob
Math Peter
Math Anne
Music Bob
Music Chis
Music Debbie
...
有1000000个班级.每个学生都参加500个课程.
(不好比喻,我知道……)
对于测试,数据库中有4000名学生(因此有2.000.000行),但这个数据库应该处理数百万学生,这就是我使用MySQL ndbcluster的原因.
无论如何……像这样的查询:
SELECT student, COUNT(class) as common_classes
FROM classes_table
WHERE class IN (my_subject_list)
GROUP BY student
ORDER BY common_classes DESC
导致类似于:
|student |commonClasses|
Brad 6
Melissa 4
Chris 3
Bob 3
...
在一台服务器上使用InnoDB引擎大约需要1秒钟,这没关系.在具有3个数据节点的ndbcluster上,相同的查询最多需要10秒,这太过分了.我不知道上面的语句是如何在内部处理的,但我想节点之间有很多通信,这使得它因延迟而变慢.
有人能告诉我,当我执行此查询时群集中会发生什么?我怎样才能让它更快?
解决方法:
首先,Cluster是一个存储引擎.它实际上并不执行查询,因为它不会说SQL.这就是您使用MySQL服务器的原因,该服务器解析您的查询并将低级别存储引擎API调用发送到群集数据节点.数据节点知道如何检索或存储数据.或者,您可以使用NDB API直接与数据节点通信.
MySQL Cluster有各种执行查询的方法.他们归结为:
>主键查找
>唯一键查找
>有序索引扫描(即使用T树的非唯一索引)
>全表扫描
假设您的群集中有4个数据节点(NoOfReplicas = 2).这意味着您有2个节点组,每个节点组都有一半的数据.群集在主键上使用哈希(除非您使用5.1分区功能控制分区).因此,对于任何表,一半的行在一个节点组中,一半的行在另一个节点组中.
现在为4种类型的查询执行.您可以验证EXPLAIN使用的执行类型.以下是每种方法的工作原理:
Primary key lookup - the MySQL server can calculate the hash on the primary key and know which data node the relevant row resides in. Then the MySQL server contacts that data node and receives the row.
Unique key lookup - the MySQL server cannot know which data node the row might be stored in. So it contacts a pseudo-random node. That data node has a hidden table that maps the unique key values to the primary key. Then the hash on the primary key reveals where the row resides.
Ordered index scans are sent in parallel to all data nodes, where they search their local t-tree.
Full table scans are send in parallel to all data nodes, where they scan their primary fragment.
摘要:主键查找最好.如果您有超过2个节点,吞吐量会上升,因为所有节点都在积极地为不同的数据片段提供服务.有序索引查找和全表扫描是并行完成的,因此更多节点可以带来更好的性能.
标签:performance,mysql,optimization
来源: https://codeday.me/bug/20190806/1599710.html