Dr. Martin Kleppmann adalah seorang peneliti dalam sistem terdistribusi di University of Cambridge, dan penulis yang sangat terkenal
"Merancang Aplikasi Data-Intensif" (O'Reilly Media, 2017).
Kevin Scott, CTO di Microsoft
pernah berkata : "Buku ini harus dibaca untuk insinyur perangkat lunak. "Merancang Aplikasi Data-Intensif adalah sumber daya langka yang menghubungkan teori dan praktik untuk membantu pengembang membuat keputusan cerdas saat mereka merancang dan mengimplementasikan infrastruktur dan sistem data."
Minat penelitian utama Martin termasuk perangkat lunak kolaborasi, CRDT, dan verifikasi formal algoritma terdistribusi. Sebelumnya dia adalah seorang insinyur perangkat lunak dan pengusaha di beberapa perusahaan Internet termasuk LinkedIn dan Rapportive, di mana dia bekerja pada infrastruktur data skala besar.
Vadim Tsesko (
@incubos ) adalah insinyur perangkat lunak utama di
Odnoklassniki yang bekerja di tim Platform Core. Minat ilmiah dan teknik Vadim meliputi sistem terdistribusi, gudang data, dan verifikasi sistem perangkat lunak.
Isi:
- Pindah dari bisnis ke penelitian akademik;
- Diskusi "Merancang Aplikasi Data-Intensif";
- Akal sehat terhadap sensasi buatan dan pemasaran yang agresif;
- Jebakan teorema CAP dan kesalahan industri lainnya;
- Manfaat desentralisasi;
- Blokir, Dat, IPFS, Filecoin, WebRTC;
- CRDT baru. Verifikasi formal dengan Isabelle;
- Sumber acara. Pendekatan tingkat rendah. Transaksi XA
- Apache Kafka, PostgreSQL, Memcached, Redis, Elasticsearch;
- Bagaimana menerapkan semua alat itu ke kehidupan nyata;
- Target audiensi yang diharapkan dari pembicaraan Martin dan konferensi Hydra.
Pindah dari bisnis ke penelitian akademis
Vadim : Pertanyaan pertama yang ingin saya tanyakan adalah sangat penting bagi saya. Anda mendirikan Go Test It dan Rapportive, dan Anda telah merancang dan merancang sistem skala besar di LinkedIn untuk sementara waktu. Kemudian Anda memutuskan untuk beralih dari teknik industri ke akademisi. Bisakah Anda jelaskan motivasi untuk keputusan itu? Apa yang telah Anda peroleh dan apa yang harus Anda korbankan?
Martin : Ini proses yang sangat menarik. Ketika Anda tampaknya mengisyaratkan, tidak banyak orang beralih ke arah itu. Banyak orang beralih dari akademisi ke industri, tetapi tidak banyak yang kembali. Ini bisa dimengerti, karena saya harus mengambil potongan gaji yang cukup besar untuk kembali ke dunia akademis. Tetapi apa yang saya sukai dari penelitian adalah kebebasan untuk mengerjakan topik yang menurut saya menarik dan saya pikir penting, bahkan jika topik itu tidak segera mengarah pada produk yang layak secara komersial dalam 6 bulan ke depan. Tentu saja, di perusahaan barang yang Anda bangun perlu berubah menjadi produk yang dapat dijual dalam berbagai bentuk. Di sisi lain, hal-hal yang saya kerjakan sekarang adalah topik yang sangat penting untuk masa depan tentang bagaimana kita membangun perangkat lunak dan bagaimana internet bekerja. Tapi kami belum benar-benar memahami topik ini dengan cukup baik untuk mulai dan mulai membangun produk komersial: kami masih pada tingkat mencoba mencari tahu, pada dasarnya, seperti apa teknologi ini harus terlihat. Dan karena ini adalah penelitian mendasar, saya menyadari lebih baik melakukan ini di universitas daripada mencoba melakukannya di sebuah perusahaan, karena di universitas saya bebas untuk mengerjakan hal-hal yang mungkin tidak menjadi layak secara komersial selama sepuluh tahun lagi, dan tidak apa-apa. Tidak apa-apa untuk bekerja dengan horizon waktu yang lebih lama ketika Anda dalam penelitian.
“Merancang Aplikasi Intensif Data”
Vadim : Kami pasti akan kembali ke minat penelitian Anda saat ini. Sementara itu mari kita bicara tentang buku terbaru Anda
Merancang Aplikasi Intensif Data . Saya penggemar berat buku Anda dan saya percaya ini adalah salah satu panduan terbaik untuk membangun sistem terdistribusi modern. Anda telah membahas hampir semua pencapaian penting terkini.
Martin : Terima kasih, saya senang Anda menemukannya berguna.
Vadim : Hanya untuk para pembaca yang kurang beruntung yang belum membaca buku Anda, dapatkah Anda menyebutkan beberapa pencapaian besar dalam bidang sistem terdistribusi saat ini?
Martin : Ya, tujuan buku ini bukan untuk menjelaskan satu teknologi tertentu; tujuannya adalah untuk memberi Anda panduan untuk seluruh lanskap berbagai sistem yang digunakan untuk menyimpan dan memproses data. Ada begitu banyak basis data, pemroses arus, alat pemrosesan batch, segala macam alat replikasi dan sebagainya, dan sangat sulit untuk mendapatkan gambaran umum. Jika Anda mencoba membangun aplikasi tertentu, sangat sulit untuk mengetahui database mana yang harus Anda gunakan, dan alat mana yang paling tepat untuk masalah yang Anda coba selesaikan. Banyak buku komputer yang ada tidak menjawab masalah itu dengan cara yang memuaskan. Saya menemukan bahwa jika Anda membaca buku tentang Cassandra misalnya, itu akan memberi tahu Anda mengapa Cassandra luar biasa, tetapi umumnya tidak akan memberi tahu Anda tentang hal-hal yang tidak cocok untuknya. Jadi yang benar-benar ingin saya lakukan dalam buku ini adalah mengidentifikasi pertanyaan utama yang perlu Anda tanyakan pada diri sendiri jika Anda mencoba membangun semacam sistem skala besar. Dan dengan menjawab pertanyaan-pertanyaan itu Anda kemudian dapat membantu mencari tahu teknologi mana yang sesuai dan mana yang kurang sesuai untuk masalah khusus yang Anda coba selesaikan - karena, secara umum, tidak ada satu teknologi yang sempurna untuk semuanya. Jadi, buku ini mencoba membantu Anda mengetahui pro dan kontra dari berbagai teknologi dalam pengaturan yang berbeda.
Akal sehat terhadap sensasi buatan dan pemasaran yang agresif
Vadim : Memang, sering - jika tidak selalu - ada banyak teknologi dengan fungsi, fitur dan model data yang tumpang tindih. Dan Anda tidak bisa percaya semua kata kunci pemasaran itu. Anda perlu membaca buku putih untuk mempelajari internal, dan bahkan mencoba membaca kode sumber untuk memahami cara kerjanya secara tepat.
Martin : Dan saya menemukan bahwa Anda sering harus membaca yang tersirat karena seringkali dokumentasi tidak benar-benar memberi tahu Anda hal-hal yang disebalkan oleh database tertentu. Yang benar adalah bahwa setiap database mengisap beberapa jenis pekerjaan, pertanyaannya adalah hanya untuk mengetahui yang mana. Jadi ya, kadang-kadang Anda harus membaca pedoman penyebaran untuk orang-orang ops dan mencoba untuk melakukan rekayasa balik dari apa yang sebenarnya terjadi pada sistem.
Vadim : Tidakkah Anda merasa bahwa industri ini tidak memiliki kosakata umum atau serangkaian kriteria untuk membandingkan berbagai solusi untuk masalah yang sama? Hal serupa disebut dengan nama yang berbeda, beberapa hal dihilangkan yang harus selalu jelas dan dinyatakan secara eksplisit, seperti jaminan transaksi. Apa yang kamu pikirkan
Martin : Ya, saya pikir masalah yang dihadapi industri kami adalah seringnya, ketika orang berbicara tentang alat tertentu, ada banyak hype tentang segalanya. Yang bisa dimengerti, karena alat dibuat oleh berbagai perusahaan, dan jelas perusahaan-perusahaan itu ingin mempromosikan produk mereka, sehingga perusahaan-perusahaan itu akan mengirim orang ke konferensi untuk berbicara tentang betapa indahnya produk mereka, pada dasarnya. Ini akan disamarkan sebagai pembicaraan teknologi, tetapi pada dasarnya ini masih merupakan aktivitas penjualan. Sebagai sebuah industri, kita benar-benar dapat melakukan dengan lebih jujur tentang kelebihan dan kekurangan beberapa produk. Dan sebagian dari itu memerlukan terminologi umum, karena jika tidak, Anda tidak dapat membandingkan hal-hal dengan pijakan yang sama. Tetapi di luar terminologi bersama kita perlu cara untuk berpikir tentang hal-hal yang baik atau buruk teknologi tertentu.
Jebakan teorema CAP dan kesalahan industri lainnya
Vadim : Pertanyaan saya berikutnya cukup kontroversial. Bisakah Anda menyebutkan kesalahan besar dalam industri yang Anda temui selama karir Anda? Mungkin teknologi yang dinilai terlalu tinggi atau solusi yang dipraktikkan secara luas yang seharusnya kita singkirkan sejak dulu? Ini mungkin contoh yang buruk, tetapi bandingkan JSON melalui HTTP / 1.1 dengan gRPC yang jauh lebih efisien daripada HTTP / 2. Atau adakah sudut pandang alternatif?
Martin : Saya pikir dalam banyak kasus ada alasan yang sangat bagus mengapa teknologi melakukan satu hal dan bukan yang lain. Jadi saya sangat ragu untuk menyebut kesalahan, karena dalam banyak kasus ini adalah masalah pertukaran. Dalam contoh Anda JSON melalui HTTP / 1.1 versus Protokol Buffer melalui HTTP / 2, saya pikir sebenarnya ada argumen yang cukup masuk akal untuk kedua belah pihak di sana. Misalnya, jika Anda ingin menggunakan Protokol Buffer, Anda harus menentukan skema Anda, dan skema dapat menjadi hal yang luar biasa karena membantu mendokumentasikan dengan tepat komunikasi apa yang sedang terjadi. Tetapi beberapa orang menganggap skema menjengkelkan, terutama jika mereka berada pada tahap awal pengembangan dan mereka sering mengubah format data. Jadi begitulah, ada pertanyaan trade-off; dalam beberapa situasi yang satu lebih baik, yang lain lebih baik.
Dalam hal kesalahan aktual yang saya rasa sangat buruk, hanya ada sejumlah kecil hal. Satu pendapat yang saya miliki adalah bahwa Teorema CAP pada dasarnya buruk dan tidak berguna. Setiap kali orang menggunakan Teorema CAP untuk membenarkan keputusan desain, saya pikir sering mereka salah menafsirkan apa yang sebenarnya dikatakan CAP, atau menyatakan yang jelas dengan cara tertentu. CAP sebagai teorema memiliki masalah yang sebenarnya hanya menyatakan yang sudah jelas. Selain itu, ia berbicara tentang hanya satu model konsistensi yang didefinisikan sangat sempit, yaitu linierabilitas, dan satu model ketersediaan yang didefinisikan sangat sempit, yaitu: Anda ingin setiap replika sepenuhnya tersedia untuk dibaca dan ditulis, bahkan jika itu tidak dapat berkomunikasi dengan replika lain. Ini adalah definisi yang masuk akal, tetapi mereka sangat sempit, dan banyak aplikasi tidak jatuh ke dalam kasus yang membutuhkan definisi konsistensi atau justru definisi ketersediaan. Dan untuk semua aplikasi yang menggunakan definisi kata-kata itu berbeda, Teorema CAP tidak memberi tahu Anda apa-apa. Itu hanya pernyataan kosong. Jadi saya rasa itu adalah kesalahan.
Dan sementara kita mengomel, jika Anda meminta saya menyebutkan kesalahan, kesalahan besar lain yang saya lihat di industri teknologi adalah penambangan cryptocurrency, yang saya pikir merupakan pemborosan listrik yang mengerikan. Saya tidak dapat memahami mengapa orang berpikir itu adalah ide yang bagus.
Vadim : Berbicara tentang Teorema CAP, banyak teknologi penyimpanan yang sebenarnya bisa ditala, dalam hal-hal seperti AP atau CP. Anda dapat memilih mode di mana mereka beroperasi.
Martin : Ya. Selain itu, ada banyak teknologi yang tidak konsisten atau tersedia di bawah definisi ketat dari Teorema CAP. Mereka benar-benar hanya P! Bukan CP, bukan CA, bukan AP, hanya P. Tidak ada yang mengatakan itu, karena itu akan terlihat buruk, tapi jujur, ini bisa menjadi keputusan desain yang masuk akal. Ada banyak sistem yang benar-benar baik-baik saja. Ini sebenarnya adalah salah satu alasan mengapa saya berpikir bahwa CAP adalah cara bicara yang tidak membantu: karena ada bagian besar dari ruang desain yang tidak dapat ditangkapnya, di mana ada desain bagus untuk perangkat lunak yang masuk akal. sama sekali tidak memungkinkan Anda untuk berbicara tentang.
Manfaat desentralisasi
Vadim : Berbicara tentang aplikasi intensif data hari ini, tantangan besar apa yang lain, masalah yang belum terpecahkan atau topik penelitian yang bisa Anda sebutkan? Sejauh yang saya tahu, Anda adalah pendukung utama perhitungan dan penyimpanan terdesentralisasi.
Martin : Ya. Salah satu tesis di balik penelitian saya adalah bahwa saat ini kami terlalu mengandalkan server dan sentralisasi. Jika Anda berpikir tentang bagaimana Internet pada awalnya dirancang kembali pada hari ketika berevolusi dari ARPANET, itu dimaksudkan sebagai jaringan yang sangat tangguh di mana paket dapat dikirim melalui beberapa rute berbeda, dan mereka masih akan sampai ke tujuan. Dan jika sebuah bom nuklir menghantam kota Amerika tertentu, sisa jaringan itu masih akan berfungsi karena ia hanya akan merutekan bagian-bagian yang gagal dari sistem. Ini adalah desain Perang Dingin.
Dan kemudian kami memutuskan untuk meletakkan semuanya di cloud, dan sekarang pada dasarnya semuanya harus melalui salah satu pusat data AWS, seperti us-east-1 di suatu tempat di Virginia. Kami telah menghilangkan cita-cita ini untuk dapat secara desentral menggunakan berbagai bagian jaringan yang berbeda, dan kami telah memasukkan server-server ini yang semuanya bergantung, dan sekarang ini sangat terpusat. Jadi saya tertarik pada desentralisasi, dalam arti memindahkan sebagian daya dan kontrol atas data dari server-server itu dan kembali ke pengguna akhir.
Satu hal yang ingin saya tambahkan dalam konteks ini adalah bahwa banyak orang berbicara tentang desentralisasi berbicara tentang hal-hal seperti mata uang kripto, karena mereka juga mencoba bentuk desentralisasi di mana kontrol dipindahkan dari otoritas pusat seperti bank ke jaringan. node bekerja sama. Tetapi itu bukan desentralisasi yang saya minati: Saya menemukan bahwa cryptocurrency ini sebenarnya masih sangat tersentralisasi, dalam arti bahwa jika Anda ingin melakukan transaksi Bitcoin, Anda harus membuatnya di jaringan Bitcoin - Anda harus menggunakan jaringan Bitcoin, jadi semuanya terpusat pada jaringan tertentu. Cara itu dibangun terdesentralisasi dalam arti bahwa itu tidak memiliki satu node pengendali, tetapi jaringan secara keseluruhan sangat terpusat dalam setiap transaksi yang harus Anda lakukan harus Anda lakukan melalui jaringan ini. Anda tidak dapat melakukannya dengan cara lain. Saya merasa itu masih merupakan bentuk sentralisasi.
Dalam kasus mata uang kripto, sentralisasi ini mungkin tidak dapat dihindari, karena Anda perlu melakukan hal-hal seperti menghindari pengeluaran ganda, dan melakukan hal itu sulit tanpa jaringan yang mencapai konsensus tentang persis transaksi mana yang telah terjadi dan mana yang tidak. Dan inilah yang dilakukan jaringan Bitcoin. Tetapi ada banyak aplikasi yang tidak memerlukan sesuatu seperti blockchain, yang sebenarnya dapat mengatasi model data yang jauh lebih fleksibel yang mengalir di sekitar sistem. Dan itulah jenis sistem desentralisasi yang paling saya minati.
Vadim : Bisakah Anda menyebutkan nama teknologi yang menjanjikan atau undervalued di bidang sistem desentralisasi selain dari blockchain? Saya telah menggunakan IPFS untuk sementara waktu.
Martin : Untuk IPFS, saya telah memeriksanya sedikit meskipun saya belum benar-benar menggunakannya sendiri. Kami telah melakukan beberapa pekerjaan dengan proyek
Dat , yang agak mirip dengan
IPFS dalam arti bahwa itu juga merupakan teknologi penyimpanan terdesentralisasi. Perbedaannya adalah bahwa IPFS memiliki
Filecoin , cryptocurrency, yang melekat padanya sebagai cara untuk membayar sumber daya penyimpanan, sedangkan Dat tidak memiliki blockchain yang melekat padanya - ini murni cara mereplikasi data di beberapa mesin dengan cara P2P.
Untuk proyek yang telah saya kerjakan, Dat sudah cukup pas, karena kami ingin membangun perangkat lunak kolaborasi di mana beberapa pengguna yang berbeda dapat masing-masing mengedit beberapa dokumen atau database, dan setiap perubahan pada data tersebut akan dikirim ke siapa pun. orang lain yang perlu memiliki salinan data ini. Kita dapat menggunakan Dat untuk melakukan replikasi ini dengan cara P2P, dan Dat menangani semua hal tingkat jaringan, seperti NAT traversal dan melewati firewall - ini masalah yang cukup sulit hanya untuk mendapatkan paket dari satu ujung ke ujung yang lain . Dan kemudian kami membangun lapisan di atasnya, menggunakan CRDT, yang merupakan cara untuk memungkinkan beberapa orang mengedit beberapa dokumen atau dataset dan untuk menukar suntingan tersebut dengan cara yang efisien. Saya pikir Anda mungkin dapat membangun hal semacam ini di IPFS juga: Anda mungkin dapat mengabaikan aspek Filecoin dan hanya menggunakan aspek replikasi P2P, dan mungkin akan melakukan pekerjaan dengan baik.
Vadim : Tentu, meskipun menggunakan IPFS dapat menyebabkan respons yang lebih rendah, karena Dat yang mendasari WebRTC menghubungkan node P2P secara langsung, dan IPFS bekerja seperti tabel hash yang didistribusikan.
Martin : Yah, WebRTC berada pada level tumpukan yang berbeda, karena ini dimaksudkan terutama untuk menghubungkan dua orang yang mungkin memiliki panggilan video; sebenarnya, perangkat lunak yang kami gunakan untuk wawancara ini sekarang mungkin menggunakan WebRTC. Dan WebRTC memang memberi Anda saluran data yang dapat Anda gunakan untuk mengirim data biner sewenang-wenang di atasnya, tetapi membangun sistem replikasi penuh di atas itu masih sedikit kerja. Dan itu sesuatu yang sudah dilakukan Dat atau IPFS.
Anda menyebutkan respons - itu tentu satu hal untuk dipikirkan. Katakanlah Anda ingin membangun Google Documents berikutnya dengan cara terdesentralisasi. Dengan Google Documents, unit perubahan yang Anda buat adalah satu penekanan tombol. Setiap huruf yang Anda ketik pada keyboard Anda dapat dikirim secara real time ke kolaborator Anda, yang sangat bagus dari sudut pandang kolaborasi real-time yang cepat. Tetapi itu juga berarti bahwa selama penulisan dokumen besar Anda mungkin memiliki ratusan ribu suntingan satu karakter yang menumpuk, dan banyak teknologi ini saat ini tidak terlalu bagus dalam mengompresi data pengeditan jenis ini. Anda dapat menyimpan semua suntingan yang pernah Anda buat pada dokumen Anda, tetapi bahkan jika Anda mengirim hanya seratus byte untuk setiap penekanan tombol yang Anda buat dan Anda menulis dokumen yang sedikit lebih besar dengan, katakanlah, 100.000 penekanan tombol, Anda tiba-tiba sekarang memiliki 10 MB data untuk dokumen yang hanya beberapa puluh kilobyte secara normal. Jadi kami memiliki overhead yang sangat besar ini untuk jumlah data yang perlu dikirim, kecuali kita menjadi lebih pintar dalam mengompresi dan mengemas perubahan.
Daripada mengirim seseorang daftar lengkap dari setiap karakter yang pernah diketik, kami mungkin hanya mengirim keadaan dokumen saat ini, dan setelah itu kami mengirim pembaruan yang telah terjadi sejak itu. Tetapi banyak dari sistem peer-to-peer ini belum memiliki cara untuk melakukan snapshot negara dengan cara yang akan cukup efisien untuk menggunakannya untuk sesuatu seperti Google Documents. Ini sebenarnya area yang sedang saya garap, mencoba mencari algoritma yang lebih baik untuk menyinkronkan pengguna yang berbeda untuk sesuatu seperti dokumen teks, di mana kami tidak ingin mempertahankan setiap penekanan tombol karena itu akan terlalu mahal, dan kami ingin untuk membuat penggunaan bandwidth jaringan yang lebih efisien.
CRDT baru. Verifikasi formal dengan isabelle
Vadim : Sudahkah Anda berhasil mengompres data keystroke itu secara substansial? Sudahkah Anda menemukan CRDT baru atau yang serupa?
Martin : Ya. Sejauh ini kami hanya memiliki prototipe untuk ini, belum sepenuhnya diimplementasikan, dan kami masih perlu melakukan beberapa percobaan untuk mengukur seberapa efisien sebenarnya dalam praktiknya. Tetapi kami telah mengembangkan beberapa skema kompresi yang terlihat sangat menjanjikan. Dalam prototipe saya, saya menguranginya dari sekitar 100 byte per edit menjadi sekitar 1,7 byte overhead per edit. Dan itu tentu saja jauh lebih masuk akal. Tetapi seperti yang saya katakan, percobaan ini masih berlangsung, dan jumlahnya mungkin masih sedikit berubah. Tapi saya pikir intinya adalah masih ada banyak ruang untuk optimasi, jadi kita masih bisa membuatnya jauh lebih baik.
Vadim : Jadi ini yang akan Anda bicarakan di
konferensi Hydra , apakah saya benar?
Martin : Ya, persis. Saya akan memberikan pengantar cepat ke bidang CRDT, perangkat lunak kolaboratif dan beberapa masalah yang muncul dalam konteks itu. Lalu saya akan menjelaskan beberapa penelitian yang telah kami lakukan di bidang ini. Sudah cukup menyenangkan karena penelitian yang kami lakukan telah melintasi berbagai macam keprihatinan yang berbeda. Di sisi yang sangat terapan, kami memiliki implementasi JavaScript dari algoritma ini, dan kami menggunakannya untuk membuat perangkat lunak nyata, mencoba menggunakan perangkat lunak itu sendiri untuk melihat bagaimana perilakunya. Di ujung lain spektrum, kami telah bekerja dengan metode formal untuk membuktikan algoritma ini benar, karena beberapa algoritma ini cukup halus dan kami ingin sangat yakin bahwa sistem yang kami buat benar-benar benar, yaitu bahwa mereka selalu mencapai kondisi yang konsisten. Ada banyak algoritma di masa lalu yang benar-benar gagal melakukan itu, yang hanya salah, yaitu, dalam kasus tepi tertentu, mereka akan tetap tidak konsisten secara permanen. Jadi, untuk menghindari masalah yang dimiliki algoritma di masa lalu, kami telah menggunakan metode formal untuk membuktikan algoritma kami benar.
Vadim : Wow. Apakah Anda benar-benar menggunakan pembuktian teorema, seperti Coq atau Isabelle atau yang lainnya?
Martin : Tepat sekali, kami sudah menggunakan Isabelle untuk itu.
Anda dapat menghadiri ceramah Martin "Bukti kebenaran sistem terdistribusi dengan Isabelle" di konferensi The Strange Loop pada bulan September.
Vadim : Kedengarannya bagus! Apakah bukti-bukti itu akan dipublikasikan?
Martin : Ya, set bukti pertama kami sudah umum. Kami
menerbitkannya satu setengah tahun yang lalu: itu adalah kerangka kerja untuk memverifikasi CRDT, dan kami memverifikasi tiga CRDT tertentu dalam kerangka itu, yang utamanya adalah RGA (
Replicated Growable Array ), yang merupakan CRDT untuk pengeditan teks kolaboratif. Meskipun tidak terlalu rumit, itu adalah algoritma yang cukup halus, dan itu merupakan kasus yang baik di mana bukti diperlukan, karena tidak jelas hanya dari melihat itu benar-benar benar. Dan buktinya memberi kita kepastian tambahan bahwa itu benar. Pekerjaan kami sebelumnya di sana adalah memverifikasi beberapa CRDT yang ada, dan pekerjaan terbaru kami di bidang ini adalah tentang CRDT kami sendiri untuk model data baru yang kami kembangkan, dan membuktikan bahwa CRDT kami sendiri juga benar.
Vadim : Seberapa besar buktinya dibandingkan dengan deskripsi algoritma? Karena terkadang bisa menjadi masalah.
Martin : Ya, itu masalah - buktinya sering kali banyak pekerjaan. Saya pikir dalam contoh terbaru kami ... Sebenarnya, izinkan saya melihat sekilas kode. Deskripsi algoritma dan struktur data adalah sekitar 60 baris kode. Jadi algoritma ini cukup kecil. Buktinya lebih dari 800 baris. Jadi kita punya sekitar 12: 1 rasio antara buktinya dan kodenya. Dan itu sayangnya cukup tipikal. Buktinya adalah sejumlah besar pekerjaan tambahan. Di sisi lain, setelah kami memiliki bukti, kami telah memperoleh kepastian yang sangat kuat dalam kebenaran algoritma. Selain itu, kita, sebagai manusia, memahami algoritme dengan lebih baik. Seringkali saya menemukan bahwa melalui mencoba memformalkannya, kita akhirnya memahami hal yang kita coba untuk memformalkan jauh lebih baik daripada yang kita lakukan sebelumnya. Dan itu sendiri sebenarnya merupakan hasil yang berguna dari pekerjaan ini: selain bukti itu sendiri kita mendapatkan pemahaman yang lebih dalam, dan itu seringkali sangat membantu untuk menciptakan implementasi yang lebih baik.
Vadim : Bisakah Anda jelaskan target audiens dari pembicaraan Anda, seberapa hardcorenya itu? Apa pengetahuan awal yang Anda harapkan dari audiens?
Martin : Saya suka membuat pembicaraan saya dapat diakses dengan sesedikit mungkin persyaratan pengetahuan sebelumnya, dan saya mencoba mengangkat semua orang ke tingkat yang sama. Saya membahas banyak materi, tetapi saya mulai dengan basis yang rendah. Saya berharap orang memiliki pengalaman sistem terdistribusi umum: bagaimana Anda mengirim beberapa data melalui jaringan menggunakan TCP, atau mungkin gagasan kasar tentang cara kerja Git, yang merupakan model yang cukup bagus untuk hal-hal ini. Tapi itu semua yang Anda butuhkan, sungguh. Kemudian, memahami pekerjaan yang telah kita lakukan di atas itu sebenarnya tidak terlalu sulit. Saya menjelaskan semuanya dengan contoh, menggunakan gambar untuk menggambarkan semuanya. Semoga semua orang bisa mengikuti.
Sumber acara. Pendekatan tingkat rendah. Transaksi XA
Vadim : Kedengarannya sangat bagus. Sebenarnya, kami punya waktu dan saya ingin membahas salah satu
artikel terbaru Anda tentang pemrosesan acara online. Anda adalah pendukung yang hebat dari ide event sourcing, apakah itu benar?
Martin : Ya, tentu.
Vadim : Saat ini pendekatan ini mendapatkan momentum, dan dalam mengejar semua keuntungan dari log operasi yang dipesan secara global, banyak insinyur mencoba untuk menyebarkannya di mana-mana. Bisakah Anda jelaskan beberapa kasus di mana sumber acara bukan pilihan terbaik? Hanya untuk mencegah penyalahgunaan dan kemungkinan kekecewaan dengan pendekatan itu sendiri.
Martin : Ada dua lapisan tumpukan yang perlu kita bicarakan terlebih dahulu. Sumber acara, seperti yang diusulkan oleh Greg Young dan beberapa lainnya, dimaksudkan sebagai mekanisme untuk pemodelan data, yaitu: jika Anda memiliki skema database dan Anda mulai kehilangan kendali karena ada begitu banyak tabel yang berbeda dan mereka ' Anda semua diubah oleh transaksi yang berbeda - maka sumber acara adalah cara untuk membawa kejelasan yang lebih baik untuk model data ini, karena peristiwa tersebut dapat mengungkapkan secara sangat langsung apa yang terjadi di tingkat bisnis. Apa tindakan yang dilakukan pengguna? Dan kemudian, konsekuensi dari tindakan itu mungkin memperbarui berbagai tabel dan sebagainya. Secara efektif, apa yang Anda lakukan dengan sumber acara adalah Anda memisahkan tindakan (peristiwa) dari efeknya, yang terjadi di suatu tempat di hilir.
Saya datang ke daerah ini dari sudut yang sedikit berbeda, yang merupakan sudut pandang tingkat lebih rendah dari menggunakan sistem seperti Kafka untuk membangun sistem yang sangat skalabel. Pandangan ini serupa dalam arti bahwa jika Anda menggunakan sesuatu seperti Kafka Anda menggunakan acara, tetapi itu tidak berarti Anda harus menggunakan sumber acara. Dan sebaliknya, Anda tidak perlu menggunakan Kafka untuk melakukan sumber acara; Anda bisa melakukan sumber acara dalam database biasa, atau Anda bisa menggunakan database khusus yang dirancang khusus untuk sumber acara. Jadi kedua gagasan ini serupa, tetapi tidak menuntut yang lain, mereka hanya memiliki beberapa tumpang tindih.
Kasus untuk ingin menggunakan sistem seperti Kafka sebagian besar adalah argumen skalabilitas: dalam hal ini Anda hanya punya begitu banyak data yang masuk sehingga Anda tidak dapat secara realistis memprosesnya pada database single-node, jadi Anda harus mempartisi dalam beberapa cara, dan menggunakan event log seperti Kafka memberi Anda cara yang baik untuk menyebarkan pekerjaan itu di beberapa mesin. Ini memberikan cara berprinsip yang baik untuk sistem penskalaan. Ini sangat berguna jika Anda ingin mengintegrasikan beberapa sistem penyimpanan yang berbeda. Jadi jika, misalnya, Anda ingin memperbarui tidak hanya basis data relasional Anda tetapi juga, katakanlah, indeks pencarian teks lengkap seperti Elasticsearch, atau sistem caching seperti Memcached atau Redis atau sesuatu seperti itu, dan Anda ingin satu acara memiliki memperbarui efek pada semua sistem yang berbeda ini, maka sesuatu seperti Kafka sangat berguna.
Dalam hal pertanyaan yang Anda ajukan (apa situasi di mana saya tidak akan menggunakan sumber acara atau pendekatan log peristiwa) - Saya pikir itu sulit untuk dikatakan secara tepat, tetapi sebagai aturan praktis saya akan mengatakan: gunakan apa pun yang paling sederhana . Artinya, apa pun yang paling dekat dengan domain yang Anda coba terapkan. Jadi, jika hal yang Anda coba terapkan dengan sangat baik ke database relasional, di mana Anda hanya menyisipkan dan memperbarui dan menghapus beberapa baris, maka gunakan saja database relasional dan masukkan serta perbarui dan hapus beberapa baris. Tidak ada yang salah dengan database relasional dan menggunakannya sebagaimana adanya. Mereka telah bekerja dengan baik untuk kami untuk waktu yang cukup lama dan mereka terus melakukannya. Tetapi jika Anda menemukan diri Anda dalam situasi di mana Anda benar-benar berjuang untuk menggunakan database semacam itu, misalnya karena kompleksitas model data semakin tak terkendali, maka masuk akal untuk beralih ke sesuatu seperti sumber acara. pendekatan.
Dan juga, pada level yang lebih rendah (skalabilitas), jika ukuran data Anda sedemikian rupa sehingga Anda bisa memasukkannya ke PostgreSQL pada satu mesin - itu mungkin baik, gunakan saja PostgreSQL pada satu mesin. Tetapi jika Anda berada di titik di mana tidak ada satu mesin pun yang dapat menangani beban Anda, Anda harus menskalakan sistem yang besar, maka mulai masuk akal untuk melihat ke sistem yang lebih terdistribusi seperti Kafka. Saya pikir prinsip umum di sini adalah: gunakan apa saja yang paling sederhana untuk tugas tertentu yang Anda coba selesaikan.
Vadim : Ini saran yang sangat bagus. Ketika sistem Anda berkembang, Anda tidak dapat secara tepat memprediksi arah pengembangan, semua pertanyaan, pola, dan aliran data.
Martin : Tepat sekali, dan untuk situasi seperti itu, basis data relasional luar biasa, karena sangat fleksibel, terutama jika Anda menyertakan dukungan JSON yang sekarang mereka miliki. PostgreSQL sekarang memiliki dukungan yang cukup bagus untuk JSON. Anda bisa menambahkan indeks baru jika ingin melakukan kueri dengan cara yang berbeda. Anda bisa mengubah skema dan terus berjalan dengan data dalam struktur yang berbeda. Dan jika ukuran kumpulan data tidak terlalu besar dan kompleksitasnya tidak terlalu besar, basis data relasional bekerja dengan baik dan memberikan banyak fleksibilitas.
Vadim : Mari kita bicara sedikit tentang sumber acara. Anda menyebutkan contoh yang menarik dengan beberapa konsumen mengkonsumsi acara dari satu antrian berdasarkan Kafka atau yang serupa. Bayangkan bahwa dokumen baru dipublikasikan, dan beberapa sistem memakan acara: sistem pencarian berdasarkan Elasticsearch, yang membuat dokumen dapat dicari, sistem caching yang menempatkannya ke dalam cache nilai-kunci berdasarkan Memcached, dan sistem basis data relasional yang memperbarui beberapa tabel sesuai. Sebuah dokumen mungkin merupakan penawaran penjualan mobil atau iklan realty. Semua sistem konsumsi ini bekerja secara simultan dan bersamaan.
Martin : Jadi pertanyaan Anda adalah bagaimana Anda menghadapi kenyataan bahwa jika Anda memiliki beberapa konsumen ini, beberapa dari mereka mungkin telah diperbarui, tetapi yang lain belum melihat pembaruan dan masih tertinggal sedikit?
Vadim : Ya, tepatnya. Seorang pengguna datang ke situs web Anda, memasukkan permintaan pencarian, mendapatkan beberapa hasil pencarian dan mengklik sebuah tautan. Tapi dia mendapat 404 kode status HTTP karena tidak ada entitas seperti itu di database, yang belum bisa mengkonsumsi dan bertahan dokumen.
Martin : Ya, ini sebenarnya sedikit tantangan. Idealnya, yang Anda inginkan adalah apa yang kami sebut "konsistensi sebab akibat" di seluruh sistem penyimpanan yang berbeda ini. Jika satu sistem berisi beberapa data yang Anda andalkan, maka sistem lain yang Anda lihat juga akan mengandung dependensi tersebut. Sayangnya, menyusun konsistensi kausal semacam itu di berbagai teknologi penyimpanan sebenarnya sangat sulit, dan ini bukan kesalahan sumber acara, karena tidak peduli pendekatan apa atau sistem apa yang Anda gunakan untuk mengirim pembaruan ke berbagai sistem yang berbeda, Anda selalu dapat berakhir dengan beberapa jenis masalah konkurensi.
Dalam contoh penulisan data ke Memcached dan Elasticsearch, bahkan jika Anda mencoba melakukan penulisan ke dua sistem secara bersamaan, Anda mungkin memiliki sedikit keterlambatan jaringan, yang berarti mereka tiba pada waktu yang sedikit berbeda pada sistem yang berbeda, dan diproses dengan waktu yang sedikit berbeda. Dan seseorang yang membaca kedua sistem itu mungkin melihat kondisi yang tidak konsisten. Sekarang, ada beberapa proyek penelitian yang setidaknya berupaya mencapai konsistensi kausal semacam itu, tetapi masih sulit jika Anda hanya ingin menggunakan sesuatu seperti Elasticsearch atau Memcached atau lebih dari itu.
Solusi yang baik di sini adalah bahwa Anda disajikan, secara konseptual, dengan snapshot point-in-time yang konsisten di kedua indeks pencarian dan cache dan database. Jika Anda bekerja hanya dalam basis data relasional, Anda mendapatkan sesuatu yang disebut isolasi snapshot, dan titik isolasi snapshot adalah bahwa jika Anda membaca dari database, sepertinya Anda memiliki salinan pribadi keseluruhan basis data. Apa pun yang Anda lihat dalam database, data apa pun yang Anda query akan menjadi keadaan pada titik waktu tersebut, sesuai dengan snapshot. Jadi, bahkan jika data kemudian diubah oleh transaksi lain, Anda benar-benar akan melihat data yang lebih lama, karena data yang lebih lama itu merupakan bagian dari snapshot yang konsisten.
Dan sekarang, dalam kasus di mana Anda mendapatkan Elasticsearch dan Memcached, benar-benar yang Anda inginkan adalah gambaran yang konsisten di kedua sistem ini. Namun sayangnya, baik Memcached, Redis, maupun Elasticsearch tidak memiliki mekanisme yang efisien untuk membuat foto-foto seperti itu yang dapat dikoordinasikan dengan sistem penyimpanan yang berbeda. Setiap sistem penyimpanan hanya berpikir untuk dirinya sendiri dan biasanya memberi Anda nilai terbaru dari setiap kunci, dan tidak memiliki fasilitas ini untuk melihat ke belakang dan menyajikan versi data yang sedikit lebih tua, karena versi terbaru dari data belum konsisten.
Saya tidak punya jawaban yang bagus untuk seperti apa solusinya. Saya khawatir solusinya akan memerlukan perubahan kode ke salah satu sistem penyimpanan yang berpartisipasi dalam hal semacam ini. Jadi itu akan membutuhkan perubahan pada Elasticsearch dan Redis dan untuk Memcached dan sistem lainnya. Dan mereka harus menambahkan semacam mekanisme untuk snapshot point-in-time yang cukup murah sehingga Anda dapat menggunakannya setiap saat, karena Anda mungkin ingin snapshot beberapa kali per detik - itu bukan hanya sekali-a Snapshot -hari, sangat halus. Dan saat ini sistem yang mendasarinya tidak ada untuk dapat melakukan snapshot semacam ini di berbagai sistem penyimpanan. Ini adalah topik penelitian yang sangat menarik. Saya berharap seseorang akan mengatasinya, tetapi saya belum melihat jawaban yang meyakinkan untuk masalah itu sejauh ini.
Vadim : Ya, kita perlu semacam
Kontrol Konversi Multiversion bersama.
Martin : Persis, seperti sistem transaksi yang didistribusikan. Transaksi yang didistribusikan XA akan membawa Anda ke sana, tetapi sayangnya XA, sebagaimana adanya, tidak benar-benar cocok karena hanya berfungsi jika Anda menggunakan kontrol concurrency berbasis penguncian. Ini berarti bahwa jika Anda membaca beberapa data, Anda harus mengambil kunci di atasnya sehingga tidak ada yang dapat mengubah data itu saat Anda memiliki kunci itu. Dan kontrol konkurensi berbasis penguncian semacam itu memiliki kinerja yang mengerikan, jadi tidak ada sistem yang benar-benar menggunakannya saat ini. Tetapi jika Anda tidak memiliki penguncian itu maka Anda tidak mendapatkan perilaku isolasi yang diperlukan dalam sistem seperti transaksi yang didistribusikan XA. Jadi mungkin yang kita butuhkan adalah protokol baru untuk transaksi terdistribusi yang memungkinkan isolasi snapshot sebagai mekanisme isolasi lintas sistem yang berbeda. Tapi saya rasa saya belum melihat apa pun yang mengimplementasikannya.
Vadim : Ya, saya harap seseorang sedang mengerjakannya.
Martin : Ya, itu akan sangat penting. Juga dalam konteks layanan microser, misalnya: cara orang mempromosikan bahwa Anda harus membuat layanan microser adalah bahwa setiap layanan microser memiliki penyimpanan sendiri, database sendiri, dan Anda tidak memiliki satu layanan yang secara langsung mengakses database layanan lain, karena yang akan merusak enkapsulasi layanan. Karena itu, setiap layanan hanya mengelola datanya sendiri.
Misalnya, Anda memiliki layanan untuk mengelola pengguna, dan memiliki basis data untuk pengguna, dan semua orang yang ingin mengetahui sesuatu tentang pengguna harus melalui layanan pengguna. Dari sudut pandang enkapsulasi yang bagus: Anda menyembunyikan detail skema database dari layanan lain misalnya.
But from the point of view of consistency across different services — well, you've got a huge problem now, because of exactly the thing we were discussing: we might have data in two different services that depends upon each other in some way, and you could easily end up with one service being slightly ahead of or slightly behind the other in terms of timing, and then you could end up with someone who reads across different services, getting inconsistent results. And I don't think anybody building microservices currently has an answer to that problem.
Vadim : It is somewhat similar to workflows in our society and government, which are inherently asynchronous and there are no guarantees of delivery. You can get your passport number, then you can change it, and you need to prove that you changed it, and that you are the same person.
Martin : Yes, absolutely. As humans we have ways of dealing with this, for example, we might know that oh, sometimes that database is a bit outdated, I'll just check back tomorrow. And then tomorrow it's fine. But if it's software that we're building, we have to program all that kind of handling into the software. The software can't think for itself.
Vadim : Definitely, at least not yet. I have another question about the advantages of event sourcing. Event sourcing gives you the ability to stop processing events in case of a bug, and resume consuming events having deployed the fix, so that the system is always consistent. It's a really strong and useful property, but it might not be acceptable in some cases like banking where you can imagine a system that continues to accept financial transactions, but the balances are stale due to suspended consumers waiting for a bugfix from developers. What might be a workaround in such cases?
Martin : I think it's a bit unlikely to stop the consumer, deploying the fix and then restart it, because, as you say, the system has got to continue running, you can't just stop it. I think what is more likely to happen is: if you discover a bug, you let the system continue running, but while it continues running with the buggy code, you produce another version of the code that is fixed, you deploy that fixed version separately and run the two in parallel for a while. In the fixed version of the code you might go back in history and reprocess all of the input events that have happened since the buggy code was deployed, and maybe write the results to a different database. Once you've caught up again you've got two versions of the database, which are both based on the same event inputs, but one of the two processed events with the buggy code and the other processed the events with the correct code. At that point you can do the switchover, and now everyone who reads the data is going to read the correct version instead of the buggy version, and you can shut down the buggy version. That way you never need to stop the system from running, everything keeps working all the time. And you can take the time to fix the bug, and you can recover from the bug because you can reprocess those input events again.
Vadim : Indeed, it's a really good option if the storage systems are under your control, and we are not talking about side effects applied to external systems.
Martin : Yes, you're right, once we send the data to external systems it gets more difficult because you might not be able to easily correct it. But this is again something you find in financial accounting, for example. In a company, you might have quarterly accounts. At the end of the quarter, everything gets frozen, and all of the revenue and profit calculations are based on the numbers for that quarter. But then it can happen that actually, some delayed transaction came in, because somebody forgot to file a receipt in time. The transaction comes in after the calculations for the quarter have been finalized, but it still belongs in that earlier quarter.
What accountants do in this case is that in the next quarter, they produce corrections to the previous quarter's accounts. And typically those corrections will be a small number, and that's no problem because it doesn't change the big picture. But at the same time, everything is still accounted for correctly. At the human level of these accounting systems that has been the case ever since accounting systems were invented, centuries ago. It's always been the case that some late transactions would come in and change the result for some number that you thought was final, but actually, it wasn't because the correction could still come in. And so we just build the system with the mechanism to perform such corrections. I think we can learn from accounting systems and apply similar ideas to many other types of data storage systems, and just accept the fact that sometimes they are mostly correct but not 100% correct and the correction might come in later.
Vadim : It's a different point of view to building systems.
Martin : It is a bit of a new way of thinking, yes. It can be disorienting when you come across it at first. But I don't think there's really a way round it, because this impreciseness is inherent in the fact that we do not know the entire state of the world — it is fundamental to the way distributed systems work. We can't just hide it, we can't pretend that it doesn't happen, because that imprecision is necessarily exposed in the way we process the data.
Professional growth and development
Vadim : Do you think that conferences like
Hydra are anticipated? Most distributed systems are quite different, and it is hard to imagine that many attendees will get to work and will start applying what they have learned in day-to-day activities.
Martin : It is broad, but I think that a lot of the interesting ideas in distributed systems are conceptual. So the insights are not necessarily like «use this database» or «use this particular technology». They are more like ways of thinking about systems and about software. And those kinds of ideas can be applied quite widely. My hope is that when attendees go away from this conference, the lessons they take away are not so much what piece of software they should be using or which programming language they should be using – really, I don't mind about that – but more like how to
think about the systems they are building.
Vadim : Why do you think it's important to give conference talks on such complex topics as your talk, compared to publishing papers, covering all their details and intricacies? Or should anyone do both?
Martin : I think they serve different purposes. When we write papers, the purpose is to have a very definitive, very precise analysis of a particular problem, and to go really deep in that. On the other hand, the purpose of a talk is more to get people interested in a topic and to start a conversation around it. I love going to conferences partly because of the discussions I then have around the talk, where people come to me and say: «oh, we tried something like this, but we ran into this problem and that problem, what do you think about that?» Then I get to think about other people's problems, and that's really interesting because I get to learn a lot from that.
So, from my point of view, the selfish reason for going to conferences is really to learn from other people, what their experiences have been, and to help share the experiences that we've made in the hope that other people will find them useful as well. But fundamentally, a conference talk is often an introduction to a subject, whereas a paper is a deep analysis of a very narrow question. I think those are different genres and I think we need both of them.
Vadim : And the last question. How do you personally grow as a professional engineer and a researcher? Could you please recommend any conferences, blogs, books, communities for those who wish to develop themselves in the field of distributed systems?
Martin : That's a good question. Certainly, there are things to listen to and to read. There's no shortage of conference talks that have been recorded and put online. There are books like my own book for example, which provides a bit of an introduction to the topic, but also lots of references to further reading. So if there are any particular detailed questions that you're interested in, you can follow those references and find the original papers where these ideas were discussed. They can be a very valuable way of learning about something in greater depth.
A really important part is also trying to implement things and seeing how they work out in practice, and talking to other people and sharing your experiences. Part of the value of a conference is that you get to talk to other people as well, live. But you can have that through other mechanisms as well; for example, there's a Slack channel that people have set up for people
interested in distributed systems . If that's your thing you can join that. You can, of course, talk to your colleagues in your company and try to learn from them. I don't think there's one right way of doing this — there are many different ways through which you can learn and get a deeper experience, and different paths will work for different people.
Vadim : Thank you very much for your advice and interesting discussion! It has been a pleasure talking to you.
Martin : No problem, yeah, it's been nice talking to you.
Vadim : Let's meet
at the conference .