Hər kəsə salam! Mənim adım Nikolay Golovdur. Əvvəllər Avito-da çalışmışam və altı il Data Platform-a rəhbərlik etmişəm, yəni analitik (Vertica, ClickHouse), axın və OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL) verilənlər bazaları ilə məşğul olmuşam. Bu müddət ərzində çoxsaylı verilənlər bazalarını — müxtəlif və qeyri-adi olanları, eləcə də qeyri-standart istifadəsi olanları öyrənmişəm.
İndi ManyChat-da çalışıram. Bu, əsasən bir startapdır — yeni, ambisiyalı və sürətlə böyüyən. Şirkətə yeni daxil olduğum zaman klassik bir sual yaranmışdı: "Gənc startap üçün verilənlər bazası və DBMS bazarından nə seçməlidir?".
Bu məqalədə, mənim təqdimatım əsaslanan , bu suala cavab verəcəyəm. Təqdimatın video versiyası .
2020-ci il üçün tanınmış verilənlər bazaları.
İndi 2020-ci ildir, ətrafıma baxdım və üç növ DB gördüm.
Birinci növ — klassik OLTP verilənlər bazaları: PostgreSQL, SQL Server, Oracle, MySQL. Onlar uzun müddət əvvəl yazılıb, amma hələ də aktualdır, çünki inkişaf etdirmə cəmiyyəti tərəfindən yaxşı tanınır.
İkinci növ — «sıfır» illərin verilənlər bazaları.Onlar SQL-dən, ənənəvi strukturlardan və ACID-dən imtina edərək klassik şablonlardan uzaqlaşmağa çalışdılar, daxili şardinq və digər cəlbedici xüsusiyyətlərin əlavə edilməsinə imkan verdilər. Məsələn, Cassandra, MongoDB, Redis və ya Tarantool bunlardır. Bütün bu həllər bazara tamamilə yeni bir şey təqdim etməyə çalışdılar və müəyyən tapşırıqlarda son dərəcə əlverişli olduqları üçün öz nişini tutdular. Bu verilənləri NOSQL kimi ümumi terminlə qeyd edəcəyəm.
«Sıfırlar» bitdi, NOSQL verilənlər bazalarına öyrəşildi, və dünyamız, mənim baxış açılarıma görə, növbəti addımı atdı — idarə olunan verilənlər bazalarına.Bu verilənlərin nüvəsi klassik OLTP verilənlər bazaları və ya yeni NoSQL-lərin nüvəsi ilə eynidir. Amma onların DBA və DevOps-a ehtiyacı yoxdur və buludlarda idarə olunan avadanlıqlarda dövr edir. İnkişaf etdirici üçün bu, «sadəcə bir verilənlər bazasıdır», hansısa yerdə işləyir, serverdə necə quraşdırıldığını, serveri kim konfiqurasiya etdiyini və kim yenilədiyini heç kim düşünmür.
Belə verilənlər bazalarına misallar:
- AWS RDS — PostgreSQL/MySQL üzərində idarə olunan örtük.
- DynamoDB — Redis və MongoDB-yə bənzər AWS-nin sənəd əsaslı verilənlər bazası.
- Amazon Redshift — idarə olunan analitik verilənlər bazası.
Bunlar köhnə verilənlər bazalarıdır, amma idarə olunan mühitdə işləyir, avadanlıqlarla işləməyə ehtiyac yoxdur.
Qeyd. Misallar AWS mühitindədir, amma onların analoqları Microsoft Azure, Google Cloud və ya Yandex.Cloud-da da mövcuddur.
Bəs bundan yeni nə var? 2020-ci ildə bunun heç biri yox.
Serverless konsepsiyası
2020-ci ildə bazarda gerçekten yenilikçi olan serverless və ya serversiz həllərdir.
Bunun nə demək olduğunu bir adi xidmət və ya backend tətbiqi misalında izah etməyə çalışacağam.
Adi bir backend tətbiqini inkişaf etdirmək üçün bir server alırıq və ya icarəyə götürürük, onun üzərinə kodu köçürürük, xaricə endpoint yayımlayırıq və mütəmadi olaraq icarə, elektrik və data mərkəzi xidmətləri üçün ödəniş edirik. Bu standart sxemdir.
Bunu başqa cür etmək olarmı? Bəli, serversiz xidmətlər vasitəsilə mümkündür.
Bu yanaşmanın fəndi budur: server yoxdur, hətta buludda virtual instance icarəsi də yoxdur. Xidməti inkişaf etdirmək üçün kodun (funksiyaların) bir depozitora köçürülür və xaricə endpoint yayımlayırıq. Sonra yalnız bu funksiyanın çağırılmasına görə ödəniş edirik, onun icra edildiyi mühit haqqında tamamilə nəzərə almırıq.
Bu yanaşmanı şəkillərlə izah etməyə çalışacağam.
Klassik yerləşdirmə. Bizim müəyyən bir yük ilə xidmətimiz var. İki instance qaldırırıq: fiziki serverlər və ya AWS-də instance-lar. Xarici sorğular bu instance-lara yönəldilir və orada emal edilir.
Şəkildən göründüyü kimi, serverlərin istifadə nisbəti eyni deyil. Biri 100% istifadə olunur, orada iki sorğu var, digəri isə yalnız 50%-dədir - qismən boşdur. Əgər üç sorğu deyil, 30 sorğu gələrsə, bütün sistem yükü qaldıra bilməyəcək və yavaşlayacaq.
Serversiz yerləşdirmə. Serversiz mühitdə belə bir xidmətin instance-ları və serverləri yoxdur. Kiçik, hazırlanmış Docker konteynerləri ilə kodun funksiyası ilə hazırlanmış müəyyən bir istiliklə təsir edən resurslar var. Sistem xarici sorğuları alır və hər biri üçün serversiz çərçivə kiçik konteyneri kod ilə qaldırır: məhz bu sorğunu emal edir və konteyneri öldürür.
Bir sorğu - bir qaldırılmış konteyner, 1000 sorğu - 1000 konteyner. Və dəmir serverlərdə yerləşdirmə - bu artıq bulud provayderinin işi. Bu tamamilə serversiz çərçivə ilə gizlədilir. Bu konsepsiyada biz hər bir çağırmaya görə ödəniş edirik. Məsələn, gündə bir çağırış gəldi - bir çağırışa görə ödəniş etdik, dəqiqədə bir milyon gəldi - bir milyon üçün ödəniş etdik. Yaxud da bir saniyədə, belə də olur.
Serverless funksiya dərc konsepsiyası state-siz bir xidmət üçün uyğundur. Lakin əgər sizə state (ştat) bir statefull xidmət lazımdırsa, o zaman xidmətə verilənlər bazası əlavə edirik. Bu halda, state ilə işləməyə gəldikdə, hər bir statefull funksiya sadəcə verilənlər bazasından yazır və oxuyur. Həm də məqalənin əvvəlində təsvir olunan üç tipdən hər hansı birindən verilənlər bazasından.
Bu bazaların hamısının ümumi məhdudiyyəti nədir? Bu, daima istifadə olunan bulud və ya avadanlıq serverinə (və ya bir neçə serverə) çəkilən xərclərdir. Klassik bazadan və ya idarə olunan bazadan asılı olmayaraq, Devops və ya administrator olması fark etməz, 24/7 avadanlığa, elektrikə və data mərkəzinin kirayəsinə ödəyirik. Klassik bazamız varsa, master və slave üçün ödəniş edirik. Əgər yüksək yüklü şardlaşdırılmış bazamız varsa, 10, 20 və ya 30 server üçün ödeyirik və daima ödəniş edirik.
Xərclər strukturunda daima ayrılmış serverlər əvvəllər mütləq bir pislik kimi qəbul edilirdi. Üstəlik, adi bazaların digər çətinlikləri də var, məsələn, bağlantı sayı üzrə limlər, genişlənmə məhdudiyyətləri, coğrafi istiqamətləndirilmiş konsensus — bunları müəyyən bazalarda nəsə bir şəkildə həll etmək olar, amma hamısını eyni anda və mükəmməl deyil.
Serverless verilənlər bazası — nəzəriyyə
2020-ci il sualı: verilənlər bazasını da serverless etmək mümkündürmü? Hamı serverless arxa plandan eşidib... bəs verilənlər bazasını da serverless etməyə çalışaq?
Bu, qəribə səslənir, çünki verilənlər bazası statefull bir xidmətdir, serverless infrastruktur üçün çox uyğun deyil. Eyni zamanda, verilənlər bazasının state-u da çox böyükdür: gigabaytlar, terabaytlar, analitik bazalarda isə hətta petabaytlar. Onu yüngül Docker konteynerlərində asanlıqla qurmaq mümkün deyil.
Digər tərəfdən, müasir bazaların əksəriyyəti — böyük bir məntiq və komponentlər toplusudur: tranzaksiyalar, bütövlüyün uyğunlaşdırılması, prosedurlar, riyazi asılılıqlar və çoxlu məntiq. Verilənlər bazasının məntiqinin böyük bir hissəsi əlverişli bir state üçün kifayətdir. Gigabaytlar və terabaytlar, yalnız verilənlər bazasının sorğuları yerinə yetirilməsi ilə bağlı kiçik bir məntiq hissəsi tərəfindən birbaşa istifadə olunur.
Beləliklə, ideya: əgər məntiqin bir hissəsi state-siz icra olunmağa icazə verirsə, niyə də verilənlər bazasını Stateful və Stateless hissələrə ayırmayaq.
OLAP həlləri üçün Serverless
Gəlin, verilənlər bazasının Stateful və Stateless hissələrə ayrılmasının praktik nümunələrdə necə görünəcəyinə baxaq.
Məsələn, bizim analitik verilənlər bazamız var.: xarici məlumatlar (solda qırmızı silindir), məlumatları bazaya yükləyən ETL prosesi və bazaya SQL sorğuları göndərən analitik. Bu, məlumat anbarının klassik işləmə sxemasıdır.
Bu sxemdə, şərti olaraq, ETL bir dəfə yerinə yetirilir. Sonra verilənlərin yükləndiyi bazanın işlədiyi serverlər üçün daima ödəniş etməlisiniz ki, sorğular göndərmək üçün bir şey olsun.
Alternativ yanaşmanı nəzərdən keçirək, AWS Athena Serverless-də həyata keçirilmişdir. Burada yüklənmiş verilənlərin saxlandığı daimi ayrılmış avadanlıq yoxdur. Bunun əvəzinə:
- İstifadəçi Athena-ya SQL sorğusu göndərir. Athena optimizatoru SQL sorğusunu analiz edir və sorğunu yerinə yetirmək üçün lazım olan konkret verilənləri metadata (metaməlumat) anbarında axtarır.
- Optimallaşdırıcı, toplanmış məlumata əsaslanaraq, xarici mənbələrdən lazım olan verilənləri müvəqqəti anbara (müvəqqəti verilənlər bazasına) yükləyir.
- Müvəqqəti anbar, istifadəçidən alınan SQL sorğusunu icra edir, nəticə istifadəçiyə qaytarılır.
- Müvəqqəti anbar təmizlənir, resurslar azad edilir.
Bu memarlıqda yalnız sorğu icrası prosesi üçün ödəniş edirik. Sorğular yoxdursa — xərc yoxdur.
Bu işgüzar yanaşmadır və yalnız Athena Serverless-də deyil, AWS-də Redshift Spectrum-da da həyata keçirilir.
Athena misalında aydın olur ki, Serverless verilənlər bazası real sorğularla onlarla və yüzlərlə Terabayt verilənlə işləyir. Yüzlərlə Terabayt üçün yüzlərlə server lazımdır, amma onlara görə ödəniş etməli deyiliksə — sorğular üçün ödəniş edirik. Hər bir sorğunun sürəti (çox) aşağıdır, Vertica kimi ixtisaslaşdırılmış analitik verilənlər bazaları ilə müqayisədə, amma durğunluq dövrlərinə görə ödəniş etmirik.
Bu verilənlər bazası nadir analitik ad-hoc sorğular üçün yararlıdır. Məsələn, böyük verilənlər cəmində bir hipotezi təsdiqləməyə spontan qərar versək. Bu hallar üçün Athena mükəmməl uyğundur. Müntəzəm sorğular üçün belə bir sistem baha başa gəlir. Bu halda verilənləri hər hansı bir ixtisaslaşdırılmış həll yolu ilə cache-ləşdirin.
OLTP həlləri üçün Serverless
Öncəki misalda OLAP məsələləri (analitiklər) müzakirə olundu. İndi OLTP problemlərini nəzərdən keçirək.
Genişlənə bilən PostgreSQL və ya MySQL düşünək. Minimum resurslarla adi bir idarə olunan PostgreSQL və ya MySQL instansiyasını quraq. İnstanza daha çox yük gəldikdə, oxuma yükünü paylamaq üçün əlavə replikalar qoşacağıq. Əgər sorğu və yük yoxdursa, replikaları söndürəcəyik. İlk instans masterdir, qalanları isə replikalardır.
Bu fikir AWS-dəki Aurora Serverless adlı bazada reallaşdırılıb. Prinsip sadədir: xarici tətbiqlərdən gələn sorğular proxy floti tərəfindən qəbul edilir. Yük artımını gördükdə, o, əvvəlcədən hazırlanan minimum instanslardan hesablama resurslarını ayrır - qoşulma maksimum dərəcədə tez həyata keçirilir. Instansların söndürülməsi də eyni şəkildə baş verir.
Aurora çərçivəsində Aurora Capacity Unit (ACU) anlayışı mövcuddur. Bu (şərti olaraq) bir instansdır (server). Hər bir ACU master və ya slave ola bilər. Hər bir Capacity Unit öz əməliyyat yaddaşı, prosessoru və minimum diski ilə təchiz olunub. Buna görə, bir master, qalanları isə yalnız oxumaq üçün olan replikalardır.
Bu çalışan Aurora Capacity Units-in sayı tənzimlənən bir parametrdir. Minimum sayı bir və ya sıfır ola bilər (bu halda, sorğular olmadıqda, baza işləməz).
Baza sorğuları aldıqda, proxy floti Aurora Capacity Units-i işə salır, sistemin istehsal resurslarını artırır. Resursların artırılması və azaltılması imkanı sistemə resursları "juggling" etmək imkanı verir: müəyyən ACU-ları avtomatik olaraq çıxarmaq (onları yeniləri ilə əvəzləmək) və çıxarılan resurslara aktual yeniləmələri tətbiq etmək.
Aurora Serverless bazası oxuma yükünü genişləndirə bilir. Lakin sənədlər bunun birbaşa qeyd olunmadığını söyləyir. Multi-master qura bildikləri hissi yarana bilər. Əslində isə burada heç bir sehr yoxdur.
Bu baza, proqressiv erişim olan sistemlərə böyük pullar xərcləməmək üçün ideal seçimdir. Məsələn, MVP və ya marketinq üçün hazırlanan veb saytlar yaradarkən, adətən sabit yüklənmə gözləmirik. Müvafiq olaraq, əgər giriş olmazsa, instansiyalar üçün ödəniş etmirik. Məsələn, konfrans və ya reklam kampaniyasından sonra qəflətən yüklənmə yarandıqda, çoxlu insanlar veb sayta daxil olur və yük kəskin şəkildə artır. Aurora Serverless avtomatik olaraq bu yükü qəbul edir və çatışmayan resursları tez bir zamanda qoşur (ACU). Sonra konfrans bitir, hər kəs prototipi unudur, serverlər (ACU) işləmədən dayanar, və xərclər sıfıra düşür — bu, çox rahatdır.
Bu həll sabit yüksək yüklənmə üçün uyğun deyil, çünki o, yazma yükünü miqyaslandırmağı bacarmır. Bütün bu resursların qoşulması və söndürülməsi, tranzaksiya olmayan, müvəqqəti cədvəllərin əhatə edilmədiyi vaxtda baş verir — bu, ‘scale point’ adlanan zamandır. Məsələn, bir həftə ərzində scale point baş verməyə bilər və baza eyni resurslar üzərində işləyir, sadəcə olaraq genişlənə və ya daralmır.
Burada bir möcüzə yoxdur — bu, adi PostgreSQL-dir. Ancaq maşınların əlavə olunması və hissə-hissə söndürülməsi prosesi qismən avtomatlaşdırılmışdır.
Serverless by design
Aurora Serverless köhnə bir bazadır, buludlar üçün yenidən yazılmışdır ki, Serverless-in spesifik üstünlüklərindən istifadə edə bilsin. İndi isə sizinlə buludlar, serverless yanaşma üçün əvvəldən yazılmış bir bazadan, Serverless-by-design-dan danışacağam. O, fiziki serverlərdə işlədiyi gözlənilmədən inkişaf etdirilmişdir.
Bu bazanın adı Snowflake-dir. Onun üç əsas bloku var.
Birincisi — metadata bloku. Bu, təhlükəsizlik, metadata, tranzaksiyalar, sorgu optimallaşdırması ilə bağlı məsələləri həll edən sürətli in-memory xidmətidir (soldakı ilüstrasiyada).
İkincisi — hesablama üçün bir çox virtual hesablayıcı klasterdir (ilüstrasiyada — mavi dairələr toplusu).
Üçüncü blok — S3 əsaslı məlumat saxlama sistemidir. S3, AWS-dəki ölçüsüz obyekt saxlama yeridir, biznes üçün ölçüsüz Dropbox-a bənzəyir.
Gəlin, Snowflake-in necə işlədiyinə, soyuq başlanğıc vəziyyətini nəzərə alaraq baxaq. Yəni, baza mövcuddur, məlumatlar yüklənmişdir, aktiv sorğular yoxdur. Buna görə də, əgər bazaya sorğular daxil olmursa, o zaman sürətli in-memory Metadata xidməti (ilk blok) işə salınır. Və S3 anbarımız var, burada cədvəllərin məlumatları mikropartiyalara bölünmüşdür. Sadəcə izah etmək üçün: əgər cədvəldə ticarət əməliyyatları varsa, mikropartiyalar — bunlar əməliyyat günləridir. Hər bir gün — ayrı bir mikropartiya, ayrı bir fayldır. Və baza belə işlədiyi zaman, yalnız məlumatların tutduğu yer üçün ödəniş edirsiniz. Həmçinin, yer üçün tarif çox aşağıdır (xüsusilə əhəmiyyətli sıxma nəzərə alınmaqla). Metadata xidməti də daim işləyir, lakin sorğuların optimallaşdırılması üçün çox resurs tələb etmir, buna görə də xidmət şərti olaraq pulsuz sayılabilir.
İndi təsəvvür edək ki, istifadəçi bazaya daxil olub SQL sorğusu göndərdi. SQL sorğusu dərhal Metadata xidmətinə emal olunması üçün göndərilir. Buna görə də, sorğunu aldıqdan sonra bu xidmət, sorğunu, mövcud məlumatları, istifadəçi səlahiyyətlərini analiz edir və hər şey qaydasındadırsa, sorğunun icrası planını hazırlayır.
Sonra xidmət hesaplayıcı klasteri işə salmağı təşviq edir. Hesaplayıcı klaster — hesablamaları həyata keçirən serverlər klasteridir. Yəni, 1 server, 2 server, 4, 8, 16, 32 - istədiyiniz qədər serveri olan bir klasterdir. Sorğunu verirsiniz və o üçün dərhal bu klasterin işə salınması başlayır. Bu, həqiqətən də, saniyələrlə baş verir.
Sonra, klaster başlatıldıktan sonra, klastere S3'ten ihtiyaç duyulan mikro parçalar kopyalanmaya başlanır. Yani, SQL sorgusunun gerçekleştirilmesi için bir tablodan iki ve diğerinden bir parçaya ihtiyaç duyulduğunu varsayalım. Bu durumda, klastere yalnızca gerekli olan üç parça kopyalanır, tüm tablolar değil. Bu nedenle, her şeyin tek bir veri merkezi içinde bulunması ve çok hızlı bağlantılarla bağlanması nedeniyle, tüm veri aktarım süreci oldukça hızlı gerçekleşir: saniyeler içinde, nadiren dakikalar içinde, eğer korkunç sorgulardan bahsetmiyorsak. Dolayısıyla, mikro parçalar hesaplama klasterine kopyalanır ve tamamlandığında SQL sorgusu bu hesaplama klasterinde yürütülür. Bu sorgunun sonucu bir satır, birkaç satır veya bir tablo olabilir; bu sonuçlar kullanıcının BI aracında görüntüleyebilmesi veya başka şekillerde kullanabilmesi için dışarı gönderilir.
Her SQL sorgusu, yalnızca daha önce yüklenmiş verilerden toplama yapmaktan değil, aynı zamanda yeni verileri veritabanına yüklemekten/oluşturmaktan da sorumludur. Yani, bu başka bir tabloya yeni kayıtlar ekleyen bir sorgu olabilir; bu, hesaplama klasterine yeni bir parçanın eklenmesine neden olur ve bu parça tek bir S3 depolama alanında otomatik olarak kaydedilir.
Yukarıda tanımlanan senaryo, kullanıcının girişinden klasterin başlatılmasına, veri yüklemeye, sorguların gerçekleştirilmesine ve sonuçların alınmasına kadar olan süreç, sanal hesaplama klasterinin kullanım dakikası tarifesi üzerinden ücretlendirilir. Tarife, AWS bölgesine ve klasterin boyutuna göre değişir, ancak ortalama olarak saatte birkaç dolar civarındadır. Dört makineden oluşan bir klaster, iki makineden iki kat daha pahalıdır; sekiz makineden oluşan bir klaster ise iki kat daha pahalıdır. 16, 32 makine seçenekleri mevcuttur, sorguların karmaşıklığına göre. Ancak sadece klaster aktif çalıştığında, gerçekten çalıştığı dakikalarda ücret ödersiniz, çünkü sorgu olmadığında ellerinizi çekmiş oluyorsunuz ve 5-10 dakikalık bir bekleme süresinden sonra (ayar yapılabilir) kendiliğinden kapanıyor, kaynakları serbest bırakıyor ve ücretsiz hale geliyor.
Tam bir senaryo gerçekte mümkündür ki, bir sorgu gönderdiğinizde, küme bir dakika içinde ortaya çıkar, başka bir dakika hesaplama yapar, sonraki beş dakika boyunca kapatılması için bekler, ve sonuç olarak bu kümenin yalnızca yedi dakikasını ödemiş olursunuz, aylara ve yıllara değil.
İlk senaryo, Snowflake'in tek kullanıcı senaryosunu betimliyordu. Şimdi, çok sayıda kullanıcı olduğunu hayal edelim; bu, gerçek bir senaryoya daha yakındır.
Varsayalım ki, birçok analistimiz ve sürekli olarak veritabanımıza büyük sayıda basit analitik SQL sorgusu gönderen Tableau raporlarımız var.
Bunun dışında, verilerle muazzam işler yapmaya çalışan yaratıcı Veri Bilimcilerimiz olduğunu varsayalım; onlar on terabaytlarla işlem yapıyor, milyarlarca ve trilyonlarca satır veriyi analiz ediyorlar.
Yukarıda açıklanan iki yük türü için, Snowflake farklı kapasitede birkaç bağımsız hesaplama kümesi oluşturulmasına izin verir. Bu hesaplama kümeleri bağımsız olarak çalışır ancak ortak, tutarlı verilere sahiptir.
Büyük sayıda hafif sorgular için 2-3 küçük küme kurmak mümkündür; her biri iki makine boyutunda. Bu davranış, otomatik ayarlar ile de uygulanabilir. Yani, "Snowflake, küçük bir küme oluştur. Eğer üzerindeki yük belirli bir parametreden fazla artarsa, ikinci, üçüncü benzer bir küme oluştur. Yük azalmaya başladığında fazlalıkları kapat." diyebilirsiniz. Böylece, ne kadar çok analist gelirse gelsin, raporlara bakmaya başladığında, herkes kaynakların yeterli olmasını sağlar.
Analistler uyuyorsa ve raporları kimse görmüyorsa, kümeler tamamen kapanabilir ve onlara ödeme yapmayı bırakırsınız.
Bununla birlikte, veri bilimcilerden gelen ağır sorgular için, varsayımsal olarak 32 makineden oluşan tek bir büyük küme oluşturabilirsiniz. Bu küme de yalnızca devasa sorgunuzun çalıştığı dakikalar ve saatler için ödenecektir.
Yukarıda belirtilen yetenek, kümeleri yalnızca iki değil, daha fazla yük türü (ETL, izleme, raporların malzemeleştirilmesi, vb.) için ayırmanıza olanak tanır.
Snowflake haqqında qısa bir yekun edək. Bu baza gözəl bir ideya və işlək bir icraatı birləşdirir. ManyChat-da bütün məlumatlarımızın analitikası üçün Snowflake-dən istifadə edirik. Bizim 3 deyil, 5-dən 9-a qədər, müxtəlif ölçülərdə klasterlərimiz var. Şərti 16-maşınlı, 2-maşınlı klasterlərimiz var, həmçinin bəzi tapşırıqlar üçün super kiçik 1-maşınlı klasterlərimiz də mövcuddur. Onlar yükü müvəffəqiyyətlə bölüşdürür və bizə əhəmiyyətli dərəcədə qənaət etməyə imkan verir.
Baza oxuma və yazma yükünü müvəffəqiyyətlə miqyaslandirir. Bu, eyni zamanda "Aurora" ilə müqayisədə çox fərqli və böyük bir irəliləyişdir, çünki o yalnız oxuma yükünü davam etdirə bilirdi. Snowflake bu hesablama klasterləri ilə yazma yükünü də miqyaslamaya imkan tanıyır. Yəni, ManyChat-da istifadə etdiyimiz bir neçə klaster var, kiçik və super kiçik klasterlər əsasən ETL, məlumatların yüklənməsi üçün istifadə olunur. Analitiklər isə, ETL yükləməsindən tamamilə təsirlənməyən orta klasterlərdə yaşayır, buna görə də çox sürətlə işləyir.
Beləliklə, baza OLAP tapşırıqları üçün yaxşı uyğun gəlir. Lakin, təəssüf ki, OLTP yükləmələri üçün hələ də tətbiq edilə bilmir. Birincisi, bu baza sütun əsaslıdır, onun bütün nəticələri ilə. İkincisi, hər bir sorğuya ehtiyac olduqda hesablama klasterini qaldırmaq və onu məlumatlarla doldurmaq yanaşması, təəssüf ki, OLTP yükləmələri üçün hələ də kifayət qədər sürətli deyil. OLAP tapşırıqları üçün gözləmə saniyələri normaldır, amma OLTP tapşırıqları üçün qəbul edilən deyil; daha yaxşı olar ki, 100 ms, daha da yaxşısı — 10 ms.
Sonuç
Serverless baza məlumatları, bazanın Stateless və Stateful hissələrə bölünməsi sayəsində mümkündür. Verilən nümunələrdə Stateful hissənin, şərti olaraq, S3-də mikropartiyaların saxlanması olduğunu mütləq fərq etdiniz, Stateless isə optimizator, meta-məlumatlarla işləmək, müstəqil yüngül Stateful xidmətlər olaraq qaldırılan təhlükəsizlik məsələlərinin işlənməsidir.
SQL sorğularının icrası da serverless rejimdə müvəqqəti klasterlər kimi yüngül vəziyyətli xidmətlər olaraq başa düşülə bilər, lazım olan məlumatları yükləmək, sorğunu yerinə yetirmək və "söndürmək".
Serverless istehsalat səviyyəsində verilənlər bazaları artıq istifadəyə hazırdır, onlar işləyir. Bu serverless verilənlər bazaları OLAP tapşırıqları ilə məşğuldur. Təəssüf ki, OLTP tapşırıqları üçün tətbiq olunması... müəyyən çətinliklərlə bağlıdır, çünki məhdudiyyətlər var. Bir tərəfdən, bu mənfi haldır. Amma, digər tərəfdən, bu bir fürsətdir. Bəlkə də oxuculardan biri OLTP verilənlər bazasını tamamilə serverless şəkildə, Aurora-nın məhdudiyyətləri olmadan etmənin bir yolunu tapacaq.
Ümid edirəm, sizin üçün maraqlı oldu. Serverless gələcək üçün 🙂
Mənbə: habr.com
