Strategi Sharding dan Partisi MySQL untuk Menangani Pertumbuhan Data Triliunan Baris

Pukul 2 pagi, pagerDuty berdering nyaring di layar monitor. Metrik Prometheus menunjukkan grafik latensi API melonjak vertikal dari 45 milidetik menjadi lebih dari 4.000 milidetik, sementara koneksi MySQL di balik backend Node.js dan Go kami menumpuk seperti antrean sembako gratis. Tabel transaksi utama telah membengkak melampaui 1,8 triliun baris. Disk I/O tercekik di angka 100% utilisation, dan buffer pool InnoDB sebesar 128GB sudah megap-megap karena cache miss yang masif. Di ruang perang virtual, perdebatan sengit langsung meletus di antara para engineer: apakah kita harus segera mengimplementasikan Horizontal Sharding berbasis rentang waktu, atau beralih sepenuhnya ke pendekatan Partitioning tingkat lanjut berbasis hash langsung di dalam instance tunggal? Pertarungan ini bukan sekadar teori akademik, melahirkan sebuah arena Head-to-Head yang menguji batas ketahanan infrastruktur modern kita.

Mari kita bedah langsung performa kedua strategi ini melalui tabel perbandingan langsung di lapangan:

1. Pertarungan Filosofi: Dua Cara Pandang Berbeda dalam Memecahkan Masalah

Ketika menghadapi pertumbuhan data triliunan baris, tim backend sering terpecah menjadi dua kubu. Kubu pertama memuja MySQL Horizontal Sharding, sebuah pendekatan radikal yang memotong-motong data dan menyebarkannya ke beberapa instance database fisik atau virtual yang terpisah secara mandiri. Ini seperti memecah satu perpustakaan raksasa yang kacau menjadi sepuluh perpustakaan independen di berbagai kota, masing-masing dengan pustakawannya sendiri.

Di sisi lain, kubu kedua mempertahankan MySQL Table Partitioning, sebuah pendekatan yang lebih jinak secara arsitektural namun tetap agresif di tingkat penyimpanan. Data dibiarkan berada dalam satu instance MySQL yang sama, namun dipecah ke dalam partisi-partisi fisik (sub-tabel) berdasarkan fungsi range, list, atau hash. Ini seperti merapikan satu perpustakaan raksasa tadi ke dalam lemari-lemari besi terpisah berdasarkan dekade penerbitan.

Masing-masing kubu memiliki penganut fanatiknya sendiri. Namun, ketika beban transaksi per detik (TPS) menembus angka 50.000 request, filosofi mana yang benar-benar mampu menyelamatkan infrastruktur dari keruntuhan total? Jawabannya terletak pada bagaimana kita mendesain arsitektur di balik Nginx, PHP-FPM, hingga lapisan cache Redis yang menyangga sistem tersebut, yang akan kita buktikan dalam uji ketahanan berikutnya.

2. Ronde 1: Ergonomi Menulis Kode & Pengalaman Konfigurasi Sehari-hari

Bekerja dengan MySQL Horizontal Sharding di tengah tekanan deadline proyek adalah ujian mental tersendiri bagi seorang Database Engineer. Anda tidak bisa lagi menulis kueri SQL sembarangan. Bayangkan jika Anda menggunakan Vitess sebagai middleware sharding, setiap kueri wajib menyertakan sharding key (misalnya tenant_id atau user_id). Jika Anda lupa menyertakannya, kueri tersebut akan memicu scatter-gather query—sebuah bencana di mana middleware harus bertanya ke seluruh shard secara paralel, mengubah operasi yang seharusnya milidetik menjadi detik.

Berikut adalah contoh konfigurasi routing dasar menggunakan ProxySQL untuk mengarahkan traffic berdasarkan skema hash sharding:

-- Konfigurasi ProxySQL untuk Query Rules Sharding
INSERT INTO mysql_query_rules (rule_id, active, match_pattern, destination_hostgroup, comment)
VALUES (1, 1, '^SELECT.*FROM transactions WHERE user_id = ([0-9]+)', 10, 'Route user transactions to Shard Group 1');

-- Aturan fallback untuk scatter-gather jika sharding key tidak ditemukan
INSERT INTO mysql_query_rules (rule_id, active, match_pattern, destination_hostgroup, comment)
VALUES (2, 1, '^SELECT.*FROM transactions', 20, 'Fallback ke Global Scatter-Gather Shard');

LOAD MYSQL QUERY RULES TO RUNTIME;
SAVE MYSQL QUERY RULES TO DISK;

Sebaliknya, bekerja dengan MySQL Table Partitioning terasa jauh lebih ramah bagi pengembang aplikasi backend berbasis Go, Node.js, atau PHP. Anda tidak perlu mengubah satu baris pun kode ORM atau struktur kueri SQL yang ada. Cukup lakukan modifikasi pada skema DDL tabel Anda. MySQL secara otomatis melakukan partition pruning—mengabaikan partisi yang tidak relevan berdasarkan klausa WHERE.

Contoh implementasi DDL untuk range partitioning berdasarkan waktu pada tabel log transaksi yang masif:

CREATE TABLE transactions (
    id BIGINT NOT NULL,
    user_id BIGINT NOT NULL,
    amount DECIMAL(10,2) NOT NULL,
    created_at DATETIME NOT NULL,
    PRIMARY KEY (id, created_at)
) ENGINE=InnoDB
PARTITION BY RANGE (UNIX_TIMESTAMP(created_at)) (
    PARTITION p_2025_q1 VALUES LESS THAN (UNIX_TIMESTAMP('2025-04-01 00:00:00')),
    PARTITION p_2025_q2 VALUES LESS THAN (UNIX_TIMESTAMP('2025-07-01 00:00:00')),
    PARTITION p_2025_q3 VALUES LESS THAN (UNIX_TIMESTAMP('2025-10-01 00:00:00')),
    PARTITION p_future VALUES LESS THAN MAXVALUE
);

