Sumbangan Yandex kepada pangkalan data berikut akan disemak.
- Klik Rumah
- RapidKL
- Pemulihan ke satu titik masa (WAL-G)
- PostgreSQL (termasuk logerrors, Amcheck, heapcheck)
- Greenplum
Video:
Hai dunia! Nama saya Andrey Borodin. Dan apa yang saya lakukan di Yandex.Cloud ialah membangunkan pangkalan data hubungan terbuka untuk kepentingan pelanggan Yandex.Cloud dan Yandex.Cloud.
Dalam ceramah ini, kita akan bercakap tentang cabaran yang dihadapi pangkalan data terbuka pada skala. Mengapa ia penting? Kerana masalah kecil-kecilan yang, seperti nyamuk, kemudian menjadi gajah. Mereka menjadi besar apabila anda mempunyai banyak kelompok.
Tetapi itu bukan perkara utama. Perkara yang luar biasa berlaku. Perkara yang berlaku dalam satu dalam sejuta kes. Dan dalam persekitaran awan, anda perlu bersedia untuk itu, kerana perkara yang luar biasa menjadi sangat berkemungkinan apabila sesuatu wujud pada skala.
Tetapi! Apakah kelebihan pangkalan data terbuka? Hakikatnya ialah anda mempunyai peluang teori untuk menangani sebarang masalah. Anda mempunyai kod sumber, anda mempunyai pengetahuan pengaturcaraan. Kami menggabungkannya dan ia berfungsi.
Apakah pendekatan yang ada dalam mengusahakan perisian sumber terbuka?
- Pendekatan yang paling mudah ialah menggunakan perisian. Jika anda menggunakan protokol, jika anda menggunakan standard, jika anda menggunakan format, jika anda menulis pertanyaan dalam perisian sumber terbuka, maka anda sudah menyokongnya.
- Anda menjadikan ekosistemnya lebih besar. Anda menjadikan kemungkinan pengesanan awal pepijat lebih besar. Anda meningkatkan kebolehpercayaan sistem ini. Anda meningkatkan ketersediaan pembangun di pasaran. Anda menambah baik perisian ini. Anda sudah pun menjadi penyumbang jika anda baru sahaja mendapat gaya dan bermain-main dengan sesuatu di sana.
- Satu lagi pendekatan yang boleh difahami ialah menaja perisian sumber terbuka. Contohnya, program Google Summer of Code yang terkenal, apabila Google membayar sejumlah besar pelajar dari seluruh dunia wang yang boleh difahami supaya mereka membangunkan projek perisian terbuka yang memenuhi keperluan pelesenan tertentu.
- Ini adalah pendekatan yang sangat menarik kerana ia membolehkan perisian berkembang tanpa mengalihkan tumpuan daripada komuniti. Google, sebagai gergasi teknologi, tidak mengatakan bahawa kami mahukan ciri ini, kami mahu membetulkan pepijat ini dan di sinilah kami perlu menggali. Google berkata: "Lakukan apa yang anda lakukan. Teruskan bekerja dengan cara anda bekerja dan semuanya akan baik-baik saja."
- Pendekatan seterusnya untuk mengambil bahagian dalam sumber terbuka ialah penyertaan. Apabila anda menghadapi masalah dalam perisian sumber terbuka dan terdapat pembangun, pembangun anda mula menyelesaikan masalah tersebut. Mereka mula menjadikan infrastruktur anda lebih cekap, program anda lebih pantas dan lebih dipercayai.
Salah satu projek Yandex yang paling terkenal dalam bidang perisian sumber terbuka ialah ClickHouse. Ini adalah pangkalan data yang dilahirkan sebagai tindak balas kepada cabaran yang dihadapi Yandex.Metrica.
Dan sebagai pangkalan data, ia dibuat dalam sumber terbuka untuk mencipta ekosistem dan membangunkannya bersama-sama dengan pembangun lain (bukan sahaja dalam Yandex). Dan kini ini adalah projek besar di mana banyak syarikat yang berbeza terlibat.
Dalam Yandex.Cloud, kami mencipta ClickHouse di atas Penyimpanan Objek Yandex, iaitu di atas storan awan.
Mengapa ini penting dalam awan? Kerana mana-mana pangkalan data berfungsi dalam segi tiga ini, dalam piramid ini, dalam hierarki jenis memori ini. Anda mempunyai daftar cepat tetapi kecil dan SSD besar tetapi perlahan yang murah, cakera keras dan beberapa peranti blok lain. Dan jika anda cekap di bahagian atas piramid, maka anda mempunyai pangkalan data yang pantas. jika anda cekap di bahagian bawah piramid ini, maka anda mempunyai pangkalan data berskala. Dan dalam hal ini, menambah lapisan lain dari bawah adalah pendekatan logik untuk meningkatkan kebolehskalaan pangkalan data.
Bagaimana ia boleh dilakukan? Ini adalah perkara penting dalam laporan ini.
- Kami boleh melaksanakan ClickHouse melalui MDS. MDS ialah antara muka storan awan Yandex dalaman. Ia lebih kompleks daripada protokol S3 biasa, tetapi ia lebih sesuai untuk peranti blok. Ia lebih baik untuk merekod data. Ia memerlukan lebih banyak pengaturcaraan. Pengaturcara akan memprogram, malah bagus, menarik.
- S3 ialah pendekatan yang lebih biasa yang menjadikan antara muka lebih mudah dengan kos penyesuaian yang kurang kepada jenis beban kerja tertentu.
Sememangnya, kami ingin menyediakan fungsi kepada keseluruhan ekosistem ClickHouse dan melakukan tugas yang diperlukan dalam Yandex.Cloud, kami memutuskan untuk memastikan bahawa seluruh komuniti ClickHouse akan mendapat manfaat daripadanya. Kami melaksanakan ClickHouse melalui S3, bukan ClickHouse melalui MDS. Dan ini adalah banyak kerja.
Rujukan:
"Lapisan abstraksi sistem fail"
"Penyepaduan AWS SDK S3"
"Pelaksanaan asas antara muka IDisk untuk S3"
"Integrasi enjin storan log dengan antara muka IDisk"
"Log sokongan enjin untuk S3 dan SeekableReadBuffer"
"Storage Stripe Log S3 sokongan"
"Storage MergeTree sokongan awal untuk S3"
"Sokongan penuh MergeTree untuk S3"
"Sokongan ReplicatedMergeTree melalui S3"
"Tambah bukti kelayakan lalai dan pengepala tersuai untuk storan s3"
"S3 dengan konfigurasi proksi dinamik"
"S3 dengan penyelesai proksi"
Ini ialah senarai permintaan tarik untuk melaksanakan sistem fail maya dalam ClickHouse. Ini adalah sejumlah besar permintaan tarik.
Rujukan:
"Pautan keras DiskS3 pelaksanaan optimum"
βPelanggan HTTP S3 β Elakkan menyalin aliran respons ke dalam memoriβ
βElakkan menyalin keseluruhan aliran respons ke dalam memori dalam HTTP S3
pelanggan"
"Keupayaan untuk menanda cache dan mengindeks fail untuk cakera S3"
"Pindahkan bahagian dari DiskLocal ke DiskS3 secara selari"
Tetapi kerja itu tidak berakhir di sana. Selepas ciri itu dibuat, beberapa kerja lagi diperlukan untuk mengoptimumkan fungsi ini.
Rujukan:
"Tambah acara SelectedRows dan SelectedBytes"
"Tambahkan acara pemprofilan daripada permintaan S3 ke system.events"
"Tambah QueryTimeMicroseconds, SelectQueryTimeMicroseconds dan InsertQueryTimeMicroseconds"
Dan kemudian adalah perlu untuk menjadikannya boleh didiagnosis, menyediakan pemantauan dan menjadikannya boleh diurus.
Dan semua ini dilakukan supaya seluruh komuniti, keseluruhan ekosistem ClickHouse, menerima hasil kerja ini.
Mari kita beralih kepada pangkalan data transaksi, kepada pangkalan data OLTP, yang lebih dekat dengan saya secara peribadi.
Ini ialah bahagian pembangunan DBMS sumber terbuka. Mereka ini melakukan sihir jalanan untuk menambah baik pangkalan data terbuka transaksi.
Salah satu projek, menggunakan contoh yang boleh kita bincangkan tentang cara dan perkara yang kita lakukan, ialah Connection Pooler dalam Postgres.
Postgres ialah pangkalan data proses. Ini bermakna pangkalan data harus mempunyai sesedikit mungkin sambungan rangkaian yang mengendalikan transaksi.
Sebaliknya, dalam persekitaran awan, situasi biasa ialah apabila seribu sambungan datang ke satu gugusan sekaligus. Dan tugas pengumpul sambungan adalah untuk membungkus seribu sambungan ke dalam sebilangan kecil sambungan pelayan.
Kita boleh mengatakan bahawa pengumpul sambungan ialah pengendali telefon yang menyusun semula bait supaya ia mencapai pangkalan data dengan cekap.
Malangnya, tiada perkataan Rusia yang baik untuk pengumpul sambungan. Kadang-kadang ia dipanggil sambungan pemultipleks. Jika anda tahu apa yang perlu dipanggil pengumpul sambungan, maka pastikan anda memberitahu saya, saya akan sangat gembira untuk bercakap bahasa teknikal Rusia yang betul.
Kami menyiasat pengumpul sambungan yang sesuai untuk kelompok pascagres terurus. Dan PgBouncer adalah pilihan terbaik untuk kami. Tetapi kami menghadapi beberapa masalah dengan PgBouncer. Bertahun-tahun yang lalu, Volodya Borodin memberikan laporan bahawa kami menggunakan PgBouncer, kami menyukai segala-galanya, tetapi ada nuansa, ada sesuatu yang perlu diusahakan.
Dan kami bekerja. Kami membetulkan masalah yang kami hadapi, kami menampal Bouncer, dan cuba menolak permintaan tarik ke hulu. Tetapi benang tunggal asas sukar untuk digunakan.
Kami terpaksa mengumpul lata daripada Bouncers yang ditampal. Apabila kita mempunyai banyak Bouncers satu benang, sambungan pada lapisan atas dipindahkan ke lapisan dalam Bouncers. Ini adalah sistem yang diurus dengan baik yang sukar untuk dibina dan diskalakan ke belakang dan ke belakang.
Kami sampai pada kesimpulan bahawa kami mencipta pengumpul sambungan kami sendiri, yang dipanggil Odyssey. Kami menulisnya dari awal.
Pada tahun 2019, pada persidangan PgCon, saya menyampaikan pengumpul ini kepada komuniti pembangun. Kini kami mempunyai kurang daripada 2 bintang di GitHub, iaitu projek itu masih hidup, projek itu popular.
Dan jika anda mencipta kluster Postgres dalam Yandex.Cloud, maka kluster itu akan menjadi kluster dengan Odyssey terbina dalam, yang dikonfigurasikan semula apabila menskala kluster ke belakang atau ke hadapan.
Apa yang kami pelajari daripada projek ini? Melancarkan projek yang bersaing sentiasa merupakan langkah yang agresif, ia adalah langkah yang melampau apabila kita mengatakan bahawa terdapat masalah yang tidak dapat diselesaikan dengan cukup cepat, tidak diselesaikan dalam selang masa yang sesuai dengan kita. Tetapi ini adalah langkah yang berkesan.
PgBouncer mula berkembang dengan lebih pantas.
Dan kini projek lain telah muncul. Contohnya, pgagroal, yang dibangunkan oleh pembangun Red Hat. Mereka mengejar matlamat yang sama dan melaksanakan idea yang serupa, tetapi, sudah tentu, dengan spesifik mereka sendiri, yang lebih dekat dengan pembangun pgagroal.
Satu lagi kes bekerja dengan komuniti postgres sedang memulihkan ke titik masa. Ini adalah pemulihan selepas kegagalan, ini adalah pemulihan daripada sandaran.
Terdapat banyak sandaran dan semuanya berbeza. Hampir setiap vendor Postgres mempunyai penyelesaian sandaran sendiri.
Jika anda mengambil semua sistem sandaran, buat matriks ciri dan secara berseloroh mengira penentu dalam matriks ini, ia akan menjadi sifar. Apakah maksud ini? Bagaimana jika anda mengambil fail sandaran tertentu, maka ia tidak boleh dipasang dari kepingan semua yang lain. Ia unik dalam pelaksanaannya, ia unik dalam tujuannya, ia unik dalam idea-idea yang tertanam di dalamnya. Dan mereka semua khusus.
Semasa kami mengusahakan isu ini, CitusData melancarkan projek WAL-G. Ini ialah sistem sandaran yang dibuat dengan memperhatikan persekitaran awan. Kini CitusData sudah pun menjadi sebahagian daripada Microsoft. Dan pada masa itu, kami sangat menyukai idea-idea yang telah ditetapkan dalam keluaran awal WAL-G. Dan kami mula menyumbang kepada projek ini.
Kini terdapat berpuluh-puluh pembangun dalam projek ini, tetapi 10 penyumbang teratas kepada WAL-G termasuk 6 Yandexoids. Kami membawa banyak idea kami ke sana. Dan, sudah tentu, kami melaksanakannya sendiri, mengujinya sendiri, melancarkannya ke dalam pengeluaran sendiri, kami menggunakannya sendiri, kami sendiri memikirkan ke mana untuk bergerak seterusnya, sambil berinteraksi dengan komuniti WAL-G yang besar.
Dan dari sudut pandangan kami, kini sistem sandaran ini, termasuk mengambil kira usaha kami, telah menjadi optimum untuk persekitaran awan. Ini adalah kos terbaik untuk membuat sandaran Postgres dalam awan.
Apakah maksudnya? Kami mempromosikan idea yang agak besar: sandaran harus selamat, murah untuk dikendalikan dan secepat mungkin untuk memulihkan.
Kenapa perlu murah untuk beroperasi? Apabila tiada apa-apa yang rosak, anda sepatutnya tidak tahu anda mempunyai sandaran. Semuanya berfungsi dengan baik, anda membazirkan sedikit CPU yang mungkin, anda menggunakan sesedikit mungkin sumber cakera anda, dan anda menghantar sesedikit bait ke rangkaian yang mungkin supaya tidak mengganggu muatan perkhidmatan berharga anda.
Dan apabila semuanya rosak, sebagai contoh, pentadbir menggugurkan data, sesuatu telah berlaku, dan anda perlu segera kembali ke masa lalu, anda pulih dengan semua wang, kerana anda mahu data anda kembali dengan cepat dan utuh.
Dan kami mempromosikan idea mudah ini. Dan, nampaknya kami, kami berjaya melaksanakannya.
Tetapi bukan itu sahaja. Kami mahukan satu lagi perkara kecil. Kami mahukan banyak pangkalan data yang berbeza. Tidak semua pelanggan kami menggunakan Postgres. Sesetengah orang menggunakan MySQL, MongoDB. Dalam komuniti, pembangun lain telah menyokong FoundationDB. Dan senarai ini sentiasa berkembang.
Komuniti menyukai idea pangkalan data dijalankan dalam persekitaran terurus di awan. Dan pembangun mengekalkan pangkalan data mereka, yang boleh disandarkan secara seragam bersama Postgres dengan sistem sandaran kami.
Apa yang kita pelajari daripada kisah ini? Produk kami, sebagai bahagian pembangunan, bukan baris kod, ia bukan pernyataan, ia bukan fail. Produk kami bukan permintaan tarik. Inilah idea yang kami sampaikan kepada masyarakat. Ini adalah kepakaran teknologi dan pergerakan teknologi ke arah persekitaran awan.
Terdapat pangkalan data seperti Postgres. Saya paling suka teras Postgres. Saya menghabiskan banyak masa membangunkan teras Postgres dengan komuniti.
Tetapi di sini mesti dikatakan bahawa Yandex.Cloud mempunyai pemasangan dalaman pangkalan data terurus. Dan ia bermula lama dahulu dalam Yandex.Mail. Kepakaran yang kini telah membawa kepada Postgres terurus telah terkumpul apabila mel itu ingin berpindah ke Postgres.
Mel mempunyai keperluan yang hampir sama dengan awan. Ia memerlukan anda untuk dapat menskalakan kepada pertumbuhan eksponen yang tidak dijangka pada bila-bila masa dalam data anda. Dan mel itu sudah mempunyai beban dengan kira-kira ratusan juta peti mel dari sejumlah besar pengguna yang sentiasa membuat banyak permintaan.
Dan ini merupakan cabaran yang agak serius bagi pasukan yang sedang membangunkan Postgres. Ketika itu, sebarang masalah yang kami hadapi telah dilaporkan kepada masyarakat. Dan masalah ini telah diperbetulkan, dan diperbetulkan oleh komuniti di beberapa tempat walaupun pada tahap sokongan berbayar untuk beberapa pangkalan data lain dan lebih baik lagi. Iaitu, anda boleh menghantar surat kepada penggodam PgSQL dan menerima jawapan dalam masa 40 minit. Sokongan berbayar dalam sesetengah pangkalan data mungkin berfikir bahawa terdapat lebih banyak perkara yang diutamakan daripada pepijat anda.
Sekarang pemasangan dalaman Postgres ialah beberapa petabait data. Ini adalah beberapa jutaan permintaan sesaat. Ini adalah beribu-ribu kluster. Ia sangat berskala besar.
Tetapi ada nuansa. Ia tidak hidup pada pemacu rangkaian mewah, tetapi pada perkakasan yang agak mudah. Dan terdapat persekitaran ujian khusus untuk perkara baharu yang menarik.
Dan pada masa tertentu dalam persekitaran ujian kami menerima mesej yang menunjukkan bahawa invarian dalaman indeks pangkalan data telah dilanggar.
Invarian ialah sejenis perhubungan yang kita harapkan akan sentiasa dipegang.
Keadaan yang sangat kritikal bagi kami. Ia menunjukkan bahawa beberapa data mungkin telah hilang. Dan kehilangan data adalah sesuatu yang benar-benar malapetaka.
Idea umum yang kami ikuti dalam pangkalan data terurus ialah walaupun dengan usaha, ia akan menjadi sukar untuk kehilangan data. Walaupun anda sengaja mengeluarkannya, anda masih perlu mengabaikan ketiadaan mereka untuk jangka masa yang panjang. Keselamatan data adalah agama yang kami ikuti dengan cukup tekun.
Dan di sini timbul satu situasi yang menunjukkan bahawa mungkin ada situasi yang mungkin kita tidak bersedia. Dan kami mula bersedia untuk situasi ini.
Perkara pertama yang kami lakukan ialah menguburkan kayu balak daripada beribu-ribu kluster ini. Kami mendapati kumpulan mana yang terletak pada cakera dengan perisian tegar bermasalah yang kehilangan kemas kini halaman data. Menandakan semua kod data Postgres. Dan kami menandai mesej yang menunjukkan pelanggaran invarian dalaman dengan kod yang direka untuk mengesan kerosakan data.
Tampalan ini secara praktikal diterima oleh komuniti tanpa banyak perbincangan, kerana dalam setiap kes tertentu adalah jelas bahawa sesuatu yang buruk telah berlaku dan perlu dilaporkan kepada log.
Selepas ini, kami sampai ke tahap bahawa kami mempunyai pemantauan yang mengimbas log. Dan sekiranya terdapat mesej yang mencurigakan, dia membangunkan pegawai bertugas, dan pegawai bertugas membaikinya.
Tetapi! Mengimbas log adalah operasi yang murah pada satu kluster dan mahal untuk seribu kluster.
Kami menulis sambungan yang dipanggil . Ia mencipta paparan pangkalan data di mana anda boleh dengan murah dan cepat memilih statistik tentang ralat lalu. Dan jika kita perlu membangunkan pegawai bertugas, maka kita akan mengetahui tentang perkara ini tanpa mengimbas fail gigabait, tetapi dengan mengekstrak beberapa bait dari jadual cincang.
Sambungan ini telah diterima pakai, sebagai contoh, dalam repositori untuk . Jika anda ingin menggunakannya, anda boleh memasangnya sendiri. Sudah tentu ia adalah sumber terbuka.
Tetapi bukan itu sahaja. Kami mula menggunakan Amcheck, sambungan yang dibina komuniti, untuk mencari pelanggaran invarian dalam indeks.
Dan kami mendapati bahawa jika anda mengendalikannya pada skala, terdapat pepijat. Kami mula membetulkannya. Pembetulan kami telah diterima.
Kami mendapati bahawa sambungan ini tidak boleh menganalisis indeks GiST & GIT. Kami membuat mereka menyokong. Tetapi sokongan ini masih dibincangkan oleh komuniti, kerana ini adalah fungsi yang agak baru dan terdapat banyak butiran di sana.
Dan kami juga mendapati bahawa apabila menyemak indeks untuk pelanggaran pada ketua replikasi, pada tuan, semuanya berfungsi dengan baik, tetapi pada replika, pada pengikut, pencarian rasuah tidak begitu berkesan. Tidak semua invarian disemak. Dan satu invarian sangat mengganggu kami. Dan kami menghabiskan satu setengah tahun berkomunikasi dengan komuniti untuk membolehkan pemeriksaan ini pada replika.
Kami menulis kod yang harus mengikut semua boleh... protokol. Kami membincangkan patch ini untuk beberapa lama dengan Peter Gaghan dari Crunchy Data. Dia terpaksa mengubah suai sedikit B-tree yang sedia ada dalam Postgres untuk menerima patch ini. Dia diterima. Dan kini menyemak indeks pada replika juga telah menjadi cukup berkesan untuk mengesan pelanggaran yang kami temui. Iaitu, ini adalah pelanggaran yang boleh disebabkan oleh ralat dalam perisian tegar cakera, pepijat dalam Postgres, pepijat dalam kernel Linux dan masalah perkakasan. Agak banyak senarai sumber masalah yang kami sediakan.
Tetapi selain indeks, terdapat bahagian seperti timbunan, iaitu tempat di mana data disimpan. Dan tidak banyak invarian yang boleh disemak.
Kami mempunyai sambungan yang dipanggil Heapcheck. Kami mula membangunkannya. Dan selari, bersama-sama dengan kami, syarikat EnterpriseDB juga mula menulis modul, yang mereka panggil Heapcheck dengan cara yang sama. Hanya kami yang memanggilnya PgHeapcheck, dan mereka hanya memanggilnya Heapcheck. Mereka memilikinya dengan fungsi yang sama, tandatangan yang sedikit berbeza, tetapi dengan idea yang sama. Mereka melaksanakannya dengan lebih baik sedikit di beberapa tempat. Dan mereka menyiarkannya dalam sumber terbuka sebelum ini.
Dan sekarang kami sedang membangunkan pengembangan mereka, kerana ia bukan lagi pengembangan mereka, tetapi pengembangan masyarakat. Dan pada masa hadapan, ini adalah sebahagian daripada kernel yang akan dibekalkan kepada semua orang supaya mereka dapat mengetahui tentang masalah masa depan terlebih dahulu.
Di sesetengah tempat, kami juga membuat kesimpulan bahawa kami mempunyai positif palsu dalam sistem pemantauan kami. Sebagai contoh, sistem 1C. Apabila menggunakan pangkalan data, Postgres kadangkala menulis data ke dalamnya yang boleh dibaca, tetapi pg_dump tidak boleh membaca.
Keadaan ini kelihatan seperti rasuah kepada sistem pengesanan masalah kami. Pegawai bertugas dikejutkan. Pegawai bertugas melihat apa yang berlaku. Selepas beberapa lama, seorang pelanggan datang dan mengatakan bahawa saya mempunyai masalah. Petugas menjelaskan apa masalahnya. Tetapi masalahnya adalah dalam teras Postgres.
Saya menemui perbincangan tentang ciri ini. Dan dia menulis bahawa kami menemui ciri ini dan ia tidak menyenangkan, seseorang bangun pada waktu malam untuk mengetahui apa itu.
Komuniti menjawab, "Oh, kami benar-benar perlu membetulkannya."
Saya mempunyai analogi yang mudah. Jika anda berjalan dalam kasut yang mempunyai butiran pasir di dalamnya, maka, pada dasarnya, anda boleh meneruskan - tidak ada masalah. Jika anda menjual but kepada beribu-ribu orang, maka mari buat but tanpa pasir sama sekali. Dan jika salah seorang pengguna kasut anda akan berlari maraton, maka anda ingin membuat kasut yang sangat bagus, dan kemudian skalakannya kepada semua pengguna anda. Dan pengguna yang tidak dijangka itu sentiasa berada dalam persekitaran awan. Sentiasa ada pengguna yang mengeksploitasi kluster dalam beberapa cara asal. Anda mesti sentiasa bersedia untuk ini.
Apa yang telah kita pelajari di sini? Kami belajar perkara mudah: perkara yang paling penting ialah menjelaskan kepada masyarakat bahawa terdapat masalah. Sekiranya masyarakat telah mengenali masalah tersebut, maka timbul persaingan semula jadi untuk menyelesaikan masalah tersebut. Kerana semua orang mahu menyelesaikan masalah penting. Semua vendor, semua penggodam faham bahawa mereka sendiri boleh memijak rake ini, jadi mereka mahu menghapuskannya.
Jika anda sedang mengusahakan masalah, tetapi ia tidak menyusahkan sesiapa selain anda, tetapi anda menyelesaikannya secara sistematik dan ia akhirnya dianggap sebagai masalah, maka permintaan tarik anda pasti akan diterima. Tampalan anda akan diterima, penambahbaikan anda atau permintaan untuk penambahbaikan akan disemak oleh komuniti. Pada penghujung hari, kami menjadikan pangkalan data lebih baik untuk satu sama lain.
Pangkalan data yang menarik ialah Greenplum. Ia adalah pangkalan data yang sangat selari berdasarkan pangkalan kod Postgres, yang sangat saya kenali.
Dan Greenplum mempunyai fungsi yang menarik - tambahkan jadual yang dioptimumkan. Ini adalah jadual yang boleh anda tambahkan dengan cepat. Mereka boleh sama ada kolumnar atau baris.
Tetapi tidak ada pengelompokan, iaitu tiada fungsi di mana anda boleh menyusun data yang terletak dalam jadual mengikut susunan yang ada dalam salah satu indeks.
Lelaki dari teksi datang kepada saya dan berkata: βAndrey, anda tahu Postgres. Dan di sini ia hampir sama. Tukar kepada 20 minit. Awak ambil dan lakukannya.β Saya fikir ya, saya tahu Postgres, bertukar selama 20 minit - saya perlu melakukan ini.
Tetapi tidak, ia bukan 20 minit, saya menulisnya selama berbulan-bulan. Pada persidangan PgConf.Russia, saya mendekati Heikki Linakangas dari Pivotal dan bertanya: βAdakah terdapat sebarang masalah dengan ini? Mengapa tiada pengelompokan jadual yang dioptimumkan tambah?" Dia berkata: "Anda mengambil data. Anda menyusun, anda menyusun semula. Ia hanya satu kerja." Saya: "Oh, ya, anda hanya perlu mengambilnya dan melakukannya." Dia berkata: "Ya, kami memerlukan tangan bebas untuk melakukan ini." Saya fikir saya pasti perlu melakukan ini.
Dan beberapa bulan kemudian saya menyerahkan permintaan tarik yang melaksanakan fungsi ini. Permintaan tarik ini telah disemak oleh Pivotal bersama komuniti. Sudah tentu, terdapat pepijat.
Tetapi perkara yang paling menarik ialah apabila permintaan tarik ini digabungkan, pepijat ditemui dalam Greenplum sendiri. Kami telah mendapati bahawa jadual timbunan kadangkala memecahkan transaksi apabila dikelompokkan. Dan ini adalah perkara yang perlu diperbaiki. Dan dia berada di tempat yang baru saya sentuh. Dan tindak balas semula jadi saya ialah β okey, biar saya buat ini juga.
Saya membetulkan pepijat ini. Menghantar permintaan tarik kepada penetap. Dia telah dibunuh.
Selepas itu ternyata fungsi ini perlu diperolehi dalam versi Greenplum untuk PostgreSQL 12. Iaitu, pengembaraan selama 20 minit diteruskan dengan pengembaraan baru yang menarik. Adalah menarik untuk menyentuh perkembangan semasa, di mana komuniti memotong ciri baharu dan paling penting. Ia beku.
Tetapi ia tidak berakhir di sana. Selepas segala-galanya, ternyata kami perlu menulis dokumentasi untuk semua ini.
Saya mula menulis dokumentasi. Nasib baik, dokumentari dari Pivotal datang. Bahasa Inggeris adalah bahasa ibunda mereka. Mereka membantu saya dengan dokumentasi. Malah, mereka sendiri menulis semula apa yang saya cadangkan ke dalam bahasa Inggeris sebenar.
Dan di sini, nampaknya, pengembaraan itu berakhir. Dan adakah anda tahu apa yang berlaku ketika itu? Lelaki dari teksi datang kepada saya dan berkata: "Masih ada dua pengembaraan, setiap satu selama 10 minit." Dan apa yang perlu saya beritahu mereka? Saya berkata bahawa sekarang saya akan memberikan laporan secara berskala, kemudian kita akan melihat pengembaraan anda, kerana ini adalah kerja yang menarik.
Apa yang kita pelajari daripada kes ini? Kerana bekerja dengan sumber terbuka sentiasa bekerja dengan orang tertentu, ia sentiasa bekerja dengan komuniti. Kerana pada setiap peringkat saya bekerja dengan beberapa pembangun, beberapa penguji, beberapa penggodam, beberapa dokumentari, beberapa arkitek. Saya tidak bekerja dengan Greenplum, saya bekerja dengan orang di sekitar Greenplum.
Tetapi! Terdapat satu lagi perkara penting - ia hanya kerja. Iaitu, anda datang, minum kopi, tulis kod. Semua jenis invarian mudah berfungsi. Lakukan seperti biasa - ia akan baik-baik saja! Dan ia adalah kerja yang agak menarik. Terdapat permintaan untuk kerja ini daripada pelanggan Yandex.Cloud, pengguna kluster kami di dalam Yandex dan di luar. Dan saya berpendapat bahawa bilangan projek yang kita sertai akan meningkat dan kedalaman penglibatan kita juga akan meningkat.
Itu sahaja. Mari kita beralih kepada soalan.
Sesi soal jawab
hello! Kita ada lagi sesi soal jawab. Dan di studio Andrei Borodin. Ini ialah orang yang baru sahaja memberitahu anda tentang sumbangan Yandex.Cloud dan Yandex kepada sumber terbuka. Laporan kami sekarang bukan sepenuhnya mengenai Awan, tetapi pada masa yang sama kami berdasarkan teknologi sedemikian. Tanpa apa yang anda lakukan di dalam Yandex, tidak akan ada perkhidmatan dalam Yandex.Cloud, jadi terima kasih daripada saya secara peribadi. Dan soalan pertama dari siaran itu: "Apakah setiap projek yang anda sebutkan ditulis?"
Sistem sandaran dalam WAL-G ditulis dalam Go. Ini adalah salah satu projek baharu yang telah kami usahakan. Dia betul-betul baru 3 tahun. Dan pangkalan data selalunya mengenai kebolehpercayaan. Dan ini bermakna bahawa pangkalan data agak lama dan ia biasanya ditulis dalam C. Projek Postgres bermula kira-kira 30 tahun yang lalu. Kemudian C89 adalah pilihan yang tepat. Dan Postgres tertulis di atasnya. Pangkalan data yang lebih moden seperti ClickHouse biasanya ditulis dalam C++. Semua pembangunan sistem berasaskan C dan C++.
Soalan daripada pengurus kewangan kami, yang bertanggungjawab untuk perbelanjaan di Cloud: "Mengapa Cloud membelanjakan wang untuk menyokong sumber terbuka?"
Terdapat jawapan mudah untuk pengurus kewangan di sini. Kami melakukan ini untuk menjadikan perkhidmatan kami lebih baik. Dalam cara apakah kita boleh melakukan yang lebih baik? Kita boleh melakukan sesuatu dengan lebih cekap, lebih pantas dan menjadikan perkara lebih berskala. Tetapi bagi kami, cerita ini terutamanya mengenai kebolehpercayaan. Sebagai contoh, dalam sistem sandaran kami menyemak 100% tampalan yang digunakan padanya. Kami tahu apa kod itu. Dan kami lebih selesa melancarkan versi baharu kepada pengeluaran. Iaitu, pertama sekali, ia adalah mengenai keyakinan, tentang kesediaan untuk pembangunan dan tentang kebolehpercayaan
Soalan lain: "Adakah keperluan pengguna luaran yang tinggal di Yandex.Cloud berbeza daripada pengguna dalaman yang tinggal dalam Cloud dalaman?"
Profil beban, sudah tentu, berbeza. Tetapi dari sudut pandangan jabatan saya, semua kes istimewa dan menarik dicipta pada beban yang tidak standard. Pembangun dengan imaginasi, pembangun yang melakukan perkara yang tidak dijangka, berkemungkinan besar ditemui secara dalaman dan luaran. Dalam hal ini, kita semua lebih kurang sama. Dan, mungkin, satu-satunya ciri penting dalam operasi pangkalan data Yandex ialah di dalam Yandex kami mempunyai pengajaran. Pada satu ketika, beberapa zon ketersediaan sepenuhnya menjadi bayang-bayang, dan semua perkhidmatan Yandex entah bagaimana mesti terus berfungsi walaupun ini. Ini adalah perbezaan kecil. Tetapi ia mencipta banyak pembangunan penyelidikan pada antara muka pangkalan data dan timbunan rangkaian. Jika tidak, pemasangan luaran dan dalaman menjana permintaan yang sama untuk ciri dan permintaan serupa untuk meningkatkan kebolehpercayaan dan prestasi.
Soalan seterusnya: "Apakah perasaan anda secara peribadi tentang fakta bahawa kebanyakan perkara yang anda lakukan digunakan oleh Awan lain?" Kami tidak akan menamakan yang khusus, tetapi banyak projek yang telah dilakukan dalam Yandex.Cloud digunakan dalam awan orang lain.
Ini hebat. Pertama, ia adalah tanda bahawa kita telah melakukan sesuatu yang betul. Dan ia mencalarkan ego. Dan kami lebih yakin bahawa kami membuat keputusan yang betul. Sebaliknya, ini adalah harapan bahawa pada masa hadapan ini akan membawa kita idea baharu, permintaan baharu daripada pengguna pihak ketiga. Kebanyakan isu pada GitHub dicipta oleh pentadbir sistem individu, DBA individu, arkitek individu, jurutera individu, tetapi kadangkala orang yang mempunyai pengalaman sistematik datang dan mengatakan bahawa dalam 30% kes tertentu kita menghadapi masalah ini dan mari kita fikirkan cara menyelesaikannya. Inilah yang paling kami nantikan. Kami berharap dapat berkongsi pengalaman dengan platform awan yang lain.
Anda banyak bercakap tentang maraton. Saya tahu awak berlari maraton di Moscow. Akibatnya? Mengatasi lelaki dari PostgreSQL?
Tidak, Oleg Bartunov berlari dengan sangat pantas. Dia selesai sejam lebih awal daripada saya. Secara keseluruhan, saya gembira dengan sejauh mana saya berjaya. Bagi saya, hanya menamatkan adalah satu pencapaian. Secara keseluruhannya, amat mengejutkan bahawa terdapat begitu ramai pelari dalam komuniti postgres. Nampaknya saya ada beberapa jenis hubungan antara sukan aerobik dan keinginan untuk pengaturcaraan sistem.
Adakah anda mengatakan tiada pelari di ClickHouse?
Saya tahu pasti bahawa mereka ada di sana. ClickHouse juga merupakan pangkalan data. Ngomong-ngomong, Oleg kini menulis kepada saya: "Bolehkah kita lari selepas laporan itu?" Ini adalah idea yang bagus.
Soalan lain dari siaran dari Nikita: "Mengapa anda membetulkan pepijat di Greenplum sendiri dan tidak memberikannya kepada junior?" Benar, ia tidak begitu jelas apa pepijat itu dan dalam perkhidmatan yang mana, tetapi ia mungkin bermaksud yang anda bincangkan.
Ya, pada dasarnya, ia boleh diberikan kepada seseorang. Ia hanya kod yang baru saya ubah. Dan adalah wajar untuk terus melakukannya dengan segera. Pada dasarnya, idea untuk berkongsi kepakaran dengan pasukan adalah idea yang baik. Kami pasti akan berkongsi tugas Greenplum di kalangan semua ahli bahagian kami.
Oleh kerana kita bercakap tentang junior, inilah soalan. Orang itu memutuskan untuk membuat komitmen pertama dalam Postgres. Apakah yang perlu dia lakukan untuk membuat komitmen pertama?
Ini adalah soalan yang menarik: "Di mana untuk bermula?" Ia biasanya agak sukar untuk memulakan dengan sesuatu dalam kernel. Dalam Postgres, sebagai contoh, terdapat senarai tugasan. Tetapi sebenarnya, ini adalah lembaran apa yang mereka cuba lakukan, tetapi tidak berjaya. Ini adalah perkara yang rumit. Dan biasanya anda boleh menemui beberapa utiliti dalam ekosistem, beberapa sambungan yang boleh diperbaiki, yang kurang menarik perhatian daripada pembangun kernel. Dan, oleh itu, terdapat lebih banyak mata untuk pertumbuhan di sana. Pada program kod Musim Panas Google, setiap tahun komuniti postgres mengemukakan banyak topik berbeza yang boleh ditangani. Tahun ini, saya rasa, kami mempunyai tiga pelajar. Malah ada yang menulis dalam WAL-G mengenai topik yang penting kepada Yandex. Di Greenplum, segala-galanya adalah lebih mudah daripada dalam komuniti Postgres, kerana penggodam Greenplum melayan permintaan tarik dengan baik dan mula menyemak dengan segera. Menghantar tampalan kepada Postgres mengambil masa beberapa bulan, tetapi Greenplum akan datang dalam sehari dan melihat apa yang telah anda lakukan. Perkara lain ialah Greenplum perlu menyelesaikan masalah semasa. Greenplum tidak digunakan secara meluas, jadi mencari masalah anda agak sukar. Dan pertama sekali, kita perlu menyelesaikan masalah, sudah tentu.
Sumber: www.habr.com