Home » 2013 » April (Page 2)

MySQL 5.7...

Oracle 的「MySQL :: MySQL 5.7 Reference Manual :: 1.4 What Is New in MySQL 5.7」列出 MySQL 5.7 預定會有的功能。由於還在發展階段,這頁還會繼續變動。

針對 ALTER TABLE 有不少改善,以下的條件下 ALTER TABLE 將不會產生 temporily table (不會卡住):

  • table 改名。
  • column 改名。
  • column 改 default value。
  • enum 或 set 在不修改原來值的情況下增加值。
  • partition 相關操作。
  • index 改名。
  • index 新增與刪除。(僅限 InnoDB)

幾個常見的操作變得更簡單了,pt-online-schema-change 的功能會慢慢被整合回 MySQL。

然後 InnoDB 要支援 spatial data types 了,不過 index 還沒支援... 不知道有沒有機會看到 :o

維基百科英文版與德文版的資料庫 (條目最多的兩個語言) 從 MySQL 轉移到 MariaDB 了...

維基百科官方宣佈兩個條目最多的資料庫 (英文與德文) 已經從 MySQL (有 FB patch 的版本) 轉移到 MariaDB 5.5 了:「Wikipedia Adopts MariaDB」。

維基百科的資料庫從 MySQL 4.0 升級到 MySQL 5.1 時花了不少功夫轉換 (可以想像出來,這兩個版本的差距...),然後這次再到這次的 MariaDB 5.5 就輕鬆不少。

在文章內有提到因為維基百科是 read-heavy site,大多數前端的負荷都在 squid 層擋下來,實際到後端的量則是再透過 Redismemcached 打散負荷。不過即使做了這麼多層 cache,英文版資料庫在尖峰時間還是有 50k qps 的量在跑。

尖峰時間這 50k qps 的量有 80% (也就是 40k qps) 是打散到兩台不同地點的 slave 上,平均的 query response time 是 0.2ms,95% 則是 50ms (好高),其他的 20% 是寫入 master 需求,或是因寫入 master 時需要一致性 (也就是要避免 replication lag 造成的問題)。

這次升級到 MariaDB 5.5.30 是先準備一台新機器,然後在 load balancer 上換掉其中一台 slave (先建後拆),如果 MariaDB 真的有問題也可以馬上 rollback 回來。另外用 pt-query-digest 取樣分析 query 的狀況。

這是成果:

For our most common query type, 95th percentile times over an 8-hour period dropped from 56ms to 43ms and the average from 15.4ms to 12.7ms. 50th percentile times remained a bit better with the 5.1-facebook build over the sample period, 0.185ms vs. 0.194ms. Many query types were 4-15% faster with MariaDB 5.5.30 under production load, a few were 5% slower, and nothing appeared aberrant beyond those bounds.

第一台觀察一陣子沒問題後,接下來一台一台換掉。然後發公告慶祝 :p

Facebook 的 Memcache 架構...

NSDI '13Facebook 的工程師有講到 Facebook 內的 Memcache 的架構:「Scaling Memcache at Facebook」,有影片可以看,也有 PDF 投影片可以下載。

其實 2013 年這次的 conference 提到的架構以前就有提過了... 雖然一時間找不到之前提到架構的投影片,但還是可以配合著以前提到各種架構的文章與投影片看出 Facebook 怎麼利用 Memcache 架構 cache layer:

Facebook 會這樣設計 Memcache 架構,跟 Facebook 用 PHP 的方式有關,是在 PHP 的限制下想辦法爭取效率的作法。

不過這些投影片裡的資料畢竟是有年代了,現在的 memcached 改善了很多,跟當年的情況不太一樣,看之前的投影片最好知道當時 memcached 有哪些問題會比較能理解 Facebook 的工程師們想要解決什麼問題。

OCSP 是如何影響 HTTPS 的效率...

Netcraft 從 2012 年 11 月開始偵測 OCSP 的 availability,然後發現各家 OCSP 的穩定性都不太好:「Certificate revocation and the performance of OCSP」。

OCSP 是 Online Certificate Status Protocol 的縮寫,當 HTTPS 連線建立中,client 可以透過 OCSP 詢問這份 certificate 是否有效。這是 PKI 架構下的事後補救機制,因為已經發出去的簽名是無法被收回的,只好靠連線時再查詢。

另外一個機制比較舊,叫 CRL (Certificate Revocation List),則是屬於清單類的機制,更新速度比 OCSP 慢。

目前是以 OCSP 為主,而舊的平台 (就是 XP 上的 IE) 則只支援 CRL。

可以看到 OCSP 檢查打開後對於速度的影響,有的影響很明顯,有的還好。而原文下面很多張 uptime 圖表也可以看出來各家 OCSP 的穩定性其實不怎樣,有些是直接上 Akamai 解決,有些是上 CloudFlare 解決 (然後遇到幾次 CloudFlare 爆炸就跟著炸 XD)

目前瀏覽器大多都是 soft-fail,也就是查不到就當作 pass。照目前的穩定性要推動 hard-fail (查不到就 break) 應該是頗有難度...

對於 HTTPS 速度很在意的人可以看一下內文的說明,可以挑 OCSP 速度比較快的幾家簽,對速度會有幫助...

Percona Server 5.5.30-30.2 (based on MySQL 5.5.30) 的改善

Percona 在前幾天推出基於 MySQL 5.5.30 的 Percona Server 5.5.30-30.2:「Percona Server for MySQL 5.5.30-30.2 now available」。

5.5.30-30.2 這個版本引入了 jemalloc

Percona Server for MySQL will now be shipped with the libjemalloc library. Benchmark showing the impact of memory allocators on MySQL performance can be found in this blogpost. (Ignacio Nin)

在去年 (2012 年) 七月 Percona 就有分析過 glibc 與 jemalloc 對效能的差異:「Impact of memory allocators on MySQL performance」,可以看到在 concurrent active connection 數量愈高,jemalloc 的優勢愈明顯。

預設總算把 jemalloc 包進去了,等好久了...

另外一個是「trx descriptors: MySQL performance improvements in Percona Server 5.5.30-30.2」,針對 transaction lock 問題的改善。

這邊比較時都用 jemalloc,是因為 Percona Server 5.5.30-30.2 是用 jemalloc,比較時必須盡可能維持一樣的條件。

圖表可以看到 Percona 把 5.6 的改善方式再改善,然後 backport 回 5.5,使得沒有被飆為 read only transaction 的 query 也能受益。

Archives