fastdb java,有没有人有FastDB（C ++内存数据库）的任何经验？

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.