DBA botu Joe. Anatoli Stansler (Postgres.ai)

SQL sorğusunun “məhsul” üzərində yaxşı işləyəcəyini arxa plan tərtibçisi necə başa düşür? Böyük və ya sürətlə inkişaf edən şirkətlərdə hər kəsin “məhsul”a çıxışı yoxdur. Giriş ilə bütün sorğular ağrısız şəkildə yoxlanıla bilməz və verilənlər bazasının surətini yaratmaq çox vaxt saatlar çəkir. Bu problemləri həll etmək üçün biz süni DBA yaratdıq - Joe. O, artıq bir neçə şirkətdə uğurla həyata keçirilib və ondan çox tərtibatçıya kömək edir.

Video:

Hamıya salam! Mənim adım Anatoli Stanslerdir. Mən bir şirkətdə işləyirəm postgres.ai. Biz tərtibatçılardan, DBA-lardan və QA-lardan Postgres-in işi ilə bağlı gecikmələri aradan qaldırmaqla inkişaf prosesini sürətləndirməyə sadiqik.

Bizim böyük müştərilərimiz var və bu gün hesabatın bir hissəsi onlarla işləyərkən qarşılaşdığımız işlərə həsr olunacaq. Onlara kifayət qədər ciddi problemlərin həllində necə kömək etdiyimizdən danışacağam.

Mürəkkəb yüksək yüklü miqrasiyaları inkişaf etdirərkən və həyata keçirərkən özümüzə sual veririk: “Bu miqrasiya baş verəcəkmi?”. Biz baxışdan istifadə edirik, daha təcrübəli həmkarların, DBA ekspertlərinin biliklərindən istifadə edirik. Və onun uçub-uçamayacağını deyə bilirlər.

Amma bəlkə də tam ölçülü nüsxələrdə özümüz sınaqdan keçirsək daha yaxşı olar. Və bu gün biz yalnız indi testə hansı yanaşmaların olduğunu və bunu necə daha yaxşı və hansı vasitələrlə etmək barədə danışacağıq. Bu cür yanaşmaların müsbət və mənfi cəhətləri və burada nəyi düzəldə biləcəyimiz haqqında da danışacağıq.

Kim indiyə qədər birbaşa məhsulda indekslər yaradıb və ya hər hansı dəyişiklik edib? Bir az. Və bu kimin üçün məlumatların itirilməsinə və ya fasilələrin olmasına səbəb oldu? Onda bu ağrını bilirsən. Allaha şükür ehtiyat nüsxələri var.

Birinci yanaşma məhsulda sınaqdır. Və ya bir tərtibatçı yerli maşında oturduqda, onun test məlumatları var, bir növ məhdud seçim var. Və biz istehsal etmək üçün çıxırıq və bu vəziyyəti əldə edirik.

Acı verir, bahadır. Yəqin ki, etməmək daha yaxşıdır.

Və bunu etməyin ən yaxşı yolu nədir?

Gəlin səhnələşdirməni götürək və orada məhsulun bir hissəsini seçək. Və ya ən yaxşı halda, real məhsulu, bütün məlumatları götürək. Onu yerli olaraq inkişaf etdirdikdən sonra əlavə olaraq səhnələşdirməni yoxlayacağıq.

Bu, bizə bəzi səhvləri aradan qaldırmağa, yəni onların istehsalda olmasının qarşısını almağa imkan verəcək.

Problemlər nələrdir?

• Problem ondadır ki, biz bu səhnələşdirməni həmkarlarımızla bölüşürük. Və çox vaxt belə olur ki, siz bir növ dəyişiklik edirsiniz, bam - və heç bir məlumat yoxdur, iş boşalır. Səhnələşdirmə çox terabayt idi. Və onun yenidən qalxması üçün uzun müddət gözləmək lazımdır. Və sabah yekunlaşdırmağa qərar verdik. Budur, inkişafımız var.
• Və təbii ki, bizim orada çalışan çoxlu həmkarlarımız, çoxlu komandalarımız var. Və bunu əl ilə etmək lazımdır. Və bu əlverişsizdir.

Və deməyə dəyər ki, bizim yalnız bir cəhdimiz, bir vuruşumuz var, əgər verilənlər bazasında bəzi dəyişikliklər etmək, məlumatlara toxunmaq, strukturu dəyişdirmək istəyirik. Əgər bir şey səhv olarsa, miqrasiyada səhv olarsa, biz tez geri çəkilməyəcəyik.

Bu, əvvəlki yanaşmadan daha yaxşıdır, lakin hələ də bir növ səhvin istehsala gedəcəyi ehtimalı yüksəkdir.

Hər bir tərtibatçıya bir test skamyası, tam ölçülü bir nüsxə verməyə bizə nə mane olur? Düşünürəm ki, mane olan şey aydındır.

Kimdə terabaytdan böyük verilənlər bazası var? Otağın yarısından çoxu.

Və aydındır ki, hər bir tərtibatçı üçün maşın saxlamaq, belə böyük istehsal olduqda, çox baha başa gəlir və bundan əlavə, uzun müddət tələb olunur.

