flâneur

(I am a manager of the Data-Perf team at FB which deals with lots of different D... | Hacker News

news.ycombinator.com · 885 words · saved by 1 readers

1. Change buffering for IO bound workloads: If you are IO bound, then InnoDB change buffering is a huge, huge win. It basically is able to reduce IO required for secondary index maintenance by a huge amount. http://dev.mysql.com/doc/innodb/1.1/en/innodb-performance-ch... 2. InnoDB compression: When you are space constrained (say using flash storage), then being able to compress your data is a big win. In our case, it reduces space by around 40% which translates directly to 40% less servers required. While you could do something like run PG on ZFS with compression, for an OLTP workload, you want the compression in the DB so that it can do a lot of work to minimize the compressing and decompressing of data. https://dev.mysql.com/doc/refman/5.6/en/innodb-compression-i... 3. Clustered index: The InnoDB PK is a clustered index. This makes a lot of query patterns (such as range scans of the PK) very cheap. Combined with covering indexes (which PG now has too!), you can really minimize the IO

(I am a manager of the Data-Perf team at FB which deals with lots of different DB technologies) MySQL (specifically InnoDB) is extremely efficient as a storage backend compared to PostgreSQL. There are a few features that make InnoDB better in many cases: 1. Change buffering for IO bound workloads: If you are IO bound, then InnoDB change buffering is a huge, huge win. It basically is able to reduce IO required for secondary index maintenance by a huge amount. http://dev.mysql.com/doc/innodb/1.1/en/innodb-performance-ch... 2. InnoDB compression: When you are space constrained (say using…

related reading