4 ms·
I'm one of the founders of RethinkDB. At no point did we ever work on an in-memory database product. RethinkDB is immediately consistent by default -- in our e
by mglukhovsky 12y ago
I'm one of the founders of RethinkDB. At no point did we ever work on an in-memory database product.
RethinkDB is immediately consistent by default -- in our earlier days we did spend a lot of time optimizing our serializer for solid-state drives. However, we never designed it with, "the tenet that [the database] was 100% in memory."
- nilsimsa 12y agoCurious what kind of optimizations you did for SSDs.
- mglukhovsky 12y agoHere's a few links (from previous HN threads and blog posts) that dive into some of the optimizations we made around SSDs: * https://news.ycombinator.com/item?id=4795443 https://news.ycombinator.com/item?id=4795443 * http://www.rethinkdb.com/blog/on-trim-ncq-and-write-amplification/ http://www.rethinkdb.com/blog/on-trim-ncq-and-write-amplific...
- SamReidHughes 12y agoThe trick involves writing sectors (of size 4K, say, and it can depend on the SSD model) sequentially in aligned blocks (of size 1M, say, but it can depend on the SSD model) so that the SSD firmware that can erase one physical block at a time can handle it efficiently. Especially in 2010.
- bayareaguy 12y agoIf you are interested in SSD optimizations you may want to read this research from Microsoft: The Bw-Tree: A B-tree for New Hardware[1] 1 - http://research.microsoft.com/apps/pubs/default.aspx?id=178758 http://research.microsoft.com/apps/pubs/default.aspx?id=1787...