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

Slide 1

Slide 1 text

善用 MySQL 及 PostgreSQL RDBMS 的逆襲 part1 Ant yftzeng@gmail.com 2017-03-24

Slide 2

Slide 2 text

2/52 程式開發 X 資訊安全 X 智慧財產權 X 創業 Profile

Slide 3

Slide 3 text

3/52 Premature optimization is the root of all evil 過早最佳化是萬惡的根源 - Donald Knuth -

Slide 4

Slide 4 text

4/52 Optimise for data first, then code 優先最佳化數據，然後程式 - Tony Albrecht -

Slide 5

Slide 5 text

5/52 GB TB PB MB

Slide 6

Slide 6 text

6/52 大數據 BigData

Slide 7

Slide 7 text

7/52 Ref: https://www.talend.com/blog/2015/07/15/hadoop-summit-2015-takeaway-the-lambda-architecture

Slide 8

Slide 8 text

8/52 Ref: http://www.slideshare.net/akirillov/data-processing-platforms-architectures-with-spark-mesos-akka-cassandra-and-kafka#p4

Slide 9

Slide 9 text

9/52 Ref: https://medium.baqend.com/nosql-databases-a-survey-and-decision-guidance-ea7823a822d

Slide 10

Slide 10 text

10/52 2015 我們很少在大數據架構中見到 RDBMS 的蹤影但 Google/Facebook/Twitter/Uber/Alibaba .. .

Slide 11

Slide 11 text

11/52 大數據 BigData 微服務 Micro-services X

Slide 12

Slide 12 text

12/52 大數據 BigData ▐ 未捨棄既有累積的知識 (RDBMS) ▐ 降低開發與維運人員的焦慮感 ( 專注，技術深化 ) ▐ 系統異質性低 ( 出錯少，除錯易 ) ▐ 依然相容現行大數據架構 ▐ 支持容器化、混合雲、私有雲 ( 顧問性質 ) ▐ 大數據核心與對外服務層權責分離 ( 兼具安全性 ) ▐ 其實大多時候我們不需要大數據解決方案資料多≠需要大數據解決方案，或許只是垃圾數據多微服務 Micro- services 處理慢≠需要大數據解決方案，大多都是程式差，架構弱

Slide 13

Slide 13 text

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 ...

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

15/52 OLTP (On-Line Transaction Processing) ➊ 應用 : Customer-oriented ➋ 回應時間 (response time) 要求較高。 ➌ 併發 (concurrency) 要求較多。 ➍ 資料處理量 (volume) 少。 ➎ 交易 (transaction) 完整性高。 ➏ 安全性 (security) 要求較高。 Workload Processing

Slide 16

Slide 16 text

16/52 Workload OLAP (On-Line Analytical Processing) ➊ 應用 : Market-oriented ➋ 回應時間 (response time) 要求較低。 ➌ 併發 (concurrency) 要求較少。 ➍ 資料處理量 (volume) 多。 ➎ 交易 (transaction) 完整性低。 ➏ 安全性 (security) 要求較低。 Processing

Slide 17

Slide 17 text

17/52 Workload Data warehouse ➊ 應用 : Subject-oriented ➋ 熱資料 (Hot) 本地、快取、粒度、一致性。 ➌ 暖資料 (Warm) 分布、快取、複製。 ➍ 冷資料 (Cold) 索引、壓縮、合併、備份。 Processing

Slide 18

Slide 18 text

18/52 2015 High throughput Low latency

Slide 19

Slide 19 text

19/52 2015 千萬人同時在線電子商務、線上媒體低延遲回應廣告平台 (30ms) 、高頻交易 (0.5~3ms) 、醫療等關鍵設備

Slide 20

Slide 20 text

20/52 Workload Capacity

Slide 21

Slide 21 text

21/52 Workload Capacity Optimal capacity

Slide 22

Slide 22 text

22/52 Workload Capacity Optimal capacity

Slide 23

Slide 23 text

23/52 Workload Capacity Language / Framework / Algorithm / Hardware 300 Server → Performance +10x → 30 Server (Price cost reduction) (Maintenance cost reduction)

Slide 24

Slide 24 text

24/52 NewSQL / HTAP RDBMS → NoSQL → NewSQL NewSQL = RDBMS + NoSQL 為什麼 RDBMS 及 NoSQL 非要二擇一？

Slide 25

Slide 25 text

25/52 NewSQL / HTAP HTAP (Hybrid Transactional/Analytical Processing) OLTP vs. OLAP ？ HTAP = OLTP + OLAP 為什麼 OLTP 及 OLAP 非要二擇一？

Slide 26

Slide 26 text

26/52 NewSQL / HTAP 演進方向 1. RDBMS → NewSQL 2. NoSQL → NewSQL 3. NewSQL

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

28/52 NewSQL / HTAP 2. NoSQL → NewSQL HBase 實現強一致性 Cassandra 趨向強一致性 LWT (Lightweight transactions) 計畫採用 RAMP Transactions 和 Egalitarian Paxos (EPaxos)

