Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

12/69 Capacity 架構先決

Slide 13

Slide 13 text

13/69 Capacity Optimal capacity 架構先決

Slide 14

Slide 14 text

14/69 Capacity Optimal capacity 架構先決

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

26/69 探嚢取物 PostgreSQL - MVCC

Slide 27

Slide 27 text

27/69 探嚢取物 PostgreSQL - MVCC

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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 p4 p3 p3 p4 p5 latch fragmentation fragmentation

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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 個。

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

45/69 探嚢取物

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

58/69

Slide 59

Slide 59 text

59/69

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

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