Sistem terdistribusi digunakan ketika ada kebutuhan untuk penskalaan horizontal untuk memberikan peningkatan indikator kinerja bahwa sistem skala vertikal tidak mampu menyediakan uang yang memadai.

Seperti transisi dari paradigma single-threaded ke multi-threaded, migrasi ke sistem terdistribusi membutuhkan semacam perendaman dan pemahaman tentang cara kerjanya di dalam, apa yang perlu Anda perhatikan.

Salah satu masalah yang dihadapi seseorang yang ingin memigrasi proyek ke sistem terdistribusi atau memulai proyek di atasnya adalah produk mana yang akan dipilih.

Kami, sebagai perusahaan yang “memakan seekor anjing” dalam pengembangan sistem semacam ini, membantu pelanggan kami untuk membuat keputusan berdasarkan informasi terkait dengan sistem penyimpanan terdistribusi. Kami juga merilis serangkaian webinar untuk audiens yang lebih luas yang fokus pada prinsip-prinsip dasar dalam bahasa yang sederhana, dan preferensi makanan tertentu apa pun membantu memetakan fitur-fitur penting untuk membuatnya lebih mudah untuk dipilih.

Artikel ini didasarkan pada materi kami tentang konsistensi dan jaminan ACID dalam sistem terdistribusi.

Apa itu dan mengapa itu dibutuhkan?

" Konsistensi data (terkadang konsistensi data ) adalah konsistensi data satu sama lain, integritas data, dan konsistensi internal." ( Wikipedia )

Konsistensi menyiratkan bahwa pada waktu tertentu, aplikasi dapat memastikan bahwa mereka bekerja dengan versi data yang benar, relevan secara teknis, dan dapat mengandalkannya ketika membuat keputusan.

Dalam sistem terdistribusi, memastikan konsistensi menjadi lebih sulit dan lebih mahal, karena serangkaian tantangan baru muncul terkait dengan pertukaran jaringan antara node yang berbeda, kemungkinan kegagalan masing-masing node dan - sering - kurangnya memori tunggal yang dapat digunakan untuk verifikasi.

Misalnya, jika saya memiliki sistem 4 simpul: A, B, C, dan D, yang melayani transaksi perbankan, dan simpul C dan D dipisahkan dari A dan B (katakanlah, karena masalah jaringan), sangat mungkin saya sekarang tidak Saya memiliki akses ke bagian dari transaksi. Bagaimana saya bertindak dalam situasi ini? Sistem yang berbeda mengambil pendekatan yang berbeda.


Di tingkat atas, ada 2 arah kunci yang dinyatakan dalam teorema CAP.

“ Teorema CAP (juga dikenal sebagai teorema Brewer ) adalah pernyataan heuristik bahwa dalam setiap implementasi komputasi terdistribusi, dimungkinkan untuk menyediakan tidak lebih dari dua dari tiga properti berikut:

• konsistensi data (Konsistensi bahasa Inggris) - di semua node komputasi pada satu titik waktu, data tidak saling bertentangan;
• ketersediaan (ketersediaan Inggris) - setiap permintaan ke sistem terdistribusi berakhir dengan respons yang benar, tetapi tanpa jaminan bahwa jawaban dari semua node sistem cocok;
• toleransi partisi - memecah sistem terdistribusi menjadi beberapa bagian yang terisolasi tidak mengarah ke respons yang salah dari setiap bagian. "

( Wikipedia )

Ketika teorema CAP berbicara tentang konsistensi, itu menyiratkan definisi yang agak ketat, termasuk linierisasi catatan dan bacaan, dan menetapkan hanya konsistensi ketika menulis nilai-nilai individual. ( Martin Kleppman )

Teorema CAP mengatakan bahwa jika kita ingin tahan terhadap masalah jaringan, maka secara umum kita harus memilih apakah akan berkorban: konsistensi atau aksesibilitas. Ada juga versi diperpanjang dari teorema ini - PACELC ( Wikipedia ), yang juga berbicara tentang fakta bahwa bahkan tanpa adanya masalah jaringan, kita harus memilih antara kecepatan respons dan konsistensi.

Dan meskipun, pada pandangan pertama, asli dari dunia DBMSs klasik, tampaknya pilihannya jelas dan konsistensi adalah hal yang paling penting yang kita miliki, ini jauh dari selalu, yang dengan jelas menggambarkan pertumbuhan eksplosif dari sejumlah DBMS NoSQL yang membuat pilihan dan Meskipun demikian, mereka mendapat basis pengguna yang sangat besar. Apache Cassandra dengan konsistensi akhirnya yang terkenal adalah contoh yang baik.

Ini semua karena fakta bahwa ini adalah pilihan yang menyiratkan bahwa kita mengorbankan sesuatu, dan kita tidak selalu siap untuk mengorbankannya.

Seringkali masalah konsistensi dalam sistem terdistribusi diselesaikan hanya dengan meninggalkan konsistensi ini.

