Jul 23, 2015
When you insert a row into a table it is stored in memory and the request is written to the command log. When the command log grows to a certain size, a snapshot is taken and then all the preceding commands in the command log can be truncated. So all the records that have been inserted are in memory when the database is running, and persisted on disk either in the command log or within the latest snapshot.
You can read more about VoltDB Durability here: http://voltdb.com/sites/default/files/voltdb_datasheet_durability_v2.pdf
Jul 24, 2015
But I read http://hstore.cs.brown.edu/papers/hstore-lookingglass.pdf
shows that log will slow down the performance...
Jul 24, 2015
The looking glass paper talks about eliminating the logging aspects of transaction management, and then describes specifically how the WAL implemented in the SHORE database was bypassed. While there are similarities between this log and the VoltDB command log, there are also some important differences. Logging in a traditional database architecture is part of isolation, where different transactions could see different versions of records, and the logs are used to keep track of these differences for active transactions. In VoltDB there is only ever one version of the state of the data. There is a minimal UNDO log for only the current transaction running in each partition.
The Command log is a separate feature which logs the invocation request to disk in parallel with the execution of the transaction, which does not impede the execution of the transaction in memory. The synchronous vs. asynchronous mode only affects whether responses must wait for confirmation that the invocation was written to disk. With an SSD or if you are using a disk controller with battery-backed write cache, the waiting can be minimized even with fully synchronous command logging.