談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議
-
Upload
yi-feng-tzeng -
Category
Technology
-
view
493 -
download
3
Transcript of 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議
![Page 2: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/2.jpg)
2/69
《 Why Uber Engineering Switched from Postgres to MySQL 》
https://eng.uber.com/mysql-migration/
今日的討論主角。
![Page 3: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/3.jpg)
3/69
本次演講為了清楚傳達
會大量使用白板描述
![Page 4: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/4.jpg)
4/69
議程
➀跳脫技術及政治鬥爭本位
➁架構先決
➂探嚢取物
![Page 5: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/5.jpg)
5/69Ref: http://fortune.com/2016/02/25/uber-patent-just-in-time-rides/
跳脫技術及政治鬥爭本位
![Page 6: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/6.jpg)
6/69
架構先決
《業務需求是什麼》
![Page 7: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/7.jpg)
7/692015
➊架構先決 無視人員、流程只講技術,是耍白痴
架構會影響公司文化、商業擴展;思維更要超越程式碼層次
![Page 8: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/8.jpg)
8/692015
➋沒有完美的架構,只有最適的架構無視場景只講架構,是耍流氓
若無法舉出架構的缺陷,代表你還無法掌握
盲目套用別人的架構,並不會讓你變得跟他一樣好
![Page 9: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/9.jpg)
9/692015
➌架構是演進的,預想但不過早調優無視未來只求現有,是耍自閉
兵馬未動,糧草先行,預想下一步,下下一步,甚至下下下一步 ...
![Page 10: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/10.jpg)
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
![Page 11: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/11.jpg)
11/692015
千萬人同時在線電子商務、線上媒體
低延遲回應廣告平台 (30ms) 、高頻交易 (0.5~3ms) 、醫療等關鍵設備
![Page 12: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/12.jpg)
12/69
Capacity
架構先決
![Page 13: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/13.jpg)
13/69
Capacity
Optimal capacity
架構先決
![Page 14: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/14.jpg)
14/69
Capacity
Optimal capacity
架構先決
![Page 15: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/15.jpg)
15/69
探嚢取物
为 PostgreSQL 讨说法 – 浅析《 UBER ENGINEERING SWITCHED FROM POSTGRES TO MYSQL 》
https://yq.aliyun.com/articles/58421
將以這篇討論為主
![Page 16: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/16.jpg)
16/69
《業務需求是什麼》
➀更新頻繁 (UPDATE-heavy)
➁無模式 (Schemaless)
➂異地同步
探嚢取物
![Page 17: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/17.jpg)
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
![Page 18: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/18.jpg)
18/69
《業務需求是什麼》
➀更新頻繁 (UPDATE-heavy)
➁無模式 (Schemaless)
➂異地同步
探嚢取物
![Page 19: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/19.jpg)
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
![Page 20: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/20.jpg)
20/69
《業務需求是什麼》
➀更新頻繁 (UPDATE-heavy)
➁無模式 (Schemaless)
➂異地同步
探嚢取物
![Page 21: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/21.jpg)
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
![Page 22: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/22.jpg)
22/69
《業務需求是什麼》
➀更新頻繁 (UPDATE-heavy)
➁無模式 (Schemaless)
➂異地同步
探嚢取物
![Page 23: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/23.jpg)
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
![Page 24: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/24.jpg)
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
![Page 25: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/25.jpg)
25/69
探嚢取物
MySQL – 回滾段
![Page 26: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/26.jpg)
26/69
探嚢取物
PostgreSQL - MVCC
![Page 27: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/27.jpg)
27/69
探嚢取物
PostgreSQL - MVCC
![Page 28: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/28.jpg)
28/69
探嚢取物
Q :一般操作時,誰的 UPDATE 較快?
![Page 29: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/29.jpg)
29/692015
索引數據結構 : 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
![Page 33: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/33.jpg)
33/69
探嚢取物
Q :一般操作時,誰的 UPDATE 較快?
InnoDB 需要把 Older row 搬到 Rollback Segment ,造成 UPDATE 比較慢。
PostgreSQL 是複製該 row 在同一 Page ,並改 Pointer 。
![Page 34: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/34.jpg)
34/69
《業務需求是什麼》
➀更新頻繁 (UPDATE-heavy)
➁無模式 (Schemaless)
➂異地同步
![Page 35: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/35.jpg)
35/69
探嚢取物
Q : UPDATE-heavy ?
![Page 36: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/36.jpg)
36/69
探嚢取物
Q : UPDATE-heavy ?
PostgreSQL 是複製該 row 在同一 Page ,並改 Pointer 。
![Page 37: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/37.jpg)
37/692015
索引頁分裂
觸發:頁剩餘空間 -保留空間<新增資料問題:頁分裂時會 Latch(小鎖 )
page
page page
latch
page
![Page 38: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/38.jpg)
38/692015
索引頁分裂 : 亂序式新增資料
操作:新增 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
![Page 39: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/39.jpg)
39/69
探嚢取物
Q : PostgreSQL HOT-updated ?
![Page 40: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/40.jpg)
40/69
探嚢取物
Q : PostgreSQL HOT-updated ?
HOT-updated 是有條件的:
➀只有在所有索引屬性都沒有被更新時才能使用 HOT
➁只有在被更新記錄所在頁面能夠存儲新版本時才能用 HOT
![Page 41: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/41.jpg)
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 個。
![Page 42: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/42.jpg)
42/69
探嚢取物
Q : MySQL 的 Primary Key 更新的開銷非常大?
![Page 43: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/43.jpg)
43/69
探嚢取物
Q : MySQL 的 Primary Key 更新的開銷非常大?
PostgreSQL 更新的 Column 為 Index 時,沒有 HOT-updated 效果,且全 Index 皆需要更新。
MySQL 雖然沒有這個問題,但若是 Primary Key 更新時,問題也是很嚴重。
![Page 44: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/44.jpg)
44/69
探嚢取物
Q : MySQL 的 Primary Key 更新的開銷非常大?
PostgreSQL 更新的 Column 為 Index 時,沒有 HOT-updated 效果,且全 Index 皆需要更新。
MySQL 雖然沒有這個問題,但若是 Primary Key 更新時,問題也是很嚴重。
但通常 Primary Key 是不會更新的。
![Page 45: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/45.jpg)
45/69
探嚢取物
![Page 46: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/46.jpg)
46/69
《業務需求是什麼》
➀更新頻繁 (UPDATE-heavy)
➁無模式 (Schemaless)
➂異地同步
![Page 47: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/47.jpg)
47/69
探嚢取物
Q :寫次數放大?
![Page 48: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/48.jpg)
48/69
探嚢取物
Q :寫次數放大?
➀場景一: Primary Key 更新時
➁場景二: N 個 Secondary Index中的 1 個更新時
➂場景三:更新的欄位不是 Index 時
![Page 49: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/49.jpg)
49/69
探嚢取物
Q :寫次數放大?
➀場景一: Primary Key 更新時
➊更新的 Row 在原長度內
(MySQL) ? I/O
(PostgreSQL) ? I/O
➋更新的 Row 不在原長度內,且發生 Page split
(MySQL) ? I/O
(PostgreSQL) ? I/O
![Page 50: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/50.jpg)
50/69
探嚢取物
Q :寫次數放大?
➁場景二: 1 個 Secondary Index中的 1 個更新時
➊更新的 Row 在原長度內
(MySQL) ? I/O
(PostgreSQL) ? I/O
➋更新的 Row 不在原長度內,且發生 Page split
(MySQL) ? I/O
(PostgreSQL) ? I/O
![Page 51: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/51.jpg)
51/69
探嚢取物
Q :寫次數放大?
➁場景二: N 個 Secondary Index中的 1 個更新時
➊更新的 Row 在原長度內
(MySQL) ? I/O
(PostgreSQL) ? I/O
➋更新的 Row 不在原長度內,且發生 Page split
(MySQL) ? I/O
(PostgreSQL) ? I/O
![Page 52: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/52.jpg)
52/69
探嚢取物
Q :寫次數放大?
➂場景三:更新的欄位不是 Index 時
➊更新的 Row 在原長度內
(MySQL) ? I/O
(PostgreSQL HOT-updated) ? I/O
➋更新的 Row 不在原長度內,且發生 Page split
(MySQL) ? I/O
(PostgreSQL) ? I/O
![Page 53: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/53.jpg)
53/69
《業務需求是什麼》
➀更新頻繁 (UPDATE-heavy)
➁無模式 (Schemaless)
➂異地同步
![Page 54: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/54.jpg)
54/69
探嚢取物
Q :長事務?
![Page 55: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/55.jpg)
55/69
探嚢取物
Q :長事務?
InnoDB 回滾 Rollback Segment 很昂貴。
尤其當長事務常發生時,可能常讀取 Older data ,效能很差。
![Page 56: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/56.jpg)
56/69
探嚢取物
Q :長事務?
InnoDB 回滾 Rollback Segment 很昂貴。
尤其當長事務常發生時,可能常讀取 Older data ,效能很差。
但通常事務 (transaction) 回滾的機率是低的。
![Page 57: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/57.jpg)
57/69
探嚢取物
Q :作者:看我文章中的測試嗎,每秒 13萬持續強力更新壓測
我的測試機AWS EC2 c4.xlarge (4 vCPU)
![Page 58: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/58.jpg)
58/69
![Page 59: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/59.jpg)
59/69
![Page 60: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/60.jpg)
60/692015
High Concurrent Write?(Hotspot:UPDATE)
《MySQL》
直接 UPDATE在同一 Row,通常不會造成該 Page的大小變化。
《 PostgreSQL》
盡量在同一 Page寫入新的 Row,但若該 Page空間不足時,則會另新建一 Page寫入。
Fragmentation? VACUUM?
![Page 61: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/61.jpg)
61/692015
High Concurrent Write?(Hotspot:UPDATE)
《 PostgreSQL》
PostgreSQL天生容易遇到 Index bloat的問題。
Ref: PostgreSQL 9.0 High Performance [PACKT] (2010) (p171)
![Page 62: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/62.jpg)
62/692015
High Concurrent Write?(Hotspot:UPDATE)
Ref: http://www.slideshare.net/denishpatel/deploying-maximum-ha-architecture-with-postgresql (p28)
![Page 63: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/63.jpg)
63/69
《業務需求是什麼》
➀更新頻繁 (UPDATE-heavy)
➁無模式 (Schemaless)
➂異地同步
![Page 64: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/64.jpg)
64/69
異地同步
Q : Physical replication vs. Logical replication?
MySQL 只有 Logical replication;
PostgreSQL 9.4之前只有 Physical replication 。
![Page 65: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/65.jpg)
65/69
異地同步
Q : Physical replication vs. Logical replication?
PostgreSQL送出WAL ,而MySQL送出 commands 。
送出WAL 有一些問題,因為它是直接修改 disk 的資料,所以可能會造成一些問題。包括 data corruption導致整個資料庫下線。
它對於 versioning 版本號的問題非常敏感,並且如果無法確保我們能支持很多 versioning 版本號的replicating 到同一台機器時,這會變得非常困難。
![Page 66: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/66.jpg)
66/69
異地同步
Q : Physical replication vs. Logical replication?
Physical replication 比 logical replication 快,因為它在 replication stream中含 index pointer ,允許 insert直接進到 index ,比需要先找到該 index位置再 insert 快。
這很有效率,但確實 replication bandwidth 需要比較多。
![Page 67: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/67.jpg)
67/69
異地同步
Q : Physical replication vs. Logical replication?
statement-based replication對 bandwidth 較有效率。但對接收端的伺服器效能並不好。
且可能導致很多 replication 非預期的問題,導致需要排錯。
![Page 68: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/68.jpg)
68/69
最後
PostgreSQL 開發團隊開始深入思考Uber遇到的問題,並著手改善,其中包括HOT 的寫入次數放大問題。
![Page 69: 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議](https://reader031.fdocuments.net/reader031/viewer/2022012402/587e85351a28abd6038b7365/html5/thumbnails/69.jpg)
69/69
i
Ref: https://www.postgresql.org/message-id/CABOikdMop5Rb_RnS2xFdAXMZGSqcJ-P-BY2ruMd%2BbuUkJ4iDPw%40mail.gmail.com