MySQL Cluster Tutorial - cdn.oreillystatic.com

Schema considerations
Develop for MySQL Cluster
Going from one storage engine is relatively easy with MySQL, but it usually isn't the best
way forward. If you go for example from MyISAM to InnoDB, you'll need to tune a
completely different set of options to make run smoothly. The same is true when you alter
tables to use the NDBCluster storage engine:
ALTER TABLE employees ENGINE=NDBCluster
One example where it can go wrong are with some of the restrictions and limitations found
in MySQL Cluster. The following table compares a few differences between NDBCluster,
InnoDB and MyISAM:
NDBCluster InnoDB MyISAM
Columns per table 128 1000 4096
Row size 8052 bytes ±8kB* 64kB
(*Excluding variable-lenght columns)
If one of your tables would have 200 columns, it would not be possible to store it in
MySQL Cluster.
More on limitations within MySQL and MySQL Cluster in the MySQL Manual:
http://dev.mysql.com/doc/refman/5.1/en/restrictions.html
http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-limitations.html
http://dev.mysql.com/doc/refman/5.1/en/innodb-restrictions.html
http://dev.mysql.com/doc/refman/5.1/en/myisam-storage-engine.html
Re-normalization
When you have an existing project, you probably did normalize your data. If you want to
get your project into MySQL Cluster, you'll have to check if your schema still fits.
The Row Size is a common pitfall. As we seen earlier, it is limited to 8052 bytes. Your
InnoDB tables will not work.
To demonstrate, lets create a table with two rather big VARCHAR fields:
CREATE TABLE t1 (
c1 INT NOT NULL KEY,
c2 VARCHAR(4000),
c3 VARCHAR(4000)
) ENGINE=NDBCluster DEFAULT CHARSET=Latin1
This works, as we keep under the 8052 bytes. Notice also that we use a 1-byte character set,
latin1. If we would use UTF-8 as character set, it would fail:
CREATE TABLE t1 (
c1 INT NOT NULL KEY,
c2 VARCHAR(4000),
c3 VARCHAR(4000)
) ENGINE=NDBCluster DEFAULT CHARSET=UTF-8
Copyright © 2010, Oracle and/or its affiliates. All rights reserved. 68/81