淺入淺出 mysql & postgresql

147
淺入淺出 MySQL & PostgreSQL 2015 Ant [email protected]

Upload: yi-feng-tzeng

Post on 15-Jul-2015

6.043 views

Category:

Software


4 download

TRANSCRIPT

Page 1: 淺入淺出 MySQL & PostgreSQL

淺入淺出MySQL & PostgreSQL

2015Ant

[email protected]

Page 2: 淺入淺出 MySQL & PostgreSQL

20152/147

請先閱讀 Triton Ho的教材

♪ Triton Ho(以下稱作者 )的教材。https://drive.google.com/file/d/0Bw4cH_iKZJzKOE5YRWtZS3lyTkk/viewhttps://drive.google.com/file/d/0Bw4cH_iKZJzKLXFIWVFfMk13Vm8/viewhttps://drive.google.com/file/d/0Bw4cH_iKZJzKd25qdV9HTEp4VVk/view

♪作者簡報中有值得參考的內容。♪目的不是為了批評,而是討論。♪本討論將探討其中幾個論點。

Page 3: 淺入淺出 MySQL & PostgreSQL

20153/147

小遊戲

網路上找了許多 MySQL & PostgreSQL的圖片,發現很多都是PostgreSQL社群對 MySQL社群的攻擊性圖片。

Page 4: 淺入淺出 MySQL & PostgreSQL

Ref: http://cloud-elements.com/wp-content/uploads/2014/07/mysql_vs_postgres.png

Page 5: 淺入淺出 MySQL & PostgreSQL

Ref: http://blog.jorgenio.com/wp-content/uploads/2012/08/postgres-vs-mysql.jpg

Page 6: 淺入淺出 MySQL & PostgreSQL

Ref: http://www.dasunhegoda.com/wp-content/uploads/2013/10/postgres3.png

Page 7: 淺入淺出 MySQL & PostgreSQL

Ref: http://people.freebsd.org/~seanc/img/mammoth_versus_dolphin_500.jpg

Page 8: 淺入淺出 MySQL & PostgreSQL

20158/147

前言

♪我不是MySQL / PostgreSQL推廣者,只看重誰能解決問題。♪非專業 DBA,只是個架構實習生。♪無漫罵,不認為MSSQL、MySQL或 PostgreSQL是垃圾。♪每個軟體都有優缺點,依實際場景選擇不同的需求。

Page 9: 淺入淺出 MySQL & PostgreSQL

20159/147

前言

♪作者簡報主在抨擊MySQL,也較少提 PostgreSQL缺點。♪為平衡報導,我著重該簡報的錯誤及 PostgreSQL缺點補充。

Page 10: 淺入淺出 MySQL & PostgreSQL

201510/147

淺談 SSD

Ref: https://www.facebook.com/groups/199493136812961/permalink/729886527106950/

Page 11: 淺入淺出 MySQL & PostgreSQL

11/1472015

淺談 SSD

《我的解釋》這點原則上是對的。但很多大企業早已開始嘗試使用 Hybrid方案 (HDD/SSD)。其一為成本因素,另一為硬體特性。

Page 12: 淺入淺出 MySQL & PostgreSQL

12/1472015

淺談 SSD

Random IO ? Sequential IO ?

但我想談的是背後更深的原因。

『為什麼MySQL及MSSQL盡力追求 Sequential IO?』

『 Sequential IO在 SSD的世界中真的無所謂?』

Page 13: 淺入淺出 MySQL & PostgreSQL

13/1472015

淺談 SSD

很多人都會說 SSD的 Sequential IO不重要,但真的不重要?

雖然MySQL相較 PostgreSQL實際只用到不算明顯的優勢。

本篇的內容側重在 Ordered INSERT生成的 Reorder及Merge,這是後續會提到的。

Page 14: 淺入淺出 MySQL & PostgreSQL

14/1472015

淺談 SSD

經工具實測與廠商 Spec,顯示 SSD Random IO的速度不如Sequential IO。

Ref: http://en.wikipedia.org/wiki/IOPS

Page 15: 淺入淺出 MySQL & PostgreSQL

15/1472015

淺談 SSD

Ref: https://www.facebook.com/note.php?note_id=350857798258600

Read(500.8-289.8)/500.8 = 42%非循序讀取耗損 42%速度

Write(371.3-282.4)/371.3 = 24%非循序寫入耗損 24%速度

Page 16: 淺入淺出 MySQL & PostgreSQL

16/1472015

淺談 SSD

Ref: http://www.techbang.com/posts/15862-intel-ssd-530-solid-state-drive-performance-measurement?page=2

Read(411.18-205.40)/411.18 = 50%非循序讀取耗損 59%速度

Write(237.88-222.34)/237.88 = 6.5%非循序寫入耗損 6.5%速度

Page 17: 淺入淺出 MySQL & PostgreSQL

17/1472015

淺談 SSD

Page 18: 淺入淺出 MySQL & PostgreSQL

18/1472015

淺談 SSD

Ref: https://www.facebook.com/groups/199493136812961/permalink/729886527106950/

Page 19: 淺入淺出 MySQL & PostgreSQL

19/1472015

淺談 SSD

Ref: http://www.fusionio.com/blog/storage-switzerland-recognizes-fusions-low-latency-over-alternative-ssd-solutions

Page 20: 淺入淺出 MySQL & PostgreSQL

20/1472015

淺談 SSD

Ref: http://www.fusionio.com/white-papers/perconalive-2013-tech-demo-latency

MySQL Low Latency and High Throughput with directFS and Atomic Writes

Page 21: 淺入淺出 MySQL & PostgreSQL

21/1472015

淺談 SSD

Ref: http://www.fusionio.com/solutions/mysql/

Fusion IO針對MySQL的最佳化。

Page 22: 淺入淺出 MySQL & PostgreSQL

22/1472015

淺談 SSD

Ref: http://www.fusionio.com/overviews/accelerate-mysql-with-fusions-atomic-writes-extension

Fusion IO針對MySQL的最佳化。

Page 23: 淺入淺出 MySQL & PostgreSQL

23/1472015

淺談 SSD

Ref: http://www.enterprisetech.com/2014/04/03/fusion-io-tweaks-flash-speed-mysql-databases/

Atomic Writes / NVM Compression在MySQL 5.7.4引入;這兩個特性也已在 Percona 5.6及MariaDB 10引入。

Page 24: 淺入淺出 MySQL & PostgreSQL

24/1472015

淺談 SSD

Ref: http://www.fusionio.com/solutions/

Fusion IO不知為何沒有針對 PostgreSQL的特性最佳化。1.單純沒做,還是;2. Flash controller的技術無法針對 PostgreSQL的行為調整,還是;3. PostgreSQL已經夠好不用最佳化?

Page 25: 淺入淺出 MySQL & PostgreSQL

25/1472015

