換 NoSQL 前的建議...

原文是「Medium Data: things to try before abandoning SQL」,放棄 SQL 前應該要嘗試的事情,原文一開始就用粗體說明帶有強烈的偏見 XD

First, my thesis: a lot of less-experienced developers are using big data and NoSQL technologies because they are new and cool, and because SQL is old and hard. A lot of these people would save themselves time and effort by learning more about SQL and tuning their databases and hardware just a little bit.

文章寫的相當概念性,主要是說明幾件事情:

  • 其實 SQL 可以解決大部分的事情,大家都知道 SQL 的瓶頸在哪裡,有哪些 workaround 可以避開。
  • 不要因為 MySQL 做不到就覺得 SQL 不好用,在這種情況下,PostgreSQL 的功能與成熟度很值得看看。
  • 不要用 Oracle 官方版本的 MySQL... XD
  • 通常可以用 cache 解決的就用 cache 試著解看看,雖然 invalidate 問題不太好處哩... XD
  • 如果是 Read 數量太多,可以用 replication 解決不少問題。
  • 試著去理解 index 的「原理」,也就是資料結構,這對於要怎麼用 index 絕對有強力的幫助。
  • 當上面都做完而發現還是不夠的時候就 sharding 吧。

MySQL 5.5 與 5.6 的預設值差異...

Oracle 放出 MySQL 5.6 後,Percona 將 MySQL 5.5 與 5.6 設定值的差異整理列出來:「MySQL 5.5 and 5.6 default variable values differences」。

因為這是直接 dump 系統設定值比較,理論上所有「可以設定的值」都可以透過這個方法找出差異,不是靠設定值的改變就沒辦法了...

文章後面有對作者覺得比較需要講的部份提出來。其中 innodb_file_per_table 終於變成預設值了 XD

先繼續觀望...

熱 MySQL 的方法...

看到 jnlin 寫的「利用 Percona Playback warm-up MySQL 資料庫...」,把之前用到的「用 pt-find 加熱 (暖機) InnoDB table」改良讓他可以平行跑,儘可能吃完 I/O capacity:

pt-find --charset=utf8 --print -h $1 -u USER -p PASSWORD | xargs -t -P8 -I% -n1 sh -c "echo 'SELECT COUNT(*) FROM %;' | mysql -h $1 > /dev/null"

在 PostgreSQL 裡分析 PostgreSQL mailing list 行為...

在「Analyzing PostgreSQL Email Archives with PostgreSQL」這篇文章看到的,用 PostgreSQL 所提供的功能找出一些資訊... (像是 full text search 的功能)

於是就產生出這樣的圖:(應該不用解釋?)

還有「Probability that a new thread gets a response」或是與 Competitors 相關的統計 XD

MySQL 平行執行的 Replication...

MySQL Replication – Multi-Threaded Slaves (Parallel Event Execution)」這篇在講 MySQL 5.6 的 multi-threaded replication。

在文章裡提到,在 5.6.3 之前的版本,MySQL replication 都是 single-threaded,所以當 master 可以充分發揮多 CPU 能力時,slave 仍然要一個更新跑完才會跑下一個更新。

舉例來說,假設 master server 上有兩個 thread 在跑:

  • thread 1 正在執行 UPDATE table1 SET foo = 0 WHERE ...; (SQL 1,假定是 CPU bound,需要跑 100 秒)
  • thread 2 正在執行 UPDATE table2 SET bar = 1 WHERE ...; (SQL 2,也假定是 CPU bound,也需要跑 100 秒)

假設 thread 1 先執行完,這時候 slave 就會在跑完的時候收到 SQL 1,然後把資料同步進去。等到 100 秒過去後,再跑 SQL 2,再花 100 秒。這導致了最少 100 秒的 replication lag (master 與 slave 不同步的時間)。

在 master server 執行時會是這樣:

兩個 SQL query 可以同時跑。

到了 slave 時,在 MySQL 5.6.3 之前的 replication 會變成這樣:

可以看到還是得先執行 SQL 1 再執行 SQL 2,所以最長會有 200 秒的 replication lag。

而 5.6.3 之後支援 multi-threaded replication,可以用 slave_parallel_workers 指定平行執行 SQL query 的數量,這讓 master server 與 slave server 之間的 replication lag 降低不少:

在收到同步的 SQL 指令後就可以同時跑,這讓 replication lag 降到 100 秒。

不過還是要提,如果希望把資料同步問題降到最低,那麼 Galera Cluster 可以解的更徹底,不論是寫入的那台 master server,或是其他的 master server (在 Galera Cluster 架構裡都是為 master),一律都是同步執行:

不會有 master server 與 slave server 不同步的問題,可以減少很多 application 層的麻煩...

測試 MariaDB 後的一些感想...

Monty Program ABMySQL 的發起人 Monty 在離開 Sun 之後所創辦的公司 (他同時也是 MySQL AB 的創辦人),這家公司目前以 MariaDB 為發展主力。

