Pertumbuhan data eksponensial dan meningkatnya permintaan untuk aplikasi real-time dan berbasis data telah menciptakan kebutuhan untuk pengembangan solusi basis data yang sangat scalable dan tangguh. Selain itu, peningkatan komputasi awan dan pergeseran menuju arsitektur terdistribusi mengharuskan solusi basis data yang dapat beroperasi di beberapa wilayah geografis dan pusat data. Arsitektur basis data monolitik tradisional sering kali kesulitan untuk memenuhi persyaratan kinerja, ketersediaan, dan efisiensi biaya dari sistem skala besar modern. Menurut laporan oleh IDC, datasphere global diproyeksikan akan tumbuh dari 33 zettabyte pada tahun 2018 menjadi 175 zettabyte pada tahun 2025, dengan lebih dari 49% data disimpan di lingkungan cloud publik [1]. Dalam artikel ini, kita akan mengeksplorasi prinsip dan strategi arsitektur untuk membangun basis data yang mampu menangani volume data besar dan beban kerja yang terdistribusi secara global.
Skala Horizontal vs Skala Vertikal
Arsitektur basis data tradisional dirancang untuk penerapan satu simpul dan penskalaan vertikal dan sering kali kesulitan memenuhi tuntutan sistem berskala besar. Penskalaan vertikal melibatkan peningkatan sumber daya perangkat keras pada satu simpul dengan menambahkan sumber daya seperti memori, penyimpanan, dan daya pemrosesan ke perangkat lunak yang ada, untuk meningkatkan kinerjanya. Ini juga disebut sebagai pendekatan Scale-up. Penskalaan vertikal memiliki beberapa keterbatasan praktis seperti biaya dan skalabilitas. Mereka juga tidak memiliki mekanisme ketahanan dan toleransi kesalahan yang diperlukan untuk menahan kegagalan, partisi jaringan, dan gangguan lainnya.
Skala Horizontal menambahkan lebih banyak node basis data untuk menangani peningkatan beban kerja. Ini mengurangi beban pada server daripada memperluas server individual. Ketika Anda membutuhkan lebih banyak kapasitas, Anda dapat menambahkan lebih banyak server ke kluster. Ini juga disebut sebagai pendekatan Scale-out. Skala horizontal mudah untuk ditingkatkan, biayanya lebih murah dan Anda dapat dengan mudah mengganti node yang rusak. Sistem skala besar memerlukan perubahan mendasar dari pendekatan skala vertikal tradisional ke skala horizontal. Pendekatan ini mendistribusikan data dan beban komputasi di seluruh kluster server komoditas, memungkinkan skalabilitas linier dan toleransi kesalahan. Ini juga memungkinkan partisi data di beberapa node yang juga disebut sebagai Sharding. Studi telah menunjukkan bahwa sharding dapat secara signifikan meningkatkan kinerja basis data, dengan perolehan hingga 50% atau lebih, tergantung pada beban kerja dan distribusi data [2].
Strategi sharding dapat bervariasi tergantung pada pola akses data dan persyaratan konsistensi data. Salah satu teknik umum mencakup sharding berbasis rentang, yang mempartisi data berdasarkan rentang nilai (misalnya, rentang tanggal). Pendekatan lain mencakup sharding berbasis direktori, yang menggunakan layanan pencarian terpisah untuk memetakan data ke shard yang sesuai. Namun, pendekatan yang paling banyak digunakan adalah sharding berbasis hash, yang menggunakan fungsi hash untuk mendistribusikan data secara merata di seluruh shard. Sharding berbasis hash menyediakan pencarian yang lebih cepat untuk entri basis data. Pilihan akhir strategi sharding bergantung pada kebutuhan aplikasi Anda dan merupakan keputusan penting karena dapat memengaruhi kinerja sistem, waktu respons, dan kompleksitas operasional.
Merancang untuk Kegagalan
Dalam sistem berskala besar, replikasi data memainkan peran penting dalam memastikan ketersediaan dan toleransi kesalahan. Anda dapat menyimpan beberapa salinan data di berbagai node atau wilayah geografis sehingga sistem dapat beroperasi bahkan jika terjadi kegagalan node atau partisi jaringan. Anda dapat memilih antara strategi replikasi sinkron, di mana data ditulis ke beberapa replika secara bersamaan atau asinkron, di mana replika akhirnya diperbarui setelah operasi penulisan awal. Menurut sebuah studi oleh Google, sistem basis data terdistribusi global mereka, Spanner, mencapai ketersediaan 99,999% yang mengesankan dengan menggabungkan replikasi sinkron dalam pusat data dan replikasi asinkron di seluruh situs [3].
Konsistensi Akhir
Model konsistensi, seperti konsistensi kuat (misalnya, menggunakan protokol konsensus seperti Paxos atau Raft) dan konsistensi akhir (misalnya, menggunakan tipe data replikasi bebas konflik, CRDT), mengatur bagaimana data direplikasi dan direkonsiliasi di seluruh replika. Pilihan model konsistensi bergantung pada persyaratan aplikasi tertentu, yang mencapai keseimbangan yang rumit antara integritas data, kinerja, dan ketersediaan. Yang terbaik adalah menggunakan konsistensi akhir jika sistem Anda dapat menanganinya karena tidak semua node harus berada dalam status yang sama setelah setiap operasi tunggal misalnya memperbarui jumlah inventaris produk antara dua sistem, Anda dapat membiarkan pelanggan Anda memesan produk dan kemudian menghitung stok yang tersisa. Konsistensi yang kuat mutlak diperlukan untuk transaksi keuangan/perbankan atau aplikasi pembayaran, karena semua node basis data di sistem Anda harus konsisten sepanjang waktu. Jika Anda perhatikan dengan seksama, sebagian besar aplikasi dapat memanfaatkan konsistensi akhir. Penelitian oleh Yahoo menunjukkan bahwa konsistensi akhir dapat memberikan throughput hingga 10x lebih tinggi dibandingkan dengan model konsistensi yang kuat, sambil mempertahankan kebenaran data yang dapat diterima untuk beban kerja tertentu [4].
Dapatkan respons lebih cepat hanya dengan Caching
Mekanisme caching sangat penting untuk meningkatkan kinerja baca dan mengurangi beban pada lapisan penyimpanan basis data. Caching dapat terjadi pada berbagai tingkatan, termasuk cache dalam memori (misalnya, Redis, Memcached), jaringan pengiriman konten (CDN), dan proxy terbalik. Strategi pembatalan cache yang efektif, seperti kedaluwarsa time-to-live (TTL) atau teknik cache busting, sangat penting untuk memastikan konsistensi data antara cache dan penyimpanan basis data yang mendasarinya. Menurut sebuah studi oleh Facebook, sistem caching Tao mereka mengurangi beban basis data hingga 95% untuk beban kerja tertentu [5], yang menggarisbawahi peningkatan kinerja signifikan yang dapat dicapai melalui strategi caching yang cerdas.
Pola akses data, seperti beban kerja yang banyak membaca atau menulis, juga memengaruhi keputusan arsitektur untuk penyimpanan basis data. Beban kerja yang banyak membaca dapat diuntungkan dari strategi caching dan replikasi yang memprioritaskan kinerja baca, sementara beban kerja yang banyak menulis mungkin memerlukan pengoptimalan untuk jaminan konsistensi dan throughput penulisan. Mengidentifikasi dan memahami pola ini sangat penting untuk menyesuaikan arsitektur penyimpanan basis data guna memenuhi kebutuhan spesifik aplikasi.
Memanfaatkan Arsitektur Layanan Terkelola
Arsitektur berbasis cloud dan layanan basis data terkelola menawarkan berbagai alat canggih untuk membangun solusi penyimpanan basis data yang dapat diskalakan. Teknologi kontainerisasi seperti Docker dan platform orkestrasi seperti Kubernetes memungkinkan penerapan, penskalaan, dan pengelolaan klaster basis data yang lancar di berbagai node atau lingkungan cloud. Sebuah studi oleh Google menunjukkan bahwa platform basis data berbasis Kubernetes mereka, Cloud SQL, dapat secara otomatis diskalakan dari 10 hingga 100 node dalam hitungan menit, menangani hingga 1,5 juta kueri per detik [6] – suatu prestasi yang akan menjadi tantangan, jika bukan mustahil, dengan arsitektur basis data tradisional.
Layanan basis data terkelola, seperti Amazon RDS, Google Cloud SQL, dan Azure SQL Database, mengabstraksikan banyak kerumitan operasional yang terkait dengan manajemen basis data, sehingga pengembang dapat fokus pada logika aplikasi. Layanan ini sering kali menyediakan fitur bawaan untuk skalabilitas, ketersediaan tinggi, dan pencadangan otomatis, sehingga mengurangi kerumitan keseluruhan dalam membangun dan memelihara penyimpanan basis data berskala besar. Dengan memanfaatkan layanan terkelola, organisasi dapat memperoleh manfaat dari keahlian dan sumber daya penyedia cloud, sekaligus mengurangi beban operasional pada tim internal mereka.
Pemantauan Berkelanjutan & Pemulihan Bencana
Pemantauan dan observabilitas penting untuk mendeteksi dan menyelesaikan masalah dengan cepat. Solusi pemantauan yang komprehensif harus melacak indikator kinerja utama (KPI) seperti latensi, throughput, dan pemanfaatan sumber daya, yang memungkinkan identifikasi hambatan dan penurunan kinerja secara tepat waktu. Penelitian oleh Dropbox mengungkapkan bahwa sistem pemantauan mereka, yang mengumpulkan lebih dari 20 miliar metrik per hari, membantu mengurangi waktu deteksi insiden dari jam menjadi menit [7], yang menggarisbawahi peran penting pemantauan yang efektif dalam meminimalkan waktu henti sistem dan memastikan kinerja yang optimal.
Alat observabilitas, seperti pelacakan terdistribusi dan agregasi log, memberikan wawasan yang sangat berharga tentang perilaku sistem terdistribusi yang kompleks, membantu dalam analisis akar penyebab dan pemecahan masalah. Alat ini memungkinkan pengembang dan operator untuk memahami interaksi dan ketergantungan yang rumit antara berbagai komponen sistem, memfasilitasi identifikasi dan penyelesaian masalah yang cepat.
Lebih jauh lagi, strategi pemulihan bencana yang kuat, termasuk pencadangan data, mekanisme failover, dan rencana pemulihan, sangat penting untuk memastikan kelangsungan bisnis dalam menghadapi kegagalan besar atau insiden kehilangan data. Sebuah studi oleh AWS menunjukkan bahwa layanan Elastic Disaster Recovery mereka dapat memulihkan basis data 16TB dalam waktu kurang dari 60 menit, dengan kehilangan data minimal [8], yang menunjukkan pentingnya memiliki rencana pemulihan bencana yang komprehensif untuk sistem penyimpanan basis data berskala besar.
Kesimpulan
Membangun penyimpanan basis data yang dapat diskalakan untuk sistem berskala besar memerlukan pendekatan holistik yang mempertimbangkan faktor-faktor seperti penskalaan horizontal, replikasi data, penyimpanan sementara, pemantauan, dan pemulihan bencana. Dengan merangkul penskalaan horizontal melalui sharding dan distribusi di seluruh server komoditas, organisasi dapat mencapai skalabilitas linier dan toleransi kesalahan untuk menangani volume data dan permintaan pengguna yang terus meningkat. Praktik pemantauan dan pemulihan bencana yang berkelanjutan sangat penting untuk menjaga ketahanan sistem. Karena volume data dan permintaan pengguna terus bertambah, prinsip dan strategi yang diuraikan dalam artikel ini akan tetap mendasar untuk merancang solusi penyimpanan basis data yang dapat diskalakan dan berkinerja tinggi. Evaluasi, adaptasi, dan inovasi yang berkelanjutan akan diperlukan untuk tetap menjadi yang terdepan dalam lanskap yang berkembang pesat ini.
Referensi:
- [1] Reinsel, D., Gantz, J., & Rydning, J. (2018). Digitalisasi Dunia: Dari Tepi ke Inti. Buku Putih IDC. https://www.seagate.com/files/www-content/our-story/trends/files/idc-seagate-dataage-whitepaper.pdf
- [2] Sumbaly, R., Kreps, J., Gao, L., Feinberg, A., Soman, C., & Shah, S. (2012). Melayani data komputasi batch skala besar dengan Project Voldemort. Dalam Prosiding konferensi USENIX ke-10 tentang Teknologi File dan Penyimpanan. https://static.usenix.org/events/fast12/tech/full_papers/Sumbaly.pdf
- [3] Corbett, JC, Dean, J., Epstein, M., Fikes, A., Frost, C., Furman, JJ, ... & Zwicky, E. (2012). Spanner: Basis data terdistribusi global milik Google. Dalam Prosiding Simposium USENIX ke-10 tentang Desain dan Implementasi Sistem Operasi (OSDI'12). https://www.usenix.org/system/files/conference/osdi12/osdi12-final-16.pdf
- [4] Cooper, BF, Ramakrishnan, R., Srivastava, U., Silberstein, A., Bohannon, P., Jacobsen, HA, & Yerneni, R. (2008). PNUTS: Platform penyajian data yang dihosting oleh Yahoo!. Prosiding Dana Abadi VLDB, 1(2), 1277-1288. https://sites.cs.ucsb.edu/~agrawal/fall2009/PNUTS.pdf
- [5] Bronson, N., Amsden, Z., Cabrera, G., Chakka, P., Dimov, P., Ding, H., ... & Xu, L. (2013). TAO: Penyimpanan data terdistribusi Facebook untuk grafik sosial. Disajikan sebagai bagian dari Konferensi Teknis Tahunan USENIX 2013 (USENIX ATC'13). http://0b4af6cdc2f0c5998459-c0245c5c937c5dedcca3f1764ecc9b2f.r43.cf2.rackcdn.com/11730-atc13-bronson.pdf
- [6] Google Cloud Platform. (2022). Cloud SQL: Basis data relasional yang terkelola sepenuhnya. https://console.cloud.google.com/marketplace/product/google-cloud-platform/cloud-sql
- [7] Dropbox. (2021). Pemantauan Skala di Dropbox. https://dropbox.tech/infrastructure/lessons-learned-in-incident-management
- [8] Layanan Web Amazon. (2022). Pemulihan Bencana Elastis AWS. https://aws.amazon.com/disaster-recovery/