Bütün dəyişiklikləri tam ölçülü nüsxələrdə sınamağın çox vacib olduğunu başa düşən müştərilərimiz var, lakin onların verilənlər bazası bir terabaytdan azdır və hər bir tərtibatçı üçün sınaq stendini saxlamaq üçün heç bir resurs yoxdur. Buna görə də, zibilləri yerli olaraq maşınlarına yükləməli və bu şəkildə sınaqdan keçirməlidirlər. Bu çox vaxt aparır.

Bunu infrastruktur daxilində etsəniz belə, saatda bir terabayt məlumat yükləmək artıq çox yaxşıdır. Ancaq məntiqi zibillərdən istifadə edirlər, buluddan yerli olaraq yükləyirlər. Onlar üçün sürət saatda təxminən 200 giqabaytdır. Məntiqi zibildən dönmək, indeksləri yuvarlamaq və s. üçün hələ də vaxt lazımdır.

Lakin onlar bu yanaşmadan istifadə edirlər, çünki bu, məhsulu etibarlı saxlamağa imkan verir.

Burada nə edə bilərik? Gəlin test skamyalarını ucuz edək və hər bir tərtibatçıya öz test stendini verək.

Və bu mümkündür.

Və bu yanaşmada hər bir tərtibatçı üçün nazik klonlar hazırladığımız zaman onu bir maşında paylaşa bilərik. Məsələn, 10TB verilənlər bazanız varsa və onu 10 tərtibatçıya vermək istəyirsinizsə, XNUMX x XNUMXTB verilənlər bazasına ehtiyacınız yoxdur. Bir maşından istifadə edərək hər bir tərtibatçı üçün nazik təcrid olunmuş nüsxələr yaratmaq üçün sizə yalnız bir maşın lazımdır. Bunun necə işlədiyini bir az sonra sizə deyəcəyəm.

Həqiqi nümunə:

• DB - 4,5 terabayt.

• Müstəqil nüsxələri 30 saniyəyə əldə edə bilərik.

Test stendini gözləmək lazım deyil və onun nə qədər böyük olduğundan asılıdır. Bir neçə saniyə ərzində əldə edə bilərsiniz. Bu, tamamilə təcrid olunmuş, lakin məlumatları öz aralarında paylaşan mühitlər olacaq.

Bu əladı. Burada sehrdən və paralel kainatdan söhbət gedir.

Bizim vəziyyətimizdə bu OpenZFS sistemindən istifadə etməklə işləyir.

OpenZFS snapshotları və qutudan çıxarılan klonları dəstəkləyən bir kopyalama-yazma fayl sistemidir. Etibarlı və miqyaslana biləndir. Onu idarə etmək çox asandır. Sözün əsl mənasında iki komandada yerləşdirilə bilər.

Digər variantlar var:

• lvm,

• Saxlama (məsələn, Pure Storage).

Haqqında danışdığım verilənlər bazası laboratoriyası moduldur. Bu variantlardan istifadə etməklə həyata keçirilə bilər. Ancaq hələlik biz OpenZFS-ə diqqət yetirmişik, çünki xüsusilə LVM ilə bağlı problemlər var idi.

Bu necə işləyir? Məlumatı hər dəfə dəyişdirəndə onun üzərinə yazmaq əvəzinə, sadəcə olaraq bu yeni məlumatın yeni bir zaman nöqtəsindən, yeni bir şəkil olduğunu qeyd etməklə onu saxlayırıq.

Gələcəkdə biz geri qayıtmaq istəyəndə və ya köhnə versiyadan yeni klon yaratmaq istədikdə sadəcə deyirik: "Yaxşı, bizə bu kimi işarələnmiş məlumat bloklarını verin."

Və bu istifadəçi belə bir məlumat dəsti ilə işləyəcək. O, tədricən onları dəyişəcək, öz snapshotlarını edəcək.

Və biz filial edəcəyik. Bizim vəziyyətimizdə hər bir tərtibatçının redaktə etdiyi öz klonuna sahib olmaq imkanı olacaq və paylaşılan məlumatlar hər kəs arasında paylaşılacaq.

Belə bir sistemi evdə yerləşdirmək üçün iki problemi həll etməlisiniz:

• Birincisi, məlumatların mənbəyidir, onu haradan götürəcəksiniz. İstehsalla təkrarlama qura bilərsiniz. Siz artıq konfiqurasiya etdiyiniz ehtiyat nüsxələrindən istifadə edə bilərsiniz, ümid edirəm. WAL-E, WAL-G və ya Barmen. RDS və ya Cloud SQL kimi bir növ Bulud həllindən istifadə etsəniz belə, məntiqi zibillərdən istifadə edə bilərsiniz. Ancaq yenə də ehtiyat nüsxələrindən istifadə etməyi məsləhət görürük, çünki bu yanaşma ilə siz faylların fiziki strukturunu da saxlayacaqsınız ki, bu da mövcud problemləri həll etmək üçün istehsalda görəcəyiniz ölçülərə daha da yaxınlaşmağa imkan verəcəkdir.

