Наш ответ Uber'у / Александр Коротков (Postgres Professional)

Наш ответ Uber’у
Александр Коротков
Postgres Professional

Russian developers of PostgreSQL:
Alexander Korotkov, Teodor Sigaev, Oleg Bartunov
▶ Speakers at PGCon, PGConf: 20+ talks
▶ GSoC mentors
▶ PostgreSQL commi ers (1+1 in progress)
▶ Conference organizers
▶ 50+ years of expertship: development, audit, consul ng
▶ Postgres Professional co-founders
PostgreSQL CORE
▶ Locale support
▶ PostgreSQL extendability:
GiST(KNN), GIN, SP-GiST
▶ Full Text Search (FTS)
▶ NoSQL (hstore, jsonb)
▶ Indexed regexp search
▶ Create AM & Generic WAL
▶ Table engines (WIP)
Extensions
▶ intarray
▶ pg_trgm
▶ ltree
▶ hstore
▶ plantuner
▶ jsquery
▶ RUM
▶ imgsmlr
Alexander Korotkov Наш ответ Uber’у 2 / 31

Disclaimer
▶ I’m NOT a MySQL expert. I didn’t even touch MySQL since 2011...
▶ This talk express my own opinion, not PostgreSQL community
posi on, not even Postgres Professional oﬃcial posi on.
▶ Uber’s guys knows be er which database they should use.

What happened?
▶ Uber migrated from MySQL to PostgreSQL in 2012.
▶ Uber migrated from PostgreSQL to MySQL in 2016.
▶ PostgreSQL to MySQL migra on made a log of buzz in PostgreSQL
community.

Why did it happen?
▶ Uber migrated from MySQL to PostgreSQL for “a bunch of reasons,
but one of the most important was availability of PostGIS” ¹
▶ Uber migrated from PostgreSQL to MySQL “some of the drawbacks
they found with Postgres” ²
¹https://www.yumpu.com/en/document/view/53683323/migrating-uber-from-mysql-to-postgresql
²https://eng.uber.com/mysql-migration/

Uber’s complaints to PostgreSQL
Uber claims following “PostgreSQL limita ons”:
▶ Inefficient architecture for writes
▶ Inefficient data replica on
▶ Issues with table corrup on
▶ Poor replica MVCC support
▶ Difficulty upgrading to newer releases

PostgreSQL’s vs. InnoDB’s storage formats

PostgreSQL storage format
▶ Both primary and secondary indexes point to loca on (blkno, oﬀset) of tuple (row
version) in the heap.
▶ When tuple is moved to another loca on, all corresponding index tuples should be
inserted to the indexes.
▶ Heap contains both live and dead tuples.
▶ VACUUM cleans up dead tuples and corresponding index tuples in a bulk manner.

Update in PostgreSQL
▶ New tuple is inserted to the heap, previous tuple is marked as
deleted.
▶ Index tuples poin ng to new tuple are inserted to all indexes.

Heap-Only-Tuple (HOT) PostgreSQL
▶ When no indexed columns are updated and new version of row can
ﬁt the same page, then HOT is used and only heap is updated.
▶ Microvacuum can be used to free required space in the page for HOT.

Update in MySQL
▶ Table rows are placed in the primary index itself. Updates are performed in-place.
Old version of rows are placed to special segment (undo log).
▶ When secondary indexed column is updated, then new index tuple is inserted while
previous index tuple is marked as deleted.

Updates: InnoDB in comparison with PostgreSQL
Pro:
▶ Update of few indexed columns is cheaper.
▶ Update, which don’t touch indexed columns, doesn’t depend on page
free space in the page
Cons:
▶ Update of majority of indexed columns is more expensive.
▶ Secondary index scan is slower.
▶ Primary key update is disaster.

Uber example for write-ampliﬁca on in PostgreSQL
CREATE TABLE users (id SERIAL PRIMARY KEY,
first TEXT,
last TEXT,
birth_year INTEGER);
CREATE INDEX ix_users_first_last ON users (first, last);
CREATE INDEX ix_users_birth_year ON users (birth_year);
UPDATE users SET birth_year = 1986 WHERE id = 1;
1. Write the new row tuple to the tablespace
2. Update the primary key index to add a record for the new tuple
3. Update the (ﬁrst, last) index to add a record for the new tuple
4. Update the birth_year index to add a record for the new tuple
5. Previous ac ons are protected by WAL log.

Uber example for write-ampliﬁca on: MySQL vs. PostgreSQL

Uber example for write-ampliﬁca on: MySQL vs. PostgreSQL
PostgreSQL
1. Write the new row tuple to the
tablespace
2. Insert new tuple to primary key index
3. Insert new tuple to (ﬁrst, last) index
4. Insert new tuple to birth_year index
5. Previous ac ons are protected by WAL
log.
MySQL
1. Update row in-place
2. Write old version of row to the rollback
segment
3. Insert new tuple to birth_year index
4. Mark old tuple of birth_year index as
obsolete
5. Previous ac ons are protected by
innodb log
6. Write update record to binary log
Assuming we have replica on turned on

