InnoDB 的 isolation mode

Percona 老大 Peter Zaitsev 寫了一篇關於 InnoDB 的 isolation mode 與效能的關係:「MySQL performance implications of InnoDB isolation modes」。

關於 isolation level 的介紹,也可以參考維基百科上的說明:「Isolation (database systems)」。

其中有個我也認同的的建議:

In general I think good practice is to use READ COMITTED isolation mode as default and change to REPEATABLE READ for those applications or transactions which require it.

需要 REPEATABLE READ 需求的 transaction 可以在 session 裡面開,不需要平常就開著。

而剛從 MyISAM 轉過去的因為本來就沒有 transaction,換到 InnoDB 時強烈建議就直接設上去 (剛好在註解也有提到):

I think READ-COMMITTED is better default yet it can break some applications. Though so changing to default storage engine from MyISAM to Innodb did.

DigitalOcean 支援 FreeBSD

DigitalOcean 宣佈支援 FreeBSD:「Presenting FreeBSD! How We Made It Happen.」。

不過不是全部的 region 都支援,由於 NYC1、NYC2 與 AMS1 這三個地區的架構比較舊,除了這三個以外的地區都支援 FreeBSD。

文章裡有說明技術上的架構,除了 infrastructure 的支援以外,另外也受益於 bsd-cloudinit

不過自從 FreeBSD 換到 Bugzilla 後,我就把 ports maintainership 都轉移出去,再加上桌機與跳板機都改用 Ubuntu,用 FreeBSD 的情況愈來愈少了...

Amazon DynamoDB 筆記

Amazon DynamoDB 頁面上的介紹:

Amazon DynamoDB is a fast and flexible NoSQL database service for all applications that need consistent, single-digit millisecond latency at any scale.

資料型態的部份就跳過去了,這篇筆記的重點在於 index 的部份 (了解他如何 scale),尤其是對 RDBMS 有了解的人要如何從他所設計的架構理解 DynamoDB 的 index。

理論基礎是 Amazon 在 2007 年丟出的論文「Dynamo: Amazon’s Highly Available Key-value Store」,這篇論文影響了很多 open source project。

DynamoDB 的 index 有 Primary Key、Local Secondary Index Key (LSI) 以及 Global Index Key (GSI),在「DynamoDB Data Model」這篇有介紹。

這邊會拿 Blogger.com 這種多人的 Blog Hosting 當例子:

  • 一個 user 可以有很多 blog。(table user)
  • 一個 blog 可以有很多 post。(table blog)
  • 一篇 post 可以有很多 comment。(table post)

接下來就從 Primary Key 開始講。

Primary Key

Primary Key 保證唯一,這也是 DynamoDB 裡面可以達到 RDBMS 的 UNIQUE KEY 效果的最佳方式。

有兩種 Primary Key 的型態,一種叫做 Hash,另外一種叫做 Hash-Range。

兩種都需要指定某一個欄位是 Hash-based column,當作切割 (partition) 的依據。

第一種:Hash

以 table user 來說,可以拿 user_id 來當作 Hash-based column,裡面有 blog_id 的 list。

以 table blog 來說,可以拿 blog_id 來當作 Hash-based column,裡面有 post_id 的 list。

要注意的是,如果表格 PK 是 Hash,那麼就不能使用 LSI 與 GSI 了。只有另外一種型態 (Hash-Range) 才可以用 LSI 與 GSI。

相對的,Hash-based 的表格因為功能有限,效率通常很好 XDDD

第二種:Hash-Range

其實 Hash-Range 是一種別的 LSI,兩者最大的差異就是唯一性了。

另外一種 Primary Key 是 Hash-Range,他需要指定兩個欄位,其中其中 Hash 的欄位就如同上面的解釋,當作資料切割的依據。這邊的唯一性是指 (Hash column, Range column) 唯一,而非只有 Hash 唯一或是 Range 唯一。

剛剛說到需要指定的另外一個欄位,被稱為「Range」的原因是因為他可以有效率的以 hash + range query 查詢資料。

以 table post 來說,可以拿 blog_id 當作 Hash-based column,再拿 post_id 當作 Range-based column,等下我們介紹 LSI 時再拿發表時間欄位排序。

同理,table comment 可以拿 (post_id, commend_id) 當 PK。

Query

PK 是 Hash 的當然就是指定 Hash-based column 直接查,條件只能是等號。

PK 是 Hash-Range 的除了可以用 Hash-based column 直接查 (還是只能用等號),另外可以用 Hash-based column + Range-based column 查。

以 SQL 的想法就像是 WHERE hash_col = 123 AND range_col BETWEEN (123, 456) 的感覺。反正 Hash-based column 一定要等號。

講到這邊,其實讀過上面提到的 Amazon 那篇論文應該就大概有感覺架構是怎麼搞的了:(這是推敲出來的,未必是實際架構)

  • 用 Hash-based column 切 consistent hash ring 塞到不同機器上。PK 是 Hash 的到這邊就搞定了。
  • PK 是 Hash-Range 的,還是照上面一條提到的,用 Hash-based column 切開,所以同樣的 Hash-based column 的資料都會塞到同一台機器上,於是就可以用有效率的 ordered tree 來存放 Range-based column 的資料,這樣就可以提供 query 了。

當然,考慮到需要實做 rebalance 機制以逐步擴充,這邊 consistent hash ring 的部份的作法可以更細膩,不過就不是這篇要談的重點了。

接下來要講重頭戲 LSI 與 GSI 了。

