Analisis Pengaruh Strong Consistency dan Eventual Consistency terhadap Write Latency dan Replication Delay pada MongoDB Replica Set
Keywords:
MongoDB Replica Set, Strong Consistency, Eventual Consistency, Write Latency, Replication Delay.Abstract
Sistem basis data terdistribusi menjadi solusi untuk meningkatkan skalabilitas, ketersediaan layanan, dan toleransi kegagalan pada pengelolaan data berskala besar. Salah satu implementasinya adalah MongoDB Replica Set yang memanfaatkan replikasi antara node Primary dan Secondary. Namun, mekanisme replikasi menimbulkan tantangan dalam menjaga konsistensi data tanpa mengurangi performa sistem. Penelitian ini bertujuan menganalisis pengaruh Strong Consistency dan Eventual Consistency terhadap write latency dan replication delay pada MongoDB Replica Set. Penelitian menggunakan metode kuantitatif eksperimental pada lingkungan Docker yang terdiri atas satu node Primary dan dua node Secondary. Data uji dibuat secara otomatis menggunakan Python dengan jumlah 10.000, 50.000, dan 100.000 dokumen. Pengujian dilakukan menggunakan konfigurasi WriteConcern("majority") untuk Strong Consistency dan WriteConcern(w=1) untuk Eventual Consistency. Hasil menunjukkan bahwa Eventual Consistency menghasilkan write latency yang sedikit lebih rendah pada volume 10.000 dokumen, sedangkan Strong Consistency memberikan nilai lebih rendah pada volume 50.000 dan 100.000 dokumen. Selain itu, rata-rata replication delay sebesar 0,023796 detik menunjukkan proses sinkronisasi data berlangsung stabil. Secara keseluruhan, kedua konfigurasi konsistensi menghasilkan performa yang relatif setara pada lingkungan pengujian. Oleh karena itu, pemilihan tingkat konsistensi lebih dipengaruhi oleh kebutuhan jaminan konsistensi data dibandingkan pertimbangan performa sistem.
References
[1] . Dari kedua kondisi tersebut, peneliti mengamati dua parameter utama, yaitu write latency dan replication delay. Gambar 1. Tahapan Penelitian Persiapan Lingkungan Pengujian MongoDB Replica Set dikonfigurasi menggunakan Docker, terdiri atas satu node Primary bernama mongo1 serta dua node Secondary bernama mongo2 dan mongo3, ketiganya terhubung dalam satu jaringan virtual lokal. Setelah infrastruktur berhasil berdiri, peneliti melakukan inisialisasi dan pengecekan sistem. Inisialisasi Replica Set Tahapan ini dilakukan menggunakan perintah rs.initiate(), kemudian kondisi sistem diperiksa melalui rs.status() guna memastikan seluruh node telah terhubung dan proses replikasi berlangsung sebagaimana mestinya. Setelah sistem dipastikan berjalan normal, peneliti beralih ke tahap persiapan data uji. Pembuatan Data Dummy Data uji dibuat secara otomatis menggunakan Python dan dimasukkan langsung ke dalam MongoDB Replica Set. Setiap dokumen memiliki struktur data yang seragam sehingga proses pengujian dapat dilakukan secara konsisten pada seluruh skenario. Data yang dihasilkan kemudian digunakan sebagai beban kerja dalam pengujian write latency dan replication delay pada konfigurasi Strong Consistency maupun Eventual Consistency. Penentuan Skenario Konsistensi Skenario pengujian didasarkan pada dua konfigurasi konsistensi, yaitu Strong Consistency dengan WriteConcern ("majority") dan Eventual Consistency dengan WriteConcern(w=1)
[2] . Setiap skenario kemudian dijalankan untuk mengukur seberapa cepat sistem menyelesaikan proses penulisan data. Pengujian Write Latency Write latency diukur guna mengetahui durasi yang diperlukan sistem untuk menuntaskan operasi tulis pada masing-masing volume data yang diuji
[3] . Agar hasil yang diperoleh lebih dapat diandalkan, setiap skenario diulang sebanyak tiga kali. Di samping write latency, peneliti juga mengamati replication delay sebagai parameter tambahan. Pengukuran Replication Delay Replication delay dihitung berdasarkan jeda waktu antara saat penulisan data selesai di node Primary dengan saat data tersebut mulai tersedia di node Secondary
[4] . Seluruh data hasil pengukuran kemudian dikumpulkan untuk dianalisis pada tahap berikutnya. Analisis dan Evaluasi Hasil Pada tahap ini, hasil pengukuran write latency dan replication delay dari konfigurasi Strong Consistency dan Eventual Consistency dibandingkan untuk mengetahui pengaruh masing-masing tingkat konsistensi terhadap performa MongoDB Replica Set. Hasil perbandingan tersebut kemudian dianalisis sebagai dasar dalam penyusunan kesimpulan penelitian. Hasil dan Pembahasan Persiapan Lingkungan Pengujian Sebelum proses pengujian dilakukan, lingkungan eksperimen terlebih dahulu dipersiapkan menggunakan Docker Desktop dan MongoDB Community Server. Lingkungan pengujian terdiri atas tiga container MongoDB yang berperan sebagai satu node primary dan dua node secondary dalam konfigurasi Replica Set. Setelah seluruh container berhasil dijalankan, dilakukan verifikasi untuk memastikan setiap node dapat saling terhubung dan berkomunikasi dengan baik. Tahap ini diperlukan agar pengujian Strong Consistency dan Eventual Consistency dapat dilakukan pada lingkungan yang sesuai dengan skenario sistem terdistribusi. Keberhasilan persiapan lingkungan pengujian ditunjukkan melalui status container yang aktif serta keberhasilan pembentukan MongoDB Replica Set sebelum proses pengukuran write latency dan replication delay dilakukan. Detail konfigurasi lingkungan pengujian yang digunakan dapat dilihat pada Tabel 1. Tabel I. Konfigurasi Lingkungan Pengujian MongoDB Replica Set Berdasarkan Tabel I, seluruh node MongoDB berhasil dijalankan dan berada dalam kondisi aktif. Node mongo1 berperan sebagai Primary, sedangkan mongo2 dan mongo3 berperan sebagai Secondary. Konfigurasi tersebut membentuk MongoDB Replica Set yang digunakan sebagai lingkungan pengujian untuk mengukur write latency dan replication delay pada skenario Strong Consistency dan Eventual Consistency. Berdasarkan hasil implementasi tersebut, seluruh node terpantau dalam kondisi aktif dan dapat berkomunikasi satu sama lain tanpa kendala. Arsitektur MongoDB Replica Set yang digunakan pada penelitian ini ditunjukkan pada Gambar 2. Dengan konfigurasi tersebut, lingkungan pengujian dinyatakan siap digunakan untuk proses pengukuran write latency dan replication delay. Gambar 2. Arsitektur MongoDB Replica Set pada Lingkungan Docker Inisialisasi dan Verifikasi Replica Set Setelah lingkungan pengujian selesai dipersiapkan, tahap berikutnya adalah melakukan inisialisasi MongoDB Replica Set menggunakan perintah rs.initiate(). Proses ini dilakukan untuk menghubungkan ketiga node MongoDB ke dalam satu Replica Set sehingga mekanisme replikasi data dapat berjalan sesuai dengan skenario pengujian yang telah dirancang. Untuk memastikan proses inisialisasi berhasil, dilakukan verifikasi menggunakan perintah rs.status(). Hasil verifikasi menunjukkan bahwa node mongo1 berhasil terpilih sebagai Primary, sedangkan node mongo2 dan mongo3 berstatus Secondary. Kondisi tersebut menandakan bahwa seluruh node telah tergabung dalam Replica Set yang sama dan mekanisme replikasi telah aktif berjalan dengan baik. Berdasarkan hasil verifikasi tersebut, tidak ditemukan kendala pada proses konfigurasi maupun komunikasi antar node. Dengan terbentuknya satu node Primary dan dua node Secondary, lingkungan pengujian dinyatakan siap digunakan untuk proses pengujian Strong Consistency dan Eventual Consistency melalui pengukuran write latency dan replication delay. Tabel II. Output rs.status() Pembuatan Data Dummy Pada tahap ini, data uji dibuat secara otomatis menggunakan Python dan dimasukkan langsung ke dalam MongoDB Replica Set. Data tersebut digunakan sebagai beban kerja untuk mengukur performa sistem pada berbagai tingkat konsistensi yang diterapkan. Pengujian dilakukan menggunakan tiga variasi jumlah data, yaitu 10.000, 50.000, dan 100.000 dokumen. Variasi jumlah data tersebut dipilih untuk mensimulasikan peningkatan beban penulisan data sehingga pengaruh Strong Consistency dan Eventual Consistency terhadap performa sistem dapat diamati secara lebih jelas. Setiap dokumen yang dihasilkan memiliki struktur data yang seragam, sehingga seluruh skenario pengujian dilakukan pada kondisi yang sama. Dengan pendekatan tersebut, perbedaan hasil yang diperoleh lebih mencerminkan pengaruh konfigurasi konsistensi yang digunakan dibandingkan perbedaan karakteristik data. Data uji yang telah dibuat kemudian digunakan pada proses pengukuran write latency dan replication delay untuk masing-masing skenario konsistensi yang diterapkan pada MongoDB Replica Set. Tabel III. Variasi jumlah data uji Berdasarkan Tabel III, pengujian dilakukan pada tiga tingkat beban yang berbeda untuk melihat perubahan performa sistem ketika jumlah data yang diproses semakin meningkat. Variasi jumlah data tersebut digunakan pada seluruh skenario pengujian sehingga hasil yang diperoleh dapat dibandingkan secara konsisten. Penentuan Skenario Konsistensi Setelah data uji selesai dipersiapkan, peneliti menerapkan dua konfigurasi konsistensi yang masing-masing akan menjadi skenario dalam pengujian. Konfigurasi pertama menggunakan pendekatan Strong Consistency melalui WriteConcern("majority"), sementara konfigurasi kedua menerapkan Eventual Consistency melalui WriteConcern(w=1). Kedua konfigurasi tersebut diterapkan pada MongoDB Replica Set yang telah berhasil diinisialisasi pada tahap sebelumnya. Penerapan dua konfigurasi yang berbeda memungkinkan pengukuran performa sistem pada tingkat konsistensi yang berbeda sehingga pengaruhnya terhadap write latency dan replication delay dapat diamati secara langsung. Melalui kedua skenario tersebut, peneliti dapat membandingkan performa MongoDB Replica Set pada kondisi Strong Consistency dan Eventual Consistency. Tabel IV. Konfigurasi Skenario Konsistensi Pengujian Write Latency Pengujian write latency dilakukan untuk mengetahui berapa lama waktu yang dibutuhkan sistem dalam menuntaskan proses penulisan data pada masing-masing konfigurasi, baik Strong Consistency maupun Eventual Consistency. Pengukuran dilakukan pada tiga variasi jumlah data, yaitu 10.000, 50.000, dan 100.000 dokumen. Hasil pengujian write latency ditunjukkan pada Tabel 5. Tabel V. Hasil Pengujian Write Latency (detik) Berdasarkan Tabel V, Eventual Consistency menunjukkan write latency yang sedikit lebih rendah pada pengujian dengan 10.000 dokumen, yaitu sebesar 0,0915 detik dibandingkan Strong Consistency sebesar 0,0989 detik. Namun, pada volume data 50.000 dan 100.000 dokumen, Strong Consistency justru menghasilkan write latency yang sedikit lebih rendah dibandingkan Eventual Consistency. Meskipun demikian, selisih waktu yang diperoleh pada seluruh skenario pengujian relatif kecil. Hasil tersebut menunjukkan bahwa perbedaan tingkat konsistensi tidak memberikan pengaruh yang signifikan terhadap write latency pada lingkungan MongoDB Replica Set yang digunakan dalam penelitian ini. Gambar 3. Grafik Perbandingan Write Latency antara Strong Consistency dan Eventual Consistency Gambar 3 menunjukkan bahwa nilai write latency meningkat seiring bertambahnya jumlah dokumen yang diproses. Pola peningkatan yang ditunjukkan oleh Strong Consistency dan Eventual Consistency terlihat hampir serupa pada seluruh variasi data. Kondisi ini mengindikasikan bahwa peningkatan volume data memiliki pengaruh yang lebih besar terhadap write latency dibandingkan perbedaan konfigurasi konsistensi yang diterapkan pada lingkungan pengujian. Selain itu, seluruh node MongoDB dijalankan pada satu lingkungan Docker dalam mesin fisik yang sama sehingga latensi komunikasi antar node relatif rendah. Kondisi tersebut menyebabkan perbedaan overhead antara WriteConcern("majority") dan WriteConcern(w=1) tidak terlihat secara signifikan selama proses pengujian berlangsung. Pengukuran Replication Delay Pengukuran replication delay dilakukan untuk mengetahui seberapa cepat data yang telah berhasil ditulis pada node Primary dapat direplikasi dan tersedia pada node Secondary. Parameter ini digunakan untuk mengevaluasi efektivitas mekanisme replikasi pada MongoDB Replica Set dalam menjaga sinkronisasi data antar node. Hasil pengukuran replication delay ditunjukkan pada Tabel 6. Tabel VI. Hasil Pengujian Replication Delay Berdasarkan Tabel VI, nilai replication delay yang diperoleh berada pada kisaran 0,021 hingga 0,028 detik dengan rata-rata sebesar 0,023796 detik. Nilai tersebut menunjukkan bahwa proses replikasi data dari node Primary ke node Secondary berlangsung dalam waktu yang sangat singkat. Perbedaan nilai yang muncul pada setiap pengujian juga relatif kecil, sehingga mengindikasikan bahwa mekanisme replikasi berjalan secara stabil. Hasil ini menunjukkan bahwa MongoDB Replica Set mampu menjaga sinkronisasi data antar node dengan baik selama proses pengujian berlangsung. Gambar 4. Grafik Hasil Pengukuran Replication Delay pada MongoDB Replica Set Gambar 4 menunjukkan bahwa nilai replication delay pada setiap sesi pengujian cenderung konsisten dan tidak mengalami fluktuasi yang signifikan. Stabilitas tersebut menunjukkan bahwa mekanisme replikasi MongoDB Replica Set mampu mendistribusikan data antar node secara efisien pada lingkungan pengujian yang digunakan. Rendahnya nilai replication delay yang diperoleh juga menunjukkan bahwa proses sinkronisasi data dapat dilakukan dengan cepat setelah operasi penulisan pada node Primary selesai dilakukan. Dengan demikian, MongoDB Replica Set mampu mempertahankan ketersediaan data pada node Secondary tanpa menimbulkan penundaan replikasi yang berarti selama pengujian berlangsung. Analisis dan Evaluasi Hasil Berdasarkan hasil pengujian yang telah dilakukan, kedua konfigurasi konsistensi menunjukkan performa yang relatif serupa pada lingkungan MongoDB Replica Set yang digunakan. Hasil pengukuran write latency memperlihatkan bahwa Eventual Consistency sedikit lebih cepat pada volume data 10.000 dokumen, sedangkan Strong Consistency menghasilkan waktu yang sedikit lebih rendah pada volume data 50.000 dan 100.000 dokumen. Namun, selisih yang diperoleh pada seluruh skenario pengujian relatif kecil sehingga tidak menunjukkan perbedaan performa yang signifikan. Hasil tersebut mengindikasikan bahwa penerapan WriteConcern("majority") pada Strong Consistency tidak memberikan tambahan overhead yang besar dibandingkan WriteConcern(w=1) pada Eventual Consistency dalam lingkungan pengujian yang digunakan. Dengan demikian, kedua konfigurasi dapat menjalankan proses penulisan data dengan performa yang hampir setara meskipun memiliki tingkat jaminan konsistensi yang berbeda. Dari sisi replikasi, nilai replication delay yang diperoleh berada pada kisaran 0,021 hingga 0,028 detik dengan rata-rata sebesar 0,023796 detik. Nilai tersebut menunjukkan bahwa proses sinkronisasi data antara node Primary dan Secondary berlangsung dengan cepat dan stabil. Hasil ini membuktikan bahwa mekanisme replikasi MongoDB Replica Set mampu menjaga ketersediaan data pada node Secondary tanpa menimbulkan keterlambatan yang berarti. Temuan penelitian juga menunjukkan bahwa karakteristik lingkungan pengujian memiliki pengaruh terhadap hasil yang diperoleh. Seluruh node MongoDB dijalankan pada satu mesin fisik yang sama melalui Docker sehingga latensi komunikasi antar node relatif rendah. Kondisi tersebut menyebabkan perbedaan performa antara Strong Consistency dan Eventual Consistency menjadi kurang terlihat secara signifikan karena proses komunikasi dan replikasi berlangsung dalam waktu yang sangat singkat. Secara keseluruhan, hasil penelitian menunjukkan bahwa Strong Consistency dan Eventual Consistency memberikan performa yang hampir setara dalam pengujian write latency, sementara MongoDB Replica Set mampu mempertahankan replication delay yang rendah dan stabil. Oleh karena itu, pemilihan tingkat konsistensi pada MongoDB Replica Set lebih dipengaruhi oleh kebutuhan jaminan konsistensi data yang diinginkan dibandingkan pertimbangan performa pada lingkungan pengujian yang digunakan. Kesimpulan Penelitian ini berhasil menganalisis pengaruh Strong Consistency dan Eventual Consistency terhadap write latency dan replication delay pada MongoDB Replica Set yang terdiri atas satu node Primary dan dua node Secondary. Pengujian dilakukan menggunakan volume data sebesar 10.000, 50.000, dan 100.000 dokumen dengan konfigurasi WriteConcern ("majority") untuk Strong Consistency dan WriteConcern(w=1) untuk Eventual Consistency. Hasil pengujian write latency menunjukkan bahwa kedua konfigurasi menghasilkan performa yang relatif setara. Eventual Consistency memperoleh write latency yang sedikit lebih rendah pada volume 10.000 dokumen, sedangkan Strong Consistency menghasilkan nilai yang sedikit lebih rendah pada volume 50.000 dan 100.000 dokumen. Namun, selisih yang diperoleh pada seluruh skenario pengujian relatif kecil sehingga tidak menunjukkan perbedaan performa yang signifikan. Hasil pengukuran replication delay menunjukkan rata-rata sebesar 0,023796 detik dengan nilai yang stabil pada setiap pengujian. Temuan ini menunjukkan bahwa mekanisme replikasi MongoDB Replica Set mampu menjaga sinkronisasi data antar node dengan cepat dan efisien selama proses pengujian berlangsung. Berdasarkan hasil penelitian, dapat disimpulkan bahwa Strong Consistency dan Eventual Consistency memberikan performa yang hampir setara pada lingkungan MongoDB Replica Set yang dijalankan dalam satu mesin fisik menggunakan Docker. Oleh karena itu, pemilihan tingkat konsistensi lebih dipengaruhi oleh kebutuhan jaminan konsistensi data yang diinginkan dibandingkan pertimbangan performa sistem pada lingkungan pengujian yang digunakan. Untuk penelitian selanjutnya, pengujian dapat dilakukan menggunakan beberapa mesin fisik yang terpisah, jumlah node yang lebih banyak, serta volume data yang lebih besar sehingga pengaruh tingkat konsistensi terhadap performa sistem terdistribusi dapat diamati secara lebih komprehensif. Ucapan Terima Kasih Penulis mengucapkan terima kasih kepada seluruh anggota tim yang telah bekerja sama dalam perancangan arsitektur MongoDB Replica Set, pelaksanaan pengujian, serta analisis data pada penelitian ini. Ucapan terima kasih juga disampaikan kepada Universitas Duta Bangsa Surakarta, khususnya Fakultas Ilmu Komputer, atas dukungan fasilitas dan kesempatan yang diberikan selama penelitian berlangsung. Referensi
[5] W. Uriawan, R. A. Fauzan, R. Z. Faroj, P. Pitriani, and R. Firmansyah, “Implementing Replica Set: Strategy to Improve the Performance of NoSQL Database Cluster in MongoDB,” 2024, doi: 10.20944/preprints202407.0449.v1.
[6] S. Ferreira, J. Mendonça, B. Nogueira, W. Tiengo, and E. Andrade, “Impacts of data consistency levels in cloud-based NoSQL for data-intensive applications,” J. Cloud Comput., vol. 13, no. 1, 2024, doi: 10.1186/s13677-024-00716-7.
[7] A. A. E. Alflahi, M. A. Y. Mohammed, and A. Alsammani, “Enhancement of Database Access Performance by Improving Data Consistency in a Non-relational Database System (NoSQL),” Lect. Notes Comput. Sci. (including Subser. Lect. Notes Artif. Intell. Lect. Notes Bioinformatics), vol. 14816 LNCS, pp. 194–205, 2024, doi: 10.1007/978-3-031-65223-3_13.
[8] S. Ferreira, J. Mendonca, B. Nogueira, W. Tiengo, and E. Andrade, “Benchmarking Consistency Levels of Cloud-Distributed NoSQL Databases Using YCSB,” IEEE Access, vol. 13, no. March, pp. 63428–63438, 2025, doi: 10.1109/ACCESS.2025.3558923.
[9] E. Dritsas and M. Trigka, “Database Systems in the Big Data Era: Architectures, Performance, and Open Challenges,” IEEE Access, vol. 13, no. June, pp. 95068–95084, 2025, doi: 10.1109/ACCESS.2025.3572059.
[10] T. Acquah, R. Amankwah, and B. Appiah, “Empirical Insights into Replication Models for Distributed Database Environments,” Int. J. Comput. Appl., vol. 186, no. 53, pp. 27–34, 2024, doi: 10.5120/ijca2024924212.
[11] P. Bhosale, “Data Consistency Models in Distributed Systems: CAP Theorem Revisited,” Int. J. Sci. Technol. IJSAT23031408, vol. 14, no. 3, pp. 1–11, 2023.
[12] H. A. Mahmoud and H. Maseeh Yasin, “Data Integrity and Consistency Challenges in Distributed Database Systems,” Eng. Technol. J., vol. 10, no. 05, pp. 5077–5086, 2025, doi: 10.47191/etj/v10i05.36.
[13] D. K. Siripurapu, “Real-Time Data Synchronization in Distributed Systems: a Comprehensive Analysis of Architectures, Strategies, and Implementation Technologies,” Int. J. Res. Comput. Appl. Inf. Technol., vol. 8, no. 1, pp. 3412–3424, 2025, [Online]. Available: https://iaeme.com/MasterAdmin/Journal_uploads/IJRCAIT/VOLUME_8_ISSUE_1/IJRCAIT_08_01_245.pdf
[14] A. Myrhorodskyi, “Comparison of data consistency models in distributed database management systems,” vol. 22, pp. 101–112, 2025, doi: 10.31649/vitce/3.2025.101.