• İkincisi, verilənlər bazası laboratoriyasını yerləşdirmək istədiyiniz yerdir. Bulud ola bilər, yerli ola bilər. Burada ZFS-nin məlumatların sıxılmasını dəstəklədiyini söyləmək vacibdir. Və bunu olduqca yaxşı edir.

Təsəvvür edin ki, hər bir belə klon üçün baza ilə etdiyimiz əməliyyatlardan asılı olaraq bir növ dev böyüyəcək. Bunun üçün devə də yer lazımdır. Ancaq 4,5 terabayt baza götürdüyümüzə görə, ZFS onu 3,5 terabayt qədər sıxacaq. Bu parametrlərdən asılı olaraq dəyişə bilər. Və hələ də inkişaf üçün yerimiz var.

Belə bir sistem müxtəlif hallarda istifadə edilə bilər.

• Bunlar tərtibatçılar, sorğuların yoxlanılması, optimallaşdırma üçün DBA-lardır.

• Bu, müəyyən miqrasiyanı istehsala təqdim etməzdən əvvəl sınaqdan keçirmək üçün QA testində istifadə edilə bilər. Biz həmçinin real məlumatlarla QA üçün yeni funksionallığı sınaqdan keçirə biləcək xüsusi mühitlər yarada bilərik. Və incə nüsxələrin istifadə edilmədiyi bəzi digər hallarda gözləmə saatları əvəzinə saniyələr və bəlkə də günlər çəkəcək.

• Və başqa bir hal. Əgər şirkətdə analitik sistem qurulmayıbsa, onda biz məhsul bazasının nazik klonunu təcrid edə və onu uzun sorğulara və ya analitikada istifadə oluna bilən xüsusi indekslərə verə bilərik.

Bu yanaşma ilə:

1. "İstehsalda" səhvlərin olma ehtimalı azdır, çünki biz bütün dəyişiklikləri tam ölçülü məlumatlar üzərində sınaqdan keçirmişik.

2. Bizdə sınaq mədəniyyəti var, çünki indi öz stendinizi saatlarla gözləmək lazım deyil.

3. Və heç bir maneə, sınaqlar arasında gözləmə yoxdur. Əslində gedib yoxlaya bilərsiniz. İnkişafı sürətləndirdikcə bu, daha yaxşı olacaq.

• Daha az refaktorinq olacaq. Daha az səhv məhsulda bitəcək. Daha sonra onları daha az refaktor edəcəyik.

• Geri dönməz dəyişiklikləri geri qaytara bilərik. Bu standart yanaşma deyil.

1. Bu, faydalıdır, çünki biz sınaq skamyalarının resurslarını paylaşırıq.

Onsuz da yaxşıdır, amma başqa nə sürətləndirmək olar?

Belə bir sistem sayəsində biz belə testə girmək üçün həddi xeyli azalda bilərik.

İndi tam ölçülü məlumatlara çıxış əldə etmək üçün bir tərtibatçının mütəxəssis olması lazım olan bir pis dairə var. Ona bu cür giriş etibar edilməlidir.

Ancaq orada olmasa necə böyümək olar. Bəs sizin üçün yalnız çox kiçik bir test məlumat dəsti varsa nə olacaq? Sonra heç bir real təcrübə əldə etməyəcəksiniz.

Bu dairədən necə çıxmaq olar? İstənilən səviyyəli tərtibatçılar üçün əlverişli olan ilk interfeys olaraq biz Slack botunu seçdik. Ancaq hər hansı digər interfeys ola bilər.

Bu sizə nə etməyə imkan verir? Siz konkret sorğu götürüb verilənlər bazası üçün xüsusi kanala göndərə bilərsiniz. Biz saniyələr ərzində avtomatik olaraq nazik bir klonu yerləşdirəcəyik. Gəlin bu sorğunu icra edək. Metriklər və tövsiyələr toplayırıq. Vizuallaşdırmanı göstərək. Və sonra bu klon qalacaq ki, bu sorğu bir şəkildə optimallaşdırılsın, indekslər əlavə olunsun və s.

Həm də Slack bizə qutudan kənar əməkdaşlıq imkanları verir. Bu, sadəcə bir kanal olduğundan, bu sorğunu elə orada müzakirə etməyə başlaya bilərsiniz, belə bir sorğu üçün mövzuda həmkarlarınıza, şirkət daxilində olan DBA-lara ping göndərin.

Amma təbii ki, problemlər var. Bu, real dünya olduğu üçün və biz eyni anda bir çox klonu saxlayan serverdən istifadə etdiyimiz üçün klonlar üçün mövcud yaddaş və CPU gücünü sıxışdırmalıyıq.

Ancaq bu testlərin inandırıcı olması üçün bu problemi bir şəkildə həll etməlisiniz.

Aydındır ki, vacib məqam eyni məlumatdır. Amma bizdə artıq var. Və eyni konfiqurasiyaya nail olmaq istəyirik. Və biz belə demək olar ki, eyni konfiqurasiya verə bilərik.

