Arsitektur microservices memberikan kita fleksibilitas untuk menggunakan jenis database yang berbeda. Anda tidak harus menggunakan tradisional relational database (RDBMS) tapi Anda juga bisa menggunakan beberapa jenis database lain yang berbeda misalnya database yang biasa dikategorikan sebagai NoSQL (non-relational). Lalu bagaimana kita memilih database yang cocok untuk microservice yang akan kita bangun?
Salah satu cara memilih jenis database adalah dengan melihat karakteristiknya berdasarkan teorema CAP (Consistency, Availability, Partition-tolerance).
Selain berdasarkan teorema CAP, orang sering memilih jenis database dari karakteristik bagaimana data disimpan dan berelasi (data model). Ada beberapa katergori database berdasarkan karakteristik ini yaitu:
- Tabular (column-oriented) database
- Document oriented database
- Graph database
- Multi-model database
- Relational/SQL database (RDBMS)
Inti dari teorema CAP adalah suatu sistem hanya bisa memiliki 2 karakteristik dari 3 karakteristik ini:
- Consistency,
- Availability,
- Partition-tolerance.
Jadi suatu sistem hanya bisa bersifat "CA" atau "CP" atau "AP" tidak ketiganya. Diagram pengkategorian dabatase ini sering digunakan sebagai referensi suatu database merupakan sistem "CA", "CP" atau "AP", tapi apakah hal ini sepenuhnya benar?
Saya tidak akan membahas detail tentang teorema CAP disini. Mungkin penjelasan dengan ilustrasi ini mungkin akan memudahkan Anda memahami maksud dari teorema CAP.
Yang ingin saya sampaikan disini --sesuai dengan judul dokumen-- adalah bahwa teorema CAP tidak boleh serta merta digunakan secara sederhana (misal hanya dengan melihat diagram pengkategorian NoSQL system) untuk memilih jenis database yang akan Anda gunakan pada microservices. Pemahaman teorema CAP akan cukup membantu Anda untuk menganalisis lebih dalam ketika memilih jenis database. Jadi pemahaman dengan baik terkait karakteristik Consistency, Availability, dan Partition-tolerance sangat penting dibanding kesimpulan pengkategorial database system dalam "CA", "CP" atau "AP".
Untuk lebih mengerti dalam konsep CAP, ada baiknya anda membaca beberapa artikel seperti kritik terhadap teorema CAP dan juga penjelasan Eric Brewer (pencetus teorema CAP) tentang kesalahpahman terkait teori CAP dan penjelasan detail dalam memahami teorinya.
Dibawah ini saya tuliskan beberapa poin kesimpulan dari artikel tersebut.
- Categorizing system into simple CAP is misleading and oversimplified -> e.g. Diagram shown in Visual guide to NoSQL system
- This categorizing is useful, although not too accurate.
So, we need to ...
- Understand the definition (meaning) of each word in C-A-P
- Understand “two out of three” formulation -> system can be categorized as only one out of three, or even none out of three
- Don't rely only on CAP theorem
- Define your SLA
- Most of system's CAP characteristic is depends on your settings
- Consider tradeoff between CAP and performance/latency
- Understand your requirement
Learning to think for yourself
Understand that "P" (Partition) will always happened.
- networks are reliable is a fallacy of distributed computing
- this means we are left with two options: Consistency and Availability
- So it always about "AP" or "CP" only.
"C" means very strong Consistency or some people call it atomic Consistency -> Linearizable
- Expensive guarantee to provide <- requires a lot of coordination
- Even low level computing system e.g CPU access to your local RAM
- "CP" means you will get consistency but since P occurs, it will take long time to sync data one and another nodes which means the response is very slow (not really Available)
"A" means strict high-avabilability (not just high-available as we know)
- Fast response from every nodes
- "AP" means you will get reponse very fast (Available) from every nodes, but since data is replicated asynchonously then the reponse from different nodes might not consistent
Terkait trade off antara Availability dan Consistency, teorema PACELC bisa menjadi alternatif untuk memilih sistem database yang cocok untuk suatu microservices.
Teorema PACELC dijelaskan seara sederhana sebagai berikut:
- when there is a network Partition, a tradeoff between Availability and Consistency,
- Else a tradeoff between Latency and Consistency
Gambar berikut yang mirip dengan visualisasi CEP diatas:
Selain itu ada artikel yang cukup bagus untuk dibaca, tapi saya sarankan Anda juga membaca dulu arikel-artikel pada link diatas untuk membuka wawasan.
Gambar ini diambil dari artikel tersebut dan bisa menjadi petunjuk sederhada dalam memilih sistem database untuk microservices:
Links: