➀ Uber 為什麼從 PostgreSQL 轉用 MySQL？ ➁ PostgreSQL 專家怎麼說？MySQL 專家怎麼回擊？ ➂ 他們說的有沒有道理？

1. 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議
Ant
yftzeng@gmail.com
2016-08-05

2. 2/69
《 Why Uber Engineering Switched from Postgres to MySQL 》
https://eng.uber.com/mysql-migration/
今日的討論主角。

3. 3/69
本次演講為了清楚傳達
會大量使用白板描述

4. 4/69
議程
➀ 跳脫技術及政治鬥爭本位
➁ 架構先決
➂ 探嚢取物

5. 5/69
Ref: http://fortune.com/2016/02/25/uber-patent-just-in-time-rides/
跳脫技術及政治鬥爭本位

6. 6/69
架構先決
《業務需求是什麼》

7. 7/69
2015
➊ 架構先決
無視人員、流程只講技術，是耍白痴
架構會影響公司文化、商業擴展；思維更要超越程式碼層次

8. 8/69
2015
➋ 沒有完美的架構，只有最適的架構
無視場景只講架構，是耍流氓
若無法舉出架構的缺陷，代表你還無法掌握
盲目套用別人的架構，並不會讓你變得跟他一樣好

9. 9/69
2015
➌ 架構是演進的，預想但不過早調優
無視未來只求現有，是耍自閉
兵馬未動，糧草先行，預想下一步，下下一步，甚至下下下一步 ...

10. 10/69
Orient Intensive Capacity
CPU intensive
Memory intensive
Storage/IO intensive
Bandwidth intensive
OLTP
OLAP
Data warehouse
Throughput
Latency
Memory footprint
Bond
Performance
Security
Cost reduction
架構先決
Service-level agreement

11. 11/69
2015
千萬人同時在線
電子商務、線上媒體
低延遲回應
廣告平台 (30ms) 、高頻交易 (0.5~3ms) 、醫療等關鍵設備

12. 12/69
Capacity
架構先決

13. 13/69
Capacity
Optimal capacity
架構先決

14. 14/69
Capacity
Optimal capacity
架構先決

15. 15/69
探嚢取物
为 PostgreSQL 讨说法 – 浅析
《 UBER ENGINEERING SWITCHED FROM POSTGRES TO MYSQL 》
https://yq.aliyun.com/articles/58421
將以這篇討論為主

16. 16/69
《業務需求是什麼》
➀ 更新頻繁 (UPDATE-heavy)
➁ 無模式 (Schemaless)
➂ 異地同步
探嚢取物

17. 17/69
Orient Intensive Capacity
CPU intensive
Memory intensive
Storage/IO intensive
Bandwidth intensive
OLTP
OLAP
Data warehouse
Throughput
Latency
Memory footprint
Bond
Performance
Security
Cost reduction
探嚢取物
Service-level agreement

18. 18/69
《業務需求是什麼》
➀ 更新頻繁 (UPDATE-heavy)
➁ 無模式 (Schemaless)
➂ 異地同步
探嚢取物

19. 19/69
Orient Intensive Capacity
CPU intensive
Memory intensive
Storage/IO intensive
Bandwidth intensive
OLTP
OLAP
Data warehouse
Throughput
Latency
Memory footprint
Bond
Performance
Security
Cost reduction
探嚢取物
Service-level agreement

20. 20/69
《業務需求是什麼》
➀ 更新頻繁 (UPDATE-heavy)
➁ 無模式 (Schemaless)
➂ 異地同步
探嚢取物

21. 21/69
Orient Intensive Capacity
CPU intensive
Memory intensive
Storage/IO intensive
Bandwidth intensive
OLTP
OLAP
Data warehouse
Throughput
Latency
Memory footprint
Bond
Performance
Security
Cost reduction
探嚢取物
Service-level agreement

22. 22/69
《業務需求是什麼》
➀ 更新頻繁 (UPDATE-heavy)
➁ 無模式 (Schemaless)
➂ 異地同步
探嚢取物

23. 23/69
Orient Intensive Capacity
CPU intensive
Memory intensive
Storage/IO intensive
Bandwidth intensive
OLTP
OLAP
Data warehouse
Throughput
Latency
Memory footprint
Bond
Performance
Security
Cost reduction
探嚢取物
Service-level agreement

24. 24/69
Orient Intensive Capacity
CPU intensive
Memory intensive
Storage/IO intensive
Bandwidth intensive
OLTP
OLAP
Data warehouse
Throughput
Latency
Memory footprint
Bond
Performance
Security
Cost reduction
探嚢取物
Service-level agreement

25. 25/69
探嚢取物
MySQL – 回滾段

