Backends dan UX yang konsisten: Bagaimana algoritma baru membantu?

Siri artikel

1. Mengapa anda perlu memberi perhatian?
2. Masalah apa yang mungkin berlaku?
3. Apakah halangan yang diterima pakai?
4. Bagaimanakah algoritma baru membantu?

Artikel terdahulu menerangkan apa yang konsisten data, perbezaan antara "konsistensi kuat" dan "konsistensi muktamad" dan mengapa perbezaan ini lebih penting kepada pemaju aplikasi moden berbanding sebelum ini. Kami juga memperkenalkan konsep "cukai konsisten": jika pasukan pembangunan memilih sistem yang hanya mempunyai konsistensi akhir atau jaminan konsistensi terhad, ia memerlukan masa dan usaha tambahan.

Banyak pangkalan data moden menggunakan algoritma terkini untuk menghapuskan perdagangan antara konsistensi dan prestasi. Sudah tentu, kami tidak mahu anda mempercayai pernyataan kami tanpa penjelasan yang betul. Oleh itu, pada bahagian terakhir artikel ini, kami akan menggali butiran teknikal di sebalik beberapa pangkalan data ini. Biasanya, satu -satunya sumber maklumat untuk butiran teknikal ini adalah kertas penyelidikan, jadi tujuan artikel ini adalah untuk menerangkan sistem ini dalam istilah yang lebih mudah. Oleh kerana sistem ini lebih kompleks dalam realiti, jika anda ingin mengetahui lebih lanjut dan menikmati membaca kertas penyelidikan, kami akan menyediakan pautan dalam teks.

Pengenalan

Dalam Bahagian 1 dan 2 siri ini, kami menerangkan bagaimana pangkalan data yang diedarkan menggunakan beban pengedaran replika yang berbeza dan/atau melayani pengguna di kawasan yang berbeza. Untuk meringkaskan, untuk pembaca baru, satu salinan hanyalah satu salinan data. Replika ini boleh terletak di lokasi yang sama untuk redundansi atau di lokasi lain untuk memberikan latensi yang lebih rendah kepada pengguna lokasi ini. Mempunyai pelbagai replika yang boleh mengendalikan operasi membaca dan menulis mempunyai kelebihan yang kuat kerana pangkalan data menjadi berskala dan dapat memberikan latensi yang lebih rendah kepada semua pengguna, tidak kira di mana mereka berada. Walau bagaimanapun, anda tidak mahu setiap replika mempunyai tafsiran sendiri mengenai data. Anda memerlukan tafsiran unik data, yang sering disebut sebagai satu sumber fakta, bukannya perbezaan data yang halus antara setiap replika. Untuk mencapai matlamat ini, anda perlu mencapai beberapa konsensus mengenai perubahan data. Kami memerlukan konsensus.

Tunggu konsensus

Setiap pangkalan data yang diedarkan yang direka untuk mengekalkan konsistensi mempunyai banyak replika yang mesti bersetuju dengan hasil transaksi. Sekiranya kemas kini data yang bercanggah berlaku, replika ini mesti bersetuju dengan yang dikemas kini dan kemas kini yang tidak. Ini dipanggil "konsensus."

Mari kita kembali ke permainan kita untuk menggambarkan mengapa kita memerlukan konsensus. Katakan pemain kami hanya mempunyai 3 syiling emas yang tersisa, tetapi cuba membeli dua item yang berbeza dari dua kedai yang berbeza pada masa yang sama, dengan jumlah anggaran melebihi baki 3 syiling emas. Ini melibatkan dua transaksi, masing -masing sepadan dengan projek/kedai, yang kami mewakili sebagai T1 dan T2. Mari kita anggap bahawa pemilik kedai beribu -ribu batu selain antara satu sama lain, jadi transaksi berlaku pada dua salinan yang berbeza. Jika dua transaksi diterima, pengguna akan dapat membeli item yang melebihi keupayaan mereka untuk menanggung. Bagaimanakah kita menghalang pengguna daripada melampaui overspending?

Kami tahu bahawa replika ini perlu berkomunikasi untuk bersetuju dengan hasil akhir kedua -dua transaksi ini. Apa yang kita tidak tahu ialah berapa banyak komunikasi yang mereka perlukan. Untuk menyetujui urus niaga yang diberikan keutamaan dan transaksi mana yang dibatalkan, berapa banyak mesej yang perlu dihantar ke belakang antara replika 1 dan replika 2?

