- Tim database Figma merangkum perjalanan sembilan bulan melakukan sharding horizontal pada stack Postgres mereka dan bagaimana hal itu memungkinkan skalabilitas yang nyaris tak terbatas
Perjalanan sharding horizontal stack Postgres Figma
- Skala stack database Figma meningkat hampir 100x sejak 2020: Ini adalah masalah positif yang menandakan ekspansi bisnis, tetapi sekaligus menimbulkan tantangan teknis. Pada 2020, mereka menjalankan satu database Postgres pada instance fisik terbesar di AWS, dan pada akhir 2022 telah membangun arsitektur terdistribusi yang mencakup caching, read replica, dan banyak database yang dipartisi secara vertikal.
- Partisi vertikal: Dengan memisahkan kelompok tabel yang saling terkait ke partisi vertikalnya masing-masing, mereka memperoleh keuntungan scaling bertahap dan menjaga ruang gerak yang cukup untuk tetap mendahului pertumbuhan. Misalnya, kelompok tabel terkait seperti “file Figma” atau “organisasi” dipisahkan ke partisi vertikal masing-masing.
- Peralihan ke sharding horizontal: Mereka menyadari bahwa partisi vertikal saja memiliki batas. Setelah upaya scaling awal yang berfokus pada penurunan penggunaan CPU, mereka mulai memantau berbagai bottleneck di fleet yang lebih besar dan beragam. Mereka mengukur batas scaling database dari berbagai sisi, mulai dari CPU dan IO hingga ukuran tabel dan jumlah baris yang ditulis. Mengidentifikasi batas-batas ini penting untuk memprediksi seberapa besar ruang gerak yang tersedia per shard.
- Batas ukuran tabel: Beberapa tabel berkembang hingga menyimpan beberapa terabyte dan miliaran baris, mencapai ukuran yang sulit ditangani oleh satu database. Pada skala ini, reliabilitas terdampak selama operasi vacuum Postgres, yaitu pekerjaan latar belakang penting agar sistem tidak berhenti karena kehabisan transaction ID. Tabel dengan write paling tinggi juga akan segera melampaui IOPS maksimum yang didukung Amazon RDS. Ini bukan masalah yang bisa diselesaikan dengan partisi vertikal, sehingga dibutuhkan solusi yang lebih besar untuk mencegah database runtuh.
Membangun fondasi untuk memperluas skala
- Meminimalkan dampak pada developer: Menangani sebagian besar kompleksitas model data relasional agar developer aplikasi bisa tetap fokus membangun fitur baru yang menarik di Figma, alih-alih me-refactor sebagian besar codebase.
- Ekspansi yang transparan: Memastikan bahwa scaling di masa depan tidak memerlukan perubahan tambahan di layer aplikasi. Dengan kata lain, setelah pekerjaan awal untuk membuat tabel kompatibel selesai, ekspansi selanjutnya bisa berlangsung secara transparan bagi tim produk.
- Menghindari backfill yang mahal: Mereka menghindari solusi yang memerlukan backfill pada tabel-tabel besar Figma atau bahkan semua tabel. Mengingat ukuran tabel mereka dan batas throughput Postgres, backfill seperti itu akan memakan waktu berbulan-bulan.
- Berjalan secara bertahap: Mereka mengidentifikasi pendekatan yang bisa dirilis secara bertahap sambil mengurangi risiko perubahan besar di production. Ini menurunkan risiko gangguan besar dan membantu tim database menjaga reliabilitas Figma selama migrasi.
- Menghindari migrasi satu arah: Mereka mempertahankan kemampuan untuk rollback bahkan setelah proses physical sharding selesai. Ini mengurangi risiko terjebak dalam kondisi buruk ketika muncul variabel yang belum diketahui.
- Menjaga konsistensi data yang kuat: Mereka menghindari solusi kompleks yang sulit diimplementasikan tanpa downtime atau yang mengorbankan konsistensi, seperti double-writes. Mereka menginginkan solusi yang bisa diperluas dengan downtime nyaris nol.
- Memanfaatkan kekuatan yang dimiliki: Saat bekerja di bawah tekanan tenggat yang ketat, mereka lebih memilih pendekatan yang bisa dirilis sebertahap mungkin. Untuk tabel yang tumbuh paling cepat, mereka berusaha memanfaatkan keahlian dan teknologi yang sudah dimiliki.
Menjelajahi opsi yang memungkinkan
- Meninjau opsi database sharding horizontal: Ada berbagai solusi open source dan managed yang populer untuk database sharding horizontal yang kompatibel dengan Postgres atau MySQL. Mereka meninjau CockroachDB, TiDB, Spanner, dan Vitess dalam proses evaluasi. Namun, beralih ke database alternatif seperti itu akan membutuhkan migrasi data yang kompleks untuk menjamin konsistensi dan reliabilitas antara dua penyimpanan database yang berbeda.
- Memanfaatkan keahlian yang ada: Dalam beberapa tahun terakhir, mereka telah membangun banyak keahlian tentang cara menjalankan RDS Postgres secara stabil dan efisien. Jika bermigrasi, mereka harus membangun ulang keahlian domain itu dari nol. Mengingat laju pertumbuhan yang sangat agresif, waktu yang tersisa hanya beberapa bulan.
- Tidak memilih database NoSQL: Solusi scalable lain yang umum dipilih saat perusahaan bertumbuh adalah database NoSQL. Namun, mereka memiliki model data relasional yang sangat kompleks dan dibangun di atas arsitektur Postgres saat ini, sementara API NoSQL tidak menawarkan fleksibilitas seperti itu. Mereka ingin para engineer fokus merilis fitur hebat dan membangun produk baru, alih-alih menulis ulang hampir seluruh aplikasi backend; karena itu NoSQL bukan solusi yang layak.
- Mempertimbangkan membangun solusi sharding horizontal di atas infrastruktur RDS Postgres yang ada: Tidak masuk akal bagi tim kecil untuk mengimplementasikan ulang database relasional sharding horizontal generik secara internal. Itu akan membuat mereka harus bersaing dengan alat yang dibangun komunitas open source besar atau vendor database khusus. Namun, karena mereka dapat menyesuaikan sharding horizontal dengan arsitektur spesifik Figma, cukup dengan menyediakan set fitur yang jauh lebih kecil. Misalnya, mereka memutuskan untuk tidak mendukung transaksi lintas shard yang menjamin atomicity, karena ada cara untuk menangani kegagalan transaksi lintas shard. Mereka memilih strategi colocation yang meminimalkan perubahan yang diperlukan di layer aplikasi. Ini memungkinkan mereka mendukung subset Postgres yang kompatibel dengan mayoritas logika produk. Selain itu, mereka dapat dengan mudah mempertahankan kompatibilitas mundur antara Postgres yang sudah di-shard dan yang belum di-shard. Jika menghadapi variabel yang belum diketahui, mereka dapat dengan mudah rollback ke Postgres non-sharded.
Jalan menuju sharding horizontal
- Penerapan sharding horizontal: Sharding horizontal adalah proses membagi satu tabel atau kelompok tabel ke beberapa instance database fisik. Melalui proses ini, tabel yang di-shard secara horizontal pada layer aplikasi dapat mendukung berapa pun jumlah shard pada layer fisik. Mereka selalu dapat melakukan ekspansi lebih lanjut hanya dengan menjalankan pemisahan shard fisik, dan pekerjaan ini berlangsung transparan di latar belakang dengan downtime minimal dan tanpa perubahan di level aplikasi. Kemampuan ini memungkinkan Figma untuk tetap unggul terhadap bottleneck scaling database yang tersisa, dan menghapus salah satu tantangan scaling besar terakhir mereka. Jika partisi vertikal memungkinkan mereka berakselerasi hingga kecepatan jalan tol, sharding horizontal menghilangkan batas kecepatannya dan memungkinkan mereka terbang.
- Kompleksitas sharding horizontal: Sharding horizontal satu tingkat lebih kompleks daripada upaya scaling sebelumnya. Ketika tabel dibagi di beberapa database fisik, banyak properti reliabilitas dan konsistensi yang biasanya dianggap wajar dalam database SQL ber-ACID menjadi hilang. Misalnya, kueri SQL tertentu bisa menjadi tidak efisien atau mustahil untuk didukung, dan kode aplikasi harus diperbarui agar dapat memberikan informasi yang cukup untuk merutekan kueri seefisien mungkin ke shard yang benar. Perubahan skema harus dikoordinasikan agar semua shard tetap sinkron, dan foreign key serta indeks unik global tidak lagi bisa ditegakkan oleh Postgres. Transaksi juga bisa membentang di beberapa shard, sehingga tidak lagi bisa dipaksakan oleh Postgres. Kini, sebagian operasi write ke beberapa database dapat berhasil sementara yang lain gagal. Logika produk harus dirancang agar tangguh terhadap “kegagalan commit parsial” semacam ini (misalnya, bayangkan saat memindahkan tim antar dua organisasi, lalu setengah datanya hilang!).
- Upaya multi-tahun menuju sharding horizontal: Mereka tahu bahwa mencapai sharding horizontal penuh akan menjadi upaya bertahun-tahun. Mereka harus memberikan nilai bertahap sambil mengurangi risiko proyek sebanyak mungkin. Tujuan pertama adalah men-shard tabel yang relatif sederhana tetapi memiliki trafik sangat tinggi di production secepat mungkin. Ini tidak hanya membuktikan kelayakan sharding horizontal, tetapi juga memperpanjang ruang gerak pada database yang menanggung beban paling tinggi. Setelah itu, mereka bisa membangun fitur tambahan sambil men-shard kelompok tabel yang lebih kompleks. Bahkan set fitur paling sederhana pun tetap merupakan pekerjaan yang besar. Dari awal hingga akhir, tim mereka membutuhkan kira-kira sembilan bulan untuk men-shard tabel pertama.
Pendekatan unik kami
- Colocation (Colos): Melakukan sharding horizontal pada grup tabel yang saling terkait ke dalam colocation yang berbagi shard key dan layout sharding fisik yang sama (disebut dengan akrab sebagai “colo”). Ini memberikan abstraksi yang ramah bagi developer untuk berinteraksi dengan tabel yang di-shard secara horizontal.
- Sharding logis: Memisahkan konsep “sharding logis” di lapisan aplikasi dari “sharding fisik” di lapisan Postgres. Memanfaatkan view untuk melakukan peluncuran sharding logis yang lebih aman dan lebih murah sebelum menjalankan failover fisik terdistribusi yang lebih berisiko.
- Mesin kueri DBProxy: Membangun layanan DBProxy yang mencegat kueri SQL yang dibuat di lapisan aplikasi dan merutekan kueri secara dinamis ke berbagai database Postgres. DBProxy mencakup mesin kueri yang dapat mem-parsing dan mengeksekusi kueri sharding horizontal yang kompleks. Melalui DBProxy, mereka dapat mengimplementasikan fitur seperti load balancing dinamis dan request hedging.
- Kesiapan aplikasi bayangan: Menambahkan framework “kesiapan aplikasi bayangan” yang dapat memprediksi bagaimana traffic produksi nyata akan berperilaku di bawah berbagai shard key potensial. Ini memberikan gambaran yang jelas bagi tim produk tentang kebutuhan untuk me-refactor atau menghapus logika aplikasi agar aplikasi siap untuk sharding horizontal.
- Replikasi logis penuh: Tidak perlu mengimplementasikan “replikasi logis terfilter” yang hanya menyalin subset data ke tiap shard. Sebagai gantinya, seluruh set data disalin, lalu hanya subset data yang termasuk dalam shard tertentu yang diizinkan untuk dibaca/ditulis.
Implementasi sharding
- Pentingnya memilih shard key: Salah satu keputusan terpenting dalam sharding horizontal adalah shard key apa yang akan digunakan. Sharding horizontal menambahkan berbagai batasan model data yang berpusat pada shard key. Misalnya, sebagian besar kueri harus menyertakan shard key agar permintaan dapat dirutekan ke shard yang benar. Beberapa constraint database tertentu, seperti foreign key, hanya berfungsi ketika foreign key tersebut adalah sharding key. Shard key juga harus mendistribusikan data secara merata ke semua shard untuk menghindari hotspot yang dapat menimbulkan masalah keandalan atau memengaruhi skalabilitas.
- Pendekatan yang disesuaikan dengan model data Figma: Figma berjalan di browser, dan banyak pengguna dapat berkolaborasi pada file Figma yang sama secara bersamaan. Ini berarti semuanya ditopang oleh model data relasional yang relatif kompleks, yang menangkap metadata file, metadata organisasi, komentar, versi file, dan lainnya. Karena tidak ada satu kandidat yang benar-benar bagus dalam model data yang ada, mereka sempat mempertimbangkan penggunaan shard key yang sama untuk semua tabel, tetapi itu akan mengharuskan pembuatan composite key untuk menambahkan shard key terpadu, penambahan kolom ke semua skema tabel, menjalankan backfill yang mahal untuk mengisinya, lalu me-refactor logika produk secara signifikan. Sebagai gantinya, mereka menyesuaikan pendekatan dengan model data unik Figma dan memilih sejumlah kecil shard key seperti UserID, FileID, dan OrgID. Hampir semua tabel di Figma dapat di-shard menggunakan salah satu key ini.
- Pengenalan Colocation (Colos): Mereka memperkenalkan konsep colocation yang memberikan abstraksi yang ramah bagi developer produk. Tabel di dalam satu colo mendukung join lintas tabel dan transaksi penuh selama dibatasi pada satu shard key. Sebagian besar kode aplikasi sudah berinteraksi dengan database dengan cara ini, sehingga pekerjaan developer aplikasi untuk menyesuaikan tabel agar siap untuk sharding horizontal menjadi minimal.
- Menjamin pemerataan distribusi data: Setelah shard key dipilih, data harus dipastikan terdistribusi secara merata ke semua database backend. Sayangnya, banyak shard key yang dipilih menggunakan ID auto-increment atau ID dengan prefiks timestamp Snowflake. Ini akan menyebabkan hotspot yang signifikan, di mana sebagian besar data terkumpul pada satu shard saja. Mereka sempat mengeksplorasi migrasi ke ID yang lebih acak, tetapi itu memerlukan migrasi data yang mahal dan memakan waktu. Sebagai gantinya, mereka memutuskan menggunakan hash dari shard key untuk routing. Jika memilih fungsi hash yang cukup acak, distribusi data yang merata dapat dijamin. Salah satu kekurangannya adalah range scan pada shard key menjadi kurang efisien, karena key yang berurutan akan di-hash ke shard database yang berbeda. Namun, pola kueri ini tidak umum di codebase mereka, sehingga ini merupakan kompromi yang bisa diterima.
Solusi “logis”
- Mengurangi risiko peluncuran sharding horizontal: Untuk mengurangi risiko peluncuran sharding horizontal, mereka ingin memisahkan proses fisik menjalankan split shard dari proses menyiapkan tabel di lapisan aplikasi. Untuk itu, mereka memisahkan “sharding logis” dan “sharding fisik”. Dengan begitu, dua bagian migrasi ini bisa dipisahkan, diimplementasikan secara independen, dan risikonya dikurangi. Sharding logis memberikan keyakinan pada serving stack melalui peluncuran berbasis persentase yang berisiko rendah. Saat bug ditemukan, rollback sharding logis hanya berupa perubahan konfigurasi sederhana. Rollback pekerjaan shard fisik memang mungkin, tetapi memerlukan koordinasi yang lebih kompleks untuk menjamin konsistensi data.
- Perilaku setelah sharding logis: Setelah tabel di-shard secara logis, semua operasi baca dan tulis sudah berjalan seolah-olah tabel tersebut benar-benar di-shard secara horizontal. Dari sisi keandalan, latensi, dan konsistensi, sistem tampak seperti sudah di-shard secara horizontal, tetapi data masih secara fisik berada pada satu host database. Setelah mereka yakin bahwa sharding logis berjalan sesuai harapan, barulah pekerjaan sharding fisik dilakukan. Ini adalah proses menyalin data dari satu database ke beberapa backend yang telah di-shard, lalu merutekan ulang traffic baca dan tulis melalui database baru.
Mesin kueri yang mampu melakukannya
- Desain ulang stack backend untuk mendukung sharding horizontal: Awalnya, layanan aplikasi berkomunikasi langsung dengan PGBouncer, lapisan connection pooling. Namun, sharding horizontal membutuhkan parsing, perencanaan, dan eksekusi kueri yang jauh lebih kompleks. Untuk mendukung ini, mereka membangun layanan golang baru bernama DBProxy. DBProxy berada di antara lapisan aplikasi dan PGBouncer. Di dalamnya ada logika untuk load balancing, observability yang lebih baik, dukungan transaksi, pengelolaan topologi database, dan mesin kueri ringan.
- Komponen inti mesin kueri:
- Query parser: Membaca SQL yang dikirim dari aplikasi dan mengubahnya menjadi abstract syntax tree (AST).
- Logical planner: Mem-parsing AST dan mengekstrak tipe kueri (insert, update, dan sebagainya) serta logical shard ID dari rencana kueri.
- Physical planner: Memetakan kueri dari logical shard ID ke database fisik. Ia menulis ulang kueri agar dapat dieksekusi pada shard fisik yang sesuai.
- Pendekatan “scatter-gather”: Bekerja seperti permainan petak umpet di seluruh database: mengirim kueri ke semua shard (scatter), lalu mengumpulkan jawaban dari masing-masing shard (gather). Menarik, tetapi jika terlalu sering digunakan untuk kueri kompleks, database bisa terasa lambat seperti siput.
- Implementasi kueri di dunia yang di-shard secara horizontal: Kueri single-shard difilter dengan satu shard key. Mesin kueri hanya perlu mengekstrak shard key dan merutekan kueri ke database fisik yang sesuai. Kompleksitas eksekusi kueri “diturunkan” ke Postgres. Namun, jika shard key tidak ada dalam kueri, mesin kueri harus melakukan “scatter-gather” yang lebih kompleks. Dalam kasus ini, kueri harus di-fan-out ke semua shard (tahap scatter), lalu hasilnya harus diagregasi (tahap gather).
- Penyederhanaan kompatibilitas SQL: Jika layanan DBProxy mendukung kompatibilitas SQL penuh, ia akan terlihat sangat mirip dengan mesin kueri database Postgres itu sendiri. Mereka ingin menyederhanakan API untuk meminimalkan kompleksitas DBProxy dan mengurangi pekerjaan developer aplikasi yang harus menulis ulang kueri yang tidak didukung. Untuk menentukan subset yang tepat, mereka membangun framework “shadow planning” yang dapat mendefinisikan skema sharding potensial sebuah tabel dan menjalankan tahap perencanaan logis di atas traffic produksi secara real-time. Kueri beserta rencana kueri terkait dapat dicatat ke database Snowflake untuk analisis offline. Dari data ini, mereka memilih bahasa kueri yang mendukung 90% kueri paling umum sekaligus menghindari kompleksitas terburuk pada mesin kueri. Misalnya, semua range scan dan point query diizinkan, tetapi join hanya diizinkan ketika dilakukan pada shard key antara dua tabel dalam colo yang sama.
Prospek ke depan
- Enkapsulasi shard logis: Tim perlu memutuskan bagaimana shard logis akan dienkapsulasi. Mereka sempat mengeksplorasi pemisahan data menggunakan database Postgres terpisah atau skema Postgres. Sayangnya, pendekatan ini memerlukan perubahan data fisik saat melakukan sharding secara logis, yang sama rumitnya dengan pemecahan shard fisik.
- Representasi shard melalui view Postgres: Sebagai gantinya, mereka memutuskan untuk merepresentasikan shard sebagai view Postgres. Untuk setiap tabel, dapat dibuat beberapa view, yang masing-masing mewakili subset data untuk shard tertentu. Bentuknya seperti ini:
CREATE VIEW table_shard1 AS SELECT * FROM table WHERE hash(shard_key) >= min_shard_range AND hash(shard_key) < max_shard_range). Semua operasi baca dan tulis dilakukan melalui view ini.
- Membuat view yang sudah di-shard di atas database fisik existing yang belum di-shard: Ini memungkinkan mereka melakukan sharding secara logis sebelum menjalankan operasi reshard fisik yang berisiko. Setiap view diakses melalui layanan connection pooler khusus yang sudah di-shard. Connection pooler tetap menunjuk ke instance fisik yang belum di-shard, sehingga sistem tampak seperti sudah di-shard. Melalui feature flag di query engine, peluncuran baca/tulis yang di-shard bisa dilakukan bertahap untuk menurunkan risiko, dan rollback kapan saja dalam hitungan detik dengan mengarahkan ulang traffic kembali ke tabel utama. Saat reshard pertama dijalankan, mereka sudah memiliki keyakinan terhadap keamanan topologi yang di-shard.
- Risiko bergantung pada view: View menambah overhead performa, dan dalam beberapa kasus dapat secara mendasar mengubah cara Postgres query planner mengoptimalkan query. Untuk memvalidasi pendekatan ini, mereka mengumpulkan korpus query produksi yang sudah disterilkan lalu menjalankan load test dengan dan tanpa view. Mereka memastikan bahwa pada sebagian besar kasus, view hanya menambah overhead performa yang minimal, dan bahkan pada kasus terburuk pun kurang dari 10%. Mereka juga membangun framework shadow read yang mengirim seluruh traffic baca real-time melalui view dan membandingkan performa serta akurasi query dengan dan tanpa view. Hasilnya menegaskan bahwa view adalah solusi yang layak dengan dampak performa yang minimal.
Menyelesaikan masalah topologi
- Pemahaman DBProxy terhadap topologi untuk routing query: Perlu memahami topologi tabel dan database fisik. Karena konsep sharding logis dan fisik dipisahkan, dibutuhkan cara untuk merepresentasikan abstraksi ini di dalam topologi.
- Pemetaan tabel dan shard key: Diperlukan cara untuk memetakan tabel
users ke shard key user_id, serta memetakan ID shard logis (123) ke database logis dan fisik yang sesuai.
- Partisi vertikal dan ketergantungan pada file konfigurasi hardcoded: Pada partisi vertikal, mereka mengandalkan file konfigurasi hardcoded sederhana yang memetakan tabel ke partisi terkait. Peralihan ke sharding horizontal memerlukan sistem yang lebih kompleks.
- Perubahan topologi yang dinamis dan kebutuhan DBProxy untuk memperbarui status dengan cepat: Selama pemecahan shard, topologi berubah secara dinamis, sehingga DBProxy perlu memperbarui statusnya dengan cepat agar tidak mengarahkan request ke database yang salah.
- Backward compatibility untuk perubahan topologi: Semua perubahan topologi harus tetap backward compatible, tanpa perubahan pada jalur kritis situs.
- Membangun topologi database yang merangkum metadata sharding horizontal yang kompleks: Mereka membangun topologi database yang merangkum metadata sharding horizontal yang kompleks dan menyediakan pembaruan real-time dalam waktu kurang dari 1 detik.
- Pemisahan topologi logis dan fisik untuk menyederhanakan pengelolaan database: Ini mengurangi biaya dan kompleksitas dengan mempertahankan topologi logis yang sama dengan produksi di lingkungan nonproduksi, sambil mengurangi jumlah database fisik.
- Menegakkan invarian dalam topologi melalui library topologi: Misalnya, setiap ID shard harus dipetakan ke tepat satu database fisik, sehingga akurasi sistem tetap terjaga saat membangun sharding horizontal.
Operasi sharding fisik
- Tahap terakhir setelah tabel siap untuk di-shard: Yaitu failover fisik dari database yang belum di-shard ke database yang sudah di-shard. Mereka dapat menggunakan kembali banyak logika yang sama untuk sharding horizontal, tetapi ada beberapa perbedaan penting, seperti perpindahan dari database 1 banding 1 menjadi 1 banding N.
- Perlu meningkatkan ketahanan proses failover: Proses failover harus dibuat lebih tangguh untuk menghadapi mode kegagalan baru, di mana operasi sharding mungkin hanya berhasil pada sebagian database.
- Sebagian besar risiko sudah diatasi selama partisi vertikal: Karena banyak risiko sudah lebih dulu diminimalkan selama partisi vertikal, mereka bisa melangkah ke operasi sharding fisik pertama jauh lebih cepat daripada yang seharusnya mungkin.
Posisi saat ini dalam perjalanan sharding horizontal
- Investasi multi-tahun pada sharding horizontal: Setelah menyadari perlunya investasi multi-tahun pada sharding horizontal demi skalabilitas masa depan Figma, mereka merilis tabel sharding horizontal pertama pada September 2023.
- Eksekusi failover yang sukses: Mereka berhasil melakukan failover dengan hanya 10 detik partial availability sementara pada database primer dan tanpa dampak availability pada replica. Setelah sharding, tidak ada regresi pada latensi maupun availability.
- Penanganan shard yang kompleks: Mereka telah menangani shard yang relatif sederhana pada database dengan write rate tertinggi. Tahun ini, mereka berencana men-shard database yang jauh lebih kompleks, dengan puluhan tabel dan ribuan titik pemanggilan kode.
- Kebutuhan sharding horizontal untuk semua tabel di Figma: Ini diperlukan untuk menghapus batas skalabilitas terakhir dan benar-benar siap menghadapi lonjakan besar. Dunia yang sepenuhnya di-shard secara horizontal menawarkan berbagai manfaat seperti peningkatan reliabilitas, pengurangan biaya, dan kecepatan developer yang lebih tinggi.
- Masalah yang masih harus diselesaikan:
- Mendukung pembaruan skema yang di-shard secara horizontal
- Menghasilkan ID unik global untuk primary key yang di-shard secara horizontal
- Transaksi atomik lintas shard untuk use case inti bisnis
- Indeks unik global yang terdistribusi (saat ini hanya didukung pada indeks yang menyertakan shard key)
- Meningkatkan kecepatan developer dengan model ORM yang kompatibel mulus dengan sharding horizontal
- Operasi reshard yang sepenuhnya otomatis, sehingga pemecahan shard bisa dijalankan cukup dengan klik tombol
- Evaluasi ulang pendekatan sharding horizontal existing berbasis RDS: Perjalanan ini dimulai 18 bulan lalu di bawah tekanan timeline yang sangat ketat. Seiring perkembangan dan kematangan NewSQL store, mereka kini punya cukup ruang untuk mengevaluasi ulang trade-off antara mempertahankan jalur saat ini atau beralih ke solusi open source maupun managed.
- Perkembangan menarik dalam perjalanan sharding horizontal: Masih ada tantangan yang baru mulai mereka hadapi. Mereka menantikan analisis yang lebih mendalam tentang berbagai bagian dari stack sharding horizontal mereka. Jika tertarik pada proyek seperti ini, mereka mengundang Anda untuk menghubungi mereka. Mereka sedang merekrut.
Opini GN⁺
- Tim database Figma berupaya mengatasi batas skalabilitas database melalui sharding horizontal, dan ini merupakan langkah penting untuk mempertahankan pertumbuhan serta performa tool kolaborasi berbasis cloud.
- Sharding horizontal menghadirkan tantangan baru dalam pengelolaan data dan optimasi query, yang menuntut pengetahuan dan keterampilan baru dari administrator database maupun developer.
- Sharding horizontal secara signifikan meningkatkan skalabilitas database, tetapi juga membutuhkan solusi baru untuk penanganan query yang kompleks dan menjaga konsistensi data.
- Salah satu proyek open source dengan fungsi serupa adalah CitusDB, yang menyediakan kemampuan untuk menskalakan database Postgres secara horizontal.
- Saat mengadopsi teknologi sharding horizontal, perlu mempertimbangkan kompleksitas model data, performa query, fleksibilitas sistem, dan aspek pemeliharaan, yang pada akhirnya berarti mencari keseimbangan antara skalabilitas database dan kemudahan pengelolaan.
1 komentar
Opini Hacker News
Tabel berukuran sangat besar dan batas IOPS RDS
Hasil sharding dan biaya
Waktu dan biaya yang dibutuhkan untuk sharding
Perbandingan biaya dengan YugabyteDB
Usulan pemisahan database per pelanggan
Membangun versi PG yang mirip Vitess milik MySQL
Pertimbangan terhadap FoundationDB
Pendekatan yang memperlakukan sharding seperti hack
Pertanyaan tentang tidak digunakannya ekstensi Citus
Kemungkinan penggunaan Aurora Limitless
Pemahaman tentang database NoSQL
jsonb, tetapi karena mereka sudah memiliki model data yang baik, kebutuhan untuk banyak memakainya tidak besar.Kematangan sharding dan pertimbangan solusi NewSQL
Teknologi Spanner milik Google dan evaluasi Figma