Pending patches: WARM (write-ampliﬁca on reduc on
method)
▶ Behaves like HOT, but works also when some of index columns are
updated.
▶ New index tuples are inserted only for updated index columns.
https://www.postgresql.org/message-id/flat/20170110192442.ocws4pu5wjxcf45b%40alvherre.pgsql

Pending patches: indirect indexes
▶ Indirect indexes are indexes which points to primary key value instead of pointer to
heap.
▶ Indirect index is not updates un l corresponding column is updated.
https://www.postgresql.org/message-id/20161018182843.xczrxsa2yd47pnru@alvherre.pgsql

Ideas: RDS (recently dead store)
▶ Recently dead tuples (deleted but visible for some transac ons) are
displaced into special storage: RDS.
▶ Heap tuple headers are le in the heap.

Idea: undo log
▶ Displace old version of rows to undo log.
▶ New index tuples are inserted only for updated index columns. Old index tuples are
marked as expired.
▶ Move row to another page if new version doesn’t ﬁt the page.
https://www.postgresql.org/message-id/flat/CA%2BTgmoZS4_CvkaseW8dUcXwJuZmPhdcGBoE_
GNZXWWn6xgKh9A%40mail.gmail.com

Idea: pluggable table engines
Owns
▶ Ways to scan and modify tables.
▶ Access methods implementa ons.
Shares
▶ Transac ons, snapshots.
▶ WAL.
https://www.pgcon.org/2016/schedule/events/920.en.html

Types of replica on
▶ Statement-level – stream wri ng queries to the slave.
▶ Row-level – stream updated rows to the slave.
▶ Block-level – stream blocks and/or block deltas to the slave.

Replica on types in PostgreSQL vs. MySQL
Replica on Type MySQL PostgreSQL
Statement-level buil n pgPool-II
Row-level buil n pgLogical
Londiste
Slony ...
Block-level N/A buil n

Uber’s replica on comparison
▶ Uber compares MySQL replica on versus PostgreSQL replica on.
▶ Actually, Uber compares MySQL row-level replica on versus
PostgreSQL block-level replica on.
▶ That happened because that me PostgreSQL had buil n block-level
replica on, but didn’t have buil n row-level replica on.
Simultaneously, MySQL had buil n row-level replica on, but didn’t
have buil n block-level replica on.

Uber’s complaints to PostgreSQL block-level replica on
▶ Replica on stream transfers all the changes at block-level including
“write-ampliﬁca on”. Thus, it requires very high-bandwidth channel.
In turn, that makes geo-distributed replica on harder.
▶ There are MVCC limita ons for read-only requires on replica. Apply of
VACUUM changes conﬂicts with read-only queries which could see
the data VACUUM is going to delete.

Is row-level replica on superior over block-level replica on?
Alibaba works on adding block-level replica on to InnoDB. Zhai Weixiang,
database developer from Alibaba considers following advantages of
block-level replica on: ³
▶ Be er performance: higher throughput and lower response me
▶ Write less data (turn oﬀ binary log and g d), and only one fsync to make
transac on durable
▶ Less recovery me
▶ Replica on
▶ Less replica on latency
▶ Ensure data consistency (most important for some sensi ve clients)
³https://www.percona.com/live/data-performance-conference-2016/sessions/
physical-replication-based-innodb

Replica read-only query MVCC conﬂict with VACUUM
Possible op ons:
▶ Delay the replica on,
▶ Cancel read-only query on replica,
▶ Provide a feedback to master about row versions which could be demanded.
Undo log would do be er, we wouldn’t have to choose...

More about replica on and write-ampliﬁca on
MySQL row-level replica on
PostgreSQL row-level replica on (pgLogical)

Major version upgrade with pg_upgrade

Major version upgrade with pgLogical
https://www.depesz.com/2016/11/08/major-version-upgrading-with-minimal-downtime/

Other Uber notes
▶ PostgreSQL 9.2 had data corrup on bug. It was fixed long me ago. Since that me
PostgreSQL automated tests system was significantly improved to evade such bugs in future.
▶ pread is faster than seek + read. Thats really gives 1.5% accelera on on read-only
benchmark. ⁴
▶ PostgreSQL advises to setup rela vely small shared_buffers and rely on OS cache, while
“InnoDB storage engine implements its own LRU in something it calls the InnoDB buffer
pool”. PostgreSQL also implements its own LRU in something it calls the shared buffers. And
you can setup any shared buffers size.
▶ PostgreSQL uses mul process model. So, connec on is more expensive since unless you
use pgBouncer or other external connec on pool.
⁴https://www.postgresql.org/message-id/flat/a86bd200-ebbe-d829-e3ca-0c4474b2fcb7%40ohmu.fi

Thank you for a en on!

Наш ответ Uber'у / Александр Коротков (Postgres Professional)

Recommended

Recommended

More Related Content

More from Ontico

More from Ontico (20)

Recently uploaded

Recently uploaded (20)

Наш ответ Uber'у / Александр Коротков (Postgres Professional)