Hacker News Reader

Comment by coreymgilmore | Hacker News Reader

Thoughts on using this as a cache instead of memcache or redis? Yes, it does not have nearly as many features or functions but when raw performance is needed I could see this working (given an api for using this via Node.JS, PHP, etc.).

View on HN

You'd be better off using MemcacheDB/LMDB http://symas.com/mdb/memcache/

You seem to have written a great piece of software that you're very proud. I don't understand the ownership very well, but if you're allowed, why don't you promote your database with its own site, like every little javascript library out there?

Good examples: http://duktape.org/ (it might seem silly but that right column makes people want to try it!), http://redis.io (i bet this page wins many folks http://redis.io/topics/twitter-clone)

why even pay the cost of memory mapping if its a transient embedded cache not shared between servers?

just use a std::unordered_map, or better yet a tbb::concurrent_unordered_map or whatever the equivalent is for your language

Because it will persist between restarts?

then it seems strange to call it a cache.

It could be a cache to a much slower backend. I pull a lot of stock price and other data to my server which is is slow - 200-1000ms per series. I cache it in postgres which allows me to load it nearly instantaneously. It also allows me access to data while I'm disconnected.

Another reason to cache to disk is that you want to store more data than you have ram.

Because it's shared between processes on the same server.

In theory STL implementations, if used with a custom allocator, should be able to pull this off... that's why the STL containers all have internal 'pointer' typedefs.

Practically speaking, Boost.Interprocess includes a shared memory hash table implementation. Boost Multi Index, which is a further generalisation of containers to allow the construction of database-like indexes, is also Interprocess compatible.

http://www.boost.org/doc/libs/1_57_0/doc/html/interprocess/a...

Reply on news.ycombinator.com