Hamıya salam! Mənim adım Qolov Nikolaydır. Əvvəllər Avito-da işləmişəm və altı il Data Platformasını idarə etmişəm, yəni bütün verilənlər bazaları üzərində işləmişəm: analitik (Vertica, ClickHouse), axın və OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). Bu müddət ərzində mən çoxlu sayda verilənlər bazası ilə - çox fərqli və qeyri-adi və onlardan istifadənin qeyri-standart halları ilə məşğul oldum.
Mən hazırda ManyChat-da işləyirəm. Əslində, bu bir başlanğıcdır - yeni, iddialı və sürətlə böyüyən. Mən şirkətə ilk dəfə qoşulanda klassik sual yarandı: “Gənc startap indi DBMS və verilənlər bazası bazarından nə götürməlidir?”
Bu yazıda mənim hesabatım əsasında , bu suala cavab verim. Hesabatın video versiyasını buradan əldə etmək olar .
Ümumi məlumat bazaları 2020
2020-ci ildir, ətrafa baxdım və üç növ verilənlər bazası gördüm.
Birinci növ - klassik OLTP verilənlər bazası: PostgreSQL, SQL Server, Oracle, MySQL. Onlar uzun müddət əvvəl yazılmışdır, lakin hələ də aktualdır, çünki onlar tərtibatçılar cəmiyyətinə çox tanışdırlar.
İkinci növdür "sıfırdan" əsaslar. Onlar SQL-dən, ənənəvi strukturlardan və ACID-dən imtina edərək, daxili parçalanma və digər cəlbedici xüsusiyyətlər əlavə edərək klassik nümunələrdən uzaqlaşmağa çalışdılar. Məsələn, bu Cassandra, MongoDB, Redis və ya Tarantooldur. Bütün bu həllər bazara əsaslı şəkildə yeni bir şey təklif etmək istədi və müəyyən tapşırıqlar üçün son dərəcə əlverişli olduqları üçün öz yerlərini tutdular. Mən bu verilənlər bazalarını NOSQL çətir termini ilə işarələyəcəyəm.
“Sıfırlar” bitdi, biz NOSQL verilənlər bazalarına öyrəşdik və dünya mənim fikrimcə növbəti addımı atdı - idarə olunan verilənlər bazaları. Bu verilənlər bazaları klassik OLTP verilənlər bazası və ya yeni NoSQL verilənlər bazası ilə eyni nüvəyə malikdir. Lakin onların DBA və DevOps-a ehtiyacları yoxdur və buludlarda idarə olunan avadanlıqla işləyirlər. Tərtibatçı üçün bu, haradasa işləyən “sadəcə bazadır”, lakin onun serverdə necə quraşdırıldığı, serveri kimin konfiqurasiya etdiyi və onu kimin yenilədiyi heç kəsin vecinə deyil.
Belə verilənlər bazalarına nümunələr:
- AWS RDS PostgreSQL/MySQL üçün idarə olunan sarğıdır.
- DynamoDB, Redis və MongoDB kimi sənəd əsaslı verilənlər bazasının AWS analoqudur.
- Amazon Redshift idarə olunan analitik verilənlər bazasıdır.
Bunlar əsasən köhnə verilənlər bazalarıdır, lakin aparatla işləməyə ehtiyac olmadan idarə olunan mühitdə qaldırılır.
Qeyd. Nümunələr AWS mühiti üçün götürülüb, lakin onların analoqları Microsoft Azure, Google Cloud və ya Yandex.Cloud-da da mövcuddur.
Bunda nə yenilik var? 2020-ci ildə bunların heç biri.
Serversiz konsepsiya
2020-ci ildə bazarda həqiqətən yeni olan serversiz və ya serversiz həllərdir.
Bunun nə demək olduğunu adi bir xidmət və ya backend tətbiqi nümunəsi ilə izah etməyə çalışacağam.
Adi backend tətbiqini yerləşdirmək üçün biz server alırıq və ya icarəyə götürürük, kodu ona kopyalayırıq, son nöqtəni kənarda dərc edirik və icarə, elektrik enerjisi və məlumat mərkəzi xidmətləri üçün müntəzəm olaraq ödəyirik. Bu standart sxemdir.
Başqa yol varmı? Serversiz xidmətlərlə edə bilərsiniz.
Bu yanaşmanın əsas məqsədi nədir: server yoxdur, buludda virtual instansiyanın icarəsi belə yoxdur. Xidməti yerləşdirmək üçün kodu (funksiyaları) depoya köçürün və son nöqtədə dərc edin. Sonra biz sadəcə olaraq bu funksiyaya edilən hər zəng üçün ödəniş edirik, onun icra olunduğu aparatlara tamamilə məhəl qoymuruq.
Bu yanaşmanı şəkillərlə izah etməyə çalışacağam.
Klassik yerləşdirmə. Müəyyən bir yüklə xidmətimiz var. Biz iki nümunə qaldırırıq: fiziki serverlər və ya AWS-də nümunələr. Xarici sorğular bu instansiyalara göndərilir və orada emal olunur.
Şəkildə gördüyünüz kimi serverlər bərabər şəkildə atılmır. Biri 100% istifadə olunur, iki sorğu var, biri isə yalnız 50% - qismən boşdur. Üç deyil, 30 sorğu gəlsə, bütün sistem yükün öhdəsindən gələ bilməyəcək və yavaşlamağa başlayacaq.
Serversiz yerləşdirmə. Serversiz bir mühitdə belə bir xidmətin nümunələri və ya serverləri yoxdur. Qızdırılan resursların müəyyən bir hovuzu var - yerləşdirilmiş funksiya kodu ilə hazırlanmış kiçik Docker konteynerləri. Sistem xarici sorğuları qəbul edir və onların hər biri üçün serversiz çərçivə kodu olan kiçik bir konteyner qaldırır: bu xüsusi sorğunu emal edir və konteyneri öldürür.
Bir sorğu - bir konteyner qaldırıldı, 1000 sorğu - 1000 konteyner. Və hardware serverlərində yerləşdirmə artıq bulud provayderinin işidir. O, serversiz çərçivə tərəfindən tamamilə gizlədilir. Bu konsepsiyada biz hər zəng üçün pul ödəyirik. Məsələn, gündə bir zəng gəldi - bir zəng üçün ödədik, dəqiqədə bir milyon gəldi - bir milyon ödədik. Və ya bir saniyədə bu da olur.
Serversiz funksiyanın nəşri konsepsiyası vətəndaşlığı olmayan xidmət üçün uyğundur. Əgər sizə (dövlət) dövlət xidmətinə ehtiyacınız varsa, onda biz xidmətə verilənlər bazası əlavə edirik. Bu halda, vəziyyətlə işləməyə gəldikdə, hər bir statuslu funksiya verilənlər bazasından sadəcə yazır və oxuyur. Üstəlik, məqalənin əvvəlində təsvir olunan üç növdən hər hansı birinin verilənlər bazasından.
Bütün bu verilənlər bazalarının ümumi məhdudiyyəti nədir? Bunlar daim istifadə olunan bulud və ya hardware serverinin (və ya bir neçə serverin) xərcləridir. Klassik və ya idarə olunan verilənlər bazasından istifadə etməyimizin, Devops və adminimizin olub-olmamasının fərqi yoxdur, biz hələ də 24/7 avadanlıq, elektrik və məlumat mərkəzi icarəsi üçün ödəniş edirik. Klassik bazamız varsa, usta və qul üçün ödəyirik. Əgər bu, yüksək yüklənmiş bir verilənlər bazasıdırsa, biz 10, 20 və ya 30 server üçün ödəniş edirik və biz daim ödəyirik.
Xərc strukturunda daimi olaraq qorunan serverlərin olması əvvəllər zəruri pislik kimi qəbul edilirdi. Adi verilənlər bazalarının digər çətinlikləri də var, məsələn, bağlantıların sayına məhdudiyyətlər, miqyaslama məhdudiyyətləri, geo-paylanmış konsensus - onlar müəyyən verilənlər bazalarında bir şəkildə həll edilə bilər, lakin hamısı birdən deyil və ideal şəkildə deyil.
Serversiz verilənlər bazası - nəzəriyyə
2020-ci ilin sualı: verilənlər bazasını serversiz etmək mümkündürmü? Hər kəs serversiz backend haqqında eşitmişdir... gəlin verilənlər bazasını serversiz etməyə çalışaq?
Bu qəribə səslənir, çünki verilənlər bazası tam tam xidmətdir, serversiz infrastruktur üçün çox uyğun deyil. Eyni zamanda, verilənlər bazasının vəziyyəti çox böyükdür: gigabayt, terabayt, analitik məlumat bazalarında isə hətta petabayt. Onu yüngül Docker qablarında qaldırmaq o qədər də asan deyil.
Digər tərəfdən, demək olar ki, bütün müasir verilənlər bazaları böyük miqdarda məntiq və komponentləri ehtiva edir: əməliyyatlar, bütövlük koordinasiyası, prosedurlar, əlaqəli asılılıqlar və çoxlu məntiq. Kifayət qədər çox verilənlər bazası məntiqi üçün kiçik bir vəziyyət kifayətdir. Gigabayt və Terabayt sorğuların birbaşa icrasında iştirak edən verilənlər bazası məntiqinin yalnız kiçik bir hissəsi tərəfindən birbaşa istifadə olunur.
Müvafiq olaraq, ideya belədir: əgər məntiqin bir hissəsi vətəndaşsız icraata imkan verirsə, niyə bazanı Dövlət və Vətəndaşlığı olmayan hissələrə bölmək olmaz.
OLAP həlləri üçün serversiz
Gəlin praktiki nümunələrdən istifadə etməklə verilənlər bazasını Dövlət və Vətəndaşlığı olmayan hissələrə kəsmək necə görünə biləcəyinə baxaq.
Məsələn, bizim analitik məlumat bazamız var: xarici məlumatlar (solda qırmızı silindr), verilənlər bazasına məlumatları yükləyən ETL prosesi və verilənlər bazasına SQL sorğuları göndərən analitik. Bu klassik məlumat anbarı əməliyyat sxemidir.
Bu sxemdə ETL şərti olaraq bir dəfə yerinə yetirilir. Sonra verilənlər bazasının ETL ilə doldurulmuş məlumatlarla işlədiyi serverlər üçün daim ödəniş etməlisiniz ki, sorğu göndərmək üçün bir şey olsun.
AWS Athena Serverless-də həyata keçirilən alternativ yanaşmaya baxaq. Yüklənmiş məlumatların saxlandığı daimi xüsusi avadanlıq yoxdur. Bunun əvəzinə:
- İstifadəçi Athenaya SQL sorğusu təqdim edir. Athena optimallaşdırıcısı SQL sorğusunu təhlil edir və sorğunu yerinə yetirmək üçün lazım olan xüsusi məlumat üçün metadata anbarında (Metaməlumatlar) axtarış aparır.
- Toplanmış məlumatlar əsasında optimallaşdırıcı xarici mənbələrdən lazımi məlumatları müvəqqəti yaddaşa (müvəqqəti verilənlər bazası) yükləyir.
- İstifadəçidən gələn SQL sorğusu müvəqqəti yaddaşda yerinə yetirilir və nəticə istifadəçiyə qaytarılır.
- Müvəqqəti saxlama təmizlənir və ehtiyatlar buraxılır.
Bu arxitekturada biz yalnız sorğunun icrası prosesini ödəyirik. İstək yoxdur - xərc yoxdur.
Bu işlək yanaşmadır və təkcə Athena Serverless-də deyil, Redshift Spectrum-da (AWS-də) həyata keçirilir.
Athena nümunəsi göstərir ki, Serversiz verilənlər bazası onlarla və yüzlərlə Terabayt məlumatı olan real sorğular üzərində işləyir. Yüzlərlə terabayt üçün yüzlərlə server tələb olunacaq, lakin biz onlar üçün pul ödəməli deyilik - sorğular üçün ödəyirik. Vertica kimi xüsusi analitik verilənlər bazası ilə müqayisədə hər sorğunun sürəti (çox) aşağıdır, lakin biz dayanma müddətləri üçün ödəniş etmirik.
Belə verilənlər bazası nadir analitik ad-hoc sorğular üçün tətbiq edilir. Məsələn, biz kortəbii olaraq nəhəng miqdarda məlumat üzərində bir fərziyyəni sınamağa qərar verdiyimiz zaman. Athena bu hallar üçün mükəmməldir. Daimi sorğular üçün belə bir sistem bahalıdır. Bu halda, bəzi xüsusi həllərdə məlumatları keş edin.
OLTP həlləri üçün serversiz
Əvvəlki nümunə OLAP (analitik) tapşırıqlarına baxdı. İndi OLTP tapşırıqlarına baxaq.
Genişləndirilə bilən PostgreSQL və ya MySQL-i təsəvvür edək. Minimum resursla müntəzəm idarə olunan PostgreSQL və ya MySQL nümunəsini qaldıraq. Nümunə daha çox yük aldıqda, oxu yükünün bir hissəsini paylayacağımız əlavə replikaları birləşdirəcəyik. Heç bir sorğu və ya yük yoxdursa, replikaları söndürürük. Birinci instansiya master, qalanları isə replikadır.
Bu ideya Aurora Serverless AWS adlı verilənlər bazasında həyata keçirilir. Prinsip sadədir: xarici tətbiqlərdən gələn sorğular proxy donanması tərəfindən qəbul edilir. Yükün artdığını görən, o, əvvəlcədən isidilmiş minimal instansiyalardan hesablama resurslarını ayırır - əlaqə mümkün qədər tez həyata keçirilir. Nümunələrin söndürülməsi eyni şəkildə baş verir.
Aurora daxilində Aurora Tutum Birimi, ACU anlayışı var. Bu (şərti olaraq) bir nümunədir (server). Hər bir xüsusi ACU master və ya qul ola bilər. Hər bir tutum vahidinin öz RAM, prosessor və minimal diski var. Müvafiq olaraq, biri ustadır, qalanları yalnız oxunan replikalardır.
Çalışan bu Aurora Tutum Vahidlərinin sayı konfiqurasiya edilə bilən parametrdir. Minimum kəmiyyət bir və ya sıfır ola bilər (bu halda sorğular olmadıqda verilənlər bazası işləmir).
Baza sorğuları qəbul etdikdə, proxy donanması sistemin performans resurslarını artıraraq Aurora CapacityUnits-i artırır. Resursları artırmaq və azaltmaq imkanı sistemə resursları “həqq-hesab etməyə” imkan verir: avtomatik olaraq fərdi ACU-ları nümayiş etdirir (onları yeniləri ilə əvəz edir) və çıxarılan resurslara bütün cari yeniləmələri yayır.
Aurora Serverless bazası oxu yükünü genişləndirə bilər. Amma sənədlər bunu birbaşa demir. Onlar multi-master qaldıra biləcək kimi hiss edə bilər. Heç bir sehr yoxdur.
Bu verilənlər bazası gözlənilməz girişi olan sistemlərə böyük miqdarda pul xərcləməmək üçün yaxşı uyğundur. Məsələn, MVP və ya marketinq vizit kartı saytları yaradarkən biz adətən sabit yük gözləmirik. Müvafiq olaraq, giriş yoxdursa, nümunələr üçün ödəniş etmirik. Gözlənilməz yüklənmə baş verdikdə, məsələn, konfrans və ya reklam kampaniyasından sonra, izdiham sayta baş çəkdikdə və yük kəskin şəkildə artdıqda, Aurora Serverless bu yükü avtomatik olaraq götürür və çatışmayan resursları (ACU) tez birləşdirir. Sonra konfrans keçir, hamı prototipi unudur, serverlər (ACU) qaranlıqlaşır və xərclər sıfıra enir - rahat.
Bu həll sabit yüksək yükləmə üçün uyğun deyil, çünki yazı yükünü miqyaslandırmır. Resursların bütün bu əlaqələri və kəsilməsi "miqyas nöqtəsi" adlanan yerdə baş verir - verilənlər bazası əməliyyat və ya müvəqqəti cədvəllər tərəfindən dəstəklənmir. Məsələn, bir həftə ərzində miqyas nöqtəsi olmaya bilər və baza eyni resurslar üzərində işləyir və sadəcə genişlənə və ya daralda bilməz.
Heç bir sehr yoxdur - bu, adi PostgreSQL-dir. Amma maşınların əlavə edilməsi və onların ayrılması prosesi qismən avtomatlaşdırılıb.
Dizaynla serversiz
Aurora Serverless, Serverless-in bəzi üstünlüklərindən istifadə etmək üçün bulud üçün yenidən yazılmış köhnə verilənlər bazasıdır. İndi mən sizə serversiz yanaşma üçün əvvəlcə bulud üçün yazılmış baza haqqında danışacağam - Dizayna görə serversiz. Fiziki serverlərdə işləyəcəyi ehtimalı olmadan dərhal hazırlanmışdır.
Bu baza Snowflake adlanır. Onun üç əsas bloku var.
Birincisi metadata blokudur. Bu, təhlükəsizlik, metadata, əməliyyatlar və sorğuların optimallaşdırılması ilə bağlı problemləri həll edən sürətli yaddaşdaxili xidmətdir (soldakı təsvirdə göstərilir).
İkinci blok hesablamalar üçün virtual hesablama klasterləri dəstidir (şəkildə mavi dairələr dəsti var).
Üçüncü blok S3 əsasında verilənlərin saxlanması sistemidir. S3 AWS-də ölçüsiz obyekt saxlama yeridir, biznes üçün ölçüsiz Dropbox kimi.
Gəlin Snowflake-in soyuq başlanğıcı fərz edərək necə işlədiyini görək. Yəni verilənlər bazası var, ona məlumatlar yüklənir, işləyən sorğular yoxdur. Müvafiq olaraq, əgər verilənlər bazasına sorğular yoxdursa, biz sürətli yaddaşdaxili Metadata xidmətini (birinci blok) artırmışıq. Cədvəl məlumatlarının saxlandığı S3 yaddaşımız var, sözdə mikro bölmələrə bölünür. Sadəlik üçün: əgər cədvəldə əməliyyatlar varsa, mikrobölmələr əməliyyat günləridir. Hər gün ayrı bir mikrobölmə, ayrı bir fayldır. Və verilənlər bazası bu rejimdə işləyərkən, siz yalnız məlumatların tutduğu yer üçün ödəniş edirsiniz. Üstəlik, oturacaq başına nisbət çox aşağıdır (xüsusilə əhəmiyyətli sıxılma nəzərə alınmaqla). Metaməlumatlar xidməti də daim işləyir, lakin sorğuları optimallaşdırmaq üçün çoxlu resursa ehtiyacınız yoxdur və xidmət paylaşılan proqram hesab edilə bilər.
İndi təsəvvür edək ki, istifadəçi verilənlər bazamıza gəlib SQL sorğusu göndərib. SQL sorğusu emal üçün dərhal Metadata xidmətinə göndərilir. Müvafiq olaraq, sorğu qəbul edildikdən sonra bu xidmət sorğunu, mövcud məlumatları, istifadəçi icazələrini təhlil edir və hər şey qaydasındadırsa, sorğunun işlənməsi planını tərtib edir.
Bundan sonra xidmət hesablama klasterinin işə salınmasına başlayır. Hesablama klasteri hesablamaları yerinə yetirən serverlər toplusudur. Yəni bu, 1 server, 2 server, 4, 8, 16, 32 - istədiyiniz qədər ola bilən bir klasterdir. Siz sorğu göndərirsiniz və bu klasterin işə salınması dərhal başlayır. Bu, həqiqətən saniyə çəkir.
Sonra, klaster işə salındıqdan sonra sorğunuzu emal etmək üçün lazım olan mikrobölmələr S3-dən klasterə kopyalanmağa başlayır. Yəni, təsəvvür edək ki, SQL sorğusunu yerinə yetirmək üçün bir cədvəldən iki, ikincidən isə bir bölmə lazımdır. Bu halda, bütün cədvəllər tamamilə deyil, yalnız üç zəruri bölmə çoxluğa kopyalanacaq. Buna görə və dəqiq olaraq hər şey bir məlumat mərkəzində yerləşdiyinə və çox sürətli kanallarla bağlandığına görə, bütün ötürmə prosesi çox tez baş verir: saniyələr ərzində, çox nadir hallarda bir neçə dəqiqə ərzində, bəzi dəhşətli istəklərdən danışmırıqsa. Müvafiq olaraq, mikrobölmələr hesablama klasterinə kopyalanır və tamamlandıqdan sonra SQL sorğusu bu hesablama klasterində yerinə yetirilir. Bu sorğunun nəticəsi bir sətir, bir neçə sətir və ya cədvəl ola bilər - onlar istifadəçiyə xaricdən göndərilir ki, onu yükləyə, öz BI alətində göstərə və ya başqa şəkildə istifadə edə bilsin.
Hər bir SQL sorğusu yalnız əvvəllər yüklənmiş məlumatların aqreqatlarını oxuya bilməz, həm də verilənlər bazasında yeni məlumatları yükləyə/yara bilər. Yəni bu, məsələn, başqa cədvələ yeni qeydlər daxil edən sorğu ola bilər ki, bu da hesablama klasterində yeni bölmənin yaranmasına gətirib çıxarır və bu da öz növbəsində avtomatik olaraq tək S3 yaddaşında saxlanılır.
İstifadəçinin gəlişindən tutmuş klasterin qaldırılmasına, məlumatların yüklənməsinə, sorğuların yerinə yetirilməsinə, nəticələrin əldə edilməsinə qədər yuxarıda təsvir edilən ssenari, qaldırılmış virtual hesablama klasterindən, virtual anbardan istifadə dəqiqələrinə görə ödənilir. Məzənnə AWS zonasından və klaster ölçüsündən asılı olaraq dəyişir, lakin orta hesabla saatda bir neçə dollardır. Dörd maşından ibarət klaster iki maşından ibarət klasterdən iki dəfə bahadır, səkkiz maşından ibarət klaster isə hələ də iki dəfə bahadır. Müraciətlərin mürəkkəbliyindən asılı olaraq 16, 32 maşın variantları mövcuddur. Ancaq klaster həqiqətən işlədiyi zaman yalnız o dəqiqələr üçün ödəyirsiniz, çünki heç bir sorğu olmadıqda, bir növ əllərinizi çıxarırsınız və 5-10 dəqiqə gözlədikdən sonra (konfiqurasiya edilə bilən parametr) öz-özünə sönəcək, resursları azad edin və azad olun.
Tamamilə real ssenari budur ki, siz sorğu göndərdiyiniz zaman klaster açılır, nisbətən desək, bir dəqiqədən sonra o, daha bir dəqiqə hesablanır, sonra beş dəqiqə bağlanır və siz bu klasterin yeddi dəqiqəlik işləməsi üçün pul ödəyirsiniz və aylarla, illərlə deyil.
Snowflake-in tək istifadəçi şəraitində istifadə edilməsi təsvir edilən ilk ssenari. İndi təsəvvür edək ki, çoxlu istifadəçi var ki, bu da real ssenariyə daha yaxındır.
Deyək ki, verilənlər bazamızı çoxlu sayda sadə analitik SQL sorğuları ilə daim bombalayan çoxlu analitiklərimiz və Tableau hesabatlarımız var.
Bundan əlavə, deyək ki, verilənlərlə dəhşətli işlər görməyə çalışan, onlarla terabaytla işləyən, milyardlarla və trilyonlarla sıra verilənləri təhlil edən ixtiraçı Data Scientists var.
Yuxarıda təsvir olunan iki növ iş yükü üçün Snowflake sizə müxtəlif tutumlu bir neçə müstəqil hesablama klasterini yaratmağa imkan verir. Üstəlik, bu hesablama qrupları müstəqil işləyir, lakin ümumi ardıcıl məlumatlarla.
Çox sayda yüngül sorğular üçün hər biri təxminən 2 maşın olmaqla 3-2 kiçik klaster toplaya bilərsiniz. Bu davranış digər şeylər arasında avtomatik parametrlərdən istifadə etməklə həyata keçirilə bilər. Beləliklə, siz deyirsiniz: “Qar dənəciyi, kiçik bir çoxluq qaldır. Üzərindəki yük müəyyən bir parametrdən yuxarı qalxarsa, oxşar ikinci, üçüncü qaldırın. Yük azalmağa başlayanda artıqlığı söndürün”. Belə ki, nə qədər analitik gəlib hesabatlara baxmağa başlasa da, hamının kifayət qədər resursları var.
Eyni zamanda, analitiklər yuxudadırsa və hesabatlara heç kim baxmırsa, klasterlər tamamilə qaralana bilər və siz onlara pul ödəməyi dayandırırsınız.
Eyni zamanda, ağır sorğular üçün (Data Scientists-dən) 32 maşın üçün çox böyük bir klaster qaldıra bilərsiniz. Bu klaster yalnız nəhəng sorğunuz orada işlədiyi dəqiqələr və saatlar üçün ödəniləcək.
Yuxarıda təsvir edilən imkan sizə təkcə 2 deyil, həm də daha çox iş yükünü klasterlərə bölməyə imkan verir (ETL, monitorinq, hesabatın materiallaşdırılması,...).
Snowflake-i ümumiləşdirək. Baza gözəl ideyanı və işlək həyata keçirməyi özündə birləşdirir. ManyChat-da biz əlimizdə olan bütün məlumatları təhlil etmək üçün Snowflake-dən istifadə edirik. Nümunədəki kimi üç çoxluqumuz yoxdur, lakin müxtəlif ölçülü 5-dən 9-a qədər. Bəzi tapşırıqlar üçün adi 16 maşın, 2 maşın və həmçinin super kiçik 1 maşınlarımız var. Onlar yükü uğurla paylayır və bizə çox qənaət etməyə imkan verir.
Verilənlər bazası oxu və yazma yükünü uğurla ölçür. Bu, yalnız oxu yükünü daşıyan eyni "Aurora" ilə müqayisədə böyük fərq və böyük bir irəliləyişdir. Snowflake sizə bu hesablama qrupları ilə yazı iş yükünüzü genişləndirməyə imkan verir. Yəni qeyd etdiyim kimi biz ManyChat-da bir neçə klasterdən istifadə edirik, kiçik və super-kiçik klasterlər əsasən ETL üçün, məlumatların yüklənməsi üçün istifadə olunur. Və analitiklər artıq ETL yükündən tamamilə təsirlənməyən orta klasterlərdə yaşayırlar, buna görə də çox tez işləyirlər.
Müvafiq olaraq, verilənlər bazası OLAP tapşırıqları üçün yaxşı uyğun gəlir. Lakin təəssüf ki, bu, OLTP iş yükləri üçün hələ tətbiq olunmur. Birincisi, bu verilənlər bazası bütün sonrakı nəticələrlə sütunludur. İkincisi, yanaşmanın özü, hər bir sorğu üçün, lazım gələrsə, bir hesablama klasterini qaldırdığınızda və onu məlumatlarla doldurduğunuzda, təəssüf ki, OLTP yükləri üçün hələ kifayət qədər sürətli deyil. OLAP tapşırıqları üçün saniyə gözləmək normaldır, lakin OLTP tapşırıqları üçün bu qəbuledilməzdir; 100 ms daha yaxşı olardı və ya 10 ms daha yaxşı olardı.
Ümumi
Serversiz verilənlər bazası verilənlər bazasını Vətəndaşlığı olmayan və Vəziyyəti olmayan hissələrə bölmək yolu ilə mümkündür. Ola bilsin ki, siz qeyd etmişsiniz ki, yuxarıda göstərilən bütün nümunələrdə Stasionar hissə, nisbətən desək, S3-də mikro-arakəsmələri saxlayır, Vətəndaşsız isə optimallaşdırıcıdır, metadata ilə işləyir, müstəqil yüngül Vətəndaşlığı olmayan xidmətlər kimi qaldırıla bilən təhlükəsizlik məsələlərini həll edir.
SQL sorğularının icrası həm də Snowflake hesablama klasterləri kimi serversiz rejimdə açıla bilən, yalnız lazımi məlumatları endirən, sorğunu yerinə yetirən və “çıxıb” çıxan yüngül xidmətlər kimi qəbul edilə bilər.
Serversiz istehsal səviyyəli verilənlər bazaları artıq istifadə üçün mövcuddur, onlar işləyir. Bu serversiz verilənlər bazaları OLAP tapşırıqlarını idarə etməyə artıq hazırdır. Təəssüf ki, OLTP tapşırıqları üçün onlar istifadə olunur... nüanslarla, çünki məhdudiyyətlər var. Bir tərəfdən, bu bir mənfi cəhətdir. Ancaq digər tərəfdən, bu bir fürsətdir. Ola bilsin ki, oxuculardan biri Aurora məhdudiyyətləri olmadan OLTP verilənlər bazasını tamamilə serversiz etmək üçün bir yol tapacaq.
Ümid edirəm maraqlı tapdınız. Serversiz gələcəkdir :)
Mənbə: www.habr.com