On Thu, Dec 24, 2015 at 1:03 PM, Dmitry Yemanov dim...@users.sourceforge.net [firebird-support] <firebird-support@yahoogroups.com> wrote:
> 24.12.2015 05:31, 'Leyne, Sean' wrote: > > > > With today's unlimited availability of disk space and silly-low cost per > GB for storage, would an argument to dispense with the delta and simply > store a full copy of the record (not including BLOB) be worthy of > discussion? > > It's not about storage cost, but about IOPS. Bigger record = more I/O > for the same data = slower performance. Situation is better for SSDs, > but "silly-low cost" does not really apply there. > Right. The logic was never about saving space on disk, except to the extent that it reduces the amount of I/O necessary to complete a query. > > > I know that Jim has mentioned that in his later db engine he has adopted > a reverse approach which has the latest version stored in full and for > transactions required back versions responsible processing the deltas. In > this way, the latest version of the row are always complete so that the > back versions can be dropped very efficiently. > > Isn't it exactly how Firebird works? > Yes it is. The primary record version - the most recently created one - is always complete. The earlier record versions may be whole or deltas. Jim did handle back versions differently in Netfrastructure and slightly differently again in NuoDB. InterBase was designed for systems where having a whole megbyte of memory, so stuff had to go to disk as quickly as possible. When designing for more generous memory systems, he chose to keep only the most current committed record on disk. That version, and important back versions, and the newest uncommited version were all maintained in memory. If the system went down, any old transactions that needed old versions went down with it. NuoDB did approximately the same thing, except that it was distributed, so old versions had to be maintained a bit more carefully so losing one node would never lose all old versions. His latest database, AmorphousDB handles versioning at the attribute level rather than the record level, but follows the model that only the most recently committed version of an attribute is worth the cost of a disk write. Cheers, Ann
