善用 MySQL 及 PostgreSQL - RDBMS 的逆襲 - part1

NewSQL = RDBMS + NoSQL
HTAP = OLTP + OLAP

Transcript

1. 善用 MySQL 及 PostgreSQL RDBMS 的逆襲 part1 Ant yftzeng@gmail.com 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 -
5. 5/52 GB TB PB MB
6. 6/52 大數據 BigData
7. 7/52 Ref: https://www.talend.com/blog/2015/07/15/hadoop-summit-2015-takeaway-the-lambda-architecture
8. 8/52 Ref: http://www.slideshare.net/akirillov/data-processing-platforms-architectures-with-spark-mesos-akka-cassandra-and-kafka#p4
9. 9/52 Ref: https://medium.baqend.com/nosql-databases-a-survey-and-decision-guidance-ea7823a822d
10. 10/52 2015 我們很少在大數據架構中 見到 RDBMS 的蹤影 但 Google/Facebook/Twitter/Uber/Alibaba .. .
11. 11/52 大數據 BigData 微服務 Micro-services X
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) 、醫療等關鍵設備
20. 20/52 Workload Capacity
21. 21/52 Workload Capacity Optimal capacity
22. 22/52 Workload Capacity Optimal capacity
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 很重要。
36. 36/52 Ref: http://www.thessdreview.com/our-reviews/intel-ssd-dc-p3608-review-1-6tb-over-5gbs-and-850k-iops/2/
37. 37/52 Ref: http://jdevelopment.nl/2009/02/ Bandwidth IOPS
38. 38/52 Ref: http://jdevelopment.nl/2009/02/ Bandwidth IOPS Throughput Latency
39. 39/52 Scale-up Hardware Storage ➊ 原則上， PCIe NVMe SSD > SSD > HDD 。 ➋ 區塊大小 (Block size) 對 SSD 很重要。 ➌ 循序寫 +RAID 的 HDD 不比 SSD 差。
40. 40/52 Ref: 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) ➊ 不是所有應用程式都支援。 ➋ 無法得知伺服器的狀態及承載。 ➌ 遭遇錯誤時，必須執行完整的資源清理。 ➍ 會保持連線，佔用伺服器連線數及線程快取。
42. 42/52 Scale-up Connection Database Application 架構問題 最大連線數 100 最大連線數 200
43. 43/52 Scale-up Connection Database Application 架構問題 最大連線數 200 { 剩餘連線數 100} 最大連線數 100 keep
44. 44/52 Scale-up Connection Database Application 架構問題 最大連線數 100 Application 最大連線數 100 keep keep 最大連線數 200 { 剩餘連線數 0}
45. 45/52 Scale-up Connection Database Application 架構問題 最大連線數 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 需善用。
52. 52/52 yftzeng@gmail.com https://www.facebook.com/yftzeng.tw Contact