Inti Masalah: Fragmentasi Indeks
UUID v4 menyebabkan bottleneck performa pada database relasional (seperti PostgreSQL, MySQL, atau SQL Server) karena sifatnya yang acak (random). Saat digunakan sebagai Primary Key dengan indeks B-Tree, nilai acak ini memaksa database melakukan penulisan data di lokasi yang tidak berurutan di seluruh halaman indeks (page splits). Hal ini menyebabkan fragmentasi indeks yang parah, penurunan rasio hit cache, dan peningkatan beban I/O disk secara signifikan dibandingkan dengan penggunaan integer auto-increment atau UUID yang berurutan.
Analisis Teknis: Mengapa UUID v4 Lambat?
Masalah utama terletak pada struktur data B-Tree. Ketika sebuah record baru dimasukkan dengan UUID v4, database tidak bisa sekadar menambahkan data di akhir tabel. Database harus mencari posisi yang tepat di tengah-tengah struktur indeks yang sudah ada. Jika halaman indeks penuh, database harus melakukan page split, memindahkan separuh data ke halaman baru, yang sangat memakan sumber daya CPU dan I/O.
| Aspek | UUID v4 (Random) | UUID v7 (Time-ordered) |
|---|---|---|
| Urutan | Acak (Non-sequential) | Berurutan (Time-based) |
| Performa Insert | Lambat (Banyak Page Split) | Cepat (Append-only) |
| Fragmentasi | Tinggi | Rendah |
| Kesesuaian DB | Buruk untuk PK | Sangat Baik untuk PK |
Dampak pada Performa Sistem
- I/O Overhead: Karena data tersebar, sistem harus membaca lebih banyak blok disk untuk mengambil data yang berdekatan secara logis.
- Cache Miss: Buffer pool database menjadi tidak efisien karena data yang sering diakses tidak tersimpan dalam blok memori yang berdekatan.
- Ukuran Indeks: UUID v4 berukuran 128-bit (16 byte), jauh lebih besar daripada integer 32-bit atau 64-bit, yang meningkatkan ukuran indeks secara keseluruhan dan mengurangi jumlah entri yang bisa masuk ke dalam RAM.
Solusi dan Rekomendasi Praktis
Jika Anda menghadapi bottleneck ini, berikut adalah langkah mitigasi yang disarankan:
1. Migrasi ke UUID v7
UUID v7 dirancang untuk menggabungkan keunggulan UUID (unik secara global) dengan keunggulan urutan waktu (time-ordered). Ini memungkinkan database melakukan penulisan secara berurutan (append-only), yang secara drastis mengurangi fragmentasi indeks.
2. Penggunaan ULID (Universally Unique Lexicographically Sortable Identifier)
ULID adalah alternatif yang dapat diurutkan secara leksikografis. ULID memiliki format 128-bit yang kompatibel dengan UUID namun dirancang agar tetap berurutan berdasarkan waktu, sehingga sangat ramah terhadap performa B-Tree.
3. Optimasi Tipe Data
Jika Anda harus tetap menggunakan UUID, simpanlah dalam format BINARY(16) atau UUID native (di PostgreSQL) alih-alih VARCHAR(36). Menyimpan UUID sebagai string teks (36 karakter) akan menggandakan ukuran penyimpanan dan memperlambat proses perbandingan (comparison) secara signifikan.
4. Strategi Clustering
Jika database mendukung, gunakan Clustered Index pada kolom yang memiliki urutan logis, bukan pada UUID v4 yang acak, untuk menjaga fisik data tetap teratur di disk.