Kerana replika dalam pangkalan data yang diedarkan direka untuk melayani pengguna di berbagai belahan dunia dengan latensi yang rendah, mereka pada dasarnya jauh. Dengan meletakkan salinan data pada pelayan lebih dekat kepada pengguna akhir, pengguna ini boleh membaca dengan latensi yang lebih rendah. Walau bagaimanapun, apabila operasi menulis berlaku, replika perlu menghantar mesej kepada satu sama lain untuk mengemas kini seragam semua data pendua -sebagai mesej ini dibatasi oleh kelajuan cahaya apabila menyebarkan secara global, mereka boleh mengambil puluhan milisaat. Adalah jelas bahawa kita perlu meminimumkan bilangan mesej di seluruh pusat data supaya pengguna akhir tidak menunggu konsensus mengenai replika ini di seluruh dunia.

Ia telah lama dipercayai bahawa berbuat demikian adalah mustahil atau tidak praktikal. Tetapi pada masa kini, terdapat pelbagai teknik yang dapat mengekalkan perjalanan bulat pada tahap yang rendah dan mengekalkan kelewatan dalam julat normal.

Jarak antara New York dan Paris adalah 5839 km. Ia memerlukan 40 milisaat untuk perjalanan dari New York ke Paris dan kemudian kembali.

- Kelajuan teori dan kelajuan dunia sebenar

Soalan yang paling penting ialah: "Berapa banyak perjalanan pusingan transaksi yang perlu kita lakukan?" Jawapan kepada soalan ini bergantung pada algoritma yang digunakan.

Bagaimana untuk mencapai persetujuan?

Nampaknya untuk mencapai persetujuan mengenai sesuatu, anda memerlukan sekurang -kurangnya empat hop (atau dua pusingan komunikasi): Satu pusingan membiarkan setiap replika tahu bahawa anda akan melakukan sesuatu, dan kemudian pusingan kedua sebenarnya melakukan tindakan selepas semua orang bersetuju bahawa anda boleh melakukannya. Ini adalah kaedah yang dipanggil penyerahan dua peringkat yang diedarkan, yang digunakan oleh hampir semua pangkalan data yang diedarkan. Mari lihat metafora. Katakan anda harus bersetuju dengan sekumpulan orang pada tarikh yang tepat untuk parti. Ini mungkin kelihatan seperti ini:

Pertama, Polly bertanya kepada semua orang jika mereka boleh berpesta pada hari Isnin; Dia kini tahu bahawa semua orang sebenarnya boleh datang ke pesta. Seterusnya, dia perlu membiarkan semua orang tahu bahawa parti itu akan diadakan pada hari Isnin dan orang mengakui mereka akan datang.

Ini sangat mirip dengan dua peringkat dalam penyerahan dua peringkat. Sudah tentu, pangkalan data tidak akan menjadi tuan rumah pihak, jadi peringkat ini mempunyai fungsi yang berbeza. Dalam kes sistem yang diedarkan, peringkat ini dipanggil:

• Sediakan atau minta penyerahan : Pastikan semua orang menyedari urus niaga. Pada peringkat ini, replika dalam pangkalan data yang diedarkan akan menanyakan dalam beberapa jenis senarai tugasan (log transaksi) yang disimpan pada cakera untuk memastikan mereka masih tahu apa yang perlu dilakukan apabila pelayan turun.
• Hantar : Hasil pengiraan sebenar dan simpannya

Sudah tentu, seperti biasa, perkara -perkara tidak begitu mudah. Terdapat banyak variasi algoritma tersebut. Sebagai contoh, terdapat penyerahan dua peringkat yang diperbaiki, dipanggil paxos dan rakit, dan terdapat banyak varian ini (multi-paxos/paxos cepat/...). Alternatif ini direka untuk menangani masalah ketersediaan atau prestasi. Untuk memahami isu kebolehgunaan, bayangkan Polly mendapat sakit atau telefon amber tidak berkuasa. Dalam kes bekas, dia tidak akan dapat meneruskan sebagai penyelaras parti; Dalam kes yang kedua, Polly tidak akan dapat mengetahui sama ada Amber bersetuju dengan tarikh parti. Rakit dan Paxos memperbaiki ini dengan meminta hanya kebanyakan orang untuk menjawab dan/atau secara automatik memilih penyelaras baru apabila pemimpin atau penyelaras turun. Di sini anda boleh mencari animasi yang baik yang menunjukkan bagaimana rakit berfungsi.

