5 ms·

SSD's should result in huge performance boosts, especially with nosql systems like MongoDB & CouchDB. Can't wait until the prices start to drop!

Nate75Sanders 16y ago
I would have thought the biggest performance boost would have come for databases based on B-tree-like structures on large datasets. You have to read to read and read to write. Every depth of the tree that doesn't fit into main memory costs you a random read, whether to read or write.
- jbellis 16y ago
  Write amplification (http://en.wikipedia.org/wiki/Write_amplification http://en.wikipedia.org/wiki/Write_amplification) means that naive random writes like what you see from b-trees are going to degrade performance on SSDs too (although not as pathologically as doing rotational seeks). In other words it still pays to be smart about i/o patterns.
  - eru 16y ago
    Shouldn't you be able to do mostly sequential writes if you have a b-tree structure and a copy-on-write filesystem (like btrfs)?
    - eru 16y ago
      Plus the occasional GC. But you can do this while idle.
ergo98 16y ago
>SSD's should result in huge performance boosts, especially with nosql systems like MongoDB & CouchDB. This is entirely backwards. NoSQL solutions tend to trade space for reduced I/O, whereas a relational database trades I/O for reduced space.
- jbooth 16y ago
  Not really. Both systems wind up IO-bound very quickly if you're out of memory. NoSQL systems might get to a higher number of requests/second before flatlining, but they're still fundamentally disk bound unless your dataset fits in memory.
  - ergo98 16y ago
    I was specifically replying to the "especially" bit. The net benefit of an SSD is far less pronounced with many NoSQL solutions (in particular document stores) than with relational databases. That's because the former was built and adopted largely to make lemonade out of the I/O problem (particularly on terrible I/O platforms like AWS).

Nate75Sanders 16y ago

I would have thought the biggest performance boost would have come for databases based on B-tree-like structures on large datasets. You have to read to read and read to write. Every depth of the tree that doesn't fit into main memory costs you a random read, whether to read or write.

jbellis 16y ago
Write amplification (http://en.wikipedia.org/wiki/Write_amplification http://en.wikipedia.org/wiki/Write_amplification) means that naive random writes like what you see from b-trees are going to degrade performance on SSDs too (although not as pathologically as doing rotational seeks). In other words it still pays to be smart about i/o patterns.
- eru 16y ago
  Shouldn't you be able to do mostly sequential writes if you have a b-tree structure and a copy-on-write filesystem (like btrfs)?
  - eru 16y ago
    Plus the occasional GC. But you can do this while idle.

ergo98 16y ago

>SSD's should result in huge performance boosts, especially with nosql systems like MongoDB & CouchDB. This is entirely backwards. NoSQL solutions tend to trade space for reduced I/O, whereas a relational database trades I/O for reduced space.

jbooth 16y ago
Not really. Both systems wind up IO-bound very quickly if you're out of memory. NoSQL systems might get to a higher number of requests/second before flatlining, but they're still fundamentally disk bound unless your dataset fits in memory.
- ergo98 16y ago
  I was specifically replying to the "especially" bit. The net benefit of an SSD is far less pronounced with many NoSQL solutions (in particular document stores) than with relational databases. That's because the former was built and adopted largely to make lemonade out of the I/O problem (particularly on terrible I/O platforms like AWS).