VoltDB is revolutionary database technology that combines the speed and performance of noSQL with the robustness and reliability of a traditional OLTP database. The advantages of VoltDB are:
Best-in-class, easily scalable throughput
Ease of use of standard SQL syntax
Full ACID-compliance including rollback, durability, high availability, and crash recovery
Clustered, shared-nothing architecture:
Provides a smooth path for scaling both throughput and data volume
Designed for use on commodity computing resources, including "bare metal" servers and cloud computing
This book helps you get started using VoltDB. The accompanying book. Using VoltDB, provides complete information about the usage and features of VoltDB.
VoltDB is a relational database. You can use VoltDB like any other relational database, defining the schema with SQL data definition language (DDL) statements and issuing ad hoc queries.
However, to get the most out of your database application, VoltDB provides ways to optimize performance through stored procedures and partitioning.
Stored procedures are units of work, where multiple SQL queries and application-specific code are pre-compiled and optimized. Each stored procedure is a separate transaction and succeeds or rolls back as a whole.
Partitioning allows VoltDB to segment both the data and the stored procedures that access that data. By running stored procedures against a specific partition, multiple transactions can be run in parallel, providing almost linear scalability in terms of transaction throughput.
You tell VoltDB what partitions to create and how to access them by compiling your schema and stored procedures into an application catalog that is used to create the database at runtime.
You can make changes to the schema by recompiling the catalog and updating it on the fly. Or, if you need to make more significant changes, such as changing the partitioning, you can save the current contents, restart the database with the new catalog and restore the data to the new schema.
The application catalog defines the logical structure of the database. You can also use a deployment file when you start the database to specify the physical layout of the database: how many servers to use, how many partitions per server, and so on. The deployment file is an XML file that can be edited with any text editor. In addition to specifying the physical configuration of the database cluster, the deployment file identifies any special features that should be enabled, such as export, K-safety, or durability features such as automatic snapshots and command logging.
To create a database instance, you compile the schema and stored procedures into an application catalog, then start the database from the catalog and deployment file. Once the database is running, you can use ad hoc queries or client applications in any of several programming languages to read, write, and update the contents of the database.