İstehsalda olduğu kimi eyni avadanlıqa sahib olmaq gözəl olardı, lakin fərqli ola bilər.

Postgresin yaddaşla necə işlədiyini xatırlayaq. İki keşimiz var. Biri fayl sistemindən və bir yerli Postgres, yəni Paylaşılan Bufer Keşi.

Qeyd etmək vacibdir ki, Paylaşılan Bufer Keşi, konfiqurasiyada göstərdiyiniz ölçüdən asılı olaraq Postgres işə salındıqda ayrılır.

Və ikinci önbellek bütün mövcud yerdən istifadə edir.

Və bir maşında bir neçə klon hazırlayanda məlum olur ki, yaddaşı tədricən doldururuq. Və yaxşı mənada, Paylaşılan Bufer Keşi maşında mövcud olan ümumi yaddaş həcminin 25%-ni təşkil edir.

Və belə çıxır ki, bu parametri dəyişdirməsək, bir maşında yalnız 4 nümunəni, yəni bütün belə nazik klonlardan 4-nü işlədə biləcəyik. Və bu, əlbəttə ki, pisdir, çünki biz onlardan daha çox olmasını istəyirik.

Ancaq digər tərəfdən, Buffer Cache indekslər üçün sorğuları yerinə yetirmək üçün istifadə olunur, yəni plan keşlərimizin nə qədər böyük olmasından asılıdır. Və sadəcə olaraq bu parametri götürsək və onu azaltsaq, o zaman planlarımız çox dəyişə bilər.

Məsələn, məhsulda böyük bir keşimiz varsa, Postgres indeksdən istifadə etməyə üstünlük verəcəkdir. Yoxdursa, SeqScan olacaq. Və planlarımız üst-üstə düşməsəydi nə mənası olardı?

Ancaq burada belə bir nəticəyə gəlirik ki, əslində Postgres-də plan planda Paylaşılan Buferdə göstərilən xüsusi ölçüdən asılı deyil, effektiv_cache_size-dən asılıdır.

Effektiv_cache_size bizim üçün əlçatan olan keşin təxmini miqdarıdır, yəni Bufer Keşi və fayl sistemi keşinin cəmidir. Bu konfiqurasiya ilə müəyyən edilir. Və bu yaddaş ayrılmır.

Və bu parametrə görə biz Postgresi aldada bilərik və bu məlumatımız olmasa belə, həqiqətən çoxlu məlumatımız olduğunu söyləyə bilərik. Beləliklə, planlar istehsalla tamamilə üst-üstə düşəcək.

Ancaq bu, vaxta təsir edə bilər. Biz sorğuları vaxtla optimallaşdırırıq, lakin vaxtın bir çox amillərdən asılı olması vacibdir:

• Bu, hazırda məhsulda olan yükdən asılıdır.

• Bu, maşının özünün xüsusiyyətlərindən asılıdır.

Və bu dolayı parametrdir, amma əslində biz nəticə əldə etmək üçün bu sorğunun oxuyacağı məlumatların miqdarına görə optimallaşdıra bilərik.

Əgər vaxtın istehsalda görəcəyimizə yaxın olmasını istəyirsinizsə, o zaman bütün klonların uyğunlaşması üçün ən oxşar avadanlıqları və bəlkə də daha çoxunu götürməliyik. Ancaq bu bir kompromisdir, yəni eyni planları əldə edəcəksiniz, müəyyən bir sorğunun nə qədər məlumat oxuyacağını görəcəksiniz və bu sorğunun yaxşı (yaxud miqrasiya) və ya pis olduğuna dair nəticəyə gələ biləcəksiniz, hələ də optimallaşdırılmalıdır. .

Gəlin Joe-nun xüsusi olaraq necə optimallaşdırıldığına nəzər salaq.

Real sistemdən sorğu götürək. Bu halda verilənlər bazası 1 terabayt təşkil edir. Və 10-dan çox bəyənilən yeni yazıların sayını saymaq istəyirik.

Kanala mesaj yazırıq, bizim üçün klon yerləşdirilib. Və belə bir sorğunun 2,5 dəqiqəyə tamamlanacağını görəcəyik. Bu, diqqətimizi çəkən ilk şeydir.

B Joe sizə plan və ölçülərə əsasən avtomatik tövsiyələr göstərəcək.

Nisbətən az sayda sətir əldə etmək üçün sorğunun həddən artıq çox məlumat emal etdiyini görəcəyik. Sorğuda həddən artıq süzülmüş sətirlərin olduğunu fərq etdiyimiz üçün bir növ ixtisaslaşmış indeksə ehtiyac var.

Gəlin baş verənlərə daha yaxından nəzər salaq. Həqiqətən, biz fayl keşindən və ya hətta diskdən demək olar ki, bir yarım gigabayt məlumat oxuduğumuzu görürük. Bu da yaxşı deyil, çünki bizdə cəmi 142 sətir var.

