Google 弄出來的 Grumpy:把 Python 2.7 的程式碼轉成 Go...

Google 放出 Grumpy,可以把 Python 2.7 的程式碼轉成 Go:「Grumpy: Go running Python!」。

下面看到一個留言頗有趣的:

This sad to see that Grumpy is mean to be a replacement of CPython 2.7 instead of CPython 3.x . I presume the code from youtube was written in python 2.x hence the reason but I hope we'll see Grumpy supporting python 3.x :)

回到原文,這次的需求主要是出自 YouTube 的需求:

The front-end server that drives youtube.com and YouTube’s APIs is primarily written in Python, and it serves millions of requests per second! YouTube’s front-end runs on CPython 2.7, so we’ve put a ton of work into improving the runtime and adapting our application to work optimally within it.

然後 Python 的 GIL 又被拿出來鞭屍:

除了 C extension 不支援外,還是有些「過於動態」的語法不支援:

exec, eval and compile: These dynamic features of CPython are not supported by Grumpy because Grumpy modules consist of statically compiled Go code. Supporting dynamic execution would require bundling Grumpy programs with the compilation toolchain which would be unwieldy and impractically slow.

這樣可用的範圍少不少,這個專案可以當作 YouTube 這種規模的網站所做的改善,而不是什麼可以拿來用的工具 :o

關閉 MySQL 的 Query Cache

MySQL 的 Query Cache 是目前已知效能不好的主要因素之一 (global mutex lock 的緣故),在正式環境裡的 best practice 一般都是關閉,之前測過也是一開下去效能就會狂掉...

Percona 的人在討論要怎麼樣才能完全關閉 MySQL 的 Query Cache:「Is Your Query Cache Really Disabled?」,而他們發現只有在 query_cache_typequery_cache_size 都設為 0,而且重開 MySQL 才能完全避免 global mutex lock:

[W]e can see it is not possible to fully disable the query cache on the fly by changing query_cache_type or/and query_cache_size to 0. Based on the code and the tests, if you want to make sure the query cache is fully disabled, change query_cache_size and query_cache_type to 0 and restart MySQL.

應該是要再修正 my.cnf 的 template 了...

Netflix 開發的 Delayed Queue

原來這個叫做 Delayed Queue,難怪之前用其他關鍵字都找不到什麼資料... (就不講其他關鍵字了 XD)

Netflix 發表了他們自己所開發的 Delayed Queue:「Distributed delay queues based on Dynomite」。

本來的架構是用 Cassandra + Zookeeper 來做:

Traditionally, we have been using a Cassandra based queue recipe along with Zookeeper for distributed locks, since Cassandra is the de facto storage engine at Netflix.

但可以馬上想到不少問題,就如同 Netflix 提到的:

Using Cassandra for queue like data structure is a known anti-pattern, also using a global lock on queue while polling, limits the amount of concurrency on the consumer side as the lock ensures only one consumer can poll from the queue at a time.

所以就改放到 Netflix 另外開發的 Dynamite 上:

Dynomite, inspired by Dynamo whitepaper, is a thin, distributed dynamo layer for different storage engines and protocols. Currently these include Redis and Memcached. Dynomite supports multi-datacenter replication and is designed for high availability.

後端是 RedisMemcached 的系統,可以對抗整個機房從 internet 上消失的狀態。

在設計上則是「保證會跑一次」,也就是有可能會有多次的情況,用 Dyno Queues 系統的人必需要考慮進去:

4. At-least-once delivery semantics

雖然整篇講的頗輕鬆,但實際看起來還是很厚重... 暫時還是不會用吧 :o

Composer 出現 lock file out of date 的解法

之前也有遇到,結果 Lorna Jane Mitchell 寫了一篇「Handling Composer "lock file out of date" Warning」給了不少解法。

第一種是 composer upgrade,直接全部升級。

第二種是先用 composer update --dry-run 看看是不是有人加到 composer.json 後忘記更新,如果是的話再用 composer update [package] 處理。

第三種是用 composer update nothing 閉上眼睛更新 hash 值,當作什麼都沒看到 XDDD

