Enviar pesquisa
Carregar
談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議
•
17 gostaram
•
4,374 visualizações
Yi-Feng Tzeng
Seguir
➀ Uber 為什麼從 PostgreSQL 轉用 MySQL? ➁ PostgreSQL 專家怎麼說?MySQL 專家怎麼回擊? ➂ 他們說的有沒有道理?
Leia menos
Leia mais
Tecnologia
Denunciar
Compartilhar
Denunciar
Compartilhar
1 de 69
Baixar agora
Baixar para ler offline
Recomendados
淺入淺出 MySQL & PostgreSQL
淺入淺出 MySQL & PostgreSQL
Yi-Feng Tzeng
善用 MySQL 及 PostgreSQL - RDBMS 的逆襲 - part1
善用 MySQL 及 PostgreSQL - RDBMS 的逆襲 - part1
Yi-Feng Tzeng
資料庫索引數據結構及主鍵設計(b+tree)(part 1)
資料庫索引數據結構及主鍵設計(b+tree)(part 1)
Yi-Feng Tzeng
恰如其分的 MySQL 設計技巧 [Modern Web 2016]
恰如其分的 MySQL 設計技巧 [Modern Web 2016]
Yi-Feng Tzeng
Linuxのユーザーランドをinitから全てまるごとgolangで書く
Linuxのユーザーランドをinitから全てまるごとgolangで書く
Tetsuyuki Kobayashi
YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)
YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)
NTT DATA Technology & Innovation
binary log と 2PC と Group Commit
binary log と 2PC と Group Commit
Takanori Sejima
JavaScriptでSQLを唱えたいだけの人生だった
JavaScriptでSQLを唱えたいだけの人生だった
iPride Co., Ltd.
Recomendados
淺入淺出 MySQL & PostgreSQL
淺入淺出 MySQL & PostgreSQL
Yi-Feng Tzeng
善用 MySQL 及 PostgreSQL - RDBMS 的逆襲 - part1
善用 MySQL 及 PostgreSQL - RDBMS 的逆襲 - part1
Yi-Feng Tzeng
資料庫索引數據結構及主鍵設計(b+tree)(part 1)
資料庫索引數據結構及主鍵設計(b+tree)(part 1)
Yi-Feng Tzeng
恰如其分的 MySQL 設計技巧 [Modern Web 2016]
恰如其分的 MySQL 設計技巧 [Modern Web 2016]
Yi-Feng Tzeng
Linuxのユーザーランドをinitから全てまるごとgolangで書く
Linuxのユーザーランドをinitから全てまるごとgolangで書く
Tetsuyuki Kobayashi
YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)
YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)
NTT DATA Technology & Innovation
binary log と 2PC と Group Commit
binary log と 2PC と Group Commit
Takanori Sejima
JavaScriptでSQLを唱えたいだけの人生だった
JavaScriptでSQLを唱えたいだけの人生だった
iPride Co., Ltd.
まずやっとくPostgreSQLチューニング
まずやっとくPostgreSQLチューニング
Kosuke Kida
Zabbix最新情報 ~Zabbix 6.0に向けて~ @OSC2021 Online/Fall
Zabbix最新情報 ~Zabbix 6.0に向けて~ @OSC2021 Online/Fall
Atsushi Tanaka
図解gitworkflows(7)
図解gitworkflows(7)
ktateish
HITCON駭客戰隊與CTF經驗分享
HITCON駭客戰隊與CTF經驗分享
Alan Lee
Pacemaker + PostgreSQL レプリケーション構成(PG-REX)のフェイルオーバー高速化
Pacemaker + PostgreSQL レプリケーション構成(PG-REX)のフェイルオーバー高速化
kazuhcurry
Solving PostgreSQL wicked problems
Solving PostgreSQL wicked problems
Alexander Korotkov
爆速クエリエンジン”Presto”を使いたくなる話
爆速クエリエンジン”Presto”を使いたくなる話
Kentaro Yoshida
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
Takuto Wada
速習!論理レプリケーション ~基礎から最新動向まで~(PostgreSQL Conference Japan 2022 発表資料)
速習!論理レプリケーション ~基礎から最新動向まで~(PostgreSQL Conference Japan 2022 発表資料)
NTT DATA Technology & Innovation
こわくない Git
こわくない Git
Kota Saito
ヤフー社内でやってるMySQLチューニングセミナー大公開
ヤフー社内でやってるMySQLチューニングセミナー大公開
Yahoo!デベロッパーネットワーク
PostgreSQLでスケールアウト
PostgreSQLでスケールアウト
Masahiko Sawada
他山の石勉強会 DRBD編
他山の石勉強会 DRBD編
tkomachi
PostgreSQL14の pg_stat_statements 改善(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL14の pg_stat_statements 改善(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
PEGで構文解析をする
PEGで構文解析をする
jiro4989
「速」を落とさないコードレビュー
「速」を落とさないコードレビュー
Takafumi ONAKA
祝!PostgreSQLレプリケーション10周年!徹底紹介!!
祝!PostgreSQLレプリケーション10周年!徹底紹介!!
NTT DATA Technology & Innovation
O/Rマッパーによるトラブルを未然に防ぐ
O/Rマッパーによるトラブルを未然に防ぐ
kwatch
PostgreSQLバックアップの基本
PostgreSQLバックアップの基本
Uptime Technologies LLC (JP)
MySQL InnoDB Clusterによる高可用性構成(DB Tech Showcase 2017)
MySQL InnoDB Clusterによる高可用性構成(DB Tech Showcase 2017)
Shinya Sugiyama
軟體接案自由職業者 (Freelancer) 意想不到的風險
軟體接案自由職業者 (Freelancer) 意想不到的風險
Yi-Feng Tzeng
Enterprise Architecture Case in PHP (MUZIK Online)
Enterprise Architecture Case in PHP (MUZIK Online)
Yi-Feng Tzeng
Mais conteúdo relacionado
Mais procurados
まずやっとくPostgreSQLチューニング
まずやっとくPostgreSQLチューニング
Kosuke Kida
Zabbix最新情報 ~Zabbix 6.0に向けて~ @OSC2021 Online/Fall
Zabbix最新情報 ~Zabbix 6.0に向けて~ @OSC2021 Online/Fall
Atsushi Tanaka
図解gitworkflows(7)
図解gitworkflows(7)
ktateish
HITCON駭客戰隊與CTF經驗分享
HITCON駭客戰隊與CTF經驗分享
Alan Lee
Pacemaker + PostgreSQL レプリケーション構成(PG-REX)のフェイルオーバー高速化
Pacemaker + PostgreSQL レプリケーション構成(PG-REX)のフェイルオーバー高速化
kazuhcurry
Solving PostgreSQL wicked problems
Solving PostgreSQL wicked problems
Alexander Korotkov
爆速クエリエンジン”Presto”を使いたくなる話
爆速クエリエンジン”Presto”を使いたくなる話
Kentaro Yoshida
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
Takuto Wada
速習!論理レプリケーション ~基礎から最新動向まで~(PostgreSQL Conference Japan 2022 発表資料)
速習!論理レプリケーション ~基礎から最新動向まで~(PostgreSQL Conference Japan 2022 発表資料)
NTT DATA Technology & Innovation
こわくない Git
こわくない Git
Kota Saito
ヤフー社内でやってるMySQLチューニングセミナー大公開
ヤフー社内でやってるMySQLチューニングセミナー大公開
Yahoo!デベロッパーネットワーク
PostgreSQLでスケールアウト
PostgreSQLでスケールアウト
Masahiko Sawada
他山の石勉強会 DRBD編
他山の石勉強会 DRBD編
tkomachi
PostgreSQL14の pg_stat_statements 改善(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL14の pg_stat_statements 改善(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
PEGで構文解析をする
PEGで構文解析をする
jiro4989
「速」を落とさないコードレビュー
「速」を落とさないコードレビュー
Takafumi ONAKA
祝!PostgreSQLレプリケーション10周年!徹底紹介!!
祝!PostgreSQLレプリケーション10周年!徹底紹介!!
NTT DATA Technology & Innovation
O/Rマッパーによるトラブルを未然に防ぐ
O/Rマッパーによるトラブルを未然に防ぐ
kwatch
PostgreSQLバックアップの基本
PostgreSQLバックアップの基本
Uptime Technologies LLC (JP)
MySQL InnoDB Clusterによる高可用性構成(DB Tech Showcase 2017)
MySQL InnoDB Clusterによる高可用性構成(DB Tech Showcase 2017)
Shinya Sugiyama
Mais procurados
(20)
まずやっとくPostgreSQLチューニング
まずやっとくPostgreSQLチューニング
Zabbix最新情報 ~Zabbix 6.0に向けて~ @OSC2021 Online/Fall
Zabbix最新情報 ~Zabbix 6.0に向けて~ @OSC2021 Online/Fall
図解gitworkflows(7)
図解gitworkflows(7)
HITCON駭客戰隊與CTF經驗分享
HITCON駭客戰隊與CTF經驗分享
Pacemaker + PostgreSQL レプリケーション構成(PG-REX)のフェイルオーバー高速化
Pacemaker + PostgreSQL レプリケーション構成(PG-REX)のフェイルオーバー高速化
Solving PostgreSQL wicked problems
Solving PostgreSQL wicked problems
爆速クエリエンジン”Presto”を使いたくなる話
爆速クエリエンジン”Presto”を使いたくなる話
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
速習!論理レプリケーション ~基礎から最新動向まで~(PostgreSQL Conference Japan 2022 発表資料)
速習!論理レプリケーション ~基礎から最新動向まで~(PostgreSQL Conference Japan 2022 発表資料)
こわくない Git
こわくない Git
ヤフー社内でやってるMySQLチューニングセミナー大公開
ヤフー社内でやってるMySQLチューニングセミナー大公開
PostgreSQLでスケールアウト
PostgreSQLでスケールアウト
他山の石勉強会 DRBD編
他山の石勉強会 DRBD編
PostgreSQL14の pg_stat_statements 改善(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL14の pg_stat_statements 改善(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
PEGで構文解析をする
PEGで構文解析をする
「速」を落とさないコードレビュー
「速」を落とさないコードレビュー
祝!PostgreSQLレプリケーション10周年!徹底紹介!!
祝!PostgreSQLレプリケーション10周年!徹底紹介!!
O/Rマッパーによるトラブルを未然に防ぐ
O/Rマッパーによるトラブルを未然に防ぐ
PostgreSQLバックアップの基本
PostgreSQLバックアップの基本
MySQL InnoDB Clusterによる高可用性構成(DB Tech Showcase 2017)
MySQL InnoDB Clusterによる高可用性構成(DB Tech Showcase 2017)
Destaque
軟體接案自由職業者 (Freelancer) 意想不到的風險
軟體接案自由職業者 (Freelancer) 意想不到的風險
Yi-Feng Tzeng
Enterprise Architecture Case in PHP (MUZIK Online)
Enterprise Architecture Case in PHP (MUZIK Online)
Yi-Feng Tzeng
Redis, another step on the road
Redis, another step on the road
Yi-Feng Tzeng
PHPConf.TW 2012: A step to better PHP
PHPConf.TW 2012: A step to better PHP
Yi-Feng Tzeng
2013-04-13_JSTW-security-for-frontend-engineer (前傳)
2013-04-13_JSTW-security-for-frontend-engineer (前傳)
Yi-Feng Tzeng
The Future of Classical Music
The Future of Classical Music
Yi-Feng Tzeng
20130112 web conf-面向網站經營者及網站用戶的個資法衝擊
20130112 web conf-面向網站經營者及網站用戶的個資法衝擊
Yi-Feng Tzeng
[BizLePro] 主題講座 #4:給資訊人的智財導論_20130429_richard
[BizLePro] 主題講座 #4:給資訊人的智財導論_20130429_richard
Yi-Feng Tzeng
[BizLePro] 主題講座 #5:台灣C2C第三方支付服務之發展_20130513_gillight
[BizLePro] 主題講座 #5:台灣C2C第三方支付服務之發展_20130513_gillight
Yi-Feng Tzeng
[BizLePro] 主題講座 #7:商業利用怎麼行? - 從開源授權十個常見 FAQ 來了解
[BizLePro] 主題講座 #7:商業利用怎麼行? - 從開源授權十個常見 FAQ 來了解
Yi-Feng Tzeng
2013-05-18_JSDC.TW-security-for-frontend-engineer-final (後傳)
2013-05-18_JSDC.TW-security-for-frontend-engineer-final (後傳)
Yi-Feng Tzeng
2014-10-25 App 及 Maker 開發者防身術 (MOPCON 2014)
2014-10-25 App 及 Maker 開發者防身術 (MOPCON 2014)
Yi-Feng Tzeng
2014-04-24 社群經營的法律議題-ant
2014-04-24 社群經營的法律議題-ant
Yi-Feng Tzeng
2016 ModernWeb 分享 - 恰如其分 MySQL 程式設計 (修)
2016 ModernWeb 分享 - 恰如其分 MySQL 程式設計 (修)
Win Yu
無瑕的程式碼 Clean Code 心得分享
無瑕的程式碼 Clean Code 心得分享
Win Yu
[CBLP] 個資法雙連發-怪怪的個資法-ox-20130225
[CBLP] 個資法雙連發-怪怪的個資法-ox-20130225
Yi-Feng Tzeng
2014 03-14 PunApp-InstAll15-山寨的界限
2014 03-14 PunApp-InstAll15-山寨的界限
Yi-Feng Tzeng
Video Face Recognition , Pattern Recognition Final Report
Video Face Recognition , Pattern Recognition Final Report
Win Yu
大型 Web Application 轉移到微服務的經驗分享
大型 Web Application 轉移到微服務的經驗分享
Andrew Wu
接案公司的日子
接案公司的日子
Hokila Jan
Destaque
(20)
軟體接案自由職業者 (Freelancer) 意想不到的風險
軟體接案自由職業者 (Freelancer) 意想不到的風險
Enterprise Architecture Case in PHP (MUZIK Online)
Enterprise Architecture Case in PHP (MUZIK Online)
Redis, another step on the road
Redis, another step on the road
PHPConf.TW 2012: A step to better PHP
PHPConf.TW 2012: A step to better PHP
2013-04-13_JSTW-security-for-frontend-engineer (前傳)
2013-04-13_JSTW-security-for-frontend-engineer (前傳)
The Future of Classical Music
The Future of Classical Music
20130112 web conf-面向網站經營者及網站用戶的個資法衝擊
20130112 web conf-面向網站經營者及網站用戶的個資法衝擊
[BizLePro] 主題講座 #4:給資訊人的智財導論_20130429_richard
[BizLePro] 主題講座 #4:給資訊人的智財導論_20130429_richard
[BizLePro] 主題講座 #5:台灣C2C第三方支付服務之發展_20130513_gillight
[BizLePro] 主題講座 #5:台灣C2C第三方支付服務之發展_20130513_gillight
[BizLePro] 主題講座 #7:商業利用怎麼行? - 從開源授權十個常見 FAQ 來了解
[BizLePro] 主題講座 #7:商業利用怎麼行? - 從開源授權十個常見 FAQ 來了解
2013-05-18_JSDC.TW-security-for-frontend-engineer-final (後傳)
2013-05-18_JSDC.TW-security-for-frontend-engineer-final (後傳)
2014-10-25 App 及 Maker 開發者防身術 (MOPCON 2014)
2014-10-25 App 及 Maker 開發者防身術 (MOPCON 2014)
2014-04-24 社群經營的法律議題-ant
2014-04-24 社群經營的法律議題-ant
2016 ModernWeb 分享 - 恰如其分 MySQL 程式設計 (修)
2016 ModernWeb 分享 - 恰如其分 MySQL 程式設計 (修)
無瑕的程式碼 Clean Code 心得分享
無瑕的程式碼 Clean Code 心得分享
[CBLP] 個資法雙連發-怪怪的個資法-ox-20130225
[CBLP] 個資法雙連發-怪怪的個資法-ox-20130225
2014 03-14 PunApp-InstAll15-山寨的界限
2014 03-14 PunApp-InstAll15-山寨的界限
Video Face Recognition , Pattern Recognition Final Report
Video Face Recognition , Pattern Recognition Final Report
大型 Web Application 轉移到微服務的經驗分享
大型 Web Application 轉移到微服務的經驗分享
接案公司的日子
接案公司的日子
Semelhante a 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議
MySQL5.6新功能
MySQL5.6新功能
郁萍 王
Apache Kylin Data Summit 2019: Kyligence Presentation
Apache Kylin Data Summit 2019: Kyligence Presentation
Tyler Wishnoff
quick_orm 简介
quick_orm 简介
tyler4long
Truck js 高性能移动web开发解决方案
Truck js 高性能移动web开发解决方案
美团技术团队
Dreaming Infrastructure
Dreaming Infrastructure
kyhpudding
MariaDB: 新兴的开源大数据引擎
MariaDB: 新兴的开源大数据引擎
Colin Charles
Using google appengine_1027
Using google appengine_1027
Wei Sun
改善Programmer生活的sql技能
改善Programmer生活的sql技能
Rack Lin
如何設計電腦 -- 還有讓電腦變快的那些方法
如何設計電腦 -- 還有讓電腦變快的那些方法
鍾誠 陳鍾誠
My sql 5.6新特性深入剖析——innodb引擎
My sql 5.6新特性深入剖析——innodb引擎
frogd
Using google appengine (2)
Using google appengine (2)
Wei Sun
百度前端技术交流会--搜搜前端架构演变与优化
百度前端技术交流会--搜搜前端架构演变与优化
tiantianli
[Baidu web frontend_conference_2010]_[soso_frontend_architecture]
[Baidu web frontend_conference_2010]_[soso_frontend_architecture]
思念 青青
Hacking Nginx at Taobao
Hacking Nginx at Taobao
Joshua Zhu
4.陈群-唯品会大规模Redis集群存储架构演进.pdf
4.陈群-唯品会大规模Redis集群存储架构演进.pdf
StevenShing
张勇 搜搜前端架构
张勇 搜搜前端架构
isnull
瀏覽器開發與開源經驗 COSCUP 2018
瀏覽器開發與開源經驗 COSCUP 2018
安齊 劉
Itpub电子杂志第七期
Itpub电子杂志第七期
yiditushe
淺談物聯網巨量資料挑戰 - Jazz 王耀聰 (2016/3/17 於鴻海內湖) 免費講座
淺談物聯網巨量資料挑戰 - Jazz 王耀聰 (2016/3/17 於鴻海內湖) 免費講座
NTC.im(Notch Training Center)
淘宝搜索前端优化
淘宝搜索前端优化
Frank Xu
Semelhante a 談 Uber 從 PostgreSQL 轉用 MySQL 的技術爭議
(20)
MySQL5.6新功能
MySQL5.6新功能
Apache Kylin Data Summit 2019: Kyligence Presentation
Apache Kylin Data Summit 2019: Kyligence Presentation
quick_orm 简介
quick_orm 简介
Truck js 高性能移动web开发解决方案
Truck js 高性能移动web开发解决方案
Dreaming Infrastructure
Dreaming Infrastructure
MariaDB: 新兴的开源大数据引擎
MariaDB: 新兴的开源大数据引擎
Using google appengine_1027
Using google appengine_1027
改善Programmer生活的sql技能
改善Programmer生活的sql技能
如何設計電腦 -- 還有讓電腦變快的那些方法
如何設計電腦 -- 還有讓電腦變快的那些方法
My sql 5.6新特性深入剖析——innodb引擎
My sql 5.6新特性深入剖析——innodb引擎
Using google appengine (2)
Using google appengine (2)
百度前端技术交流会--搜搜前端架构演变与优化
百度前端技术交流会--搜搜前端架构演变与优化
[Baidu web frontend_conference_2010]_[soso_frontend_architecture]
[Baidu web frontend_conference_2010]_[soso_frontend_architecture]
Hacking Nginx at Taobao
Hacking Nginx at Taobao
4.陈群-唯品会大规模Redis集群存储架构演进.pdf
4.陈群-唯品会大规模Redis集群存储架构演进.pdf
张勇 搜搜前端架构
张勇 搜搜前端架构
瀏覽器開發與開源經驗 COSCUP 2018
瀏覽器開發與開源經驗 COSCUP 2018
Itpub电子杂志第七期
Itpub电子杂志第七期
淺談物聯網巨量資料挑戰 - Jazz 王耀聰 (2016/3/17 於鴻海內湖) 免費講座
淺談物聯網巨量資料挑戰 - Jazz 王耀聰 (2016/3/17 於鴻海內湖) 免費講座
淘宝搜索前端优化
淘宝搜索前端优化
Mais de Yi-Feng Tzeng
重新想像:如何做技術選型決策 / Rethinking : Technical Decision
重新想像:如何做技術選型決策 / Rethinking : Technical Decision
Yi-Feng Tzeng
擁抱開源:企業應如何善用開源技術,才能得其利而防其弊-加強版
擁抱開源:企業應如何善用開源技術,才能得其利而防其弊-加強版
Yi-Feng Tzeng
Testing in Production, Deploy on Fridays
Testing in Production, Deploy on Fridays
Yi-Feng Tzeng
COSCUP 2020 Day 2 - Opening Keynote
COSCUP 2020 Day 2 - Opening Keynote
Yi-Feng Tzeng
COSCUP 2020 Day 1 - Opening Keynote
COSCUP 2020 Day 1 - Opening Keynote
Yi-Feng Tzeng
Severless PHP Case : Agile Dashboard via GitLab Board API
Severless PHP Case : Agile Dashboard via GitLab Board API
Yi-Feng Tzeng
給資安工程師開源授權觀念
給資安工程師開源授權觀念
Yi-Feng Tzeng
Progressive Deployment & NoDeploy
Progressive Deployment & NoDeploy
Yi-Feng Tzeng
Dev(Sec)Ops - Architecture for Security and Compliance
Dev(Sec)Ops - Architecture for Security and Compliance
Yi-Feng Tzeng
擁抱開源:企業應如何善用開源技術,才能得其利而防其弊
擁抱開源:企業應如何善用開源技術,才能得其利而防其弊
Yi-Feng Tzeng
淺談量子機器學習 - 當機器學習遇見量子計算
淺談量子機器學習 - 當機器學習遇見量子計算
Yi-Feng Tzeng
A Modern Web Architecture for (GDPR) Compliance
A Modern Web Architecture for (GDPR) Compliance
Yi-Feng Tzeng
量子技術 (2018 03-31)
量子技術 (2018 03-31)
Yi-Feng Tzeng
Swoole Love PHP
Swoole Love PHP
Yi-Feng Tzeng
邏輯優化的灰色面:針對網頁應用的時序攻擊 (2018臺灣資安大會: 軟體安全論壇)
邏輯優化的灰色面:針對網頁應用的時序攻擊 (2018臺灣資安大會: 軟體安全論壇)
Yi-Feng Tzeng
Modern Web Architecture Design Journey
Modern Web Architecture Design Journey
Yi-Feng Tzeng
Mais de Yi-Feng Tzeng
(16)
重新想像:如何做技術選型決策 / Rethinking : Technical Decision
重新想像:如何做技術選型決策 / Rethinking : Technical Decision
擁抱開源:企業應如何善用開源技術,才能得其利而防其弊-加強版
擁抱開源:企業應如何善用開源技術,才能得其利而防其弊-加強版
Testing in Production, Deploy on Fridays
Testing in Production, Deploy on Fridays
COSCUP 2020 Day 2 - Opening Keynote
COSCUP 2020 Day 2 - Opening Keynote
COSCUP 2020 Day 1 - Opening Keynote
COSCUP 2020 Day 1 - Opening Keynote
Severless PHP Case : Agile Dashboard via GitLab Board API
Severless PHP Case : Agile Dashboard via GitLab Board API
給資安工程師開源授權觀念
給資安工程師開源授權觀念
Progressive Deployment & NoDeploy
Progressive Deployment & NoDeploy
Dev(Sec)Ops - Architecture for Security and Compliance
Dev(Sec)Ops - Architecture for Security and Compliance
擁抱開源:企業應如何善用開源技術,才能得其利而防其弊
擁抱開源:企業應如何善用開源技術,才能得其利而防其弊
淺談量子機器學習 - 當機器學習遇見量子計算
淺談量子機器學習 - 當機器學習遇見量子計算
A Modern Web Architecture for (GDPR) Compliance
A Modern Web Architecture for (GDPR) Compliance
量子技術 (2018 03-31)
量子技術 (2018 03-31)
Swoole Love PHP
Swoole Love PHP
邏輯優化的灰色面:針對網頁應用的時序攻擊 (2018臺灣資安大會: 軟體安全論壇)
邏輯優化的灰色面:針對網頁應用的時序攻擊 (2018臺灣資安大會: 軟體安全論壇)
Modern Web Architecture Design Journey
Modern Web Architecture Design Journey
談 Uber 從 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
Baixar agora