Untuk mencapai persetujuan mengenai apa?

Bolehkah kita menyimpulkan bahawa setiap pangkalan data yang diedarkan memerlukan 2 perjalanan bulat untuk membaca dan menulis data? Tidak, realiti lebih rumit daripada ini. Di satu pihak, terdapat banyak pengoptimuman yang mungkin, dan sebaliknya, kita mungkin perlu bersetuju dengan pelbagai perkara.

• Setuju pada masa perkara itu
• Bersetuju sama ada operasi bacaan boleh dilakukan

Contoh yang paling mudah dengan pelbagai pusingan dua peringkat mungkin merupakan transaksi ringan Cassandra. Mereka perlu mencapai persetujuan konsensus mengenai bacaan, dan kemudian mereka perlu mencapai konsensus mengenai menulis. Jika setiap mesej mengambil 40 milisaat untuk menyebarkan, ini bermakna keseluruhan transaksi mengambil 320 milisaat atau lebih - bergantung kepada "kunci" yang diperlukan, yang akan kita jelaskan kemudian.

Ini mudah difahami, tetapi terdapat beberapa masalah dengan pelaksanaan, kerana Cassandra tidak pernah direka untuk menjadi konsistensi yang kuat. Adakah ini bermakna bahawa pangkalan data konsistensi yang kuat lebih perlahan? sama sekali tidak! Pangkalan data yang diedarkan moden menggunakan pelbagai ciri menarik untuk mencapai prestasi yang lebih baik.

Tunggu kunci

Bukan sahaja kita perlu menunggu mesej itu bersetuju, tetapi hampir setiap pangkalan data yang diedarkan juga akan menggunakan "kunci". Kunci memastikan bahawa data yang akan diubah oleh transaksi tidak akan diubah serentak oleh transaksi lain. Apabila data dikunci, urus niaga lain tidak dapat mengubahnya, yang bermaksud bahawa urus niaga ini perlu menunggu. Oleh itu, tempoh kunci tersebut mempunyai kesan yang besar terhadap prestasi. Sekali lagi, kesan prestasi ini bergantung kepada algoritma dan pengoptimuman yang dilaksanakan oleh pangkalan data. Sesetengah pangkalan data memegang kunci lebih lama daripada yang lain, sementara beberapa pangkalan data tidak menggunakan kunci sama sekali.

Sekarang kita telah mempelajari pengetahuan asas yang cukup, kita dapat mendapatkan pemahaman yang lebih mendalam tentang algoritma.

Algoritma konsensus moden

Sekarang kita tahu bahawa konsensus dan kunci adalah kesesakan utama yang kita perlukan untuk mengoptimumkan. Oleh itu, mari kita kembali ke soalan utama artikel ini: "Bagaimanakah teknologi baru dapat mengawal kelewatan ini ke julat yang boleh diterima?" Mari kita mulakan dengan yang pertama dari algoritma moden ini, yang mengilhami beberapa idea menarik di kawasan lain di dunia pangkalan data.

2010 - Percolator

Percolator adalah sistem dalaman berdasarkan BigTable, salah satu pangkalan data NoSQL awal yang dibina oleh Google, yang digunakan Google untuk mengemas kini secara bertahap halaman merangkak kelajuan indeks carian. Kertas pertama mengenai Percolator telah diterbitkan pada tahun 2010, dan ia mengilhami pangkalan data yang diedarkan pertama yang diilhamkan olehnya: FoundationDB pada tahun 2013. FoundationDB kemudiannya diperolehi oleh Apple, dan akhirnya mengeluarkan versi yang stabil pada tahun 2019, serta kertas asas.

