截取一段关于ACM (Auto Commit Memory)的描述。也就是9 million IOPS的benchmark。
consistency and durability都有保证。
On the other hand, when you write something to Auto Commit Memory, by design
it will be automatically committed. In other words, it is durable across
service interruptions such as power failures.
Note that part of the ACM API will be a write barrier operation, like a
flush, ensuring that the data is cleared from the processor complex, various
levels of CPU caches and what not. Once flushed from the processor complex,
it's automatically persisted to ioMemory.
What attracts a lot of database developers to this new API is the notion of
solving the tail-of-their-transaction log performance inhibitor. By
definition, it is the transaction log through which they can ensure ACID
properties of transactions.
Previously developers had to issue blocking synchronous I/Os at the tail of
their log, to ensure that the most recent writes before service interruption
were durable. With our ACM API they can convert that blocking synchronous
IO to a non-blocking asynchronous IO by maintaining the tail of their
transaction log in auto commit memory.
They may still persist the tail of their log to a backing store but they
will not need to do it synchronously through a blocking IO. If there's an
interruption, for instance upon a system or an application restart, they can
always recover their state through what was persisted in auto commit memory
. So developers are quite keen on that.