[erlang-questions] Selecting a speedy NoSQL datastore

Zubair Quraishi <>
Tue Feb 23 20:59:10 CET 2010


I have personally used Riak, Tokyo Cabinet, and Redis. Redis is by far
the best performing data store at the moment, and you also have disk
based support for the values.

On Tue, Feb 23, 2010 at 8:25 PM, Henning Diedrich <> wrote:
> Redis and Tokyo are written in C, not sure if that was meant with "powered
> by".
>
> The Erlang DBs are generally more about distribution, thus scalable. Redis
> and Tokyo are about speed.
>
> Henning
>
> Masklinn wrote:
>>
>> On 23 Feb 2010, at 19:33 , Hank Knight wrote:
>>
>>>
>>> There are an abundance of NoSQL datastores powered by Erlang.
>>>
>>> Riak, CouchDB, Dynomite and Scalaris to name a few.
>>>
>>> I need to select a datastore for a logging application.
>>>
>>> We anticipate 1,000+ write transitions per second and 100+ read
>>> transactions per second.
>>>
>>> There will be about two dozen columns and each of the columns will
>>> store between 200 and 800 bytes of data.
>>>
>>> The hosted solution will be served on a cloud.
>>>
>>> Speed is important.  Please help me select a datastore with
>>> low-latency and high scalability.
>>>
>>
>> Disclaimer: I don't have any involvement in nor experience with any of the
>> systems below, those are just the results of my readings and thus
>> "suggestions to try out" rather than "suggestions to use"
>>
>> As far as I know, the most stable and best performing NoSQL dbs right now
>> seem to be Redis and Tokyo Tyrant. You might want to take them for a drive,
>> either is apparently able to handle about 10000 transactions (read or write)
>> per second on a *small* EC2 instance (see
>> http://michalf.me/blog:redis-performance for instance for Redis). Note that
>> I dont know how the performance scales with the size of the tables, don't
>> forget to test for that (e.g. some solutions might completely crumble once
>> you reach a few dozen million records).
>>
>> MySQL Cluster (the Cluster part is important) might also be a target worth
>> considering.
>> ________________________________________________________________
>> erlang-questions (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:
>>
>>
>>
>
>


More information about the erlang-questions mailing list