Tag: database

Meta (Facebook) 把 MySQL replication 丟上自製的 Raft 系統

看到「Building and deploying MySQL Raft at Meta」這篇，在講 Meta (Facebook) 把 MySQL 的 replication 架構換成自己用 Raft 的系統。

舊的系統是走 MySQL 的 semisync replication：

Previously, our replication solution used the MySQL semisynchronous (semisync) replication protocol.

其中 semisync replication 是在 MySQL 5.5 加入的功能，在至少一個遠端收到 replication log 後才傳回成功 (可以設定數量)：「Semisynchronous Replication」。

Semisynchronous replication falls between asynchronous and fully synchronous replication. The source waits until at least one replica has received and logged the events (the required number of replicas is configurable), and then commits the transaction.

然後舊的系統是透過一包 Python 軟體在管理這些機器的各種 failover 操作：

The control plane operations (e.g., promotions, failover, and membership change) would be the responsibility of a set of Python daemons (henceforth called automation).

這個方法常遇到的問題是切換 primary server (以前叫做 master server) 時有可能會因為 binlog position 接不起來而失敗。

所以後來 MySQL 導入了 GTID，可以緩解這個問題，但還是有可能會發生不同的 secondary server (以前叫做 slave server) 會有不一樣的資料。

而在 Meta 改出來的架構裡面，把 replication data 直接寫到一個用 Raft 同步的系統，同步到其他的 secondary server 上面：

In MySQL Raft:

  • Primary writes to binlog via Raft, and Raft sends binlog to followers/replicas.
  • Replicas/followers receive in binlog and apply the transactions to the engine. An apply log is created during apply.
  • Binlog is the replicated log from the Raft point of view.

是個一般單位不太會遇到的架構，而且可以預期其他公司的人遇到類似問題應該也不會用這個方法解...

MariaDB 嘗試相容於 PostgreSQL 協定的產品

在 Twitter 上看到的消息，新聞在「MariaDB's Xpand offers PostgreSQL compatibility without the forking drama」這邊：

看起來是 SkySQL 的服務，這樣聽起來不像會 open source... 看起來賣點在於 globally distributed RDBMS 這個部分：

MariaDB is previewing a PostgreSQL-compatible front end in its SkySQL Database-as-a-Service which provides a globally distributed RDBMS on the back end.

再看看後續會不會有更多消息？

測了 PGroonga，PostgreSQL 上的 fulltext search engine

在 PostgreSQL 的 news 頁上看到「PGroonga 3.0.0 - Multilingual fast full text search」，想到一直沒有測過 PGroonga，就找台機器測了一下。

PGroonga 是以 Groonga 為引擎提供 PostgreSQL 全文搜尋能力的套件，是個能支援 CJK 語系的全文搜尋套件。

可以先看一下支援的 column type 與對應的語法：「Reference manual | PGroonga」，可以發現基本的 text、text[] 與 varchar、varchar[] 都有支援，比較特別的是有 jsonb，看起來是對裡面的 text 欄位搜尋。

另外一個比較特別的是他會去配合 LIKE '%something%' 這樣的語法，對於無法修改的既有程式也會有幫助。

缺點方面，官方有提到產生出來的 index 會比其他的套件大，但畢竟我們在的環境要支援 CJK，場上的選手已經不多了。

另外一個缺點是目前 AWS 的 RDS 與 GCP 的 Cloud SQL 看起來都沒支援，要用的話得自己架 & 自己管，也許可以考慮用老方法，replication 接出來？

接下來就是安裝測試了，我在 x86-64 上的 Ubuntu 22.04 上面測試，就照著「Install on Ubuntu | PGroonga」這頁裡面的「How to install for system PostgreSQL」這段就可以了，裝系統的 PostgreSQL 14 以及 postgresql-14-pgroonga，之後要用 PostgreSQL 官方的新版的話可以參考「How to install for the official PostgreSQL」這段的安裝。

後續再到「Tutorial | PGroonga」頁，針對要搜尋的欄位下 index (這邊裱格式 memos，欄位是 content)：

CREATE INDEX ON memos USING pgroonga (content);

官方的教學文件裡是用 SET enable_seqscan = off; 關閉 sequence scan，可以用 EXPLAIN 看到使用了 index：

test=# SELECT * FROM memos WHERE content &@ 'engine';
 id |                                content                                 
----+------------------------------------------------------------------------
  2 | Groonga is a fast full text search engine that supports all languages.
(1 row)

test=# EXPLAIN SELECT * FROM memos WHERE content &@ 'engine';
                                   QUERY PLAN                                    
---------------------------------------------------------------------------------
 Index Scan using memos_content_idx on memos  (cost=0.00..43.18 rows=1 width=36)
   Index Cond: (content &@ 'engine'::text)
