Atomicity dalam Database: Tulang Punggung Transaksi yang Andal

Atomicity adalah konsep inti dalam sistem database. Ini berarti suatu transaksi harus sepenuhnya berhasil atau tidak dijalankan sama sekali. Jika ada yang gagal di tengah jalan, semuanya dibatalkan seolah tidak pernah terjadi.

Mengapa ini sangat penting, Anda mungkin bertanya? Bayangkan mentransfer uang dari satu rekening bank ke rekening lain. Anda menekan "Send", aplikasi memuat sebentar, lalu terjadi sesuatu yang salah. Uang hilang dari rekening Anda, tetapi tidak pernah masuk ke rekening tujuan. Sekarang uang itu…lenyap. Skenario inilah yang dirancang untuk dicegah oleh atomicity.

Anda mungkin pernah mendengar tentang ACID. Ini adalah kumpulan empat properti kunci yang digunakan database untuk memastikan semuanya tidak berantakan. Atomicity adalah yang pertama dalam daftar itu, dan untuk alasan yang bagus: tanpanya, yang lain (Consistency, Isolation, dan Durability) tidak terlalu berarti.

Dalam artikel ini, kita akan membahas apa arti atomicity, bagaimana cara kerjanya, dan mengapa hal ini begitu krusial dalam sistem sehari-hari seperti perbankan dan e-commerce. Kita juga akan melihat bagaimana berbagai database menerapkannya, dan bagaimana Anda dapat merancang sistem atomik yang dapat menangani keadaan saat hal-hal tak terhindarkan berjalan salah.

Apa Itu Atomicity?

Atomicity berarti bahwa sebuah transaksi dalam database tidak dapat dibagi. Transaksi dijalankan hingga selesai, dengan setiap langkah berjalan sesuai rencana, atau tidak dijalankan sama sekali. Tidak ada jalan tengah. Tidak ada pembaruan setengah jadi, tidak ada data yang tersimpan sebagian, tidak ada kondisi aneh di mana sebagian berhasil dan sebagian tidak.

Atomicity dalam DBMS. Sumber: Arpit Bhayani

Jika satu bagian dari transaksi gagal, keseluruhan transaksi dibatalkan seolah tidak pernah terjadi. Inilah yang membuat atomicity menjadi pengaman yang sangat kuat. Tanpanya, Anda terus-menerus berisiko meninggalkan data dalam keadaan rusak atau tidak konsisten, terutama dalam sistem yang memerlukan beberapa hal terjadi secara berurutan.

Mari kita lihat beberapa skenario dunia nyata di mana atomicity membuat (atau merusak) sistem:

Contoh 1: Transfer bank

Misalnya Anda mentransfer $100 dari rekening giro ke rekening tabungan Anda.

Transaksi memiliki dua bagian:

1. Mengurangi $100 dari rekening giro
2. Menambahkan $100 ke rekening tabungan

Tanpa atomicity, ada kemungkinan langkah pertama selesai dan langkah kedua gagal, mungkin karena gangguan jaringan atau server crash. Selamat, uang Anda baru saja lenyap ke dalam kehampaan. Atomicity memastikan bahwa kedua langkah tersebut berhasil, atau tidak sama sekali. Jika terjadi kesalahan, $100 itu tetap persis di tempat semula.

Contoh 2: Inventaris dan pemrosesan pesanan

Anda membeli piringan hitam edisi terbatas terakhir secara online. Sistem perlu:

1. Mengurangi inventaris sebanyak satu
2. Mengonfirmasi pesanan Anda

Tanpa atomicity, sistem mungkin mengurangi inventaris, tetapi crash sebelum pesanan dikonfirmasi. Kini toko mengira stok habis, tetapi tidak ada yang mendapatkan piringan tersebut. 

Seringnya hal ini terjadi saat saya berbelanja online sungguh mencengangkan. Saya biasanya menutup tab dan mendoakan para insinyurnya beruntung, tetapi kemungkinan besar saya tidak akan mencoba berbelanja di situs itu lagi. Siapa yang tahu bagaimana mereka menangani data pribadi saya jika fungsionalitas pembelian inti mereka saja tidak andal?

Contoh 3: Sistem pemesanan penerbangan