Və deyəsən, burada indeks skanımız var və tez işləməliydik, lakin biz çoxlu sətirləri süzgəcdən keçirdiyimiz üçün (onları saymalı olduq), sorğu yavaş-yavaş yerinə yetirildi.

Və bu, sorğudakı şərtlərlə indeksdəki şərtlərin qismən uyğun gəlməməsi səbəbindən planda baş verdi.

Gəlin indeksi daha dəqiq etməyə çalışaq və ondan sonra sorğunun icrasının necə dəyişdiyini görək.

İndeksin yaradılması kifayət qədər uzun müddət çəkdi, lakin indi sorğunu yoxlayırıq və görürük ki, 2,5 dəqiqə əvəzinə vaxt cəmi 156 millisaniyədir, bu kifayət qədər yaxşıdır. Biz isə cəmi 6 meqabayt məlumat oxuyuruq.

İndi biz yalnız indeks taramasından istifadə edirik.

Başqa bir mühüm hekayə ondan ibarətdir ki, biz planı daha başa düşülən şəkildə təqdim etmək istəyirik. Biz Flame Graphs istifadə edərək vizuallaşdırma həyata keçirdik.

Bu fərqli bir istəkdir, daha sıxdır. Və biz Alov Qrafiklərini iki parametrə görə qururuq: bu, müəyyən bir düyünün planda və vaxtda saydığı məlumatların miqdarıdır, yəni qovşağın icra müddəti.

Burada xüsusi qovşaqları bir-biri ilə müqayisə edə bilərik. Və onlardan hansının daha çox və ya daha az götürdüyü aydın olacaq, adətən bunu digər göstərmə üsullarında etmək çətindir.

Təbii ki, hər kəs izahat.depesz.com saytını bilir. Bu vizuallaşdırmanın yaxşı xüsusiyyəti ondan ibarətdir ki, biz mətn planını saxlayırıq və bəzi əsas parametrləri cədvələ qoyuruq ki, sıralaya bilək.

Bu mövzunu hələ araşdırmamış tərtibatçılar da explain.depesz.com-dan istifadə edirlər, çünki onlar üçün hansı ölçülərin vacib və hansının olmadığını anlamaq daha asandır.

Vizuallaşdırmaya yeni bir yanaşma var - bu izahat.dalibo.com. Ağacın vizuallaşdırılmasını edirlər, lakin qovşaqları bir-biri ilə müqayisə etmək çox çətindir. Burada strukturu yaxşı başa düşə bilərsiniz, lakin böyük bir sorğu varsa, o zaman irəli və geri sürüşməli olacaqsınız, həm də bir seçim.

əməkdaşlıq

Və dediyim kimi, Slack bizə əməkdaşlıq etmək imkanı verir. Məsələn, necə optimallaşdırılacağı bəlli olmayan mürəkkəb sorğuya rast gəlsək, Slack-dəki mövzuda həmkarlarımızla bu məsələyə aydınlıq gətirə bilərik.

Bizə elə gəlir ki, tam ölçülü verilənlər üzərində sınaqdan keçirmək vacibdir. Bunun üçün açıq mənbədə mövcud olan Update Database Lab alətini etdik. Siz də Joe botundan istifadə edə bilərsiniz. Siz onu indi götürüb öz yerinizdə həyata keçirə bilərsiniz. Bütün bələdçilər orada mövcuddur.

Onu da qeyd etmək lazımdır ki, həllin özü inqilabi deyil, çünki Delphix var, lakin bu, müəssisə həllidir. Tam qapalıdır, çox bahadır. Biz xüsusilə Postgres-də ixtisaslaşmışıq. Bunların hamısı açıq mənbəli məhsullardır. Bizə qoşul!

Sonum budur. Çox sağ ol!

Suallar

Salam! Hesabat üçün təşəkkür edirik! Çox maraqlıdır, xüsusən də mənim üçün, çünki bir müddət əvvəl eyni problemi həll etmişdim. Və buna görə də bir sıra suallarım var. İnşallah heç olmasa bir hissəsini alacam.

Maraqlıdır, bu mühit üçün yeri necə hesablayırsınız? Texnologiya o deməkdir ki, müəyyən şərtlər altında klonlarınız maksimum ölçüyə qədər böyüyə bilər. Təxminən desək, on terabayt verilənlər bazanız və 10 klonunuz varsa, hər bir klonun 10 unikal məlumatı çəkdiyi bir vəziyyəti simulyasiya etmək asandır. Bu klonların yaşayacağı bu yeri, yəni haqqında danışdığınız deltanı necə hesablayırsınız?

Yaxşı sual. Burada xüsusi klonları izləmək vacibdir. Və əgər klonun çox böyük dəyişikliyi varsa, o, böyüməyə başlayır, o zaman biz əvvəlcə istifadəçiyə bununla bağlı xəbərdarlıq edə bilərik və ya uğursuz vəziyyətə düşməmək üçün bu klonu dərhal dayandıra bilərik.

Bəli, mənim bir sualım var. Yəni bu modulların həyat dövrünü necə təmin edirsiniz? Bu problemimiz və tam ayrı bir hekayəmiz var. Bu necə baş verir?

