NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter



Benchmarking the performance impact of Foreign Keys in MySQL Cluster 7.3

FOREIGN KEYs in MySQL Cluster is a big step forward. […] It is implemented natively at the Data Node level, where NDB stores its data. It is well known that FOREIGN KEYs come with an overhead. E.g., when writing a record into a child table, the existence must be checked in the parent table. Since data is distributed across multiple Data Nodes, the child record and parent record may be on different nodes or shards (Node Groups). Hence there is extra work to be done in terms of internal triggers and network communication, the latter being the more costly. The performance impact must be taken into account when doing capacity planning of the cluster. The question is how much the impact is, and that is what we will look at next.

These micro-benchmark numbers are looking good. But here are a couple of questions I couldn’t answer after reading the post:

  1. how was the data distributed inside the cluster? Basically those results could have been achieved with most of the foreign keys actually living on the same machine
  2. how does the impact on performance vary with the size of the cluster? (differently put, how effective is the routing of FK checks and what’s the impact on the cluster network traffic and locks)

Original title and link: Benchmarking the performance impact of Foreign Keys in MySQL Cluster 7.3 (NoSQL database©myNoSQL)