Comments on: Intelligent user-controlled partitioning and writing distribution-aware NDB API Applications http://www.clusterdb.com/mysql-cluster/intelligent-user-controlled-partitioning-and-writing-distribution-aware-ndb-api-applications/?utm_source=rss&utm_medium=rss&utm_campaign=intelligent-user-controlled-partitioning-and-writing-distribution-aware-ndb-api-applications MySQL Cluster database & MySQL Replication Thu, 02 Feb 2012 16:19:38 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: admin http://www.clusterdb.com/mysql-cluster/intelligent-user-controlled-partitioning-and-writing-distribution-aware-ndb-api-applications/comment-page-1/#comment-1784 admin Tue, 06 Oct 2009 09:36:22 +0000 http://www.clusterdb.com/?p=248#comment-1784 Hi Mike, in general, MySQL Cluster performs best when an individual transaction can be handled by a single data node. As all of the data is in memory, it is extremely fast for the data node to work on that data. Where it gets slower is when there needs to be lots of messaging between nodes. There are some cases where the MySQL Server node can be smart and break up the work between data nodes and so get the benefits of adding parallelism and if the application is only processing one transaction at a time then that might improve performance. It's more typical with Cluster though that the applications would be working on multiple sub_ids at the same time and so that is where you leverage the power of multiple, shared-nothing data nodes. The good news is that it's extremely simple to change the partitioning for an existing database and so the best answer is to try it for yourself with your schema and application :) Andrew. Hi Mike,

in general, MySQL Cluster performs best when an individual transaction can be handled by a single data node. As all of the data is in memory, it is extremely fast for the data node to work on that data. Where it gets slower is when there needs to be lots of messaging between nodes.

There are some cases where the MySQL Server node can be smart and break up the work between data nodes and so get the benefits of adding parallelism and if the application is only processing one transaction at a time then that might improve performance. It’s more typical with Cluster though that the applications would be working on multiple sub_ids at the same time and so that is where you leverage the power of multiple, shared-nothing data nodes.

The good news is that it’s extremely simple to change the partitioning for an existing database and so the best answer is to try it for yourself with your schema and application :)

Andrew.

]]> By: Mike van Lammeren http://www.clusterdb.com/mysql-cluster/intelligent-user-controlled-partitioning-and-writing-distribution-aware-ndb-api-applications/comment-page-1/#comment-1690 Mike van Lammeren Wed, 30 Sep 2009 21:43:50 +0000 http://www.clusterdb.com/?p=248#comment-1690 I am trying to understand the ramifications of setting "partition by key" on the "services" table. By storing all the "services" records with the associated "names" record, aren't we preventing the ndbd nodes from working on a query in parallel? If there are many hundreds or thousands of "services" records per "names" record, then wouldn't it be better if they were spread around? So that each of the 4 nodes, for example, could pull 1/4 of the records? What am I missing? I am trying to understand the ramifications of setting “partition by key” on the “services” table. By storing all the “services” records with the associated “names” record, aren’t we preventing the ndbd nodes from working on a query in parallel?

If there are many hundreds or thousands of “services” records per “names” record, then wouldn’t it be better if they were spread around? So that each of the 4 nodes, for example, could pull 1/4 of the records?

What am I missing?

]]>