Memesan penerbangan biasanya bukan sekadar memilih kursi. Sistem perlu:

1. Menetapkan kursi
2. Memperbarui ketersediaan kursi
3. Menagih kartu Anda

Jika langkah kedua gagal dan langkah ketiga berhasil, Anda membayar untuk kursi yang tidak ada. Jelas tidak ideal.

Contoh 4: Sinkronisasi database dan indeks pencarian

Misalkan aplikasi Anda memperbarui deskripsi produk di database utama. Pada saat yang sama, indeks pencarian juga harus diperbarui agar pengguna dapat menemukan produk dengan deskripsi baru.

Jika pembaruan database berhasil tetapi pembaruan indeks gagal, pengguna akan melihat hasil yang kedaluwarsa, atau bahkan tidak dapat menemukan produknya sama sekali.

Mengapa Atomicity Penting

Jadi, mengapa atomicity sangat penting? 

Ada begitu banyak alasan transaksi dapat terputus. Bisa karena listrik padam, server crash, atau tenggat waktu jaringan habis di tengah proses. Jika atomicity tidak ditegakkan, transaksi itu mungkin hanya selesai sebagian. Sekarang database Anda berada dalam keadaan canggung: beberapa perubahan masuk, yang lain tidak, dan Anda tidak punya cara mudah untuk membenahi kekacauan tersebut.

Di sinilah bug data menjadi sangat licik. Pengguna mungkin tidak langsung menyadari ada yang salah, tetapi seiring waktu semuanya mulai tidak masuk akal. Analitik Anda terlihat aneh, pesanan menghilang, saldo akun tidak cocok, atau tiket dukungan melonjak karena orang tidak dapat menemukan apa yang baru saja mereka simpan.

Atomicity mencegah semua itu dengan memastikan bahwa:

• Sebuah transaksi terjadi sepenuhnya atau tidak terjadi sama sekali
• Sistem dapat pulih dengan bersih bahkan jika sesuatu gagal di tengah jalan
• Data Anda tetap konsisten, bahkan selama crash atau akses bersamaan

Atomicity juga sangat terkait dengan properti ACID lainnya. Tanpa atomicity, consistency akan runtuh karena Anda tidak dapat menegakkan aturan jika separuh data hilang, dan isolation rusak, karena pengguna lain mungkin melihat data parsial dari transaksi yang belum selesai.

Ini sangat penting jika Anda berurusan dengan:

• Transaksi multi-langkah, di mana satu tindakan bergantung pada tindakan lainnya.
• Pembaruan multi-baris atau multi-tabel, di mana data terkait perlu tetap sinkron.
• Sistem terdistribusi, di mana bagian transaksi terjadi pada mesin atau database yang berbeda.

Cara Kerja Atomicity dalam Praktik

Di balik kesederhanaan "semua atau tidak sama sekali" terdapat sistem yang mengejutkan rumit. Saat database mengeksekusi transaksi, ia secara aktif melacak, menyiapkan, dan melindungi setiap langkah.

Berikut gambaran tingkat tinggi tentang apa yang terjadi:

Siklus hidup transaksi

1. Mulai transaksi: Sistem menandai awal transaksi, mengisolasi perubahan yang akan datang dari sisa database.
2. Jalankan operasi: Ini mencakup semua insert, update, delete Anda, atau apa pun "sihir" SQL yang Anda lakukan.
3. Commit atau rollback: Jika setiap operasi berhasil, transaksi di-commit, dan perubahan menjadi permanen. Jika ada yang gagal, seluruh transaksi di-rollback.

Logging dan journaling

Untuk memastikan atomicity, database menulis log tentang apa yang akan terjadi sebelum benar-benar terjadi. Log ini disimpan secara terpisah dan bertindak sebagai rencana cadangan.

Jika sistem crash saat transaksi berlangsung, sistem dapat merujuk ke log dan membatalkan perubahan yang belum selesai, menerapkan kembali yang sudah selesai dengan aman, dan memulihkan database ke keadaan yang bersih dan konsisten.

Pendekatan ini kadang disebut Write-Ahead Logging (WAL) atau journaling, dan merupakan bagian kunci dari pemulihan saat crash.

Rollback dan pemulihan

