FastDB is an open-source, in-memory database that's tightly integrated with C++ (it supports a SQL-like query language where tables are classes and rows are objects). Like most IMDBs, it's meant for applications dominated by read access patterns. The algorithms and data structures are optimized for systems that read and write data entirely in main memory (RAM). It's supposed to be very fast, even compared to other in-memory databases, but I can't find any benchmarks online.
I'm considering using FastDB for time-series data, in a project where 1) sub-millisecond random-access read latencies, and 2) millions of rows per second sequential read throughput would be very good to have.
I can't find many references to first-hand experience with FastDB; has anyone here used it? Can you point to any benchmarks of FastDB, especially those that consider read latency and throughput?
A recent post on an Erlang forum (from 2009): http://www.trapexit.org/forum/viewtopic.php?p=49476#49476 has someone (Serge Aleynikov) recommending FastDB for trading systems with sub-millisecond latencies:
If you don't want to spend too much time coding C++, since you have
already done good work of abstracting mnesia backend, why don't you
create an Erlang driver for this database: www.fastdb.org. It's based
on memory mapped files, implemented in C++, is relatively fast compared
to other in-memory databases (about 250k lookups/s, 50k inserts/s), has
time-series capabilities, simple C-API. I implemented FastDB interface
in several languages, and generally it's good for systems that deal with
latencies in sub-milliseconds range. It may suffice for you unless you
need to stay in the low microseconds realm.
My 2c.
Serge
It's pretty intimidating to see people worrying about latencies in the low microseconds; I'm considering FastDB for digital signal processing (DSP), where live audio systems generally limit latency to no more than about 10 milliseconds. Of course, if a system responds in milliseconds, we might use input pulses of only a few microseconds in length.
There's no mention of what system was used for the 250K lookups/s, 50K inserts/s. Still, it's a positive sign.
