[erlang-questions] Selecting a speedy NoSQL datastore

[Michael Truog]

By Tokyo Cabinet, do you mean Tokyo Tyrant? (i.e., the server front-end
to Tokyo Cabinet)

Zubair Quraishi wrote:
> 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 <hd2010@REDACTED> 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:erlang-questions-unsubscribe@REDACTED
>>>
>>>
>>>
>>>       
>>     
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>
>
>