Skip to content
laforge49 edited this page Oct 24, 2011 · 19 revisions

The Swift Datastore has the same capabilities as the Small Records Datastore. The difference is that the datastore is only written to disk once every 100 updates. So it is much faster and in the test environment described below, it does 5,552 transactions per second (2,776 being updates)--when not flushing the log file. But flushing the log file is necessary if want to offer any assurance that there will be no lost transactions. And that brings the transaction rate down to 76 per second (38 updates).

Moving the transaction log to a faster disk, or using a disk with built-in batteries so that flushing is not required, or switching to a Solid State Disk (SSD) will all improve the transaction rate significantly. Another way to speed up the effective transaction rate is to batch transactions at the application level.

SwiftRecordsTest
SwiftLockTest

##When the Datastore is Not Current

With the database updated only once every 100 or more transactions, it will rarely be current. How do you handle that?

The structure of the Swift datastore is a bit different from the Small Records datastore. SwiftInitializationComponent builds the new structure. The root block now holds a root map rather than the records map, the records map now being held by the root map. The root map also holds the name of the log file and the position in the log file where you will find journal entries which have not yet been processed.

When the swift datastore is restarted, you first select the latest valid copy of the datastore and then get the name of the log file and the position. Then you reprocess the journal entries from that position to the end of the file to bring the datastore up-to-date.

##Test Environment

  • Windows 7
  • Intel(R) Core(TM)2 Duo CPU T6400 @ 2.00GHz
  • Fujitsu MHZ2320BH-G2 320GB 5400 RPM 8MB 2.5" SATA 3.0Gb/s

SwiftTimingsTest
NoFlushSwiftTimingsTest


SwiftDataStoreComponent

tutorial

Clone this wiki locally