Postgres is also a good in-memory NoSQL solution. Actually you can use anything really as an in-memory NoSQL solution such as ArangoDB, MySQL, MongoDB, RethinkDB or whatever.
How to choose an in-memory NoSQL solution: Performance measuring
11–20 of 33 posts
Re: How to choose an in-memory NoSQL solution: Performance measuring
#12Sqlite is always a good option if you want in-memory and SQL. Kyotocabinet supports a number of in-memory database types, as does its networked counterpart kyototycoon. BerkeleyDB can be effectively run in memory if you size your cache right, and as a bonus you can build bdb with a sqlite frontend.
Anyway, cool post. For more lua, there's openresty (nginx and lua), and kyototycoon supports lua scripts as well.
Re: How to choose an in-memory NoSQL solution: Performance measuring
#13> Tarantool is an open-source NoSQL database management system and Lua application server developed in my.com. The first version of Tarantool was released in 2008 and the newest version is 1.6.7.
and later
> Through all tests we executed, Tarantool showed the best result for the count requests per second and for many of tests latency values on any type of examined workloads. Therefore, we can decide that for most of typical projects Tarantool suits them more that popular solutions such as Redis, CouchBase or Memcached. This is the basis of our decision to use Tarantool for our projects here at my.com.
So yeah. Obviously.
Re: How to choose an in-memory NoSQL solution: Performance measuring
#14Apache Geode is a distributed, in-memory database (http://geode.incubator.apache.org/).
Re: How to choose an in-memory NoSQL solution: Performance measuring
#15[deleted]
Re: How to choose an in-memory NoSQL solution: Performance measuring
#16Postgres is also a good in-memory NoSQL solution. Actually you can use anything really as an in-memory NoSQL solution such as ArangoDB, MySQL, MongoDB, RethinkDB or whatever.
Do you mean using postgres tablespaces backed by memory or do you mean using a FDW?
If you do mean using a ramdisk tablespace, the postgres docs recommend not doing that. However, if you really want to do that, make sure you attach xlog (the WAL table) to that ramdisk tablespace as well, otherwise every transaction will still hit the disk.
Re: How to choose an in-memory NoSQL solution: Performance measuring
#17Postgres is also a good in-memory NoSQL solution. Actually you can use anything really as an in-memory NoSQL solution such as ArangoDB, MySQL, MongoDB, RethinkDB or whatever.
Do you mean using postgres tablespaces backed by memory or do you mean using a FDW? If you do mean using a ramdisk tablespace, the postgres docs recommend not doing that. However, if you really want to do that, make sure you attach xlog (the WAL table) to that ramdisk tablespace as well, otherwise every transaction will still hit the disk.
Putting tables in RAM and setting the config as you suggest works just fine.
Re: How to choose an in-memory NoSQL solution: Performance measuring
#18Re: How to choose an in-memory NoSQL solution: Performance measuring
#19Why is memcached under-performing? Is it maybe their driver? Or their benchmark? Shouldn't it be similar to Redis, if not a bit faster?
It's a bit fishy that the leading one is by the guys who wrote the article, see https://news.ycombinator.com/item?id=10814318