Note Check the solidDB Release Notes for any limitations that are associated with using a grid in the current release.
Scaling up a database is a complicated problem. The underlying database technology is expected to provide a similar level of response when data volumes, transaction throughput, number of concurrent users, or some other relevant metric grows to a potentially different order of magnitude.
Typically, you cannot fulfill this requirement by just adding more CPU power, more memory, or better hard drives to the system. At some point, it becomes necessary to distribute the data and workload to multiple systems.
Sometimes it is practical just to split an entire system into multiple fully-independent systems. For example, you might split a centralized system that covers the whole country into systems that cover one province each.
However it is likely that, while most of the workload is expected to execute within a single partition, some queries that span the entire data set will be required. This is the typical use case for a solidDB grid solution, where one logical database can be split into several physical databases that run on different nodes.
solidDB Grid is designed to perform well under the following conditions:
▪ The write workload involves single row transactions.
These transactions can be executed by just one network hop to the server and can be executed with low latency. Transactions that access multiple nodes require a distributed transaction mechanism, which can not provide low latencies, and is not supported.
▪ The read workload consists predominantly of single row lookups.
Database operations that involve access to multiple nodes require multiple network hops.
▪ Low latencies are expected for a high volume of single row read or write operations.
▪ Fault tolerance by using redundancy and automated failure recovery is required.
▪ The data model and transactions can be designed to take advantage of the grid capabilities.
▪ The nodes in the grid are connected by a high-speed network.
solidDB Grid is not recommended for the following situations:
▪ The write workload involves transactions that write multiple rows, within the same transaction.
solidDB standalone servers can handle this workload with equally good throughput and latencies as single row transactions. However, due to the partition mechanism of a solidDB grid, this workload might not perform well in a grid.
▪ The majority of the workload involves large join operations that access and process multiple rows within the same SQL statement.
Even though solidDB is not an analytical database, these queries typically work well up to moderate data volumes and complexity on solidDB standalone servers. In a grid, a distributed query produces correct results but does not generally perform as well as on a standalone server.
However, if only a fraction of queries are complicated, a solidDB grid might still be a suitable solution, as performance benefits could still be gained from the simple queries that constitute the majority of the workload.
▪ The nature of solidDB Grid was not taken into account during the design of the system.
The greatest performance and scalability benefits are expected when the application is designed to be aware of the grid as the database solution.
▪ The nodes in the grid are not technically identical.
▪ There is a requirement for geographical redundancy across multiple data centers.