恰如其分的 MySQL 設計技巧 [Modern Web 2016]

Slide 1

Slide 1 text

Modern Web 2016 恰如其分的 MySQL 設計技巧 Ant yftzeng@gmail.com 2016-08-24

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

3/117 剛好符合分寸。形容做事、說話十分恰當。

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

5/117 架構是演進的，預想有益身心健康預先策想

Slide 6

Slide 6 text

6/117 GB TB PB MB

Slide 7

Slide 7 text

7/117 新平台預計下一季上線。營運預計導入多少流量？我可以先行準備。有流量再說，快就好。那我之後 ( 有空 ) 再做。新平台上線

Slide 8

Slide 8 text

8/117 為什麼網站很慢又常當機？調整架構需要一週。這麼久？不能快點嗎？沒有辦法 ... 上線一週後

Slide 9

Slide 9 text

9/117 MVP 若沒有控制好，技術債將迅速增長 Minimum Viable Product 先前程式常不能用遺舊程式不忍棄之結構變動反覆無常

Slide 10

Slide 10 text

10/117 只做最低限度產品 (MVP) 最終得到的可能是壞產品

Slide 11

Slide 11 text

11/117 Pivot Object Go ✖ ✖ ✖ ✖ ✖ Research Development

Slide 12

Slide 12 text

12/117 2015 ➊ 架構先決無視人員、流程只講技術，是耍白痴架構會影響公司文化、商業擴展；思維更要超越程式碼層次

Slide 13

Slide 13 text

13/117 2015 ➋ 沒有完美的架構，只有最適的架構無視場景只講架構，是耍流氓若無法舉出架構的缺陷，代表你還無法掌握盲目套用別人的架構，並不會讓你變得跟他一樣好

Slide 14

Slide 14 text

14/117 2015 ➌ 架構是演進的，預想但不過早調優無視未來只求現有，是耍自閉兵馬未動，糧草先行，預想下一步，下下一步，甚至下下下一步 ...

Slide 15

Slide 15 text

15/117 Monolith Microservices SOA Nanoservices Picoservices ？

Slide 16

Slide 16 text

16/117 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 17

Slide 17 text

17/117 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 18

Slide 18 text

18/117 License

Slide 19

Slide 19 text

19/117 License 程式原始碼是否在意授權對方修改、散布？ GNU GPL 的互惠性 / 感染性散布于對方時，強制啟動授權 ( 接案 ) 軟體交付時嵌入式設備自己的程式 GPL 程式 GPL 程式

Slide 20

Slide 20 text

20/117 License C/Java + MySQL/Percona → PHP/PDO + MySQL/Percona → C/Java/PHP + MariaDB → 自己的程式 Database GPL 程式

Slide 21

Slide 21 text

21/117 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 22

Slide 22 text

22/117 當業務需求變更程式設計時預想但不過早調優總工程師不該把每次新需求都認為獨立需求 ( 多想二分鐘，團隊可以不必自虐 ) Elastic business

Slide 23

Slide 23 text

23/117 狀態原表格設計 Elastic business id name ... is_deleted 1 Apple ... 0 2 Banana ... 1

Slide 24

Slide 24 text

24/117 狀態新業務需要儲存「鎖定」狀態 Elastic business id name ... is_deleted 1 Apple ... 0 2 Banana ... 1 id name ... is_deleted is_locked 1 Apple ... 0 1 2 Banana ... 1 0

Slide 25

Slide 25 text

25/117 狀態其實若狀態是互斥的，則可以合併 Elastic business id name ... status 1 Apple ... 0 2 Banana ... 1 id name ... is_deleted is_locked 1 Apple ... 0 1 2 Banana ... 1 0 { 0: deleted, 1: enabled, 2: locked }

Slide 26

Slide 26 text

26/117 標籤雲原表格設計 Elastic business id name tag1 1 Apple admin 2 Banana reporter 3 Cherry reporter SELECT * FROM {Table} WHERE tag1 = ‘admin’

Slide 27

Slide 27 text

27/117 標籤雲新增標籤 Elastic business id name tag1 tag2 tag3 1 Apple admin reporter programmer 2 Banana reporter programmer NULL 3 Cherry reporter admin NULL SELECT * FROM {Table} WHERE (tag1 = ‘admin’ OR tag2 = ‘admin’ OR tag3 = ‘admin’) AND (tag1 = ‘reporter’ OR tag2 = ‘reporter’ OR tag3 = ‘reporter’) SELECT * FROM {Table} WHERE ‘admin’ IN (tag1, tag2, tag3) AND ‘reporter’ IN (tag1, tag2, tag3) ALTER TABLE !!

