幹壞事是進步最大的原動力
在 Hacker News 上看到的方法，Simon Willison 試著把程式碼餵進 GPT-3，然後問 GPT-3 程式碼的意思，看起來答的還不錯：「Using GPT-3 to explain how code works」，對應的討論 (包括 Simon Willison 的回應) 則可以在「Using GPT-3 to explain how code works (simonwillison.net)」這邊看到。
第一個範例裡面可以解讀 regular expression，雖然裡面對 (?xm) 的解讀是錯的，但我會說已經很強了...
第二個範例在解釋 Shadow DOM，看起來也解釋的很不錯...
第三個範例回來原來產生程式碼的例子，拿來生 SQL 指令。
後面的 bonus 題目居然是拿來解釋數學公式，他直接丟 TeX 文字進去要 GPT-3 解釋柯西不等式 (Cauchy–Schwarz inequality)。這樣我想到以前高微作業常常會有一堆證明題，好像可以丟進去要 GPT-3 給證明耶...
翻資料的時候翻到「pg-osc: Zero downtime schema changes in PostgreSQL」這篇文章，可以在 PostgreSQL 上做到類似 pt-online-schema-change 的事情，這邊先提一下 pt-online-schema-change 的說明：
ALTER tables without locking them.
不管是 MySQL 還是 PostgreSQL，都會遇到 ALTER TABLE 常常會 lock 的問題，這點主要的影響就是 db migration。
在 dev 環境的機器應該沒什麼問題，資料量都不大，應該是很快就可以跑完；但在 stage 環境時就會開始有狀況了 (假設是從 production 複製過來的資料，表格的大小可能偏大)，但應該還是可以用 downtime 換，慢慢跑，花幾個小時把 db migration 跑完。
可是到了 production 環境時就不太能這樣搞了，這也是一般不太建議在 production 環境裡用現成的 db migration 工具，尤其當資料量偏大的時候。
解這個問題的方法就是透過繞路的方式，不要直接動原來的 table：基本的想法是開一個新的 table，然後一直從舊的 table 搬資料到新的 table 上 (包括應用程式下指令寫到舊的 table 上的資料)，直到最後用一個短暫的 lock 機制來切換 table。
在 MySQL 的世界裡比較有名的是 Percona 的 pt-online-schema-change (trigger-based) 以及 GitHub 的 gh-ost (replication-based)，另外找資料的時候有發現 Facebook 也有丟 OnlineSchemaChange (trigger-based) 出來。
在 PostgreSQL 的世界裡似乎是 pg_repack 這個方案，用了 trigger-based 的方式處理，但之前沒有注意到，是翻 pg-osc 的時候被提到才知道有這個工具。
而這次提到的 pg-osc 則是 2022 年才出的軟體，也是 trigger-based 的方式：
pg-osc uses the concept of shadow tables to perform schema changes. At a high level, it creates a shadow table that looks structurally the same as the primary table, performs the schema change on the shadow table (avoiding any locks since nothing is using this table), copies contents from the primary table to the shadow table and swaps the table names in the end while preserving all changes to the primary table using triggers (via audit table).
另外從 PostgreSQL 的 wiki 上看到「Change management tools and techniques」這頁，裡面看到「Metagration: Logical PostgreSQL Migration」這個工具，看起來好像是 replication-based 的方案，不過還是有用到一些 trigger 做事。
這些方案都先記錄起來好了...
從 Simon Willison 這邊看到 command line 下用 SQLite 的技巧：「One-liner for running queries against CSV files with SQLite」。
範例指令是這樣 (整理了一下排版)：
sqlite3 :memory: \
-cmd '.import -csv taxi.csv taxi' \
'SELECT passenger_count, COUNT(*), AVG(total_amount) FROM taxi GROUP BY passenger_count'
可以看出來這個方式是將 csv 檔先讀到 in-memory database (:memory:)，再用 SQLite 下指令處理，另外也可以自己變化，應該可以透過 /dev/stdin 這樣的方式讀 pipe 的東西。
拿來簡單跑一些東西應該還不賴？
也是在清 RSS reader 的時候翻到的，看起來是在今年的 Google I/O 上發表的服務，AlloyDB：「AlloyDB for PostgreSQL under the hood: Intelligent, database-aware storage」，值得提的是這篇有中文版可以看：「適用於 PostgreSQL 的 AlloyDB 隆重登場：從此擺脫成本高昂的老舊資料庫」。
另外還有一篇比較偏 PR 的文章也可以看看：「Introducing AlloyDB for PostgreSQL: Free yourself from expensive, legacy databases」，這篇就比較針對的提到了與 AWS 的服務相比，但畢竟是 PR 稿沒有明講 (出事會比較好打模糊戰)，但我猜測是與 Aurora 對比：
AlloyDB was also two times faster for transactional workloads than Amazon’s comparable service.
宣稱在 OLTP 上快了兩倍 (原來的三倍？)，但應該都是以 PostgreSQL 下去改，猜測可能是底層的 storage 與 replication 比較好？
AlloyDB 設計上是考慮了 HTAP (Hybrid transactional/analytical processing) 的使用，所以同時可以提供 OLAP 與 OLTP 的應用：
[...] This makes AlloyDB a great fit for business intelligence, reporting, and hybrid transactional and analytical workloads (HTAP).
直接在一個資料庫內處理 OLAP 與 OLTP 這點的確會讓 AlloyDB 比 AWS 目前能提供的方案方便不少 (然後想一下 BigQuery 團隊...)。
目前在 AWS 對應的方案應該是透過 Redshift 來解決，另外一個方案是透過 Athena 來跑。
最後來看價錢，如果效能變成兩倍但價錢也是兩倍的話，就代表在價格上沒優勢。
先看機器的部份，如果是拿 Aurora 這邊 Intel-based 的 db.r5.24xlarge (96 vCPU + 768 GB RAM) 來算的話是 US$13.92/hr，而如果換算到 AlloyDB 的話是 US$14.94528/hr，相除是 0.9314，大約 7% 的差距，可以算是同一個級距。
如果 Aurora 這邊是拿 ARM-based 的 db.r6g.16xlarge (64 vCPU + 512 GB RAM) 來算的話是 US$8.306/hr，換算到 AlloyDB 的話是 US$9.96352/hr，相除是 0.8336，這邊就差超過 16% 了...
(這邊剛好回顧一下 "Amazon’s comparable service" 這段，不確定他是跟 Intel-based 比還是跟 ARM-based 比，畢竟 ARM 除了比較便宜外，還有效能的提昇)
但最大的差異應該是在 storage 相關的部份。其中 Aurora 這邊的空間與 I/O 是分開收費的，以 us-east-1 來說，storage 是 US$0.10/GB/mo，而 I/O 是 US$0.20/million-requests，在 AlloyDB 這邊來說，Regional cluster storage 是 US$0.0004109/GB/hr (us-east4)，變成是 US$0.295848/GB/mo，兩邊相比後可以算出來對等的計價會是 AWS 的 storage 加上 AWS 給你 1.47M 的 I/O (per GB)。
這樣算起來把資料丟 S3 跑 Athena 可能不會比較貴... (當然效能是另外的主題了)
光就檯面上的資料來看，看起來是個不錯的東西，等後續有人跳進去用看看感想...
GitHub 針對了這個月的四次 downtime 說明，大致上都跟 mysql1 這組 cluster 有關：「An update on recent service disruptions」，這是 Keith Ballinger 發的文章，找了一下掛的頭銜是 SVP of Engineering at GitHub。
文章裡提到的 mysql1 在「Partitioning GitHub’s relational databases to handle scale」這邊可以看到一些資訊 (我在「GitHub 的 MySQL 架構與數字」這邊也有提到)，基本上有 ProxySQL + Vitess 兩套方案在 scale，但可以看出來主資料庫本身還是有很大的 loading 在上面跑。
這次的問題是 mysql1 看起來這次遇到了效能上的瓶頸，不過還是沒找到原因，這可以從這幾次的說明看出來，從第一次的 outage：
The incident appeared to be related to peak load combined with poor query performance for specific sets of circumstances.
第二次的：
The following day, we saw the same peak traffic pattern and load on mysql1. We were not able to pinpoint and address the query performance issues before this peak, and we decided to proactively failover before the issue escalated.
第三次的：
While we had reduced load seen in the previous incidents, we were not fully confident in the mitigations.
In this third incident, we enabled memory profiling on our database proxy in order to look more closely at the performance characteristics during peak load.
到最近第四次的：
In order to reduce load, we throttled webhook traffic and will continue to use that as a mitigation to prevent future recurrence during peak load times as we continue to investigate further mitigations.
可以看到基本上還沒完，之後再遇到問題時應該還是會把 webhook traffic 拿出來開刀...
看到「Waiting for PostgreSQL 15 – Add UNIQUE null treatment option」這篇文章裡面提到 PostgreSQL 對 UNIQUE 多加了一些功能進去：「Add UNIQUE null treatment option」。
The SQL standard has been ambiguous about whether null values in unique constraints should be considered equal or not. Different implementations have different behaviors. In the SQL:202x draft, this has been formalized by making this implementation-defined and adding an option on unique constraint definitions UNIQUE [ NULLS [NOT] DISTINCT ] to choose a behavior explicitly.
This patch adds this option to PostgreSQL. The default behavior remains UNIQUE NULLS DISTINCT. Making this happen in the btree code is pretty easy; most of the patch is just to carry the flag around to all the places that need it.
The CREATE UNIQUE INDEX syntax extension is not from the standard, it's my own invention.
I named all the internal flags, catalog columns, etc. in the negative ("nulls not distinct") so that the default PostgreSQL behavior is the default if the flag is false.
Reviewed-by: Maxim Orlov
Reviewed-by: Pavel Borisov
Discussion: https://www.postgresql.org/message-id/flat/84e5ee1b-387e-9a54-c326-9082674bde78@enterprisedb.com
以往針對某個欄位下 UNIQUE 後，雖然同樣的值是無法 INSERT 進去，但 NULL 則是個例外，是可以塞多次進去的。
現在則是提供選項指定對 NULL 的解讀了；預設還是保留原來行為的 UNIQUE NULLS DISTINCT (把每個 NULL 都當作不同的值看待)，特別指定後會變成 UNIQUE NULLS NOT DISTINCT (把每個 NULL 都當作一樣的值，進而被 UNIQUE 條件限制)。
在下一個版本的 PostgreSQL 15 就會出現這個功能了...
發現自己根本還不熟悉 PostgreSQL 的特性，寫一下記錄起來。
產品上常常會有 coupon 與 voucher 之類的設計，這時候通常都會設定 coupon 或 voucher 的有效期間，在 MySQL 的環境下可能會這樣設計：
CREATE TABLE coupon ( id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT, code VARCHAR(255) NOT NULL, started_at INT UNSIGNED NOT NULL, ended_at INT UNSIGNED NOT NULL );
另外是設計 index 的部份，在產品推出夠久後，通常是過期的 coupon 或 voucher 會比目前還有效的多，而還沒生效的 coupon 與 voucher 通常都不多，所以會設計成對 ended_at 放一組 B-tree index：
CREATE INDEX ON t1 (ended_at);
這個設計不算差，不過用了一些假設。
如果不想要用這些假設，可以改用 Spatial 的資料型態去模擬並且加上 index (使用到 LineString Class)，這樣就直接對 a < x < b 這類查詢更有效率，不過缺點就是可讀性會比較差。
在 PostgreSQL 這邊就有更清晰的資料結構來處理這些事情，主要是有一般性的 int4range 與 int8range 以及時間類的 tsrange、tstzrange 與 daterange (參考「Range Types」這邊有更多資料型態)，所以會變成：
CREATE TABLE coupon ( id INT GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY, code VARCHAR NOT NULL, active_at INT4RANGE NOT NULL );
然後用 GIST 建立 index：
CREATE INDEX ON t1 USING GIST(active_at);
後續的 query 語法就用 <@ 的語法：
SELECT COUNT(*) FROM coupon WHERE 10000 <@ active_at;
塞了 10M 筆資料後的 table 可以看到本來需要的時間是：
Time: 779.542 ms
變成：
Time: 5.510 ms
不過缺點就是 SQLite 沒支援這些資料型態，對於 test case 就一定得跑個 PostgreSQL 起來測...
在 Hacker News Daily 上看到「A truly Open Source MongoDB alternative」這個東西，在「MangoDB: An open-source MongoDB alternative (mangodb.io)」的討論也可以翻一翻。
MongoDB 最主要的問題就是 4.0 以及以後的版本變成 SSPL 後就不是 open source license 了。
而 MangoDB 是個 Proxy service，前端提供 MongoDB 的協定，後端則是 PostgreSQL。
在 GitHub 上的「MangoDB-io/MangoDB」這邊可以看到 MangoDB 主要是用 Golang 寫的，軟體授權則是 Apache License 2.0。
The core of our solution is a stateless proxy, which converts MongoDB protocol queries to SQL, and uses PostgreSQL as a database engine. This will be compatible with MongoDB drivers, and should work as a drop-in replacement to MongoDB in many cases.
這對於只有提供 MongoDB 當儲存層的軟體來說會是個替代方案。不過如果是自己開發的話，這其實也證明了可以直接用 PostgreSQL，基本上 MongoDB 的功能都可以在 PostgreSQL 上找到方案。
話說這個讓我想到 2019 年 AWS 推出 Amazon DocumentDB 的時候，大家都一直在猜 Amazon DocumentDB 是不是拿 PostgreSQL 前面加上一些東西 (參考「大家在猜 Amazon DocumentDB 的底層是不是 PostgreSQL...」)，後來也有人發現再更早之前就有人 PoC 過了：「A proof of concept MongoDB clone built on Postgres (github.com/jerrysievert)」，現在一般的公認應該就是，只是 AWS 沒有 open source 出來。
目前 MangoDB 還在早期的階段，但看起來這波應該會有一些能量進去幫忙...
看到「Goodbye Microsoft SQL Server, Hello Babelfish」這篇，AWS 對 Aurora (PostgreSQL) 推出了可以吃 Microsoft SQL Server 協定的 Babelfish：
Today, we are making Babelfish for Aurora PostgreSQL available. Babelfish allows Amazon Aurora PostgreSQL-Compatible Edition to understand the SQL Server wire protocol.
查了一下資料發現是去年年底的時候發表的：「Want more PostgreSQL? You just might like Babelfish」，不過當時沒注意到這東西，大概是因為是 preview 的關係：
We are open sourcing Babelfish in 2021. Until then, you can use Babelfish on Amazon Aurora in a preview to see how it works and to get a sense for whether this is the right approach for you.
用起來不知道怎樣，但感覺很值得注意，目前雖然沒用到 Microsoft SQL Server 的東西，但以後遇到可以考慮看看...
除了在 AWS 上用以外，也可以自己到 GitHub 上拉 patch 回來上：「babelfish-for-postgresql」。
話說回來，PostgreSQL 被 AWS 拿來用在好多地方啊，先前大家也猜是 DocumentDB 後面是 PostgreSQL (參考「大家在猜 Amazon DocumentDB 的底層是不是 PostgreSQL...」這篇)，不知道之後會不會想要跟 Oracle 的律師打架...
先前 Percona 的人在講 MySQL 存 JSON object 的方式，現在開始講在 PostgreSQL 裡存 JSON object，並且增加 index 的方式了：「Storing and Using JSON Within PostgreSQL Part One」。
這基本上就是不想用 MongoDB，但還是有需要極為彈性而選擇用 JSON object 的需求。
首先先先建立一個表格，這邊直接用 JSONB：
alice=# CREATE TABLE table1 (id SERIAL PRIMARY KEY, jb JSONB);
接著拿「A dataset of English plaintext jokes」這邊的 reddit_jokes.json 來玩，我先把 JSON 裡面的內容變成 JSON Lines 格式：
cat reddit_jokes.json | jq -c '.[]' > reddit_jokes.jsonl
然後 COPY 了十次，多一點資料，後面可以看效能：
alice=# COPY table1 (jb) FROM '/tmp/reddit_jokes.jsonl' CSV QUOTE e'\x01' DELIMITER e'\x02'; -- (repeat this command 10 times)
接著跑個 SELECT 看看速度，我跑了幾次大約都在 260ms 上下：
alice=# SELECT COUNT(*) FROM table1 WHERE (jb->>'score')::int = 10; count ------- 25510 (1 row) Time: 264.023 ms
然後針對 score 生個數字的 index：
alice=# CREATE INDEX ON table1 (((jb->>'score')::int)); CREATE INDEX Time: 1218.503 ms (00:01.219)
接著再跑 SELECT 下去，可以看到速度快超多：
alice=# SELECT COUNT(*) FROM table1 WHERE (jb->>'score')::int = 10; count ------- 25510 (1 row) Time: 12.735 ms
另外也可以加 column：
alice=# ALTER TABLE table1 ADD COLUMN score INT GENERATED ALWAYS AS ((jb->>'score')::int) STORED;
然後可以看到速度也不快：
alice=# SELECT COUNT(*) FROM table1 WHERE score = 10; count ------- 25510 (1 row) Time: 222.163 ms
幫他補 index：
alice=# CREATE INDEX ON table1 (score);
速度有變快，但不知道為什麼沒有 JSONB 的版本快：
alice=# SELECT COUNT(*) FROM table1 WHERE score = 10; count ------- 25510 (1 row) Time: 81.346 ms
算是還蠻好用的，不過得學 JSON query 語法... (應該是還好)