Hər bir klon üçün bir qədər ttl var. Əsasən, biz sabit ttl var.

Sirr olmasa nə olar?

1 saat, yəni boş - 1 saat. İstifadə edilmirsə, onu vururuq. Ancaq burada sürpriz yoxdur, çünki klonu saniyələr ərzində qaldıra bilərik. Və yenidən ehtiyacınız varsa, xahiş edirəm.

Texnologiyaların seçimi ilə də maraqlanıram, çünki, məsələn, biz bu və ya digər səbəbdən paralel olaraq bir neçə üsuldan istifadə edirik. Niyə ZFS? Niyə LVM istifadə etmədiniz? LVM ilə bağlı problemlərin olduğunu qeyd etdiniz. Problemlər nə idi? Məncə, performans baxımından ən optimal variant saxlama ilədir.

ZFS ilə bağlı əsas problem nədir? Eyni hostda işləməlisiniz, yəni bütün nümunələr eyni OS daxilində yaşayacaqdır. Və saxlama vəziyyətində, müxtəlif avadanlıqları birləşdirə bilərsiniz. Və darboğaz yalnız saxlama sistemində olan bloklardır. Texnologiyaların seçimi məsələsi isə maraqlıdır. Niyə LVM deyil?

Konkret olaraq LVM-i görüşdə müzakirə edə bilərik. Saxlama haqqında - bu, sadəcə bahalıdır. ZFS sistemini istənilən yerdə tətbiq edə bilərik. Siz onu maşınınızda yerləşdirə bilərsiniz. Siz sadəcə deponu yükləyə və yerləşdirə bilərsiniz. Linux haqqında danışırıqsa, ZFS demək olar ki, hər yerdə quraşdırılmışdır. Yəni çox çevik bir həll əldə edirik. Və ZFS özü qutudan çox şey verir. İstədiyiniz qədər məlumat yükləyə, çox sayda diski birləşdirə bilərsiniz, anlıq görüntülər var. Və dediyim kimi, idarə etmək asandır. Yəni istifadə etmək çox xoş görünür. Sınaqdan keçir, çox yaşı var. Onun böyüyən çox böyük bir icması var. ZFS çox etibarlı bir həlldir.

Nikolay Samoxvalov: Əlavə şərh verə bilərəmmi? Mənim adım Nikolay, biz Anatoli ilə birlikdə işləyirik. Razıyam ki, saxlama əladır. Bəzi müştərilərimizdə Pure Storage və s.

Anatoli düzgün qeyd etdi ki, biz modulluğa diqqət yetiririk. Və gələcəkdə bir interfeys həyata keçirə bilərsiniz - snapshot çəkin, klon hazırlayın, klonu məhv edin. Hər şey asandır. Və saxlama sərindir, əgər varsa.

Lakin ZFS hər kəs üçün əlçatandır. DelPhix artıq kifayətdir, onların 300 müştərisi var. Bunlardan Fortune 100-ün 50 müştərisi var, yəni onlar NASA-ya yönəlib və s. Hər kəsin bu texnologiyanı əldə etmə vaxtıdır. Və buna görə də bizdə açıq mənbəli Core var. Açıq mənbə olmayan bir interfeys hissəmiz var. Bu, göstərəcəyimiz platformadır. Amma biz onun hamı üçün əlçatan olmasını istəyirik. Biz inqilab etmək istəyirik ki, bütün testçilər noutbuklarda təxmin etməyi dayandırsınlar. Biz SELECT yazmalıyıq və onun yavaş olduğunu dərhal görməliyik. DBA-nın bu barədə sizə məlumat verməsini gözləməyi dayandırın. Əsas məqsəd budur. Və düşünürəm ki, hamımız buna gələcəyik. Və bu şeyi hər kəsin sahib olması üçün edirik. Buna görə də ZFS, çünki hər yerdə mövcud olacaq. Problemləri həll etdiyinə və açıq mənbə lisenziyasına malik olduğu üçün icmaya təşəkkürlər və s.*

salamlar! Hesabat üçün təşəkkür edirik! Mənim adım Maksim. Eyni məsələlərlə məşğul olmuşuq. Onlar özləri qərar verdilər. Bu klonlar arasında resursları necə paylaşırsınız? Hər bir klon istənilən vaxt öz işini görə bilər: biri bir şeyi yoxlayır, digəri digərini, kimsə indeks qurur, kiminsə işi ağırdır. Əgər siz hələ də CPU-ya, sonra IO-ya bölünə bilirsinizsə, necə bölmək olar? Bu birinci sualdır.

İkinci sual isə tribunaların fərqliliyi ilə bağlıdır. Tutaq ki, məndə ZFS var və hər şey əladır, lakin məhsuldakı müştəridə ZFS yox, məsələn, ext4 var. Bu halda necə?

