3 ms·

You have a point in general, because that is how these things usually go, but these guys spent like three years working on the foundation for what they're doing

• andrewflnr 13y ago
  Speaking of which, for the rethink people on the thread, how much of old "key-value store for SSDs" code is still active? Is the document store at all a layer on top of that?
  • SamReidHughes 13y ago
    Most of that code still exists, extensively modified. Here are some things that don't: - Talking to files with libaio -- we now only support use of blocking I/O calls in a thread pool. - Use of block devices instead of files, and code optimized for older SSDs that spread writes to different parts of the disk. - A fsck utility and a utility for extracting data from a corrupted file. Most other stuff has been rewritten and refactored, though -- RethinkDB was once implemented entirely using callbacks on an epoll loop. Then we introduced coroutines (cooperative green threads that sit atop an epoll loop) into the codebase. Nowadays almost everything is implemented in terms of coroutines -- there aren't many APIs left that take a callback and say it'll get called sometime later. There's even still a secret memcache interface. The storage engine itself does a bit more now than it used to. Support for secondary indexes, MVCC, efficiently bringing back out-of-date replicas, and better on-disk storage are the main ones I can think of at this hour.