Yandex-in aşağıdakı verilənlər bazalarına verdiyi töhfə nəzərdən keçiriləcək.
- Basın Evi
- Odyssey
- Bir zamana qədər bərpa (WAL-G)
- PostgreSQL (logerrors, Amcheck, heapcheck daxil olmaqla)
- Yaşıl gavalı
Video:
Salam dünya! Mənim adım Andrey Borodindir. Yandex.Cloud-da mənim gördüyüm iş Yandex.Cloud və Yandex.Cloud müştərilərinin maraqlarına uyğun olaraq açıq relational verilənlər bazası hazırlamaqdır.
Bu söhbətdə biz miqyasda açıq verilənlər bazalarının üzləşdiyi problemlər haqqında danışacağıq. Niyə vacibdir? Çünki ağcaqanadlar kimi sonradan fillərə çevrilən kiçik, kiçik problemlər. Çoxlu klasteriniz olduqda onlar böyüyürlər.
Amma əsas olan bu deyil. İnanılmaz şeylər baş verir. Milyonda bir halda baş verən hadisələr. Bulud mühitində isə buna hazır olmalısınız, çünki miqyasda bir şey mövcud olduqda inanılmaz şeylər ehtimalı yüksək olur.
Amma! Açıq verilənlər bazalarının üstünlüyü nədir? Fakt budur ki, istənilən problemin öhdəsindən gəlmək üçün nəzəri imkanınız var. Mənbə kodunuz var, proqramlaşdırma biliyiniz var. Birləşdiririk və işləyir.
Açıq mənbə proqram təminatı üzərində işləmək üçün hansı yanaşmalar var?
- Ən sadə yanaşma proqram təminatından istifadə etməkdir. Əgər siz protokollardan istifadə edirsinizsə, standartlardan istifadə edirsinizsə, formatlardan istifadə edirsinizsə, açıq mənbə proqramında sorğular yazırsınızsa, deməli, artıq onu dəstəkləyirsiniz.
- Siz onun ekosistemini böyüdürsünüz. Bir səhvin erkən aşkarlanması ehtimalını artırırsınız. Siz bu sistemin etibarlılığını artırırsınız. Siz bazarda tərtibatçıların əlçatanlığını artırırsınız. Siz bu proqramı təkmilləşdirin. Əgər yenicə stil əldə etdinizsə və orada bir şeylə məşğul oldunuzsa, siz artıq töhfə verənsiniz.
- Başqa bir başa düşülən yanaşma açıq mənbəli proqram təminatına sponsorluq etməkdir. Məsələn, tanınmış Google Summer of Code proqramı, Google dünyanın hər yerindən çoxlu sayda tələbələrə müəyyən lisenziya tələblərinə cavab verən açıq proqram layihələri hazırlamaq üçün başa düşülən pul ödədikdə.
- Bu, çox maraqlı bir yanaşmadır, çünki o, diqqəti icmadan uzaqlaşdırmadan proqram təminatının təkamülə keçməsinə imkan verir. Google, bir texnologiya nəhəngi olaraq, bu xüsusiyyəti istədiyimizi demir, biz bu səhvi düzəltmək istəyirik və qazmamız lazım olan yer budur. Google deyir: “Etdiyiniz işi edin. Sadəcə işlədiyiniz şəkildə işləməyə davam edin və hər şey yaxşı olacaq."
- Açıq mənbədə iştirak etmək üçün növbəti yanaşma iştirakdır. Açıq mənbəli proqram təminatında probleminiz olduqda və tərtibatçılar olduqda, tərtibatçılarınız problemləri həll etməyə başlayır. Onlar infrastrukturunuzu daha səmərəli, proqramlarınızı daha sürətli və etibarlı etməyə başlayırlar.
Açıq mənbə proqram təminatı sahəsində ən məşhur Yandex layihələrindən biri ClickHouse-dur. Bu, Yandex.Metrica-nın üzləşdiyi problemlərə cavab olaraq yaranan məlumat bazasıdır.
Və verilənlər bazası olaraq, ekosistem yaratmaq və onu digər tərtibatçılarla birlikdə inkişaf etdirmək üçün açıq mənbədə hazırlanmışdır (yalnız Yandex daxilində deyil). İndi bu, çoxlu müxtəlif şirkətlərin iştirak etdiyi böyük bir layihədir.
Yandex.Cloud-da biz Yandex Obyekt Yaddaşının üstündə, yəni bulud yaddaşının üstündə ClickHouse yaratdıq.
Bu buludda niyə vacibdir? Çünki istənilən verilənlər bazası bu üçbucaqda, bu piramidada, yaddaş tiplərinin bu iyerarxiyasında işləyir. Sizdə sürətli, lakin kiçik registrlər və ucuz böyük, lakin yavaş SSD-lər, sərt disklər və bəzi digər blok cihazları var. Əgər siz piramidanın zirvəsində səmərəlisinizsə, o zaman sürətli məlumat bazanız var. bu piramidanın dibində səmərəlisinizsə, o zaman miqyaslı məlumat bazanız var. Və bu baxımdan, aşağıdan başqa bir təbəqənin əlavə edilməsi verilənlər bazasının miqyasını artırmaq üçün məntiqi bir yanaşmadır.
Bunu necə etmək olardı? Bu hesabatda mühüm məqamdır.
- MDS üzərindən ClickHouse tətbiq edə bilərik. MDS daxili Yandex bulud saxlama interfeysidir. Ümumi S3 protokolundan daha mürəkkəbdir, lakin blok cihazı üçün daha uyğundur. Məlumatları qeyd etmək daha yaxşıdır. Daha çox proqramlaşdırma tələb edir. Proqramçılar proqramlaşdıracaq, hətta yaxşıdır, maraqlıdır.
- S3, müəyyən növ iş yüklərinə daha az uyğunlaşma hesabına interfeysi sadələşdirən daha çox yayılmış bir yanaşmadır.
Təbii ki, bütün ClickHouse ekosisteminə funksionallıq təmin etmək və Yandex.Cloud daxilində lazım olan işi yerinə yetirmək istəyən biz bütün ClickHouse icmasının bundan faydalanacağına əmin olmaq qərarına gəldik. Biz ClickHouse-u MDS üzərində yox, S3 üzərindən ClickHouse tətbiq etdik. Və bu çox işdir.
Referanslar:
"Fayl sistemi abstraksiya təbəqəsi"
"AWS SDK S3 inteqrasiyası"
“S3 üçün IDisk interfeysinin əsas tətbiqi”
"Log saxlama mühərriklərinin IDisk interfeysi ilə inteqrasiyası"
"S3 və SeekableReadBuffer üçün mühərrik dəstəyini qeyd edin"
"Storage Stripe Log S3 dəstəyi"
"S3 üçün Storage MergeTree ilkin dəstəyi"
"MergeTree S3 üçün tam dəstək"
"S3 üzərində ReplicatedMergeTree dəstəyi"
“S3 yaddaşı üçün defolt etimadnamələr və fərdi başlıqlar əlavə edin”
"Dinamik proxy konfiqurasiyası ilə S3"
"Proxy həlledici ilə S3"
Bu, ClickHouse-da virtual fayl sisteminin tətbiqi üçün çəkilmiş sorğu siyahısıdır. Bu, çoxlu sayda çəkmə sorğusudur.
Referanslar:
"DiskS3 sabit bağlantıları optimal həyata keçirir"
"S3 HTTP müştərisi - Cavab axınını yaddaşa köçürməyin"
“Bütün cavab axınını S3 HTTP-də yaddaşa köçürməkdən çəkinin
müştəri"
“S3 diski üçün qeyd və indeks fayllarını keş etmək imkanı”
"Paralel olaraq hissələri DiskLocal-dan DiskS3-ə köçürün"
Amma iş bununla bitmədi. Funksiya hazırlandıqdan sonra bu funksionallığı optimallaşdırmaq üçün bir az daha iş tələb olundu.
Referanslar:
"SelectedRows və SelectedBytes hadisələrini əlavə et"
"S3 sorğusundan system.events-ə profil hadisələri əlavə edin"
"QueryTimeMicroseconds, SelectQueryTimeMicroseconds və InsertQueryTimeMicroseconds əlavə edin"
Və sonra onu diaqnoz qoymaq, monitorinq qurmaq və idarə edilə bilən etmək lazım idi.
Və bütün bunlar ona görə edildi ki, bütün icma, bütün ClickHouse ekosistemi bu işin nəticəsini alsın.
Keçək tranzaksiya verilənlər bazalarına, şəxsən mənə daha yaxın olan OLTP verilənlər bazalarına.
Bu, açıq mənbəli DBMS inkişaf bölməsidir. Bu uşaqlar tranzaksiya xarakterli açıq verilənlər bazalarını təkmilləşdirmək üçün küçə sehrləri ilə məşğul olurlar.
Necə və nə etdiyimiz haqqında danışa biləcəyimiz layihələrdən biri də Postgres-də Connection Pooler-dir.
Postgres proses verilənlər bazasıdır. Bu o deməkdir ki, verilənlər bazasında əməliyyatları idarə edən mümkün qədər az şəbəkə bağlantısı olmalıdır.
Digər tərəfdən, bulud mühitində tipik bir vəziyyət, bir anda bir çoxluğa min əlaqənin gəlməsidir. Bağlantı toplayıcısının vəzifəsi min əlaqəni az sayda server bağlantısına yığmaqdır.
Deyə bilərik ki, əlaqə hovuzu baytları verilənlər bazasına səmərəli şəkildə çatdırmaq üçün yenidən təşkil edən telefon operatorudur.
Təəssüf ki, əlaqə hovuzu üçün yaxşı rus sözü yoxdur. Bəzən buna multipleksor əlaqələri deyilir. Bağlantı hovuzunu nə adlandıracağınızı bilirsinizsə, o zaman mənə deyin ki, mən düzgün rus texniki dilində danışmaqdan çox məmnunam.
Biz idarə olunan postgres klasteri üçün uyğun olan əlaqə hovuzlarını araşdırdıq. Və PgBouncer bizim üçün ən yaxşı seçim idi. Lakin PgBouncer ilə bir sıra problemlərlə qarşılaşdıq. Uzun illər əvvəl Volodya Borodin PgBouncer istifadə etdiyimiz barədə hesabat verdi, hər şeyi bəyənirik, amma nüanslar var, üzərində işləmək üçün bir şey var.
Və işlədik. Qarşılaşdığımız problemləri aradan qaldırdıq, Bouncer-i yamaqladıq və tələbləri yuxarıya doğru itələməyə çalışdıq. Lakin fundamental tək iplə işləmək çətin idi.
Yamaqlı Bouncerlərdən şəlalələr toplamalı olduq. Çoxlu tək yivli Bouncerlərimiz olduqda, üst təbəqədəki əlaqələr Bouncerlərin daxili təbəqəsinə köçürülür. Bu zəif idarə olunan sistemdir, onu qurmaq və miqyasını irəli-geri genişləndirmək çətindir.
Odyssey adlanan öz əlaqə hovuzumuzu yaratdığımız qənaətinə gəldik. Biz bunu sıfırdan yazdıq.
2019-cu ildə PgCon konfransında mən bu hovuzu tərtibatçı cəmiyyətinə təqdim etdim. İndi GitHub-da 2-dən bir az az ulduzumuz var, yəni layihə canlıdır, layihə məşhurdur.
Yandex.Cloud-da Postgres klasteri yaratsanız, bu, klasteri geri və ya irəli miqyaslandırarkən yenidən konfiqurasiya edilən daxili Odyssey ilə bir klaster olacaq.
Bu layihədən nə öyrəndik? Rəqabətli bir layihənin işə salınması həmişə aqressiv addımdır, kifayət qədər tez həll olunmayan, bizə uyğun gələn zaman intervallarında həll olunmayan problemlərin olduğunu desək, bu, həddindən artıq tədbirdir. Amma bu effektiv tədbirdir.
PgBouncer daha sürətli inkişaf etməyə başladı.
İndi isə başqa layihələr ortaya çıxıb. Məsələn, Red Hat tərtibatçıları tərəfindən hazırlanmış pgagroal. Onlar oxşar məqsədlər güdürlər və oxşar ideyaları həyata keçirirlər, lakin təbii ki, pgagroal tərtibatçılarına daha yaxın olan öz xüsusiyyətləri ilə.
Postgres icması ilə işləməyin başqa bir halı bir zamana qədər bərpa olunur. Bu, uğursuzluqdan sonra bərpa, bu, ehtiyat nüsxədən bərpadır.
Bir çox ehtiyat nüsxəsi var və hamısı fərqlidir. Demək olar ki, hər bir Postgres satıcısının öz ehtiyat həlli var.
Əgər bütün ehtiyat sistemləri götürsəniz, xüsusiyyət matrisi yaradıb zarafatla bu matrisdəki determinantı hesablasanız, sıfır olacaq. Bu nə deməkdir? Müəyyən bir ehtiyat nüsxə faylı götürsəniz, o, bütün digərlərinin parçalarından yığıla bilməz. O, həyata keçirilməsində bənzərsizdir, məqsədinə görə bənzərsizdir, ona daxil olan ideyalara görə bənzərsizdir. Və onların hamısı spesifikdir.
Biz bu məsələ üzərində işləyərkən CitusData WAL-G layihəsini işə saldı. Bu, bulud mühitini nəzərə alaraq hazırlanmış ehtiyat sistemdir. İndi CitusData artıq Microsoft-un bir hissəsidir. Və o anda WAL-G-nin ilkin buraxılışlarında irəli sürülən fikirləri çox bəyəndik. Və biz bu layihəyə töhfə verməyə başladıq.
İndi bu layihədə onlarla tərtibatçı var, lakin WAL-G-nin ilk 10 iştirakçısına 6 Yandexoid daxildir. Bir çox ideyalarımızı ora gətirdik. Və əlbəttə ki, biz onları özümüz həyata keçirdik, özümüz sınaqdan keçirdik, özümüz istehsala çıxardıq, özümüz istifadə edirik, böyük WAL-G icması ilə qarşılıqlı əlaqədə olarkən növbəti yeri hara keçirəcəyimizi özümüz müəyyənləşdiririk.
Və bizim nöqteyi-nəzərimizdən, indi bu ehtiyat sistemi, o cümlədən səylərimizi nəzərə alaraq, bulud mühiti üçün optimal hala gəldi. Bu, buludda Postgres-in ehtiyat nüsxəsini çıxarmaq üçün ən yaxşı xərcdir.
Bunun mənası nədi? Biz kifayət qədər böyük ideyanı irəli sürürdük: ehtiyat nüsxə təhlükəsiz, işləmək üçün ucuz və bərpa etmək mümkün qədər tez olmalıdır.
Əməliyyat niyə ucuz olmalıdır? Heç bir şey pozulmadıqda, ehtiyat nüsxələriniz olduğunu bilməməlisiniz. Hər şey yaxşı işləyir, mümkün qədər az CPU sərf edirsiniz, disk resurslarınızdan mümkün qədər az istifadə edirsiniz və dəyərli xidmətlərinizin yüklənməsinə mane olmamaq üçün şəbəkəyə mümkün qədər az bayt göndərirsiniz.
Və hər şey pozulduqda, məsələn, admin məlumatları atdı, bir şey səhv oldu və siz təcili olaraq keçmişə qayıtmalısınız, bütün pulunuzla bərpa olunursunuz, çünki məlumatlarınızı tez və bütöv şəkildə geri qaytarmaq istəyirsiniz.
Və biz bu sadə ideyanı təbliğ etdik. Və bizə elə gəlir ki, biz bunu həyata keçirə bilmişik.
Ancaq bu, hamısı deyil. Daha kiçik bir şey istədik. Çox fərqli verilənlər bazası istədik. Müştərilərimizin heç də hamısı Postgres istifadə etmir. Bəzi insanlar MySQL, MongoDB istifadə edirlər. Cəmiyyətdə digər tərtibatçılar FoundationDB-ni dəstəklədilər. Və bu siyahı daim genişlənir.
İcma verilənlər bazasının buludda idarə olunan mühitdə işlədilməsi ideyasını bəyənir. Tərtibatçılar öz verilənlər bazalarını saxlayırlar ki, bu da bizim ehtiyat sistemimizlə Postgres ilə bərabər yedəklənə bilər.
Bu hekayədən nə öyrəndik? Bizim məhsulumuz bir inkişaf bölməsi olaraq kod sətirləri deyil, ifadələr deyil, fayllar deyil. Məhsulumuz çəkmə tələbləri deyil. Bizim cəmiyyətə çatdırdığımız ideyalar bunlardır. Bu, texnoloji təcrübə və texnologiyanın bulud mühitinə doğru hərəkətidir.
Postgres kimi verilənlər bazası var. Mən ən çox Postgres nüvəsini bəyənirəm. Mən cəmiyyətlə Postgres nüvəsini inkişaf etdirməyə çox vaxt sərf edirəm.
Ancaq burada qeyd etmək lazımdır ki, Yandex.Cloud idarə olunan verilənlər bazalarının daxili quraşdırılmasına malikdir. Və Yandex.Mail-də çoxdan başladı. İndi idarə olunan Postgres-ə səbəb olan təcrübə, poçt Postgres-ə keçmək istəyəndə toplandı.
Poçtun bulud tələblərinə çox oxşar tələbləri var. Məlumatınızın istənilən nöqtəsində gözlənilməz eksponensial artıma miqyas verə bilməyiniz lazımdır. Və poçt artıq yüzlərlə milyonlarla poçt qutusu ilə dolu idi, daim çoxlu sorğular göndərən çox sayda istifadəçi.
Və bu, Postgres-i inkişaf etdirən komanda üçün olduqca ciddi problem idi. O vaxtlar rastlaşdığımız hər hansı problemi cəmiyyətə bildirirdilər. Və bu problemlər bəzi yerlərdə hətta bəzi digər verilənlər bazaları üçün ödənişli dəstək səviyyəsində və hətta daha yaxşı şəkildə cəmiyyət tərəfindən düzəldildi və düzəldildi. Yəni PgSQL hakerinə məktub göndərib 40 dəqiqə ərzində cavab ala bilərsiniz. Bəzi verilənlər bazalarında pullu dəstək səhvinizdən daha çox prioritet şeylərin olduğunu düşünə bilər.
İndi Postgres-in daxili quraşdırılması bir neçə petabayt məlumatdır. Bunlar saniyədə milyonlarla sorğudur. Bunlar minlərlə klasterdir. Çox geniş miqyaslıdır.
Ancaq bir nüans var. O, dəbdəbəli şəbəkə disklərində deyil, kifayət qədər sadə aparatlarda yaşayır. Və maraqlı yeni şeylər üçün xüsusi olaraq sınaq mühiti var.
Və müəyyən bir anda test mühitində verilənlər bazası indekslərinin daxili invariantlarının pozulduğunu göstərən bir mesaj aldıq.
İnvariant hər zaman saxlamağı gözlədiyimiz bir növ münasibətdir.
Bizim üçün çox kritik bir vəziyyət. Bu, bəzi məlumatların itirildiyini göstərir. Və məlumat itkisi tamamilə fəlakətli bir şeydir.
İdarə olunan verilənlər bazalarında izlədiyimiz ümumi fikir ondan ibarətdir ki, hətta səy göstərsəniz də, məlumatları itirmək çətin olacaq. Onları qəsdən aradan qaldırsanız belə, uzun müddət onların yoxluğuna məhəl qoymamalısınız. Məlumat təhlükəsizliyi olduqca səylə əməl etdiyimiz bir dindir.
Və burada elə bir vəziyyət yaranır ki, bizim hazır olmaya biləcəyimiz bir vəziyyət ola bilər. Və bu vəziyyətə hazırlaşmağa başladıq.
Etdiyimiz ilk iş bu minlərlə klasterin loglarını basdırmaq oldu. Klasterlərdən hansının məlumat səhifəsi yeniləmələrini itirən problemli proqram təminatı olan disklərdə yerləşdiyini tapdıq. Bütün Postgres məlumat kodunu qeyd etdi. Biz daxili invariantların pozulmasını göstərən həmin mesajları məlumatların pozulmasını aşkar etmək üçün nəzərdə tutulmuş kodla qeyd etdik.
Bu yamaq praktiki olaraq ictimaiyyət tərəfindən çox müzakirə edilmədən qəbul edildi, çünki hər bir konkret halda pis bir şeyin baş verdiyi və jurnala bildirilməsi lazım olduğu aydın idi.
Bundan sonra, logları skan edən monitorinqimiz olduğu nöqtəsinə gəldik. Və şübhəli mesajlar gələndə növbətçini yuxudan oyadır, növbətçi onu təmir edir.
Amma! Qeydlərin skan edilməsi bir klasterdə ucuz əməliyyatdır və min klaster üçün fəlakətli dərəcədə baha başa gəlir.
adlı bir uzantı yazdıq . Bu, keçmiş səhvlər üzrə statistik məlumatları ucuz və tez seçə biləcəyiniz verilənlər bazasının görünüşünü yaradır. Növbətçini oyatmaq lazımdırsa, bu barədə gigabayt faylları skan etmədən, ancaq hash cədvəlindən bir neçə bayt çıxarmaqla öyrənəcəyik.
Bu genişləndirmə, məsələn, üçün depoda qəbul edilmişdir . İstifadə etmək istəyirsinizsə, özünüz quraşdıra bilərsiniz. Təbii ki, açıq mənbədir.
Ancaq bu, hamısı deyil. İndekslərdə invariant pozuntuları tapmaq üçün icma tərəfindən yaradılmış genişləndirmə Amcheck-dən istifadə etməyə başladıq.
Və biz onu miqyasda işlətsəniz, səhvlər olduğunu öyrəndik. Onları düzəltməyə başladıq. Düzəlişlərimiz qəbul edildi.
Bu genişləndirmənin GiST və GIT indekslərini təhlil edə bilməyəcəyini aşkar etdik. Biz onlara dəstək olduq. Amma bu dəstək hələ də cəmiyyət tərəfindən müzakirə olunur, çünki bu nisbətən yeni funksionallıqdır və orada çoxlu detallar var.
Həm də aşkar etdik ki, replikasiya lideri, master-da pozuntular üçün indeksləri yoxlayarkən hər şey yaxşı işləyir, lakin replikalarda, izləyicidə korrupsiya axtarışı o qədər də effektiv deyil. Bütün invariantlar yoxlanılmır. Və bir invariant bizi çox narahat edirdi. Biz replikaların yoxlanılmasını təmin etmək üçün icma ilə əlaqə saxlamağa bir il yarım sərf etdik.
Biz bütün can... protokollarına əməl etməli olan kod yazdıq. Bu yamağı Crunchy Data-dan Peter Gaghan ilə bir müddət müzakirə etdik. O, bu yamağı qəbul etmək üçün Postgres-də mövcud B-ağacını bir az dəyişdirməli oldu. Qəbul edildi. İndi replikalarda indekslərin yoxlanılması da qarşılaşdığımız pozuntuları aşkar etmək üçün kifayət qədər təsirli oldu. Yəni bunlar diskin proqram təminatındakı səhvlər, Postgres-dəki səhvlər, Linux nüvəsindəki səhvlər və hardware problemləri nəticəsində yarana biləcək pozuntulardır. Hazırladığımız problem mənbələrinin kifayət qədər geniş siyahısı.
Ancaq indekslərdən başqa, yığın kimi bir hissə var, yəni məlumatların saxlandığı yer. Və yoxlanıla bilən bir çox invariant yoxdur.
Heapcheck adlı bir uzantımız var. Biz onu inkişaf etdirməyə başladıq. Paralel olaraq, bizimlə birlikdə EnterpriseDB şirkəti də eyni şəkildə Heapcheck adlandırdıqları bir modul yazmağa başladı. Yalnız biz onu PgHeapcheck adlandırdıq, onlar isə sadəcə Heapcheck adlandırdılar. Onların oxşar funksiyaları, bir az fərqli imzası var, lakin eyni ideyaları var. Bəzi yerlərdə onları bir az daha yaxşı tətbiq etdilər. Və daha əvvəl açıq mənbədə yerləşdirdilər.
İndi biz onların genişlənməsini inkişaf etdiririk, çünki bu, artıq onların genişlənməsi deyil, cəmiyyətin genişlənməsidir. Gələcəkdə bu, hər kəsə gələcək problemlər haqqında əvvəlcədən bilə bilməsi üçün təmin ediləcək nüvənin bir hissəsidir.
Hətta bəzi yerlərdə belə qənaətə gəldik ki, monitorinq sistemlərimizdə yanlış pozitivlər var. Məsələn, 1C sistemi. Verilənlər bazasından istifadə edərkən Postgres bəzən ona oxuya biləcəyi məlumatları yazır, lakin pg_dump oxuya bilmir.
Bu vəziyyət bizim problem aşkarlama sistemində korrupsiya kimi görünürdü. Növbətçi yuxudan ayıldı. Növbətçi baş verənlərə baxdı. Bir müddətdən sonra müştəri gəlib dedi ki, problemim var. Xidmətçi problemin nə olduğunu izah etdi. Ancaq problem Postgres nüvəsindədir.
Bu xüsusiyyət haqqında müzakirə tapdım. Və yazdı ki, biz bu xüsusiyyətlə qarşılaşdıq və xoşagəlməz oldu, adam gecə yuxudan oyandı ki, nə olduğunu anlamaq üçün.
Camaat cavab verdi: "Oh, həqiqətən bunu düzəltmək lazımdır."
Sadə bir bənzətməm var. İçində bir qum dənəsi olan bir ayaqqabıda gəzirsinizsə, o zaman, prinsipcə, davam edə bilərsiniz - problem yoxdur. Minlərlə insana çəkmə satırsınızsa, gəlin, ümumiyyətlə, qumsuz çəkmələr tikək. Ayaqqabılarınızın istifadəçilərindən biri marafonda iştirak edəcəksə, siz çox yaxşı ayaqqabılar hazırlamaq və sonra onları bütün istifadəçilərinizə çatdırmaq istəyirsiniz. Və belə gözlənilməz istifadəçilər həmişə bulud mühitində olurlar. Həmişə çoxluqdan hansısa orijinal şəkildə istifadə edən istifadəçilər var. Buna hər zaman hazırlaşmalısınız.
Biz burada nə öyrəndik? Biz sadə bir şey öyrəndik: ən başlıcası problemin olduğunu cəmiyyətə izah etməkdir. Əgər cəmiyyət problemi dərk edibsə, problemi həll etmək üçün təbii rəqabət yaranır. Çünki hər kəs vacib bir problemi həll etmək istəyir. Bütün satıcılar, bütün hakerlər başa düşürlər ki, onlar özləri bu dırmığa basa bilərlər, ona görə də onları aradan qaldırmaq istəyirlər.
Əgər bir problem üzərində işləyirsinizsə, lakin bu, sizdən başqa heç kimi narahat etmirsə, lakin onun üzərində sistemli şəkildə işləyirsinizsə və nəticədə problem hesab olunursa, o zaman çəkmə sorğunuz mütləq qəbul olunacaq. Yamanız qəbul ediləcək, təkmilləşdirmələriniz və ya hətta təkmilləşdirmə sorğularınız icma tərəfindən nəzərdən keçiriləcək. Günün sonunda verilənlər bazasını bir-birimiz üçün daha yaxşı hala gətiririk.
Maraqlı verilənlər bazası Greenplum-dur. Bu, çox tanış olduğum Postgres kod bazasına əsaslanan çox paralel verilənlər bazasıdır.
Və Greenplum maraqlı funksionallığa malikdir - optimallaşdırılmış cədvəllər əlavə edin. Bunlar tez bir zamanda əlavə edə biləcəyiniz cədvəllərdir. Onlar sütunlu və ya sıra ola bilər.
Ancaq klasterləşmə yox idi, yəni cədvəldə yerləşən məlumatları indekslərdən birində olan sıraya uyğun olaraq təşkil edə biləcəyiniz heç bir funksionallıq yox idi.
Taksidəki uşaqlar yanıma gəlib dedilər: “Andrey, sən Postqresi tanıyırsan. Və burada demək olar ki, eynidir. 20 dəqiqəyə keçin. Sən götür və bunu et”. Fikirləşdim ki, bəli, mən Postgresi tanıyıram, 20 dəqiqəyə dəyişirəm - bunu etməliyəm.
Amma yox, 20 dəqiqə deyildi, aylarla yazdım. PgConf.Russia konfransında Pivotal-dan Heikki Linakanqasa yaxınlaşıb soruşdum: “Bununla bağlı hər hansı problem varmı? Niyə əlavə optimallaşdırılmış cədvəl qruplaşması yoxdur? O deyir: “Sən məlumatları götürürsən. Siz çeşidləyirsiniz, yenidən təşkil edirsiniz. Bu, sadəcə bir işdir”. Mən: "Oh, bəli, sadəcə götürüb bunu etməlisən." O deyir: “Bəli, bunu etmək üçün bizə əllər lazımdır”. Düşündüm ki, bunu mütləq etməliyəm.
Və bir neçə ay sonra mən bu funksiyanı həyata keçirən bir çəkmə sorğusu təqdim etdim. Bu cəlbetmə sorğusu Pivotal tərəfindən icma ilə birlikdə nəzərdən keçirilib. Təbii ki, səhvlər var idi.
Ancaq ən maraqlısı odur ki, bu çəkmə sorğusu birləşdirildikdə Greenplum-un özündə səhvlər tapıldı. Biz tapdıq ki, yığın cədvəlləri bəzən klasterləşdikdə əməliyyat qabiliyyətini pozur. Və bu düzəldilməli olan bir şeydir. Və o, indicə toxunduğum yerdədir. Və mənim təbii reaksiyam belə oldu - tamam, icazə verin bunu da edim.
Bu səhvi düzəltdim. Təmirçilərə çəkmə sorğusu göndərildi. O, öldürüldü.
Bundan sonra məlum oldu ki, bu funksionallığı PostgreSQL 12 üçün Greenplum versiyasında əldə etmək lazımdır. Yəni 20 dəqiqəlik macəra yeni maraqlı macəralarla davam edir. Cəmiyyətin yeni və ən vacib xüsusiyyətləri kəsdiyi cari inkişafa toxunmaq maraqlı idi. Donub.
Amma bununla da bitmədi. Hər şeydən sonra məlum oldu ki, bütün bunlar üçün sənədlər yazmaq lazım idi.
Sənədləri yazmağa başladım. Xoşbəxtlikdən, Pivotal-dan sənədli rəssamlar gəldi. İngilis dili onların ana dilidir. Sənədləşmədə mənə kömək etdilər. Əslində, onlar mənim təklif etdiklərimi əsl ingiliscə yenidən yazdılar.
Və burada, deyəsən, macəra bitdi. Və sonra nə baş verdiyini bilirsinizmi? Taksidəki uşaqlar yanıma gəlib dedilər: “Hələ iki macəra var, hər biri 10 dəqiqədir”. Və onlara nə deməliyəm? Dedim ki, indi miqyasda hesabat verəcəyəm, sonra macəralarınızı görəcəyik, çünki bu maraqlı işdir.
Bu vəziyyətdən nə öyrəndik? Açıq mənbə ilə işləmək həmişə konkret bir şəxslə işlədiyi üçün həmişə cəmiyyətlə işləyir. Çünki hər mərhələdə mən bəzi tərtibatçı, bəzi tester, bəzi haker, bəzi sənədli müəllif, bəzi memarla işləmişəm. Mən Greenplum ilə işləmədim, Greenplum ətrafındakı insanlarla işlədim.
Amma! Başqa bir vacib məqam var - bu, sadəcə işdir. Yəni gəl, kofe iç, kod yaz. Hər cür sadə invariantlar işləyir. Bunu normal edin - yaxşı olacaq! Və olduqca maraqlı bir işdir. Bu iş üçün Yandex.Cloud müştərilərindən, həm Yandex daxilində, həm də xaricində klasterlərimizin istifadəçilərindən müraciət var. Və düşünürəm ki, iştirak etdiyimiz layihələrin sayı artacaq və iştirakımızın dərinliyi də artacaq.
Hamısı budur. Gəlin suallara keçək.
Suallar sessiyası
Salam! Daha bir sual-cavab sessiyamız var. Və studiyada Andrey Borodin. Bu, Yandex.Cloud və Yandex-in açıq mənbəyə verdiyi töhfələrdən indicə sizə danışan şəxsdir. İndiki hesabatımız tamamilə Bulud haqqında deyil, eyni zamanda biz bu cür texnologiyalara əsaslanırıq. Yandex daxilində etdikləriniz olmasaydı, Yandex.Cloud-da heç bir xidmət olmayacaqdı, buna görə şəxsən məndən təşəkkür edirəm. Verilişdən ilk sual: “Adını çəkdiyiniz layihələrin hər biri hansı mövzuda yazılıb?”
WAL-G-də ehtiyat sistem Go-da yazılmışdır. Bu, üzərində işlədiyimiz yeni layihələrdən biridir. Onun sözün həqiqi mənasında cəmi 3 yaşı var. Və verilənlər bazası çox vaxt etibarlılıqla bağlıdır. Bu isə o deməkdir ki, verilənlər bazası kifayət qədər köhnədir və onlar adətən C dilində yazılır. Postgres layihəsi təxminən 30 il əvvəl başlayıb. Sonra C89 düzgün seçim idi. Və üzərində Postgres yazılıb. ClickHouse kimi daha müasir verilənlər bazaları adətən C++ dilində yazılır. Bütün sistem inkişafı C və C++ ətrafında qurulur.
Cloud-da xərclərə cavabdeh olan maliyyə menecerimizdən sual: "Niyə Cloud açıq mənbəni dəstəkləməyə pul xərcləyir?"
Burada maliyyə meneceri üçün sadə bir cavab var. Biz bunu xidmətlərimizi daha yaxşı etmək üçün edirik. Hansı yollarla daha yaxşısını edə bilərik? Biz işləri daha səmərəli, daha sürətli edə və daha geniş miqyaslı edə bilərik. Ancaq bizim üçün bu hekayə ilk növbədə etibarlılıqla bağlıdır. Məsələn, ehtiyat sistemdə ona aid olan yamaqların 100%-ni nəzərdən keçiririk. Kodun nə olduğunu bilirik. Və biz istehsala yeni versiyaları yaymaqda daha rahatıq. Yəni, ilk növbədə, inam, inkişafa hazır olmaq və etibarlılıq haqqındadır
Başqa bir sual: "Yandex.Cloud-da yaşayan xarici istifadəçilərin tələbləri daxili Buludda yaşayan daxili istifadəçilərdən fərqlidirmi?"
Yük profili, əlbəttə ki, fərqlidir. Amma mənim şöbəm baxımından bütün xüsusi və maraqlı hallar qeyri-standart yüklə yaradılır. Təxəyyülü olan tərtibatçılar, gözlənilməz işlər görən tərtibatçılar həm daxildə, həm də xaricdə tapıla bilər. Bu baxımdan hamımız təxminən eyniyik. Və yəqin ki, Yandex verilənlər bazası əməliyyatının yeganə vacib xüsusiyyəti, Yandex-in içərisində bir tədrisin olmasıdır. Bir nöqtədə, bəzi mövcudluq zonası tamamilə kölgəyə düşür və bütün Yandex xidmətləri buna baxmayaraq bir şəkildə işləməyə davam etməlidir. Bu kiçik bir fərqdir. Lakin o, verilənlər bazası və şəbəkə yığınının interfeysində çoxlu tədqiqat işlərinin yaradılmasını yaradır. Əks halda, xarici və daxili quraşdırmalar etibarlılıq və performansı artırmaq üçün xüsusiyyətlər və oxşar sorğular üçün eyni sorğular yaradır.
Növbəti sual: "Sizin gördüyünüz işlərin çoxunun digər Buludlar tərəfindən istifadə edilməsinə şəxsən münasibətiniz necədir?" Konkret olanların adını çəkməyəcəyik, lakin Yandex.Cloud-da həyata keçirilən bir çox layihələr digər insanların buludlarında istifadə olunur.
Bu əladır. Birincisi, bu, nəyisə düzgün etdiyimizə işarədir. Və eqoyu cızırır. Və biz düzgün qərar verdiyimizə daha çox əminik. Digər tərəfdən, bu, gələcəkdə bunun bizə yeni ideyalar, üçüncü tərəf istifadəçilərinin yeni istəkləri gətirəcəyinə ümiddir. GitHub-da əksər məsələlər ayrı-ayrı sistem administratorları, fərdi DBA-lar, fərdi memarlar, fərdi mühəndislər tərəfindən yaradılır, lakin bəzən sistemli təcrübəsi olan insanlar gəlib deyirlər ki, müəyyən halların 30%-də bizdə bu problem var və gəlin bunu necə həll edəcəyimizi düşünək. Ən çox gözlədiyimiz budur. Digər bulud platformaları ilə təcrübə mübadiləsini səbirsizliklə gözləyirik.
Siz marafon haqqında çox danışdınız. Bilirəm ki, siz Moskvada marafonda qaçmısınız. Nəticə olaraq? PostgreSQL-dən olanları ötdü?
Xeyr, Oleq Bartunov çox sürətlə qaçır. Məndən bir saat qabaq bitirdi. Ümumiyyətlə, nə qədər irəli getdiyimdən məmnunam. Mənim üçün sadəcə bitirmək uğur idi. Ümumiyyətlə, postgres cəmiyyətində çoxlu qaçışçıların olması təəccüblüdür. Mənə elə gəlir ki, aerob idmanı ilə sistem proqramlaşdırması istəyi arasında bir növ əlaqə var.
ClickHouse-da qaçışçı olmadığını deyirsiniz?
Onların orada olduğunu dəqiq bilirəm. ClickHouse həm də verilənlər bazasıdır. Yeri gəlmişkən, Oleq indi mənə yazır: "Hesabatdan sonra qaçaq?" Bu əla fikirdir.
Nikitadan yayımlanan başqa bir sual: "Niyə Greenplum-dakı səhvi özünüz düzəltdiniz və yeniyetmələrə vermədiniz?" Düzdür, səhvin nə olduğu və hansı xidmətdə olduğu çox aydın deyil, amma bu, yəqin ki, haqqında danışdığınız deməkdir.
Bəli, prinsipcə, kiməsə verilə bilərdi. Sadəcə dəyişdirdiyim kod idi. Və bunu dərhal davam etdirmək təbii idi. Prinsipcə, komanda ilə təcrübə mübadiləsi ideyası yaxşı fikirdir. Greenplum tapşırıqlarını bölməmizin bütün üzvləri arasında mütləq bölüşəcəyik.
Yeniyetmələrdən danışdığımız üçün burada bir sual var. Bu şəxs Postgres-də ilk öhdəliyi yaratmağa qərar verdi. O, ilk öhdəliyi etmək üçün nə etməlidir?
Bu maraqlı sualdır: “Haradan başlamaq lazımdır?” Nüvədəki bir şeylə başlamaq adətən olduqca çətindir. Postgres-də, məsələn, görüləcək işlər siyahısı var. Amma əslində bu, onların etməyə çalışdıqları, lakin bacara bilmədiklərinin bir vərəqidir. Bunlar mürəkkəb şeylərdir. Və adətən siz ekosistemdə bəzi kommunal proqramları, təkmilləşdirilə bilən bəzi uzantıları tapa bilərsiniz ki, onlar nüvə tərtibatçılarının daha az diqqətini cəlb edir. Və müvafiq olaraq, orada böyümə üçün daha çox nöqtə var. Google Summer of code proqramında hər il postgres icması həll oluna biləcək çoxlu müxtəlif mövzular irəli sürür. Bu il, məncə, üç tələbəmiz oldu. Biri hətta WAL-G-də Yandex üçün vacib olan mövzularda yazdı. Greenplum-da hər şey Postgres cəmiyyətindən daha sadədir, çünki Greenplum hakerləri pull sorğularına çox yaxşı yanaşır və dərhal nəzərdən keçirməyə başlayır. Postgres-ə yamaq göndərmək aylar məsələsidir, lakin Greenplum bir gündə gələcək və nə etdiyinizi görəcək. Başqa bir şey budur ki, Greenplum cari problemləri həll etməlidir. Greenplum geniş istifadə edilmir, ona görə də probleminizi tapmaq olduqca çətindir. Və ilk növbədə, əlbəttə ki, problemləri həll etməliyik.
Mənbə: www.habr.com