hamsterdb: release 2.0.0 (stable!)
January 22nd, 2012
After 1.5 years of work and 3 beta-releases I’m really happy to announce that 2.0.0 is finally stable!
Compared to rc3, a few minor performance improvements were added. Also, the interface of ham_txn_begin was changed. This is more or less the first API change since 1.0. I wrote a short migration guide.
Additionally, i added the Java and .NET APIs to the main repository. The Python API will follow with one of the next releases. This will basically force me to always keep them up-to-date. They were neglected for quite a long time.
And finally the webpage was redesigned. Have a look and tell me if you like it!
Hi,
I have read about this benchmark http://www.lessfs.com/wordpress/?p=378 , but I’m looking for HamsterDB benchmark in multi-thread version (single process with multiple thread).
I’m using a development environment which is optimized for high core of processor, that a suitable match for lock-free algorithms. Is HamsterDB suitable and optimized for this kind of system?
regards
-aris
Hi aris,
no, hamsterdb is not multi-threaded. you still need a mutex around it. but multi-threading and concurrency is the big focus for the next couple of months.
bye
Christoph
Hi,
I think, if it I use mutex the performance (write/second) will be similar with another KV store.
There are some lock-free data structure libraries exist recently, but none of them offer persistency and available only in memory.
-aris
Well, i think “lock-free architecture” might have different meanings. In hamsterdb’s case it means that no database pages are locked while a transaction is modifying a page (or rather a key that is stored in a page). You will only benefit from this when using Transactions in parallel (“parallel” means they exist in the same time; it does NOT refer to multi-threading).
Still, Mark from lessfs reported that performance and scalability are really good with 2.0, so it might be worth a try. If you have Transactions which run for some time then some operations are pure in-memory operations (ham_insert w/ HAM_OVERWRITE flag) and they do not require any btree/disk access.