(2 rows)

先拔掉 index：

test=# DROP INDEX pgroonga_content_index;
DROP INDEX

接著要塞資料，這邊拿 CQD 生的「中文假文產生器」來用，有 API 可以接比較方便。

test=# SELECT COUNT(*) FROM memos;
 count  
--------
 100000
(1 row)

Time: 15.495 ms

接著多跑幾次測試直接用 LIKE '%台北%' 去找，可以看到大概都在 150ms 以上：

test=# SELECT COUNT(*) FROM memos WHERE content LIKE '%台北%';
 count 
-------
   710
(1 row)

Time: 178.784 ms

接著來建立 index：

test=# CREATE INDEX ON memos USING pgroonga (content);
CREATE INDEX
Time: 17638.124 ms (00:17.638)

再跑幾次同樣的 query，可以看到巨大的改善：

test=# SELECT COUNT(*) FROM memos WHERE content LIKE '%台北%';
 count 
-------
   710
(1 row)

Time: 9.876 ms

SQL:2023 的新玩意

Hacker News 上看到「SQL: 2023 is finished: Here is what's new (eisentraut.org)」這篇題到了 SQL:2023 標準的新東西，對應的原文在「SQL:2023 is finished: Here is what's new」這邊。

「UNIQUE null treatment (F292)」讓你可以決定 NULL 到底要不要算 unique，剛好跟之前寫過的「PostgreSQL 15 將可以對透過 UNIQUE 限制 NULL 的唯一性了」要做的事情一樣。

「ORDER BY in grouped table (F868)」則是針對沒有出現在 SELECT 的欄位頁可以 ORDER BY，看了一下說明，主要是在 JOIN 的時候限制住了。很明顯的 workaround 是多加上這個欄位，但就代表會增加傳回的資料量。

「GREATEST and LEAST (T054)」這個因為 MIN() 與 MAX() 已經被 aggregate function 用掉了，所以只好另外取名。

「String padding functions (T055)」與「Multi-character TRIM functions (T056)」是熟悉的語法，各家都有對應的 function 可以做，但這次就放進標準化。

「Optional string types maximum length (T081)」是 VARCHAR 可以不用指定大小了，實務上應該是還好？

「Enhanced cycle mark values (T133)」這編提到的 recursive 真的是每次用每次忘，然後 cycle 這個功能就沒看懂了...

「ANY_VALUE (T626)」看起來可以隨機取出資料，搭配 GROUP BY '' 就不用拿 ORDER BY RAND() 這種髒髒的東西出來了？

「Non-decimal integer literals (T661)」與「Underscores in numeric literals (T662)」都是讓數字更好讀以及操作。

後面講了很多 JSON 功能，看起來是 SQL:2016 有先納入一些，但 SQL:2023 補的更完整了。

然後有 Graph 相關的標準也被定義進 SQL:2023，原文介紹的也不是很多，看起來是要跨足過來？

MySQL 5.7 的支援只到今年十月 (Oct 2023)

剛剛翻資料才看到 Oracle 對 MySQL 5.7 的支援原來只剩下半年了，預定在 2023 年十月中止：「Oracle Technology Products - Oracle Lifetime Support Policy」。

隔壁棚 Percona 包的 Percona Server for MySQL 5.7 可以從「Percona Release Lifecycle Overview」這邊查，看起來也設定一樣的時間 (2023 年十月)，但不確定會不會宣佈延長，至少提供 security fix 之類的。

一直沒注意，突然發現只剩下半年...

MongoDB 的替代方案 FerretDB 推出 1.0 (GA) 版本

Hacker News 上看到 FerretDB 推出 1.0 (GA) 版本：「FerretDB: open-source MongoDB alternative (ferretdb.io)」，原文在「Announcing FerretDB 1.0 GA - a truly Open Source MongoDB alternative」這邊。

當初有寫過「MangoDB 改名為 FerretDB (雪貂)」這篇，但沒注意到他們成立公司來開發？在「Careers at FerretDB」這邊可以看到 hiring 的訊息。

官網有整理出目標，像是他們提到不是以 drop-in replacement 為目標，而是實做核心功能與常用的功能，涵蓋大多數的使用者：

Is FerretDB 100% compatible with MongoDB?

It is not necessary, nor it is feasible to implement every single MongoDB feature out there. Our aim is to cover the core feature set of MongoDB, and then continue adding features which could enhance the experience or increase application compatibility. Non-OSS alernatives of MongoDB are similar in this sense, eg. none of these products are able to provide the full feature set of MongoDB. We are aiming to please 85% of MongoDB users, not all of them.

