Percona 對 MongoDB 的建議

看到「5 Things DBAs Should Know Before Deploying MongoDB」這篇,裡面給了五個建議,其中第五點頗有趣:

5) Whenever Possible, Working Set < RAM

As with any database, fitting your data into RAM will allow for faster reads than from disk. MongoDB is no different. Knowing how much data MongoDB has to read in for your queries can help you determine how much RAM you should allocate to your database.

這樣的設計邏輯很奇怪啊,你不要扯其他 database 啊,你們家主力的 InnoDB 一直都沒有推薦要 Working Set < RAM 啊,反過來才是用 InnoDB 的常態吧,而且在 PostgreSQL 上也是這樣吧 XDDD

現在上面的文章真的是挑著看了... XD

MySQL 的 TIME 範圍

這篇算是考古文,找出 MySQLTIME 資料型態奇怪範圍的由來:「TIME for a WTF MySQL moment」。

在官方的文件裡面可以看到 TIME 的範圍是個奇怪的數字,如果把各版本的文件都拉出來看,會發現都沒改過:「11.2.3 The TIME Type (8.0)」、「11.2.3 The TIME Type (5.7)」、「11.2.3 The TIME Type (5.6)」,「11.3.2 The TIME Type (5.5,靠 Internet Archive 的存檔頁面)」、「11.3.2 The TIME Type (5.1,靠 Internet Archive 的存檔頁面)」、「11.3.2 The TIME Type (5.0,靠 Internet Archive 的存檔頁面)」,裡面一直都是:

TIME values may range from '-838:59:59' to '838:59:59'.

這個數字看起來應該是某個限制,但作者粗粗算了幾種可能都不像,所以就一路考古,發現算是在 MySQL 3 年代因為某個特別公式留下來的遺毒,就一路用到現在了:

One of the bits was used for the sign as well, but the remaining 23 bits were an integer value produced like this: Hours × 10000 + Minutes × 100 + Seconds; in other words, the two least significant decimal digits of the number contained the seconds, the next two contained the minutes, and the remaining ones contained the hours. 223 is 83888608, i.e. 838:86:08, therefore, the maximum valid time in this format is 838:59:59.

話說回來,用 MySQL 的人還是很習慣用 INTBIGINT 來存時間,這樣可以自動遠離這些鳥問題,之前在「MySQL 裡儲存時間的方式...」與「Facebook 在 MySQL 裡存時間的型態」這邊都寫過...

不過最近用 PostgreSQL 比較多,可以比較「正常」的使用各種資料型態...

對 Amazon Aurora (MySQL-Compatible Edition) 另外建 Replica

Percona 的人寫了一篇怎麼對 Amazon Aurora (MySQL-Compatible Edition) 生 replica 的文章:「Creating an External Replica of AWS Aurora MySQL with Mydumper」。

這邊用的方法主要是出自「Replication with Amazon Aurora」這篇,裡面有提到有 binlog 可以用,所以 Percona 的作法應該是屬於「雖然不能 100% 保證以後還是可以用,但 99% 的機會以後應該還是可以用」。

這樣搞主要應該是用在 1) 省錢,2) 需要特殊的調整;如果不是這兩種,一般會選 Aurora 版本,應該不會太在意成本,直接用他提供的 read replica 就好?

MyRocks/MariaDB 的 tuning 過程

看起來應該是找 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,真的搞大了再考慮要不要換過去...

MariaDB 的 S3 Engine 效能測試

PerconaMariaDB 在 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 好像還好...

Multithreading 版本 pt-online-schema-change

看起來是個嘗試,Percona 的人試著修改 pt-online-schema-change,讓他可以在 INSERT 時 multi-threading,然後看效果:「Multithreaded ALTER TABLE with pt-online-schema-change and myloader」。

可以看出來 thread 夠多的情況下其實都變快不少 (上圖主要是看絕對數字,下圖是看相對比率):

如果沒有意外的話應該會有更多的測試,而這些測試沒問題的話,之後的官方版本裡面應該就會有這個功能。

Runtime 期間的最佳化工具:Dynimize