Tetapi penting dan penting untuk memahami kapan penolakan terhadap konsistensi ini dapat diterima, dan ketika itu merupakan persyaratan bisnis yang kritis.

Misalnya, jika saya mendesain komponen yang bertanggung jawab untuk menyimpan sesi pengguna, di sini, kemungkinan besar, konsistensi tidak begitu penting bagi saya, dan kehilangan data tidak penting jika hanya terjadi pada kasus yang bermasalah - sangat jarang. Yang terburuk yang akan terjadi adalah bahwa pengguna harus masuk, dan bagi banyak bisnis ini hanya akan berdampak kecil pada kinerja keuangan mereka.

Jika saya melakukan analisis pada aliran data dari sensor, dalam banyak kasus itu sama sekali tidak kritis bagi saya untuk kehilangan beberapa data dan mendapatkan downsampling untuk waktu yang singkat, terutama jika saya akhirnya melihat datanya.

Tetapi jika saya membuat sistem perbankan, konsistensi transaksi tunai sangat penting untuk bisnis saya. Jika saya mendapat penalti atas pinjaman klien karena fakta bahwa saya tidak melihat pembayaran dilakukan tepat waktu, meskipun ia ada dalam sistem, ini sangat, sangat buruk. Serta jika klien dapat menarik semua uang dari kartu kredit saya beberapa kali, karena saya punya masalah jaringan pada saat transaksi, dan informasi penarikan tidak mencapai bagian dari cluster saya.

Jika Anda melakukan pembelian mahal di toko online, Anda tidak ingin pesanan Anda dilupakan, meskipun ada laporan sukses di halaman web.

Tetapi jika Anda memilih untuk konsistensi, Anda mengorbankan aksesibilitas. Dan seringkali ini diharapkan, kemungkinan besar, Anda telah menemukan ini secara pribadi lebih dari sekali.

Lebih baik jika keranjang toko online mengatakan "coba nanti, DBMS yang didistribusikan tidak tersedia" daripada jika melaporkan keberhasilan dan lupa pesanan. Lebih baik untuk mendapatkan penolakan dalam transaksi karena tidak tersedianya layanan bank daripada mengalahkan kesuksesan dan kemudian proses dengan bank karena fakta bahwa dia lupa bahwa Anda membayar pinjaman.

Akhirnya, jika kita melihat pada teorema PACELC yang diperluas, maka kita memahami bahwa bahkan dalam kasus operasi reguler sistem, memilih konsistensi, kita dapat mengorbankan latensi rendah, mendapatkan tingkat kinerja maksimum yang berpotensi lebih rendah.

Oleh karena itu, menjawab pertanyaan "mengapa ini perlu?": Penting jika tugas Anda penting untuk memiliki data yang konsisten dan terbaru, dan alternatifnya akan membawa Anda kerugian yang signifikan lebih besar daripada tidak tersedianya sementara layanan selama periode insiden atau kinerjanya yang lebih rendah.

Bagaimana cara menyediakan ini?

Dengan demikian, keputusan pertama yang perlu Anda buat adalah di mana Anda berada dalam teorema CAP, Anda ingin konsistensi atau ketersediaan jika terjadi insiden.

Selanjutnya, Anda perlu memahami pada level apa Anda ingin melakukan perubahan. Mungkin Anda hanya memiliki cukup catatan atom yang mempengaruhi satu objek, karena MongoDB mampu dan mampu (sekarang ini memperluas ini dengan dukungan tambahan untuk transaksi penuh). Biarkan saya mengingatkan Anda bahwa teorema CAP mengatakan apa-apa tentang konsistensi operasi tulis yang melibatkan banyak objek: sistem mungkin CP (yaitu, lebih memilih konsistensi aksesibilitas) dan pada saat yang sama hanya memberikan catatan tunggal atom.

Jika ini tidak cukup untuk Anda, kami mulai mendekati konsep transaksi ACID terdistribusi penuh.

Saya perhatikan bahwa bahkan ketika pindah ke dunia baru transaksi ACID terdistribusi, kita sering harus mengorbankan sesuatu. Sebagai contoh, sejumlah sistem penyimpanan terdistribusi telah mendistribusikan transaksi, tetapi hanya dalam satu partisi. Atau, misalnya, sistem mungkin tidak mendukung bagian "I" pada level yang Anda butuhkan, tanpa isolasi, atau dengan jumlah level isolasi yang tidak mencukupi.

Pembatasan ini sering dibuat untuk beberapa alasan: baik untuk menyederhanakan implementasi, atau, misalnya, untuk meningkatkan kinerja, atau untuk hal lain. Mereka cukup untuk sejumlah besar kasus, jadi Anda tidak boleh menganggapnya sebagai kontra sendiri.

