Salam, Habr sakinləri. Adət olduğu kimi, yeni kursların başlamasından əvvəl maraqlı materialları paylaşmağa davam edirik. Bugün sizlər üçün, Google Cloud Spanner haqqında bir məqalə təqdim etdik və bu məqaləni kursun başlanması ilə əlaqələndirdik. .
İlk dəfə nəşr olunub .
Dünyanın hər yerində pərakəndə satışçılar, restoran sahibləri və onlayn satıcılar üçün bir çox bulud əsaslı POS həlləri təklif edən Lightspeed şirkəti, bir çox tranzaksiya, analitik və axtarış senariləri üçün bir neçə fərqli tip verilənlər bazası platforması istifadə edir. Bu verilənlər bazası platformalarının hər birinin öz güclü və zəif tərəfləri var. Buna görə də, Google, bazara Cloud Spanner təqdim edəndə - əlaqəli verilənlər bazalarında görünməmiş vəd olunan funksiyalarla, məsələn, faktiki olaraq sonsuz üfüqi miqyaslanma və 99.999% xidmət səviyyəsi sazişi (SLA) ilə - bunu əlimizə almaq imkanı əldən vermək istəmədik!
Cloud Spanner ilə təcrübəmizi və istifadə etdiyimiz qiymətləndirmə meyarlarını əhatəli bir şəkildə təqdim etmək üçün aşağıdakı mövzuları ələ alacağıq:
- Qiymətləndirmə meyarlarımız
- Cloud Spanner haqqında qısa məlumat
- Qiymətləndirməmiz
- Nəticələrimiz
1. Qiymətləndirmə meyarlarımız
Cloud Spanner-in xüsusiyyətlərinə, bazardakı digər həllərlə bənzərliklərinə və fərqlərinə dərindən baxmadan əvvəl, gəlin əvvəlcə Cloud Spanner-i öz infrastrukturumuza yerləşdirmək barədə düşünərkən nəzərə aldığımız əsas istifadə senarilərindən bəhs edək:
- Mövcud ənənəvi SQL verilənlər bazası həllinin əvəzi kimi
- OLTP və OLAP dəstəyi olan bir həll olaraq
Qeyd: Müqayisəni asanlaşdırmaq üçün bu məqalə Cloud Spanner-i GCP Cloud SQL və Amazon AWS RDS-nin MySQL variantları ilə müqayisə edir.
Cloud Spanner-i ənənəvi SQL verilənlər bazası həllinin əvəzi kimi istifadə etmək
Mühitdə ənənəvi verilənlər bazaları, verilənlər bazasına sorğunun cavab müddəti əvvəlcədən müəyyən edilmiş tətbiq həddindən yaxınlaşdığında və ya hətta onu aşdığında, cavab müddətini qəbul edilən səviyyələrə endirmək üçün bir neçə yol var. Lakin, bu həllərin əksəriyyəti manuel müdaxiləni tələb edir.
Məsələn, ilk addım verilənlər bazası ilə bağlı performansa aid müxtəlif parametrlərə baxmaq və onları tətbiq senarilərinin istifadə şablonlarına ən yaxşı uyğunlaşacaq şəkildə konfiqurasiya etməkdir. Əgər bu kifayət etməsə, verilənlər bazasını şaquli və ya üfüqi miqyaslama seçilə bilər.
Tətbiqin şaquli miqyaslandırılması adətən server instansiyasının yenilənməsini, daha çox prosessor/nüvə, daha çox əməli yaddaş, daha sürətli saxlama əlavə etməklə həyata keçirilir. Daha çox aparat resurslarının əlavə olunması, əsasən saniyədə tranzaksiyalarla və OLTP sistemləri üçün tranzaksiya gecikməsi ilə ölçülən verilənlər bazasının performansını artırır. MySQL kimi çox ipli yanaşmadan istifadə edən rekursiv verilənlər bazası sistemləri yaxşı şaquli şəkildə miqyaslana bilir.
Bu yanaşmanın bir neçə çatışmazlığı var, amma ən açıqı bazarda serverin maksimum ölçüsüdür. Ən böyük server instansiyasının hüdudlarına çatdıqda, yalnız bir yol qalır: üfüqi miqyaslandırma.
Üfüqi miqyaslaşdırma, klasterə əlavə serverlərin əlavə edilməsi ilə, ideya olaraq server sayının artırılması ilə xətti şəkildə performansı artırmaqdır. Əksər ənənəvi verilənlər bazası sistemləri üfüqi olaraq pis miqyaslanır və ya ümumiyyətlə miqyaslana bilmir. Məsələn, MySQL oxu əməliyyatları üçün köməkçi oxucu əlavə etməklə üfüqi miqyaslana bilsə də, yazma əməliyyatları üçün üfüqi miqyaslana bilmir.
Digər tərəfdən, Cloud Spanner-in təbiəti sayəsində minimal müdaxilə ilə üfüqi olaraq asanlıqla miqyaslana bilər.
Tam funksional DBMS xidmət olaraq fərqli istiqamətlərdən qiymətləndirilməlidir. Bir əsas olaraq, buludda ən populyar DBMS-ni götürdük — Google üçün GCP Cloud SQL və Amazon üçün AWS RDS. Qiymətləndirməmizdə aşağıdakı kateqoriyalara fokuslandıq:
- Xüsusiyyətlərin müqayisəsi: SQL əhatəsi, DDL, DML; bağlantı kitabxanaları/konnektorlar, tranzaksiya dəstəyi və s.
- İnkişaf dəstəyi: inkişaf və test üçün asanlıq.
- Adminstrasiya dəstəyi: instansiyaların idarə edilməsi — məsələn, yuxarı/aşağı miqyaslandırma və instansiyaların yüksəldilməsi; SLA, ehtiyat nüsxə və bərpa; təhlükəsizlik/ giriş kontrolu.
Cloud Spanner-in OLTP dəstəyi ilə OLAP həll kimi istifadəsi
Hərçənd ki, Google açıqca bildirir ki, Cloud Spanner analitik işləmə üçün nəzərdə tutulmayıb, o, Apache Impala & Kudu və YugaByte kimi digər mexanizmlərlə bəzi atributları paylaşır ki, bunlar OLAP iş yükü üçün nəzərdə tutulub.
Cloud Spanner-in sərfəli üfüqi miqyaslana bilən HTAP (hibrid tranzaksiya/analitik işləmə) motorunu (bir növ) istifadəyə yararlı OLAP xüsusiyyət toplusu ilə birləşdirmək ehtimalının yalnız az bir şansı olsaydı belə, bunun diqqətimizi cəlb etməyə dəyər olduğunu düşünürük.
Bu nəzərə alaraq, aşağıdakı kateqoriyaları araşdırdıq:
- Məlumatların yüklənməsi, indekslər və partionlaşdırma dəstəyi
- Sorğuların və DML-in performansı
2. Cloud Spanner haqqında qısa məlumat
Google Spanner, Google-in bir neçə öz xidmətində istifadə etdiyi klasterli relasiyalı verilənlər bazası idarəetmə sistemidir (RDBMS). Google, 2017-ci ilin əvvəlində, bunu Google Cloud Platform istifadəçiləri üçün açıq elan etdi.
Cloud Spanner-in bəzi atributları:
- Yüksək uyğunluğa malik, genişlənə bilən klaster RDBMS: məlumatların uyğunluğunu təmin etmək üçün vaxtın avadanlıq sinxronizasiyasını istifadə edir.
- Çarpaz stol trasaksiyalarının dəstəyi: trasaksiyalar bir neçə stolu əhatə edə bilər - yalnız bir stolla məhdudlaşma tələb olunmur (Apache HBase və ya Apache Kudu-dan fərqli olaraq).
- Birincil açar əsasında cədvəllər: bütün cədvəllərin bir bəyan edilmiş birincil açarı (BA) olmalıdır, bu da cədvəl sütunlarından bir neçəsindən ibarət ola bilər. Cədvəl məlumatları BA sırasına görə saxlanılır, bu da BA-ya görə axtarışı olduqca səmərəli və sürətli edir. BA əsasında olan digər sistemlərdə olduğu kimi, həyata keçirilmə, əvvəlcədən düşünülmüş istifadə hallarını nəzərə almaqla modelləşdirilməlidir ki, bu da .
- Alternativ cədvəllər: cədvəllər bir-birinə fiziki asılılıqlar ola bilər. Uşaq cədvəlinin sətirləri valideyn cədvəlindəki sətirlərlə əlaqələndirilə bilər. Belə bir yanaşma, müştərilərin və onların hesab-fakturalarının bir arada yerləşdirilməsi kimi, məlumatların modelləşdirilməsi mərhələsində müəyyən edilə biləcək münasibətləri axtarışı sürətləndirir.
- İndeks: Cloud Spanner ikincil indekslərə dəstək verir. İndeks, indekslənmiş sütunlardan və BA-nın bütün sütunlarından ibarətdir. Arzuladığınız halda, indeks eyni zamanda digər indekslənməmiş sütunları da əhatə edə bilər. İndeks, sorğuları sürətləndirmək üçün valideyn cədvəli ilə bir arada ola bilər. İndekslərə, indeksdə saxlanılan əlavə sütunların maksimum sayı kimi bir neçə məhdudiyyət tətbiq olunur. Eyni zamanda, indekslərdən keçən sorğular, digər RDBMS-lərdə olduğu kimi, o qədər də düz olmaya bilər.
«Cloud Spanner, yalnız nadir hallarda indeksi avtomatik seçir. Xüsusilə, Cloud Spanner, sorğu hansısa sütunları sorğuladıqda ikincil indeksini avtomatik seçmir, bu sütunlar indeksdə saxlanmır. ».
- Xidmət səviyyəsi razılaşması (SLA): 99,99% SLA ilə bir bölgədə, 99,999% SLA ilə çox bölgəli yerləşmələr. Hərçənd ki, xidmət səviyyəsi razılaşması yalnız bir razılaşmadır, heç bir təminat deyil, mən düşünürəm ki, Google əməkdaşlarının belə ciddi bir iddia etmək üçün həqiqətən də dəqiq məlumatları var. (İstinad üçün, 99,999% deməkdir ki, ayda 26,3 saniyə xidmətin əlçatmaz olmasıdır.)
- Daha çox:
Qeyd: Apache Tephra layihəsi Apache HBase-a (indi Apache Phoenix-də beta versiyası olaraq tətbiq edilmişdir) genişləndirilmiş tranzaksiyaların dəstəyini əlavə edir.
3. Bizim qiymətləndirməmiz
Beləliklə, Google-un Cloud Spanner-in üstünlükləri barədəki bəyannamələrini oxumuşuq — yüksək konsistensiyanı və çox yüksək SLA-ni qoruyaraq demək olar ki, limitsiz üfiqi genişlənmə. Bu tələbləri heç bir halda yerinə yetirmək olduqca çətindir, amma məqsədimiz onları təkzib etmək deyildi. Bunun əvəzinə gəlin daha çox verilənlər bazası istifadəçilərini narahat edən digər məsələlərə yönlənək: konsistensiya və istifadənin rahatlığı.
Cloud Spanner-i Sharded MySQL-ın əvəzi kimi qiymətləndirdik
Google Cloud SQL və Amazon AWS RDS, bulud bazarında iki ən populyar OLTP DB-dir, olduqca geniş xüsusiyyətlər toplusuna malikdir. Lakin bu verilənlər bazalarını bir düyün ölçüsündən kənara genişləndirmək üçün tətbiq parçalanmasını həyata keçirməlisiniz. Bu yanaşma, özü də tətbiqetmə və idarəetmə üçün əlavə çətinlik yaradır. Spanner-in bir neçə seqmenti bir instansiya birləşdirmə senaryosuna necə daxil olduğunu və hansı xüsusiyyətlərdən (əgər varsa) imtina etməli olacağımızı araşdırdıq.
SQL, DML və DDL dəstəyi, eləcə də konnektor və kitabxanalar?
Birinci, hansısa verilənlər bazası ilə başladığınızda, məlumat modeli yaratmalısınız. JDBC Spanner-i sevdiyiniz SQL alətinə qoşmağı düşünürsünüzsə, onunla məlumatlarınızı sorğulaya biləcəyinizi, lakin cədvəl yaratmaq və dəyişdirmək (DDL) və ya hər hansı insert/update/delete (DML) əməliyyatlarını yerinə yetirmək üçün istifadə edə bilməyəcəyinizi görəcəksiniz. Google-un rəsmi JDBC-sı nə DDL-ni, nə də DML-i dəstəkləyir.
«Hazırda sürücülər DML və ya DDL əmrlərini dəstəkləmir».
Spanner sənədləri
GCP konsolunda vəziyyət daha yaxşı deyil — yalnız SELECT sorğuları göndərə bilərsiniz. Xoşbəxtlikdən, tranzaksiyaları əhatə edən DML və DDL dəstəyi olan bir icma JDBC sürücüsü mövcuddur. . Bu sürücü son dərəcə faydalıdır, lakin Google-dan öz JDBC sürücüsünün olmaması təəccüblüdür. Xoşbəxtlikdən, Google müştəri kitabxanalarının (gRPC bazasında) geniş dəstəyini təqdim edir: C#, Go, Java, node.js, PHP, Python və Ruby.
Cloud Spanner-in özelleştirilmiş API-lərinin istifadəsi (JDBC-də DDL və DML-in olmaması səbəbindən) əlaqəli kod sahələri üçün bəzi məhdudiyyətlərə səbəb olur, məsələn, əlaqə havuzları və verilənlər bazası bağlama çərçivələri (məsələn, Spring MVC). Adətən, JDBC istifadə edərkən, əla test edilmiş və yaxşı işləyən sevdiyiniz əlaqə havuzunu (məsələn, HikariCP, DBCP, C3PO və s.) sərbəst seçə bilərsiniz. Xüsusi API Spanner ilə, özümüz yaratdığımız çərçivələr/havuzlar/istinadlar üzərinə etibar etməliyik.
Primar açar (PA) ilə yönəldilmiş konstruksiya, Cloud Spanner-ı PA vasitəsilə verilənlərə sürətli erişim təmin etməklə yanaşı, bəzi sorğularla bağlı problemlərə də gətirib çıxarır.
- Primar açar dəyərini yeniləyə bilməzsiniz; əvvəlcə orijinal PA ilə qeydi silməli və yeni dəyər ilə onu yenidən daxil etməlisiniz. (Bu, digər PA-yönümlü verilənlər bazaları / saxlama mexanizmlərinə bənzəyir.)
- Hər hansı bir UPDATE və DELETE operatoru WHERE-də PA göstərməlidir, buna görə də boş DELETE all operatorları ola bilməz — həmişə bir sub-sorğu olmalıdır, məsələn: UPDATE xxx WHERE id IN (SELECT id FROM table1)
- Avtomatik artırma seçiminin olmaması və ya PA sahəsi üçün sıralama edən bir şey. Bunun işləməsi üçün müvafiq dəyər tətbiq tərəfində yaradılmalıdır.
İkincil indekslər?
Google Cloud Spanner ikincil indekslərin daxili dəstəyinə malikdir. Bu, digər texnologiyalarda hər zaman mövcud olmayan çox yaxşı bir xüsusiyyətdir. Apache Kudu hal-hazırda ikincil indeksləri tamamilə dəstəkləmir, Apache HBase isə indeksləri birbaşa dəstəkləmir, lakin onları Apache Phoenix ilə əlavə edə bilər.
Kudu və HBase-də indekslər, müxtəlif PA-ların tərkibi ilə ayrılmış cədvəl olaraq modelləşdirilə bilər, lakin ana cədvəl və əlaqəli indeks cədvəlləri ilə aparılan əməliyyatların atomikliyi tətbiq səviyyəsində həyata keçirilməli və düzgün icra olunma üçün mürəkkəbdir.
Cloud Spanner-in tövsiyəsində qeyd edildiyi kimi, onun indeksləri MySQL indekslərindən fərqlənə bilər. Buna görə də, sorğuları qurarkən və profil qurarkən ehtiyatlı olmalısınız ki, lazım olan yerdə müvafiq indeksdən istifadə edilsin.
Görünüşlər?
Verilənlər bazasında çox məşhur və faydalı bir obyekt - görünüşlər. Onlar çoxsaylı istifadə hallarına faydalı ola bilər; iki sevimlim - məntiqi abştraksiya səviyyəsi və təhlükəsizlik səviyyəsidir. Təəssüf ki, Cloud Spanner görünüşləri DƏSTƏKLEMİR. Ancaq bu, bizə yalnız qismən məhdudiyyət qoyur, çünki giriş icazələri üçün sütun səviyyəsində detal yoxdur, burada görünüşlər münasib bir həll ola bilər.
Cloud Spanner-in sənədlərində kvotlar və məhdudiyyətlər haqqında ətraflı məlumat verən hissədə () xüsusi ilə, bəzi tətbiqlər üçün problemli ola biləcək bir məhdudiyyət var: Cloud Spanner-da standart olaraq maksimum 100 verilənlər bazası bir instansiya üzrə məhduddur. Aydındır ki, bu, 100-dən çox verilənlər bazasında genişləndirilmiş bir verilənlər bazası üçün ciddi əngəl ola bilər. Xoşbəxtlikdən, Google-un texniki nümayəndəsiylə danışdıqdan sonra, bu limitin Google dəstəyi vasitəsilə demək olar ki, hər hansı bir dəyərə qaldırıla biləcəyini öyrəndik.
İnkişaf dəstəyi?
Cloud Spanner, API ilə işləmək üçün xeyli dərəcədə yaxşı proqramlaşdırma dilləri dəstəyi təklif edir. Rəsmi dəstəklənən kitabxanalar C#, Go, Java, node.js, PHP, Python və Ruby sahələrindədir. Sənəd hazırlanması kifayət qədər detallıdır, amma digər qabaqcıl texnologiyalarla olduğu kimi, icma daha populyar məlumat bazası texnologiyaları ilə müqayisədə olduqca kiçikdir, bu da daha az yayılmış istifadə halları və ya problemlərin həllinə daha çox vaxt sərf etməyə səbəb ola bilər.
Bəs lokal inkişaf dəstəyi necədir?
Biz lokaldakı mühitdə Cloud Spanner instansiyasını yaratmağın yolunu tapmadıq. Aldığımız ən yaxın şey - Docker görüntüsüdür. , bu prinsipcə bənzəyir, amma praktikada çox fərqlidir. Məsələn, CockroachDB PostgreSQL JDBC-dən istifadə edə bilər. İnkişaf mühiti iş mühitinə mümkün qədər yaxın olmalıdır, Cloud Spanner ideal deyil, çünki tam Spanner instansiyasına etibar etmək lazımdır. Xərcləri azaltmaq üçün tək bir bölgə üçün instansiya seçə bilərsiniz.
Administrasiya dəstəyi necədir?
Cloud Spanner instansiyası yaratmaq çox asandır. Yalnız çox bölgəli və ya tək bölgə instansiyası arasında seçim etmək, bölgə (lər) və düyün sayı göstərmək lazımdır. Bir dəqiqədən az bir müddətdə instansiya fəaliyyətə başlayacaq və işə hazır olacaq.
Bir neçə sadə metriklər birbaşa Google konsolundakı Spanner səhifəsində mövcuddur. Daha ətraflı görüntülər Stackdriver vasitəsilə mövcuddur, burada metriqlər üçün hədd dəyərlərini və xəbərdarlıq siyasətlərini də təyin edə bilərsiniz.
Resurslara giriş?
MySQL geniş və çox detallı icazələr / istifadəçi rollarının tənzimlənməsini təklif edir. Müəyyən bir cədvələ və ya hətta onun sütunlarının yalnız bir alt dəstəsinə asanlıqla giriş təyin edə bilərsiniz. Cloud Spanner, çox yüksək səviyyədə siyasətləri və icazələri təyin etməyə imkan verən Google Identity & Access Management (IAM) vasitəsini istifadə edir. Ən detalı variant isə, əksər istehsal halları üçün uyğun gəlməyən verilənlər bazası səviyyəsində icazədir. Bu məhdudiyyət, Spanner resurslarının icazəsiz istifadəsini qarşısını almaq üçün kodunuza, infrastrukturunuza və ya hər ikisinə əlavə təhlükəsizlik tədbirləri əlavə etməyə məcbur edir.
Ehtiyat nüsxələr?
Sadə dillə desək, Cloud Spanner-da ehtiyat nüsxələri yoxdur. Google-un yüksək SLA tələbləri avadanlıq və ya verilənlər bazası qəzası səbəbindən məlumatların itirilməyəcəyini təmin edə bilər, amma insan xətaları, tətbiq qüsurları və s. kimi digər səbəblərdən yox. Hamımızın bildiyi bir qayda var: yüksək mövcudluq müvafiq ehtiyat nüsxə strategiyasını əvəz etmir. Hazırda verilənlərin ehtiyat nüsxəsini çıxarmağın tək yolu onları verilənlər bazasından ayrı bir saxlama mühitinə proqram vasitəsilə axıdmaqdır.
Sorğuların məhsuldarlığı?
Verilənləri yükləmək və sorğuları test etmək üçün Yahoo! Cloud Serving Benchmark-dan istifadə etdik. Aşağıdakı cədvəldə YCSB-nin iş yükü 95% oxuma və 5% yazma nisbəti ilə təqdim olunub.
* Yük testləri n1-standard-32 (32 vCPU, 120 GB RAM) hesablama mühərrikində (CE) icra edilib və test instansı testlərdə heç vaxt dar boğaz olmayıb.
** YCSB nümunəsindəki maksimum iplik sayı 400-dür. Cəmi 2400 iplik əldə etmək üçün altı paralel YCSB test instansiyasını işə salmaq lazım idi.
Test nəticələrinə baxarkən, xüsusilə CPU yükü və TPS kombinasyonunu nəzərə alaraq, Cloud Spanner-in kifayət qədər yaxşı ölçülən canlanma qabiliyyəti olduğunu görürük. Daha çox ipliklərin yaratdığı artıqlama, Cloud Spanner klasterindəki daha çox nodelarla kompensasiya edilir. 2400 iplikdən istifadə edərkən gecikmə nisbətən yüksək görünsə də, daha dəqiq nəticələr əldə etmək üçün 6 daha kiçik hesablama mühərriki ilə test etməyə ehtiyac ola bilər. Hər bir nümunə bir YCSB testini işə salacaq, bunun əvəzinə altı paralel testlərlə bir böyük CE instansı. Beləliklə, Cloud Spanner-in sorğu gecikmələrini və testin icra edildiyi CE instansı ilə Cloud Spanner arasındakı şəbəkə bağlantısının əlavə etdiyi gecikmələri asanlıqla ayırd etmək mümkün olacaq.
Cloud Spanner OLAP olaraq necə fəaliyyət göstərir?
Partisiya?
Verilənlərin fiziki və ya məntiqi müxtəlif parçalara ayrılması, partisiya adlanan çox populyar bir konsepsiyadır və sakinlərinin əksəriyyətində müşahidə olunur. Partisiya sorğuların məhsuldarlığını və verilənlər bazasının saxlanmasını əhəmiyyətli dərəcədə artırır. Partisiya məsələsinə dərinləşmək ayrıca bir məqalə (məqalələr) tələb edər, ona görə də sadəcə seqmentasiya və alt-partisiya sisteminin əhəmiyyətini qeyd edək. Verilənləri partisiya və hətta alt-partisiya etmək imkanı analitik sorğuların məhsuldarlığı üçün kilid rolunu oynayır.
Cloud Spanner partisiya sistemlərini dəstəkləmir. O, daxilində verilənləri, yəni split-lər əsas açar aralığından. Bulud Spanner klasterində yük balanslaşdırılması üçün avtomatik bölmələr aparılır. Bulud Spanner-in çox faydalı xüsusiyyəti ana cədvəlin (digər cədvəllərlə bölünməyən cədvəl) əsas yükünün bölünməsi dir. Spanner avtomatik olaraq müəyyən edir ki, split məlumatlar digər məlumatlardan daha tez-tez oxunur split-lər, və əlavə bölünmə qərarı qəbul edə bilər. Beləliklə, sorğuda daha çox node istifadə oluna bilər, bu da effektiv şəkildə bant genişliyini artırır.
Məlumat yükləmə?
Bulud Spanner-in böyük məlumatlar üçün yükləmə metodu adi yükləmə ilə eynidir. Maksimum performans əldə etmək üçün bəzi tövsiyələrə əməl etməlisiniz, o cümlədən:
- Verilərinizi əsas açara görə sıralayın.
- Onları 10*node sayına ayrı-seçkilik hissələrə bölün.
- Veriləri paralel yükləyən iş tapşırıqları yaradın.
Bu cür məlumat yükləməsi Bulud Spanner-in bütün node-larını istifadə edir.
10M satırdan ibarət məlumat dəstini yaratmaq üçün A YCSB iş yükündən istifadə etdik.
* Yük testi n1-standard-32 (32 vCPU, 120 GB RAM) hesablama mühərrikində icra edildi və test instansı testlərdə heç vaxt məhdudiyyət olmadı.
** 1 node-lu konfiqurasiya hər hansı istehsal yükü üçün tövsiyə edilmir.
Yuxarıda qeyd edildiyi kimi, Bulud Spanner avtomatik olaraq yükə görə split-ləri idarə edir, buna görə nəticələr bir neçə ardıcıl test təkrarı sonrası yaxşılaşır. Burada təqdim olunan nəticələr bizim əldə etdiyimiz ən yaxşı nəticələrdir. Yuxarıdakı ədədlərə baxarkən, Bulud Spanner-in node-ların klasterdə sayının artması ilə necə düzgün ölçülüdür (yaxşı) görünür. Vurğulanan ədədlər, qarışıq iş yükü nəticələri ilə müqayisədə (oxuma üçün 95% və yazma üçün 5%) son dərəcə aşağı orta gecikmələri təmsil edir.
Ölçülmə?
Bulud Spanner-in node sayını artırmaq və azaltmaq bir kliklə həyata keçirilən bir tapşırıqdır. Əgər məlumatları tez yükləmək istəyirsinizsə, instansı maksimuma (bizim halımızda ABŞ-ŞƏRQ regionunda 25 node) qədər artırmağı düşünə bilərsiniz, sonra isə bütün məlumatlar verilənlər bazasına daxil olduqdan sonra gündəlik yükgə uyğun bir node sayı azalda bilərsiniz, 2 TB/node məhdudiyyətini nəzərə alaraq.
Bunun məhdudiyyətini daha kiçik verilənlər bazasıyla da xatırlatdılar. Bir neçə yük test keçirdikdən sonra bizim verilənlər bazası təxminən 155 GB ölçüsündə idi və bir node-lu instansa azaldıqda, aşağıdakı xətanı aldıq:
25-dən 2 instansa qədər ölçülməyi bacardıq, amma iki node-da qaldıq.
Cloud Spanner-də düyün sayını artırmaq və azaltmaq REST API vasitəsilə avtomatlaşdırıla bilər. Bu, xüsusilə pik saatlarda sistemdəki yükü azaltmaq üçün faydalı ola bilər.
OLAP sorğularının performansı?
Başlanğıcda, Spanner-in bu hissəsini qiymətləndirməyə əhəmiyyətli vaxt ayırmağı planlaşdırırdıq. Bir neçə SELECT COUNT-dan sonra dərhal anladıq ki, testlər qısa olacaq və Spanner OLAP mühərriki üçün uyğun olmayacaq. Klasterdəki düyünlərin sayından asılı olmayaraq, 10M sətirdən ibarət bir cədvəldə sətir sayını seçmək 55-60 saniyə çəkdi. Həmçinin, kəsirli nəticələri saxlamaq üçün daha çox yaddaş tələb edən hər hansı bir sorğu OOM səhvi ilə başa çatdı.
SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M fərqli dəyər) -> SpoolingHashAggregateIterator yeni satır yaradarkən yaddaşdan çıxdı.
TPC-H sorğuları üçün bəzi rəqəmləri Todd Lipkonun məqaləsində tapa bilərsiniz. , slaydlar 42 və 43. Bu rəqəmlər bizim öz nəticələrimizlə uyğun gəlir (təəssüf ki).
4. Nəticələrimiz
Cloud Spanner-in indiki xüsusiyyətləri ilə hesab edildikdə, onun mövcud OLTP həllinin sadə əvəzləyicisi kimi təsəvvür etmək çətindir, xüsusən də tələbləriniz ona doğru genişlənəndə. Cloud Spanner-in çatışmazlıqlarını nəzərə alaraq bir həll qurmağa əhəmiyyətli vaxt sərf etmək lazımdır.
Cloud Spanner-i qiymətləndirməyə başladığımızda, onun idarəetmə xüsusiyyətlərinin digər Google SQL həlləri ilə eyni səviyyədə olacağını gözləyirdik. Lakin, tamamilə ehtiyat nüsxələrinin olmaması və resurslara çox məhdud girişin olması bizi təəccübləndirdi. Görmə sahələrinin olmaması, yerli inkişaf mühitinin olmaması, dəstəklənməyən sıralar, DML və DDL dəstəyi olmayan JDBC və sair barədə danışmıram.
Bəs transaksion verilənlər bazasını genişləndirmək lazım olan kəs kimin üçün nə etmək olar? Görünür, bazarda hər şeydən istifadə üçün uyğun olan tək bir həll yoxdur. Bu məqalədə bəhs olunan bir çox bağlanmış və açıq mənbəli həll var, hər birinin öz güclü və zəif tərəfləri var, lakin heç biri 99,999% SLA ilə SaaS və yüksək səviyyədə ahəng təmin etmir. Əgər yüksək SLA səviyyəsi sizin əsas məqsədinizdirsə və birdən çox bulud mühitində öz həllinizi yaratmağa meylli deyilsinizsə, Cloud Spanner sizin axtardığınız həll ola bilər. Lakin, onun bütün məhdudiyyətləri haqqında məlumatlı olmalısınız.
Ədalət naminə qeyd etmək lazımdır ki, Cloud Spanner yalnız 2017-ci ilin yazında geniş istifadə üçün təqdim edilib, buna görə də indiki bəzi çatışmazlıqlarının zamanla aradan qalxacağına ümid etmək məsləhətdir (ümid edirik ki, belə olacaq) və bu baş verərsə, oyun dəyişəcək. Nəhayət, Cloud Spanner yalnız Google üçün üçüncü tərəf layihəsi deyil. Google onu Google-in digər məhsulları üçün əsas kimi istifadə edir. Və Google son vaxtlar Megastore-u Google Cloud Storage-dan Cloud Spanner ilə əvəz etdikdə, bu, Google Cloud Storage-ın dünya miqyasında obyektlərin siyahıları üçün tam etibarlı olmasına imkan tanıdı (bu hələ də Amazon-un olmadığı bir şeydir). ).
Beləliklə, hələ ümid var... biz ümid edirik.
Bu qədər. Məqalənin müəllifi kimi, biz də hələ ümid edirik, bəs siz bununla bağlı nə düşünürsünüz? Şərhlərdə yazın.
İstəyən hər kəsi bizim çərçivəsində kurs haqqında ətraflı məlumat verəcəyik. OTUS-dan.
Mənbə: habr.com