淺談 SSD

《我的解釋》

重點是 Fusion IO很可能使得常見資料庫的瓶頸由 IO bound轉變為 CPU bound。

如果變成 CPU bound,後續談的 Hotspot的影響將有效降低。

Page 26: 淺入淺出 MySQL & PostgreSQL

201526/147

OLTP: Fragmentation

Ref: https://drive.google.com/file/d/0Bw4cH_iKZJzKLXFIWVFfMk13Vm8/view (p11)

Page 27: 淺入淺出 MySQL & PostgreSQL

27/1472015

OLTP: Fragmentation

Ref: https://www.facebook.com/groups/199493136812961/permalink/729886527106950/

Page 28: 淺入淺出 MySQL & PostgreSQL

28/1472015

OLTP: Fragmentation

《我的解釋》

因為 INSERT循序 (規律 ),所以 Hotspot會發生在 last node (頻繁地在 last node寫入 );但若不循序,則容易造成 Storage /Memory Fragmentation,也就是若資料增刪改是不循序的,則空間配置也會是不循序的。

Ref: https://www.facebook.com/yftzeng.tw/posts/10202227746654516

Page 29: 淺入淺出 MySQL & PostgreSQL

29/1472015

OLTP: Fragmentation

Ref: http://www.slideshare.net/mysqlops/innodb-internal-9032556 (p17)

Page 30: 淺入淺出 MySQL & PostgreSQL

30/1472015

OLTP: Fragmentation

Ref: http://www.xaprb.com/blog/2006/07/04/how-to-exploit-mysql-index-optimizations/

Page 31: 淺入淺出 MySQL & PostgreSQL

31/1472015

OLTP: Fragmentation

Ref: http://www.xaprb.com/blog/2006/07/04/how-to-exploit-mysql-index-optimizations/

Page 32: 淺入淺出 MySQL & PostgreSQL

32/1472015

OLTP: Fragmentation

Ref: http://etutorials.org/SQL/Postgresql/Part+I+General+PostgreSQL+Use/Chapter+4.+Performance/Gathering+Performance+Information/

Page 33: 淺入淺出 MySQL & PostgreSQL

33/1472015

OLTP: Fragmentation

《我的解釋》

MySQL InnoDB Index會保持 (邏輯 )循序 (Ordered)。

InnoDB Primary Key也包括一些 data,所以找到 Key也同時取得這些 data。

Page 34: 淺入淺出 MySQL & PostgreSQL

34/1472015

OLTP: Fragmentation

Ref: https://www.facebook.com/groups/199493136812961/permalink/729886527106950/

Page 35: 淺入淺出 MySQL & PostgreSQL

35/1472015

OLTP: Fragmentation

Ref: https://www.facebook.com/groups/199493136812961/permalink/729886527106950/

《我的解釋》

很多技術本來就有優點與缺點,在不同業務需求都有不同的適用情境,也就是說幾乎沒有什麼技術一體適用,而沒有缺點。這是我的觀點。

也理所當然地認為,請使用者依業務需求選擇自己適用的方法。我同時說出優缺點後,才讓使用者自行選擇。

Page 36: 淺入淺出 MySQL & PostgreSQL

36/1472015

OLTP: Fragmentation

Ref: https://www.facebook.com/groups/199493136812961/permalink/729886527106950/

這點我同意

Page 37: 淺入淺出 MySQL & PostgreSQL

37/1472015

OLTP: Fragmentation

《我的解釋》

INSERT循序時,會頻繁在同一 page操作 (維持 Sequential,但有 Hotspot問題 )。MySQL預設會延遲寫入 Storage,並將連續異動的 pages一次寫入,甚至將請求合併,從而有效降低Random write的次數以及合併部分 Random write變成Sequential write。

但若使用 Random UUID時,寫的不一定是同一 page,所以即使延遲寫入 Storage,也會產生很多次 Random write。

Ref: http://www.tocker.ca/2013/05/06/when-does-mysql-perform-io.html

Page 38: 淺入淺出 MySQL & PostgreSQL

38/1472015

OLTP: Fragmentation

Ref: http://www.slideshare.net/morgo/inno-db-presentation (p9)

Page 39: 淺入淺出 MySQL & PostgreSQL

39/1472015

OLTP: Fragmentation

Ref: http://www.percona.com/files/presentations/percona-live/london-2011/PLUK2011-linux-and-hw-optimizations-for-mysql.pdf (p17)

MySQL Insert Buffering:

1. Reducing the number of disk i/o operations by merging i/orequests to the same block.

2. Some random i/o operations can be sequential.

Page 40: 淺入淺出 MySQL & PostgreSQL

40/1472015

OLTP: Fragmentation

《我的解釋》

SELECT時,若在Memory中,MySQL會保持 (邏輯 )Ordered。但 PostgreSQL不是,而且再加上它的MVCC設計, UPDATE/DELETE遺留下的 dead rows會使得 Fragmentation更嚴重。

若 SELECT是從 Storage取出時,因MySQL連續異動的 pages一次寫入,甚至將請求合併,所以相近的資料放在同一 block的機率較高。且將 Storage讀出放入Memory時,MySQL仍會保持 (邏輯 )Ordered。

Page 41: 淺入淺出 MySQL & PostgreSQL

41/1472015

OLTP: Fragmentation

Ref: http://www.percona.com/blog/2014/12/19/store-uuid-optimized-way/

Page 42: 淺入淺出 MySQL & PostgreSQL

42/1472015

OLTP: Fragmentation

Ref: https://www.facebook.com/groups/199493136812961/permalink/729886527106950/

Page 43: 淺入淺出 MySQL & PostgreSQL

43/1472015

OLTP: Fragmentation

《我的解釋》

EXT4不用 defrag ,不代表它沒有 fragmentation。再者,EXT4上看到的 fragmentation,也不是 SSD上實際的fragmentation。

Ref: https://www.facebook.com/groups/199493136812961/permalink/729886527106950/

Page 44: 淺入淺出 MySQL & PostgreSQL

44/1472015

OLTP: Fragmentation

Ref: https://www.facebook.com/groups/199493136812961/permalink/729886527106950/

Page 45: 淺入淺出 MySQL & PostgreSQL

45/1472015

OLTP: Fragmentation

我同意「 OLTP在現實是中是自然存在的」,其實不管是 OLTP /OLAP都一樣。我從來沒有否定這點。

我指的也不是『難道 [email protected]登入系統了,然後便會是[email protected](p比 o後)會登入系統嗎?』

不過,即使真的 .ho登入後是 .hp登入也一定是 Random IO。因為這是兩個不同的 SELECT Query。同一個 Query下才有可能是 Sequential IO。

Sequential IO需例如一次寫入一批資料,而這些資料寫入的block是順序的。 Random IO則是分別寫入不同的 block。

