Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議
Search
Yi-Feng Tzeng
August 05, 2016
Technology
4
470
談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議
➀ Uber 為什麼從 PostgreSQL 轉用 MySQL?
➁ PostgreSQL 專家怎麼說?MySQL 專家怎麼回擊?
➂ 他們說的有沒有道理?
Yi-Feng Tzeng
August 05, 2016
Tweet
Share
More Decks by Yi-Feng Tzeng
See All by Yi-Feng Tzeng
重新想像:如何做技術選型決策 / Rethinking : Technical Decision
yftzeng
7
1.8k
擁抱開源:企業應如何善用開源技術,才能得其利而防其弊 - 加強版
yftzeng
0
150
Testing in Production, Deploy on Fridays
yftzeng
0
2.8k
COSCUP 2020 Day 1 - Opening Keynote
yftzeng
0
68
COSCUP 2020 Day 2 - Opening Keynote
yftzeng
0
78
Severless PHP Case : Agile Dashboard via GitLab Board API
yftzeng
0
120
Dev(Sec)Ops: Architecture for Security and Compliance
yftzeng
0
180
給資安工程師開源授權觀念
yftzeng
0
81
Progressive Deployment & NoDeploy
yftzeng
0
150
Other Decks in Technology
See All in Technology
Amazon_CloudWatch_ログ異常検出_導入ガイド
tsujiba
5
1.6k
AWS CDKでデータリストアの運用、どのように設計する?~Aurora・EFSの実践事例を紹介~/aws-cdk-data-restore-aurora-efs
mhrtech
4
670
10分でわかるfreeeのQA
freee
1
3.4k
話題のGraphRAG、その可能性と課題を理解する
hide212131
4
1.5k
pandasはPolarsに性能面で追いつき追い越せるのか
vaaaaanquish
4
4.7k
なんで、私がAWS Heroに!? 〜社外の広い世界に一歩踏み出そう〜
minorun365
PRO
6
1.1k
日経電子版におけるリアルタイムレコメンドシステム開発の事例紹介/nikkei-realtime-recommender-system
yng87
1
520
ネット広告に未来はあるか?「3rd Party Cookie廃止とPrivacy Sandboxの効果検証の裏側」 / third-party-cookie-privacy
cyberagentdevelopers
PRO
1
140
【技術書典17】OpenFOAM(自宅で極める流体解析)2次元円柱まわりの流れ
kamakiri1225
0
220
20241031_AWS_生成AIハッカソン_GenMuck
tsumita
0
110
小規模に始めるデータメッシュとデータガバナンスの実践
kimujun
3
600
AIを駆使したゲーム開発戦略: 新設AI組織の取り組み / sge-ai-strategy
cyberagentdevelopers
PRO
1
130
Featured
See All Featured
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
191
16k
Why You Should Never Use an ORM
jnunemaker
PRO
53
9k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
Building Your Own Lightsaber
phodgson
102
6.1k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.2k
VelocityConf: Rendering Performance Case Studies
addyosmani
325
24k
Teambox: Starting and Learning
jrom
132
8.7k
Statistics for Hackers
jakevdp
796
220k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
328
21k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.1k
YesSQL, Process and Tooling at Scale
rocio
167
14k
Optimizing for Happiness
mojombo
376
69k
Transcript
談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議 Ant
[email protected]
2016-08-05
2/69 《 Why Uber Engineering Switched from Postgres to MySQL
》 https://eng.uber.com/mysql-migration/ 今日的討論主角。
3/69 本次演講為了清楚傳達 會大量使用白板描述
4/69 議程 ➀ 跳脫技術及政治鬥爭本位 ➁ 架構先決 ➂ 探嚢取物
5/69 Ref: http://fortune.com/2016/02/25/uber-patent-just-in-time-rides/ 跳脫技術及政治鬥爭本位
6/69 架構先決 《業務需求是什麼》
7/69 2015 ➊ 架構先決 無視人員、流程只講技術,是耍白痴 架構會影響公司文化、商業擴展;思維更要超越程式碼層次
8/69 2015 ➋ 沒有完美的架構,只有最適的架構 無視場景只講架構,是耍流氓 若無法舉出架構的缺陷,代表你還無法掌握 盲目套用別人的架構,並不會讓你變得跟他一樣好
9/69 2015 ➌ 架構是演進的,預想但不過早調優 無視未來只求現有,是耍自閉 兵馬未動,糧草先行,預想下一步,下下一步,甚至下下下一步 ...
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/69 2015 千萬人同時在線 電子商務、線上媒體 低延遲回應 廣告平台 (30ms) 、高頻交易 (0.5~3ms) 、醫療等關鍵設備
12/69 Capacity 架構先決
13/69 Capacity Optimal capacity 架構先決
14/69 Capacity Optimal capacity 架構先決
15/69 探嚢取物 为 PostgreSQL 讨说法 – 浅析 《 UBER ENGINEERING
SWITCHED FROM POSTGRES TO MYSQL 》 https://yq.aliyun.com/articles/58421 將以這篇討論為主
16/69 《業務需求是什麼》 ➀ 更新頻繁 (UPDATE-heavy) ➁ 無模式 (Schemaless) ➂ 異地同步
探嚢取物
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/69 《業務需求是什麼》 ➀ 更新頻繁 (UPDATE-heavy) ➁ 無模式 (Schemaless) ➂ 異地同步
探嚢取物
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/69 《業務需求是什麼》 ➀ 更新頻繁 (UPDATE-heavy) ➁ 無模式 (Schemaless) ➂ 異地同步
探嚢取物
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/69 《業務需求是什麼》 ➀ 更新頻繁 (UPDATE-heavy) ➁ 無模式 (Schemaless) ➂ 異地同步
探嚢取物
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/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/69 探嚢取物 MySQL – 回滾段
26/69 探嚢取物 PostgreSQL - MVCC
27/69 探嚢取物 PostgreSQL - MVCC
28/69 探嚢取物 Q :一般操作時,誰的 UPDATE 較快?
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/69 Ref: https://yq.aliyun.com/articles/58421
31/69 Ref: https://yq.aliyun.com/articles/58421
32/69 Ref: https://yq.aliyun.com/articles/58421
33/69 探嚢取物 Q :一般操作時,誰的 UPDATE 較快? InnoDB 需要把 Older row
搬到 Rollback Segment , 造成 UPDATE 比較慢。 PostgreSQL 是複製該 row 在同一 Page , 並改 Pointer 。
34/69 《業務需求是什麼》 ➀ 更新頻繁 (UPDATE-heavy) ➁ 無模式 (Schemaless) ➂ 異地同步
35/69 探嚢取物 Q : UPDATE-heavy ?
36/69 探嚢取物 Q : UPDATE-heavy ? PostgreSQL 是複製該 row 在同一
Page , 並改 Pointer 。
37/69 2015 索引頁分裂 觸發:頁剩餘空間 - 保留空間 < 新增資料 問題:頁分裂時會 Latch(
小鎖 ) page page page latch page
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
39/69 探嚢取物 Q : PostgreSQL HOT-updated ?
40/69 探嚢取物 Q : PostgreSQL HOT-updated ? HOT-updated 是有條件的: ➀
只有在所有索引屬性都沒有被更新時才能使用 HOT ➁ 只有在被更新記錄所在頁面能夠存儲新版本時才能用 HOT
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/69 探嚢取物 Q : MySQL 的 Primary Key 更新的開銷非常大?
43/69 探嚢取物 Q : MySQL 的 Primary Key 更新的開銷非常大? PostgreSQL
更新的 Column 為 Index 時, 沒有 HOT-updated 效果,且全 Index 皆需要更新。 MySQL 雖然沒有這個問題,但若是 Primary Key 更新時, 問題也是很嚴重。
44/69 探嚢取物 Q : MySQL 的 Primary Key 更新的開銷非常大? PostgreSQL
更新的 Column 為 Index 時, 沒有 HOT-updated 效果,且全 Index 皆需要更新。 MySQL 雖然沒有這個問題,但若是 Primary Key 更新時, 問題也是很嚴重。 但通常 Primary Key 是不會更新的。
45/69 探嚢取物
46/69 《業務需求是什麼》 ➀ 更新頻繁 (UPDATE-heavy) ➁ 無模式 (Schemaless) ➂ 異地同步
47/69 探嚢取物 Q :寫次數放大?
48/69 探嚢取物 Q :寫次數放大? ➀ 場景一: Primary Key 更新時 ➁
場景二: N 個 Secondary Index 中的 1 個更新時 ➂ 場景三:更新的欄位不是 Index 時
49/69 探嚢取物 Q :寫次數放大? ➀ 場景一: Primary Key 更新時 ➊
更新的 Row 在原長度內 (MySQL) ? I/O (PostgreSQL) ? I/O ➋ 更新的 Row 不在原長度內,且發生 Page split (MySQL) ? I/O (PostgreSQL) ? I/O
50/69 探嚢取物 Q :寫次數放大? ➁ 場景二: 1 個 Secondary Index
中的 1 個更新時 ➊ 更新的 Row 在原長度內 (MySQL) ? I/O (PostgreSQL) ? I/O ➋ 更新的 Row 不在原長度內,且發生 Page split (MySQL) ? I/O (PostgreSQL) ? I/O
51/69 探嚢取物 Q :寫次數放大? ➁ 場景二: N 個 Secondary Index
中的 1 個更新時 ➊ 更新的 Row 在原長度內 (MySQL) ? I/O (PostgreSQL) ? I/O ➋ 更新的 Row 不在原長度內,且發生 Page split (MySQL) ? I/O (PostgreSQL) ? I/O
52/69 探嚢取物 Q :寫次數放大? ➂ 場景三:更新的欄位不是 Index 時 ➊ 更新的
Row 在原長度內 (MySQL) ? I/O (PostgreSQL HOT-updated) ? I/O ➋ 更新的 Row 不在原長度內,且發生 Page split (MySQL) ? I/O (PostgreSQL) ? I/O
53/69 《業務需求是什麼》 ➀ 更新頻繁 (UPDATE-heavy) ➁ 無模式 (Schemaless) ➂ 異地同步
54/69 探嚢取物 Q :長事務?
55/69 探嚢取物 Q :長事務? InnoDB 回滾 Rollback Segment 很昂貴。 尤其當長事務常發生時,可能常讀取
Older data ,效能很差。
56/69 探嚢取物 Q :長事務? InnoDB 回滾 Rollback Segment 很昂貴。 尤其當長事務常發生時,可能常讀取
Older data ,效能很差。 但通常事務 (transaction) 回滾的機率是低的。
57/69 探嚢取物 Q :作者:看我文章中的測試嗎,每秒 13 萬持續強力更新壓測 我的測試機 AWS EC2 c4.xlarge
(4 vCPU)
58/69
59/69
60/69 2015 High Concurrent Write?(Hotspot:UPDATE) 《 MySQL 》 直接 UPDATE
在同一 Row ,通常不會造成該 Page 的大小變化。 《 PostgreSQL 》 盡量在同一 Page 寫入新的 Row ,但若該 Page 空間不足時,則 會另新建一 Page 寫入。 Fragmentation ? VACUUM ?
61/69 2015 High Concurrent Write?(Hotspot:UPDATE) 《 PostgreSQL 》 PostgreSQL 天生容易遇到
Index bloat 的問題。 Ref: PostgreSQL 9.0 High Performance [PACKT] (2010) (p171)
62/69 2015 High Concurrent Write?(Hotspot:UPDATE) Ref: http://www.slideshare.net/denishpatel/deploying-maximum-ha-architecture-with-postgresql (p28)
63/69 《業務需求是什麼》 ➀ 更新頻繁 (UPDATE-heavy) ➁ 無模式 (Schemaless) ➂ 異地同步
64/69 異地同步 Q : Physical replication vs. Logical replication? MySQL
只有 Logical replication ; PostgreSQL 9.4 之前只有 Physical replication 。
65/69 異地同步 Q : Physical replication vs. Logical replication? PostgreSQL
送出 WAL ,而 MySQL 送出 commands 。 送出 WAL 有一些問題,因為它是直接修改 disk 的資料, 所以可能會造成一些問題。包括 data corruption 導致 整個資料庫下線。 它對於 versioning 版本號的問題非常敏感, 並且如果無法確保我們能支持很多 versioning 版本號的 replicating 到同一台機器時,這會變得非常困難。
66/69 異地同步 Q : Physical replication vs. Logical replication? Physical
replication 比 logical replication 快, 因為它在 replication stream 中含 index pointer , 允許 insert 直接進到 index ,比需要先找到該 index 位置再 insert 快。 這很有效率,但確實 replication bandwidth 需要比較多。
67/69 異地同步 Q : Physical replication vs. Logical replication? statement-based
replication 對 bandwidth 較有效率。 但對接收端的伺服器效能並不好。 且可能導致很多 replication 非預期的問題,導致需要排錯。
68/69 最後 PostgreSQL 開發團隊開始深入思考 Uber 遇到的問題, 並著手改善,其中包括 HOT 的寫入次數放大問題。
69/69 i Ref: https://www.postgresql.org/message-id/CABOikdMop5Rb_RnS2xFdAXMZGSqcJ-P-BY2ruMd%2BbuUkJ4iDPw%40mail.gmail.com