但這樣也讓想換的人會有一些顧慮... 而且這邊的 85% 不知道是怎麼喊出來的？

把 RabbitMQ 換成 PostgreSQL 的那篇文章...

在 Hacker News 上看到「SQL Maxis: Why We Ditched RabbitMQ and Replaced It with a Postgres Queue (prequel.co)」這篇文章，原文在「SQL Maxis: Why We Ditched RabbitMQ And Replaced It With A Postgres Queue」這邊，裡面在講他們把 RabbitMQ 換成 PostgreSQL 的前因後果。

文章裡面可以吐嘈的點其實蠻多的，而且在 Hacker News 上也有被點出來，像是有人就有提到他們遇到了 bug (或是 feature) 卻不解決 bug，而是決定直接改寫成用 PostgreSQL 來解決，其實很怪：

In summary -- their RabbitMQ consumer library and config is broken in that their consumers are fetching additional messages when they shouldn't. I've never seen this in years of dealing with RabbitMQ. This caused a cascading failure in that consumers were unable to grab messages, rightfully, when only one of the messages was manually ack'ed. Fixing this one fetch issue with their consumer would have fixed the entire problem. Switching to pg probably caused them to rewrite their message fetching code, which probably fixed the underlying issue.

另外一個吐嘈的點是量的部份，如果就這樣的量，用 PostgreSQL 降低使用的 tech stack 應該是個不錯的決定 (但另外一個問題就是，當初為什麼要導入 RabbitMQ...)：

>To make all of this run smoothly, we enqueue and dequeue thousands of jobs every day.

If you your needs aren't that expensive, and you don't anticipate growing a ton, then it's probably a smart technical decision to minimize your operational stack. Assuming 10k/jobs a day, thats roughly 7 jobs per minute. Even the most unoptimized database should be able to handle this.

在同一個 thread 下面也有人提到這個量真的很小，甚至直接不講武德提到可以用 Jenkins 解 XD：

Years of being bullshitted have taught me to instantly distrust anyone who is telling me about how many things they do per day. Jobs or customers per day is something to tell you banker, or investors. For tech people it’s per second, per minute, maybe per hour, or self aggrandizement.

A million requests a day sounds really impressive, but it’s 12req/s which is not a lot. I had a project that needed 100 req/s ages ago. That was considered a reasonably complex problem but not world class, and only because C10k was an open problem. Now you could do that with a single 8xlarge. You don’t even need a cluster.

10k tasks a day is 7 per minute. You could do that with Jenkins.

然後意外看到 Simon Willison 提到了一個重點，就是 RabbitMQ 到現在還是不支援 ACID 等級的 job queuing (尤其是 Durability 的部份)，也就是希望 MQ 系統回報成功收到的 task 一定會被處理：

The best thing about using PostgreSQL for a queue is that you can benefit from transactions: only queue a job if the related data is 100% guaranteed to have been written to the database, in such a way that it's not possible for the queue entry not to be written.

Brandur wrote a great piece about a related pattern here: https://brandur.org/job-drain

He recommends using a transactional "staging" queue in your database which is then written out to your actual queue by a separate process.

這也是當年為什麼用 MySQL 幹類似的事情，要 ACID 的特性來確保內容不會掉。

這也是目前我覺得唯一還需要用 RDBMS 當 queue backend 的地方，但原文公司的想法就很迷，遇到 library bug 後決定換架構，而不是想辦法解 bug，還很開心的寫一篇文章來宣傳...

MariaDB 以及 Trac 在 arm64 上的安裝

把一台本來跑在 Vultr 上的機器搬到 AWS 的 us-east-1 上面，除了剛好把 Ubuntu 18.04 換成 Ubuntu 22.04 外，也把本來用 x86-64 架構的機器換成用 ARM 的 t4g.micro (都是 1GB RAM)。

就效能上來說，t4g 機器的效能很不錯，這兩年 blog 跑的也都還算順，先前公司用起來感覺也很好，然後價錢更便宜，另外加上 AWS 的三年 RI 折扣大約是 4 折的價錢，算是會想要換的主因。

在確認應用跑得起來後，買三年 RI 是 $87.15/3y，所以機器本身的費用大約是 $29.05/y，就算加上 8GB 的 EBS (gp3) 空間費用，整體比本來在 Vultr 的 $6/mo 低不少。

上面跑的是我自己的 Trac，想搬到 AWS 上一陣子了，但有幾個不確定的因素，所以連假期間才有空多花一些時間確認。

第一個是 MySQL 的部份，我自己習慣用 Percona Server 的版本，但目前還沒有 arm64 的套件可以直接裝，要用的話就得自己編以及升級。