Slide 28

Slide 28 text

28/117 Tag Elastic business id tag 1 admin 1 reporter 1 programmer 2 reporter ... ... 新方法標籤雲 id name X X X 1 Apple X X X 2 Banana X X X SELECT * FROM {Table} INNER JOIN ‘Tag’ AS t1 USING (id) INNER JOIN ‘Tag’ AS t2 USING (id) WHERE t1.tag = ‘admin’ AND t2.tag = ‘reporter’

Slide 29

Slide 29 text

29/117 Elastic business 或是 M:N 標籤雲 id name 1 Apple 2 Banana id tag_id 1 1 1 2 1 3 2 2 2 3 tag_id name 1 admin 2 reporter 3 programmer

Slide 30

Slide 30 text

30/117 Elastic business 廣告需求營運有新的需求，受眾在一天內不要看到相同廣告。瞭解，預計一個工作天。第一天

Slide 31

Slide 31 text

31/117 Elastic business 廣告需求營運有新的需求，受眾在小時內不要看到相同廣告。瞭解，預計二個工作天。第二天時間粒度不同

Slide 32

Slide 32 text

32/117 Elastic business 廣告需求營運有新的需求，受眾在一天內不要看到同類廣告。瞭解，預計八個工作天。第三天目標粒度不同不能一次講清楚嗎？

Slide 33

Slide 33 text

33/117 Elastic business 廣告需求受眾在 M 時間內不要看到 N 廣告預想該需求的延伸會是什麼？ M → 年 / 季 / 月 / 週 / 時 / 分 / 秒 N → 相同 / 同類看到的次數？ 1/2/3... 裝置有別？區域？廣告主屬性？

Slide 34

Slide 34 text

34/117 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 35

Slide 35 text

35/117 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 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

39/117 Workload Intensive Bandwidth CPU Memory Storage/IO

Slide 40

Slide 40 text

40/117 Workload Capacity Latency Memory footprint Trade-off Throughput

Slide 41

Slide 41 text

41/117 2015 High throughput Low latency

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

43/117 機房只能給你 4U 共 2 台機器，請您務必提供每秒 1 萬次的處理效能。每次請求包括產生 46 張圖片及 46 次加密演算法 Workload Capacity

Slide 44

Slide 44 text

44/117 Workload Capacity

Slide 45

Slide 45 text

45/117 Workload Capacity Optimal capacity

Slide 46

Slide 46 text

46/117 Workload Capacity Optimal capacity

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

48/117 Workload Bond Security Cost Restriction Trade-off Performance

Slide 49

Slide 49 text

49/117 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 50

Slide 50 text

50/117 Scale-up Hardware CPU ➊ 快取對 InnoDB 影響很大 (CPU Cache) 。 ➋ 超執行緒 (Hyper threading) 有助益。 ➌ 通常啟用 Node Interleaving ，可避免 NUMA 問題。 ➍ 多核心處理 MySQL 5.5 最佳表現為 16 核心，同時連線數 128 。 MySQL 5.6 支援至少 64 核心，同時連線數處理不受影響；但 RW 在同時處理 128 連線數後顯著下降。 MySQL 5.7 支援至少 64 核心，同時連線數處理不受影響；解決 RW 同時處理連線數下降問題。

Slide 51

Slide 51 text

51/117 Scale-up Hardware 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 52

Slide 52 text

52/117 Scale-up Hardware Memory ➊ 原則上愈多愈好 ➋ 確保能把所需資料表全儲存在記憶體中。

Slide 53

Slide 53 text

53/117 Scale-up Hardware Storage ➊ 原則上， PCIe NVMe SSD > SSD > HDD 。 Ref: http://agigatech.com/blog/ssds-some-cold-hard-numbers-to-flavor-your-opinions/

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

56/117 Ref: http://jdevelopment.nl/2009/02/ Bandwidth IOPS

Slide 57

Slide 57 text

57/117 Ref: http://jdevelopment.nl/2009/02/ Bandwidth IOPS Throughput Latency

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

59/117 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)

Slide 60

Slide 60 text

60/117 Scale-up OS Kernel ➊ vm.swappiness = 1

Slide 61

Slide 61 text

61/117 Scale-up OS Kernel ➊ vm.swappiness = 1 ➋ vm.dirty_background_ratio / vm.dirty_ratio

Slide 62

Slide 62 text

62/117 Scale-up OS Kernel ➊ vm.swappiness = 1 ➋ vm.dirty_background_ratio / vm.dirty_ratio ➌ IO scheduler (DEADLINE or NOOP)