Page 46: 淺入淺出 MySQL & PostgreSQL

46/1472015

OLTP: Fragmentation

Ref: https://www.facebook.com/groups/199493136812961/permalink/729886527106950/?comment_id=730137420415194

我講的是 OLAP,他講的是OLTP。所以在 OLAP應用上,我的論點沒錯;而在 OLTP的應用上,他的論點也沒錯。

可是我們還是要考量實際需求是什麼。他認為 OLTP在一般SELECT是很小量的 record,所以 fragmentation沒有影響。

注意他說的是『小量的 record 』,但舉個例子, 資料關聯 的數值統計是小量嗎?例如,用戶的朋友總數 / 用戶 LIKE

過的文章 /文章的留言回應數等,這些都是分散在大表不同的 record,會產生很多的 random I/O,這對 PostgreSQL影響比較大。這功能一般網站不常用?

其實光是 JOIN就可能產生一堆 random I/O 了。

Page 47: 淺入淺出 MySQL & PostgreSQL

47/1472015

OLTP: Fragmentation

Ref: https://www.facebook.com/groups/199493136812961/permalink/729886527106950/?comment_id=730137420415194

「對 PostgreSQL ≠ 影響比較大」 對MySQL沒有影響

Page 48: 淺入淺出 MySQL & PostgreSQL

48/1472015

OLTP: Fragmentation

Ref: https://www.facebook.com/groups/199493136812961/permalink/729886527106950/

Page 49: 淺入淺出 MySQL & PostgreSQL

49/1472015

OLTP: Fragmentation

《我的解釋》

如果 SSD的 Sequential IO真的不重要,為什麼有些新的引擎設計卻偏要追求 Sequential IO?

TokuDBRethinkDBCassandraAerospikeWiredTiger (MongoDB)

這點值得我們思考。

Page 50: 淺入淺出 MySQL & PostgreSQL

50/1472015

OLTP: Fragmentation

Page 51: 淺入淺出 MySQL & PostgreSQL

201551/147

Hotspot

Ref: https://drive.google.com/file/d/0Bw4cH_iKZJzKLXFIWVFfMk13Vm8/view (p7)

Page 52: 淺入淺出 MySQL & PostgreSQL

52/1472015

Hotspot

這部分我的結論是,反正 Disk IOPS 會愈來愈快 (作者也同意 ),Hotspot的影響程度也會愈來愈低。雖然 Fragmentation的問題也隨 IOPS增加而減輕,但是只要 SSD的「非循序讀寫」與「循序讀寫」差距仍然高達至少四分之一時,通常應該傾向選擇 Hotspot會比較好。 (因為我知道緩解甚至最終解方案 )

另外, Hotspot會造成 write效能降低,而 Fragmentation會降低read效能,但一般資料庫的操作通常是 read比 write次數高很多,所以選擇 Hotspot也 (可能 )是正確的。

最後, PostgreSQL天生無法避免 Fragmentation問題,而且修復Fragmentation的解決方法就是執行 VACUUM FULL (標準的VACUUM 沒用 ),可惜這會造成 table locked,更慘。

Ref: https://www.facebook.com/yftzeng.tw/posts/10202227746654516

Page 53: 淺入淺出 MySQL & PostgreSQL

53/1472015

Hotspot

Ref: https://www.facebook.com/groups/199493136812961/permalink/729886527106950/

Page 54: 淺入淺出 MySQL & PostgreSQL

54/1472015

Hotspot

《我的解釋》

很多技術本來就有優點與缺點,在不同業務需求都有不同的適用情境,也就是說幾乎沒有什麼技術一體適用,而沒有缺點。這是我的觀點。

也理所當然地認為,請使用者依業務需求選擇自己適用的方法。我同時說出優缺點後,才讓使用者自行選擇。

Ref: https://www.facebook.com/groups/199493136812961/permalink/729886527106950/

Page 55: 淺入淺出 MySQL & PostgreSQL

55/1472015

Hotspot

Ref: https://www.facebook.com/groups/199493136812961/permalink/729886527106950/

《我的解釋》

我從來沒有說MySQL可以撐住 Google / Facebook的量。聰明的讀者都看得出來。

「 OLTP看重WRITE而不看重 READ」,我同意也不同意。你這句我從來沒全面否認。我的結論是,看大家在架構面的未來進展,如果打算 RDBMS將來無痛移轉到 OLAP,則MySQL從前線退役時,我覺得剛好適合做 OLAP。你說的 PostgreSQL當OLAP有的特色當然好,只是我傾向用 Big data的技術解掉,畢竟這時候面對的都是「量」的問題,傳統的 SQL無法滿足我對 scalability的要求。若你不覺得也無妨,這點我留給讀者自行去判斷。

Page 56: 淺入淺出 MySQL & PostgreSQL

56/1472015

Hotspot

Ref: https://www.facebook.com/groups/199493136812961/permalink/729886527106950/

Page 57: 淺入淺出 MySQL & PostgreSQL

57/1472015

Hotspot

因為 PostgreSQL只是把問題延後處理,後續補充。

Page 58: 淺入淺出 MySQL & PostgreSQL

58/1472015

Hotspot

♪Database TuningTuning (Insert buffering, ...etc.)Partitions

♪Database DesignTokuDBNoSQLApproximately ordered / Completely random

♪HardwareRAID 0 / 5 / 10 / 50Fusion IO (From IO bound to CPU bound)

Page 59: 淺入淺出 MySQL & PostgreSQL

201559/147

Auto / Manual Clean Dead Node

Ref: https://drive.google.com/file/d/0Bw4cH_iKZJzKLXFIWVFfMk13Vm8/view (p20)

Page 60: 淺入淺出 MySQL & PostgreSQL

60/1472015

Auto / Manual Clean Dead Node

Ref: https://www.facebook.com/yftzeng.tw/posts/10202227746654516

《我的解釋》

MySQL會在有限時間與空間內保持數據循序性,並依 backgroundjob清理 dead tuples。這在簡報第 17頁有提及。雖然會影響concurrent write的效能,但卻保持 concurrent read的效率。

但 PostgreSQL使用不一樣的思路,它把清理 dead tuples的功能交由 VACUUM程序處理。不過自從 PostgreSQL 8.1版新增AUTOVACUUM功能後,也等同於開始允許程序自動清理舊數據而非單純只能人工; 9.0版更是預設啟動 AUTOVACCUM功能。

Page 61: 淺入淺出 MySQL & PostgreSQL

61/1472015

Auto / Manual Clean Dead Node

Ref: https://www.facebook.com/yftzeng.tw/posts/10202227746654516

《我的解釋》

這意謂 PostgreSQL轉向MySQL 的自動 (而非人工 ) 數據清理方式。所以也就沒有作者所說的,「讓你自行決定什麼時候執行」的問題,除非我們主動關閉 AUTOVACUUM改手動。