Walaupun Percolator membenarkan Google untuk mempercepatkan halaman merangkak, ia tidak pada asalnya dibina sebagai pangkalan data tujuan umum. Ia lebih direka untuk menjadi enjin pemprosesan tambahan yang cepat dan berskala untuk menyokong pengindeksan carian Google. Oleh kerana indeks carian mesti berskala, banyak perhitungan mesti dilakukan secara serentak pada banyak mesin, yang memerlukan pangkalan data yang diedarkan. Seperti yang kita pelajari dalam artikel terdahulu, pengaturcaraan untuk sistem yang diedarkan yang menyimpan data boleh menjadi kompleks dan secara tradisinya memerlukan pemaju untuk membayar "cukai konsisten" untuk menangani tingkah laku pangkalan data yang tidak dapat diramalkan. Untuk mengelakkan membayar cukai konsistensi yang tinggi, Google mengguna pakai model konsistensi yang kuat ketika membina percolator.

Model konsistensi Percolator tidak dapat wujud tanpa dua elemen utama: Kawalan Versi dan Timestamp Oracle

Elemen 1: Kawalan Versi

Seperti yang telah kami nyatakan dalam artikel kami yang terdahulu, konsistensi yang kuat mengharuskan kami menyetujui susunan urus niaga global. Versioning adalah salah satu elemen utama banyak algoritma tersebut kerana ia boleh digunakan untuk pemulihan kegagalan, membantu meniru data, dan menyokong model konsistensi yang disebut "pengasingan snapshot."

Kawalan versi membantu dengan pemulihan kegagalan apabila nod gagal atau terputus. Apabila nod kembali dalam talian, disebabkan kewujudan versi, ia dapat dengan mudah memulihkan keadaannya dengan memulakan dari snapshot terakhir yang dapat disimpan dan kemudian memainkan semula urus niaga berdasarkan versi dalam nod lain. Apa yang perlu dilakukan ialah bertanya nod lain: "Hei, apa yang telah berubah sejak saya tidak berada di sini?" Tanpa kawalan versi, ia perlu menyalin semua data, yang akan meletakkan banyak tekanan pada sistem.

Pemulihan kegagalan adalah hebat, tetapi kelebihan terbesar ialah sistem kawalan jenis jenis ini boleh digunakan untuk melaksanakan model konsistensi yang kuat. Jika sistem kawalan versi menyimpan versi setiap perubahan data, kita sebenarnya boleh kembali pada masa lalu dan melakukan pertanyaan terhadap versi terdahulu data kami.

Sesetengah orang pandai mendapati bahawa ciri pertanyaan sejarah ini boleh digunakan untuk menyediakan model konsistensi yang dipanggil "Konsistensi Snapshot." Idea konsistensi snapshot adalah untuk memilih versi data pada permulaan pertanyaan, gunakan nombor versi itu untuk pertanyaan yang lain, dan kemudian tulis versi baru pada akhir pertanyaan.

Terdapat kemungkinan perangkap di sini: Semasa pelaksanaan pertanyaan sedemikian, pertanyaan lain boleh menulis data yang bertentangan dengan pertanyaan pertama. Sebagai contoh, jika kedua -dua pertanyaan menulis bermula dengan gambar yang sama dari akaun bank ($ 1,000 pada akaun), kedua -duanya boleh menelan belanja wang kerana mereka tidak melihat menulis pertanyaan lain. Untuk mengelakkan ini, transaksi tambahan dilakukan untuk melihat apakah nilai snapshot telah berubah sebelum sebarang pertanyaan ditulis kepada hasilnya. Sekiranya konflik berlaku yang menyebabkan perubahan dalam nilai snapshot, urus niaga akan dilancarkan semula dan mesti dimulakan semula.

Walau bagaimanapun, percolator masih perlu menyelesaikan satu masalah. Jam pada mesin yang berbeza boleh berubah dengan mudah oleh beratus -ratus milisaat. Jika data pertanyaan diedarkan di pelbagai mesin (seperti dalam contoh awal kami), anda tidak boleh hanya memerlukan kedua -dua mesin untuk menyediakan data dengan setem masa, kerana mereka mempunyai pemahaman yang sedikit berbeza pada masa semasa. Ini adalah masalah milisaat, tetapi apabila banyak urus niaga perlu diproses, beberapa milisaat cukup untuk pergi dari data yang betul ke data yang salah.

Penyegerakan masa mengingatkan kita tentang elemen kedua Percolator.

Elemen 2: Oracle Timestamp