Slide 63

Slide 63 text

63/117 Scale-up File system OLTP Ext4 / XFS Journal / O_DIRECT COMPRESSION ...

Slide 64

Slide 64 text

64/117 Scale-up Database Design Configuration MT-malloc: jemalloc / tcmalloc / etc. DB Engine: InnoDB / TokuDB / RocksDB Schema design / ID Index Partitions default_time_zone = ‘+00:00’ max_connections sort_buffer_size join_buffer_size read_buffer_size innodb_use_native_aio = 1 innodb_file_per_table = 1 innodb_buffer_pool_size = { 65~80% of Mem } innodb_thread_concurrency = { 2xCPUs } innodb_read_io_threads = { CPUs } innodb_write_io_threads = { CPUs }

Slide 65

Slide 65 text

65/117 Scale-up Database OLTP innodb_flush_method innodb_max_dirty_pages_pct innodb_page_size innodb_io_capacity innodb_flush_neighbors innodb_random_read_ahead innodb_read_ahead_threshold ...

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

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

Slide 77

Slide 77 text

77/117 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 78

Slide 78 text

78/117 Replication Scale-out Master Replica Replica Replica

Slide 79

Slide 79 text

79/117 Replication Scale-out Master Replica Replica Replica Applications write read

Slide 80

Slide 80 text

80/117 Clustering Scale-out

Slide 81

Slide 81 text

81/117 2015 Database #1 Database #2 Database #3 ... Applications RW RW RW RW Master-Master

Slide 82

Slide 82 text

82/117 2015 Database #1 Database #2 Database #3 ... Applications RW RW RW RW UPDATE t SET … WHERE id = 1 T1 Master-Master UPDATE t SET … WHERE id = 1 T2

Slide 83

Slide 83 text

83/117 2015 Database #1 Database #2 Database #3 ... Applications RW RW RW RW UPDATE t SET … WHERE id = 1 T1 Master-Master UPDATE t SET … WHERE id = 1 T2 100 → 200 100 → 200

Slide 84

Slide 84 text

84/117 2015 Database #1 Database #2 Database #3 ... Applications RW RW RW RW UPDATE t SET … WHERE id = 1 T1 Master-Master UPDATE t SET … WHERE id = 1 T2 100 → 200 100 → 200 Deadlock / Rollback

Slide 85

Slide 85 text

85/117 2015 Database #1 Database #2 Database #3 ... Applications Master-Master Load balancing W R R R

Slide 86

Slide 86 text

86/117 2015 Database #1 Database #2 Database #3 ... Applications UPDATE t SET … WHERE id = 1 T1 Master-Master SELECT ... T2 W R R R T3 SELECT ... T4 SELECT ... T5 Load balancing

Slide 87

Slide 87 text

87/117 2015 Database #1 Database #2 Database #3 ... Applications UPDATE t SET … WHERE id = 1 T1 Master-Master SELECT ... T2 W R R R T3 SELECT ... T4 SELECT ... T5 Load balancing Load balancing HA Monitor

Slide 88

Slide 88 text

88/117 2015 Percona XtraDB Cluster: Multi-node writing and Unexpected deadlocks 2012-08-17 https://www.percona.com/blog/2012/08/17/percona-xtradb-cluster-multi-node-writing-and-unexpected-deadlocks/ Avoiding Deadlocks in Galera - Set up HAProxy for single-node writes and multi-node reads 2013-09-17 http://www.severalnines.com/blog/avoiding-deadlocks-galera-set-haproxy-single-node-writes-and-multi-node-reads Optimizing Percona XtraDB Cluster for write hotspots 2015-06-03 https://www.percona.com/blog/2015/06/03/optimizing-percona-xtradb-cluster-write-hotspots/

Slide 89

Slide 89 text

89/117 2015 Database #1 Database #2 Database #3 ... Applications UPDATE t SET … WHERE id = 1 T1 Master-Master SELECT ... T2 W R R R T3 SELECT ... T4 SELECT ... T5 Load balancing Load balancing HA Monitor Hot-Spot 1 Complexity 2

Slide 90

Slide 90 text

90/117 2015 Database #1 Database #2 Database #3 ... Applications RW RW RW RW Master-Master Smart Client

Slide 91

Slide 91 text

91/117 Sharding Scale-out

Slide 92

Slide 92 text

92/117 Disaster Recovery Scale-out

Slide 93

Slide 93 text

93/117 Disaster Recovery Scale-out Latency ? Bandwidth ?

Slide 94

Slide 94 text

