Tag: row

MariaDB 的 S3 Engine 效能測試

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

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

在「MySQL 8.0: When to use utf8mb3 over utf8mb4?」這邊提到了 MySQL 對 utf8 以及 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.

PostgreSQL 9.5 預定提供的 Row Locking 改善

在「More Concurrency: Improved Locking In PostgreSQL」這邊提到 PostgreSQL 的 Row Locking 的改善，也就是 SELECT ... FOR UPDATE 與 SELECT ... FOR SHARE。

查了一下 SELECT 的文件，在 7.2 開始提供 FOR UPDATE (PostgreSQL: Documentation: 7.2: SELECT)，在 8.1 開始提供 FOR SHARE (PostgreSQL: Documentation: 8.1: SELECT)，以維基百科上的紀錄來看，7.2 是 2002 年二月，8.1 是 2005 年十一月，都是已經提很久的功能了。

用 FOR UPDATE 與 FOR SHARE 可以降低對 transaction 的依賴程度，PostgreSQL 的預設值是 READ COMMITTED，配合 Row Locking 就已經可以做到不少效果了，不需要用到 SERIALIZABLE 等級。

而在最新的 PostgreSQL 9.5 (目前還是開發版)，則又多提供了 FOR UPDATE SKIP LOCKED 功能，以官方提供的範例來說，就可以直接避開選位造成的 lock 問題了：

This makes sense because 100 users checking for a free seat concurrently will get 100 different rows. The consequence is that you are not stuck with 1 CPU but you can nicely scale out to all CPUs in the system. As conflicts cannot happen anymore, nobody has to wait on somebody else.

對 locking 控制的更細微。

InnoDB 的 BLOB field 存放的方式

這邊的 BLOB field 指的包括 VARCHAR、VARBINARY、BLOB、TEXT 這些常常被拿來放大物件的類型：「Externally Stored Fields in InnoDB」。

這跟 InnoDB 存放的格式 (ROW_FORMAT) 也有關，對於不同的格式都需要分開討論。

看之前需要帶一些背景知識，像是 Database index 裡面講到 index 種類時所提到的 Clustered。

看完後對 MySQL InnoDB 的運作方式會更了解一些，對於規劃 schema 也加減有些幫助。