Penyelesaian untuk percolator untuk menyelesaikan masalah penyegerakan masa dipanggil oracle timestamp. Daripada membiarkan setiap nod memutuskan masa itu sendiri (yang tidak cukup tepat), Percolator menggunakan sistem pusat mendedahkan API untuk menyediakan cap waktu. Node di mana sistem ini terletak adalah oracle timestamp. Apabila kita menyimpan pelbagai versi data, setiap pertanyaan memerlukan sekurang -kurangnya dua cap waktu. Pertama, kita memerlukan cap waktu untuk menanyakan gambar, yang akan kita gunakan untuk membaca data. Kemudian, apabila kita sudah bersedia untuk menulis, pada akhir transaksi, kita memerlukan cap waktu kedua untuk menandakan versi data baru. Oleh itu, kelemahan percolator adalah bahawa ia memerlukan sekurang -kurangnya dua panggilan ke timestamp Oracle, yang memperkenalkan lebih banyak latensi jika ia terletak di kawasan yang berbeza daripada nod sumber panggilan. Apabila Google mencadangkan Spanner Pangkalan Data yang diedarkan, mereka menyelesaikan masalah tersebut.

2012 - Spanner

Spanner adalah pangkalan data yang diedarkan global pertama untuk memberikan konsistensi yang kuat, yang pada dasarnya bermakna anda boleh mendapatkan latensi rendah yang dibaca tanpa perlu risau tentang kesilapan pangkalan data yang berpotensi lagi. Pemaju tidak lagi memerlukan kerja tambahan untuk mengelakkan kesilapan berpotensi yang disebabkan oleh konsistensi akhir. Kertas itu diterbitkan pada tahun 2012 dan diterbitkan secara terbuka pada tahun 2017 sebagai Spanner Cloud.

Elemen 1: Kawalan Versi

Google membina spanner selepas pengalaman menggunakan percolator. Kerana sistem kawalan versi Percolator terbukti berkesan, mereka mengekalkan ini dalam reka bentuk Spanner. Sistem kawalan versi ini menyediakan keupayaan untuk melakukan bacaan yang sangat cepat (snapshot Reads) apabila anda sanggup melepaskan konsistensi. Dalam kes ini, anda boleh menjalankan pertanyaan dan memberikan umur maksimum untuk hasilnya kepada Spanner. Sebagai contoh: "Sila kembalikan inventori semasa saya secepat mungkin, tetapi data hanya boleh dari 15 saat yang lalu." Pada asasnya, anda boleh memilih tahap konsistensi yang sesuai dengan kes penggunaan anda untuk setiap pertanyaan, dan bukannya meninggalkan konsistensi.

Elemen 2: Trueetime

Untuk menghapuskan overhead masa tambahan antara mesin yang disegerakkan, Spanner meninggalkan Oracle Timestamp memihak kepada konsep baru yang dipanggil Trueetime. Daripada menggunakan sistem pusat untuk memberikan pandangan masa yang bersatu, percubaan tiga kali untuk mengurangkan hanyut jam pada mesin itu sendiri. Jurutera Google mengehadkan hanyut jam tempatan dengan melaksanakan protokol penyegerakan masa berdasarkan GPS dan jam atom. Algoritma penyegerakan ini membolehkan mereka mengehadkan jam hanyut kepada kurang daripada 7 milisaat, tetapi ini memerlukan perkakasan tertentu dari gabungan teknologi GPS dan atom.

Sudah tentu, masih terdapat hanyut jam yang berpotensi sebanyak 7 milisaat, yang bermaksud bahawa kedua -dua pelayan masih boleh mentafsir cap waktu sebagai dua gambar yang berbeza. Ini diselesaikan oleh Elemen Ketiga Spanner: Hantar Menunggu.

Elemen 3: Hantar Menunggu

Malah, API Trueetime tidak mengembalikan cap waktu, tetapi selang n, yang menentukan bahawa cap waktu semasa harus berada dalam selang waktu itu. Sebaik sahaja anda sudah bersedia untuk menyerahkan, ia hanya perlu menunggu beberapa milisaat untuk menangani potensi drift, yang dipanggil "komit menunggu". Ini memastikan bahawa timestamp yang ditugaskan untuk menulis adalah cap waktu yang telah diluluskan pada semua nod. Ini juga mengapa menjalankan Spanner pada perkakasan komoditi tidak memberikan jaminan yang sama, kerana masa menunggu mengambil beratus -ratus milisaat.

