幹壞事是進步最大的原動力
這兩篇剛好一起看，Amazon RDS 支援了 ARM 架構的 t4g 與 x2g：「Amazon RDS now supports X2g instances for MySQL, MariaDB, and PostgreSQL databases.」與「Amazon RDS now supports T4g instances for MySQL, MariaDB, and PostgreSQL databases.」。
目前主要是關注 t4g，因為目前量的關係反而是大量使用 t4g 類的機器，如果上面的 PostgreSQL 可以跑 t4g 的話，看起來只要沒有買 RI 的可以換過去，主要是比 t3 再省一些錢：以新加坡區的 PostgreSQL 來說，db.t4g.micro 目前是 $0.025/hr，而 db.t3.micro 則是 $0.028/hr，差不多是九折。
沒意外的話效能應該也會提昇一些，不過用 t 系列的機器本來就沒有太大的量在上面跑，這點應該是還好...
Let's Encrypt 升級了 MariaDB 資料庫的伺服器 (跑 InnoDB)，特地寫了一篇文章出來講：「The Next Gen Database Servers Powering Let's Encrypt」。
CPU 的部份從本來的 2x Intel Xeon E5-2650 (Total 24 cores / 48 threads) 換成了 2x AMD EPYC 7542 (Total 64 cores / 128 threads)，這點在本來就是 CPU 滿載的情境下改善很大：
而本來的瓶頸一解決，也使得 API 的 latency 直接降下去：
回頭看一下架構，可以看到他們提到沒有使用分散式的資料庫，而是單台 database 硬撐，驗證了即使到了 Let's Encrypt 這種規模，以暴制暴還是很有效的：
We run the CA against a single database in order to minimize complexity. Minimizing complexity is good for security, reliability, and reducing maintenance burden. We have a number of replicas of the database active at any given time, and we direct some read operations to replica database servers to reduce load on the primary.
除了 CPU 暴力外，2TB RAM 與 24 顆 NVMe SSD 的搞法也是很讚的，擺明就是用記憶體拼 cache 的量，以及用大量的 NVMe SSD 疊 IOPS。
然後硬體還在成長，看起來暴力解應該會變成以後的基本答案了...
在 Percona 的「Generating Numeric Sequences in MySQL」這篇在討論產生字串序列，主要是在 MySQL 環境下，裡面看到的技巧「Session Variable Increment Within a SELECT」這組，剛好可以用在要在每個 row 裡面增加名次：
SELECT (@val := @val + 1) - 1 AS value FROM t1, (SELECT @val := 0) AS tt;
另外看到 MariaDB 與 MySQL 8.0 系列因為有多支援各種功能，剛好也可以被拿來用，然後最後也提到了 Percona 自家出的 MySQL 8.0.20-11 將會直接有 SEQUENCE_TABLE() 可以用 (這應該才是 Percona 這篇文章的主要目的，推銷一下自家產品的新功能)。
文章收起來之後遇到可以拿出來參考用...
看起來應該是找 Percona 的人幫忙轉移到 MyRocks 上，然後整理出來的成功案例：「The Road Story of a MyRocks/MariaDB Migration」。
看起來是跑在獨立機器上，而不是雲端的虛擬機上，所以不是想 scale up 就可以把硬體規格拉上去 (說不定記憶體插槽已經滿了之類的...)：
Replicas run on bare metal servers, usually Dual Xeon E5 v3 or v4, with 192 GB to 384 GB of RAM.
這次遇到的主要的問題是發現效能跟不上。另外在文章裡面沒寫到，但可以猜到的是，他們目前不打算改架構，而是想要藉由改善資料庫的效能來解決問題：
The servers were close to their limits and were slow to catch up with replication after a maintenance period
後面可以看到不少過程，主要是重新編一份 MariaDB，讓 MyRocks 支援 Zstandard (MyRocks 支援 Zstandard，不過 MariaDB 內的 MyRocks 不知道為什麼關掉了...)，這點大幅降低了空間的佔用。
另外是遇到 OOM 問題，在改用 jemalloc 解決記憶體用量的問題後就解決了 (這個在使用 InnoDB 的時候也算是標配了)。
不過在「Increased Read Load Over Time」那段還是看到了 workaround：
The read load was still rising a bit but at a much smaller pace. Instead of hours, it was days. That’s kind of expected given the workload and we were already planning for periodic manual compactions.
目前看起來 MyRocks 的強項主要是在省資源，但缺點就是有不少眉眉角角得小心處理。這樣的話，一般應該還是會先用 InnoDB，真的搞大了再考慮要不要換過去...
Percona 對 MariaDB 在 10.5 (目前的最新穩定版) 裡出的 S3 Engine 給出了簡單的測試報告：「MariaDB S3 Engine: Implementation and Benchmarking」。
這個 engine 顧名思義就是把資料丟到 Amazon S3 上，目前是 alpha 版本，預設是不會載入的，需要開 alpha flag 才能用：
The S3 engine is READ_ONLY so you can’t perform any write operations ( INSERT/UPDATE/DELETE ), but you can change the table structure.
另外這是從 Aria 改出來的 read-only engine，而 Aria 是從 MyISAM 改出來的：
The S3 storage engine is based on the Aria code and the main feature is that you can directly move your table from a local device to S3 using ALTER.
測出來發現在 read-only 的情境下，COUNT(*) 超快，看起來就是跟 MyISAM 體系有關，直接撈 MyISAM 內的資料，所以本地要 18 秒，但放到 S3 反而秒殺 XDDD
整體看起來還不錯？算是一種 Data warehouse 的方案，主要是要用到 row-based format 儲存的優點，遇到一些冷資料可以這樣玩。
從「Using the S3 Storage Engine」這邊的設定方式看到 s3_host_name，看起來有機會接其他家的 S3 API，或是本地的 Storage。
話說 Aria 這個引擎當初最主要的重點就在 crash-safe，在有了 crash-safe 之後，DRBD 這種 block-level replication 機制就可以硬幹上去，後來主力就在擴充其他型態了，像是 GIS 與 virtual column 的功能，不過這些功能本家在 InnoDB 上好像也都陸陸續續跟上來了，單純的 Aria engine 好像還好...
在 MariaDB 的「MyISAM and KPTI – Performance Implications From The Meltdown Fix」這篇看到頗驚人的數字，這篇提到了他們收到回報 (回報的 ticket 可以參考「[MDEV-15072] Massive performance impact after PTI fix - JIRA」)，說 KPTI (Meltdown Mitigation) 對 MyISAM 效能影響巨大：
Recently we had a report from a user who had seen a stunning 90% performance regression after upgrading his server to a Linux kernel with KPTI (kernel page-table isolation – a remedy for the Meltdown vulnerability).
他們發現 90% 是因為 VMware 舊版本無法使用 CPU feature 加速，在新版應該可以改善不少。但即使如此，文章內還是在實體機器上看到了 40% 的效能損失：
A big deal of those 90% was caused by running in an old version of VMware which doesn’t pass the PCID and INVPCID capabilities of the CPU to the guest. But I could reproduce a regression around 40% even on bare metal.
然後後面就在推銷 MariaDB 的 Aria Storage Engine 了，不是那麼重要... 不過知道 MyISAM 在 KPTI 下這麼傷還蠻重要的，因為接下來五年應該都還是愈的到 KPTI，應該還是有人在用 MyISAM...
Amazon RDS 的升級：「Amazon RDS Now Supports Database Storage Size up to 16TB and Faster Scaling for MySQL, MariaDB, Oracle, and PostgreSQL Engines」。
空間上限從 6TB 變成 16TB，而且可以無痛升。另外 IOPS 上限從 30K 變成 40K：
Starting today, you can create Amazon RDS database instances for MySQL, MariaDB, Oracle, and PostgreSQL database engines with up to 16TB of storage. Existing database instances can also be scaled up to 16TB storage without any downtime.
The new storage limit is an increase from 6TB and is supported for Provisioned IOPS and General Purpose SSD storage types. You can also provision up to 40,000 IOPS for Provisioned IOPS storage volumes, an increase from 30,000 IOPS.
不過隔壁的 Amazon Aurora 還是大很多啊 (64TB)，而且實際上不用管劃多大，他會自己長大：
Q: What are the minimum and maximum storage limits of an Amazon Aurora database?
The minimum storage is 10GB. Based on your database usage, your Amazon Aurora storage will automatically grow, up to 64 TB, in 10GB increments with no impact to database performance. There is no need to provision storage in advance.
這個大家等好久了，尤其 MySQL 常遇到需要用記憶體換效能的情境：「Amazon RDS for MySQL and MariaDB Supports R4, T2 and M4 Instance Types」。
先前 t2 最大只能開到 t2.large (8GB RAM)，對於需要大量記憶體運算的 SQL query，就有機會被 MySQL 使用 filesort 寫到硬碟裡面暫存了。這次支援這些 instance type，開發環境至少有選擇可以開到 t2.2xlarge (32GB RAM) 跟他拼。
而 r4 應該是正式環境期待已久的 instance type 了。r3 最大是 r3.8xlarge (244GB)，跟 r4 最大的 r4.16xlarge (488GB) 剛好差了一倍。
m4 就比較微妙了，順便補上去的感覺... 不過應該還是會有應用會剛好用到。
不過還是期待前陣子出來的 c5，對於寫出很驚人的 SQL query，在 MySQL 內跑大量運算的應用會有幫助，就繼續等吧... :o
Percona 的人花了些時間整理 MySQL 5.7 與 MariaDB 10.2 在預設值上的差異：「MySQL and MariaDB Default Configuration Differences」。
整體可以感覺到 MariaDB 10.2 相較於 MySQL 5.7 還是頗偏 MyISAM 的設計，可能跟 Monty (Michael Widenius) 的偏好有關吧... 不過技術面上來說，MariaDB 10.2 是基於 5.5 分支出來一路改出來的，當時的 InnoDB 跟現在的版本比起來的確沒那麼強...
不過這畢竟只是預設值，看過留個印象就好...