Anda perlu memahami jika pembatasan ini merupakan masalah untuk skenario spesifik Anda. Jika tidak, Anda memiliki lebih banyak pilihan, dan Anda dapat memberikan bobot lebih, misalnya, untuk indikator kinerja atau kemampuan sistem untuk memberikan toleransi bencana, dll. Akhirnya, kita tidak boleh lupa bahwa dalam sejumlah sistem, parameter ini dapat disesuaikan hingga sistem dapat berupa CP atau AP tergantung pada konfigurasi.

Jika produk kami bertujuan menjadi CP, maka biasanya ia memiliki pendekatan kuorum untuk pemilihan data, atau node khusus yang merupakan pemilik utama catatan, semua perubahan data melewati mereka, dan jika terjadi masalah jaringan, jika node master ini tidak dapat memberikan jawabannya, diyakini bahwa data, pada prinsipnya, tidak dapat diperoleh, atau arbitrase, ketika komponen eksternal yang sangat mudah diakses (misalnya, kluster ZooKeeper) dapat mengatakan segmen segmen mana yang merupakan yang utama, berisi versi data saat ini dan dapat melayani permintaan secara efisien s.

Akhirnya, jika kita tertarik bukan hanya pada CP, tetapi untuk mendukung transaksi ACID terdistribusi penuh, maka sering satu sumber kebenaran sering digunakan, misalnya, penyimpanan disk terpusat, di mana node kita, pada kenyataannya, hanya bertindak sebagai cache untuk itu, yang dapat dinonaktifkan di waktu komit, atau protokol komit multifase diterapkan.

Pendekatan disk tunggal pertama juga menyederhanakan implementasi, memberikan latensi rendah pada transaksi terdistribusi, tetapi berdagang dengan imbalan skalabilitas yang sangat terbatas pada beban dengan volume rekaman besar.

Pendekatan kedua memberi lebih banyak kebebasan dalam penskalaan, dan, pada gilirannya, dibagi menjadi protokol komitmen dua fase ( Wikipedia ) dan tiga fase ( Wikipedia ).

Pertimbangkan komit dua fase yang menggunakan, misalnya, Apache Ignite.



Prosedur komit dibagi menjadi 2 fase: persiapan dan komit.

Dalam fase persiapan, sebuah pesan disiapkan tentang persiapan untuk komit, dan setiap peserta, jika perlu, membuat kunci, melakukan semua operasi hingga dan termasuk komit aktual, dan mengirimkan persiapan ke replika-replika-nya, jika hal ini dianggap oleh produk. Jika setidaknya salah satu peserta merespons dengan penolakan karena alasan tertentu atau ternyata tidak tersedia - data tidak benar-benar berubah, tidak ada komitmen. Peserta mengembalikan perubahan, melepaskan kunci dan kembali ke keadaan semula.

Dalam fase komit, eksekusi aktual dari komit dikirim ke node cluster. Jika karena alasan tertentu beberapa node tidak tersedia atau merespons dengan kesalahan, maka pada saat itu data dimasukkan dalam redo-log mereka (karena persiapan berhasil), dan komit dalam kasus apa pun dapat diselesaikan setidaknya dalam keadaan tertunda.

Akhirnya, jika koordinator gagal, maka pada tahap persiapan komit akan dibatalkan, pada tahap komit, koordinator baru dapat dipilih, dan jika semua node telah menyelesaikan persiapan, ia dapat memeriksa dan memastikan bahwa tahap komit selesai.

Berbagai produk memiliki fitur implementasi dan optimisasi mereka sendiri. Jadi, misalnya, beberapa produk dalam beberapa kasus dapat mengurangi komitmen 2 fase menjadi komitmen 1 fase, memenangkan kinerja yang signifikan.

Kesimpulan

Kesimpulan utama: sistem penyimpanan terdistribusi adalah pasar yang cukup maju, dan produk di atasnya dapat memberikan konsistensi data yang tinggi.

Selain itu, produk dari kategori ini terletak pada titik yang berbeda dari skala konsistensi, dari produk AP sepenuhnya tanpa transaksionalitas ke produk CP yang tambahan memberikan transaksi ACID penuh. Beberapa produk dapat dikonfigurasi dengan satu atau lain cara.

Ketika Anda memilih apa yang Anda butuhkan, Anda perlu memperhitungkan kebutuhan kasus Anda dan memahami dengan baik pengorbanan dan kompromi yang Anda ingin lakukan, karena tidak ada yang terjadi secara gratis, dan memilih satu, kemungkinan besar Anda akan menolak sesuatu yang lain.

Saat mengevaluasi produk dari sisi ini, ada baiknya memperhatikan hal-hal berikut:

• di mana mereka berada di teorema CAP;
• Apakah mereka mendukung transaksi ACID terdistribusi?
• pembatasan apa yang mereka tetapkan pada transaksi terdistribusi (misalnya, hanya dalam satu partisi, dll);
• Kenyamanan dan efisiensi menggunakan transaksi terdistribusi, integrasi mereka ke dalam komponen produk lainnya.