Benchmark - Bangdb Embedded IOPS Summary

There are many scenarios in which the IOPS for the db could be measured. We have measured the value to help users in few such scenarios and from there user can understand what to expect from Bangdb as far as IOPS is concerned.

The average values for the throughput(ops/sec) over the 1M – 10M operations

Scenario 1: All operations from the buffer pool, log = OFF

In this scenario, we write and read completely from the buffer pool with out going into the hard disk. Log is off in this case. The other configuration are same as described in the Benchmark page in the section. This maps to the real world scenario of working out as cache where log in seldom needed

Index (Access Method) Write (ops/sec) Read (ops/sec)
Btree 685,000 1,045,000
Hash 790,000 1,675,000

Scenario 2: All operations from the buffer pool, log = ON

In this scenario, we write and read completely from the buffer pool with out going into the hard disk. Log is on in this case. The other configuration are same as described in the Benchmark page in the section. This maps to the real world scenario where cache is in-memory but would like to take snapshot of the log for future purposes

Index (Access Method) Write (ops/sec) Read (ops/sec)
Btree 475,000 1025,000
Hash 500,000 1,690,000

Scenario 3: Operations involving hard disk access some of the time, log = OFF

In this scenario, we write and read mostly from the buffer pool(wrote 20% more than the buffer pool capacity) with going out to the hard disk whenever data was not present in the bufferpool. Since we write and read random data hence db has to go to hard disk more often than not. Log is off in this case. The other configuration are same as described in the Benchmark page in the section. This maps to the real world scenario for corner cases of store being persistent but the data durability is of less importance compared to sheer speed of the operation

Index (Access Method) Write (ops/sec) Read (ops/sec)
Btree 570,000 830,000
Hash 625,000 1,275,000

Scenario 4: Operations involving hard disk access some of the time, log = ON

In this scenario, we write and read mostly from the buffer pool(wrote 20% more than the buffer pool capacity) with going out to the hard disk whenever data was not present in the bufferpool. Since we write and read random data hence db has to go to hard disk more often than not. Log is on in this case. The other configuration are same as described in the Benchmark page in the section. This maps to the real world scenario for most of the cases of store being persistent and the data durability is of high importance. But we generally don't write and read to db to the maximum of it's capacity continuously all the time hence real world would treat db much better than this

Index (Access Method) Write (ops/sec) Read (ops/sec)
Btree 355,000 815,000
Hash 365,000 1,300,000

Scenario 5: Operations involving hard disk access most of the time, log = ON

In this scenario, we write and read less from the buffer pool(wrote 125% more than the buffer pool capacity) with going out to the hard disk most of the time when data was not present in the bufferpool. Log is on in this case. The other configuration are same as described in the Benchmark page in the section. This is an extreeme scenario where we continuously write much more than the buffer pool can handle. Db consistently flushes out data and reads data into the pool, read write operations happen in parallel

Index (Access Method) Write (ops/sec) Read (ops/sec)
Btree 200,000 600,000
Hash 190,000 820,000

Please see the resource section for more detail data