Ketika sebuah transaksi gagal, database tidak sekadar menyerah, melainkan dengan cermat membatalkan perubahan. Baris yang dimodifikasi dikembalikan ke keadaan semula, semua lock yang dipegang oleh transaksi dilepas, dan log digunakan untuk membalikkan pembaruan parsial.

Sekarang, dalam kasus crash, rutinitas pemulihan dijalankan saat restart. Mereka memutar ulang log, menyelesaikan transaksi yang belum selesai, dan memastikan database melanjutkan tepat dari titik terakhir, tanpa keadaan setengah jadi yang aneh.

Kinerja vs. atomicity

Tidak mengherankan, semua ini ada biayanya. Atomicity memperkenalkan:

• Locking: Untuk mencegah pihak lain memodifikasi data yang sama saat transaksi berjalan
• Overhead: Dari mekanisme logging dan rollback
• Deadlock: Saat beberapa transaksi saling menunggu untuk melepaskan sumber daya

Inilah sebabnya Anda perlu merancang transaksi besar dengan hati-hati. Jika Anda melakukan terlalu banyak dalam satu waktu, Anda bisa memperlambat seluruh sistem atau mengalami masalah konkurensi.

Atomicity di Sistem Database Populer

Atomicity adalah konsep inti di semua database besar, tetapi cara penerapannya dapat sedikit berbeda bergantung pada mesin penyimpanan dan filosofi desain yang mendasarinya. Mari kita lihat bagaimana PostgreSQL dan MySQL (InnoDB) memastikan transaksi berjalan sebagaimana mestinya.

PostgreSQL

Sebelum data ditulis secara permanen, PostgreSQL membuat write-ahead log (WAL), yaitu catatan setiap perubahan yang direncanakan seperti yang kita bahas sebelumnya. Log ini disimpan dengan aman dan digunakan sebagai rencana pemulihan jika terjadi sesuatu yang salah selama transaksi.

Saat sebuah transaksi di-commit, PostgreSQL memeriksa WAL, mengonfirmasi bahwa semua perubahan telah lengkap dan valid, lalu menyelesaikan pembaruan. Jika sesuatu crash di tengah jalan, database menggunakan log tersebut untuk membatalkan pekerjaan yang belum selesai.

Hebatnya, semua ini terjadi secara otomatis di balik layar. Dari sudut pandang pengembang, ini mulus: Anda menulis transaksi, dan PostgreSQL menjamin atomicity tanpa perlu Anda mengelola kompleksitasnya.

Tidak ada perubahan yang terlihat oleh pengguna lain sampai transaksi sepenuhnya di-commit. Itu menjaga konsistensi dan menghindari keanehan "setengah tersimpan" di lingkungan multi-pengguna.

PostgreSQL WAL. Sumber: AlgoMaster

Jika Anda ingin praktik langsung dan membuat database sendiri untuk menguji transaksi, lihat kursus PostgreSQL kami.

MySQL (InnoDB)

Mesin penyimpanan InnoDB di MySQL juga mendukung transaksi atomik, dan pendekatannya dibangun untuk keandalan sekaligus kinerja.

Seperti PostgreSQL, InnoDB menggunakan log transaksi untuk melacak perubahan sebelum meng-commit-nya. Jika sesuatu gagal, log digunakan untuk mengembalikan semuanya ke keadaan sebelum transaksi. Ini memastikan tidak ada pembaruan parsial yang lolos.

Salah satu hal yang dilakukan InnoDB dengan baik adalah mengelompokkan write bersama-sama. Ini membantu mengurangi I/O disk dan meningkatkan kinerja sambil tetap melindungi atomicity. InnoDB juga menggunakan undo log untuk membalikkan perubahan selama rollback dan redo log untuk pemulihan saat crash.

Sama seperti di PostgreSQL, Anda dapat mengandalkan database untuk menangani mekanisme ini. Anda tidak perlu menulis kode rollback kustom.

Intisari untuk Engineer dan Arsitek Data

Ada beberapa hal yang perlu diingat saat bekerja dengan transaksi atomik dalam proyek Anda sendiri. Gagasan utamanya adalah memperlakukan atomicity sebagai standar, bukan kemewahan. Jika Anda membangun sistem yang memodifikasi data di lebih dari satu tempat pada satu waktu (yang pada dasarnya semuanya demikian), merancang dengan mempertimbangkan atomicity akan menghemat waktu, kewarasan, dan potensi notifikasi insiden jam 3 pagi. 