在 2021 年的時候 blog 搬到 AWS 的時候就遇過了，本來以為這次有機會，但看了一下還是沒支援，所以還是得用 MariaDB。

第二個是 Trac 1.4 只能跑在 Python 2.7 上 (mailing list 上有在討論轉到 Python 3 的事情，但看起來官方的動力也不大...)，這在 18.04 的時代是沒什麼問題，但 22.04 下面不知道會爛掉多少東西。

所以只能繼續用 pyenv 扛著，但已經有預期會遇到問題，加上這次又從 MySQL 轉到 MariaDB，應該也會有些地雷...

所以跳下去後遇到的問題就跟上面提到的類似，分成兩塊。

在 MariaDB 這邊第一個遇到問題是，雖然官方有提供 APT server，但沒有在 HTTPS server 上放新的 public key，所以一定得從 key server 撈。

但 GnuPG 就是沒有直接從 key server 下載變成檔案的功能，一定要先塞到 keystore 裡面再 export 出來，就覺得很...

所以就冒出利用 mktemp -d 在 /tmp 下產生暫存目錄這樣的寫法，讓 GnuPG 把 keystore 放進去，這樣至少在重開機後就會消失：

export GNUPGHOME=$(mktemp -d); gpg --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0x177F4010FE56CA3336300305F1656F24C74CD1D8; gpg --export 0x177F4010FE56CA3336300305F1656F24C74CD1D8 | sudo tee /etc/apt/trusted.gpg.d/mariadb.gpg > /dev/null; unset GNUPGHOME

這邊為了安全性，還得把官方提供的 0xF1656F24C74CD1D8 換成 0x177F4010FE56CA3336300305F1656F24C74CD1D8。

另外就是整理 MariaDB 需要的 my.cnf 內容，我是拿 Percona Server 5.7 的設定檔來改，只刪掉了跟 GTID 相關的設定就會動了。

而其他 MariaDB 遇到的問題主要是設計改變的問題，在 wiki 上有提到。

接下來是 Trac 1.4 的問題，本來的安裝是用 libmysqlclient-dev，然後再安裝 mysql-python：

sudo apt install -y libmysqlclient-dev
pip install mysql-python PyMySQL Pygments Trac

但單純把 libmysqlclient-dev 換成 libmariadb-dev 後，mysql-python 還是編不動，照著錯誤訊息試著 workaround (像是試著把 /usr/bin/mysql_config 指到 /usr/bin/mariadb_config) 半天還是不過，最後找資料發現要改用 mysqlclient：

sudo apt install -y libmariadb-dev
pip install mysqlclient PyMySQL Pygments Trac

搞定後後續就一路看錯誤訊息解就可以了...

Amazon DocumentDB 支援 MongoDB 5.0 協定

看到「Amazon DocumentDB (with MongoDB compatibility) adds support for MongoDB 5.0 wire protocol and client-side field level encryption」這篇，Amazon DocumentDB 推出了 MongoDB 5.0 的支援。

MongoDB 5.0 是 2021 年七月的版本，對使用者端比較重要的看起來是 PII 處理與 TSDB 的支援。

比較感興趣的是，TSDB 的部份是繼續用 PostgreSQL 魔改嗎...？

Pony ORM

在 Simon Willison 的 blog 上看到的東西：「Python’s “Disappointing” Superpowers」，裡面提到的原文是「Python’s “Disappointing” Superpowers」這篇，在講 Python 的工具。

雖然是說「disappointing」，但實際上是反義，在原文裡面提到了很多特別的工具，其中 Pony ORM 算是我覺得最有趣的了，他的寫法就非常的 Python：

select(c for c in Customer if sum(c.orders.price) > 1000)

也可以用 lambda 的形式來寫：

Customer.select(lambda c: sum(c.orders.total_price) > 1000)

這樣會產生出對應的 SQL：

SELECT "c"."id"
FROM "customer" "c"
  LEFT JOIN "order" "order-1"
    ON "c"."id" = "order-1"."customer"
GROUP BY "c"."id"
HAVING coalesce(SUM("order-1"."total_price"), 0) > 1000

不會產生 syntax error 的原因是因為他直接解讀 bytecode 分析，產生出對應的 SQL query：

A normal understanding of generator expressions suggests that the select function is consuming a generator. But that couldn’t explain the behaviour here. Instead, it actually introspects the frame object of the calling code, then decompiles the byte code of the generator expression object it finds, and builds a Query based on the AST objects.

用這樣的設計來達到語法的自由度。

看了一下也有一些 integration，像是 Flask 的「Integration with flask」與 FastAPI 的「Integration with FastAPI」。

不過應該是先看看，目前 Python 上用的主力還是 Django，有自己的 ORM 架構...