Catatan Saya tentang Desain Skema Postgres GitLab (2022)

Catatan Saya tentang Desain Skema Postgres GitLab

• Dengan mempelajari skema Postgres GitLab, saya ingin membandingkannya dengan skema yang saya rancang sendiri dan mempelajari praktik terbaik dari definisi skema GitLab.
• GitLab adalah platform DevOps open source, alternatif GitHub, dan dapat di-host sendiri.

Penggunaan Tipe Kunci Utama yang Tepat

• Saat database masih kecil, hal ini tidak terlalu terlihat, tetapi seiring pertumbuhan, kunci utama memengaruhi penggunaan ruang penyimpanan, kecepatan tulis, dan kecepatan baca.
• Dari 573 tabel, GitLab menggunakan tipe kunci utama bigserial pada 380 tabel, serial4 pada 170 tabel, dan 23 sisanya menggunakan kunci utama komposit.

Penggunaan ID Internal dan Eksternal

• Praktik yang baik adalah tidak mengekspos kunci utama ke dunia luar.
• GitLab menggunakan baik id (ID internal) maupun iid (ID eksternal) pada tabel seperti issues, ci_pipelines, deployments, dan epics.

Penggunaan tipe data text dan Constraint CHECK

• Skema GitLab menggunakan character varying(n) dan text, tetapi lebih sering menggunakan tipe text.
• Tipe text tidak memiliki batasan panjang, dan batasan panjangnya didefinisikan dengan menggunakan CHECK.

Konvensi Penamaan

• Semua tabel menggunakan bentuk jamak dan memberi ruang nama dengan menggunakan awalan nama modul.
• Nama tabel dan kolom mengikuti aturan snake_case.

Penggunaan Zona Waktu pada Timestamp

• GitLab menggunakan timestamp with timezone dan timestamp without timezone.
• Untuk pekerjaan sistem, GitLab menggunakan timestamp without timezone, dan untuk pekerjaan pengguna menggunakan timestamp with timezone.

Constraint Kunci Asing

• GitLab menggunakan constraint kunci asing pada sebagian besar tabel, tetapi pada beberapa tabel seperti audit_events, abuse_reports, web_hooks_logs, dan spam_logs, GitLab tidak menggunakannya.

Partisi pada Tabel Besar

• GitLab melakukan partisi pada tabel-tabel yang dapat membengkak agar performa query meningkat.

Dukungan Kasus Penggunaan Pencarian LIKE dengan Trigram dan gin_trgm_ops

• GitLab menggunakan indeks GIN (Generalized Inverted Index) untuk melakukan pencarian yang efisien.

Penggunaan jsonb

• Skema GitLab menggunakan tipe data jsonb di beberapa tabel.

Tip Lainnya

• Tabel yang dapat diperbarui menggunakan field audit seperti updated_at, sedangkan pada tabel log yang tidak dapat diperbarui field tersebut tidak digunakan.
• Enum disimpan sebagai smallint alih-alih character varying untuk menghemat ruang.

Pendapat GN⁺:

• Desain skema GitLab memberikan wawasan mendalam tentang desain basis data dan memuat pelajaran penting tentang optimasi skema untuk sistem berskala besar.
• Karena GitLab bersifat open source, keputusan desain skema semacam ini memberi contoh praktis yang dapat diadopsi pengembang lain untuk proyek mereka.
• Hal yang bisa dipelajari dari skema GitLab adalah bahwa pemilihan tipe data, strategi pengindeksan, partisi, dan penggunaan constraint kunci asing sangat memengaruhi kinerja dan pemeliharaan basis data sehingga perlu dipertimbangkan dengan cermat.

[GN⁺]

Komentar Hacker News

• Menyembunyikan primary key dari luar umumnya merupakan praktik yang baik. Ini terutama penting ketika memakai identifier integer atau bigint yang bertambah secara berurutan karena dapat ditebak.

  • Pendapat bahwa menyembunyikan primary key dari luar itu merupakan praktik yang baik diungkapkan. Terutama penting karena identifier berurutan yang meningkat secara otomatis sangat mudah ditebak.

• Sebagai contoh, GitHub pada tahun 2020 memiliki 128 juta repositori publik. Jika diasumsikan 20 issue per repositori, maka rentang serial bisa terlampaui. Selain itu, mengubah tipe kolom di tabel sangat mahal.

  • Penulis menyoroti bahwa dengan contoh jumlah repositori publik GitHub dan estimasi isu, rentang serial bisa terlampaui, serta menyinggung bahwa mengubah tipe tabel sangat mahal.

• Argumen bahwa ukuran penyimpanan kolom UUID tidak meyakinkan. Dengan 5 kolom lain dalam tabel, perbedaan antara 128 bit dan 64 bit tidaklah signifikan.

  • Disampaikan bahwa yang lebih penting daripada ukuran penyimpanan kolom UUID adalah masalah kinerja. UUIDv4 bersifat acak penuh dan tidak ideal untuk performa indeks, sehingga UUIDv7 mungkin solusi yang lebih baik.

• Klaim bahwa foreign key mahal sering diulang namun hampir tidak terverifikasi. Menggunakan database membutuhkan pengetahuan dan eksperimen dibandingkan membangun ulang sendiri, dan sering kali memberi hasil yang lebih baik.

  • Pertanyaan terhadap klaim umum bahwa foreign key itu mahal, sambil menekankan pentingnya memanfaatkan database dengan baik.

• Ingin tahu apakah ada yang menulis tentang perbedaan performa antara Gitlab dan GitHub.

  • Menyatakan rasa ingin tahu terhadap perbedaan performa antara Gitlab dan GitHub, dan merasakan waktu muat halaman Gitlab jauh lebih lambat dibanding GitHub.

• Saya penasaran untuk apa penambahan "I" pada variabel CI CI_PIPELINE_IID dan CI_MERGE_REQUEST_IID. Saya sempat menduga ini keputusan terkait database, dan tulisan ini mengonfirmasi hal itu.

  • Menyatakan keingintahuan tentang tujuan adanya tambahan "I" pada variabel CI, dan memahami bahwa ini berkaitan dengan keputusan yang diambil di database.

• Artikel ini sangat bermanfaat. Ingin tahu di mana saya bisa menemukan artikel lain yang serupa.

  • Merasa artikel ini sangat bermanfaat dan ingin mencari materi lain dengan topik yang mirip.

• Apakah aku satu-satunya yang merasa desain skema dan pengembangan itu ketinggalan zaman?

  • Merasa bahwa desain skema dan pengembangan terkesan kuno, terutama saat migrasi karena merasa adanya risiko kehilangan data. Juga mempertanyakan mengapa database/ORM tidak secara otomatis menangani ID eksternal dan ID internal.

• 1 gyeong setara dengan 1.000.000.000 jo.

  • Menyebut realitas pilihan antara integer 32-bit dan 64-bit, sambil menyoroti kebutuhan tipe integer 5 byte yang mampu mendukung kardinalitas sekitar 1 triliun.

• Menggunakan tipe UUID v4 native di Postgres membuat ukuran tabel membengkak 25% dan menurunkan kecepatan insert menjadi 25% dibanding bigserial.

  • Menanyakan perbedaan kinerja antara UUIDv4 dan bigserial, serta meminta penjelasan mengapa UUIDv4 menunjukkan performa yang lebih buruk.