2012 - Calvin

Kertas pertama mengenai algoritma Calvin diterbitkan pada tahun 2012, dari penyelidikan Yale University. Seperti penyelesaian sebelumnya, Calvin juga mengandungi beberapa elemen. Walaupun versi adalah sebahagian daripadanya, selebihnya kaedahnya agak berbeza, yang memerlukan beberapa elemen tambahan berfungsi: pengiraan deterministik dan memisahkan penyortiran dari mengunci. Ini sering tidak dijumpai dalam pangkalan data dengan seni bina tradisional. Dengan menukar skema dan menerima pertanyaan mestilah deterministik, Calvin dapat mengurangkan jumlah mesej terburuk di seluruh pusat data kepada dua . Ini sangat mengurangkan latensi terburuk dalam urus niaga global dan mengurangkannya di bawah 200 milisaat, atau secara teorinya walaupun di bawah 100 milisaat. Sudah tentu, untuk mempercayai ini adalah mungkin, anda mungkin terlebih dahulu ingin tahu bagaimana ia berfungsi, jadi mari kita lihat algoritma.

Elemen 1: Kawalan Versi

Sama seperti Percolator dan Spanner, Calvin juga bergantung pada data versi. Gambar -gambar di Calvin ini digunakan terutamanya untuk memastikan toleransi kesalahan. Setiap nod menyimpan gambar yang berbeza, yang boleh dianggap sebagai pusat pemeriksaan. Selepas nod yang terputus kembali dalam talian, hanya dapatkan cap waktu pusat pemeriksaan terakhir yang telah disaksikan dan minta nod lain untuk memberitahu semua transaksi selepas pusat pemeriksaan itu.

Elemen 2: pengiraan deterministik

Banyak pemaju front-end telah mendengar rangka kerja front-end ELM, yang melaksanakan aliran kerja yang serupa dengan React Redux. ELM mempunyai keluk pembelajaran yang lebih curam daripada rangka kerja berasaskan JavaScript yang serupa, kerana ia memerlukan anda mempelajari bahasa baru. Walau bagaimanapun, kerana bahasa itu berfungsi (tanpa kesan sampingan), ELM membolehkan beberapa pengoptimuman yang mengagumkan. Kuncinya ialah fungsi dalam ELM menyerahkan operasi merosakkan untuk menjadi deterministik. Anda boleh menjalankan fungsi yang sama dua kali dengan input yang sama dan ia akan menghasilkan hasil yang sama. Oleh kerana mereka adalah deterministik, pertanyaan Elm kini membuat keputusan yang lebih cekap tentang cara mengemas kini pandangan.

Sama seperti ELM, Calvin juga menyerah pada sesuatu untuk mempercepatkan pengiraan. Dalam kes Calvin, kita pada dasarnya boleh mengatakan bahawa hasil transaksi akan sama, sama ada ia dilaksanakan pada mesin A atau mesin B. Ini kelihatan jelas, tetapi pangkalan data umumnya tidak menjamin ini. Ingat bahawa SQL membolehkan anda menggunakan masa semasa atau membenarkan transaksi interaktif yang dipanggil di mana input pengguna boleh dimasukkan di tengah-tengah transaksi, yang kedua-duanya mungkin melanggar jaminan yang disediakan oleh Calvin.

Untuk mencapai pengiraan deterministik, Calvin (1) perlu mengambil pengiraan seperti masa semasa dan pra-mengira mereka, dan (2) tidak membenarkan urus niaga interaktif. Urus niaga interaktif adalah urus niaga yang pengguna memulakan transaksi, membaca beberapa data, memberikan beberapa input pengguna tambahan di tengah, dan akhirnya melakukan beberapa pengiraan tambahan dan beberapa transaksi bertulis. Oleh kerana pengguna tidak dapat diramalkan, urus niaga tersebut tidak ditentukan. Pada asasnya, Calvin berdagang kurang kemudahan (urus niaga interaktif) untuk prestasi cemerlang.

Isu penyortiran berasingan

Pangkalan data membelanjakan banyak masa untuk merundingkan kunci untuk menjadikannya kelihatan seperti sistem yang dilaksanakan dalam urutan tertentu ". Jika semua yang anda perlukan adalah pesanan, mungkin kita dapat memisahkan masalah mengunci dari masalah penyortiran. Tetapi itu bermakna urus niaga anda harus suci.