Suallar cox gozeldir. Mən bu problemi bir az da resursları paylaşdığımızla qeyd etdim. Və həll yolu budur. Təsəvvür edin ki, səhnələşdirmədə sınaqdan keçirsiniz. Sizdə də eyni vaxtda elə bir vəziyyət yarana bilər ki, kimsə bir yükü başqasına verir. Və nəticədə siz anlaşılmaz ölçülər görürsünüz. Hətta eyni problem məhsulda da ola bilər. Hansısa sorğunu yoxlamaq və onunla hansısa problemin olduğunu görmək istəyəndə - o, yavaş işləyir, deməli, əslində problem sorğuda deyil, bir növ paralel yüklənmənin olmasında idi.

Buna görə də, burada planın nə olacağına, planda hansı addımları atacağımıza və bunun üçün nə qədər məlumat toplayacağımıza diqqət yetirmək vacibdir. Məsələn, disklərimizin bir şeylə yüklənməsi, bu, xüsusi olaraq vaxta təsir edəcəkdir. Lakin bu sorğunun nə qədər yükləndiyini məlumatların miqdarı ilə təxmin edə bilərik. Eyni zamanda bir növ edamın olması o qədər də vacib deyil.

Mənim iki sualım var. Bu çox gözəl şeydir. Kredit kartı nömrələri kimi istehsal məlumatlarının kritik olduğu hallar olubmu? Artıq hazır bir şey varmı, yoxsa bu ayrıca bir işdir? Və ikinci sual - MySQL üçün belə bir şey varmı?

Məlumatlar haqqında. Bunu edənə qədər çaşqınlıq edəcəyik. Ancaq dəqiq Joe-ni yerləşdirsəniz, tərtibatçılara giriş vermirsinizsə, məlumatlara giriş yoxdur. Niyə? Çünki Joe data göstərmir. Yalnız ölçüləri, planları göstərir və bu qədər. Bu, qəsdən edilib, çünki bu, müştərimizin tələblərindən biridir. Hər kəsə giriş imkanı vermədən optimallaşdıra bilmək istəyirdilər.

MySQL haqqında. Bu sistem diskdə vəziyyəti saxlayan hər şey üçün istifadə edilə bilər. Postgres ilə məşğul olduğumuz üçün indi ilk olaraq Postgres üçün bütün avtomatlaşdırma işləri görürük. Biz ehtiyat nüsxədən məlumat əldə etməyi avtomatlaşdırmaq istəyirik. Postgres-i düzgün konfiqurasiya edirik. Planları necə uyğunlaşdıracağımızı və s.

Lakin sistem genişləndirilə bilən olduğundan MySQL üçün də istifadə oluna bilər. Və belə nümunələr var. Yandex-də də oxşar bir şey var, lakin onlar bunu heç bir yerdə dərc etmirlər. Yandex.Metrica daxilində istifadə edirlər. Və sadəcə MySQL haqqında bir hekayə var. Ancaq texnologiyalar eynidir, ZFS.

Hesabat üçün təşəkkür edirik! Mənim də bir-iki sualım var. Siz qeyd etdiniz ki, klonlaşdırma analitika üçün, məsələn, orada əlavə indekslər yaratmaq üçün istifadə edilə bilər. Bunun necə işlədiyi barədə bir az ətraflı məlumat verə bilərsinizmi?

Mən dərhal stendlərin oxşarlığı, planların oxşarlığı ilə bağlı ikinci sualı verəcəm. Plan həmçinin Postgres tərəfindən toplanan statistikadan asılıdır. Bu problemi necə həll edirsiniz?

Analitiklərə görə, konkret hallar yoxdur, çünki biz hələ istifadə etməmişik, amma belə bir imkan var. Əgər biz indekslərdən danışırıqsa, onda təsəvvür edin ki, sorğu yüz milyonlarla qeyddən ibarət cədvəli və adətən məhsulda indeksləşdirilməyən sütunu təqib edir. Və biz orada bəzi məlumatları hesablamaq istəyirik. Əgər bu sorğu məhsula göndərilirsə, o zaman onun istehsalda sadə olması ehtimalı var, çünki sorğu orada bir dəqiqə ərzində işlənəcək.

Yaxşı, bir neçə dəqiqə dayanmaq qorxunc olmayan nazik bir klon hazırlayaq. Və analitikanı oxumağı daha rahat etmək üçün məlumatlarla maraqlandığımız sütunlar üçün indekslər əlavə edəcəyik.

İndeks hər dəfə yaradılacaq?

Siz bunu elə edə bilərsiniz ki, biz dataya toxunaq, snapshotlar edək, sonra biz bu snapshotdan bərpa edəcəyik və yeni sorğular göndərəcəyik. Yəni, onu elə edə bilərsiniz ki, artıq əlavə edilmiş indekslərlə yeni klonlar qaldıra biləsiniz.

Statistikaya dair suala gəlincə, əgər ehtiyat nüsxədən bərpa etsək, replikasiya etsək, statistikamız tam olaraq eyni olacaq. Çünki bizdə bütün fiziki məlumat strukturu var, yəni məlumatları bütün statistik ölçülərlə olduğu kimi gətirəcəyik.

