5 ms·

Related: Why Uber Engineering Switched from Postgres to MySQL https://eng.uber.com/mysql-migration/ https://eng.uber.com/mysql-migration/ Edit: This is above

• rosser 9y ago
  Vacuuming is not why Uber flounced off PostgreSQL. They were naïvely using it as a KV store, and indexing every column, which caused a write-amplification cascade. Edit, re: the parent's edit: Quoting that article, "Perhaps the thorniest problem which Uber raises is that of write amplification caused by secondary index updates." The word "vacuum" is mentioned exactly once, in the context of keeping up with index insertions (writes).
  • warent 9y ago
    Lol. If that's true (and I'm not disputing it) then how would switching to MySQL fix that problem?
    • noncoml 9y ago
      > Lol. If that's true (and I'm not disputing it) then how would switching to MySQL fix that problem? It's explained in the blog the great-grandparent linked: https://eng.uber.com/mysql-migration/ https://eng.uber.com/mysql-migration/
      • rosser 9y ago
        Uber's explanation of the problem neglects to consider their poor usage of the tool as contributory to the problem.
        • dozzie 9y ago
          That's why there were so many rebuttals to their arguments.
        • Thaxll 9y ago
          Even Postgres dev ack the problem they had, don't try to dismiss the issue it's real.
          • jtc331 9y ago
            There is a real issue, yes, but it’s heavily lessened by using sane scheme design, while Uber basically used the worst possible design.
          • rosser 9y ago
            Can you point out where I dismissed anything? PostgreSQL has a write-amplification issue — especially when you index every column on a table. My point is: if you don't do that, it doesn't hurt.
    • rosser 9y ago
      Writes in postgres touch all indexes. When you index every column, you have to touch every column's index for every write. Writes in MySQL (using InnoDB) just touch the pkey index, to which all other indexes point, or something like that. (Can someone who knows MySQL innards better — I avoid it like it's contagious — please confirm or clarify?)
      • blaisio 9y ago
        That's correct.
    • dragonwriter 9y ago
      Postgres’s MVCC implementation with immutable tuples means every write to a table affecting any index touches every index on that table. Excessive indexing will have a performance hit in any DB, but combined with Postgres’s architecture it’s particularly bad.
      • anarazel 9y ago
        > Postgres’s MVCC implementation with immutable tuples means every write (even updates to a column not in any indexes) to a table touches every index on that table. The parenthetical comment is not true. If no indexed columns are updated, and there's space on the same page, a so called "HOT" update is performed. Basically a redirection is inserted triggering index scans to follow the update chain to the newest version: https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/access/heap/README.HOT&hb=HEAD https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f...
        • dragonwriter 9y ago
          Edited the comment to correct the error in my original understanding; thanks for pointing it out!
      • deleted 9y ago
        [deleted]
    • jtc331 9y ago
      The other thing here they downplay in the article is that they didn’t switch to MySQL per se; they implemented a columnar storage backend within MySQL. It’d have been more accurate to say they abandoned traditional relational databases entirely.