Yandex.Mail 從 Oracle 搬移到 PostgreSQL 上的故事

Hacker News Daily 上看到 Yandex.MailOracle 搬到 PostgreSQL 的故事:「Yandex.Mail success story」。

首先是在 Oracle-based 的系統上遇到的問題:

除了技術類的問題外,這個「Not very responsive support」可以看到對 Oracle 的服務很不滿意。

另外下一張投影片只講 shop.oracle.com 是主要原因... 我猜是 Oracle 在開始提供 cloud service 後把售價都拉高。在最後的 Summary 看起來也有點像:

雖然沒有講明換 PostgreSQL 的理由,但注意到「3x more hardware」這點,這表示是原來的四倍。在這樣的情況下還是要換,可以猜測 Oracle 的授權費用在 web-scale 服務上的問題。

另外如果仔細品投影片,可以發現其實 migration 成功的原因是 DBA team 的能力夠強大,以及充足的時間修正問題 (可以看到作者在 mailing list 上一直提問也一直修正問題)。如果當初評估後決定要換到 MySQL,我相信也是會順利完成...

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 的問題,我猜是會有...

MySQL 全系列的安全性漏洞

包含 MySQL 本家與所有從 MySQL 改出去的分支都中了,引用 Percona 的通報:「Percona Server Critical Update CVE-2016-6662」。

This is a CRITICAL update, and the fix mitigates the potential for remote root code execution.

原始的 security advisory 在「CVE-2016-6662 - MySQL Remote Root Code Execution / Privilege Escalation ( 0day )」這邊,雖然是標 0day,但發現的人在七月時就有先通報給 vendor 們讓他們有時間修正:

The vulnerability was reported to Oracle on 29th of July 2016 and triaged by the security team. It was also reported to the other affected vendors including PerconaDB and MariaDB.

Oracle 還沒修正,也就是 upstream 目前仍然是有問題的,目前得靠其他 vendor 修正:

Official patches for the vulnerability are not available at this time for Oracle MySQL server.

其中 Percona 與 MariaDB 都已經先推出修正版本了:

The vulnerabilities were patched by PerconaDB and MariaDB vendors by the end of 30th of August.

然後看了一下這個漏洞,從 SQL 指令可以做檔案操作一路打出來... 可以看到範例:

mysql> set global general_log_file = '/etc/my.cnf';
mysql> set global general_log = on;
mysql> select '
    '> 
    '> ; injected config entry
    '> 
    '> [mysqld]
    '> malloc_lib=/tmp/mysql_exploit_lib.so
    '> 
    '> [separator]
    '> 
    '> ';
1 row in set (0.00 sec)
mysql> set global general_log = off;

這下苦了...

Percona 對 MySQL Index 效用的基本教學

Percona 好像偶而就會整理一篇類似的文章出來...

這次是對 MySQL 上線後,關於 Index 的設計研究:「Basic Housekeeping for MySQL Indexes」。

包括了這幾個主題:

  • Unused indexes
  • Duplicated indexes
  • Potentially missing indexes
  • Multiple column indexes order

這幾點都還蠻基本的,不過這些都做完了之後效能應該不會太差,算是上線後的觀測基本功...

Scylla 1.3

看到 Scylla 正式公告 1.3 版的消息了:「Scylla release: version 1.3」。

Scylla 是用 C++ 重寫 Java 版本的 Cassandra 所有東西 (包括資料結構與 Protocol),目標是做到可以完全相容替換現有 Cassandra Cluster。(號稱可以一台一台移除 Cassandra 的程式,裝上 Scylla 後就可以無痛換過去)

而 Scylla 另外一個重點是效能的提昇,官方宣稱在完整最佳化的情況下是 10x 以上的效能提昇,之前拿 AWS 實測 (沒有完整最佳化) 也可以看到 2x 到 4x 的數字,對於目前的 Cassandra 應用來說極為重要。

1.3 版最重要的功能就是對 Thrift 的支援:

Thrift support. Many Cassandra users are still using Thrift, and they can now continue doing so while benefiting from Scylla’s performance. Built on top of Scylla CQL internal implementation, Scylla Thrift provides similar throughput and latency to Scylla CQL. Users of projects like KairosDB and Titan can now migrate to Scylla while maintaining full protocol compatibility .

