Amazon Aurora 可以 clone 了...

Amazon Aurora 可以 clone 複製資料庫了:「Amazon Aurora Introduces Database Cloning Capabilities」。

而且是 COW 架構 (Copy on write),所以複製出來的部份不需要額外付儲存費用,只有修改的部份才要付費,這點相當殺啊:

A cloning operation does not incur any storage charges. You will only be charged for additional storage space if you make data changes.

這對於「測試」這件事情變出不少變化可以用...

官方支援 DynamoDB 的 Auto Scaling 了

DynamoDB 可以透過 console 或是 API 調整 R/W 的 capacity,但一直都沒有全自動的機制這件事情為人詬病頗久。

以前都是自己用 AWS Lambda 或是其他架構判斷調整,現在官方直接提供了:「New – Auto Scaling for Amazon DynamoDB」。

終於啊...

用 Machine Learning 調校資料庫

AWS AI Blog 在月初上放出來的消息:「Tuning Your DBMS Automatically with Machine Learning」。

Carnegie Mellon Database Group 做的研究,除了預設值以外,另外跟四種不同的參數做比較,分別是 OtterTune (也就是這次的研究)、Tuning script (對於不熟資料庫的人,常用的 open source 工具)、DBA 手動調整,以及 RDS

MySQL

PostgreSQL

比較明顯的結論是:

  • Default 值在所有的 case 下都是最差的 (無論是 MySQL 與 PostgreSQL 平台,以及包括 99% 的 Latency 與 QPS,這樣二乘二的四個結果)。而且 Default 跑出來的數字與其他的差距都很明顯。
  • OtterTune 在所有 case 下跑出來都比 Tuning script 的好。這也是合理的結果,本來就是想要取代其他機器跑出來的結果。

至於有些討論 DBA 會失業的事情,我是樂見其成啦... 這些繁瑣的事情可以自動化就想交給自動化吧 XD

MySQL 5.6/5.7/5.8 在 single thread 時的效能比較

作者 Mark Callaghan 在討論 MySQL 在量小的時候,新版可能反而比舊版慢:「The history of low-concurrency performance regressions in MySQL 5.6, 5.7 and 5.8」。

One example of the regression occurs for in-memory sysbench where MySQL 5.7 and MySQL 8 get 60% to 70% of the QPS compared to 5.6, which is the same as writing that 5.6 gets 1.43X to 1.67X more QPS than MySQL 5.7 and MySQL 8.

其實不算太意外,因為功能愈來愈多,而且最佳化的重心都放在用量大的各種情境下。並沒有針對 single thread 時的情境最佳化...

performance_schema 的簡易用法

Mark Callaghan 寫了篇關於 performance_schema 的用法 (很短),讓大家先把這個參數開習慣,雖是入門推廣班:「Short guide on using performance_schema for user & table stats」。

他推薦的兩個資訊是:

select * from table_io_waits_summary_by_table
select * from events_statements_summary_by_account_by_event_name

當使用 5.7+ 時,可以考慮這兩個:

SELECT * FROM sys.schema_table_statistics
SELECT * FROM sys.user_summary

簡單到不行,但卻可以幫不少忙... 很棒的入門推廣班 XDDD

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 應該還可以撐不少量起來。

Amazon Aurora 的論文

AWS 老大介紹自家產品 Amazon Aurora 的論文:「Weekend Reading: Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases.」,論文在「Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases」這邊可以取得。

Amazon Aurora 算是用很特別的架構達到高可靠架構的需求,主要用了一堆已經很強大的底層,像是用 Amazon S3 來交換一堆資料。

不過 AWS 在論文裡的比較的事情其實並不合現實,因為現在的 MySQL 在做分散式架構時的方式其實並不一樣 (i.e. Galera Cluster),論文裡提的很多比較的項目,其實都不是其他方式會遇到的問題,所以就看看就好,畢竟是在推銷自家產品...

ScyllaDB 1.7 支援 Counters 了

在「Scylla release: version 1.7」這邊看到 ScyllaDB 支援 Counters 的消息了 (雖然剛出來,掛著 Experimental 的消息):

Scylla now supports Counters as a native type. A counter column is a column whose value is a 64-bit signed integer and on which two operations are supported: incrementing and decrementing.

這其實是 Cassandra 其中一個強項,針對 counter 這種應用特化的資料型態。

CockroachDB 1.0

CockroachDB 推出 1.0 版:「CockroachDB 1.0 is Production-Ready」。CockroachDB 是希望在分散式環境裡打造出有 ACID 特性的服務,這點類似於 GoogleSpanner 架構。

整個系統主要是用 Go 寫成,支援 PostgreSQL 協定,這讓許多現成的應用可以接上去:

Use existing PostgreSQL client drivers or supported ORMs.

而另外一邊有支援 MySQL 協定的 TiDB (剛好也是用 Go 寫的),整個 NewSQL 領域東西愈來愈多了...

MySQL 8.0 對 4 bytes UTF-8 的效能改善

在「MySQL 8.0: When to use utf8mb3 over utf8mb4?」這邊提到了 MySQLutf8 以及 utf8mb4 的故事,以及在 MySQL 8.0 預期的效能提昇:

可以看到 Oracle 的團隊花了不少力氣提昇 utf8mb4 的效能。另外提到了在 5.7 的時候將 row format 的預設值轉成 DYNAMIC

MySQL 5.7 (2015) added some optimizations such as a variable length sort buffer, and also changed InnoDB’s default row format to DYNAMIC. This allows for indexes on VARCHAR(255) with utf8mb4; something that made migrations more difficult prior.

依照「14.11.3 DYNAMIC and COMPRESSED Row Formats」這邊的敘述,看起來 COMPRESSED 也應該支援一樣的特性,不過不確定... (因為通常不會完整 index 整個 VARCHAR(255),只會 index 某個 prefix length):

The COMPRESSED row format uses similar internal details for off-page storage as the DYNAMIC row format, with additional storage and performance considerations from the table and index data being compressed and using smaller page sizes.