[erlang-questions] Kai - An Open Source Implementation of Amazon's Dynamo

Takeru INOUE takeru.inoue@REDACTED
Mon Jul 14 16:09:52 CEST 2008

>> Thank you for detailed explanation.
>> I understand that tcerl has no disadvantage against dets in architectural point.
>> Don't you have any benchmark results?
> tcerl appears faster than dets on simple benchmarks (e.g., random inserts
> and deletes of random small (e.g, size (erlang:term_to_binary (X)) < 32)
> erlang terms), until the scale of the data gets to the point that the O
> (log N) loses to the O (1), which occurs around the 10 million record
> point, after which dets becomes progressively better at equality lookup. i
> say appears because i don't put much stock in such benchmarks, they never
> seem to correspond to actual usage.  it was more for me to make sure i
> didn't do something horribly inefficient in the driver.
> our main motivation for tcerl was ordered_set on disk. we didn't have any
> particular performance difficulty with dets for equality queries, and the
> file size problem never really bothered us since we heavily use fragmented
> tables for availability and load balancing anyway.  we just do alot of
> range queries in our particular application.

I understood performance characteristics of dets and tecrl.
These discussions are quite helpful for us.

>> To make installation easy, we're planning to support dets or mnesia first.
>> But I'd like to support tcerl as next step for better performance.
> well, if you target mnesia, you can then use tcerl via the mnesia storage
> API extension.
> http://code.google.com/p/mnesiaex/

Cool, tecrl has mnesia API.

> -- p
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions

  Takeru INOUE <takeru.inoue@REDACTED>

More information about the erlang-questions mailing list