Burada başqa bir problem var. Əgər bulud həllindən istifadə edirsinizsə, onda orada yalnız məntiqi zibillər mövcuddur, çünki Google, Amazon fiziki surət götürməyə icazə vermir. Problem olacaq.

Hesabat üçün təşəkkür edirik. Burada MySQL və resurs mübadiləsi ilə bağlı iki yaxşı sual var idi. Amma əslində hər şey ondan irəli gəlir ki, bu konkret DBMS-nin mövzusu deyil, bütövlükdə fayl sistemi ilə bağlıdır. Və buna uyğun olaraq, resurs mübadiləsi məsələləri də oradan həll edilməlidir, sonda Postgres deyil, fayl sistemində, serverdə, məsələn.

Sualım bir az fərqlidir. O, bir neçə təbəqənin olduğu çoxqatlı verilənlər bazasına daha yaxındır. Məsələn, biz on terabaytlıq bir şəkil yeniləməsini qurduq, təkrarlayırıq. Və biz bu həlli verilənlər bazası üçün xüsusi olaraq istifadə edirik. Replikasiya davam edir, məlumatlar yenilənir. Burada paralel olaraq çalışan 100 işçi var ki, onlar daim bu müxtəlif kadrları işə salırlar. Nə etməli? Münaqişənin olmadığına, birini işə saldıqlarına və sonra fayl sisteminin dəyişdiyinə və bu şəkillərin hamısı getdiyinə necə əmin olmaq olar?

Onlar getməyəcək, çünki ZFS belə işləyir. Replikasiya nəticəsində yaranan fayl sistemi dəyişikliklərini ayrıca bir mövzuda saxlaya bilərik. Və tərtibatçıların məlumatların köhnə versiyalarında istifadə etdiyi klonları saxlayın. Və bizim üçün işləyir, bununla hər şey qaydasındadır.

Belə çıxır ki, yeniləmə əlavə bir təbəqə kimi baş verəcək və bütün yeni şəkillər artıq bu təbəqə əsasında gedəcək, elə deyilmi?

Əvvəlki replikalardan olan əvvəlki təbəqələrdən.

Əvvəlki təbəqələr yıxılacaq, lakin onlar köhnə təbəqəyə istinad edəcək və yeniləmədə qəbul edilmiş sonuncu təbəqədən yeni şəkillər çəkəcəklər?

Ümumiyyətlə, bəli.

Sonra nəticədə bir əncirə qədər təbəqəmiz olacaq. Və zaman keçdikcə onları sıxmaq lazımdır?

Bəli hər şey düzgündür. Bir az pəncərə var. Həftəlik snapshotları saxlayırıq. Hansı resursunuz olduğundan asılıdır. Əgər çoxlu məlumat saxlamaq qabiliyyətiniz varsa, anlıq görüntüləri uzun müddət saxlaya bilərsiniz. Onlar özbaşına getməyəcəklər. Məlumatların korlanması olmayacaq. Əgər anlıq görüntülər bizə göründüyü kimi köhnəlibsə, yəni şirkətdəki siyasətdən asılıdırsa, biz onları sadəcə silə və yer boşalta bilərik.

Salam, hesabata görə təşəkkürlər! Joe haqqında sual. Siz dediniz ki, müştəri hər kəsə məlumatlara giriş imkanı vermək istəmir. Düzünü desək, əgər bir insanın Təhlili izah et nəticəsi varsa, o, məlumatları nəzərdən keçirə bilər.

Elə bil. Məsələn, yaza bilərik: "SEÇ FROM WHERE email = to that". Yəni biz məlumatların özünü görməyəcəyik, lakin bəzi dolayı əlamətləri görə bilərik. Bu başa düşülməlidir. Ancaq digər tərəfdən, hər şey var. Bizim log auditimiz var, tərtibatçıların nə etdiyini görən digər həmkarlarımıza da nəzarət edirik. Kimsə bunu etməyə cəhd edərsə, o zaman mühafizə xidməti onların yanına gəlib bu məsələ ilə məşğul olacaq.

Günortanız Xeyir Hesabat üçün təşəkkür edirik! Qısa sualım var. Şirkət Slack-dən istifadə etmirsə, indi bununla bağlı hər hansı bir məcburiyyət varmı və ya tərtibatçılar test tətbiqini verilənlər bazasına qoşmaq üçün nümunələri yerləşdirə bilərlərmi?

İndi Slack-ə bir keçid var, yəni başqa messencer yoxdur, amma həqiqətən digər messencerlərə də dəstək olmaq istəyirəm. Sən nə edə bilərsən? Siz DB Lab-ı Joe olmadan yerləşdirə, REST API və ya platformamızın köməyi ilə gedə və klonlar yarada və PSQL ilə əlaqə saxlaya bilərsiniz. Ancaq bu, tərtibatçılarınıza məlumatlara giriş verməyə hazır olduğunuz halda edilə bilər, çünki artıq heç bir ekran olmayacaq.

Mənə bu təbəqə lazım deyil, amma belə bir fürsət lazımdır.

Sonra bəli, edilə bilər.

Mənbə: www.habr.com