UUID atau Auto Increment untuk Primary Key?

Beberapa orang atau perusahaan mungkin terbiasa menggunakan auto increment sebagai primary key untuk tabel database relasional. Selain praktis dan mudah digunakan, auto increment mempunyai performa yang cukup bagus.

Lalu, kenapa ada beberapa orang atau perusahaan yang menggunakan UUID/GUID sebagai primary key? Coba kita bandingkan kelebihan dan kekurangan auto increment dibanding UUID.

Data berikut berdasarkan artikel ini,

Garis hijau menggunakan UUID, garis merah menggunakan auto increment. Bisa kita lihat, ketika ada 15.000.000 data di database kita, butuh waktu 20 menit untuk bisa memasukkan 100.000 data baru jika kita menggunakan UUID. Sedangkan auto increment tetap stabil membutuhkan kurang dari 1 menit.

Studi Kasus

Jika UUID begitu lambat, kenapa ada yang mau menggunakan UUID? Jawabannya adalah karena UUID lebih mudah digunakan di sistem terdistribusi, saat semua endpoint bisa membuat data baru, sangat susah untuk mempunyai data yang tersinkronisasi dengan baik.

Kasus yang terjadi jika menggunakan auto increment adalah:

1. Perangkat A membuat data baru, dan server memberikan data auto increment.
2. Perangkat B membuat data baru, dan server memberikan data auto increment.

Perangkat A dan B tidak peduli dengan primary key yang dihasilkan oleh server, karena server mengatur supaya tidak ada primary key yang sama.

Sedangkan jika sistem kita harus support sistem offline:

1. Perangkat A membuat data di perangkatnya sendiri, primary key mencoba mengambil data primary key terakhir dari server, contoh 1001.
2. Perangkat B membuat data di perangkatnya sendiri, primary key mencoba mengambil data primary key terakhir dari server, contoh 1001.

Karena data tidak ada di server, maka server tetap memberikan 1001 sebagai data primary key terakhir.

3. Perangkat B mengirim data ke server, dengan primary key 1001.

4. Perangkat A mengirim data ke server, dengan primary key 1001 juga.

Kasus seperti ini yang membuat UUID digunakan, jika menggunakan UUID, maka alurnya seperti ini:

1. Perangkat A membuat data di perangkatnya sendiri, generate UUID random.
2. Perangkat B membuat data di perangkatnya sendiri, generate UUID random.
3. Perangkat B mengirim data ke server, karena UUID random tidak ada primary key yang sama.
4. Perangkat A mengirim data ke server, karena UUID random tidak ada primary key yang sama.

Catatan: UUID tidak 100% menjamin bahwa tidak akan ada data yang sama, tapi peluang adanya data yang sama sangat kecil.

Kesimpulan

Semua keputusan tetap ada di tangan kita, jika sistem yang kita buat tidak perlu menggunakan sistem yang terdistribusi atau kemampuan untuk menyimpan data secara offline, kita bisa menggunakan auto increment karena kecepatannya jauh lebih baik daripada UUID.

Jika sistem kita terdistribusi dan bisa bekerja secara offline, kita bisa menggunakan UUID, atau menggunakan generator ID lainnya yang disupport oleh database yang kita gunakan.