關於 GitLab 的 SQL 設計
source link: https://blog.gslin.org/archives/2024/02/19/11671/%e9%97%9c%e6%96%bc-gitlab-%e7%9a%84-sql-%e8%a8%ad%e8%a8%88/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
關於 GitLab 的 SQL 設計
今天「My notes on Gitlab's Postgres schema design (2022) (shekhargulati.com)」這篇上 Hacker News 首頁 (看起來因為是在 pool 的關係，在第一頁卡很久...)，文章「My Notes on GitLab Postgres Schema Design」是作者在 2022 年七月的時候分析了 GitLab 的 structure.sql 的資料庫設計整理出來的心得 & 感想，裡面有不少東西，不過這邊想補充個背景知識 (姿勢？)：
RDBMS 在系統架構裡面，相較於其他的元件，是個很難 scale out 的東西 (i.e. 加更多機器得到更多效能)，所以遇過 scalability 問題的架構師，會很習慣避開在 RDBMS 上面跑各種功能，有其他方式可以做的就拆出去用容易 scale out 的工具來做，非不得已才上 RDBMS。
而就算要塞進 RDBMS 裡的資料，能省的還是要省，畢竟宣稱自動幫你處理資料庫 scale out 的技術 (像是 CockroachDB 與 TiDB) 其實沒想像中萬能，還是需要開發者改寫以前大惡搞的 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 的設計有他當時的限制以及想法，這些是外面的人看不到的，也就不好批評對錯。
Related
PostgreSQL 的 scale 建議
在 Hacker News Daily 上看到「Postgres scaling advice for 2021」這篇，講 PostgreSQL 要怎麼 scale，在 Hacker News 上也有對應的討論可以看：「Postgres scaling advice (cybertec-postgresql.com)」。 文章前面先提到分散式系統的複雜度會導致 RDBMS 上的一些假設失效，所以如果可以用單台機器暴力解，就儘量用單台機器來解 (scale up 的情境)，裡面就提到了一些「暴力可以解決很多問題」的說明，差不多就是前幾天提到的「Let's Encrypt 升級資料庫伺服器 (AMD YES？)」。 後面提到如果真的要放進分散式的 RDBMS (scale out 的情境)，怎麼設計資料結構會比較好。 這邊剛好也可以提一下，量夠大的時候要把 OLTP 與 OLAP 的應用分開，現在有很多 OLAP 資料庫可以選擇，同步的工具也很成熟了，通常效能會比在 OLTP 上面硬跑來的好。 最後提一下，文章裡面對於 transaction per second 可以拉很高，有些假設沒有明寫出來。這需要盡可能把 transaction 拆小，避免常常有 giant…
January 30, 2021In "Computer"
RDBMS 裡的各種 Lock 與 Isolation Level
來推薦其他人寫的文章 (雖然是在 Medium 上...)：「複習資料庫的 Isolation Level 與圖解五個常見的 Race Conditions」、「對於 MySQL Repeatable Read Isolation 常見的三個誤解」，另外再推薦英文維基百科上的「Snapshot isolation」條目。 兩篇文章都是中文 (另外一個是英文維基百科條目)，就不重複講了，這邊主要是拉條目的內容記錄起來，然後寫一些感想... SQL-92 定義 Isolation 的時候，技術還沒有這麼成熟，所以當時在訂的時候其實是以當時的技術背景設計 Isolation，所以當技術發展起來後，發生了一些 SQL-92 的定義沒那麼好用的情況： Unfortunately, the ANSI SQL-92 standard was written with a lock-based database in mind, and hence is rather vague when applied to MVCC systems. Berenson et al.…
June 26, 2019In "Computer"
Distributed Key-Value Database
這篇是因為在 PIXNET 內講了 n 次，決定寫成文字，至少之後新人進來可以說「就看這篇」，避免整套系統都需要重新講一次。 對了，補充一下，PIXNET 還是有缺人，參考「缺人找人」這篇的內容，如果有想問的細節，可以寫信問我。 資料庫 在 RDBMS 提供了很多而且很豐富的操作方式，但當資料量愈來愈大時，會遇到單台機器的網路頻寬有限以及空間有限。這時候一定得走向多台的架構。 Replication 最容易解決的情況是「讀取的 query 比寫入的 query 多」，可以用 database replication 解決，這也是 Web 1.0 網站常見的解法之一 (另外一種常見的解法是使用靜態檔案，或是 reverse proxy cache)，同步將資料複製到多台。 Memcached 接下來會發現當 slave 過多時會造成每台記憶體內重複 cache 相同的元素，也就是說，有二十台 slave，每台都有 SELECT * FROM `user` WHERE `name` = 'gslin' 的結果其實很浪費資源。不過這個問題可以用 memcached 或是 hash selection 解決。 Sharding 在…
July 25, 2009In "Computer"
Leave a Reply
Your email address will not be published. Required fields are marked *
Comment *
Name *
Email *
Website
Notify me of follow-up comments by email.
Notify me of new posts by email.
To respond on your own website, enter the URL of your response which should contain a link to this post's permalink URL. Your response will then appear (possibly after moderation) on this page. Want to update or remove your response? Update or delete your post and re-enter your post's URL again. (Learn More)
Post navigation
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK