Tweet
Tweet

Slide 1

Slide 1 text

Modern Web 2016 恰如其分的 MySQL 設計技巧 Ant [email protected] 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 [email protected] https://www.facebook.com/yftzeng.tw Contact