Frequently Asked Questions
Is ScaleBase’s distributed database platform ACID compliant?
Yes. ScaleBase supports two-phase commit and rollback across the distributed database platform, thereby maintaining ACID compliance and full relational integrity.
Does ScaleBase’s distributed database platform support SQL’s query model?
Yes. ScaleBase’s distributed database platform support SQL properties like cross-database queries, including ORDER BY, GROUP, BY, and LIMIT. ScaleBase also provides automated aggregation of query results and Map-Reduce-Like parallel query execution.
Is ScaleBase’s distributed database platform transparent to my applications?
Yes. ScaleBase is completely transparent to your applications:
- Access transparency – clients are unaware of the distribution of data.
- Location transparency – clients see a single database namespace and data can be relocated without any changes to the application.
- Concurrency control transparency – users and applications can access shared data without interference between each other.
- Replication transparency – clients are unaware if replica copies of the data exist.
- Failure transparency – ScaleBase is fault-tolerant, allowing users and applications to complete their tasks despite the failure of hardware or software components.
- Migration transparency – users are unaware of the movement of data or processes within the system.
- Scaling transparency – scale out / scale in occurs without any changes to applications.
How does ScaleBase scale your database?
ScaleBase uses a transparent data distribution method (similar to a concept known as sharding). Sharding is a well-known method for scaling databases, but it’s very difficult to implement. ScaleBase automates the process – so your database scales, and you don’t have to manage any of the complexity associated with it.
Are all database servers the same? Duplicate copies?
No. Making all databases the same is not a good scaling mechanism. Your application will instantly run into bottlenecks. ScaleBase splits the data across multiple databases. All the databases share the same schema, but each holds a different portion of the data (some data is copied across all databases, but it’s a small portion of the overall data).
What is the best way to split and federate the data between the database servers?
That’s the most difficult decision to make – how to split the data. ScaleBase analyses your schema and automatically builds a sharding configuration.
Does splitting and federating data between database servers really improve database scaling?
Yes, absolutely. Sharding has proven itself as the best way to scale out databases. Just have a quick look at our TPCC performance report, or some testimonials from people who implemented our sharding solution. It should give you a good feel for the kind of performance and scaling you can expect.
Do I have to make changes to my application?
No. ScaleBase is a transparent solution so it supports the SQL commands in your application. However our analysis might suggest making some changes as an optimizing technique, to improve application performance.
Do I now have to manage multiple databases?
No. Since ScaleBase supports any application, your management solutions can connect to ScaleBase and all management actions remain the same. The existence of multiple databases is transparent.
Do I need to install anything on my database machine?
No. ScaleBase requires no agent installation on your database machine – your machines remain untouched.
Does ScaleBase handle database high availability?
Yes. By utilizing replication, each primary database server can have one or more backup databases. When ScaleBase detects that the primary database server is down, it automatically directs traffic to the most up-to-date backup database. This ensures that the application continues working, without any errors or failures.
Does ScaleBase monitor the replication status?
Yes. ScaleBase monitors the replication status, so we don’t failover to a backup server that is not up-to-date. Since replication is asynchronous, backup databases can hold information that is not current (lag time between the backup and the primary database server). ScaleBase lets you define what an acceptable lag-time is, and will not fail over if the lag-time is too big. In any case, ScaleBase always fails over to the backup database server that is most up-to-date.
Does each primary database server have to have a backup database server?
No, but it’s highly recommended.
Does each primary database server have to have only one backup database server?
No. Each primary database server can have any number of backup databases – in the same or different geographical locations.
Can backup database servers be used while in backup mode?
Yes. If so configured, ScaleBase can direct writes to the primary database server database, and reads to the backup databases. It’s a great way to scale your database read load.
What happens when the primary database server fails?
When the primary database server fails, commands sent to it from ScaleBase return an error. ScaleBase automatically determines the most up-to-date backup database and directs all traffic to that backup database. The primary database server is marked as down and will not get any traffic.
What happens if the primary database server comes back to life?
Nothing. Since many changes might have happened during the time the primary was down, ScaleBase does not access the primary again, until a special API call is made.