Persidangan HighLoad++ seterusnya akan diadakan pada 6 dan 7 April 2020 di St. Petersburg.
Butiran dan tiket . HighLoad++ Siberia 2019. Dewan "Krasnoyarsk". 25 Jun, 12:00. Tesis dan .
Ia berlaku bahawa keperluan praktikal bercanggah dengan teori, di mana aspek penting untuk produk komersial tidak diambil kira. Ceramah ini membentangkan satu proses untuk memilih dan menggabungkan pendekatan yang berbeza untuk mencipta komponen ketekalan Kausal berdasarkan penyelidikan akademik berdasarkan keperluan produk komersial. Pendengar akan belajar tentang pendekatan teori sedia ada untuk jam logik, penjejakan kebergantungan, keselamatan sistem, penyegerakan jam dan sebab MongoDB menyelesaikan penyelesaian tertentu.
Mikhail Tyulenev (selepas ini dirujuk sebagai MT): – Saya akan bercakap tentang konsistensi Sebab - ini adalah ciri yang kami usahakan dalam MongoDB. Saya bekerja dalam kumpulan sistem teragih, kami melakukannya kira-kira dua tahun lalu.
Dalam proses itu, saya terpaksa membiasakan diri dengan banyak penyelidikan akademik, kerana ciri ini telah dikaji dengan baik. Ternyata tiada satu artikel pun sesuai dengan apa yang diperlukan dalam pangkalan data pengeluaran kerana keperluan yang sangat spesifik yang mungkin terdapat dalam mana-mana aplikasi pengeluaran.
Saya akan bercakap tentang bagaimana kami, sebagai pengguna Penyelidikan akademik, menyediakan sesuatu daripadanya yang kemudiannya boleh kami persembahkan kepada pengguna kami sebagai hidangan siap sedia yang mudah dan selamat untuk digunakan.
Konsistensi penyebab. Mari kita tentukan konsep
Sebagai permulaan, saya ingin menyatakan secara umum apa itu Konsistensi Sebab. Terdapat dua watak - Leonard dan Penny (siri TV "The Big Bang Theory"):
Katakan Penny berada di Eropah dan Leonard ingin mengadakan pesta kejutan untuknya. Dan dia tidak dapat memikirkan apa-apa yang lebih baik daripada membuangnya daripada senarai rakannya, menghantar kemas kini kepada semua rakannya tentang suapan: "Mari kita gembirakan Penny!" (dia berada di Eropah, semasa dia tidur, dia tidak melihat semua ini dan tidak dapat melihatnya, kerana dia tidak ada di sana). Akhirnya, dia memadamkan siaran ini, memadamkannya daripada Suapan dan memulihkan akses supaya dia tidak menyedari apa-apa dan tiada skandal.
Ini semua baik dan baik, tetapi mari kita anggap bahawa sistem itu diedarkan dan keadaan menjadi sedikit tidak kena. Ia mungkin, sebagai contoh, berlaku bahawa sekatan akses Penny berlaku selepas siaran ini muncul, jika peristiwa itu tidak berkaitan dengan sebab dan akibat. Sebenarnya, ini ialah contoh apabila konsistensi Sebab-sebab diperlukan untuk melaksanakan fungsi perniagaan (dalam kes ini).
Sebenarnya, ini adalah sifat pangkalan data yang tidak penting - sangat sedikit orang yang menyokongnya. Mari kita beralih kepada model.
Model Ketekalan
Apakah sebenarnya model ketekalan dalam pangkalan data? Ini adalah beberapa jaminan yang diberikan oleh sistem yang diedarkan tentang data yang boleh diterima oleh pelanggan dan dalam urutan apa.
Pada dasarnya, semua model ketekalan merujuk kepada kesamaan sistem teragih dengan sistem yang berjalan, contohnya, pada satu nod pada komputer riba. Dan ini adalah kesamaan sistem yang berjalan pada beribu-ribu "Nod" yang diedarkan secara geo kepada komputer riba, di mana semua sifat ini dilakukan secara automatik pada dasarnya.
Oleh itu, model ketekalan digunakan hanya untuk sistem teragih. Semua sistem yang sebelum ini wujud dan beroperasi pada penskalaan menegak yang sama tidak mengalami masalah sedemikian. Terdapat satu Cache Penampan, dan semuanya sentiasa dibaca daripadanya.
Model Kuat
Sebenarnya, model pertama ialah Strong (atau garisan keupayaan naik, seperti yang sering dipanggil). Ini ialah model ketekalan yang memastikan bahawa setiap perubahan, setelah disahkan bahawa ia telah berlaku, dapat dilihat oleh semua pengguna sistem.
Ini mewujudkan susunan global semua acara dalam pangkalan data. Ini adalah sifat konsistensi yang sangat kuat, dan ia biasanya sangat mahal. Walau bagaimanapun, ia disokong dengan baik. Ia sangat mahal dan perlahan - ia jarang digunakan. Ini dipanggil keupayaan bangkit.
Terdapat satu lagi sifat yang lebih kukuh yang disokong dalam Spanner - dipanggil Ketekalan Luaran. Kita akan bercakap mengenainya sedikit kemudian.
Sebab
Yang seterusnya ialah Causal, iaitu apa yang saya bincangkan. Terdapat beberapa lagi sub-peringkat antara Strong dan Causal yang saya tidak akan bercakap tentang, tetapi semuanya bermuara kepada Causal. Ini adalah model yang penting kerana ia adalah yang paling kuat daripada semua model, konsistensi yang paling kuat dengan kehadiran rangkaian atau partition.
Sebab-sebab sebenarnya adalah situasi di mana peristiwa dihubungkan oleh hubungan sebab-akibat. Selalunya mereka dianggap sebagai Hak Baca anda mengenai dari sudut pandangan pelanggan. Jika pelanggan telah memerhati beberapa nilai, dia tidak dapat melihat nilai yang ada pada masa lalu. Dia sudah mula melihat bacaan awalan. Semuanya datang kepada perkara yang sama.
Causal sebagai model ketekalan ialah susunan separa peristiwa pada pelayan, di mana peristiwa daripada semua pelanggan diperhatikan dalam urutan yang sama. Dalam kes ini, Leonard dan Penny.
Akhirnya
Model ketiga ialah Konsistensi Akhirnya. Inilah yang menyokong semua sistem teragih, model minimum yang masuk akal sama sekali. Ini bermakna yang berikut: apabila kami mempunyai beberapa perubahan dalam data, pada satu ketika ia menjadi konsisten.
Pada saat seperti itu dia tidak berkata apa-apa, jika tidak, dia akan bertukar menjadi Konsistensi Luaran - ia akan menjadi cerita yang sama sekali berbeza. Walau bagaimanapun, ini adalah model yang sangat popular, yang paling biasa. Secara lalai, semua pengguna sistem teragih menggunakan Konsistensi Akhirnya.
Saya ingin memberikan beberapa contoh perbandingan:
Apakah maksud anak panah ini?
- Latensi. Apabila kekuatan konsistensi meningkat, ia menjadi lebih besar atas sebab yang jelas: anda perlu membuat lebih banyak rekod, dapatkan pengesahan daripada semua hos dan nod yang mengambil bahagian dalam kelompok bahawa data sudah ada. Oleh itu, Konsistensi Akhirnya mempunyai jawapan terpantas, kerana di sana, sebagai peraturan, anda juga boleh memasukkannya ke ingatan dan ini, pada dasarnya, sudah cukup.
- Ketersediaan. Jika kita memahami ini sebagai keupayaan sistem untuk bertindak balas dengan kehadiran pemecahan rangkaian, partition, atau beberapa jenis kegagalan, toleransi kesalahan meningkat apabila model konsistensi berkurangan, kerana sudah cukup untuk kita bahawa satu hos hidup dan pada masa yang sama masa menghasilkan beberapa data. Ketekalan Akhirnya tidak menjamin apa-apa tentang data sama sekali - ia boleh jadi apa sahaja.
- Anomali. Pada masa yang sama, tentu saja, bilangan anomali meningkat. Dalam Konsistensi Kuat mereka hampir tidak sepatutnya wujud sama sekali, tetapi dalam Konsistensi Akhirnya mereka boleh menjadi apa-apa sahaja. Timbul persoalan: mengapa orang memilih Konsistensi Akhirnya jika ia mengandungi anomali? Jawapannya ialah model Konsistensi Akhirnya boleh digunakan dan anomali wujud, sebagai contoh, dalam tempoh yang singkat; adalah mungkin untuk menggunakan wizard untuk membaca dan lebih kurang membaca data yang konsisten; Selalunya mungkin untuk menggunakan model konsistensi yang kuat. Dalam amalan ini berfungsi, dan selalunya bilangan anomali adalah terhad dalam masa.
Teorem CAP
Apabila anda melihat perkataan konsisten, ketersediaan - apa yang terlintas di fikiran anda? Betul - teorem CAP! Sekarang saya mahu menepis mitos itu... Bukan saya - Martin Kleppmann, yang menulis artikel yang menarik, sebuah buku yang menarik.
Teorem CAP ialah prinsip yang dirumuskan pada tahun 2000an bahawa Konsistensi, Ketersediaan, Pemisahan: ambil mana-mana dua, dan anda tidak boleh memilih tiga. Ia adalah prinsip tertentu. Ia telah dibuktikan sebagai teorem beberapa tahun kemudian oleh Gilbert dan Lynch. Kemudian ini mula digunakan sebagai mantera - sistem mula dibahagikan kepada CA, CP, AP dan sebagainya.
Teorem ini sebenarnya telah dibuktikan untuk kes berikut... Pertama, Ketersediaan dianggap bukan sebagai nilai berterusan dari sifar hingga ratusan (0 - sistem "mati", 100 - bertindak balas dengan cepat; kami biasa menganggapnya seperti itu) , tetapi sebagai harta algoritma , yang menjamin bahawa untuk semua pelaksanaannya ia mengembalikan data.
Tidak ada perkataan tentang masa tindak balas sama sekali! Terdapat algoritma yang mengembalikan data selepas 100 tahun - algoritma tersedia yang sangat menarik, yang merupakan sebahagian daripada teorem CAP.
Kedua: teorem telah terbukti untuk perubahan dalam nilai kunci yang sama, walaupun pada hakikatnya perubahan ini boleh diubah saiz. Ini bermakna bahawa pada hakikatnya mereka boleh dikatakan tidak digunakan, kerana modelnya berbeza Konsistensi Akhirnya, Konsisten Kuat (mungkin).
Untuk apa semua ini? Lebih-lebih lagi, teorem CAP dalam bentuk yang tepat di mana ia telah dibuktikan secara praktikal tidak boleh digunakan dan jarang digunakan. Dalam bentuk teori, ia entah bagaimana mengehadkan segala-galanya. Ternyata prinsip tertentu yang betul secara intuitif, tetapi secara umum belum terbukti.
Konsistensi sebab adalah model terkuat
Apa yang berlaku sekarang ialah anda boleh mendapatkan ketiga-tiga perkara: Ketekalan, Ketersediaan menggunakan Partition. Khususnya, Konsistensi Sebab ialah model konsistensi terkuat, yang masih berfungsi dengan kehadiran Partition (pecah dalam rangkaian). Itulah sebabnya ia sangat menarik, dan itulah sebabnya kami mengambilnya.
Pertama, ia memudahkan kerja pembangun aplikasi. Khususnya, kehadiran sokongan hebat dari pelayan: apabila semua rekod yang berlaku di dalam satu pelanggan dijamin tiba dalam urutan yang sama pada klien lain. Kedua, ia tahan sekatan.
Dapur Dalaman MongoDB
Mengenangkan sudah makan tengah hari, kami bergerak ke dapur. Saya akan memberitahu anda tentang model sistem, iaitu MongoDB untuk mereka yang pertama kali mendengar tentang pangkalan data sedemikian.
MongoDB (selepas ini dirujuk sebagai "MongoDB") ialah sistem teragih yang menyokong penskalaan mendatar, iaitu, sharding; dan dalam setiap serpihan ia juga menyokong lebihan data, iaitu, replikasi.
Sharding dalam MongoDB (bukan pangkalan data hubungan) melakukan pengimbangan automatik, iaitu, setiap koleksi dokumen (atau "jadual" dari segi data hubungan) dibahagikan kepada kepingan, dan pelayan secara automatik memindahkannya antara serpihan.
Penghala Pertanyaan, yang mengedarkan permintaan, untuk pelanggan ialah beberapa pelanggan yang melaluinya ia berfungsi. Ia sudah mengetahui di mana dan data apa yang terletak dan mengarahkan semua permintaan ke serpihan yang betul.
Satu lagi perkara penting: MongoDB ialah tuan tunggal. Terdapat satu Utama - ia boleh mengambil rekod yang menyokong kunci yang terkandung di dalamnya. Anda tidak boleh menulis Multi-master.
Kami membuat keluaran 4.2 - perkara menarik baru muncul di sana. Khususnya, mereka memasukkan Lucene - carian - iaitu java boleh laku terus ke dalam Mongo, dan di sana ia menjadi mungkin untuk melakukan carian melalui Lucene, sama seperti di Elastica.
Dan mereka membuat produk baharu - Carta, ia juga tersedia di Atlas (Awan Mongo sendiri). Mereka mempunyai Peringkat Percuma - anda boleh bermain-main dengannya. Saya sangat menyukai Carta - visualisasi data, sangat intuitif.
Bahan-bahan Konsistensi penyebab
Saya mengira kira-kira 230 artikel yang telah diterbitkan mengenai topik ini - daripada Leslie Lampert. Sekarang dari ingatan saya, saya akan menyampaikan kepada anda beberapa bahagian bahan-bahan ini.
Semuanya bermula dengan artikel oleh Leslie Lampert, yang ditulis pada tahun 1970-an. Seperti yang anda lihat, beberapa penyelidikan mengenai topik ini masih diteruskan. Kini konsistensi sebab mengalami minat berkaitan dengan pembangunan sistem teragih.
Sekatan
Apakah sekatan yang ada? Ini sebenarnya salah satu perkara utama, kerana sekatan yang dikenakan oleh sistem pengeluaran adalah sangat berbeza daripada sekatan yang wujud dalam artikel akademik. Mereka selalunya agak tiruan.
- Pertama, "MongoDB" ialah tuan tunggal, seperti yang telah saya katakan (ini sangat memudahkan).
- Kami percaya bahawa sistem itu harus menyokong kira-kira 10 ribu serpihan. Kami tidak boleh membuat sebarang keputusan seni bina yang akan mengehadkan nilai ini secara eksplisit.
- Kami mempunyai awan, tetapi kami menganggap bahawa seseorang masih perlu mempunyai peluang apabila dia memuat turun binari, menjalankannya pada komputer ribanya, dan semuanya berfungsi dengan baik.
- Kami menganggap sesuatu yang jarang diandaikan oleh Penyelidikan: pelanggan luar boleh melakukan apa sahaja yang mereka mahu. MongoDB ialah sumber terbuka. Oleh itu, pelanggan boleh menjadi begitu bijak dan marah - mereka boleh mahu memecahkan segala-galanya. Kami membuat spekulasi bahawa Feilor Byzantine mungkin berasal.
- Untuk pelanggan luaran yang berada di luar perimeter, terdapat had penting: jika ciri ini dilumpuhkan, maka tiada kemerosotan prestasi harus diperhatikan.
- Perkara lain secara amnya adalah anti-akademik: keserasian versi sebelumnya dan yang akan datang. Pemacu lama mesti menyokong kemas kini baharu, dan pangkalan data mesti menyokong pemacu lama.
Secara umum, semua ini mengenakan sekatan.
Komponen ketekalan sebab
Sekarang saya akan bercakap tentang beberapa komponen. Jika kita menganggap konsistensi Sebab secara umum, kita boleh memilih blok. Kami memilih daripada kerja yang dimiliki oleh blok tertentu: Penjejakan Ketergantungan, memilih jam, cara jam ini boleh disegerakkan antara satu sama lain dan cara kami memastikan keselamatan - ini adalah garis kasar tentang perkara yang akan saya bincangkan:
Penjejakan Kebergantungan Penuh
Mengapa ia diperlukan? Supaya apabila data direplikasi, setiap rekod, setiap perubahan data mengandungi maklumat tentang perubahan yang bergantung padanya. Perubahan yang pertama dan naif ialah apabila setiap mesej yang mengandungi rekod mengandungi maklumat tentang mesej sebelumnya:
Dalam contoh ini, nombor dalam kurungan kerinting ialah nombor rekod. Kadang-kadang rekod dengan nilai ini dipindahkan secara keseluruhannya, kadang-kadang beberapa versi dipindahkan. Intinya ialah setiap perubahan mengandungi maklumat tentang yang sebelumnya (jelas membawa semua ini dalam dirinya sendiri).
Mengapa kami memutuskan untuk tidak menggunakan pendekatan ini (penjejakan penuh)? Jelas sekali, kerana pendekatan ini tidak praktikal: sebarang perubahan pada rangkaian sosial bergantung pada semua perubahan sebelumnya pada rangkaian sosial itu, memindahkan, katakan, Facebook atau VKontakte dalam setiap kemas kini. Walau bagaimanapun, terdapat banyak penyelidikan mengenai Penjejakan Ketergantungan Penuh - ini adalah rangkaian pra-sosial; untuk beberapa situasi ia benar-benar berfungsi.
Penjejakan Ketergantungan Eksplisit
Yang seterusnya lebih terhad. Pemindahan maklumat juga dipertimbangkan di sini, tetapi hanya yang jelas bergantung. Apa yang bergantung pada apa, sebagai peraturan, ditentukan oleh Aplikasi. Apabila data direplikasi, pertanyaan hanya mengembalikan respons apabila kebergantungan sebelumnya telah dipenuhi, iaitu ditunjukkan. Inilah intipati bagaimana konsistensi Sebab-sebab berfungsi.
Dia melihat bahawa rekod 5 bergantung pada rekod 1, 2, 3, 4 - oleh itu, dia menunggu sebelum pelanggan mempunyai akses kepada perubahan yang dibuat oleh keputusan akses Penny, apabila semua perubahan sebelumnya telah melalui pangkalan data.
Ini juga tidak sesuai dengan kami, kerana masih terdapat terlalu banyak maklumat, dan ia akan memperlahankan keadaan. Ada pendekatan lain...
Jam Lamport
Mereka sangat tua. Jam Lamport bermaksud bahawa kebergantungan ini dilipat menjadi fungsi skalar, yang dipanggil Jam Lamport.
Fungsi skalar ialah beberapa nombor abstrak. Ia sering dipanggil masa logik. Dengan setiap acara, kaunter ini bertambah. Kaunter, yang kini diketahui prosesnya, menghantar setiap mesej. Adalah jelas bahawa proses boleh menjadi tidak segerak, mereka boleh mempunyai masa yang sama sekali berbeza. Walau bagaimanapun, sistem itu entah bagaimana mengimbangi jam dengan pemesejan sedemikian. Apa yang berlaku dalam kes ini?
Saya membelah serpihan besar itu kepada dua untuk menjelaskannya: Rakan boleh hidup dalam satu nod, yang mengandungi sekeping koleksi, dan Suapan boleh hidup dalam nod lain, yang mengandungi sekeping koleksi ini. Adakah jelas bagaimana mereka boleh keluar dari barisan? Suapan Pertama akan berkata: "Direplikasi", dan kemudian Rakan. Jika sistem tidak memberikan beberapa jenis jaminan bahawa Suapan tidak akan ditunjukkan sehingga kebergantungan Rakan dalam koleksi Rakan juga dihantar, maka kita akan mempunyai situasi yang saya nyatakan.
Anda melihat bagaimana masa balas pada Suapan meningkat secara logik:
Jadi sifat utama Jam Lamport dan konsistensi Kausal ini (dijelaskan melalui Jam Lamport) ialah ini: jika kita mempunyai Peristiwa A dan B, dan Peristiwa B bergantung pada Peristiwa A*, maka ia mengikuti bahawa Masa Logik Peristiwa A adalah kurang daripada LogicalTime daripada Peristiwa B.
* Kadang-kadang mereka juga mengatakan bahawa A berlaku sebelum B, iaitu, A berlaku sebelum B - ini adalah hubungan tertentu yang sebahagiannya memerintahkan keseluruhan set peristiwa yang berlaku secara umum.
Sebaliknya adalah tidak betul. Ini sebenarnya salah satu kelemahan utama Jam Lamport - susunan separa. Terdapat konsep tentang peristiwa serentak, iaitu peristiwa yang tidak (A berlaku sebelum B) mahupun (A berlaku sebelum B). Contohnya ialah Leonard menambah orang lain sebagai rakan secara serentak (bukan Leonard, tetapi Sheldon, sebagai contoh).
Ini adalah sifat yang sering digunakan apabila bekerja dengan jam Lamport: mereka melihat secara khusus pada fungsi dan dari sini mereka membuat kesimpulan bahawa mungkin peristiwa ini bergantung. Kerana satu cara adalah benar: jika LogicalTime A kurang daripada LogicalTime B, maka B tidak boleh berlaku sebelum A; dan jika lebih, maka mungkin.
Jam Vektor
Perkembangan logik jam Lamport ialah Jam Vektor. Mereka berbeza kerana setiap nod yang ada di sini mengandungi jam tersendiri, dan ia dihantar sebagai vektor.
Dalam kes ini, anda melihat bahawa indeks sifar vektor bertanggungjawab untuk Suapan, dan indeks pertama vektor adalah untuk Rakan (setiap nod ini). Dan kini mereka akan meningkat: indeks sifar "Suapan" meningkat apabila menulis - 1, 2, 3:
Mengapa Jam Vektor lebih baik? Kerana ia membolehkan anda mengetahui peristiwa yang serentak dan apabila ia berlaku pada nod yang berbeza. Ini sangat penting untuk sistem sharding seperti MongoDB. Walau bagaimanapun, kami tidak memilih ini, walaupun ia adalah perkara yang menarik, dan ia berfungsi dengan baik, dan ia mungkin sesuai dengan kami...
Jika kami mempunyai 10 ribu serpihan, kami tidak boleh memindahkan 10 ribu komponen, walaupun kami memampatkannya atau menghasilkan sesuatu yang lain - muatan masih akan beberapa kali lebih kecil daripada jumlah keseluruhan vektor ini. Oleh itu, dengan mengetap hati dan gigi, kami meninggalkan pendekatan ini dan beralih kepada yang lain.
Spanner TrueTime. Jam atom
Saya kata akan ada cerita tentang Spanner. Ini adalah perkara yang menarik, terus dari abad ke-XNUMX: jam atom, penyegerakan GPS.
Apa ideanya? "Spanner" ialah sistem Google yang baru-baru ini telah tersedia kepada orang ramai (mereka menambahkan SQL padanya). Setiap transaksi di sana mempunyai beberapa cap masa. Memandangkan masa disegerakkan*, setiap acara boleh ditetapkan masa tertentu - jam atom mempunyai masa menunggu, selepas itu masa yang berbeza dijamin untuk "berlaku".
Oleh itu, dengan hanya menulis ke pangkalan data dan menunggu beberapa tempoh masa, Kebolehbersirilan acara dijamin secara automatik. Mereka mempunyai model Konsistensi terkuat yang boleh dibayangkan secara prinsip - ia adalah Konsistensi Luaran.
* Ini adalah masalah utama dengan jam Lampart - ia tidak pernah segerak pada sistem teragih. Mereka boleh menyimpang; walaupun dengan NTP, mereka masih tidak berfungsi dengan baik. "Spanner" mempunyai jam atom dan penyegerakan, nampaknya, adalah mikrosaat.
Mengapa kita tidak memilih? Kami tidak menganggap bahawa pengguna kami mempunyai jam atom terbina dalam. Apabila ia muncul, dibina ke dalam setiap komputer riba, akan ada beberapa jenis penyegerakan GPS yang hebat - kemudian ya... Tetapi buat masa ini yang terbaik yang mungkin adalah Amazon, Stesen Pangkalan - untuk fanatik... Jadi kami menggunakan jam tangan lain .
Jam Hibrid
Inilah sebenarnya yang terdetik dalam MongoDB apabila memastikan konsistensi Causal. Bagaimanakah mereka hibrid? Hibrid ialah nilai skalar, tetapi ia mempunyai dua komponen:
- Yang pertama ialah zaman Unix (berapa saat telah berlalu sejak "permulaan dunia komputer").
- Yang kedua ialah beberapa kenaikan, juga int tidak bertanda 32-bit.
Itu sahaja, sebenarnya. Terdapat pendekatan ini: bahagian yang bertanggungjawab untuk masa disegerakkan dengan jam sepanjang masa; setiap kali kemas kini berlaku, bahagian ini disegerakkan dengan jam dan ternyata masa sentiasa lebih kurang betul, dan kenaikan membolehkan anda membezakan antara peristiwa yang berlaku pada masa yang sama.
Mengapa ini penting untuk MongoDB? Kerana ia membolehkan anda membuat beberapa jenis restoran sandaran pada masa tertentu, iaitu acara diindeks mengikut masa. Ini penting apabila acara tertentu diperlukan; Untuk pangkalan data, peristiwa ialah perubahan dalam pangkalan data yang berlaku pada selang masa tertentu.
Saya akan memberitahu anda sebab yang paling penting hanya kepada anda (tolong, jangan beritahu sesiapa)! Kami melakukan ini kerana inilah yang kelihatan seperti data tersusun dan diindeks dalam OpLog MongoDB. OpLog ialah struktur data yang mengandungi semua perubahan dalam pangkalan data: ia mula-mula pergi ke OpLog, dan kemudian ia digunakan pada Storan itu sendiri dalam kes apabila ia adalah tarikh atau serpihan yang direplikasi.
Ini adalah sebab utama. Namun begitu, terdapat juga keperluan praktikal untuk membangunkan pangkalan data, yang bermaksud ia mestilah mudah - kod kecil, sesedikit mungkin perkara yang rosak yang perlu ditulis semula dan diuji. Fakta bahawa oplog kami telah diindeks oleh jam hibrid banyak membantu dan membolehkan kami membuat pilihan yang tepat. Ia benar-benar membuahkan hasil dan entah bagaimana berfungsi secara ajaib pada prototaip pertama. Ia sangat keren!
Penyegerakan jam
Terdapat beberapa kaedah penyegerakan yang diterangkan dalam kesusasteraan saintifik. Saya bercakap tentang penyegerakan apabila kita mempunyai dua serpihan yang berbeza. Jika terdapat satu set replika, tidak ada keperluan untuk sebarang penyegerakan: ini adalah "tuan tunggal"; kami mempunyai OpLog, di mana semua perubahan jatuh - dalam kes ini, semuanya telah dipesan secara berurutan dalam "Oplog" itu sendiri. Tetapi jika kita mempunyai dua serpihan yang berbeza, penyegerakan masa adalah penting di sini. Di sinilah jam vektor banyak membantu! Tetapi kita tidak mempunyai mereka.
Yang kedua sesuai - ini ialah "Degupan Jantung". Adalah mungkin untuk menukar beberapa isyarat yang berlaku setiap unit masa. Tetapi Degupan Jantung terlalu perlahan, kami tidak dapat memberikan kependaman kepada pelanggan kami.
Masa sebenar, sudah tentu, satu perkara yang indah. Tetapi, sekali lagi, ini mungkin masa hadapan... Walaupun ia sudah boleh dilakukan di Atlas, sudah ada penyegerak masa "Amazon" yang pantas. Tetapi ia tidak akan tersedia untuk semua orang.
Bergosip ialah apabila semua mesej termasuk masa. Ini kira-kira apa yang kami gunakan. Setiap mesej antara nod, pemacu, penghala nod data, semuanya untuk MongoDB adalah sejenis elemen, komponen pangkalan data yang mengandungi jam yang berjalan. Mereka mempunyai makna masa hibrid di mana-mana, ia dihantar. 64 bit? Ini membolehkan, ini mungkin.
Bagaimanakah semuanya berfungsi bersama?
Di sini saya melihat satu set replika untuk menjadikannya lebih mudah. Terdapat Sekolah Rendah dan Menengah. Secondary melakukan replikasi dan tidak sentiasa disegerakkan sepenuhnya dengan Primary.
Sisipan berlaku ke dalam "Primery" dengan nilai masa tertentu. Sisipan ini meningkatkan kiraan dalaman sebanyak 11, jika ini adalah maksimum. Atau ia akan menyemak nilai jam dan menyegerakkan ke jam jika nilai jam lebih besar. Ini membolehkan anda menyusun mengikut masa.
Selepas dia membuat rakaman, detik penting berlaku. Jam berada dalam "MongoDB" dan dinaikkan hanya jika ia ditulis kepada "Oplog". Ini adalah peristiwa yang mengubah keadaan sistem. Dalam semua artikel klasik, peristiwa dianggap sebagai apabila mesej mengenai nod: mesej telah tiba, yang bermaksud sistem telah menukar keadaannya.
Ini disebabkan oleh fakta bahawa semasa penyelidikan tidak sepenuhnya jelas bagaimana mesej ini akan ditafsirkan. Kami tahu pasti bahawa jika ia tidak ditunjukkan dalam "Oplog", maka ia tidak akan ditafsirkan dalam apa-apa cara, dan perubahan dalam keadaan sistem hanyalah entri dalam "Oplog". Ini memudahkan segala-galanya untuk kami: model memudahkannya, dan membolehkan kami menyusunnya dalam satu set replika, dan banyak perkara lain yang berguna.
Nilai yang telah ditulis pada "Oplog" dikembalikan - kita tahu bahawa "Oplog" sudah mengandungi nilai ini, dan masanya ialah 12. Sekarang, katakan, bacaan bermula dari nod lain (Secondary), dan ia menghantar afterClusterTime dalam mesej itu. Dia berkata: "Saya memerlukan semua yang berlaku sekurang-kurangnya selepas 12 atau semasa dua belas" (lihat gambar di atas).
Inilah yang dipanggil Causal a consistent (CAT). Terdapat konsep sedemikian dalam teori bahawa ini adalah sebahagian daripada masa, yang konsisten dengan sendirinya. Dalam kes ini, kita boleh mengatakan bahawa ini adalah keadaan sistem yang diperhatikan pada masa 12.
Sekarang tiada apa-apa lagi di sini, kerana jenis ini mensimulasikan keadaan apabila anda memerlukan Menengah untuk meniru data daripada Utama. Dia menunggu... Dan kini data telah tiba - dia mengembalikan nilai ini kembali.
Itulah cara semuanya berfungsi. Hampir.
Apakah maksud "hampir"? Mari kita anggap bahawa terdapat beberapa orang yang telah membaca dan memahami bagaimana ini semua berfungsi. Saya menyedari bahawa setiap kali ClusterTime berlaku, ia mengemas kini jam logik dalaman, dan kemudian entri seterusnya meningkat sebanyak satu. Fungsi ini mengambil 20 baris. Katakan orang ini menghantar nombor 64-bit terbesar, tolak satu.
Mengapa "tolak satu"? Oleh kerana jam dalaman akan digantikan ke dalam nilai ini (jelas, ini adalah yang terbesar mungkin dan lebih besar daripada masa semasa), maka entri akan berlaku dalam "Oplog", dan jam akan dinaikkan oleh unit lain - dan sudah ada menjadi nilai maksimum (hanya terdapat semua unit, tiada tempat lain untuk pergi) , int tidak bersih).
Adalah jelas bahawa selepas ini sistem menjadi tidak dapat diakses sama sekali untuk apa-apa. Ia hanya boleh dipunggah dan dibersihkan - banyak kerja manual. Ketersediaan penuh:
Lebih-lebih lagi, jika ini direplikasi di tempat lain, maka keseluruhan kluster akan jatuh ke bawah. Situasi yang sama sekali tidak boleh diterima bahawa sesiapa sahaja boleh mengatur dengan cepat dan mudah! Oleh itu, kami menganggap detik ini sebagai salah satu yang paling penting. Bagaimana untuk mencegahnya?
Cara kami adalah dengan menandatangani clusterTime
Ini adalah bagaimana ia dihantar dalam mesej (sebelum teks biru). Tetapi kami juga mula menjana tandatangan (teks biru):
Tandatangan dijana oleh kunci yang disimpan di dalam pangkalan data, di dalam perimeter selamat; itu sendiri dijana dan dikemas kini (pengguna tidak melihat apa-apa tentangnya). Cincang dijana, dan setiap mesej ditandatangani apabila dibuat dan disahkan apabila diterima.
Persoalan mungkin timbul dalam fikiran orang: "Berapa banyak perkara ini memperlahankan keadaan?" Saya memberitahu anda bahawa ia harus berfungsi dengan cepat, terutamanya jika tiada ciri ini.
Apakah yang dimaksudkan untuk menggunakan konsistensi Kausal dalam kes ini? Ini adalah untuk menunjukkan parameter afterClusterTime. Tanpa ini, ia hanya akan melepasi nilai. Bergosip, bermula dari versi 3.6, sentiasa berkesan.
Jika kita meninggalkan penjanaan tandatangan yang berterusan, ia akan memperlahankan sistem walaupun tanpa ciri, yang tidak memenuhi pendekatan dan keperluan kita. Jadi apa yang kita buat?
Buat cepat!
Ia adalah perkara yang agak mudah, tetapi helahnya menarik - saya akan berkongsinya, mungkin seseorang akan berminat.
Kami mempunyai cincang yang menyimpan data yang ditandatangani. Semua data melalui cache. Cache tidak menandatangani masa tertentu, tetapi Julat. Apabila beberapa nilai tiba, kami menjana Julat, menutup 16 bit terakhir, dan kami menandatangani nilai ini:
Dengan menerima tandatangan sedemikian, kami mempercepatkan sistem (secara relatif) 65 ribu kali. Ia berfungsi hebat: apabila kami menjalankan eksperimen, masa sebenarnya berkurangan sebanyak 10 ribu kali apabila kami mempunyai kemas kini berurutan. Adalah jelas bahawa apabila mereka berselisih, ini tidak berfungsi. Tetapi dalam kebanyakan kes praktikal ia berfungsi. Gabungan tandatangan Julat bersama-sama dengan tandatangan menyelesaikan masalah keselamatan.
Apa yang telah kita pelajari?
Pengajaran yang kami pelajari daripada ini:
- Kita perlu membaca bahan, cerita, artikel, kerana kita mempunyai banyak perkara yang menarik. Apabila kami mengusahakan beberapa ciri (terutamanya sekarang, apabila kami melakukan transaksi, dll.), kami perlu membaca dan memahami. Ia mengambil masa, tetapi ia sebenarnya sangat berguna kerana ia menjelaskan di mana kita berada. Kami nampaknya tidak menghasilkan sesuatu yang baru - kami hanya mengambil bahan-bahannya.
Secara umum, terdapat perbezaan tertentu dalam pemikiran apabila ada persidangan akademik (Sigmon, misalnya) - semua orang menumpukan pada idea baru. Apakah yang baharu tentang algoritma kami? Tiada kebaharuan khusus di sini. Kebaharuan itu terletak pada cara kami menggabungkan pendekatan sedia ada bersama-sama. Oleh itu, perkara pertama adalah membaca klasik, bermula dengan Lampart.
- Dalam pengeluaran, keperluan adalah berbeza sama sekali. Saya pasti bahawa ramai daripada anda tidak berhadapan dengan pangkalan data "sfera" dalam vakum abstrak, tetapi dengan perkara biasa dan nyata yang mempunyai masalah dengan ketersediaan, kependaman dan toleransi kesalahan.
- Perkara terakhir ialah kita perlu melihat idea yang berbeza dan menggabungkan beberapa artikel yang sama sekali berbeza ke dalam satu pendekatan, bersama-sama. Idea tentang menandatangani, sebagai contoh, secara amnya datang daripada artikel yang menganggap protokol Paxos, yang bagi Pelanggar bukan Byzantine berada di dalam protokol kebenaran, untuk Byzantine - di luar protokol kebenaran... Secara umum, ini adalah apa yang kami akhirnya buat.
Tidak ada yang baru di sini! Tetapi sebaik sahaja kami mencampurkan semuanya ... Ia sama seperti mengatakan bahawa resipi salad Olivier adalah karut, kerana telur, mayonis dan timun telah dicipta ... Ia mengenai cerita yang sama.
Saya akan selesaikan dengan ini. Terima kasih!
soalan
Soalan daripada hadirin (selepas ini dirujuk sebagai B): – Terima kasih, Mikhail, atas laporan itu! Topik tentang masa adalah menarik. Anda menggunakan Gossiping. Mereka berkata bahawa setiap orang mempunyai masa mereka sendiri, semua orang tahu masa tempatan mereka. Seperti yang saya faham, kami mempunyai pemandu - mungkin terdapat ramai pelanggan dengan pemandu, perancang pertanyaan juga, serpihan juga... Dan apakah punca sistem jika kita tiba-tiba mengalami percanggahan: seseorang memutuskan bahawa ia adalah untuk minit di hadapan, seseorang seminit di belakang? Di manakah kita akan berakhir?
MT: - Soalan yang sangat bagus! Saya hanya mahu bercakap tentang serpihan. Jika saya memahami soalan dengan betul, kita mempunyai situasi berikut: terdapat serpihan 1 dan serpihan 2, bacaan berlaku dari kedua-dua serpihan ini - mereka mempunyai percanggahan, mereka tidak berinteraksi antara satu sama lain, kerana masa yang mereka tahu adalah berbeza, terutamanya masa yang mereka wujud dalam oplog.
Katakan bahawa serpihan 1 membuat sejuta rekod, serpihan 2 tidak melakukan apa-apa, dan permintaan itu mencapai dua serpihan. Dan yang pertama mempunyai afterClusterTime lebih sejuta. Dalam keadaan sedemikian, seperti yang saya jelaskan, shard 2 tidak akan bertindak balas sama sekali.
V: – Saya ingin tahu bagaimana mereka menyegerakkan dan memilih satu masa yang logik?
MT: - Sangat mudah untuk disegerakkan. Shard, apabila afterClusterTime datang kepadanya dan dia tidak menemui masa dalam "Oplog", memulakan tidak diluluskan. Iaitu, dia meningkatkan masanya dengan tangannya kepada nilai ini. Ini bermakna ia tidak mempunyai acara yang sepadan dengan permintaan ini. Dia mencipta acara ini secara buatan dan dengan itu menjadi Konsisten Sebab.
V: – Bagaimana jika selepas ini beberapa peristiwa lain datang kepadanya yang hilang di suatu tempat dalam rangkaian?
MT: – Shard direka sedemikian rupa sehingga mereka tidak akan datang lagi, kerana ia adalah tuan tunggal. Jika dia sudah mendaftar, maka mereka tidak akan datang, tetapi akan datang kemudian. Ia tidak boleh berlaku bahawa sesuatu tersangkut di suatu tempat, kemudian dia tidak menulis, dan kemudian peristiwa ini tiba - dan konsistensi Causal rosak. Apabila dia tidak menulis, mereka semua harus datang seterusnya (dia akan menunggu mereka).
V: – Saya mempunyai beberapa soalan mengenai baris gilir. Konsistensi sebab mengandaikan bahawa terdapat baris gilir tindakan tertentu yang perlu dilakukan. Apa yang berlaku jika salah satu pakej kami hilang? Ini datang ke-10, ke-11... ke-12 telah hilang, dan orang lain sedang menunggu ia menjadi kenyataan. Dan tiba-tiba kereta kami mati, kami tidak boleh berbuat apa-apa. Adakah terdapat panjang maksimum baris gilir yang terkumpul sebelum dilaksanakan? Apakah kegagalan maut yang berlaku apabila mana-mana satu negeri hilang? Lebih-lebih lagi, jika kita menulis bahawa terdapat beberapa keadaan sebelumnya, maka entah bagaimana kita harus bermula daripadanya? Tetapi mereka tidak menolaknya!
MT: - Juga soalan yang bagus! Apa yang kita buat? MongoDB mempunyai konsep menulis kuorum, membaca kuorum. Dalam kes apakah mesej boleh hilang? Apabila menulis tidak korum atau apabila membaca tidak korum (sesetengah jenis sampah juga boleh melekat).
Berkenaan dengan ketekalan Kausal, satu ujian eksperimen yang besar telah dijalankan, yang hasilnya adalah dalam kes apabila penulisan dan bacaan tidak memenuhi kuorum, pelanggaran ketekalan Kausal berlaku. Betul apa yang awak cakap!
Nasihat kami: gunakan sekurang-kurangnya bacaan kuorum apabila menggunakan konsistensi Kausal. Dalam kes ini, tiada apa yang akan hilang, walaupun rekod kuorum hilang... Ini adalah situasi ortogon: jika pengguna tidak mahu data hilang, dia perlu menggunakan rekod kuorum. Konsistensi sebab tidak menjamin ketahanan. Ketahanan dijamin oleh replikasi dan jentera yang berkaitan dengan replikasi.
V: – Apabila kita mencipta contoh yang melakukan sharding untuk kita (bukan tuan, tetapi hamba, masing-masing), ia bergantung pada masa Unix mesinnya sendiri atau pada masa "tuan"; Adakah ia menyegerak buat kali pertama atau secara berkala?
MT: - Saya akan jelaskan sekarang. Shard (iaitu partition mendatar) – sentiasa ada Primer di sana. Dan serpihan boleh mempunyai "tuan" dan boleh ada replika. Tetapi shard sentiasa menyokong rakaman, kerana ia mesti menyokong beberapa domain (shard mempunyai Utama).
V: - Jadi semuanya bergantung semata-mata pada "tuan"? Adakah masa induk sentiasa digunakan?
MT: - Ya. Anda secara kiasan boleh mengatakan: jam berdetik apabila kemasukan ke dalam "master", ke dalam "Oplog" berlaku.
V: – Kami mempunyai pelanggan yang berhubung dan tidak perlu tahu apa-apa tentang masa itu?
MT: - Anda tidak perlu tahu apa-apa sama sekali! Jika kita bercakap tentang cara ia berfungsi pada pelanggan: apabila pelanggan ingin menggunakan konsistensi Sebab, dia perlu membuka sesi. Kini semuanya ada: urus niaga dalam sesi, dan dapatkan semula hak... Sesi ialah susunan peristiwa logik yang berlaku dengan pelanggan.
Jika dia membuka sesi ini dan mengatakan di sana bahawa dia mahukan konsistensi Causal (jika sesi menyokong konsistensi Causal secara lalai), semuanya berfungsi secara automatik. Pemandu mengingati masa ini dan meningkatkannya apabila ia menerima mesej baharu. Ia ingat tindak balas yang sebelumnya dikembalikan daripada pelayan yang mengembalikan data. Permintaan seterusnya akan mengandungi afterCluster("masa lebih besar daripada ini").
Pelanggan tidak perlu tahu apa-apa! Ini benar-benar legap kepadanya. Jika orang menggunakan ciri ini, apakah yang boleh mereka lakukan? Mula-mula, anda boleh membaca sekunder dengan selamat: anda boleh menulis kepada Primer dan membaca daripada sekunder yang direplikasi secara geografi dan pastikan ia berfungsi. Pada masa yang sama, sesi yang dirakam pada Rendah malah boleh dipindahkan ke Menengah, iaitu anda tidak boleh menggunakan satu sesi, tetapi beberapa.
V: – Lapisan baharu sains Pengiraan – jenis data CRDT (Jenis Data Replika Tanpa Konflik) – sangat berkaitan dengan topik Konsistensi Akhirnya. Pernahkah anda mempertimbangkan untuk menyepadukan jenis data ini ke dalam pangkalan data dan apakah yang boleh anda katakan mengenainya?
MT: - Soalan yang baik! CRDT masuk akal untuk menulis konflik: dalam MongoDB, tuan tunggal.
V: – Saya ada soalan daripada devops. Di dunia nyata, terdapat situasi Jesuitical seperti apabila Kegagalan Byzantine berlaku, dan orang jahat di dalam perimeter yang dilindungi mula mencucuk ke dalam protokol, menghantar pakej kraf dengan cara yang istimewa?
MT: – Orang jahat di dalam perimeter adalah seperti kuda Trojan! Orang jahat di dalam perimeter boleh melakukan banyak perkara buruk.
V: – Jelas sekali bahawa meninggalkan, secara kasarnya, lubang dalam pelayan yang membolehkan anda meletakkan zoo gajah dan meruntuhkan seluruh gugusan selama-lamanya... Ia akan mengambil masa untuk pemulihan manual... Ini, secara ringkasnya, adalah salah. Sebaliknya, ini menarik: dalam kehidupan sebenar, dalam amalan, terdapat situasi apabila serangan dalaman yang serupa secara semula jadi berlaku?
MT: – Memandangkan saya jarang menghadapi pelanggaran keselamatan dalam kehidupan sebenar, saya tidak dapat mengatakan jika ia berlaku. Tetapi jika kita bercakap tentang falsafah pembangunan, kita berfikir seperti ini: kita mempunyai perimeter yang menyediakan orang yang melakukan keselamatan - ini adalah istana, dinding; dan di dalam perimeter anda boleh melakukan apa sahaja yang anda mahu. Jelas bahawa terdapat pengguna yang mempunyai keupayaan untuk melihat sahaja, dan terdapat pengguna yang mempunyai keupayaan untuk memadamkan direktori.
Bergantung pada hak, kerosakan yang boleh dilakukan pengguna boleh menjadi tetikus, atau ia boleh menjadi gajah. Adalah jelas bahawa pengguna yang mempunyai hak penuh boleh melakukan apa sahaja. Pengguna yang mempunyai hak terhad boleh menyebabkan lebih sedikit bahaya. Khususnya, ia tidak boleh memecahkan sistem.
V: – Dalam perimeter yang dilindungi, seseorang cuba mencipta protokol yang tidak dijangka untuk pelayan untuk memusnahkan pelayan sepenuhnya, dan jika anda bernasib baik, keseluruhan kluster... Adakah ia mendapat "baik" itu?
MT: "Saya tidak pernah mendengar perkara seperti itu." Hakikat bahawa anda boleh merosakkan pelayan dengan cara ini bukanlah rahsia. Gagal di dalam, daripada protokol, menjadi pengguna sah yang boleh menulis sesuatu seperti ini dalam mesej... Sebenarnya, mustahil, kerana ia masih akan disahkan. Adalah mungkin untuk melumpuhkan pengesahan ini untuk pengguna yang tidak menginginkannya - maka itu adalah masalah mereka; mereka, secara kasar bercakap, memusnahkan dinding itu sendiri dan anda boleh menolak gajah di sana, yang akan menginjak-injak... Tetapi secara umum, anda boleh berpakaian sebagai tukang baik, datang dan tarik keluar!
V: – Terima kasih atas laporan itu. Sergey (Yandex). Terdapat pemalar dalam Mong yang mengehadkan bilangan ahli mengundi dalam Set Replika, dan pemalar ini ialah 7 (tujuh). Mengapa ini pemalar? Mengapa ini bukan sejenis parameter?
MT: – Kami mempunyai Set Replika dengan 40 nod. Sentiasa ada majoriti. Saya tidak tahu versi yang mana...
V: – Dalam Set Replica anda boleh menjalankan ahli bukan mengundi, tetapi terdapat maksimum 7 ahli mengundi. Bagaimanakah kita boleh bertahan daripada penutupan dalam kes ini jika Set Replika kami tersebar di 3 pusat data? Satu pusat data boleh dimatikan dengan mudah, dan mesin lain boleh jatuh.
MT: – Ini sudah sedikit di luar skop laporan. Ini adalah soalan umum. Mungkin saya boleh memberitahu anda mengenainya kemudian.
Beberapa iklan 🙂
Terima kasih kerana tinggal bersama kami. Adakah anda suka artikel kami? Ingin melihat kandungan yang lebih menarik? Sokong kami dengan membuat pesanan atau mengesyorkan kepada rakan, , analog unik pelayan peringkat permulaan, yang kami cipta untuk anda: (tersedia dengan RAID1 dan RAID10, sehingga 24 teras dan sehingga 40GB DDR4).
Dell R730xd 2 kali lebih murah di pusat data Equinix Tier IV di Amsterdam? Hanya disini di Belanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - daripada $99! Baca tentang
Sumber: www.habr.com