本來在 roadmap 上的計畫是用兩個版本支援 Thrift:(從 Google Cache 拉出來的,CSS 看起來有些問題,不過意思有到就好)

剛剛發現 1.4 的 roadmap 已經沒有列 Thrift 了:

這應該是暗示已經實作完了?透過 Thrift 界面跟 Cassandra 溝通的應用程式都可以使用 Scylla 了...

先前在「Facebook Presto · Issue #1139 · scylladb/scylla」這邊跟 ScyllaDB 的人花了不少時間,總算是給出一份 data set 可以讓他們重製 bug,也算是有代價了 XD

Yelp 對 MySQL 更新的資料送到 Kafka 的作法

Apache Kafka 是個 pub-sub 系統:

Apache Kafka is publish-subscribe messaging rethought as a distributed commit log.

Yelp 的人想要將 MySQL 的更新資訊送一份到 Kafka 就可以做很多應用。文章前面介紹了很多原理以及理論,像是講 MySQL 的 replication:

但讀這篇文章發現重點在於他介紹了 GitHub 上的「noplay/python-mysql-replication」這個專案:

Our stream reader is an abstraction over the BinLogStreamReader from the python-mysql-replication package.

這個專案可以解析 MySQL 的 replication protocol:

Pure Python Implementation of MySQL replication protocol build on top of PyMYSQL. This allow you to receive event like insert, update, delete with their datas and raw SQL queries.

馬上就感覺到可以透過這個 library 做不少事情,像是直接接到 worker,再更新 Elasticsearch 上的資料,這樣就是 100% 確保不會漏更新...

Ruby 上使用 DynamoDB 的函式庫:aws-record

AWS 正式發表了在 Ruby 上使用 DynamoDB 的 library:「Announcing General Availability of aws-record」。

GitHub 連結在「aws/aws-sdk-ruby-record」,而 Ruby Gems 的連結在「aws-record」。

這樣用起來更簡單了...

對 NoSQL 分析的大量說明與圖表

Twitter 上看到「NoSQL Databases: a Survey and Decision Guidance」這邊有夠長的,對於還不熟悉目前 NoSQL 常用到的理論技術的人,剛好可以拿來看一看...

對於熟悉的人來說,這些圖表整理的頗不錯:

不過 NoSQL 裡面頗多地雷,大家保持健康的心態用就是了 XDDD

GitHub 發展出來的 ALTER TABLE 方式

GitHub 解釋了他們在 MySQL 上 ALTER TABLE 的方式:「gh-ost: GitHub's online schema migration tool for MySQL」。

GitHub 的舊方式是使用 pt-online-schema-change,會遇到的問題有幾個,其中看起來只有 Non pausability 這個是真正的痛點:

Non pausability: when load on the master turns high, you wish to throttle or suspend your pending migration. However a trigger-based solution cannot truly do so. While it may suspend the row-copy operation, it cannot suspend the triggers. Removal of the triggers results in data loss. Thus, the triggers must keep working throughout the migration. On busy servers, we have seen that even as the online operation throttles, the master is brought down by the load of the triggers.

當開始後,多出來的 trigger 是沒有辦法停下來的 (停下來就代表要全部重來),而且會影響線上服務。

新的方式則是用 replication 做,多一台機器出來跑,等結束後再切換,而中間有任何過程也都很好處理:

這方法手筆比較大,不過對於系統已經有規模的組織來說不是問題... 看起來以後可以朝這個方向研究 XD

看到 zmx 貼了之前的連結,更確信 Uber 的問題不是技術問題了...

Twitter 上看到 zmx 提了一個連結,講 Uber 年初時貼的「How We Built Uber Engineering’s Highest Query per Second Service Using Go」這篇文章的問題:

對照最近的事情還蠻有趣的,尤其是這篇文章後面提到的,酸~爆~了~XDDD:

It is clear to me that the team at Uber under-engineered this problem. Thoughtfully designing this service could trim down the number of nodes by an order of magnitude and save hundreds of thousands of dollars each year. That may sound like pittance to a company valued at more than the GDP of Delaware, but in my eyes that’s the salaries of a few engineers and a few good engineers can go a long way. Maybe even further than the few extra Mercedes-Benz S-Classes they could add to their fleet from the money they could be saving...

先不提政治問題,上面提到的 Quadtree 算是簡單易懂的結構,好久沒看到這個資料結構了: