SSD: All content tagged as SSD in NoSQL databases and polyglot persistence
I didn’t know too much about RethinkDB until watching Tim Anglade’s interview with Slava Akhmechet and Mike Glukhovsky. There were mainly three things that caught my attention:
RethinkDB is firstly building a persistent memcached compatible solution to work with SSD. The reason for starting with a memcached-compatible system is that building it is much simpler than implementing a MySQL storage engine. On the other hand I think that having a persistent memcached might bring RethinkDB some customers to validate the technology.
Even if announced in 8-10 weeks at the time of the interview, I don’t think this implementation has been launched yet. Update: according to Tim, RethinkDB technology has been available to private beta users for a while now. But I still couldn’t find any reference to it on either the website or blog.
Next will come a MySQL engine optimized for SSD
- Replacing rotational disks with SSD shows an immediate bump in performance. But shortly after (months) performance seriously degrades.
It is this last point that I haven’t heard before. And I’d really be interested to understand:
- if it applies to all scenarios or if it is related to databases in general
- are there specific database scenarios (access patterns, read/write ratios) that lead to this behavior or will it manifest in general cases too
My current assumption is that this behavior occurs for write intensive databases only. But I’d really like to hear some better documented answers.
Update: First answer I got to the above questions comes from Travis Truman: The SSD Anthology: Understanding SSDs and New Drives from OCZ.
Update: RethinkDB guys have published a follow up: On TRIM, NCQ, and write amplification.