Apa yang dimaksud dengan teorema CAP?

Teorema CAP mengatakan bahwa sistem terdistribusi hanya dapat memberikan dua dari tiga karakteristik yang diinginkan:
konsistensi, ketersediaan, dan  toleransi partisi ('C', 'A', dan 'P' dalam CAP).

Pernahkah Anda melihat iklan tukang taman, pelukis rumah, atau penjual jasa lainnya yang dimulai dengan judul, “Murah, Cepat, dan Bagus: Pilih Dua Saja”? Teorema CAP menerapkan jenis logika yang serupa untuk sistem terdistribusi.

Sistem terdistribusi adalah jaringan yang menyimpan data pada lebih dari satu node ( mesin virtual atau fisik) bersamaan. Karena semua aplikasi cloud adalah sistem terdistribusi, penting untuk memahami teorema CAP saat merancang aplikasi cloud sehingga Anda dapat memilih sistem manajemen data yang memberikan karakteristik yang paling dibutuhkan aplikasi Anda.

Teorema CAP juga disebut Teorema Brewer, karena pertama kali dikemukakan oleh Profesor Eric A. Brewer dalam sebuah ceramah yang dia berikan tentang komputasi terdistribusi pada tahun 2000. Dua tahun kemudian, profesor MIT Seth Gilbert dan Nancy Lynch mempublikasikan bukti dari "Dugaan Brewer."

Mari kita lihat secara terperinci tiga karakteristik sistem terdistribusi yang menjadi acuan teorema CAP.

Konsistensi

Konsistensi berarti bahwa semua klien melihat data yang sama pada waktu yang sama, tidak peduli node mana yang mereka sambungkan. Agar hal ini dapat terjadi, setiap kali data ditulis ke satu node, data tersebut harus segera diteruskan atau direplikasi ke semua node lain dalam sistem sebelum penulisan dianggap 'berhasil'.

Ketersediaan

Ketersediaan berarti bahwa setiap klien yang membuat permintaan data mendapat respons, bahkan jika satu atau lebih node sedang tidak berfungsi. Cara lain untuk menyatakan ini—semua node yang berfungsi dalam sistem terdistribusi mengembalikan respons yang valid untuk permintaan apa pun, tanpa kecuali.

Toleransi partisi

Partisi adalah terputusnya komunikasi dalam sistem terdistribusi - koneksi yang terputus atau tertunda untuk sementara waktu antara dua node. Toleransi partisi berarti bahwa kluster harus terus bekerja meskipun ada sejumlah gangguan komunikasi antar node dalam sistem.

Basis data NoSQL cocok untuk aplikasi jaringan terdistribusi. Tidak seperti rekan-rekan SQL (relasional) yang dapat diskalakan secara vertikal, basis data NoSQL dapat diskalakan secara horizontal dan didistribusikan dengan desain—mereka dapat dengan cepat berkembang di seluruh jaringan yang terdiri dari beberapa node yang saling terhubung. (Lihat "SQL vs Basis data NoSQL: Apa Bedanya?" untuk informasi lebih lanjut).

Saat ini, database NoSQL diklasifikasikan berdasarkan dua karakteristik CAP yang mereka dukung:

• Basis data CP: Basis data CP memberikan konsistensi dan toleransi partisi dengan mengorbankan ketersediaan. Ketika partisi terjadi di antara dua node, sistem harus mematikan node yang tidak konsisten (yaitu, membuatnya tidak tersedia) sampai partisi diselesaikan.
  
  
• Basis data AP: Basis data AP memberikan ketersediaan dan toleransi partisi dengan mengorbankan konsistensi. Ketika partisi terjadi, semua node tetap tersedia, tetapi node yang berada di ujung partisi yang salah mungkin mengembalikan versi data yang lebih lama daripada yang lain. (Ketika partisi diselesaikan, basis data AP biasanya menyinkronkan ulang node untuk memperbaiki semua ketidakkonsistenan dalam sistem).
  
  
• Basis data CA: Basis data CA memberikan konsistensi dan ketersediaan di semua node. Basis data ini tidak dapat melakukan ini jika ada partisi antara dua node dalam sistem dan karena itu tidak dapat memberikan toleransi kesalahan.