- Kyle Kingsbury

Memisahkan isu penyortiran transaksi dari pelaksanaan sebenar telah dianggap banyak kali dalam bidang pangkalan data, tetapi dengan sedikit kejayaan. Walau bagaimanapun, apabila urus niaga anda menentukan, ia sebenarnya boleh dilaksanakan untuk memisahkan jenis dari seluruh algoritma. Malah, gabungan pengiraan deterministik dan memisahkan jenis dari seluruh algoritma sangat kuat kerana ia membantu mengurangkan tempoh kunci dan mengurangkan komunikasi yang lebih perlahan antara nod jauh (komunikasi pusat trans-data).

Tempoh kunci yang lebih pendek

Setiap kali kunci diadakan pada sebahagian daripada data, ini bermakna bahawa pertanyaan lain menggunakan data itu mesti menunggu. Oleh itu, lebih pendek tempoh kunci, lebih baik prestasi. Angka berikut menunjukkan gambaran keseluruhan proses penguncian di Calvin dan bagaimana pangkalan data yang diedarkan tradisional mungkin melakukan ini. Kebanyakan pangkalan data terus dikunci pada data sehingga sekurang -kurangnya bersetuju dengan kandungan tulis, sementara Calvin hanya terus dikunci sehingga semua nod bersetuju dengan perintah itu. Oleh kerana pengiraan adalah deterministik dan mereka semua bersetuju dengan perintah, setiap nod akan mengira secara individu dan menghasilkan hasil akhir yang sama.

Mengurangkan komunikasi antara nod jauh

Sebagai tambahan kepada kelebihan tempoh kunci, memisahkan jenis dari seluruh algoritma memerlukan kurang komunikasi. Seperti yang dijelaskan sebelum ini menggunakan contoh Cassandra, pangkalan data yang diedarkan sering memerlukan komunikasi pusat cross data di banyak peringkat algoritma mereka. Dalam kes Calvin, satu -satunya saat kita perlu bersetuju dengan sesuatu adalah momen di mana kita menentukan perintah itu. Menggunakan protokol rakit, ini boleh dilakukan dalam dua hop, yang membolehkan kelewatan kurang daripada 100 milisaat untuk membaca dan menulis pertanyaan.

Digabungkan dengan masa kunci yang dikurangkan, ini juga membawa throughput yang sangat tinggi. Kertas Calvin yang asal juga menjalankan eksperimen yang menunjukkan bahawa pendekatan ini secara signifikan mengatasi reka bentuk pangkalan data yang diedarkan tradisional di bawah beban kerja pertikaian yang tinggi. Keputusan mereka melakukan 500,000 transaksi sesaat pada kluster mesin komoditi bersaing dengan hasil rekod dunia semasa yang diperolehi pada perkakasan mewah.

Jalankan perkakasan

Selain itu, Calvin mempunyai kelebihan lain: ia tidak lagi memerlukan perkakasan khusus untuk mendapatkan hasil tersebut. Oleh kerana Calvin boleh berjalan pada mesin komoditi, ia boleh berjalan di mana -mana pembekal awan.

2014 - Gaya Konsensus FaunAdb

Elemen 1: Kawalan Versi

FaunAdb mempunyai protokol transaksi tersebar sendiri, yang mempunyai beberapa persamaan dengan Calvin. Seperti kaedah terdahulu, data FaunAdb versi. Oleh kerana versi tidak hanya berguna untuk model konsisten, ia juga mempunyai nilai perniagaan, FaunADB telah menaik taraf mekanisme kepada rakyat kelas pertama, yang boleh digunakan oleh pengguna akhir. Ciri ini sebenarnya membolehkan pertanyaan perjalanan masa. Pengguna akhir boleh melaksanakan pertanyaan mengenai data sejarah untuk menjawab soalan berikut: "Apakah hasil pertanyaan ini 20 hari yang lalu?". Ini berguna untuk memulihkan data yang tidak disangka -sangka, mengkaji semula perubahan data, atau hanya menambahkan perjalanan masa ke ciri -ciri aplikasi.

Unsur 2 dan 3: Pengiraan dan Pemisahan Deterministik

