31 CEDA LSS versus Oracle BerkeleyDB

CEDA has a high performance storage engine which features atomic transactions, automatic crash recovery, incremental backup, slave mirroring, optional transaction durability and concurrent reading with writing. It is well suited to being used as an embedded key-value database, as an alternative to products like the Oracle BerkeleyDB.

The following are the results of a comparison of the write performance of the CEDA LSS against the Oracle BerkeleyDB (C++ version).

The test involved writing a million (key,value) pairs using 1000 atomic transactions (not flushed) on a laptop which is an x64 Windows 7 platform with a pair of SSDs in RAID0 (striped). In both cases the database used a 512MB cache. Note that certainly for the CEDA LSS the file was unbuffered (i.e. not using the Windows file system cache) (see the code used for the test).

Results with 4096 byte mapped values

With 4096 byte mapped values the total amount of data to be written to disk is about 4GB. For both databases this is 8 times the size of the cache, so the test is dominated by the writing of data to non-volatile storage.

BerkeleyDB was not space efficient. It wrote over 12GB to disk (more than 3 times the amount of actual data). By contrast the CEDA space overhead was tiny (about 0.3%).

BerkeleyDB performance was very poor. It took 2 minutes and 20 seconds using over 1 million write operations while CEDA only took 4 seconds using less than 1000 write operations.

BerkeleyDB used over a million write operations while the CEDA LSS used less than a thousand.

These results were discussed on an Oracle BerkeleyDB forum here.

Results for other sizes of the mapped values are tabulated below. Also shown are results for a B+Tree implemented on top of the CEDA LSS.

Across all the mapped value sizes tested, the CEDA LSS completed the workload between 5.7 and 40 times faster than BerkeleyDB. It also used substantially less disk space and required far fewer write operations.

BerkeleyDB

CEDA LSS

CEDA B+Tree implemented on top of the LSS

BerkeleyDB Test Code

// Test code minus error handling and timing:
void BerkeleyTest(int objectSize)
{
    const char* environPath = "env";
    const char* dbPath = "my_db.db";
    DbEnv env(0);
    env.open(
        environPath,
        DB_CREATE |
            DB_INIT_LOCK |
            DB_INIT_LOG |
            DB_INIT_MPOOL |
            DB_INIT_TXN,
        0);
    Db database(&env, 0);
    database.open(
        NULL,
        dbPath,
        NULL,
        DB_BTREE,
        DB_CREATE | DB_AUTO_COMMIT,
        0);
    __int64 keyid = 0;
    std::vector buffer(objectSize);

    // note: only this for loop is being timed
    for (int i=0 ; i < 1000 ; ++i)
    {
        DbTxn* txn = NULL;
        env.txn_begin(NULL, &txn, 0);
        for (int j=0 ; j < 1000 ; ++j)
        {
            Dbt key(&keyid, sizeof(keyid));
            Dbt data(buffer.data(),objectSize);
            database.put(
                txn,
                &key,
                &data,
                DB_NOOVERWRITE);
            ++keyid;
        }
        txn->commit(0);
    }

    database.close(0);
    env.close(0);
}

# DB_CONFIG
set_cachesize   0       536870912        0
set_flags       DB_TXN_NOSYNC
set_lg_regionmax        1048576
set_lg_max              10485760
set_lg_bsize            2097152

Comparison of I/O

The total number of I/O operations and total I/O bytes for the process were recorded using the Windows Task Manager. The numbers in both the following tables seem repeatable down to the last digit.

BerkeleyDB

These numbers reveal inherent inefficiencies in BDB, particularly for 1024 byte mapped values. It is reading 3x the amount of data it is supposed to be writing!

CEDA LSS