Kami mencantumkan jenis basis data CA di urutan terakhir karena suatu alasan—dalam sistem terdistribusi, partisi tidak dapat dihindari. Jadi, meskipun kita dapat mendiskusikan basis data terdistribusi CA secara teori, untuk semua tujuan praktis, basis data terdistribusi CA tidak mungkin ada. Ini bukan berarti Anda tidak dapat memiliki basis data CA untuk aplikasi terdistribusi Anda jika Anda membutuhkannya. Banyak basis data relasional, seperti PostgreSQL, memberikan konsistensi dan ketersediaan dan dapat digunakan ke beberapa node menggunakan replikasi.

MongoDB adalah sistem manajemen basis data NoSQL populer yang menyimpan data sebagai dokumen BSON (binary JSON). Ini sering digunakan untuk big data dan aplikasi real-time yang berjalan di beberapa lokasi berbeda. Sehubungan dengan teorema CAP, MongoDB adalah penyimpanan data CP—teorema ini menyelesaikan partisi jaringan dengan mempertahankan konsistensi, sementara mengorbankan ketersediaan.

MongoDB adalah sistem master tunggal —setiap set replika hanya dapat memiliki satu node utama yang menerima semua operasi penulisan. Semua node lain dalam set replika yang sama adalah node sekunder yang mereplikasi log operasi node primer dan menerapkannya ke set data mereka sendiri. Secara default, klien juga membaca dari node primer, tetapi mereka juga dapat menentukan preferensi baca yang memungkinkan mereka membaca dari node sekunder.

Ketika node primer tidak tersedia, node sekunder dengan log operasi terbaru akan dipilih sebagai node primer yang baru. Setelah semua node sekunder lainnya menyusul induk yang baru, kluster akan tersedia lagi. Karena klien tidak dapat membuat permintaan tulis selama interval ini, data tetap konsisten di seluruh jaringan.

Apache Cassandra adalah database NoSQL sumber terbuka yang dikelola oleh Apache Software Foundation. Ini adalah database kolom lebar yang memungkinkan Anda menyimpan data pada jaringan terdistribusi. Namun, tidak seperti MongoDB, Cassandra memiliki arsitektur tanpa induk, dan akibatnya, Cassandra memiliki banyak titik kegagalan, bukan hanya satu titik kegagalan.

Sehubungan dengan teorema CAP, Cassandra adalah basis data AP—teorema ini memberikan ketersediaan dan toleransi partisi tetapi tidak dapat memberikan konsistensi setiap saat. Karena Cassandra tidak memiliki node utama, semua node harus tersedia secara terus menerus. Namun, Cassandra memberikan konsistensi pada akhirnya dengan mengizinkan klien untuk menulis ke node mana pun kapan pun dan mendamaikan ketidakkonsistenan secepat mungkin.

Karena data hanya menjadi tidak konsisten dalam kasus partisi jaringan dan ketidakkonsistenan dapat diselesaikan dengan cepat, Cassandra menawarkan fungsionalitas "perbaikan" untuk membantu node mengejar ketertinggalan dari rekan-rekannya. Namun, ketersediaan yang konstan menghasilkan sistem dengan kinerja tinggi yang mungkin sepadan untuk dipertukarkan dalam banyak kasus.

Layanan mikro adalah komponen aplikasi yang digabungkan secara longgar dan dapat digunakan secara independen yang menggabungkan tumpukan mereka sendiri—termasuk basis data dan model basis data mereka sendiri—dan berkomunikasi satu sama lain melalui jaringan. Karena Anda bisa menjalankan layanan mikro di server cloud dan pusat data di lokasi, layanan ini menjadi sangat populer untuk aplikasi hybrid dan multicloud.

Memahami teorema CAP dapat membantu Anda memilih basis data terbaik saat merancang aplikasi berbasis layanan mikro yang berjalan dari beberapa lokasi. Sebagai contoh, jika kemampuan untuk mengulang model data dengan cepat dan menskalakan secara horizontal sangat penting untuk aplikasi Anda, tetapi Anda dapat mentoleransi konsistensi yang akhirnya (sebagai lawan dari konsistensi yang ketat), basis data AP seperti Cassandra atau Apache CouchDB dapat memenuhi kebutuhan Anda dan menyederhanakan penerapan Anda. Di sisi lain, jika aplikasi Anda sangat bergantung pada konsistensi data-seperti pada aplikasi eCommerce atau layanan pembayaran-Anda dapat memilih basis data relasional seperti PostgreSQL.