Sometimes this is the right answer so it's a handy trick to know!. I seem to see these kinds of issues in people's projects quite often (I'm a consultant, I see a lot of projects) so I thought I'd share my usual tactics for getting things sorted - if you have any tricks of your own to share, I'd love to hear them :)

該說很「實用」嗎 XDDD

Berkeley DB 的介紹

在滿滿都是 NoSQL 的世代中,意外在「Berkeley DB: Architecture」這邊看到 Berkeley DB 的介紹...

2006 年 Berkeley DB 的公司 SleepycatOracle 收購。在收購後 Oracle 改變了 open source 授權部份,從之前的 Sleepycat License 改成了 AGPLv3

Berkeley DB 算是早期功能很完整的 database library,由於 page level locking、crash-safe 加上有 transaction,也曾經被 MySQL 拿去當作 engine,不過在 MySQL 5.1 被拔掉:「14.5 The BDB (BerkeleyDB) Storage Engine」。

文章裡講了很多底層設計上的想法 (而非單純只說明「做了什麼」),以四個面向來討論。Buffer、Lock、Log 以及 Transaction,並且圍繞著 ACID 需求討論。

算是懷念的考古文?Google 弄出來的 LevelDBFacebook 接著改善的 RocksDB 的走向也不太一樣了,現在大家對 ACID 需求因為 NoSQL 盛行的關係又重新在檢視...

MySQL InnoDB 遇到 Deadlock 時的判讀

Percona 的「How to deal with MySQL deadlocks」這篇文章裡面提到了 MySQL InnoDB Deadlock 的判讀與處理。

在支援 transaction 的 engine 裡 deadlock 是不可避免的常態。

在 MySQL 5.5 以及之前的版本,可以透過 Percona 的 pt-deadlock-logger 這隻 script,每固定幾秒鐘就跑一次 SHOW ENGINE INNODB STATUS 記錄下來。在 MySQL 5.6 之後,可以直接使用 innodb_print_all_deadlocks 這個參數,遇到 deadlock 時就寫到 error log 裡。

有了 log 後,接下來就可以判讀 deadlock 的情況,得知是什麼樣的情況造成 deadlock。

文章最後面則是對減少 deadlock 的方法給了一些建議,都是比較一般性。一般還是要靠 bussiness logic 的分析來切割降低 deadlock 的情況。

不過這篇文章需要一些背景知識,像是 InnoDB Lock Modes 與維基百科上的「Multiple granularity locking」,對解讀會有更多幫助。

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 也能受益。

MySQL 內 JOIN 的應用...

Common use cases for the MySQL Join statement」這篇給的範例與把 MySQL 上常用到的幾種 JOIN 提出來分析,包括 index 與 explain。另外在「Managing hierarchical data with MySQL」也提到了要怎麼處理階層式資料。

對於 JOIN 大概分幾個階段:

  • 在使用 MyISAM 的時候會儘量避免 JOIN,因為當 SQL 執行時間久的時候會有好幾個 table 同時卡住無法寫入。
  • 改用 InnoDB 後一直用 JOIN,不論是報表或是 web SQL query,造成 CPU bound (雖然不是 table lock,但在 MVCC 架構下,讀取也還是有 lock 成本存在)。
  • 把 JOIN 形式的 web SQL query 拆成多個 SQL query 以降低 lock 成本;針對計算成本很高的結果 cache,再針對 cache 效果不佳的表格逆正規化。只有報表不受限使用 JOIN。

後面的階段則是 data sharding 與 NoSQL。不過每個階段的界線不是那麼明顯,有時候會重疊在一起...

說到逆正規化,MariaDBVirtual Columns + PERSIST 好像是逆正規化的好工具,再來測仔細一點...

MySQL 中,MyISAM 與 InnoDB 帶來的差異...

標題所提到的兩個 engine 是在 MySQL 中最常用到的兩個 engine。其中 MyISAM 是在 MySQL 5.1 之前的 default engine,InnoDB 則是 MySQL 5.5 之後的 default engine。

這篇主要是講 MySQL 5.1 + InnoDB Plugin,或是 MySQL 5.5 後的情況。

MyISAM 是 Table-level lock,當有寫入時其他人無法讀取 (有少數例外,像是 bulk insert)。而 InnoDB 設計成 Row-level lock,在寫入時有很大機會還是可以讀取。

另外,InnoDB 支援 ACID transaction,對於學過資料庫理論的人 (像是科班出身) 會覺得比較「親切」,比起 MyISAM 有很多東西可以用。

大多數不換 InnoDB 有幾個原因:

InnoDB 佔用的空間比較大

最常見的原因是認為 InnoDB 相對 MyISAM 所佔用的空間會大不少 (看過三倍大的):但在 InnoDB 自從推出壓縮功能後就接近很多 (看過只大 20% 的,甚至有可能比 MyISAM 小)。而資料量的問題可以參考 Mobile01 的 55GB (2012 年 10 月 uid=1 的蔣大在 Mobile01 上揭露的數字)。

當網站夠大時,記憶體與用 15KRPM SAS 硬碟加上 RAID1+0 的一次性成本其實不高。

InnoDB 不好備份

第二個常見的原因是認為 MyISAM 備份比較容易,直接 copy 就可以備份:這種備份方式其實有很高的風險造成 inconsistent backup (「備份的資料損毀」)。以交易的例子來說,有 auction 與 user 兩個表格,按照字母順序先複製了 auction 表格,再複製 user 表格,中間使用者用點數購買了某個物品 (扣 user 表格裡的點數,在 auction 裡建立一筆資料)。這份備份裡就會備份到「user 內的點數扣掉,但 auction 沒有資料」的情況。

比較好的方式是用 InnoDB 提供的 transaction 建立 consistent backup,備份時長時間讀取不會像 MyISAM 無法寫入。另外一種方式是建立 backup 專用的 slave,要備份時可以整台 slave 停掉備份 (還有像是 filesystem snapshot 之類的方式,這邊跳過)。

書上寫 MyISAM 效能比較好...

是的,不過這個前提是「如果你只有讀取」。

MyISAM 讀取效能比較好並不是指 MyISAM query 一次 <1ms 時 InnoDB query 一次就要 100ms 這種程度。兩個都還是在 <1ms,只是當你用到「效率不好的 query」時,MyISAM 在 Table scan 的效能會比 InnoDB 好。

但當網站變大遇到 MyISAM + table scan 時就完蛋了:一個 query 卡 1 秒就代表網站上寫入時遇到這個 query 時最少要卡一秒,InnoDB 反而能救你。(雖然這不是好的方向。好的方向應該是想辦法解決 Table scan 的問題,可能是改 query,也有可能是增加 index 或修改 index)

也因為以上的特性,當使用 InnoDB 時,可以這樣設計:

只對時間敏感 Query 加上 Index

以前用 MyISAM 時為了避免跑報表會造成其他線上服務的 query 卡住,如果用 InnoDB 因為不會卡,報表的 query 沒有 index 而 table scan 也是可以接受的。

有嚴格資料正確性需求的 Query 使用 Transaction

像是金流相關系統,一筆購買紀錄可能要修改好幾個表格。用 MyISAM 時必須對好幾個表格使用 TABLE LOCK (仍然有 atomic 問題),現在可以用 transaction 解決。

資料庫正規化

有可能會因為 MyISAM 卡 query 的問題而設計出非正規化的 schema。用 InnoDB 可能可以正規化,用適當的設備成本 (像是適當使用 JOIN) 降低人力維護成本。

InnoDB 的 Table Lock

InnoDB 設計上允許同時讀寫,在大多數的情況下不會產生 table lock,不過還是有機會。(或是刻意產生)

在「Innodb Table Locks」這篇文章提到 InnoDB 的各種 lock (都是帶過而已,不過當關鍵字去 Google 找應該是夠用了),在文章最後面整理出結論,第一個是:

MySQL Table level locks and Innodb Table Level locks are two separate beings.

而就算是 InnoDB,你也還是可以用 LOCK TABLES,效果的確會如同你想的,只是這並不是由 InnoDB engine 實作。而最後是這樣建議:

It is a good practice not to use LOCK TABLES when you're using Innodb Tables.

另外註解也有提到 auto inc primary key 偶而也會造成問題,都可以當關鍵字去找出細節 :p

Reply to「長野雅廣 (Masahiro Nagano) 的 MySQL Beginners Talk」的 comment :p