不過,清理數據的時機很敏感 (否則會影響正常運行的效能 ),交由官方演算法自行決定通常會比較安穩,除非你自己很明白你在做什麼。況且, VACUUM也不是沒有副作用。(http://rhaas.blogspot.tw/2011/03/troubleshooting-stuck-vacuums.html)

Page 62: 淺入淺出 MySQL & PostgreSQL

62/1472015

Auto / Manual Clean Dead Node

Ref: https://www.facebook.com/groups/199493136812961/permalink/729886527106950/

Page 63: 淺入淺出 MySQL & PostgreSQL

63/1472015

Auto / Manual Clean Dead Node

Ref: https://www.facebook.com/groups/199493136812961/permalink/729886527106950/?comment_id=731212386974364

《我的解釋》

VACUUM或 AUTOVACUUM,我都讓使用者自行選擇,我只是說 AUTOVACUUM自有一套演算法自己知道何時會最好,如果專家自認「手工」的方式比官方自帶的好,自然改「手工」,我對此從來沒有意見。

Page 64: 淺入淺出 MySQL & PostgreSQL

64/1472015

Auto / Manual Clean Dead Node

Ref: https://devcenter.heroku.com/articles/postgresql-concurrency

Heroku對 auto_vacuum的引入非常樂見

Page 65: 淺入淺出 MySQL & PostgreSQL

65/1472015

Auto / Manual Clean Dead Node

Ref: http://www.postgresql.org/docs/9.4/static/routine-vacuuming.html

PostgreSQL官方文件:

有些管理員會習慣在承載很低的時候,自動執行 VACUUM。但固定在某個時間執行會有一定的風險,例如 (不一定這期間 )突然有非預期大量的 UPDATE活動時,那麼就會發生 "bloat",反而事後需要使用 VACUUM FULL。

使用 autovacuum可以緩解這個問題,因為 autovacuum會動態視 UPDATE活動做調整。所以關閉 autovacuum並不明智,除非你能夠預期極端的工作量發生。

Page 66: 淺入淺出 MySQL & PostgreSQL

66/1472015

Auto / Manual Clean Dead Node

Ref: https://www.facebook.com/groups/199493136812961/permalink/731201573642112/

Page 67: 淺入淺出 MySQL & PostgreSQL

67/1472015

Auto / Manual Clean Dead Node

Ref: https://www.facebook.com/groups/199493136812961/permalink/729886527106950/

作者一直強調:1. DBA一定要知道什麼時候系統最清閒。2. 手動決定而不要自動。

Page 68: 淺入淺出 MySQL & PostgreSQL

68/1472015

Auto / Manual Clean Dead Node

《我的解釋》

很多營運不是政府機關或金融單位。夜間也不一定可以緩機休息。因此,面對全球化營運思維時,系統隨時都有高承載的可能。這意謂著系統即使相對上有「比較空閒」的時間,但此時線上人數都還可能超過數萬,甚至數百萬人使用。

這時候的任何回收行為都會影響正常的系統營運。

還是回到初衷,選擇最適你的業務需求。

Page 69: 淺入淺出 MySQL & PostgreSQL

69/1472015

Auto / Manual Clean Dead Node

《 Sentry 的災難與慘痛經驗 》

The internet is full of awful advice of users suggesting youshould turn off autovacuum, or run it manually at low traffictimes, or simply adjust its schedule to run less often. To knowwhy that’s ill-advised, you first need to understand theconsequences of autovacuum not running.

網路上很多人建議關閉 AUTOVACUUM,改以排程或手動選擇負載低的期間執行 VACUUM。但這是不明智的,你只要知道不運行 AUTOVACUUM會帶來的各種嚴重後果就會明白了。

Ref: http://blog.getsentry.com/2015/07/23/transaction-id-wraparound-in-postgres.html

Page 70: 淺入淺出 MySQL & PostgreSQL

201570/147

大型系統不能用 auto-inc一定要 UUID

Ref: https://www.facebook.com/groups/199493136812961/permalink/697098433719093/?comment_id=697629090332694

Page 71: 淺入淺出 MySQL & PostgreSQL

71/1472015

大型系統不能用 auto-inc一定要 UUID

Ref: https://www.facebook.com/groups/199493136812961/permalink/697098433719093/?comment_id=707018646060405

Page 72: 淺入淺出 MySQL & PostgreSQL

72/1472015

大型系統不能用 auto-inc一定要 UUID

Ref: https://www.facebook.com/groups/199493136812961/permalink/697098433719093/?comment_id=711524915609778

Page 73: 淺入淺出 MySQL & PostgreSQL

73/1472015

大型系統不能用 auto-inc一定要 UUID

Ref: http://en.wikipedia.org/wiki/Universally_unique_identifier

UUID有很多種,用錯結果會不一樣。

常見的有 UUIDv1(Ordered UUID)及 UUIDv4 (Random UUID)。作者在名詞上混淆了兩者。

UUIDv1是跳號循序,同機器上後一個會比前一個大,所以總是INSERT在 last node,仍有 Hotspot問題。

顯然作者這裡用字若再精準些,應該要用 Random UUID,而不應該用較廣泛定義的 UUID。

(所以作者建議的是 Random UUID,如 UUIDv4)

Page 74: 淺入淺出 MySQL & PostgreSQL

74/1472015

大型系統不能用 auto-inc一定要 UUID

其實有很多大型 24x7全球網站系統都用 auto-inc。

Page 75: 淺入淺出 MySQL & PostgreSQL

75/1472015

大型系統不能用 auto-inc一定要 UUID

Ref: http://www.percona.com/blog/2014/12/19/store-uuid-optimized-way/

Page 76: 淺入淺出 MySQL & PostgreSQL

201576/147

MySQL index->lock contention

Ref: https://www.facebook.com/groups/199493136812961/permalink/697098433719093/

Page 77: 淺入淺出 MySQL & PostgreSQL

77/1472015

MySQL index->lock contention

Ref: https://www.facebook.com/groups/199493136812961/permalink/697098433719093/?comment_id=711524915609778

Page 78: 淺入淺出 MySQL & PostgreSQL

78/1472015

MySQL index->lock contention

Ref: http://www.slideshare.net/mysqlops/innodb-internal-9032556 (p17)

Page 79: 淺入淺出 MySQL & PostgreSQL

79/1472015

MySQL index->lock contention

Ref: https://drive.google.com/file/d/0Bw4cH_iKZJzKLXFIWVFfMk13Vm8/view (p21)

Page 80: 淺入淺出 MySQL & PostgreSQL

80/1472015

MySQL index->lock contention

Ref: https://www.facebook.com/groups/199493136812961/permalink/729902013772068/?comment_id=730136760415260

Page 81: 淺入淺出 MySQL & PostgreSQL

81/1472015

MySQL index->lock contention

Ref: https://www.facebook.com/groups/199493136812961/permalink/729902013772068/

Page 82: 淺入淺出 MySQL & PostgreSQL

82/1472015

MySQL index->lock contention

Ref: https://www.facebook.com/groups/199493136812961/permalink/731201573642112/?comment_id=731385080290428

作者簡報上說:MySQL的 B+ tree在 page splitting / merging時,整棵 B+ tree都會加上WRITE_LOCK

但引用 Oracle文章時又改說:Oracle官方人員說得很明白: leaf-node split / merge(他口中的 tree modification change)會引起 indexX lock的。

”前者意謂: always” 會發生。”後者意謂: 只有發生在 leaf-node ”才會 。

我不是故意要找碴,但定義不清楚,很難討論。

Page 83: 淺入淺出 MySQL & PostgreSQL

83/1472015

MySQL index->lock contention

Ref: https://www.facebook.com/groups/199493136812961/permalink/731201573642112/?comment_id=731385080290428

不過我的論點也不是指「 page splitting / merging 不會造成整個 B+ tree 都會加上 WRITE_LOCK」

,而是在某些特定情況下才會,所以不認為是您簡 報上說的 "always"。

"latch"中文是 "鎖 "沒錯,但他的 locked是針對"one page",不等同於 "full index",這是我的重點。但會不會造成 "full index",不好意思,我承認沒有追完所有原始碼。

Page 84: 淺入淺出 MySQL & PostgreSQL

84/1472015

MySQL index->lock contention

Ref: https://www.facebook.com/groups/199493136812961/permalink/731201573642112/?comment_id=731236786971924

1. 我從來沒說過作者不接受批評。2. 我的重點不是MySQL 5.7有沒有修正,而是當下作者稱的事實到底是什麼。

Page 85: 淺入淺出 MySQL & PostgreSQL

85/1472015

MySQL index->lock contention

《整理》

作者的論點 (前後論點兩者彼此衝突 )1. MySQL的 B+ tree在 page splitting / merging時 ,(always)整棵B+ tree都會加上WRITE_LOCK。2.只有 leaf-node split / merge會引起 index X lock。

我的論點 (兩個是獨立事件 )1. “latch” “與 lock” 的定義在MySQL中不一樣。2. ”latch” “只是 one page”,不等同於 "full index"。( ”但若 latch” ”不只是 one page”則可能,原始碼還沒追完 )

Page 86: 淺入淺出 MySQL & PostgreSQL

86/1472015

MySQL index->lock contention

MySQL 5.6.22原始碼storage/innobase/btr/btr0btr.cc第 640行

“latch” ”可能指 tree” (full index) ”,也可能指 node” latch。

Page 87: 淺入淺出 MySQL & PostgreSQL

87/1472015

MySQL index->lock contention

《整理》

作者的論點 (雖然兩者衝突 )1. MySQL的 B+ tree在 page splitting / merging時 ,(always)整棵B+ tree都會加上WRITE_LOCK。2.只有 leaf-node split / merge會引起 index X lock。

我的論點 (兩個是獨立事件 )1. “latch” “與 lock” 的定義在MySQL中不一樣。2. ”latch” “只是 one page”,不等同於 "full index"。( ”但若 latch” ”不只是 one page”則可能,原始碼還沒追完 )2. “latch” ”可以對 node” ”,也可以對 full index”。

Page 88: 淺入淺出 MySQL & PostgreSQL

88/1472015

MySQL index->lock contention

MySQL 5.6.22原始碼storage/innobase/lock/lock0lock.cc第 118行

Page 89: 淺入淺出 MySQL & PostgreSQL

89/1472015

MySQL index->lock contention

《整理》

作者的論點 (雖然兩者衝突 )1. MySQL的 B+ tree在 page splitting / merging時 ,(always)整棵B+ tree都會加上WRITE_LOCK。2.只有 leaf-node split / merge會引起 index X lock。

我的論點 (兩個是獨立事件 )1. “latch” “與 lock” 的定義在MySQL中不一樣。2. ”latch” “只是 one page”,不等同於 "full index"。( ”但若 latch” ”不只是 one page”則可能 )2. “latch” ”可以對 node” ”,也可以對 full index”。

Page 90: 淺入淺出 MySQL & PostgreSQL

90/1472015

MySQL index->lock contention

Ref: http://mysqlserverteam.com/mysql-5-7-improves-dml-oriented-workloads/

Before 5.7, every modifications to non-leaf pages (every modifications for thetree structure) required to exclude the other threads’ access to the whole indexby X-lock, and every concurrent accessing the index tree were blocked.

Page 91: 淺入淺出 MySQL & PostgreSQL

91/1472015

MySQL index->lock contention

Ref#1: http://mysqlserverteam.com/mysql-5-7-improves-dml-oriented-workloads/Ref#2: http://www.percona.com/blog/author/yasufumi/Ref#3: http://dev.mysql.com/worklog/task/?id=6326Ref#4: https://github.com/mysql/mysql-server/commit/070115a3d9548f790039c39a48b19d759ab2407c

Before 5.7, every modifications to non-leaf pages (every modifications for thetree structure) required to exclude the other threads’ access to the whole indexby X-lock, and every concurrent accessing the index tree were blocked.

MySQL開發者講了兩件事:1. page split / merge “時,只有發生在 non-leaf pages”時才會 whole index locked。2. page split / merge “時,只有在 non-leaf pages” ”才稱 tree structure modification”。

補充:這位MySQL開發者是誰?1. 他是 Yasufumi Kinoshita。2. Percona官方認證數一數二 InnoDB專家,從事 InnoDB內核改進多年。 (底下附參考連結 #2)3. 本次的改良幾乎由他主導,是實際改程式碼的人。 (詳見下方參考連結 #3及 #4)4. 如果不相信他,我也不知道該相信誰。

Page 92: 淺入淺出 MySQL & PostgreSQL

92/1472015

MySQL index->lock contention

《整理》

作者的論點 (雖然兩者衝突 )1. MySQL的 B+ tree在 page splitting / merging時 ,(always)整棵B+ tree都會加上WRITE_LOCK。2.只有 leaf-node split / merge會引起 index X lock。

我的論點 (兩個是獨立事件 )1. “latch” “與 lock” 的定義在MySQL中不一樣。2. ”latch” “只是 one page”,不等同於 "full index"。( ”但若 latch” ”不只是 one page”則可能 )

Page 93: 淺入淺出 MySQL & PostgreSQL

93/1472015

MySQL index->lock contention

Ref: https://www.facebook.com/groups/199493136812961/permalink/731201573642112/?comment_id=731280403634229

1. 作者引用官方文件卻誤解真實現象。 (full index lock會發生在 non-leaf node而非 leaf node)2. “如同我所述,確實 latch” ≠ “lock”。3. “我沒有說過 tree modification ≠ page split / merge”。

Page 94: 淺入淺出 MySQL & PostgreSQL

94/1472015

MySQL index->lock contention

经常有人把 latch造成的等待事件误认为是 lock造成的阻塞,其实这是两个完全不同的概念。

在性能优化上,如果能够区别开这两个因素引起的性能问题, 将能极大地提高我们的性能分析判断能力。

Ref: http://zoroeye.iteye.com/blog/2187289

Page 95: 淺入淺出 MySQL & PostgreSQL

95/1472015

MySQL index->lock contention

Ref: Relational Database Index Design and the Optimizers [Wiley] (2005) (31)

什麼是 non-leaf pages?

Page 96: 淺入淺出 MySQL & PostgreSQL

201596/147

MSSQL是垃圾?

Ref: https://www.facebook.com/groups/199493136812961/permalink/729902013772068/

Page 97: 淺入淺出 MySQL & PostgreSQL

97/1472015

MSSQL是垃圾?

Ref: https://www.facebook.com/groups/199493136812961/permalink/731201573642112/?comment_id=731385080290428

這是我的回應:想了解為何作者稱MSSQL為垃圾的證據。

雖然我過去只有一年多的時間使用MSSQL;但MSSQL並不一定很差。

工程師在發現工具 (軟體 )很差時,有時候應先問問自己是否真的明白如何善用手中的工具。殺雞用牛刀?!

Page 98: 淺入淺出 MySQL & PostgreSQL

201598/147

Pgpool超級智障?

Ref: https://www.facebook.com/groups/199493136812961/permalink/706019732826963/

單純想了解為什麼作者覺得 Pgpool超級智障?

Page 99: 淺入淺出 MySQL & PostgreSQL

99/1472015

Pgpool超級智障?

Ref: https://drive.google.com/file/d/0Bw4cH_iKZJzKd25qdV9HTEp4VVk/view (p18)

但 Pgpool仍然出現在作者的簡報中?

Page 100: 淺入淺出 MySQL & PostgreSQL

2015100/147

無論如何絕對別升級到MySQL 5.7?

Ref: https://www.facebook.com/groups/199493136812961/permalink/697098433719093/?comment_id=697105970385006

Page 101: 淺入淺出 MySQL & PostgreSQL

101/1472015

無論如何絕對別升級到MySQL 5.7?

當天演講作者非常強烈不建議使用MySQL 5.7,但缺失也只提出這點

Page 102: 淺入淺出 MySQL & PostgreSQL

102/1472015

無論如何絕對別升級到MySQL 5.7?

Ref: https://www.facebook.com/groups/199493136812961/permalink/731201573642112/?comment_id=731236786971924

可是後來作者又承認MySQL 5.7解決了他心中最大的問題之一

Page 103: 淺入淺出 MySQL & PostgreSQL

2015103/147

Replication crash safe

是否能夠忍受資料丟失?

Master-slave是否能容忍資料不一致?(資料在Master寫入成功,但尚未複製於 Slave時發生當機 )

金融業?

Page 104: 淺入淺出 MySQL & PostgreSQL

104/1472015

Replication crash safe

PostgreSQL 9.0引進了 Stream replication技術,能夠極快地處理WAL (Write-Ahead Logging)日誌。

但 9.0的 Stream replication是 Async replication;當Master當機時,會有資料丟失的風險。

直到 PostgreSQL 9.1 ( 2011-09-11 )引進 Sync replication技術後才解決。

而MySQL必須等到 5.7才有完整的解決方案。比 PostgreSQL晚了約 4年,但也說明MySQL 5.7有很多大改進。

(還是不建議升級為MySQL 5.7嗎? )

Page 105: 淺入淺出 MySQL & PostgreSQL

2015105/147

Query Optimizer

Ref: https://drive.google.com/file/d/0Bw4cH_iKZJzKLXFIWVFfMk13Vm8/view (p24)

Page 106: 淺入淺出 MySQL & PostgreSQL

106/1472015

Query Optimizer

– 《数据库查询优化器的艺术 原理解析与 SQL性能》

PostgreSQL 9.2.3 vs. MySQL 5.6.10

17.3 本章小結 (p486)

  對於子查詢的優化, PostgreSQL和MySQL各有所長;對於等價謂詞重寫,條件的處理,MySQL略勝 PostgreSQL一籌,在各種連接消除方面,二者基本相當,都支持外連接消除和嵌套連接消除。在索引和約束的利用方面,尤其是語義優化和非 SPJ的優化,MySQL顯得技高一籌;對於索引和約束以及條件化簡的充分利用,使得MySQL能及早把計算和推理的工作在查詢計劃生成的過程中完成,從而生成更為高效的查詢執行計劃。

  整體上,MySQL查詢優化器支持的邏輯優化點比 PostgreSQL多,MySQL查詢優化器邏輯查詢優化部分靈光閃爍,讓讀之者愛不德手,但這不代表查詢優化器的效率高於 PostgreSQL。查詢優化器的效率高低需要在現實中根據實際場景通過測試來評估。

Page 107: 淺入淺出 MySQL & PostgreSQL

2015107/147

High Concurrent Write?

PostgreSQL比MySQL更適於應付 High Concurrent Write?

我覺得還是要視業務場景。

Page 108: 淺入淺出 MySQL & PostgreSQL

108/1472015

High Concurrent Write?(Fragmentation)

《MySQL》

INSERT循序時,會頻繁在同一 page操作 (維持 Sequential,但有 Hotspot問題 )。MySQL預設會延遲寫入 Storage,並將連續異動的 pages一次寫入,甚至將請求合併,從而有效降低Random write的次數以及合併部分 Random write變成Sequential write。

但若使用 Random UUID時,寫的不一定是同一 page,所以即使延遲寫入 Storage,也會產生很多 Random write。

Ref: http://www.tocker.ca/2013/05/06/when-does-mysql-perform-io.html

Page 109: 淺入淺出 MySQL & PostgreSQL

109/1472015

High Concurrent Write?(Fragmentation)

《MySQL》

SELECT時,若在Memory中,MySQL會保持 (邏輯 )Ordered。但 PostgreSQL不是,而且再加上它的MVCC設計, UPDATE/DELETE遺留下的 dead rows會使得 Fragmentation更嚴重。

若 SELECT是從 Storage取出時,因MySQL連續異動的 pages一次寫入,甚至將請求合併,所以相近的資料放在同一 block的機率較高。且將 Storage讀出放入Memory時,MySQL仍會保持 (邏輯 )Ordered。

Page 110: 淺入淺出 MySQL & PostgreSQL

110/1472015

High Concurrent Write?(Hotspot)

《 Hotspot》

討論兩種情況:1. 頻繁 UPDATE同一 Row。2. 頻繁 INSERT (Ordered)。

Page 111: 淺入淺出 MySQL & PostgreSQL

111/1472015

High Concurrent Write?(Hotspot:UPDATE)

《 Hotspot》

討論兩種情況:1. 頻繁 UPDATE同一 Row。2. 頻繁 INSERT (Ordered)。

Page 112: 淺入淺出 MySQL & PostgreSQL

112/1472015

High Concurrent Write?(Hotspot:UPDATE)

PostgreSQL

Page 113: 淺入淺出 MySQL & PostgreSQL

113/1472015

High Concurrent Write?(Hotspot:UPDATE)

PostgreSQL

Page 114: 淺入淺出 MySQL & PostgreSQL

114/1472015

High Concurrent Write?(Hotspot:UPDATE)

《MySQL》

直接 UPDATE在同一 Row,不會造成該 Page的大小變化。

《 PostgreSQL》

盡量在同一 Page寫入新的 Row,但若該 Page空間不足時,則會另新建一 Page寫入。

Fragmentation? VACUUM?

Page 115: 淺入淺出 MySQL & PostgreSQL

115/1472015

High Concurrent Write?(Hotspot:UPDATE)

《 PostgreSQL》

PostgreSQL天生容易遇到 Index bloat的問題。

Ref: PostgreSQL 9.0 High Performance [PACKT] (2010) (p171)

Page 116: 淺入淺出 MySQL & PostgreSQL

116/1472015

High Concurrent Write?(Hotspot:UPDATE)

Ref: http://www.slideshare.net/denishpatel/deploying-maximum-ha-architecture-with-postgresql (p28)

Page 117: 淺入淺出 MySQL & PostgreSQL

117/1472015

High Concurrent Write?(Hotspot:UPDATE)

Ref: http://zh.wikipedia.org/zh-tw/%E5%86%99%E5%85%A5%E6%94%BE%E5%A4%A7

SSD:寫入放大效應 +垃圾回收SSD在寫入資料時,一定要抹除該區塊的資料後才能寫入。而抹除的最小單位是 512KB。

即使這 512KB中只有 1KB的資料需要更改,也要將整個區塊中的資料複製到緩衝區,然後將資料抹除後寫回。

舉某些廠牌的測試數據,寫入資料的延遲約為 0.2ms,但抹除需要 2ms。

Page 118: 淺入淺出 MySQL & PostgreSQL

118/1472015

High Concurrent Write?(Hotspot:UPDATE)

Ref: http://zh.wikipedia.org/zh-tw/%E5%86%99%E5%85%A5%E6%94%BE%E5%A4%A7

SSD:寫入放大效應 +垃圾回收

Page 119: 淺入淺出 MySQL & PostgreSQL

119/1472015

High Concurrent Write?(Hotspot:UPDATE)

Ref: http://is.gd/eUss8P (如何写一个为 SSD 优化的数据库? )

SSD重寫數據時由於寫放大效應的存在隨機寫入可能會比順序寫入帶來的損耗更大。

Page 120: 淺入淺出 MySQL & PostgreSQL

120/1472015

High Concurrent Write?(Hotspot:INSERT)

《 Hotspot》

討論兩種情況:1. 頻繁 UPDATE同一 Row。2. 頻繁 INSERT (Ordered)。

Page 121: 淺入淺出 MySQL & PostgreSQL

121/1472015

High Concurrent Write?(Hotspot:INSERT)

PostgreSQL

Page 122: 淺入淺出 MySQL & PostgreSQL

122/1472015

High Concurrent Write?(Hotspot:INSERT)

《MySQL》

直接 INSERT(Ordered)在同一 Page。

《 PostgreSQL》

直接 INSERT(Ordered)在同一 Page。

Page 123: 淺入淺出 MySQL & PostgreSQL

123/1472015

High Concurrent Write?(實驗數據 )

有些實驗數據顯示 PostgreSQL在高壓寫入 /更新時比MySQL快。

Page 124: 淺入淺出 MySQL & PostgreSQL

124/1472015

High Concurrent Write?(實驗數據 )

Ref: http://www.percona.com/blog/2014/12/19/store-uuid-optimized-way/

Page 125: 淺入淺出 MySQL & PostgreSQL

125/1472015

High Concurrent Write?(實驗數據 )

有沒有把 PostgreSQL VACUUM / Fragmentation因子考慮進去?有些從開始到結束,可能連一次 VACUUM都沒執行過。

PostgreSQL 8.1新增 autovacuum功能。PostgreSQL 9.0預設啟動 autovacuum。

MySQL預設則是會在背景啟動 Purge。

MySQL預設使用 REPEATABLE-READ;PostgreSQL預設使用 READ-COMMITTED。

Page 126: 淺入淺出 MySQL & PostgreSQL

126/1472015

High Concurrent Write?(PURGE/VACUUM)

MySQL InnoDB清理舊資料使用的是 PURGE;PostgreSQL清理舊資料使用的是 VACUUM。

Page 127: 淺入淺出 MySQL & PostgreSQL

127/1472015

High Concurrent Write?(PURGE/VACUUM)

InnoDB只有最新的資料會留在 table中,舊資料會移到 rollbacksegment。意謂舊資料會移出空間並標示為未來可清除。

於是, Purge得以擺脫 table中的任何 deleted rows,並專心從rollback segment中清理舊資料。

PostgreSQL沒有類似 rollback segment的設計,導致最終的清理工作較昂貴。由於少了中心化的清理資訊, VACUUM必須掃描全表,以找出需要清理的舊資料。

Ref: http://rhaas.blogspot.tw/2011/02/mysql-vs-postgresql-part-2-vacuum-vs.html

Page 128: 淺入淺出 MySQL & PostgreSQL

128/1472015

High Concurrent Write?(PURGE/VACUUM)

PostgreSQL 8.3之後,加入了 HOT ("heap only tuple")。

但 HOT並沒有完全解決問題,它的缺點如下:1. 只有在所有索引屬性都沒有被更新時才能使用 HOT。2. 只有在被更新記錄所在頁面能夠存儲新版本時才能用 HOT。

Ref: http://rhaas.blogspot.tw/2011/02/mysql-vs-postgresql-part-2-vacuum-vs.html

Page 129: 淺入淺出 MySQL & PostgreSQL

129/1472015

High Concurrent Write?(PURGE/VACUUM)

PostgreSQL 8.4之後,加入了 bitmap,也就是 visibility map,得以指出哪些需要清理的 pages。

使得 VACUUM可以掃描 dirty pages,但也僅止於 pages而不是直接指到 rows。

而 VACUUM仍然需要掃描所有 index,這個操作在大表裡很昂貴。

Ref: http://rhaas.blogspot.tw/2011/02/mysql-vs-postgresql-part-2-vacuum-vs.html

Page 130: 淺入淺出 MySQL & PostgreSQL

130/1472015

High Concurrent Write?(PURGE/VACUUM)

PostgreSQL讓 UPDATE比較快 (因為把問題往後丟 );MySQL讓 PURGE比 VACUUM快 (提前處理問題 )。

但 PostgreSQL要小心事務的成長導致 VACUUM跟不上的情形。

(系統瓶頸在寫入不夠快時發現容易,還是 VACUUM跟不上時 ?)

Ref: http://rhaas.blogspot.tw/2011/02/mysql-vs-postgresql-part-2-vacuum-vs.html

Page 131: 淺入淺出 MySQL & PostgreSQL

131/1472015

High Concurrent Write?(PURGE/VACUUM)

VACUUM會造成大量的 IO,進而影響其它的效能。

Plain VACUUM可能無法滿足業務有大量的 UPDATE/DELETE。如果有這種情形,則應使用 VACUUM FULL,或 CLUSTER或ALTER TABLE。

Ref: http://www.postgresql.org/docs/9.4/static/routine-vacuuming.html

Page 132: 淺入淺出 MySQL & PostgreSQL

132/1472015

High Concurrent Write?(抖動 )

對於一個上線服務而言,穩定性遠大於平均效能。意即效能防抖動,好預估,降低重要時刻發生在低點的機率。

PostgreSQL的理念是把問題往後丟,不管是 Fragmentation或GC,而這些多少也可能造成 SSD的效能抖動。且 VACUUM的性能會因表愈大愈慢 (執行期間也會影響其它工作 )。

MySQL的理念則是提早解決問題,不管是 Ordered Index、Sequential或 GC。所以MySQL平均效能抖動有機會平緩,但相對地,最佳高峰性能表現可能不及 PostgreSQL。

不過這問題太複雜,需視參數及硬體的實際特性而論,最終還是需以業務長期測試數據為準。不同業務有不同結果。

Page 133: 淺入淺出 MySQL & PostgreSQL

133/1472015

High Concurrent Write?(XID)

PostgreSQL對每個事務都有分配一個 XID。這些事務不是只指BEGIN/COMMIT,還包括 INSERT / UPDATE / DELETE。每次使用都會遞增。

但這個 XID是 32bits,最大支持 40億個事務。當 XID達到最大值時,會從零再度開始。

突然間,所有事務變成未來所產生的,新事務都沒有辦法訪問這些舊紀錄了。

Ref: https://devcenter.heroku.com/articles/postgresql-concurrency

Page 134: 淺入淺出 MySQL & PostgreSQL

134/1472015

High Concurrent Write?(XID)

《 Sentry 的災難與慘痛經驗 》

Sentry遇到非常嚴重的災難,這一切都與 XID的設計有關。

如果你的系統負載很高,而你又關閉 AUTOVACUUM時。最終你會因為 XID達到上限值而造成MVCC不再正常運作,造成資料遺失等各種麻煩問題。

PostgreSQL官方網站聲明, XID是 32 bits,理論上限為四百萬筆交易。為了避免這個問題,最好每二百萬筆交易時就要執行 VACUUM。

Ref: http://blog.getsentry.com/2015/07/23/transaction-id-wraparound-in-postgres.htmlRef: http://www.postgresql.org/docs/9.5/static/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND

Page 135: 淺入淺出 MySQL & PostgreSQL

135/1472015

High Concurrent Write?(TokuDB)

倘若使用MySQL真遇到需要 Concurrent Write高的業務情況時,也可以使用一行指令將 InnoDB轉換為 TokuDB。

TokuDB採用類似於 PostgreSQL的設計,但更為先進 (官方說法 ),且已申請專利。

早期是商用軟體,現已依 GPL-2.0開放源碼。

但 TokuDB也不是沒有缺點。

Page 136: 淺入淺出 MySQL & PostgreSQL

136/1472015

High Concurrent Write?(WebScaleSQL)

WebScaleSQL主要由四家業者支持:1. Facebook2. Google3. LinkedIn4. Twitter

阿里巴巴隨後也一同參與開發計畫: 『阿里 MySQL 团队加入参与 WebScaleSQL 开发』

Ref: http://www.oschina.net/news/58837/alibaba-mysql-team-join-webscalesql

Page 137: 淺入淺出 MySQL & PostgreSQL

137/1472015

High Concurrent Write?

每個軟體都有它的優點與缺點,重要的是我們必須先瞭解需求,而後選擇正確的工具。

Page 138: 淺入淺出 MySQL & PostgreSQL

2015138/147

勘誤回報

若本簡報有任何錯誤,歡迎指正回報。

請寄至 <[email protected]>

Page 139: 淺入淺出 MySQL & PostgreSQL

2015139/147

最後

Ref: https://www.facebook.com/groups/199493136812961/permalink/728646047230998/

Page 140: 淺入淺出 MySQL & PostgreSQL

140/1472015

最後

我同意作者說的。

Open Source的世界,大家都可以成為 Coder。

但若流於批評就不好了。

Page 141: 淺入淺出 MySQL & PostgreSQL

141/1472015

最後

Ref: https://www.facebook.com/groups/199493136812961/permalink/731201573642112/?comment_id=732041130224823

Page 142: 淺入淺出 MySQL & PostgreSQL

142/1472015

最後

我無意流於情緒之爭。我只想討論技術。

Ref: https://www.facebook.com/groups/199493136812961/permalink/731201573642112/?comment_id=731218686973734Ref: https://www.facebook.com/groups/199493136812961/permalink/729886527106950/?comment_id=731385066957096

Page 143: 淺入淺出 MySQL & PostgreSQL

143/1472015

最後

Ref: https://www.facebook.com/groups/199493136812961/permalink/731201573642112/?comment_id=732041130224823

Page 144: 淺入淺出 MySQL & PostgreSQL

144/1472015

最後

Ref: https://www.facebook.com/groups/199493136812961/permalink/731201573642112/?comment_id=732041130224823

而我只是說:

而我只是說:

我不覺得個人情緒需要在 Facebook的【 PHP台灣】公眾技術討論社團中發洩。況且內容與 PHP無關,也與資料庫技術無關。

作者罵我說:

作者怒罵說:

Page 145: 淺入淺出 MySQL & PostgreSQL

145/1472015

最後

Ref: https://www.facebook.com/groups/199493136812961/permalink/731201573642112/?comment_id=732041130224823

為什麼我的公開討論不能算是實際行動?為什麼不能好好討論技術?為什麼技術討論要變成戰公司?為什麼對我人身攻擊外,還要攻擊我公司?

Page 146: 淺入淺出 MySQL & PostgreSQL

146/1472015

最後

Ref: https://www.facebook.com/groups/199493136812961/permalink/718233354938934/

Page 147: 淺入淺出 MySQL & PostgreSQL

147/1472015

最後

Ref: https://www.facebook.com/groups/199493136812961/permalink/718233354938934/