[!TIP] Saat merancang partisi berbasis waktu, pastikan Anda selalu menyertakan kolom partisi (created_at) di dalam Primary Key atau Unique Key tabel Anda. Kegagalan melakukan ini akan memaksa MySQL membuat local index yang berujung pada penurunan performa unique check secara drastis.

3. Ronde 2: Ketahanan di Bawah Gempuran Beban Ekstrem

Kami melakukan simulasi stress testing menggunakan k6 dan wrk untuk menguji batas maksimal kedua strategi ini. Skenario pengujian mensimulasikan 100.000 concurrent users yang melakukan insert data transaksi finansial secara masif bersamaan dengan read query analitik.

Begitu beban mencapai puncaknya, MySQL Table Partitioning mulai menunjukkan batasan fisiknya. Meskipun partition pruning bekerja sangat baik untuk kueri ber-indeks, operasi DDL pemeliharaan seperti penambahan partisi baru atau partition drop (untuk retensi data lama) mengunci metadata lock dalam waktu yang cukup lama. CPU pada server database tunggal tersebut melonjak hingga 98% karena mutex contention pada InnoDB buffer pool.

Sebaliknya, MySQL Horizontal Sharding dengan Vitess bertindak layaknya petarung kelas berat yang lincah. Karena beban tulis (write throughput) tersebar secara merata di 16 node server terpisah (masing-masing menangani sebagian kecil dari total triliunan baris), CPU utilization per node stabil di angka 40-50%. Latency rata-rata tetap terjaga di bawah 12 milidetik bahkan di tengah terjangan beban puncak.

[!WARNING] Hindari Hotspot Sharding. Jika Anda memilih sharding key yang buruk (misalnya berdasarkan status 'active' atau 'country' di negara kecil), salah satu shard akan menanggung 90% traffic, sementara shard lainnya menganggur. Ini akan memusnahkan seluruh keunggulan distribusi sharding.

4. Ronde 3: Konsumsi Sumber Daya Server & Efisiensi Biaya Nyata

Pertarungan arsitektur tidak akan lengkap tanpa menghitung anggaran infrastruktur bulanan. MySQL Table Partitioning jauh lebih unggul dalam hal efisiensi operasional skala menengah. Anda hanya perlu menyewa satu atau dua server database berkapasitas tinggi (fat instances dengan RAM 256GB dan NVMe SSD kencang). Biaya lisensi operasional, backup, dan replikasi master-slave sangat mudah dikelola oleh satu tim DBA kecil.

Namun, ketika data melompati angka beberapa terabyte, pendekatan server tunggal ini berubah menjadi bom waktu finansial. Membeli server dengan RAM 1TB+ harganya melompat secara eksponensial. Di sinilah MySQL Horizontal Sharding membalikkan keadaan. Anda dapat menggunakan banyak instance server berukuran sedang (misalnya instance cloud dengan 8 vCPU dan 32GB RAM) yang digabungkan dalam kluster Vitess. Pendekatan skala horisontal (scale-out) ini jauh lebih murah secara jangka panjang dan transparan terhadap batasan fisik perangkat keras.

5. Kapan Wajib Menggunakan MySQL Horizontal Sharding

Pilihlah MySQL Horizontal Sharding ketika ukuran total data Anda sudah melampaui kapasitas penyimpanan satu mesin fisik yang wajar (biasanya di atas 5 Terabyte), atau ketika jumlah Write Transactions Per Second (TPS) melampaui kemampuan satu instance MySQL (di atas 15.000 TPS). Sangat cocok untuk aplikasi skala global seperti e-commerce multinasional, platform SaaS multi-tenant berskala besar, atau sistem pembayaran fintech di mana isolasi data per pelanggan adalah harga mati.

6. Kapan Wajib Menggunakan MySQL Table Partitioning

Pilihlah MySQL Table Partitioning ketika masalah utama Anda bukanlah kapasitas tulis yang masif, melainkan manajemen siklus hidup data (data retention policy). Jika Anda memiliki tabel log, audit trail, atau data analitik historis yang ukurannya masih di bawah 2-3 Terabyte dan pola aksesnya berbasis rentang waktu (misalnya laporan bulanan atau pembersihan data lama secara berkala), Partition Pruning memberikan solusi yang elegan tanpa kerumitan mengelola kluster sharding yang kompleks.

7. Keputusan Akhir: Rekomendasi Jujur untuk Tim Engineering

Sebagai arsitek yang pernah terbakar oleh keputusan salah pilih teknologi di masa lalu, aturan emas saya sangat sederhana: Jangan pernah melakukan sharding kecuali Anda benar-benar terpaksa melakukannya. Kompleksitas operasional dari distributed database (seperti penanganan distributed transaction / 2PC, masalah cross-shard join, hingga kompleksitas backup dan migrasi skema) adalah beban operasional yang sangat mahal.

Jika data Anda masih di bawah beberapa terabyte dan bisa diatasi dengan optimasi indeks, caching Redis yang agresif, serta Table Partitioning, tempulah jalan tersebut terlebih dahulu. Namun, jika grafik bisnis Anda melaju tajam menuju triliunan baris dan batasan fisik server sudah di depan mata, bersiaplah merangkul MySQL Horizontal Sharding dengan arsitektur middleware yang matang. Pilihlah dengan bijak, ukur beban kerja Anda secara objektif, dan biarkan data yang berbicara.