Local Secondary Index (LSI) 與 Global Secondary Index (GSI)

前面有提到 LSI 與 GSI 必須 PK 是 Hash-Range 的情況下能用,兩者都不強制唯一性。

LSI 與 GSI 都是 (Hash-column based, Range-column based) 的形式,差別在 LSI 的 Hash-column based column 必須跟 PK 的相同,GSI 的可以不用一樣。

所以對於 table post 可以加一個 LSI (blog_id, post_datetime),就可以用 WHERE blog_id = 123 ORDER BY post_datetime DESC 拉出對應的文章了。

同理,table comment 是 (post_id, comment_datetime)。

用鍵盤翻頁 (Navigation Shortcuts)

Google Chrome 上裝了「Navigation Shortcuts」:

快速鍵包含這些:

  • Space Bar - navigates to the next page when scrolled to the bottom
  • Shift + Space Bar - navigates to the previous page when scrolled to the top
  • Ctrl + Right - navigates to the next page
  • Ctrl + Left - navigates to the previous page
  • Ctrl + Up - navigates to section's index page
  • Ctrl + Shift + Up - navigates to the top page

其實讀的就是 HTML header 裡面的 rel tag。拿來讀 AWS 的文件還蠻方便的...

Redshift 的 2*dw2.8xlarge 與 32*dw2.large 的比較

這邊的 Amazon Redshift 都是跑在 Oregon (us-west-2),前者的價錢是 USD$9.6/hour,後者是 USD$8/hour,大約貴一些。這是同一個 query 跑過多次後穩定的數字,用 PostgreSQL\timing 出來的數字計算。

先從比較簡單的 query 開始,這個表格大約六億筆資料,如果以記憶體大小算的話,是 memory-fit。

前者是:

dev=# SELECT COUNT(DISTINCT x) FROM t;
 count  
--------
 925612
(1 row)

Time: 3345.946 ms

後者是:

dev=# SELECT COUNT(DISTINCT x) FROM t;
 count  
--------
 925612
(1 row)

Time: 2145.132 ms

再來條件多一點,一樣前者是:

dev=# SELECT x, COUNT(*) AS cnt FROM t GROUP BY x ORDER BY cnt DESC LIMIT 20;
...
(20 rows)

Time: 2121.002 ms

後者是:

dev=# SELECT x, COUNT(*) AS cnt FROM t GROUP BY x ORDER BY cnt DESC LIMIT 20;
...
(20 rows)

Time: 1388.102 ms

發現比較貴的 cluster 的反而比較慢 (大台 dw2.8xlarge 組成的),用多台小台的去堆反而比較快。晚點找時間測沒辦法 memory-fit 的速度。

意外的跟直覺不太一樣,要測過才知道...

Amazon EC2 的 C4 Instance

這時候就要拿出經典台詞:

Anyway,Amazon EC2 推出 C4 Instance 了:「Now Available – New C4 Instances」。

來看看 c4.8xlarge,最近說不定用的上,不過要注意的是,C4 Instance 只支援 EBS only。

c4.8xlarge 的 ECU 是 132 (USD$1.856/hour) 而 c3.8xlarge 是 108 (USD$1.68/hour),跟 C3 相比,看起來更實惠一些。

用 Docker 測試 Mesos

照著「Deploy a Mesos Cluster with 7 Commands Using Docker」上面的方法做,遇到一些小狀況,解決後總算是搞定了。

文章作者的目的是利用 Docker 在不弄髒環境下讓人很容易上手測試,不需要處理一堆 Java 以及設定檔的問題。讓沒有用過的人可以感受一下 MesosMarathon 的界面與操作。

總共會跑起四個 docker instance,分別是 ZooKeeper、Mesos Master、Marathon、Mesos Slave Container。

我遇到的問題是我在 Ubuntu 上面的 UFW 設為 default deny,造成這四隻程式之間溝通不良,最後是針對 docker0 這個 interface 放行:

# ufw allow in on docker0

有些感覺之後就可以看官網看更進階的功能操作。

安全的 SSH (Secure Secure Shell)

Twitter 上看到「Secure Secure Shell」這篇文章,介紹要如何加強 OpenSSH

文章裡分成四個部份討論,從 Key exchange 開始,Authentication、Symmetric ciphers 以及 Message authentication codes。

先把已知有問題的技術都先拿掉 (像是 MD5RC4DES),然後有被 NSA 影響到的技術,而且有不錯的替代方案的也拿掉。

另外還介紹了 Tor hidden service 下的保護。

感覺有點偏激的文件,可以拿來參考...

Amazon EC2 Spot Instance 的關機通知

AWS 改善了 EC2 Spot Instance 的關機通知,在決定 terminate 前兩分鐘 instance 可以得知消息,讓 instance 可以處理「後事」,像是將計算的資料寫回 EBS 或是 S3:「New – EC2 Spot Instance Termination Notices」。

Today we are improving the reclamation process with the addition of a two-minute warning, formally known as a Spot Instance Termination Notice.

不過目前不是 trigger,而是透過 polling 的方式提供:

The Termination Notice is accessible to code running on the instance via the instance’s metadata at http://169.254.169.254/latest/meta-data/spot/termination-time. This field will become available when the instance has been marked for termination (step 3, above), and will contain the time when a shutdown signal will be sent to the instance’s operating system.

建議的 polling 時間是五秒鐘一次:

We recommend that interested applications poll for the termination notice at five-second intervals.

至少有方法得知了...