大型 WordPress 站台會用到的 LudicrousDB (以及 HyperDB)

最近收到 HyperDB 的 mailing list 信件 (開頭是「[HyperDB] How can I set up HyperDB with latest version.」這封),有人提到 HyperDB 很久沒更新了... 結果在信理看到有人回了「stuttter/ludicrousdb」這個專案:

LudicrousDB is an advanced database interface for WordPress that supports replication, failover, load balancing, & partitioning

兩個專案都是抽換掉 WordPress 在處理 database 的 library,然後希望自己控制 master/slave 的讀寫分離以及各機房之間的處理 (還有 replication lag),而不要靠 ProxySQL 這類工具來做 (以時間來看,當初他們發展這些工具時,ProxySQL 這類的方案也還不夠成熟,大家都不會想要選這個方向...)。

先記錄下來,如果之後有遇到時可以當作是一個選項...

MySQL 總算要拔掉 mysql_query_cache 了

半官方的 MySQL blog 上宣佈了拔掉 mysql_query_cache 的計畫:「MySQL 8.0: Retiring Support for the Query Cache」。

作者開頭引用了 ProxySQL 的人對 MySQL Query Cache 的說明:

Although MySQL Query Cache was meant to improve performance, it has serious scalability issues and it can easily become a severe bottleneck.

主要問題在於 MySQL Query Cache 在多 CPU 環境下很難 scale,很容易造成一堆 thread 在搶 lock。而且作者也同意 ProxySQL 的說法,將 cache 放到 client 的效能比較好:

We also agree with Rene’s conclusion, that caching provides the greatest benefit when it is moved closer to the client:

可以看到 Query Cache 在複雜的環境下對效能極傷。而之前也提到過類似的事情了:「Percona 對 mysql_query_cache 的測試 (以 Magento 為例)」、「關閉 MySQL 的 Query Cache」。

一般如果要 cache 的話,透過 InnoDB 裡良好的 index 應該還可以撐不少量起來。

Stripe 的 Increment 雜誌

Stripe 推出了 Increment 雜誌,講團隊合作時的各種議題:「Introducing Increment」。

And so we've decided to start Increment, a software engineering magazine dedicated to providing practical and useful insight into what effective teams are doing so that the rest of us can learn from them more quickly.

雜誌網站上也有類似的描述:

A digital magazine about how teams build and operate software systems at scale.

Increment is dedicated to covering how teams build and operate software systems at scale, one issue at a time.

可以看一看 Stripe 對團隊合作的想法...

Amazon Aurora 支援 Reader Endpoint

Amazon Aurora 支援 Reader Endpoint,讓讀的部份可以打散掉:「New Reader Endpoint for Amazon Aurora – Load Balancing & Higher Availability」。

讀的部份比較容易 scale (常見的方式是透過 replication 做到),而現在很多 database framework (包括各類的 ORM framework) 都支援讀寫分離,這個支援對於系統的 scale 來說幫忙頗大。

不過不知道會不會有 replication lag 的問題,我猜是會有...

Netflix 評估影片品質的方法

Netflix 在發了一篇很長的文章,說明怎麼評估 video quality:「Toward A Practical Perceptual Video Quality Metric」,文章雖然有點長,但其實還蠻好懂的...

講的白話一點,Netflix 想要做各種壓縮方式的改善,但在超大的量的情況下 (scale) 缺乏自動化打分數的機制:

All of the challenging work described above hinges on one fundamental premise: that we can accurately and efficiently measure the perceptual quality of a video stream at scale.

如果先不考慮 scale 問題,影片的評估方式有人工處理以及常見的計算方法 (像是 MSEPSNRSSIM):

Traditionally, in video codec development and research, two methods have been extensively used to evaluate video quality: 1) Visual subjective testing and 2) Calculation of simple metrics such as PSNR, or more recently, SSIM.

前者因為牽涉到人工,所以不 scale,而後者跟「人的觀感」還是不夠正相關:

Without doubt, manual visual inspection is operationally and economically infeasible for the throughput of our production, A/B test monitoring and encoding research experiments.

Although researchers and engineers in the field are well-aware that PSNR does not consistently reflect human perception, it remains the de facto standard for codec comparisons and codec standardization work.

Netflix 的作法其實很簡單:(但是每一步都很仔細)

  • 首先先把影片依照手上有的 metadata 歸類,然後再挑出代表性的剪輯,並且產生不同 bitrate 的檔案。
  • 用人工對這些剪輯評分。
  • 用機器產生各種既有計算方法的分數 (PSNR、SSIM、...)。
  • 用數學方法把人工的與機器算的分數建立 model。
  • 然後對於未知的影片先寄算出既有方法的分數 (PSNR、SSIM、...),然後套用 model 推估人的觀感。

沒什麼特別發明出來的演算法,只是苦工 XDDD

Firefox 支援 OCSP Must-Staple