94/117 Multi Regional Resiliency Scale-out Ref: https://cloud.google.com/solutions/scalable-and-resilient-apps

Slide 95

Slide 95 text

95/117 Multi Regional Resiliency Scale-out Ref: https://securosis.com/blog/resilient-cloud-network-architectures-design-patterns

Slide 96

Slide 96 text

96/117 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 97

Slide 97 text

97/117 大數據 BigData

Slide 98

Slide 98 text

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

Slide 99

Slide 99 text

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

Slide 100

Slide 100 text

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

Slide 101

Slide 101 text

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

Slide 102

Slide 102 text

102/117 大數據 BigData 微服務 Micro-services X

Slide 103

Slide 103 text

103/117 大數據 BigData Hadoop (Java) Spark (Java/Scala) Cassandra (Java) Kafka (Java/Scala) Pig (Java) Hive (Java) HBase (Java) Flink (Java) ElasticSearch (Java) JVM 的天下

Slide 104

Slide 104 text

104/117 Ref: http://eugenedvorkin.com/seven-micro-services-architecture-advantages/

Slide 105

Slide 105 text

105/117 部署快 ( 起滅快 ) 效能高 ( 機數少 ) 開發速 ( 碼量少 ) 體積小編譯式 GC 編譯式 JIT 保護編程下限 (IDE/ 除錯 ) 保障破壞下限

Slide 106

Slide 106 text

106/117 部署快 ( 起滅快 ) 效能高 ( 機數少 ) 開發速 ( 碼量少 ) 體積小編譯式 GC 編譯式容器化 Java 混合雲 JIT 保護編程下限 (IDE/ 除錯 ) 保障破壞下限

Slide 107

Slide 107 text

107/117 Java Container Size Oracle JDK (~350 MB) Oracle JRE (~70 MB) Oracle Server JRE (~70 MB) Alpine Java Docker Container ? 只是 JRE 本身

Slide 108

Slide 108 text

108/117 Java Container Size docker-alpine-java curl -jksSLH "Cookie: oraclelicense=accept-securebackup-cookie" ... rm -rf /opt/jdk/*src.zip \ /opt/jdk/lib/missioncontrol \ /opt/jdk/lib/visualvm \ /opt/jdk/lib/*javafx* \ /opt/jdk/jre/plugin \ /opt/jdk/jre/bin/javaws \ ... Ref: https://github.com/anapsix/docker-alpine-java/blob/master/8/92b14/jdk/standard/Dockerfile

Slide 109

Slide 109 text

109/117 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 License CONSILIENCE and more ...

Slide 110

Slide 110 text

110/117 Java ▐ 問題一 : Oracle/Java 安裝前需人工同意 Oracle/Java 授權。 ▐ 問題二 Oracle/Java 為整體不可分割之授權。 (i) you distribute the Redistributables complete and unmodified, and only bundled as part of Programs, Ref: http://www.oracle.com/technetwork/java/javase/terms/license/index.html License Oracle Java 部署時，不得刪減任何程式及文件

Slide 111

Slide 111 text

111/117 Java ▐ 問題一 : Oracle/Java 安裝前需人工同意 Oracle/Java 授權。 ▐ 問題二 Oracle/Java 為整體不可分割之授權。 (i) you distribute the Redistributables complete and unmodified, and only bundled as part of Programs, Ref: http://www.oracle.com/technetwork/java/javase/terms/license/index.html License Oracle Java 部署時，不得刪減任何程式及文件 OpenJDK ( openjdk-7-jre-headless ) 有些人不敢用

Slide 112

Slide 112 text

112/117 部署快 ( 起滅快 ) 效能高 ( 機數少 ) 開發速 ( 碼量少 ) 體積小編譯式 GC 編譯式容器化 Java 混合雲 JIT 保護編程下限 (IDE/ 除錯 ) 保障破壞下限

Slide 113

Slide 113 text

113/117 部署快 ( 起滅快 ) 效能高 ( 機數少 ) 開發速 ( 碼量少 ) 體積小編譯式 GC 編譯式容器化 Java 混合雲 JIT 保護編程下限 (IDE/ 除錯 ) 保障破壞下限 Go

Slide 114

Slide 114 text

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

Slide 115

Slide 115 text

115/117 Go Go HDFS/RDBMS HDFS/RDBMS Go MySQL MySQL

Slide 116

Slide 116 text

116/117 2015 ➊ 架構先決 ➋ 沒有完美的架構，只有最適的架構 ➌ 架構是演進的，預想但不過早調優

Slide 117

Slide 117 text

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