Pernahkah Anda melihat iklan untuk penata taman, pelukis rumah, atau penjual jasa lainnya yang dimulai dengan judul, "Murah, Cepat, dan Bagus: Pilih Dua"?

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

Sistem terdistribusi adalah jaringan yang menyimpan data pada lebih dari satu node (mesin fisik atau virtual) secara 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.

Database NoSQL cocok untuk aplikasi jaringan terdistribusi. Tidak seperti rekan-rekan SQL (relasional) yang dapat diskalakan secara vertikal, database 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 Database NoSQL: Apa Bedanya?" untuk informasi lebih lanjut).

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

• Database CP: Database 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.
  
  
• Database AP: Database 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, database AP biasanya menyinkronkan ulang node untuk memperbaiki semua ketidakkonsistenan dalam sistem).
  
  
• Database CA: Database CA memberikan konsistensi dan ketersediaan di semua node. Database ini tidak dapat melakukan ini jika ada partisi antara dua node dalam sistem dan karena itu tidak dapat memberikan toleransi kesalahan.

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

MongoDB adalah sistem manajemen database NoSQL populer yang menyimpan data sebagai dokumen BSON (binary JSON). Ini sering digunakan untuk data besar 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 induk tunggal, setiap set replika (tautan berada di luar ibm.com) hanya dapat memiliki satu node utama yang menerima semua operasi tulis. 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 (tautan berada di luar ibm.com) 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 database 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 database dan model database 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 database 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), database 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 database relasional seperti PostgreSQL.