Kontribusi Yandex pada database berikut akan ditinjau.
- KlikRumah
- Pengembaraan
- Pemulihan ke suatu titik waktu (WAL-G)
- PostgreSQL (termasuk kesalahan log, Amcheck, heapcheck)
- plum hijau
Video:
Halo Dunia! Nama saya Andrey Borodin. Dan apa yang saya lakukan di Yandex.Cloud adalah mengembangkan database relasional terbuka untuk kepentingan klien Yandex.Cloud dan Yandex.Cloud.
Dalam pembicaraan ini, kita akan membahas tentang tantangan yang dihadapi database terbuka dalam skala besar. Mengapa ini penting? Karena masalah kecil, seperti nyamuk, kemudian menjadi gajah. Mereka menjadi besar jika Anda memiliki banyak cluster.
Namun itu bukanlah hal yang utama. Hal-hal luar biasa terjadi. Hal-hal yang terjadi dalam satu dari sejuta kasus. Dan di lingkungan cloud, Anda harus bersiap menghadapi hal tersebut, karena hal-hal luar biasa menjadi sangat mungkin terjadi ketika sesuatu ada dalam skala besar.
Tetapi! Apa keuntungan dari database terbuka? Faktanya adalah Anda memiliki peluang teoretis untuk mengatasi masalah apa pun. Anda memiliki kode sumber, Anda memiliki pengetahuan pemrograman. Kami menggabungkannya dan berhasil.
Pendekatan apa yang ada dalam mengerjakan perangkat lunak sumber terbuka?
- Pendekatan yang paling mudah adalah dengan menggunakan perangkat lunak. Jika Anda menggunakan protokol, jika Anda menggunakan standar, jika Anda menggunakan format, jika Anda menulis kueri dalam perangkat lunak sumber terbuka, maka Anda sudah mendukungnya.
- Anda membuat ekosistemnya lebih besar. Anda membuat kemungkinan deteksi dini suatu bug menjadi lebih besar. Anda meningkatkan keandalan sistem ini. Anda meningkatkan ketersediaan pengembang di pasar. Anda meningkatkan perangkat lunak ini. Anda sudah menjadi kontributor jika Anda baru saja mulai bergaya dan mengutak-atik sesuatu di sana.
- Pendekatan lain yang dapat dimengerti adalah mensponsori perangkat lunak sumber terbuka. Misalnya, program Google Summer of Code yang terkenal, ketika Google membayar sejumlah besar siswa dari seluruh dunia dengan uang yang dapat dimengerti sehingga mereka mengembangkan proyek perangkat lunak terbuka yang memenuhi persyaratan lisensi tertentu.
- Ini adalah pendekatan yang sangat menarik karena memungkinkan perangkat lunak berkembang tanpa mengalihkan fokus dari komunitas. Google, sebagai raksasa teknologi, tidak mengatakan bahwa kami menginginkan fitur ini, kami ingin memperbaiki bug ini dan kami perlu menggalinya. Google mengatakan: “Lakukan apa yang Anda lakukan. Teruslah bekerja seperti yang Anda lakukan selama ini dan semuanya akan baik-baik saja.”
- Pendekatan berikutnya untuk berpartisipasi dalam open source adalah partisipasi. Ketika Anda memiliki masalah dalam perangkat lunak sumber terbuka dan ada pengembang, pengembang Anda mulai memecahkan masalah tersebut. Mereka mulai membuat infrastruktur Anda lebih efisien, program Anda lebih cepat dan lebih dapat diandalkan.
Salah satu proyek Yandex paling terkenal di bidang perangkat lunak sumber terbuka adalah ClickHouse. Ini adalah database yang lahir sebagai jawaban atas tantangan yang dihadapi Yandex.Metrica.
Dan sebagai database, dibuat secara open source untuk menciptakan ekosistem dan mengembangkannya bersama dengan pengembang lain (tidak hanya di dalam Yandex). Dan sekarang ini adalah proyek besar yang melibatkan banyak perusahaan berbeda.
Di Yandex.Cloud, kami membuat ClickHouse di atas Yandex Object Storage, yaitu di atas penyimpanan cloud.
Mengapa hal ini penting di cloud? Karena database apa pun bekerja dalam segitiga ini, dalam piramida ini, dalam hierarki tipe memori ini. Anda memiliki register yang cepat namun kecil dan SSD yang murah, besar namun lambat, hard drive, dan beberapa perangkat blok lainnya. Dan jika Anda efisien di puncak piramida, maka Anda memiliki database yang cepat. jika Anda efisien di bagian bawah piramida ini, maka Anda memiliki database yang berskala. Dan dalam hal ini, menambahkan lapisan lain dari bawah merupakan pendekatan logis untuk meningkatkan skalabilitas database.
Bagaimana hal itu bisa dilakukan? Ini adalah poin penting dalam laporan ini.
- Kita bisa mengimplementasikan ClickHouse melalui MDS. MDS adalah antarmuka penyimpanan cloud internal Yandex. Ini lebih kompleks daripada protokol S3 pada umumnya, tetapi lebih cocok untuk perangkat blok. Lebih baik untuk merekam data. Ini membutuhkan lebih banyak pemrograman. Pemrogram akan memprogram, bahkan bagus, menarik.
- S3 adalah pendekatan yang lebih umum yang membuat antarmuka lebih sederhana dengan biaya adaptasi yang lebih sedikit terhadap jenis beban kerja tertentu.
Tentu saja, karena ingin memberikan fungsionalitas ke seluruh ekosistem ClickHouse dan melakukan tugas yang diperlukan di dalam Yandex.Cloud, kami memutuskan untuk memastikan bahwa seluruh komunitas ClickHouse mendapat manfaat darinya. Kami menerapkan ClickHouse melalui S3, bukan ClickHouse melalui MDS. Dan ini adalah pekerjaan yang banyak.
Ссылки:
"Lapisan abstraksi sistem file"
"Integrasi AWS SDK S3"
“Implementasi dasar antarmuka IDisk untuk S3”
"Integrasi mesin penyimpanan log dengan antarmuka IDisk"
"Dukungan mesin log untuk S3 dan SeekableReadBuffer"
"Dukungan Penyimpanan Stripe Log S3"
"Dukungan awal Penyimpanan MergeTree untuk S3"
"MergeTree dukungan penuh untuk S3"
"Mendukung ReplikasiMergeTree melalui S3"
“Tambahkan kredensial default dan header khusus untuk penyimpanan s3”
"S3 dengan konfigurasi proksi dinamis"
"S3 dengan penyelesai proksi"
Ini adalah daftar permintaan tarik untuk mengimplementasikan sistem file virtual di ClickHouse. Ini adalah permintaan tarik dalam jumlah besar.
Ссылки:
"Implementasi optimal hardlink DiskS3"
“Klien HTTP S3 — Hindari menyalin aliran respons ke memori”
“Hindari menyalin seluruh aliran respons ke memori di S3 HTTP
klien"
“Kemampuan untuk menandai cache dan mengindeks file untuk disk S3”
"Pindahkan bagian dari DiskLocal ke DiskS3 secara paralel"
Namun pekerjaannya tidak berakhir di situ. Setelah fitur ini dibuat, diperlukan beberapa pekerjaan lagi untuk mengoptimalkan fungsi ini.
Ссылки:
"Tambahkan acara SelectedRows dan SelectedBytes"
"Tambahkan peristiwa pembuatan profil dari permintaan S3 ke system.events"
"Tambahkan QueryTimeMicroseconds, SelectQueryTimeMicroseconds, dan InsertQueryTimeMicroseconds"
Dan kemudian penting untuk membuatnya dapat didiagnosis, melakukan pemantauan, dan membuatnya dapat dikelola.
Dan semua ini dilakukan agar seluruh komunitas, seluruh ekosistem ClickHouse, menerima hasil kerja ini.
Mari beralih ke database transaksional, ke database OLTP, yang lebih dekat dengan saya pribadi.
Ini adalah divisi pengembangan DBMS open source. Orang-orang ini melakukan keajaiban jalanan untuk meningkatkan database terbuka transaksional.
Salah satu proyek, dengan menggunakan contoh yang dapat kita bicarakan tentang bagaimana dan apa yang kita lakukan, adalah Connection Pooler di Postgres.
Postgres adalah database proses. Ini berarti database harus memiliki koneksi jaringan sesedikit mungkin yang menangani transaksi.
Di sisi lain, dalam lingkungan cloud, situasi yang umum terjadi adalah ketika seribu koneksi datang ke satu cluster sekaligus. Dan tugas connection pooler adalah mengemas seribu koneksi ke dalam sejumlah kecil koneksi server.
Kita dapat mengatakan bahwa connection pooler adalah operator telepon yang mengatur ulang byte sehingga mencapai database secara efisien.
Sayangnya, tidak ada kata Rusia yang bagus untuk pooler koneksi. Kadang-kadang disebut koneksi multiplexer. Jika Anda tahu apa yang harus disebut pooler koneksi, pastikan untuk memberi tahu saya, saya akan dengan senang hati berbicara dalam bahasa teknis Rusia yang benar.
Kami menyelidiki pooler koneksi yang cocok untuk cluster postgres yang dikelola. Dan PgBouncer adalah pilihan terbaik bagi kami. Namun kami menemui sejumlah masalah dengan PgBouncer. Bertahun-tahun yang lalu, Volodya Borodin melaporkan bahwa kami menggunakan PgBouncer, kami menyukai semuanya, tetapi ada perbedaan, ada sesuatu yang harus dikerjakan.
Dan kami bekerja. Kami memperbaiki masalah yang kami temui, kami menambal Bouncer, dan mencoba mendorong permintaan tarik ke hulu. Namun single-threading yang mendasar sulit untuk dikerjakan.
Kami harus mengumpulkan kaskade dari Bouncer yang ditambal. Jika kita memiliki banyak Bouncer berulir tunggal, koneksi di lapisan atas ditransfer ke lapisan dalam Bouncer. Ini adalah sistem yang dikelola dengan buruk sehingga sulit untuk dibangun dan ditingkatkan skalanya.
Kami sampai pada kesimpulan bahwa kami membuat pooler koneksi kami sendiri, yang disebut Odyssey. Kami menulisnya dari awal.
Pada tahun 2019, di konferensi PgCon, saya mempresentasikan pooler ini kepada komunitas pengembang. Sekarang kami memiliki kurang dari 2 bintang di GitHub, artinya proyek ini aktif, proyek ini populer.
Dan jika Anda membuat cluster Postgres di Yandex.Cloud, maka itu akan menjadi cluster dengan Odyssey bawaan, yang dikonfigurasi ulang saat menskalakan cluster maju atau mundur.
Apa yang kita pelajari dari proyek ini? Meluncurkan proyek pesaing selalu merupakan langkah agresif, ini merupakan tindakan ekstrem ketika kita mengatakan bahwa ada masalah yang tidak diselesaikan dengan cukup cepat, tidak diselesaikan dalam interval waktu yang sesuai untuk kita. Tapi ini adalah langkah yang efektif.
PgBouncer mulai berkembang lebih cepat.
Dan sekarang proyek lain telah muncul. Misalnya pgagroal yang dikembangkan oleh developer Red Hat. Mereka mengejar tujuan yang sama dan menerapkan ide-ide yang serupa, tetapi, tentu saja, dengan spesifikasinya sendiri, yang lebih dekat dengan pengembang pgagroal.
Kasus lain dalam bekerja dengan komunitas postgres adalah memulihkan ke suatu titik waktu. Ini adalah pemulihan setelah kegagalan, ini adalah pemulihan dari cadangan.
Ada banyak cadangan dan semuanya berbeda. Hampir setiap vendor Postgres memiliki solusi pencadangannya sendiri.
Jika Anda mengambil semua sistem cadangan, membuat matriks fitur dan bercanda menghitung determinan dalam matriks ini, hasilnya akan menjadi nol. Apa artinya ini? Bagaimana jika Anda mengambil file cadangan tertentu, maka file tersebut tidak dapat dirakit dari bagian-bagian lainnya. Unik dalam pelaksanaannya, unik dalam tujuannya, unik dalam ide-ide yang tertanam di dalamnya. Dan semuanya spesifik.
Saat kami menangani masalah ini, CitusData meluncurkan proyek WAL-G. Ini adalah sistem cadangan yang dibuat dengan memperhatikan lingkungan cloud. Kini CitusData sudah menjadi bagian dari Microsoft. Dan pada saat itu, kami sangat menyukai ide-ide yang dituangkan dalam rilis awal WAL-G. Dan kami mulai berkontribusi pada proyek ini.
Sekarang ada lusinan pengembang dalam proyek ini, tetapi 10 kontributor teratas WAL-G mencakup 6 Yandexoids. Kami membawa banyak ide kami ke sana. Dan, tentu saja, kami menerapkannya sendiri, mengujinya sendiri, meluncurkannya sendiri ke dalam produksi, kami menggunakannya sendiri, kami sendiri yang memikirkan ke mana harus bergerak selanjutnya, sambil berinteraksi dengan komunitas besar WAL-G.
Dan dari sudut pandang kami, sekarang sistem pencadangan ini, termasuk dengan mempertimbangkan upaya kami, telah menjadi optimal untuk lingkungan cloud. Ini adalah biaya terbaik untuk mencadangkan Postgres di cloud.
Apa artinya? Kami mempromosikan ide yang cukup besar: pencadangan harus aman, murah untuk dioperasikan, dan dipulihkan secepat mungkin.
Mengapa pengoperasiannya harus murah? Ketika tidak ada yang rusak, Anda tidak akan tahu bahwa Anda memiliki cadangan. Semuanya berfungsi dengan baik, Anda membuang CPU sesedikit mungkin, Anda menggunakan sumber daya disk sesedikit mungkin, dan Anda mengirim byte sesedikit mungkin ke jaringan agar tidak mengganggu muatan layanan berharga Anda.
Dan ketika semuanya rusak, misalnya admin menjatuhkan data, ada yang tidak beres, dan Anda harus segera kembali ke masa lalu, Anda memulihkan dengan semua uang, karena Anda ingin data Anda kembali dengan cepat dan utuh.
Dan kami mempromosikan ide sederhana ini. Dan, menurut kami, kami berhasil menerapkannya.
Tapi bukan itu saja. Kami menginginkan satu hal kecil lagi. Kami menginginkan banyak database yang berbeda. Tidak semua klien kami menggunakan Postgres. Beberapa orang menggunakan MySQL, MongoDB. Di komunitas, pengembang lain telah mendukung FoundationDB. Dan daftar ini terus bertambah.
Komunitas menyukai gagasan database dijalankan di lingkungan terkelola di cloud. Dan pengembang memelihara database mereka, yang dapat dicadangkan secara seragam bersama Postgres dengan sistem cadangan kami.
Apa yang telah kita pelajari dari cerita ini? Produk kami, sebagai divisi pengembangan, bukanlah baris kode, bukan pernyataan, bukan file. Produk kami bukan permintaan tarik. Ide-ide inilah yang kami sampaikan kepada masyarakat. Ini adalah keahlian teknologi dan pergerakan teknologi menuju lingkungan cloud.
Ada database seperti Postgres. Saya paling menyukai inti Postgres. Saya menghabiskan banyak waktu mengembangkan inti Postgres bersama komunitas.
Namun di sini harus dikatakan bahwa Yandex.Cloud memiliki instalasi internal database terkelola. Dan itu dimulai sejak lama di Yandex.Mail. Keahlian yang kini memimpin Postgres yang dikelola diakumulasikan ketika email ingin dipindahkan ke Postgres.
Mail memiliki persyaratan yang sangat mirip dengan cloud. Anda harus mampu menskalakan pertumbuhan eksponensial yang tidak terduga di titik mana pun dalam data Anda. Dan email tersebut sudah memuat ratusan juta kotak surat dari sejumlah besar pengguna yang terus-menerus membuat banyak permintaan.
Dan ini merupakan tantangan yang cukup serius bagi tim yang mengembangkan Postgres. Saat itu, setiap masalah yang kami temui dilaporkan ke masyarakat. Dan masalah ini telah diperbaiki, dan diperbaiki oleh komunitas di beberapa tempat bahkan pada tingkat dukungan berbayar untuk beberapa database lain dan bahkan lebih baik lagi. Artinya, Anda dapat mengirim surat ke peretas PgSQL dan menerima tanggapan dalam waktu 40 menit. Dukungan berbayar di beberapa database mungkin menganggap ada hal yang lebih diprioritaskan daripada bug Anda.
Sekarang instalasi internal Postgres adalah beberapa petabyte data. Ini adalah jutaan permintaan per detik. Ini adalah ribuan cluster. Ini berskala sangat besar.
Tapi ada nuansanya. Ia tidak hidup pada drive jaringan yang mewah, tetapi pada perangkat keras yang cukup sederhana. Dan ada lingkungan pengujian khusus untuk hal-hal baru yang menarik.
Dan pada saat tertentu di lingkungan pengujian kami menerima pesan yang menunjukkan bahwa invarian internal indeks database dilanggar.
Invarian adalah suatu jenis hubungan yang kita harap akan selalu ada.
Situasi yang sangat kritis bagi kami. Ini menunjukkan bahwa beberapa data mungkin telah hilang. Dan kehilangan data adalah bencana besar.
Gagasan umum yang kami ikuti dalam database terkelola adalah bahwa meskipun ada upaya, data akan sulit hilang. Meskipun Anda sengaja menghapusnya, Anda tetap harus mengabaikan ketidakhadirannya dalam jangka waktu yang lama. Keamanan data adalah agama yang kami anut dengan tekun.
Dan di sini muncul situasi yang menunjukkan bahwa mungkin ada situasi di mana kita mungkin tidak siap menghadapinya. Dan kami mulai bersiap menghadapi situasi ini.
Hal pertama yang kami lakukan adalah mengubur kayu dari ribuan cluster ini. Kami menemukan cluster mana yang terletak di disk dengan firmware bermasalah yang kehilangan pembaruan halaman data. Menandai semua kode data Postgres. Dan kami menandai pesan-pesan yang menunjukkan pelanggaran invarian internal dengan kode yang dirancang untuk mendeteksi kerusakan data.
Patch ini praktis diterima oleh komunitas tanpa banyak diskusi, karena dalam setiap kasus jelas ada sesuatu yang buruk telah terjadi dan perlu dilaporkan ke log.
Setelah ini, kami sampai pada titik bahwa kami memiliki pemantauan yang memindai log. Dan jika ada pesan yang mencurigakan, dia membangunkan petugas jaga, dan petugas jaga memperbaikinya.
Tetapi! Pemindaian log adalah operasi yang murah pada satu cluster dan sangat mahal untuk seribu cluster.
Kami menulis ekstensi bernama . Ini menciptakan tampilan database di mana Anda dapat dengan murah dan cepat memilih statistik kesalahan masa lalu. Dan jika kita perlu membangunkan petugas jaga, maka kita akan mengetahuinya tanpa memindai file gigabyte, tetapi dengan mengekstrak beberapa byte dari tabel hash.
Ekstensi ini telah diadopsi, misalnya, di repositori untuk . Jika ingin menggunakannya, Anda bisa menginstalnya sendiri. Tentu saja ini open source.
Tapi bukan itu saja. Kami mulai menggunakan Amcheck, ekstensi buatan komunitas, untuk menemukan pelanggaran invarian dalam indeks.
Dan kami menemukan bahwa jika Anda mengoperasikannya dalam skala besar, terdapat bug. Kami mulai memperbaikinya. Koreksi kami telah diterima.
Kami menemukan bahwa ekstensi ini tidak dapat menganalisis indeks GiST & GIT. Kami membuat mereka mendukung. Namun dukungan ini masih terus dibicarakan oleh komunitas karena ini merupakan fungsi yang relatif baru dan banyak detailnya di sana.
Dan kami juga menemukan bahwa ketika memeriksa indeks pelanggaran pada pemimpin replikasi, pada master, semuanya berfungsi dengan baik, tetapi pada replika, pada pengikut, pencarian korupsi tidak begitu efektif. Tidak semua invarian dicentang. Dan satu invarian sangat mengganggu kami. Dan kami menghabiskan satu setengah tahun berkomunikasi dengan komunitas untuk memungkinkan pemeriksaan replika ini.
Kami menulis kode yang harus mengikuti semua... protokol. Kami mendiskusikan patch ini cukup lama dengan Peter Gaghan dari Crunchy Data. Dia harus sedikit memodifikasi B-tree yang ada di Postgres untuk menerima patch ini. Dia diterima. Dan kini pemeriksaan indeks pada replika juga menjadi cukup efektif untuk mendeteksi pelanggaran yang kami temui. Artinya, pelanggaran-pelanggaran tersebut dapat disebabkan oleh kesalahan pada firmware disk, bug pada Postgres, bug pada kernel Linux, dan masalah perangkat keras. Daftar sumber masalah yang sedang kami persiapkan cukup lengkap.
Namun selain indeks, ada bagian yang disebut heap, yaitu tempat penyimpanan data. Dan tidak banyak invarian yang bisa diperiksa.
Kami memiliki ekstensi yang disebut Heapcheck. Kami mulai mengembangkannya. Dan secara paralel, bersama kami, perusahaan EnterpriseDB juga mulai menulis modul, yang mereka sebut dengan cara yang sama Heapcheck. Hanya kami yang menyebutnya PgHeapcheck, dan mereka menyebutnya Heapcheck saja. Mereka memilikinya dengan fungsi serupa, tanda tangan yang sedikit berbeda, tetapi dengan ide yang sama. Mereka menerapkannya sedikit lebih baik di beberapa tempat. Dan mereka mempostingnya di open source sebelumnya.
Dan sekarang kita kembangkan pemekaran mereka, karena bukan lagi pemekaran mereka, tapi pemekaran komunitas. Dan kedepannya, ini adalah bagian dari kernel yang akan diberikan kepada semua orang agar mereka dapat mengetahui masalah yang akan datang terlebih dahulu.
Di beberapa tempat, kami bahkan sampai pada kesimpulan bahwa ada hasil positif palsu dalam sistem pemantauan kami. Misalnya, sistem 1C. Saat menggunakan database, Postgres terkadang menulis data ke dalamnya yang bisa dibaca, tetapi pg_dump tidak bisa membaca.
Situasi ini tampak seperti kerusakan pada sistem deteksi masalah kami. Petugas jaga terbangun. Petugas jaga melihat apa yang terjadi. Setelah beberapa waktu, seorang klien datang dan mengatakan bahwa saya mempunyai masalah. Petugas menjelaskan apa masalahnya. Namun masalahnya ada pada inti Postgres.
Saya menemukan diskusi tentang fitur ini. Dan dia menulis bahwa kami menemukan fitur ini dan itu tidak menyenangkan, seseorang terbangun di malam hari untuk mencari tahu apa itu.
Komunitas menjawab, “Oh, kami benar-benar harus memperbaikinya.”
Saya punya analogi sederhana. Jika Anda berjalan dengan sepatu yang memiliki sebutir pasir di dalamnya, maka pada prinsipnya Anda dapat melanjutkan - tidak masalah. Jika Anda menjual sepatu bot ke ribuan orang, maka mari kita membuat sepatu bot tanpa pasir sama sekali. Dan jika salah satu pengguna sepatu Anda akan lari maraton, Anda ingin membuat sepatu yang sangat bagus, lalu menskalakannya ke semua pengguna Anda. Dan pengguna tak terduga seperti itu selalu berada di lingkungan cloud. Selalu ada pengguna yang mengeksploitasi cluster dengan cara yang orisinal. Anda harus selalu bersiap untuk ini.
Apa yang telah kita pelajari di sini? Kami belajar satu hal sederhana: yang terpenting adalah menjelaskan kepada masyarakat bahwa ada masalah. Jika masyarakat telah menyadari permasalahannya, maka timbullah persaingan alamiah untuk menyelesaikan permasalahan tersebut. Karena semua orang ingin menyelesaikan masalah penting. Semua vendor, semua peretas memahami bahwa mereka sendiri dapat menginjak penggaruk ini, jadi mereka ingin menghilangkannya.
Jika Anda sedang mengerjakan suatu masalah, tetapi tidak mengganggu siapa pun kecuali Anda, tetapi Anda mengerjakannya secara sistematis dan pada akhirnya dianggap sebagai masalah, maka pull request Anda pasti akan diterima. Patch Anda akan diterima, perbaikan Anda atau bahkan permintaan perbaikan akan ditinjau oleh komunitas. Pada akhirnya, kami membuat database menjadi lebih baik untuk satu sama lain.
Database yang menarik adalah Greenplum. Ini adalah database yang sangat paralel berdasarkan basis kode Postgres, yang sangat saya kenal.
Dan Greenplum memiliki fungsi menarik - menambahkan tabel yang dioptimalkan. Ini adalah tabel yang dapat Anda tambahkan dengan cepat. Mereka bisa berbentuk kolom atau baris.
Namun tidak ada clustering, yaitu tidak ada fungsi dimana Anda dapat mengatur data yang terletak pada tabel sesuai dengan urutan yang ada di salah satu indeks.
Orang-orang dari taksi mendatangi saya dan berkata: “Andrey, Anda kenal Postgres. Dan di sini hampir sama. Beralih ke 20 menit. Ambillah dan lakukanlah.” Saya pikir ya, saya tahu Postgres, beralih selama 20 menit - saya perlu melakukan ini.
Tapi tidak, itu bukan 20 menit, saya menulisnya selama berbulan-bulan. Pada konferensi PgConf.Russia, saya mendekati Heikki Linakangas dari Pivotal dan bertanya: “Apakah ada masalah dengan ini? Mengapa tidak ada penambahan pengelompokan tabel yang dioptimalkan?” Dia berkata: “Anda mengambil datanya. Anda mengurutkan, Anda mengatur ulang. Itu hanya pekerjaan." Saya: “Oh ya, kamu hanya perlu mengambilnya dan melakukannya.” Dia berkata: “Ya, kita memerlukan tangan yang bebas untuk melakukan ini.” Saya pikir saya pasti perlu melakukan ini.
Dan beberapa bulan kemudian saya mengirimkan permintaan tarik yang mengimplementasikan fungsi ini. Permintaan penarikan ini ditinjau oleh Pivotal bersama komunitas. Tentu saja ada bug.
Namun yang paling menarik adalah ketika pull request ini digabungkan, ditemukan bug di Greenplum itu sendiri. Kami menemukan bahwa tabel heap terkadang merusak transaksionalitas ketika dikelompokkan. Dan ini merupakan hal yang perlu diperbaiki. Dan dia ada di tempat yang baru saja saya sentuh. Dan reaksi alami saya adalah – oke, izinkan saya melakukan ini juga.
Saya memperbaiki bug ini. Mengirim permintaan tarik ke pemecah masalah. Dia terbunuh.
Setelah itu ternyata fungsi tersebut perlu didapatkan pada versi Greenplum untuk PostgreSQL 12. Artinya, petualangan 20 menit tersebut dilanjutkan dengan petualangan baru yang menarik. Menarik sekali untuk menyentuh perkembangan saat ini, dimana komunitas sedang memotong fitur-fitur baru dan terpenting. Ini beku.
Tapi itu tidak berakhir di situ. Bagaimanapun, ternyata kami perlu menulis dokumentasi untuk semua ini.
Saya mulai menulis dokumentasi. Untungnya, pembuat dokumenter dari Pivotal datang. Bahasa Inggris adalah bahasa ibu mereka. Mereka membantu saya dengan dokumentasi. Faktanya, mereka sendiri menulis ulang apa yang saya usulkan ke dalam bahasa Inggris yang sebenarnya.
Dan di sini, tampaknya, petualangannya berakhir. Dan tahukah Anda apa yang terjadi kemudian? Orang-orang dari taksi mendatangi saya dan berkata: “Masih ada dua petualangan, masing-masing 10 menit.” Dan apa yang harus kukatakan pada mereka? Saya bilang sekarang saya akan memberikan laporan dalam skala besar, lalu kita lihat petualangan Anda, karena ini pekerjaan yang menarik.
Apa yang kita pelajari dari kasus ini? Karena bekerja dengan open source selalu bekerja dengan orang tertentu, selalu bekerja dengan komunitas. Karena di setiap tahap saya bekerja dengan beberapa pengembang, beberapa penguji, beberapa hacker, beberapa pembuat dokumenter, beberapa arsitek. Saya tidak bekerja dengan Greenplum, saya bekerja dengan orang-orang di sekitar Greenplum.
Tetapi! Ada poin penting lainnya - ini hanya pekerjaan. Artinya, Anda datang, minum kopi, menulis kode. Segala macam invarian sederhana berfungsi. Lakukan secara normal - semuanya akan baik-baik saja! Dan itu pekerjaan yang cukup menarik. Ada permintaan untuk pekerjaan ini dari klien Yandex.Cloud, pengguna cluster kami baik di dalam Yandex maupun di luar. Dan menurut saya jumlah proyek yang kami ikuti akan meningkat dan kedalaman keterlibatan kami juga akan meningkat.
Itu saja. Mari kita beralih ke pertanyaan.
Sesi pertanyaan
Halo! Kami memiliki sesi tanya jawab lagi. Dan di studio Andrey Borodin. Ini adalah orang yang baru saja memberi tahu Anda tentang kontribusi Yandex.Cloud dan Yandex terhadap open source. Laporan kami saat ini tidak sepenuhnya tentang Cloud, namun pada saat yang sama kami didasarkan pada teknologi tersebut. Tanpa apa yang Anda lakukan di Yandex, tidak akan ada layanan di Yandex.Cloud, jadi terima kasih dari saya pribadi. Dan pertanyaan pertama dari siaran tersebut: “Proyek apa yang Anda sebutkan tertulis di dalamnya?”
Sistem cadangan di WAL-G ditulis dalam Go. Ini adalah salah satu proyek baru yang kami kerjakan. Dia benar-benar baru berusia 3 tahun. Dan database seringkali tentang keandalan. Artinya databasenya sudah cukup tua dan biasanya ditulis dalam C. Proyek Postgres dimulai sekitar 30 tahun yang lalu. Maka C89 adalah pilihan yang tepat. Dan Postgres tertulis di atasnya. Database yang lebih modern seperti ClickHouse biasanya ditulis dalam C++. Semua pengembangan sistem didasarkan pada C dan C++.
Pertanyaan dari manajer keuangan kami, yang bertanggung jawab atas pengeluaran di Cloud: “Mengapa Cloud menghabiskan uang untuk mendukung open source?”
Ada jawaban sederhana untuk manajer keuangan di sini. Hal ini kami lakukan agar pelayanan kami menjadi lebih baik. Dalam hal apa kita bisa berbuat lebih baik? Kita dapat melakukan berbagai hal dengan lebih efisien, lebih cepat, dan menjadikannya lebih terukur. Namun bagi kami, cerita ini terutama tentang keandalan. Misalnya, dalam sistem cadangan, kami meninjau 100% patch yang berlaku padanya. Kami tahu apa kodenya. Dan kami lebih nyaman meluncurkan versi baru ke produksi. Pertama-tama, ini tentang kepercayaan diri, kesiapan untuk pengembangan, dan keandalan
Pertanyaan lain: “Apakah persyaratan pengguna eksternal yang tinggal di Yandex.Cloud berbeda dengan pengguna internal yang tinggal di Cloud internal?”
Profil muatannya tentu saja berbeda. Namun dari sudut pandang departemen saya, semua kasus khusus dan menarik dibuat dengan beban non-standar. Pengembang dengan imajinasi, pengembang yang melakukan hal-hal tak terduga, kemungkinan besar ditemukan baik secara internal maupun eksternal. Dalam hal ini, kita semua kurang lebih sama. Dan, mungkin, satu-satunya fitur penting dalam pengoperasian database Yandex adalah bahwa di dalam Yandex kami memiliki pengajaran. Pada titik tertentu, beberapa zona ketersediaan benar-benar menjadi bayangan, dan semua layanan Yandex harus terus berfungsi meskipun demikian. Ini adalah perbedaan kecil. Tapi itu menciptakan banyak pengembangan penelitian pada antarmuka database dan tumpukan jaringan. Jika tidak, instalasi eksternal dan internal menghasilkan permintaan fitur yang sama dan permintaan serupa untuk meningkatkan keandalan dan kinerja.
Pertanyaan berikutnya: “Bagaimana perasaan Anda secara pribadi tentang kenyataan bahwa sebagian besar dari apa yang Anda lakukan digunakan oleh Cloud lain?” Kami tidak akan menyebutkan nama spesifiknya, tetapi banyak proyek yang dilakukan di Yandex.Cloud digunakan di cloud orang lain.
Ini keren. Pertama, itu tanda bahwa kita telah melakukan sesuatu dengan benar. Dan itu menggores ego. Dan kami lebih yakin bahwa kami mengambil keputusan yang tepat. Di sisi lain, ini adalah harapan bahwa di masa depan ini akan membawa kita ide-ide baru, permintaan baru dari pengguna pihak ketiga. Sebagian besar masalah di GitHub dibuat oleh administrator sistem individu, DBA individu, arsitek individu, insinyur individu, tetapi kadang-kadang orang dengan pengalaman sistematis datang dan mengatakan bahwa dalam 30% kasus tertentu kita memiliki masalah ini dan mari kita memikirkan cara mengatasinya. Inilah yang paling kami nantikan. Kami berharap dapat berbagi pengalaman dengan platform cloud lainnya.
Anda berbicara banyak tentang maraton. Saya tahu Anda lari maraton di Moskow. Sebagai akibat? Menyalip orang-orang dari PostgreSQL?
Tidak, Oleg Bartunov berlari sangat cepat. Dia selesai satu jam lebih awal dariku. Secara keseluruhan, saya senang dengan sejauh mana pencapaian saya. Bagi saya, finis saja sudah merupakan sebuah pencapaian. Secara keseluruhan, sungguh mengejutkan bahwa ada begitu banyak pelari di komunitas postgres. Tampak bagi saya ada semacam hubungan antara olahraga aerobik dan keinginan untuk pemrograman sistem.
Apakah Anda mengatakan tidak ada pelari di ClickHouse?
Saya tahu pasti bahwa mereka ada di sana. ClickHouse juga merupakan database. Ngomong-ngomong, Oleg sekarang menulis kepada saya: "Bagaimana kalau kita lari setelah laporan itu?" Ini adalah ide yang bagus.
Pertanyaan lain dari siaran dari Nikita: “Mengapa Anda sendiri yang memperbaiki bug di Greenplum dan tidak memberikannya kepada junior?” Benar, tidak begitu jelas apa bugnya dan di layanan mana, tapi mungkin yang dimaksud adalah bug yang Anda bicarakan.
Ya, pada prinsipnya bisa saja diberikan kepada seseorang. Itu hanya kode yang baru saja saya ubah. Dan wajar untuk terus melakukannya. Pada prinsipnya, ide berbagi keahlian dengan tim adalah ide yang bagus. Kami pasti akan membagi tugas Greenplum di antara seluruh anggota divisi kami.
Karena kita berbicara tentang junior, inilah pertanyaannya. Orang tersebut memutuskan untuk membuat komit pertama di Postgres. Apa yang perlu dia lakukan untuk melakukan komitmen pertama?
Ini adalah pertanyaan yang menarik: “Di mana memulainya?” Biasanya cukup sulit untuk memulai dengan sesuatu di dalam kernel. Di Postgres, misalnya, ada daftar tugas. Namun nyatanya, ini adalah lembaran dari apa yang mereka coba lakukan, namun tidak berhasil. Ini adalah hal-hal yang rumit. Dan biasanya Anda dapat menemukan beberapa utilitas di ekosistem, beberapa ekstensi yang dapat ditingkatkan, yang kurang menarik perhatian pengembang kernel. Oleh karena itu, ada lebih banyak poin pertumbuhan di sana. Pada program kode Musim Panas Google, setiap tahun komunitas postgres mengedepankan banyak topik berbeda yang dapat dibahas. Tahun ini, menurut saya, kami memiliki tiga siswa. Seseorang bahkan menulis di WAL-G tentang topik yang penting bagi Yandex. Di Greenplum, semuanya lebih sederhana daripada di komunitas Postgres, karena peretas Greenplum menangani permintaan tarik dengan sangat baik dan segera mulai meninjau. Mengirim patch ke Postgres membutuhkan waktu beberapa bulan, tetapi Greenplum akan datang dalam satu hari dan melihat apa yang telah Anda lakukan. Hal lainnya adalah Greenplum perlu menyelesaikan masalah saat ini. Greenplum tidak banyak digunakan, sehingga menemukan masalah Anda cukup sulit. Dan pertama-tama, tentu saja kita perlu memecahkan masalah.
Sumber: www.habr.com