Slide 29

Slide 29 text

29/52 NewSQL / HTAP 3. NewSQL CockroachDB FoundationDB (Apple) RethinkDB (Linux Foundation) VoltDB

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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 同時處理連線數下降問題。

Slide 32

Slide 32 text

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)

Slide 33

Slide 33 text

33/52 Scale-up Hardware Memory ➊ 原則上愈多愈好 ➋ 確保能把所需資料表全儲存在記憶體中。 Ref: MySQL 5.7 Performance Scalability & Benchmarks (2015-09-23).pdf

Slide 34

Slide 34 text

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/

Slide 35

Slide 35 text

35/52 Scale-up Hardware Storage ➊ 原則上， PCIe NVMe SSD > SSD > HDD 。 ➋ 區塊大小 (Block size) 對 SSD 很重要。

Slide 36

Slide 36 text

36/52 Ref: http://www.thessdreview.com/our-reviews/intel-ssd-dc-p3608-review-1-6tb-over-5gbs-and-850k-iops/2/

Slide 37

Slide 37 text

37/52 Ref: http://jdevelopment.nl/2009/02/ Bandwidth IOPS

Slide 38

Slide 38 text

38/52 Ref: http://jdevelopment.nl/2009/02/ Bandwidth IOPS Throughput Latency

Slide 39

Slide 39 text

39/52 Scale-up Hardware Storage ➊ 原則上， PCIe NVMe SSD > SSD > HDD 。 ➋ 區塊大小 (Block size) 對 SSD 很重要。 ➌ 循序寫 +RAID 的 HDD 不比 SSD 差。

Slide 40

Slide 40 text

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 都是順序寫。

Slide 41

Slide 41 text

41/52 Scale-up Connection Connection pool (Client/Application) ➊ 不是所有應用程式都支援。 ➋ 無法得知伺服器的狀態及承載。 ➌ 遭遇錯誤時，必須執行完整的資源清理。 ➍ 會保持連線，佔用伺服器連線數及線程快取。

Slide 42

Slide 42 text

42/52 Scale-up Connection Database Application 架構問題最大連線數 100 最大連線數 200

Slide 43

Slide 43 text

43/52 Scale-up Connection Database Application 架構問題最大連線數 200 { 剩餘連線數 100} 最大連線數 100 keep

Slide 44

Slide 44 text

44/52 Scale-up Connection Database Application 架構問題最大連線數 100 Application 最大連線數 100 keep keep 最大連線數 200 { 剩餘連線數 0}

Slide 45

Slide 45 text

45/52 Scale-up Connection Database Application 架構問題最大連線數 100 Application 最大連線數 100 Application 最大連線數 100 keep keep 最大連線數 200 { 剩餘連線數 0}

Slide 46

Slide 46 text

46/52 Scale-up Connection 架構問題 MySQL ➊ 線程模式。 ➋ 不需 Connection pool 就可以支持高併發。 ➌ 支持短連接使用資料庫。 ➍ 新版 5.7 建立連線的開銷更少。 5.6 版的 62.5% ； 5.5 版的 40% 。

Slide 47

Slide 47 text

47/52 Scale-up Application 效能通常有 99% 的問題在於 Application ➊ N+1 queries / ORM ➋ Bad SQL ➌ Bad Schema Design ➍ Big SQL ➎ Big Transaction ➏ Big Batch

Slide 48

Slide 48 text

48/52 Scale-up Application 效能通常有 99% 的問題在於 Application ➊ N+1 queries / ORM ➋ Bad SQL ➌ Bad Schema Design ➍ Big SQL ➎ Big Transaction ➏ Big Batch

Slide 49

Slide 49 text

49/52 Scale-up Application (MySQL) CHAR vs. VARCHAR ➀ 如果更新頻繁且長度不一， CHAR 通常比較快。 ➁ 在 MySQL 5.7.7 之後， CHAR 通常比 VARCHAR 快。

Slide 50

Slide 50 text

50/52 Scale-up Application (MySQL) VARCHAR vs. VARCHAR ➀ 某些編碼下， VARCHAR(760) 與 VARCHAR(770) 快得多。 ➁ 某些編碼下， VARCHAR(190) 比 VARCHAR(200) 快得多。 ➂ 不過在 MySQL 5.7.7 之後，前兩者幾乎沒什麼差別。雖然只差 10 ，但效能在這長度間有個跳躍雖然只差 10 ，但效能在這長度間有個跳躍

Slide 51

Slide 51 text

51/52 Scale-up Application INDEX ➀ Primary Index 對 MySQL 很重要，循序式比亂序式快。 ➁ Index 愈多不一定愈好。 ➂ Composite Index 需善用。

Slide 52

Slide 52 text

52/52 yftzeng@gmail.com https://www.facebook.com/yftzeng.tw Contact