Home » Posts tagged "rds" (Page 3)

Amazon Aurora (MySQL) 推出的 Asynchronous Key Prefetch

Amazon Aurora (MySQL) 推出新的效能改善,可以改善 JOIN 時的效能:「Amazon Aurora (MySQL) Speeds Join Queries by More than 10x with Asynchronous Key Prefetch」。

看起來像是某個情況的 optimization,將可能的 random access 換成 sequential access 而得到大量的效能:

This feature applies to queries that require use of the Batched Key Access (BKA) join algorithm and Multi-Range Read (MRR) optimization, and improves performance when the underlying data set is not in the main memory buffer pool or query cache.

其實記憶體還是最好用的加速器,能加大硬拼就先硬拼... XD

Amazon Aurora 也支援 PostgreSQL 了

AWS 宣佈 Amazon Aurora 也支援 PostgreSQL 了,相容於 9.6.3 的版本 (應該就是改自這個版本):「Now Available – Amazon Aurora with PostgreSQL Compatibility」。


On the performance side, you can expect up to 3x the throughput that you’d get if you ran PostgreSQL on your own (you can read Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases to learn more about how we did this).

架構上也是採用 6-way replication 的方式:

It is compatible with PostgreSQL 9.6.3 and scales automatically to support up to 64 TB of storage, with 6-way replication behind the scenes to improve performance and availability.


You can use Amazon Aurora with PostgreSQL Compatibility today in the US East (Northern Virginia), EU (Ireland), US West (Oregon), and US East (Ohio) Regions, with others to follow as soon as possible.

Amazon RDS 的 RI 也支援彈性計價了

AWS 宣佈 RDS 的 RI 也支援彈性計價了:「Amazon RDS Reserved Instances Offer Instance Size Flexibility」。

也就是說跟 EC2 的 RI 方式切齊,買 db.m4.2xlarge 的 RI 後,可以用在兩台 db.m4.xlarge 上:

For example, let’s say you purchased a db.m4.2xlarge MySQL RI in US East (N. Virginia). The discounted rate of this RI can automatically apply to 2 db.m4.xlarge MySQL instances without you needing to do anything.

包括了相當多種類的 RDS,主要是沒有 license fee 的類型都包括在內了:

Amazon RDS Reserved Instance size flexibility is offered in all regions for the MySQL, MariaDB, PostgreSQL, and Amazon Aurora database engines, as well as the “bring your own license” (BYOL) edition of the Oracle database engine. To learn more about flexible RIs, please visit the Amazon RDS Reserved Instances Page.

但不包括要另外收 license fee 的 SQL Server 與 Oracle LI edition:

Size flexibility does not apply to Microsoft SQL Server and the License Included (LI) edition of Oracle.

Heimdall Data:自動 Cache RDBMS 資料增加效能

看到 AWS 的「Automating SQL Caching for Amazon ElastiCache and Amazon RDS」這篇裡面介紹了 Heimdall Data – SQL caching and performance optimization 這個產品。

從官網的介紹也可以看出來是另外疊一層 proxy,但自動幫你處理 cache invalidation 的問題:

But what makes Heimdall Data unique in industry is its auto-cache AND auto-invalidation capability. Our machine learning algorithms determine what queries to cache while invalidating to ensure maximum performance and data integrity.

看起來支援了四個蠻常見的 RDBMS:

Heimdall Data supports most all relational database (e.g. MySQL, Postgres, Amazon RDS, Oracle, SQL Server, MariaDB).

看起來是一個花錢直接買效能的方案... 不過 cache invalidation 的部分不知道要怎麼跨機器做,在 FAQ 沒看到 cluster 情況下會怎麼解決。

Amazon Aurora 支援快速複製

Amazon Aurora 宣佈支援快速複製:「Amazon Aurora Fast Database Cloning」。

對於 2TB 的資料大約五分鐘就完成了:

This means my 2TB snapshot restore job that used to take an hour is now ready in about 5 minutes – and most of that time is spent provisioning a new RDS instance.

主要是得力於後端 storage 的部份可以實做 copy-on-write 架構:

By taking advantage of Aurora’s underlying distributed storage engine you’re able to quickly and cheaply create a copy-on-write clone of your database.

可以快速複製就可以很快的驗證一些事情,像是可以直接測試 ALTER TABLE 需要的時間,或是事前演練...

小台機器上的 innodb_purge_threads 對效能的影響

雖然「MyISAM, small servers and sysbench at low concurrency」這篇標題是在講 MySQL 上的 MyISAM,但還是有提到一些 InnoDB 的東西...

其中提到了 innodb_purge_threads 對效能的影響:

the default value for innodb_purge_threads, which is 4, can cause too much mutex contention and a loss in QPS on small servers. For sysbench update-only I lose 25% of updates/second with 5.7.17 and 15% with 8.0.1 when going from innodb_purge_threads=1 to =4.

當機器不大的時候,innodb_purge_threads 對於效能帶來的影響其實頗大的?

另外從作者最近的一系列測試看起來,5.7 在小機器的效能比 5.6 差不少... 這點在考慮 RDS 的時候也許要注意 (因為 t2.* 應該不算大 XD)。

用 Machine Learning 調校資料庫

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

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




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

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