GitHub 重新定位 Redis 的功能...

GitHub Engineering 說明了他們為什麼改變 Redis 的使用情境:「Moving persistent data out of Redis」。

GitHub 裡面,Redis 有兩種不同的情境,一種叫做 transient Redis,只用做 cache:

We used it as an LRU cache to conveniently store the results of expensive computations over data originally persisted in Git repositories or MySQL. We call this transient Redis.

另外一種則是打開 persistence 功能,叫做 persistent Redis:

We also enabled persistence, which gave us durability guarantees over data that was not stored anywhere else. We used it to store a wide range of values: from sparse data with high read/write ratios, like configuration settings, counters, or quality metrics, to very dynamic information powering core features like spam analysis. We call this persistent Redis.

這邊講的是 persistent Redis 被換成用 MySQL (InnoDB) 儲存:

Recently we made the decision to disable persistence in Redis and stop using it as a source of truth for our data. The main motivations behind this choice were to:

  • Reduce the operational cost of our persistence infrastructure by removing some of its complexity.
  • Take advantage of our expertise operating MySQL.
  • Gain some extra performance, by eliminating the I/O latency during the process of writing big changes on the server state to disk.

For the majority of callsites, we replaced persistent Redis with GitHub::KV, a MySQL key/value store of our own built atop InnoDB, with features like key expiration. We were able to use GitHub::KV almost identically as we used Redis: from trending repositories and users for the explore page, to rate limiting to spammy user detection.

後面講了不少轉換的過程 (還包含了某些功能的改寫),但沒有講的太清楚為什麼不繼續使用 Redis。

目前只能就提到的三點問題來看,persistent 的 i/o 成本可能太高?而且難以再壓榨效能出來?而相反的,InnoDB 已經花了很多力氣在上面,直接拿來用反而可以解決問題?

不過看得出來這個轉換還是花了不少力氣,看得出來有些 application 使用 Redis 的模式不能直接搬到 InnoDB 上,花了時間改寫...

資料庫在 EC2 上選擇 Instance Type 的方向

ScyllaDBCassandra 的 C++ 相容版本,效能比起 Java 版本的好不少 (尤其是與 CPU 與記憶體有關的部份)。

ScyllaDB 的人上個月給了一份指南,主要是在講在 Amazon EC2 上怎麼選 instance type 跑 NoSQL (主要還是針對 ScyllaDB 的情境下分析)。不過道理是通的:「Choosing EC2 instances for NoSQL」。

不同於 Cassandra 比較容易吃到 CPU bound,ScyllaDB 比較容易吃到 i/o bound,所以 i/o 的效能對於選擇 instance type 重要許多。

後面也有提到 instance size 的問題 (八台 xlarge 還是一台 8xlarge),不過感覺沒有給很清楚的方向。一般來說,分散式資料庫之間溝通還是有不少成本在,另外文章裡也提到同一台實體機器的鄰居造成 i/o noise 的問題,看起來在經濟規模夠大的情況下,開到最大台才是王道啊?

Facebook 的 InnoDB patch 讓 table scan 速度變快...

Facebook 的 Database Engineering team 實作了 patch,讓 InnoDB 在 table scan 的速度大幅提昇:「Making full table scan 10x faster in InnoDB」。

第一個 patch 叫做 Logical Readahead。第二個 patch 是針對 async i/o 的改善 (Submitting multiple async I/O requests at once)。

引用文章內的幾段話就知道這幾個 patch 的功力了:

Logical backup size is much smaller. 3x-10x size difference is not uncommon.

備份出來的資料會變小,而且宣稱 1/3 到 1/10 不是罕見情況... -_-

With logical readahead, our full table scan speed improved 9~10 times than before under usual production workloads. Under heavy production workloads, full table scan speed became 15~20 times faster.

然後 table scan 的速度會快非常多... 10 倍?如果是平常就很操的 database 會更明顯?

如果這幾個 patch 如果沒有什麼問題,可以預期會被 merge 到 PerconaMariaDB,至於 Oracle 官方的 source tree... 有的話當然很好,沒有的話也很正常?

關於 Linux 的 Disk I/O 調整...

Twitter 上看到 tka 的 retweet,介紹了 Linux 下 Disk I/O 的調整:「PostgreSQL: Linux kernel I/O tuning」。

文章裡介紹了三種 scheduler,NOOP、CFQ、Deadline,其中 CFQ 是系統預設值。

其實 MySQL 的結論也差不多,Percona 在 2009 年的時候做過 benchmark,就直接看圖講故事吧:「Linux schedulers in tpcc like benchmark」。


數字愈大愈好。

noop 與 deadline 相當接近,對於 i/o bound 的人都應該要調整 :p

AWS 推出高速 I/O 的 EC2 instance

早上就看到 AWS EC2 推出 hi1.4xlarge 的消息:「New High I/O EC2 Instance Type - hi1.4xlarge - 2 TB of SSD-Backed Storage」(官方 blog)、「Expanding The Cloud – High Performance I/O Instances for Amazon EC2」(CTO Werner Vogels 的 blog)。

幾個比較重要的特性:

  • 60.5GB 記憶體
  • 10Gbps 網路
  • 1TB 的 SSD volume 兩個

前面兩個不會太意外,因為需要高速 I/O 的服務通常也都很需要用大量記憶體當作 cache 降低 I/O,也需要大量頻寬提供服務。用 SSD 也在預期的範圍內,不過提供的 SSD 空間居然這麼大...

當然,價位也不便宜,美東就要 USD$3.10/hour,冰島愛爾蘭則是 USD$3.41/hour (目前只有這兩區有提供)。如果以美東一個月 720hours 計算是 USD$2232,約台幣六萬六千多?