MySQL Cluster Tutorial - cdn.oreillystatic.com

Scaling and Performance
MySQL Nodes
MySQL Cluster is not designed for the single thread / single query performance. In fact
you can be almost certain that it will perform worse in this scenario than any other storage
engine type. It is designed for multiple simultaneous queries.
By default a mysqld server only has a single connection to the cluster to process queries
which can be a bottleneck. There are two ways around this. First, you could add more
mysqld nodes and have your application load-balance between them.
Or alternatively you could use the --ndb-cluster-connection-pool setting to add more
connections between mysqld and the cluster. Please note that to do this you will need to
add more [mysqld] slots to your my.cnf to account for each connection in the pool.
NDBAPI
Of course, direct NDBAPI is going to give much better performance than using SQL.
Not only do you eliminate the SQL overhead but there are some things in NDBAPI which
cannot be defined using SQL.
Data Nodes
MySQL Cluster was originally designed for primary key equality lookups, and it excels at
this. When running an SQL query with this kind of lookup mysqld will try to go directly to
the node with the data and the data will be retrieved very quickly.
Ordered index lookups are, in general, a lot slower. This is because the query has to be
sent to all nodes to be processed simultaneous and then the results are collected and sent
back. When adding more nodes there is more network traffic and round trips required for
this. So performance can degrade with more nodes when ordered indexes are used.
Other Issues
Blobs
Blobs (text columns are blob columns too) in MySQL Cluster are stored using a hidden
table.
Each blob is split up into many rows for this table (depending on the size of the blob). This
not only causes performance problems but can cause locking problems too because MySQL
needs to keep the blob table consistent with the main table.
Where possible a large VARCHAR or VARBINARY may be a better option.
Joins
At the moment joins require a lot of excessive overhead to process. The second table in the
join is effectively queried for every matching row in the first table. This is a lot of network
overhead.
There is a work-in-progress solution to this called pushed-down joins. This is where the
joins are processed directly in the data nodes. This is currently an in-development feature
with no scheduled release date (or any guarantee it will ever be released).
Copyright © 2010, Oracle and/or its affiliates. All rights reserved. 71/81