善用 MySQL 及 PostgreSQL - RDBMS 的逆襲 - part1
17 likes3,609 views
NewSQL = RDBMS + NoSQL HTAP = OLTP + OLAP
![恰如其分的 MySQL 設計技巧 [Modern Web 2016]](https://cdn.slidesharecdn.com/ss_thumbnails/2016-08-24modernweb-mysql-161019062706-thumbnail.jpg?width=560&fit=bounds)
More Related Content
What's hot (20)
Viewers also liked (20)
![[BizLePro] 主題講座 #5：台灣C2C第三方支付服務之發展_20130513_gillight](https://cdn.slidesharecdn.com/ss_thumbnails/c2c-130515050736-phpapp02-thumbnail.jpg?width=560&fit=bounds)
![[BizLePro] 主題講座 #4：給資訊人的智財導論_20130429_richard](https://cdn.slidesharecdn.com/ss_thumbnails/bizlepro20130429richard-130430014156-phpapp02-thumbnail.jpg?width=560&fit=bounds)
![[BizLePro] 主題講座 #7：商業利用怎麼行？ - 從開源授權十個常見 FAQ 來了解](https://cdn.slidesharecdn.com/ss_thumbnails/20130610-130610200023-phpapp02-thumbnail.jpg?width=560&fit=bounds)
Similar to 善用 MySQL 及 PostgreSQL - RDBMS 的逆襲 - part1 (20)
More from Yi-Feng Tzeng (17)
善用 MySQL 及 PostgreSQL - RDBMS 的逆襲 - part1
- 1. 善用 MySQL 及 PostgreSQL RDBMS 的逆襲 part1 Ant [email protected] 2017-03-24
- 2. 2/52 程式開發 X 資訊安全 X 智慧財產權 X 創業 Profile
- 3. 3/52 Premature optimization is the root of all evil 過早最佳化是萬惡的根源 - Donald Knuth -
- 4. 4/52 Optimise for data first, then code 優先最佳化數據，然後程式 - Tony Albrecht -
- 12. 12/52 大數據 BigData ▐ 未捨棄既有累積的知識 (RDBMS) ▐ 降低開發與維運人員的焦慮感 ( 專注，技術深化 ) ▐ 系統異質性低 ( 出錯少，除錯易 ) ▐ 依然相容現行大數據架構 ▐ 支持容器化、混合雲、私有雲 ( 顧問性質 ) ▐ 大數據核心與對外服務層權責分離 ( 兼具安全性 ) ▐ 其實大多時候我們不需要大數據解決方案 資料多≠需要大數據解決方案，或許只是垃圾數據多 微服務 Micro- services 處理慢≠需要大數據解決方案，大多都是程式差，架構弱
- 13. 13/52 Business License Elastic business Workload Technology Scale-up Application Connection Database File system OS Kernel Hardware Scale-out Replication Clustering Sharding Disaster Recovery Multi Regional Resiliency CONSILIENCE Architecture and more ...
- 14. 14/52 Workload Processing Intensive Capacity CPU intensive Memory intensive Storage/IO intensive Bandwidth intensive OLTP OLAP Data warehouse Throughput Latency Memory footprint Service-level agreement Bond Performance Security Cost restriction
- 15. 15/52 OLTP (On-Line Transaction Processing) ➊ 應用 : Customer-oriented ➋ 回應時間 (response time) 要求較高。 ➌ 併發 (concurrency) 要求較多。 ➍ 資料處理量 (volume) 少。 ➎ 交易 (transaction) 完整性高。 ➏ 安全性 (security) 要求較高。 Workload Processing
- 16. 16/52 Workload OLAP (On-Line Analytical Processing) ➊ 應用 : Market-oriented ➋ 回應時間 (response time) 要求較低。 ➌ 併發 (concurrency) 要求較少。 ➍ 資料處理量 (volume) 多。 ➎ 交易 (transaction) 完整性低。 ➏ 安全性 (security) 要求較低。 Processing
- 17. 17/52 Workload Data warehouse ➊ 應用 : Subject-oriented ➋ 熱資料 (Hot) 本地、快取、粒度、一致性。 ➌ 暖資料 (Warm) 分布、快取、複製。 ➍ 冷資料 (Cold) 索引、壓縮、合併、備份。 Processing
- 18. 18/52 2015 High throughput Low latency
- 19. 19/52 2015 千萬人同時在線 電子商務、線上媒體 低延遲回應 廣告平台 (30ms) 、高頻交易 (0.5~3ms) 、醫療等關鍵設備
- 23. 23/52 Workload Capacity Language / Framework / Algorithm / Hardware 300 Server → Performance +10x → 30 Server (Price cost reduction) (Maintenance cost reduction)
- 24. 24/52 NewSQL / HTAP RDBMS → NoSQL → NewSQL NewSQL = RDBMS + NoSQL 為什麼 RDBMS 及 NoSQL 非要二擇一？
- 25. 25/52 NewSQL / HTAP HTAP (Hybrid Transactional/Analytical Processing) OLTP vs. OLAP ？ HTAP = OLTP + OLAP 為什麼 OLTP 及 OLAP 非要二擇一？
- 26. 26/52 NewSQL / HTAP 演進方向 1. RDBMS → NewSQL 2. NoSQL → NewSQL 3. NewSQL
- 27. 27/52 NewSQL / HTAP 1. RDBMS → NewSQL PostgreSQL 支援 HSTORE / JSON / JSONB MySQL 支援 JSON ( 對等於 PostgreSQL 的 JSON 還是 JSONB ?) MariaDB 支援 Cassandra 引擎 Facebook 在 MySQL 引入 RocksDB (MyRocks) MS SQL Server 2016 支援 JSON (JSONB ?) Oracle 12c 支援 JSON (JSONB ?) SQLite 支援 JSON (JSONB ?) TokuDB
- 28. 28/52 NewSQL / HTAP 2. NoSQL → NewSQL HBase 實現強一致性 Cassandra 趨向強一致性 LWT (Lightweight transactions) 計畫採用 RAMP Transactions 和 Egalitarian Paxos (EPaxos)
- 29. 29/52 NewSQL / HTAP 3. NewSQL CockroachDB FoundationDB (Apple) RethinkDB (Linux Foundation) VoltDB
- 30. 30/52 Business License Elastic business Workload Technology Scale-up Application Connection Database File system OS Kernel Hardware Scale-out Replication Clustering Sharding Disaster Recovery Multi Regional Resiliency Architecture and more ... CONSILIENCE
- 31. 31/52 Scale-up Hardware CPU ➊ 快取對 InnoDB 影響很大 (CPU Cache) 。 ➋ 超執行緒 (Hyper threading) 有助益。 ➌ 通常啟用 Node Interleaving ，可避免 NUMA 問題。 ➍ 多核心處理 Ref: MySQL 5.7 Performance Scalability & Benchmarks (2015-09-23).pdf MySQL 5.5 最佳表現為 16 核心，同時連線數 128 。 MySQL 5.6 支援至少 64 核心，同時連線數處理不受影響； 但 RW 在同時處理 128 連線數後顯著下降。 MySQL 5.7 支援至少 64 核心，同時連線數處理不受影響； 解決 RW 同時處理連線數下降問題。
- 32. 32/52 Scale-up Hardware Ref: SSD Deployment Strategies for MySQL (2010-04-15).pdf (p30) CPUs North Bridge (MCH) Memory PCIe FSB (10.6 GB/s) Intel Xeon (Older) CPUs North Bridge (IOH) Memory PCIe QBI (25.6 GB/s) Intel Xeon (Newer)
- 33. 33/52 Scale-up Hardware Memory ➊ 原則上愈多愈好 ➋ 確保能把所需資料表全儲存在記憶體中。 Ref: MySQL 5.7 Performance Scalability & Benchmarks (2015-09-23).pdf
- 34. 34/52 Scale-up Hardware Storage ➊ 原則上， PCIe NVMe SSD > SSD > HDD 。 Ref: http://agigatech.com/blog/ssds-some-cold-hard-numbers-to-flavor-your-opinions/
- 35. 35/52 Scale-up Hardware Storage ➊ 原則上， PCIe NVMe SSD > SSD > HDD 。 ➋ 區塊大小 (Block size) 對 SSD 很重要。
- 39. 39/52 Scale-up Hardware Storage ➊ 原則上， PCIe NVMe SSD > SSD > HDD 。 ➋ 區塊大小 (Block size) 對 SSD 很重要。 ➌ 循序寫 +RAID 的 HDD 不比 SSD 差。
- 40. 40/52Ref: SSD Deployment Strategies for MySQL (2010-04-15).pdf (p16) Ref: http://yoshinorimatsunobu.blogspot.tw/2009/05/tables-on-ssd-redobinlogsystem.html RAID-10 > RAID-5 (RAID 控制器很重要 ) battery backed up write cache (BBWC) MySQL 的 table 是 random-write ， 但 Redo Log / Binary Log / ibdata 都是順序寫。
- 41. 41/52 Scale-up Connection Connection pool (Client/Application) ➊ 不是所有應用程式都支援。 ➋ 無法得知伺服器的狀態及承載。 ➌ 遭遇錯誤時，必須執行完整的資源清理。 ➍ 會保持連線，佔用伺服器連線數及線程快取。
- 43. 43/52 Scale-up Connection DatabaseApplication 架構問題 最大連線數 200 { 剩餘連線數 100} 最大連線數 100 keep
- 44. 44/52 Scale-up Connection DatabaseApplication 架構問題 最大連線數 100 Application 最大連線數 100 keep keep 最大連線數 200 { 剩餘連線數 0}
- 45. 45/52 Scale-up Connection DatabaseApplication 架構問題 最大連線數 100 Application 最大連線數 100 Application 最大連線數 100 keep keep 最大連線數 200 { 剩餘連線數 0}
- 46. 46/52 Scale-up Connection 架構問題 MySQL ➊ 線程模式。 ➋ 不需 Connection pool 就可以支持高併發。 ➌ 支持短連接使用資料庫。 ➍ 新版 5.7 建立連線的開銷更少。 5.6 版的 62.5% ； 5.5 版的 40% 。
- 47. 47/52 Scale-up Application 效能通常有 99% 的問題在於 Application ➊ N+1 queries / ORM ➋ Bad SQL ➌ Bad Schema Design ➍ Big SQL ➎ Big Transaction ➏ Big Batch
- 48. 48/52 Scale-up Application 效能通常有 99% 的問題在於 Application ➊ N+1 queries / ORM ➋ Bad SQL ➌ Bad Schema Design ➍ Big SQL ➎ Big Transaction ➏ Big Batch
- 49. 49/52 Scale-up Application (MySQL) CHAR vs. VARCHAR ➀ 如果更新頻繁且長度不一， CHAR 通常比較快。 ➁ 在 MySQL 5.7.7 之後， CHAR 通常比 VARCHAR 快。
- 50. 50/52 Scale-up Application (MySQL) VARCHAR vs. VARCHAR ➀ 某些編碼下， VARCHAR(760) 與 VARCHAR(770) 快得多。 ➁ 某些編碼下， VARCHAR(190) 比 VARCHAR(200) 快得多。 ➂ 不過在 MySQL 5.7.7 之後，前兩者幾乎沒什麼差別。 雖然只差 10 ，但效能在這長度間有個跳躍 雖然只差 10 ，但效能在這長度間有個跳躍
- 51. 51/52 Scale-up Application INDEX ➀ Primary Index 對 MySQL 很重要，循序式比亂序式快。 ➁ Index 愈多不一定愈好。 ➂ Composite Index 需善用。