Pilih database yang tepat untuk tugasnya

Tidak semua database menangani atomicity dengan cara yang sama, dan tidak semua mesin penyimpanan diciptakan setara. Jika atomicity penting bagi kasus penggunaan Anda (misalnya, keuangan, logistik, manajemen status pengguna), pastikan database Anda mendukung transaksi ACID penuh. Ini sangat relevan jika Anda menggunakan MySQL, di mana pilihan mesin penyimpanan sangat berpengaruh.

Rancang untuk kegagalan

Asumsikan bahwa hal-hal akan berjalan salah, karena itu pasti terjadi. Bungkus operasi multi-langkah dalam transaksi dan tangani error dengan benar. Gunakan pernyataan BEGIN, COMMIT, dan ROLLBACK secara eksplisit, atau gunakan framework yang menanganinya secara aman di balik layar.

Sebagian besar ORM dan lapisan akses data modern menawarkan dukungan transaksi bawaan. Misalnya:

• Di Node.js, pustaka seperti Prisma dan TypeORM memungkinkan Anda membungkus logika dalam pemanggilan transaction() yang menangani commit/rollback di balik layar.

• Di Python, SQLAlchemy menawarkan context manager (with session.begin():) yang memastikan commit dan rollback yang aman.

• Di Java, framework seperti Spring memungkinkan Anda memberi anotasi pada metode dengan @Transactional, sehingga database menangani semuanya secara atomik, bahkan lintas beberapa pemanggilan fungsi.

Alat-alat ini membuat pembangunan yang aman menjadi jauh lebih mudah secara default. Alat ini mengurangi risiko lupa melakukan rollback atau salah mengelola logika commit, terutama saat aplikasi Anda semakin kompleks.

Seimbangkan kinerja dengan keandalan

Atomicity memiliki overhead, terutama pada transaksi besar. Pecahlah operasi yang masif jika memungkinkan, hindari mengunci seluruh tabel, dan jaga transaksi tetap singkat dan terfokus. Transaksi berdurasi lama meningkatkan risiko kontensi, deadlock, dan pengguna yang tidak puas.

Pahami dependensi dan isolasi

Seperti yang telah kita lihat, atomicity tidak berdiri sendiri melainkan bersama consistency dan isolation. Pastikan perubahan terkait terjadi bersamaan, dan pertimbangkan bagaimana transaksi bersamaan mungkin berinteraksi. Gunakan level isolasi yang sesuai dengan beban kerja Anda tanpa membuatnya terlalu rumit.

Properti ACID dalam DBMS. Sumber: Datacamp

Uji dengan skenario kegagalan yang realistis

Jangan hanya menguji skenario yang mulus. Simulasikan apa yang terjadi saat aplikasi Anda crash di tengah transaksi, atau ketika kueri mengalami timeout. Anda dapat menggunakan failpoint atau memalsukan kegagalan DB untuk melihat bagaimana sistem Anda berperilaku di bawah tekanan.

Kesimpulan

Jika Anda membangun sistem di mana beberapa hal perlu terjadi bersama-sama, atomicity bukanlah opsional, melainkan esensial. Baik Anda memindahkan uang antar rekening, memperbarui inventaris, atau menyinkronkan sistem, atomicity memastikan data Anda tidak berakhir dalam keadaan rusak atau setengah jadi.

Jika Anda ingin mendalami, mengapa tidak mengikuti kursus Perancangan Database kami? Anda akan belajar merancang database di SQL untuk memproses, menyimpan, dan mengorganisasi data secara lebih efisien.

Dan jika Anda tertarik dengan lebih banyak artikel dan tutorial perancangan database yang praktis, lihat seri normalisasi database kami:

• Normalisasi dalam SQL (1NF - 5NF): Panduan Pemula tutorial
• Apa itu First Normal Form (1NF)? tutorial
• Apa itu Second Normal Form (2NF)? tutorial
• Apa itu Third Normal Form (3NF)? Tutorial
• Apa itu Ketergantungan Transitif? Tutorial