直接接管整個 .io 的網域...

在「The .io Error – Taking Control of All .io Domains With a Targeted Registration」這邊看到的 XDDD

其實就是這樣:

;; AUTHORITY SECTION:
io.         172800  IN  NS  ns-a1.io.
io.         172800  IN  NS  ns-a2.io.
io.         172800  IN  NS  ns-a3.io.
io.         172800  IN  NS  ns-a4.io.
io.         172800  IN  NS  a0.nic.io.
io.         172800  IN  NS  b0.nic.io.
io.         172800  IN  NS  c0.nic.io.

然後他就去註冊 ns-a{1,2,3,4}.io 了 XDDD

這很歡樂 XDDD

(應該可以來掃一下所有的 tld...)

InnoDB redo log 大小對效能的影響

在「Benchmark(et)ing with InnoDB redo log size」這邊看到在討論 InnoDB redo log 的大小對效能的影響 (也就是 innodb_log_file_sizeinnodb_log_files_in_group)。

開頭就有先提到重點,在新版 MySQL 裡,幾乎所有的情況比較大的 redo log 有比較好的效能 (平均值):

tl;dr - conclusions specific to my test

  1. A larger redo log improves throughput
  2. A larger redo log helps more with slower storage than with faster storage because page writeback is more of a bottleneck with slower storage and a larger redo log reduces writeback.
  3. A larger redo log can help more when the working set is cached because there are no stalls from storage reads and storage writes are more likely to be a bottleneck.
  4. InnoDB in MySQL 5.7.17 is much faster than 5.6.35 in all cases except IO-bound + fast SSD

可以看出來平均效能的提昇很顯著,不管是增加 redo log 大小還是升級到 5.7:

但作者也遇到了奇怪的效能問題。雖然平均效能提昇得很顯著,但隨著加入資料的增加,效能的 degradation 其實很嚴重,在原來的網頁上可以看到這些資訊。

The results above show average throughput and that hides a lot of interesting behavior. We expect throughput over time to not suffer from variance -- for both InnoDB and for MyRocks. For many of the results below there is a lot of variance (jitter).

所以也許現階段先加大就好 (至少寫入的效能會提昇),不需要把這個特性當作升級 MySQL 的理由。

eBay 把 MongoDB 當 cache layer 的用法...

在「How eBay’s Shopping Cart used compression techniques to solve network I/O bottlenecks」這邊 eBay 描述了他們怎麼解決在 MongoDB 上遇到的問題,不過我看的是他們怎麼用 MongoDB,而不是這次解決的問題:

It’s easier to think of the MongoDB layer as a “cache” and the Oracle store as the persistent copy. If there’s a cache miss (that is, missing data in MongoDB), the services fall back to recover the data from Oracle and make further downstream calls to recompute the cart.

把 MongoDB 當作 cache layer,當 cache miss 的時候還是會回去底層的 Oracle 撈資料計算,這用法頗有趣的...

不拿 memcached 出來用的原因不知道是為什麼,是要找個有 HA 方案的 cache layer 嗎?還是有針對 JSON document 做判斷操作?

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,約台幣六萬六千多?