NewSQL = RDBMS + NoSQL HTAP = OLTP + OLAP

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
ThroughputLatency

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)
➊ 不是所有應用程式都支援。
➋ 無法得知伺服器的狀態及承載。
➌ 遭遇錯誤時，必須執行完整的資源清理。
➍ 會保持連線，佔用伺服器連線數及線程快取。

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

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 需善用。

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