Log structured store versus Write ahead logging

Most databases use the ARIES algorithm (or similar). This allows for in-place changes to be made to binary objects on disk. However it must use write ahead logging to support atomicity. This has a number of disadvantages:

• It is vital that changes be written (and flushed) to the log before the corresponding changes are made to the "real" data. Unfortunately most off the shelf hard-disks need to have their local cache disabled to ensure that data is not written in the wrong order.
• The write performance is essentually halved because all changes must be logged - i.e. written to disk twice.
• Writing changes in-place means the disk head needs to seek around a lot. Fairly sophisicated techniques are required to reduce these problems. For example dirty pages are typically ordered so they can be written to disk by a lazy writer thread to minimise disk-head seek times. In practise, the product of transfer rate and seek time for a modern hard-disk is quite high - e.g. 512kB. Therefore it is very inefficient for the disk head to seek around only writing a small number of bytes at a time.
• Writing changes in place usually means that objects can't vary in size over time. Therefore objects that contain strings and other variable sized data either need to reserve a fixed size buffer, and impose a limit on the size, or else store the string separately. Storing the string separately hurts clustering. In fact storage of strings in object oriented databases is a well known performance problem.

A log structured store eliminates these problems. Write performance is typically limited only by the maximum transfer rate of the hard-disk.