關於 GitLab 的 SQL 設計

今天「My notes on Gitlab's Postgres schema design (2022) (shekhargulati.com)」這篇上 Hacker News 首頁 (看起來因為是在 pool 的關係,在第一頁卡很久...),文章「My Notes on GitLab Postgres Schema Design」是作者在 2022 年七月的時候分析了 GitLabstructure.sql 的資料庫設計整理出來的心得 & 感想,裡面有不少東西,不過這邊想補充個背景知識 (姿勢?):

RDBMS 在系統架構裡面,相較於其他的元件,是個很難 scale out 的東西 (i.e. 加更多機器得到更多效能),所以遇過 scalability 問題的架構師,會很習慣避開在 RDBMS 上面跑各種功能,有其他方式可以做的就拆出去用容易 scale out 的工具來做,非不得已才上 RDBMS。

而就算要塞進 RDBMS 裡的資料,能省的還是要省,畢竟宣稱自動幫你處理資料庫 scale out 的技術 (像是 CockroachDBTiDB) 其實沒想像中萬能,還是需要開發者改寫以前大惡搞的 SQL query (一個 terminal 列不完那種)。

而你心裡也有底,如果 scale out 不是條好的路,那麼只好 scale up (i.e. 加大機器的 CPU & RAM),而 scale up 總是有極限,真的遇到自己被迫要處理 sharding 的時候,DBOps/DBA 與 Dev 的臉都很臭... (一堆 JOIN 要改成拉回 application 端自己湊,或是有 ProxySQL 這種東西幫你處理,但是發現 ProxySQL 去後面資料庫拉太多資料幫你組反而很慢 !@#$%)

但另外一方面,現在已經不是 2005 年 64GB RAM 的伺服器是個天價的年代... 硬體的成長已經長到在 AWS 雲端上面可以租到給 SAP 用的 24TB RAM 的機器 (u-24tb1.112xlarge),而地端找個 server 也都有 15TB RAM (POWEREDGE R940),所以很容易把所有資料都塞到記憶體裡面搞,加上 NVMe 的讀寫速度比以前 HDD disk 快多了。

記得這兩件都是現實,然後再回來看文章內容與其他的討論,用不同的現實就會有不同的想法出現。

GitLab 的設計有他當時的限制以及想法,這些是外面的人看不到的,也就不好批評對錯。

Slack 自己幹的 Cron System

在 HN 上看到「Executing Cron Scripts Reliably at Scale (slack.engineering)」,發現是去年九月的文章:「Executing Cron Scripts Reliably At Scale」(話說 Slack 的 engineering blog 可讀性變差好多,不過這又是另外一回事了...)。

夠大的組織的 cron job system 都會自己幹一套出來用,因為檯面上的都不好用 XD

Slack 的搞法是組合三個內部系統:

  • 一個 container-based 管理實際執行資源的系統,基於 Bedrock,而 Bedrock 則是基於 k8s 上的系統。
  • 一個 job queue 子系統,後面是 Kafka + Redis 組成的。
  • 一組在 Vitess 上的表格,所以後面是 MySQL

這樣的系統也注定這是 Slack-only 的系統了,看一下知道用什麼就好了...

HashiCorp 的 Vault 也有 fork 了:OpenBao

當初 HashiCorp 宣布改 license (可以參考之前寫的「HashiCorp 將放棄 Open Source License,改採用 BSL 1.1」),用的最多的 Terraform 就馬上有人 fork 出來:「OpenTF 宣佈從 Terraform 最後一個 Open Source 版本 fork 出來」、「OpenTF (Terraform 的 fork) 改名為 OpenTofu」。

Vault 也受到影響,當時花了一些時間找看看有沒有人 fork,沒找到後就改用 etcd (然後搭配 etcd-adminer 以及 oauth2-proxyGoogle Workspace 的 SSO),後來就沒有追這個問題了...

剛剛才看到 fork 的消息出來了:「OpenBao – FOSS Fork of HashiCorp Vault (github.com/openbao)」,專案在「OpenBao」這邊,要注意目前只有 development branch 有東西,main branch 目前是空的,而且 Hacker News 上討論也有提到現在還在 early stage,很多東西都還在整理。

之後有機會再回來看看...

Trino Gateway

先前一直有在追蹤 TrinoHA 方案:「High Availability #391」,昨天看到有人更新消息,提到 Trino Gateway 這個專案,以及九月底的時候的公告:「Trino Gateway has arrived」。

主要是從 Presto Gateway 整理出來的:

The release is the result of many, many months of effort to move the legacy Presto Gateway to Trino, start a refactor of the project, and add numerous new features.

原始的 Presto Gateway 專案上面也已經標示後續請大家去看 Trino Gateway:

NOTE: This is a legacy version of Trino Gateway. Please refer to https://github.com/trinodb/trino-gateway for active development and updates moving forward.

然後 Release notes 這邊可以看到前幾天又出一個新版了,看起來是有能量在專案上的。

從「Design」這頁可以看到軟體本身分成 BaseApp、ProxyServer 與 Gateway 三個部分,架構面上可以看得出來是 Proxy 架構。

從「References」這頁可以看到一些組織使用前身 Presto Gateway 的心得:

目前應該會需要一些時間,把積在 backlog 的功能開發出來。之後如果還有遇到 Trino 的話可以拿出來重新研究發展到什麼地方...