先說對 MariaDB 目前的看法:暫時還是會用 Percona 所提供的版本,以及 XtraDB (基於 InnoDB 的產品)。

MariaDB 發展的重點在於 Aria storage Engine,但目前的 1.5 版只支援 crash-safe,要到 2.0 才會支援 InnoDB 主要功能,而到了 2.5 才會針對效能調整,看起來要到「能用」必須要到 2.5 之後... (參考「Aria FAQ」的說明)

InnoDB 控制權在 Oracle 手上,XtraDB 控制權在 Percona 手上,而 MyISAM 拿不上檯面。所以 Monty 想要一個控制權在他自己手上的 storage engine...

對於社群來說,因為 XtraDB 還是基於 InnoDB 的分支,所以當 Oracle 從 InnoDB 抽手後大家會擔心 Percona 能夠自己發展到什麼程度。這使得對於 Aria 有所期待,也趁著現在 Oracle 被歐盟盯著不致於做的太明顯趕快發展。

這也可能是 WikimediaMozilla 選 MariaDB 當 slave 測試的原因?當然也有可能只是「看名字比較順眼」之類的原因而選... XD

看 Mozilla Database Team 的年終報告...

有時候除了可以看介紹新技術的文章學東西外,報告類的文章也可以看得出來目前的趨勢。

像是 Mozilla Database Team 的年終報告描述近況與最後這季做了哪些事情「December News from the Mozilla Database Team」:

  • 之前還在用 MySQL 5.0,現在 Migrate 到 5.1 了,另外正在嘗試 MariaDB 5.5。
  • 很大一部分是在 tune Bugzilla 的效能,包括 SQL query optimization,以及 data partition 計畫。
  • 測試 SSD 覺得不錯,看起來好像也測過 Fusion-io 的產品,不過價錢不太能接受?

另外還有一些 PostgreSQL 的說明,看起來還沒穩下來...

目前已經看到維基百科與 Mozilla 都在嘗試 MariaDB,看了看 MariaDB versus MySQL - Features 發現有趣的東西還不少,除了 Aria 以外,Virtual ColumnsDynamic columns 似乎都是有趣的東西...

MySQL 的 audit log

在「Auditing login attempts in MySQL」這篇文章裡討論 MySQL 登入的 audit log,其中第一個方法是 full log (包含 SELECT 這類指令),看起來可以活用...

打開 General Query Log 後,幾乎所有的行為都會被記錄下來,照這個設計應該可以寫到 FIFO 裡丟到 log server 上?不知道會增加 log server 多少負荷...

使用 Percona Toolkit 管理 MySQL...

Percona 在前幾天辦了 Webniar 解釋 Percona Toolkit 要怎麼用 (並且宣傳有多好用 XD):「10 Percona Toolkit Tools Every MySQL DBA Should Know About」。

依照慣例,Percona 在結束後會把投影片與錄影整理後放出來 (也就是上面的連結),如果沒時間的話可以看投影片留個印象,有時間的話可以實際操作看看到底有多好用。

另外在 MySQL Performance Blog 上主講者也整理了 Q&A 的部份也很值得看一看:「Percona Toolkit Webinar followup Q&A」。

Wikipedia 把英文版資料庫的其中一個 slave 從 MySQL 5.1 換到 MariaDB 5.5...

維基百科的 mailing list 上丟出的消息,英文版 Wikipedia 資料庫的 slave server 目前已經在 MariaDB 5.5 上了:「mariadb 5.5 in production for english wikipedia」。

之前跑的版本是 MySQL 5.1 + Facebook patchset 版本,整體大約快了 8%:

Taking the times of 100% of all queries over regular sample windows, the average query time across all enwiki slave queries is about 8% faster with MariaDB vs. our production build of 5.1-fb. Some queries types are 10-15% faster, some are 3% slower, and nothing looks aberrant beyond those bounds. Overall throughput as measured by qps has generally been improved by 2-10%. I wouldn't draw any conclusions from this data yet, more is needed to filter out noise, but it's positive.

然後計畫在接下來一兩個月觀察,沒問題就全換:

MariaDB has some nice performance improvements that our workload doesn't really hit (better query optimization and index usage during joins, much better sub query support) but there are also some things, such as full utilization of the primary key embedded on the right of every secondary index that we can take advantage of (and improve our schema around) once prod is fully upgraded, hopefully over the next 1-2 months.

效能不是最主要考量,而是政治面的原因,官方說法是支持 open source 社群:(沒有講的就是「我們對 Oracle 不怎麼信任...」)

The main goal of migrating to MariaDB is not performance driven. More so, I think it's in WMF's and the open source communities interest to coalesce around the MariaDB Foundation as the best route to ensuring a truly open and well supported future for mysql derived database technology. Performance gains along the way are icing on the cake.

另外參考:「on wikipedia and mariadb」。