26. 26/69
探嚢取物
PostgreSQL - MVCC

27. 27/69
探嚢取物
PostgreSQL - MVCC

28. 28/69
探嚢取物
Q ：一般操作時，誰的 UPDATE 較快？

29. 29/69
2015
索引數據結構 : B+tree 索引
資料表：
1 user1 pass1
2 user2 pass2
3 user3 pass3
4 user4 pass4
5 user5 pass5
13
4 7
1 2 3 4 5 6 7

30. 30/69
Ref: https://yq.aliyun.com/articles/58421

31. 31/69
Ref: https://yq.aliyun.com/articles/58421

32. 32/69
Ref: https://yq.aliyun.com/articles/58421

33. 33/69
探嚢取物
Q ：一般操作時，誰的 UPDATE 較快？
InnoDB 需要把 Older row 搬到 Rollback Segment ，
造成 UPDATE 比較慢。
PostgreSQL 是複製該 row 在同一 Page ，
並改 Pointer 。

34. 34/69
《業務需求是什麼》
➀ 更新頻繁 (UPDATE-heavy)
➁ 無模式 (Schemaless)
➂ 異地同步

35. 35/69
探嚢取物
Q ： UPDATE-heavy ？

36. 36/69
探嚢取物
Q ： UPDATE-heavy ？
PostgreSQL 是複製該 row 在同一 Page ，
並改 Pointer 。

37. 37/69
2015
索引頁分裂
觸發：頁剩餘空間 - 保留空間 < 新增資料
問題：頁分裂時會 Latch( 小鎖 )
page
page page
latch
page

38. 38/69
2015
索引頁分裂 : 亂序式新增資料
操作：新增 5( 假設頁只能存三筆資料 )
20
6 12
2 4 6 8 10 12
5
20
4 6 12
2 4 5 6 8 10 12
p1 p1
p2 p2
p4p3 p3 p4p5
latch
fragmentation fragmentation

39. 39/69
探嚢取物
Q ： PostgreSQL HOT-updated ？

40. 40/69
探嚢取物
Q ： PostgreSQL HOT-updated ？
HOT-updated 是有條件的：
➀ 只有在所有索引屬性都沒有被更新時才能使用 HOT
➁ 只有在被更新記錄所在頁面能夠存儲新版本時才能用 HOT

41. 41/69
探嚢取物
Q ： PostgreSQL HOT-updated ？
HOT-updated 是有條件的：
➀ 只有在所有索引屬性都沒有被更新時才能使用 HOT
為了目標的 Column 可支援 HOT-updated ，
勢必就不行加上索引，損失 Read 效能。 ( 三個月沒登入的會員 ? )
➁ 只有在被更新記錄所在頁面能夠存儲新版本時才能用 HOT
UPDATE-heavy 下， fillfactor 要調更小，
浪費的空間更多， I/O 開銷更大。
PostgreSQL 預設 100% ，博主使用 80% ， 8K*20%=1.6K 為空，
假設 Record Size 200 bytes ， 1.6K 約可放 8.2 個。

42. 42/69
探嚢取物
Q ： MySQL 的 Primary Key 更新的開銷非常大？

43. 43/69
探嚢取物
Q ： MySQL 的 Primary Key 更新的開銷非常大？
PostgreSQL 更新的 Column 為 Index 時，
沒有 HOT-updated 效果，且全 Index 皆需要更新。
MySQL 雖然沒有這個問題，但若是 Primary Key 更新時，
問題也是很嚴重。

44. 44/69
探嚢取物
Q ： MySQL 的 Primary Key 更新的開銷非常大？
PostgreSQL 更新的 Column 為 Index 時，
沒有 HOT-updated 效果，且全 Index 皆需要更新。
MySQL 雖然沒有這個問題，但若是 Primary Key 更新時，
問題也是很嚴重。
但通常 Primary Key 是不會更新的。

45. 45/69
探嚢取物

46. 46/69
《業務需求是什麼》
➀ 更新頻繁 (UPDATE-heavy)
➁ 無模式 (Schemaless)
➂ 異地同步

47. 47/69
探嚢取物
Q ：寫次數放大？

48. 48/69
探嚢取物
Q ：寫次數放大？
➀ 場景一： Primary Key 更新時
➁ 場景二： N 個 Secondary Index 中的 1 個更新時
➂ 場景三：更新的欄位不是 Index 時

49. 49/69
探嚢取物
Q ：寫次數放大？
➀ 場景一： Primary Key 更新時
➊ 更新的 Row 在原長度內
(MySQL) ? I/O
(PostgreSQL) ? I/O
➋ 更新的 Row 不在原長度內，且發生 Page split
(MySQL) ? I/O
(PostgreSQL) ? I/O