Seperti Calvin, FaunAdb juga mempunyai pengiraan deterministik dan memisahkan masalah penyortiran dari seluruh algoritma. Walaupun persamaan, urus niaga yang dikira berlaku di FaunADB pada tahap yang berbeza daripada Calvin. Calvin menggunakan ciri deterministik untuk melaksanakan urus niaga yang sama beberapa kali selepas menetapkan pesanan, sementara FaunADB mengira hanya sekali sebelum mencapai konsensus mengenai urutan urus niaga. Ini mengingatkan kita tentang elemen keempat.

Elemen 4: Pengiraan Optimis

FaunAdb telah menambah elemen keempat, yang telah kita lihat ketika membincangkan pengasingan snapshot: pengiraan optimis dan bukannya mengunci.

FaunAdb tidak mengunci, tetapi secara optimis mengira hasil urus niaga sekali dalam nod yang menerima transaksi, dan kemudian menambah hasil dan nilai input asal ke log. Calvin menjimatkan pertanyaan yang perlu dilaksanakan dalam log transaksi, manakala FaunADB menyelamatkan kedua -dua keputusan pengiraan dan nilai input asal dalam log. Setelah konsensus dicapai atas urutan hasil aplikasi, FaunADB akan mengesahkan bahawa data input yang dikira telah diubah (terima kasih kepada kawalan versi). Jika nilai input telah berubah, urus niaga akan membatalkan dan memulakan semula; Jika nilai input tetap sama, hasilnya akan digunakan pada semua nod tanpa sebarang pengiraan tambahan.

Algoritma FaunADB mempunyai kelebihan yang sama dengan Calvin, tetapi mengurangkan jumlah pengiraan yang diperlukan dalam kelompok.

kesimpulannya

Dalam siri ini, kami menerangkan bagaimana konsistensi yang kuat dapat membantu anda membina aplikasi bebas ralat dengan lebih cekap. Di bahagian terakhir artikel ini, kami selanjutnya menjelaskan bagaimana idea -idea revolusioner dapat menguasai generasi baru pangkalan data yang diedarkan yang konsisten dan cekap. Dalam artikel sebelumnya, perkara utama ialah: "Konsistensi adalah penting." Pada akhir artikel ini, perkara utama dimasukkan dalam perkara berikut:

Dalam masa terdekat, jika anda membaca frasa seperti:

"Banyak pangkalan data NoSQL tidak memberikan penulisan atom pelbagai dokumen, tetapi seterusnya memberikan prestasi yang lebih baik. Walaupun konsistensi adalah satu lagi ciri yang kuat dari pangkalan data SQL, ia menghalang keupayaan untuk skala pangkalan data merentasi pelbagai nod, begitu banyak pangkalan data NoSQL meninggalkan konsistensi."

Perlu diketahui bahawa algoritma moden membolehkan pangkalan data untuk menyediakan konsistensi tanpa pemusatan. Dalam artikel ini, kita telah melihat beberapa contoh algoritma dan pangkalan data yang melakukan ini. Pangkalan data yang dibina di atas algoritma ini adalah generasi baru pangkalan data yang tidak lagi dapat diterangkan dalam kategori mudah seperti NoSQL, SQL, atau bahkan NewsQL.

Menggunakan pangkalan data awan yang diedarkan berdasarkan protokol transaksi percolator, spanner, calvin, dan faunADB, anda boleh mempunyai pangkalan data yang diedarkan berprestasi tinggi yang menyediakan model konsistensi yang lebih kukuh. Ini bermakna anda boleh membina aplikasi intensif data yang menyediakan latensi rendah tanpa bimbang tentang kesilapan data, prestasi, atau konfigurasi perkhidmatan. Dalam sistem sedemikian, konsistensi adalah telus dan anda tidak perlu menganggapnya sebagai pemaju. Kali seterusnya anda memilih pangkalan data, pilih pangkalan data yang tetap konsisten secara lalai.

Siri artikel

1. Mengapa anda perlu memberi perhatian?
2. Masalah apa yang mungkin berlaku?
3. Apakah halangan yang diterima pakai?
4. Bagaimanakah algoritma baru membantu?

Atas ialah kandungan terperinci Backends dan UX yang konsisten: Bagaimana algoritma baru membantu?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!