忘記在哪邊看到「Reduce MySQL CPU Usage Through Dynamic Binary Optimization」這篇文章了,裡面其實是在描述自家產品 Dynimize 的威猛。

翻了一些資料可以發現這個產品出來一陣子了,在 2018 的時候曾經在 Percona Live 上發表過:「Accelerating MySQL with JIT Compilers」,可以看出來有點像是 PGO (Profile-guided optimization) 的行為,只是他可以直接對 binary 處理。

定價的部份會是這類產品的重點,如果價錢比加硬體貴的話就沒那麼好用了... 在 Dynimize Pricing 這邊可以看到是 per CPU 的價錢,$0.00139/hr、$1/month 或是一次性的 $24,以效能提昇的程度來看,如果在 database 這邊是 CPU bound,是個頗值得投資的項目。

MySQL (InnoDB) 的內部狀態

Percona 老大 Peter Zaitsev 在「MySQL – A Series of Bad Design Decisions」這篇裡提到了他認為 MySQL 設計上的問題,不過裡面也提到了不少有用的指令,平常可以先熟悉一下輸出,等真的有狀況的時候才會想起來可以用這些指令。

首先是最經典的 SHOW ENGINE INNODB STATUS,算是很多文件上面都會提到的指令。可以看 InnoDB 當下的情況,藉以猜測內部現在是怎麼卡住...

另外一個是 SHOW ENGINE INNODB MUTEX,就如同 Peter Zaitsev 所提到的,這個指令想辦法抓出最重要的資訊,但不要像 SHOW ENGINE INNODB STATUS 給了那麼多。

另外當然就是 INFORMATION_SCHEMA,他甚至希望 SHOW ENGINE INNODB 系列的指令應該要被整合進去,這樣才能用 SELECT 相關的指令整理... (因為 ORDER BY 以及蠻多的指令沒辦法在 SHOW ... 上面用)

Amazon RDS 推出了 Connection Pool 的產品

Amazon RDS 推出了 Connection Pool 的產品,叫做 Amazon RDS Proxy:「Introducing Amazon RDS Proxy (Preview)」。

目前支援 MySQL (包括了傳統的與 Aurora 版本的):

Amazon RDS Proxy supports Amazon RDS for MySQL and Amazon Aurora with MySQL compatibility, with support for additional RDS database engines coming soon.

定價策略看起來是依照後端資料庫的 vCPU 計算:

Pricing is simple and predictable: you pay per vCPU of the database instance for which the proxy is enabled.

翻了一下價錢頁是 USD$0.015/vCPU (用 us-east-1 的資料),而如果是 t2 系列的機器,最低是以 2 vCPUs 計算,不是照使用比例算:

RDS Proxy pricing correlates to the number of vCPUs of the database instance for which it is enabled, with a minimum charge for 2 vCPUs.

這樣一個 vCPU 一個月大約要 USD$21.6,算起來頗貴的... 如果 SLA 允許的話,用基本的方式 failover 也許就 ok 了...

如果 SLA 真的要追求到這麼高的話,可以在這些區域測試:

Amazon RDS Proxy is available in preview for RDS MySQL and Aurora MySQL in US East (N. Virginia), US East (Ohio), US West (Oregon), EU West (Ireland), and Asia Pacific (Tokyo) regions. Support for RDS PostgreSQL and Aurora PostgreSQL is coming soon.

Amazon Aurora 可以直接使用 AWS 的 Machine Learning 服務

AWS 宣佈了 Amazon Aurora 可以直接使用 AWS 自家的 Machine Learning 服務:「New for Amazon Aurora – Use Machine Learning Directly From Your Databases」。

整合了兩個服務,分別是 Amazon SageMaker (各類的模型) 以及 Amazon Comprehend (文字處理相關)。

目前只有 Amazon Aurora MySQL 5.7 的版本有支援,其他的還在做:

The new machine learning integration is available today for Aurora MySQL 5.7, with the SageMaker integration generally available and the Comprehend integration in preview. You can learn more in the documentation. We are working on other engines and versions: Aurora MySQL 5.6 and Aurora PostgreSQL 10 and 11 are coming soon.

這個整合讓程式用起來更方便了...