Firefox 宣佈支援 OCSP Must-Staple:「Improving Revocation: OCSP Must-Staple and Short-lived Certificates」。

先前的 SSL certificate 的 revoke 技術目前是透過 CRLOCSP 兩個技術在支撐,前者是列出所有被 revoke 的清單,後者則是瀏覽器主動去指定的 server 確認這個 SSL certificate 是否有效。但這兩個方法都有嚴重的問題。

CRL 的問題是 revoke 清單會愈來愈多。這完全沒辦法 scale。

OCSP 的問題有幾個,一個是熱門網站的 SSL certificate 會讓 OCSP server 的負擔非常重 (不過還是有些辦法打散)。第二個問題是 OCSP server 會知道哪些 IP 造訪了哪些網站,使得隱私權受到嚴重侵害。第三個問題則是 client 需要再連線確認花掉很多時間,而且失敗機率超高:

However, these checks can be slow and unreliable. They time out about 15% of the time, and take about 350ms even when they succeed.

也因為極度不穩定,對於一般的 SSL certificate 在連不到 OCSP server 時,沒有瀏覽器敢直接 hard-fail (EV SSL certificate 是強制要求 OCSP 要過),於是反而給了攻擊者一個很簡單的方法:取得 private key 攻擊時順便擋掉對 OCSP server 的連線。

後來 OCSP 技術改善而推出 OCSP stapling,由 server 定時去 OCSP server 取得「這個 SSL certificate 未被 revoke」的簽名認證後,一起在 TLS connection 裡傳輸給 client 端,這樣有許多好處:

  • 隱私問題直接解決了,因為 server 是固定時間去抓,OCSP server 完全不知道使用者端的資訊 (甚至連「有沒有來連線」都不知道)。
  • 穩定性提昇了,因為 OCSP server 的負荷量變低,可以預期 OCSP server 會變得比較容易 scale。
  • 用戶端的速度增加了,因為 client 不需要額外的連線確認。

而這次 Firefox 更進一步支援讓 SSL certificate 上標注 OCSP Must-Staple,表示這個 certificate 必須有 OCSP stapling 才行,這使得這類 SSL certificate 在 revoke 後無法被利用,真正的完全失效。

不知道其他家會不會跟進...

Netflix 不僅使用 AWS,還使用了 GCE...

在「Cloud guru Adrian Cockcroft on Netflix, Amazon, Google, and DigitalOcean」這篇裡面提到 Netflix 現在不僅使用 AWS,還使用了 GCE

The company’s services are now all hosted in the public cloud, but not just in AWS. Netflix is also using Google Compute Engine.

不算是很意外... 畢竟有那個 scale 與實力。

WebScaleSQL

WebScaleSQLFacebookGoogleLinkedIn 以及 Twitter 四家公司對 MySQL 5.6 的 fork。

Percona 的人也針對 WebScaleSQL 與 Percona Server 5.6 的比較,寫了一篇技術分析的文章:「A technical WebScaleSQL review and comparison with Percona Server」。

Percona 那篇分析文章提到不少改善屬於比較激進類型,對於 Percona Server 以及 MySQL 官方版本的定位並不適合。

而在開發上,語法也換到 C99C++11,也就是打算拋棄很舊的系統 (沒有 C99/C++11 compiler)。不過就這點來說,使得這上面的 patch 要 backport 回 MySQL 又增加了一些狀況...

WebScaleSQL 的出現代表 MySQL fork 又多一家,而且因為背後是這四家公司搞出來的,看起來聲勢會很浩大。進入「合久必分」的階段...

Facebook 發展的 RocksDB...

Facebook 利用 Google 所發展的 LevelDB 開發了 RocksDB,跟 LevelDB 相同,仍然是 persistent key-value store,重點在於能夠使用多個 CPU 增加效能的能力:

RocksDB builds on LevelDB to be scalable to run on servers with many CPU cores, to efficiently use fast storage, to support IO-bound, in-memory and write-once workloads, and to be flexible to allow for innovation.

Performance Benchmarks 這邊可以看到效能的數據,主要都是跟 LevelDB 比較。比較的時候不只是寫了快了多少,而是包含原理都有寫出來。

source code 在 GitHub 上可以翻到:facebook/rocksdb,除了 source code 外,還發現裡面有 PATENTS 這個檔案,裡面針對專利的部份給予豁免... 好像很少看到?

Jeremy Cole 在 XLDB 2013 上的演講:「The MySQL Ecosystem at Scale」

GoogleJeremy ColeXLDB 2013 (Extremely Large Databases) 上的演講投影片:「The MySQL Ecosystem at Scale」(PDF)。

投影片內對於 MySQL 的歷史以及現況的說明的很清楚,另外就是 sharding 那塊的方式很值得看一看,量大之後大家解決的方法都差不多,算是已經被證實可行的方法了。