Martin Kleppman adalah seorang peneliti di University of Cambridge yang mengerjakan CRDT dan verifikasi formal algoritma. Bukunya
Merancang Aplikasi Intensif Data , yang diterbitkan pada tahun 2017, telah menjadi buku terlaris dalam penyimpanan dan pemrosesan data.
Kevin Scott (CTO di Microsoft) pernah
berkata : “Buku ini harus menjadi keharusan bagi para insinyur pengembangan. "Ini adalah sumber daya langka yang menggabungkan teori dan praktik, membantu pengembang untuk berpikir lebih dalam tentang desain dan implementasi infrastruktur dan sistem pemrosesan data." Hal serupa dikatakan oleh Jay Kreps, pencipta Apache Kafka dan CEO Confluent.
Sebelum memulai penelitian akademis, Martin bekerja di industri ini dan ikut mendirikan dua startup yang sukses: Rapportive (dibeli oleh LinkedIn pada 2012) dan Go Test It (dibeli oleh RedGate).
Habrapost ini adalah wawancara terperinci dengan Martin. Contoh topik diskusi:
- Transisi dari bisnis ke penelitian akademik;
- Prasyarat untuk Menulis Merancang Aplikasi Intensif Data;
- Akal sehat terhadap hype dan alat iklan buatan;
- Tidak perlunya teorema CAP dan kesalahan industri lainnya;
- Kegunaan desentralisasi;
- Blokir, Dat, IPFS, Filecoin, WebRTC;
- CRDT baru. Verifikasi formal di Isabelle;
- Diskusi tentang sumber acara. Pendekatan tingkat rendah. Transaksi XA
- Apache Kafka, PostgreSQL, Memcached, Redis, Elasticsearch;
- Menggunakan semuanya dalam kehidupan nyata;
- Ambang batas untuk memasukkan laporan Martin dan konferensi Hydra.
Wawancara dilakukan oleh
Vadim Tsesko (
@incubos ) - pengembang terkemuka dalam tim perusahaan Platform Odnoklassniki. Minat ilmiah dan teknik Vadim terkait dengan sistem terdistribusi dan gudang data, serta verifikasi sistem perangkat lunak.
Dari bisnis ke penelitian akademik
Vadim : Saya ingin memulai dengan pertanyaan yang sangat penting bagi saya secara pribadi. Anda mendirikan Go Test It dan Rapportive, dan untuk waktu yang lama terlibat dalam pengembangan sistem besar di LinkedIn, tetapi kemudian memutuskan untuk meninggalkan pengembangan komersial dan melakukan penelitian di universitas. Bisakah Anda memberi tahu saya apa yang mendorong Anda melakukan ini? Apa manfaat bekerja di universitas dan apa yang telah Anda korbankan?
Martin : Itu adalah transisi yang sangat menarik. Seperti yang saya pahami, Anda tertarik pada keputusan saya karena fakta bahwa beberapa orang pergi untuk penelitian akademis dari pengembangan komersial, lebih sering ada gerakan ke arah yang berlawanan. Ini bisa dimengerti, karena pendapatan di universitas jauh lebih rendah daripada di bisnis. Saya pribadi tertarik pada posisi seorang peneliti oleh fakta bahwa saya dapat memutuskan untuk diri sendiri topik mana yang harus dikerjakan, dan saya membuat pilihan ini berdasarkan apa yang tampak menarik dan penting bagi saya, bahkan jika mengerjakan suatu topik tidak menjanjikan untuk menghasilkan keuntungan selama 6 berikutnya bulan. Segala sesuatu yang Anda bekerja di perusahaan harus dijual dalam satu bentuk atau lainnya. Saat ini, saya sedang mengerjakan topik-topik yang penting untuk masa depan Internet dan perangkat lunak, tetapi pemahaman kita tentang mereka belum cukup dalam untuk menciptakan produk jadi. Sejauh ini, kami bahkan tidak memiliki gagasan umum tentang bagaimana teknologi ini seharusnya bekerja. Karena studi ini mendasar, saya memutuskan bahwa lebih baik melakukannya di universitas, dan bukan di perusahaan: universitas memiliki lebih banyak kebebasan, di sana Anda dapat melakukan hal-hal yang tidak akan menghasilkan keuntungan selama 10 tahun lagi. Cakrawala perencanaan jauh lebih luas.
Buku Merancang Aplikasi Intensif Data
Vadim : Kami pasti akan kembali ke topik penelitian, tetapi untuk sekarang mari kita bicara tentang buku Anda,
Merancang Aplikasi Intensif Data . Menurut pendapat saya, ini adalah salah satu panduan terbaik tentang sistem terdistribusi modern, hampir merupakan ensiklopedia: ia mencantumkan semua pencapaian paling signifikan yang ada saat ini.
Martin : Terima kasih, saya senang itu berguna.
Vadim : Sepertinya pembaca kami belum mengenalnya, tetapi untuk berjaga-jaga, mari kita bahas pencapaian paling signifikan di bidang sistem terdistribusi yang Anda tulis.
Martin : Sebenarnya, ketika menulis buku ini, saya tidak menetapkan tujuan untuk menggambarkan teknologi tertentu. Sebaliknya, saya ingin membuat panduan di seluruh dunia tentang sistem yang digunakan untuk menyimpan dan memproses data. Sekarang ada sejumlah besar basis data, pemroses arus, alat pemrosesan batch, semua jenis alat replikasi dan sejenisnya, sehingga sangat sulit untuk menyusun gambaran keseluruhan area ini. Dan jika Anda membutuhkan database untuk menyelesaikan masalah tertentu, sulit untuk memilih salah satu dari banyak yang sudah ada. Banyak buku yang ditulis tentang sistem seperti itu tidak berguna dalam hal ini. Sebagai contoh, dalam sebuah buku tentang Apache Cassandra dapat ditulis tentang betapa indahnya Cassandra, tetapi tidak ada yang akan dikatakan tentang tugas-tugas yang tidak sesuai. Karena itu, dalam buku saya, saya mencoba mengidentifikasi pertanyaan dasar yang perlu Anda tanyakan pada diri sendiri ketika menulis sistem besar. Jawaban atas pertanyaan-pertanyaan ini akan membantu menentukan teknologi mana yang cocok untuk menyelesaikan masalah saat ini, dan mana yang tidak terlalu baik. Yang utama adalah tidak ada teknologi yang bisa melakukan semuanya. Saya mencoba menunjukkan apa kelebihan dan kekurangan dari berbagai teknologi dalam konteks yang berbeda.
Vadim : Memang, banyak teknologi memiliki fitur dan fungsi yang sama dan menyediakan model data yang sama. Pada saat yang sama, seseorang tidak dapat mempercayai iklan, dan untuk memahami struktur internal sistem, seseorang harus membaca tidak hanya laporan teknis dan dokumentasi, tetapi bahkan kode sumber.
Akal sehat versus hype dan iklan alat buatan
Martin : Selain itu, Anda sering harus membaca yang tersirat, karena dokumentasi tidak mengatakan untuk tugas apa database tidak sangat cocok. Bahkan, database apa pun memiliki keterbatasannya sendiri, jadi Anda harus selalu tahu yang mana. Seringkali Anda harus membaca panduan penyebaran dan merekonstruksi operasi internal sistem.
Vadim : Ya, ini adalah contoh yang bagus. Tidakkah Anda berpikir bahwa dalam bidang ini tidak ada cukup kosakata umum atau sekumpulan kriteria tunggal, dengan menggunakan mana dimungkinkan untuk membandingkan berbagai solusi untuk satu tugas? Sekarang nama yang berbeda digunakan untuk hal yang sama, dan banyak aspek yang harus dijabarkan dengan jelas dan jelas tidak disebutkan sama sekali - misalnya, jaminan transaksionalitas.
Martin : Ya, benar. Sayangnya, di industri kami sangat sering ada kegembiraan berlebihan di sekitar instrumen yang berbeda. Yang bisa dimengerti, karena alat ini dibuat oleh perusahaan yang tertarik untuk mempromosikan produk mereka. Oleh karena itu, perusahaan-perusahaan ini mengirim orang ke konferensi, dan mereka, pada dasarnya, berbicara tentang produk-produk apa yang hebat. Ini menyamar sebagai laporan teknis, tetapi, pada dasarnya, ini adalah iklan. Tidak ada salahnya kita sebagai industri untuk lebih jujur tentang kelebihan dan kekurangan produk kita. Salah satu persyaratan untuk ini adalah terminologi umum, tanpa itu, tidak mungkin untuk membandingkan hal-hal. Namun selain itu, metode diperlukan untuk menganalisis kelebihan dan kekurangan berbagai teknologi.
Teorema CAP yang Tidak Perlu dan Kesalahan Industri Lainnya
Vadim : Pertanyaan saya berikutnya cukup sensitif. Bisakah Anda memberi tahu kami tentang kesalahan umum dalam industri kami yang Anda temui selama karier Anda? Misalnya, tentang beberapa teknologi berlebihan atau solusi yang banyak digunakan yang seharusnya sudah Anda singkirkan sejak dulu? Ini mungkin bukan contoh terbaik, tetapi terlintas di benak saya untuk menggunakan JSON melalui HTTP / 1.1 bukannya gRPC melalui HTTP / 2. Atau mungkin Anda tidak berbagi pandangan ini?
Martin : Paling sering, ketika membuat sistem, untuk mencapai satu hal, Anda perlu mengorbankan sesuatu yang lain, dan di sini saya lebih suka untuk tidak berbicara tentang kesalahan. Dalam hal pilihan antara JSON melalui HTTP / 1.1 dan, katakanlah, Protokol Buffer atas HTTP / 2, kedua opsi memiliki hak untuk ada. Jika Anda memutuskan untuk menggunakan Protokol Buffer, Anda perlu mendefinisikan skema, dan itu bisa sangat berguna, karena membantu menentukan secara akurat perilaku sistem. Tetapi dalam beberapa situasi, skema seperti itu tidak menyebabkan gangguan, terutama pada tahap awal pengembangan, ketika format data berubah cukup sering. Sekali lagi, di sini untuk mencapai tujuan tertentu seseorang harus mengorbankan sesuatu, dan dalam beberapa situasi ini dibenarkan, tetapi dalam situasi lain tidak. Tidak banyak solusi yang benar-benar bisa disebut salah. Tetapi karena kita berbicara tentang ini, mari kita bicara tentang teorema CAP - menurut pendapat saya, sama sekali tidak ada manfaatnya. Ketika digunakan dalam desain sistem, baik ada kesalahpahaman tentang makna teorema CAP, atau pernyataan yang terbukti sendiri dibuktikan menggunakannya. Ini menggunakan model konsistensi yang didefinisikan sangat sempit - linierabilitas, dan model aksesibilitas yang didefinisikan sangat sempit - setiap replika harus dapat diakses sepenuhnya, bahkan jika tidak dapat membuat koneksi dengan replika lainnya. Di satu sisi, definisi ini cukup benar, tetapi, di sisi lain, definisi itu terlalu sempit: banyak aplikasi tidak memerlukan definisi konsistensi atau aksesibilitas ini. Dan jika aplikasi menggunakan definisi yang berbeda dari kata-kata ini, teorema CAP tidak berguna baginya. Jadi saya tidak melihat banyak gunanya menerapkannya. Ngomong-ngomong, karena kita mulai berbicara tentang kesalahan dalam industri kita, mari kita jujur mengakui bahwa penambangan cryptocurrency adalah benar-benar pemborosan listrik. Saya tidak mengerti bagaimana Anda bisa melakukan ini dengan serius.
Vadim : Selain itu, sebagian besar teknologi penyimpanan sekarang dapat disesuaikan untuk tugas tertentu, mis. Anda dapat memilih mode operasi yang tepat di hadapan kegagalan.
Martin : Benar. Selain itu, bagian penting dari teknologi tidak jatuh di bawah definisi yang ketat tentang konsistensi dan aksesibilitas teorema CAP, yaitu, mereka bukan CP, bukan AP dan bukan CA, tetapi hanya P. Tidak ada yang akan menulis tentang perangkat lunak ini secara langsung, tetapi dalam kenyataannya dapat Jadilah strategi pengembangan rasional yang sempurna. Ini adalah salah satu alasan mengapa saya percaya bahwa CAP ketika menganalisis perangkat lunak lebih berbahaya daripada baik: bagian penting dari keputusan desain tidak disajikan dengan cara apa pun, dan itu bisa menjadi solusi yang cukup rasional, tetapi CAP tidak memungkinkan mereka untuk dijelaskan.
Manfaat desentralisasi
Vadim : Apa masalah paling akut dalam mengembangkan Aplikasi Data-Intensif sekarang? Topik apa yang paling aktif dieksplorasi? Sejauh yang saya tahu, Anda adalah pendukung komputasi terdesentralisasi dan pergudangan data terdesentralisasi.
Martin : Ya. Salah satu poin yang saya buktikan dalam penelitian saya adalah bahwa saat ini kami terlalu bergantung pada server dan sentralisasi. Pada masa awal Internet, ketika berevolusi dari ARPANET, ia dirancang sebagai jaringan yang sangat stabil di mana paket dapat dikirim di sepanjang berbagai rute, dan mereka masih mencapai tujuannya. Jika terjadi ledakan nuklir di kota mana pun di Amerika, bagian jaringan yang masih hidup akan terus beroperasi, rute alternatif hanya akan digunakan untuk memotong bagian yang gagal. Itu adalah skema yang dihasilkan oleh Perang Dingin. Tapi kemudian kami memutuskan untuk meletakkan segala sesuatu di awan, jadi sekarang hampir semuanya entah bagaimana melewati salah satu pusat AWS di suatu tempat di Virginia, di Amerika Serikat bagian timur. Di beberapa titik, kami meninggalkan ideal penggunaan desentralisasi dari berbagai bagian jaringan dan mengidentifikasi layanan yang sekarang semuanya tergantung. Saya menganggap penting untuk kembali ke pendekatan desentralisasi, di mana lebih banyak kontrol atas data bukan milik layanan, tetapi untuk pengguna akhir.
Ketika sampai pada desentralisasi, sangat sering hal-hal itu berarti hal-hal seperti cryptocurrency, karena mereka memiliki jaringan agen yang berinteraksi di mana tidak ada otoritas terpusat tunggal seperti bank. Tetapi ini bukan desentralisasi yang saya bicarakan, karena, menurut pendapat saya, cryptocurrency juga sangat tersentralisasi: jika Anda perlu menyelesaikan kesepakatan dengan Bitcoin, itu harus dilakukan melalui jaringan Bitcoin, jadi semuanya terpusat di sekitar jaringan ini. Struktur jaringan terdesentralisasi dalam arti bahwa ia tidak memiliki pusat pengorganisasian tunggal, tetapi jaringan secara keseluruhan sangat terpusat, karena setiap transaksi harus dilakukan melalui jaringan ini dan tidak ada yang lain. Saya percaya bahwa ini juga merupakan bentuk sentralisasi. Dalam kasus cryptocurrency, ini tidak bisa dihindari, karena perlu untuk memastikan tidak adanya biaya ganda, dan ini sulit dicapai tanpa jaringan yang memberikan konsensus tentang transaksi yang diselesaikan dan sejenisnya. Tetapi ada banyak aplikasi yang tidak memerlukan sistem seperti blockchain, mereka dapat bekerja dengan model data yang jauh lebih fleksibel. Sistem desentralisasi inilah yang paling menarik minat saya.
Vadim : Karena Anda menyebutkan blockchain, dapatkah Anda memberi tahu kami tentang teknologi yang menjanjikan atau tidak terkenal di bidang sistem desentralisasi? Saya sendiri bermain dengan IPFS, tetapi Anda memiliki lebih banyak pengalaman di bidang ini.
Martin : Sebenarnya, saya tidak secara aktif mengikuti teknologi semacam itu. Saya membaca sedikit tentang IPFS, tetapi saya belum menggunakannya sendiri. Kami bekerja sedikit dengan
Dat , yang, seperti
IPFS , adalah teknologi penyimpanan terdesentralisasi. Perbedaannya adalah bahwa cryptocurrency
Filecoin terikat ke IPFS, dan digunakan untuk membayar penyimpanan data, dan tidak ada blockchain yang terikat pada Dat. Dat hanya memungkinkan Anda untuk mereplikasi data ke beberapa mesin berdasarkan P2P, dan untuk proyek yang kami kerjakan, Dat hebat. Kami menulis perangkat lunak bagi pengguna untuk berkolaborasi pada dokumen, data, atau basis data, dan setiap perubahan dalam data ini dikirimkan kepada semua orang yang memiliki salinan data. Dalam sistem seperti itu, Dat dapat digunakan sesuai dengan prinsip P2P, sehingga memastikan operasi di tingkat jaringan, yaitu, NAT Traversal dan melewati firewall, yang merupakan tugas yang agak sulit. Di atas ini, kami menulis tingkat dari CRDT, dengan bantuan yang beberapa orang dapat mengedit dokumen atau dataset dan yang memungkinkan untuk berbagi suntingan dengan cepat dan mudah. Saya pikir sistem yang sama dapat ditulis di atas IPFS, sementara mengabaikan Filecoin dan hanya menggunakan replikasi P2P.
Vadim : Tetapi apakah sistem seperti itu tidak akan menjadi kurang responsif, karena WebRTC secara langsung menghubungkan satu sama lain, dan IPFS lebih merupakan tabel hash yang didistribusikan.
Martin : Masalahnya, WebRTC adalah level tumpukan yang sedikit berbeda. Ini dimaksudkan terutama untuk panggilan video - dengan probabilitas tinggi digunakan dalam perangkat lunak yang dengannya kami berkomunikasi sekarang. Selain itu, WebRTC menyediakan saluran di mana Anda dapat mengirim data biner sewenang-wenang. Tetapi menciptakan sistem replikasi di atasnya bisa sulit. Namun dalam Dat dan IPFS, Anda tidak perlu melakukan apa pun untuk ini.
Anda menyebutkan respons, dan ini adalah faktor yang sangat penting untuk diingat. Misalkan kita ingin membuat Google Documents berikutnya terdesentralisasi. Di Google Documents, unit perubahan adalah keystroke tunggal, dan setiap karakter baru dapat dikirim secara real time ke orang lain yang bekerja dengan dokumen yang sama. Di satu sisi, ini memastikan kolaborasi cepat, di sisi lain, itu berarti bahwa ketika menulis dokumen besar, Anda perlu mengirim ratusan ribu perubahan satu karakter, dan banyak teknologi yang ada menghadapi dengan buruk dengan jenis kompresi data. Bahkan jika kita mengasumsikan bahwa untuk setiap penekanan tombol perlu mengirim hanya seratus byte, maka untuk dokumen yang terdiri dari 100.000 karakter akan diperlukan untuk mengirim 10 MB data, walaupun biasanya dokumen semacam itu hanya membutuhkan beberapa puluh kilobyte. Sampai beberapa metode kompresi yang cerdik telah ditemukan, sinkronisasi data seperti itu membutuhkan biaya sumber daya yang sangat besar. Banyak sistem P2P belum memiliki cara yang efektif untuk membuat snapshot dari keadaan yang memungkinkannya digunakan untuk sistem seperti Google Documents. Ini adalah masalah yang sedang saya kerjakan, mencoba membuat algoritma untuk sinkronisasi dokumen yang lebih efisien untuk beberapa pengguna. Ini harus merupakan algoritma yang tidak akan menyimpan setiap penekanan tombol, karena ini membutuhkan terlalu banyak sumber daya, dan harus menyediakan penggunaan jaringan yang lebih efisien.
CRDT baru, verifikasi formal di Isabelle
Vadim : Bisakah Anda memberi tahu kami lebih banyak tentang ini? Sudahkah Anda berhasil mencapai lebih dari 100x kompresi data? Apakah Anda berbicara tentang teknik kompresi baru atau CRDT khusus?
Martin : Ya. , . , , . . 100 1.7 . , , , . , .
: , Hydra ?
: . CRDT, , . , — . JavaScript, , . , , , . . , .
: Coq Isabelle?
: ,
Isabelle .
: Isabelle The Strange Loop.
: ?
: ,
CRDT. CRDT , RGA (
Replicated Growable Array ), CRDT . , , , , . CRDT, , — CRDT .
: ? .
: , . : 60 , , 800 . , 12 . , . , . , . . , .
: , ? ?
: , . , . : TCP, Git . , , . , . . , .
Event sourcing, , XA-
:
, . , event sourcing. , - . event sourcing ? - , .
: . Event sourcing , , . , event sourcing . , , , . , event sourcing () .
event sourcing . Apache Kafka. Event sourcing Apache Kafka, , . event sourcing Apache Kafka , , , event sourcing. , , , . Apache Kafka , , , , , . Apache Kafka . Apache Kafka , . , Elasticsearch, Memcached Redis.
, , event sourcing. , . , , . — , . , event sourcing. : PostgreSQL , . , Kafka. , , .
: . , , , , .
: , , JSON (, PostgreSQL ) . , . . , .
: event sourcing. , . , (, ), : Elasticsearch, ; , key-value Memcached; , . .
: , , , — ?
: . , , , , , 404, .
: . (causal consitency) . , . , : , , . , , - . . , , , Elasticsearch Memcached. , , , . , snapshot isolation: , , . . , , . Memcached Elasticsearch . , , Memcached, Redis, Elasticsearch , . , , . , . . , . , , — , . . , . , - , .
: ,
Multiversion Concurrency Control .
: , . XA-, , , . , , . , , . XA . , , . .
: , - .
: , . , , , . , . - , . , . - , : , , , . . , .
: , . , . - , , , - .
: . . , , . , .
: , . event sourcing. , , , . , . , , , . , , , , , . ?
: , . , , . , , , , . . , . , , .
: , , , .
: . , . , . , , , . (, - ), . . - , . — , . , , , , 100%, .
: . .
: .
: , , . , — , . .
Hydra 2019,
: , Hydra? , , , .
: , , , , « » « ». . . , , - ; , , , , .
: , , , ? . , , ?
: , . , . , . - . , - , - . , . : , . — , — . , , , .
: . ? , - , , ?
: . . , . , , , . - — . , , . : . , , Slack ,
. , , . , , , .
: .
: , .
: ,
!
Saya mengingatkan Anda bahwa ini adalah wawancara yang direkam sebelumnya. Ketika Anda menulis komentar, ingat bahwa Martin tidak akan membacanya. Kami hanya bisa menyampaikan sesuatu yang paling menarik. Jika Anda benar-benar ingin berbicara dengan penulis, ia akan memberikan presentasi "Menyinkronkan data di seluruh perangkat pengguna untuk kolaborasi terdistribusi" di konferensi Hydra 2019, yang akan diselenggarakan pada 11-12 Juli 2019 di St. Petersburg. Tiket dapat dibeli di situs web resmi .