50. 50/69
探嚢取物
Q ：寫次數放大？
➁ 場景二： 1 個 Secondary Index 中的 1 個更新時
➊ 更新的 Row 在原長度內
(MySQL) ? I/O
(PostgreSQL) ? I/O
➋ 更新的 Row 不在原長度內，且發生 Page split
(MySQL) ? I/O
(PostgreSQL) ? I/O

51. 51/69
探嚢取物
Q ：寫次數放大？
➁ 場景二： N 個 Secondary Index 中的 1 個更新時
➊ 更新的 Row 在原長度內
(MySQL) ? I/O
(PostgreSQL) ? I/O
➋ 更新的 Row 不在原長度內，且發生 Page split
(MySQL) ? I/O
(PostgreSQL) ? I/O

52. 52/69
探嚢取物
Q ：寫次數放大？
➂ 場景三：更新的欄位不是 Index 時
➊ 更新的 Row 在原長度內
(MySQL) ? I/O
(PostgreSQL HOT-updated) ? I/O
➋ 更新的 Row 不在原長度內，且發生 Page split
(MySQL) ? I/O
(PostgreSQL) ? I/O

53. 53/69
《業務需求是什麼》
➀ 更新頻繁 (UPDATE-heavy)
➁ 無模式 (Schemaless)
➂ 異地同步

54. 54/69
探嚢取物
Q ：長事務？

55. 55/69
探嚢取物
Q ：長事務？
InnoDB 回滾 Rollback Segment 很昂貴。
尤其當長事務常發生時，可能常讀取 Older data ，效能很差。

56. 56/69
探嚢取物
Q ：長事務？
InnoDB 回滾 Rollback Segment 很昂貴。
尤其當長事務常發生時，可能常讀取 Older data ，效能很差。
但通常事務 (transaction) 回滾的機率是低的。

57. 57/69
探嚢取物
Q ：作者：看我文章中的測試嗎，每秒 13 萬持續強力更新壓測
我的測試機 AWS EC2 c4.xlarge (4 vCPU)

58. 58/69

59. 59/69

60. 60/69
2015
High Concurrent Write?(Hotspot:UPDATE)
《 MySQL 》
直接 UPDATE 在同一 Row ，通常不會造成該 Page 的大小變化。
《 PostgreSQL 》
盡量在同一 Page 寫入新的 Row ，但若該 Page 空間不足時，則
會另新建一 Page 寫入。
Fragmentation ？ VACUUM ？

61. 61/69
2015
High Concurrent Write?(Hotspot:UPDATE)
《 PostgreSQL 》
PostgreSQL 天生容易遇到 Index bloat 的問題。
Ref: PostgreSQL 9.0 High Performance [PACKT] (2010) (p171)

62. 62/69
2015
High Concurrent Write?(Hotspot:UPDATE)
Ref: http://www.slideshare.net/denishpatel/deploying-maximum-ha-architecture-with-postgresql (p28)

63. 63/69
《業務需求是什麼》
➀ 更新頻繁 (UPDATE-heavy)
➁ 無模式 (Schemaless)
➂ 異地同步

64. 64/69
異地同步
Q ： Physical replication vs. Logical replication?
MySQL 只有 Logical replication ；
PostgreSQL 9.4 之前只有 Physical replication 。

65. 65/69
異地同步
Q ： Physical replication vs. Logical replication?
PostgreSQL 送出 WAL ，而 MySQL 送出 commands 。
送出 WAL 有一些問題，因為它是直接修改 disk 的資料，
所以可能會造成一些問題。包括 data corruption 導致
整個資料庫下線。
它對於 versioning 版本號的問題非常敏感，
並且如果無法確保我們能支持很多 versioning 版本號的
replicating 到同一台機器時，這會變得非常困難。

66. 66/69
異地同步
Q ： Physical replication vs. Logical replication?
Physical replication 比 logical replication 快，
因為它在 replication stream 中含 index pointer ，
允許 insert 直接進到 index ，比需要先找到該 index
位置再 insert 快。
這很有效率，但確實 replication bandwidth 需要比較多。

67. 67/69
異地同步
Q ： Physical replication vs. Logical replication?
statement-based replication 對 bandwidth 較有效率。
但對接收端的伺服器效能並不好。
且可能導致很多 replication 非預期的問題，導致需要排錯。

68. 68/69
最後
PostgreSQL 開發團隊開始深入思考 Uber 遇到的問題，
並著手改善，其中包括 HOT 的寫入次數放大問題。

69. 69/69
i
Ref: https://www.postgresql.org/message-id/CABOikdMop5Rb_RnS2xFdAXMZGSqcJ-P-BY2ruMd%2BbuUkJ4iDPw%40mail.gmail.com