Skip to end of metadata
Go to start of metadata

This page provides an overview on how to evaluate ClustrixDB and helps navigate around some common pitfalls during testing. There are links to best practices and performance guide for further details.

1. Pick a Testing Strategy

The first step is to identify whether to use a test workload or use your own workload to evaluate ClustrixDB. Our customers usually follow one of these two approaches:


2. Ensure the Test is setup correctly

When transitioning from a single node database to a distributed database, you need to take care of a few more things:


Increase the concurrency while the transactions per second increase with increasing threads. Here is as example graph showing how you will know you have adequate concurrency.


2.3 Adequately powerful clients

Sometimes during evaluation, customers will see lower TPS because their client in the test setup is not able to push the database to its maximum capacity. Ensure that the database TPS plateaus as shown above in the high concurrency requirement, if it does not you might have to use a more powerful client or multiple clients.

2.4 Using a load balancer

If your clients do not distribute the load evenly across all the nodes in the cluster, you should use an external load balancer. Load balancers such as HAProxy can be used. You can ensure that the load is evenly balanced by looking at the UI.

2.5 Testing using existing MySQL database

You can use your own MySQL database by moving the data to ClustrixDB using MySQLDump. Then you can simulate a workload or use production workload with ClustrixDB setup as a slave. You can get more detailed instructions in Best Practices for Migrating an Application from MySQL

2.6 Loading the data fast

You have to ensure that there is adequate concurrency and for large tables pre-slicing makes loading faster. More information can be found in Best Practices for Loading Data Onto Clustrix

3 Testing Analytics

ClustrixDB is often used for real-time analytics. Here are the common configurations:

  • Mixed OLTP and Analytics workload on same cluster (more common)
  • ClustrixDB as an analytics slave to ClustrixDB (or MySQL) master used exclusively for OLTP

If you run into any issues, check for:

  • Your data is evenly distributed across the cluster (happens automatically)
  • Look at explain of your queries and ensure that there are appropriate indexes. If you need help with query optimization, ask Clustrix support or post on forum.

4 Testing Scale-Out

You should test by increasing the size of the cluster to see that you can run more OLTP load and faster analytics queries. ClustrixDB maintains slices of ~1GB, so large tables have many slices and they will get evenly redistributed. However, if you're running a test case with smaller data set, you need to ensure your data is evenly divided.

5 Testing Availability

You should drop a node and test that you're still able to run queries. The rebalancer will redistribute the load.



inserted by FC2 system