...

If you are currently using MySQL, you can use the following methods to validate your application's compatibility with ClustrixDB: 

• To validate write statements, set up ClustrixDB as a slave using the SBR mode of replication to ensure the ClustrixDB slave can handle your application's write queries.

  • SBR provides the simplest option to validate compatibility, but for a production deployment, RBR is recommended. 

• To validate read statements, SQL queries may be captured either using tcpdump utility or by enabling full query logging.
  • Once you have captured tcpdump output, Clustrix Support can help convert it into valid SQL, which you can then replay using MySQL client.

• To understand how ClustrixDB differs from MySQL review the document General Differences from MySQL.

another database, see MySQL Compatibility and related pages to review differences. 

Prerequisites for a Successful Evaluation

...

The ClustrixGui Administration UI will indicate if your test workload is dominated by a single query. You can also look for such a problem by running SHOW PROCESSLIST or selecting from system.sessions while running your test, to identify any long-running queries. If you discover queries that are dominating your workload, you can optimize them as described in Optimizing Query Performance.

Testing

...

Query Performance

For OLAP testing, customers Customers are typically concerned with query response time for complex particular queries, rather than aggregate throughput. In this case, a simple framework that executes queries one at a time is reasonable, but consider the following guidelines:can be used for testing. The following guidlelines are helpful in determining query performance. 

Execute Queries at Least Twice

...

• Start with a cluster that is larger than you need, and try to achieve desired target TPS/Latency. 

• For very large tables (> 100 Gigs) that will keep growing, import the data into 8 Gig slices with slices with one slice per core using clustrix_import with the -m option where -m is the number of slicesthe -m option to set the number of slices.  If your table is bigger than (8 x number of nodes x number of cores), then use this formula for the number of slices: number of slices = (ceil(table size / 8GB / number of nodes)) * number of nodes.  Without the -m option clustrix_import ensures each table/index has at least once slice per node.                        

  shell> clustrix_import -u<user> -p<passwd> -i <dump_filename> -D <databasename> -m 48

• Create smaller tables with a slice count that is a common multiple of the cluster sizes you plan to test (e.g. 18 if you plan to test 3, 6, and 9 nodes).

• Once your tests are running within acceptable limits, scale cluster down to the point where it can sustain the load at < 80% average CPU.

• If for some reason you need to grow the cluster again, you may need to re-slice your tables (ALTER TABLE <table_name> SLICES=<number of nodes>) after growing the cluster.
• Check that the Rebalancer is finished rebalancing and that system.layer_merges are complete, after reducing or expanding the cluster.

...