Salam Xabrovsk sakinləri. Həmişəki kimi yeni kursların başlaması ərəfəsində maraqlı materialları paylaşmağa davam edirik. Bu gün, xüsusən də sizin üçün, kursun başlanması ilə eyni vaxtda Google Cloud Spanner haqqında məqalə dərc etmişik. .
Əvvəlcə nəşr olundu .
Dünya üzrə pərakəndə satıcılara, restorançılara və onlayn satıcılara bulud əsaslı müxtəlif POS həllər təklif edən şirkət olaraq, Lightspeed müxtəlif əməliyyat, analitik və axtarış istifadə halları üçün bir neçə fərqli verilənlər bazası platformasından istifadə edir. Bu verilənlər bazası platformalarının hər birinin özünəməxsus güclü və zəif tərəfləri var.Beləliklə, Google Cloud Spanner-i bazara təqdim etdikdə - faktiki olaraq qeyri-məhdud üfüqi genişlənmə və 99,999% xidmət səviyyəsi razılaşması (SLA) kimi relational verilənlər bazası dünyasında görünməyən perspektivli xüsusiyyətlər, - əlimizə almaq fürsətini əldən verə bilməzdik!
Cloud Spanner ilə təcrübəmizə, eləcə də istifadə etdiyimiz qiymətləndirmə meyarlarına dair hərtərəfli icmalı təqdim etmək üçün biz aşağıdakı mövzuları əhatə edəcəyik:
- Qiymətləndirmə meyarlarımız
- Bir sözlə Cloud Spanner
- Bizim reytinqimiz
- Bizim tapıntılarımız
1. Qiymətləndirmə meyarlarımız
Cloud Spanner-in xüsusiyyətlərinə, onun bazardakı digər həllər ilə oxşarlıqlarına və fərqlərinə keçməzdən əvvəl gəlin əvvəlcə infrastrukturumuzda Cloud Spanner-ı harada yerləşdirməyi düşünərkən nəzərə aldığımız əsas istifadə hallarından danışaq:
- Ənənəvi SQL verilənlər bazası həlli üçün əvəzedici kimi
- OLAP dəstəyi ilə OLTP həlli necə
Qeyd: Sadəlik və müqayisə asanlığı üçün bu məqalə Cloud Spanner-ı GCP Cloud SQL və Amazon AWS RDS həll ailələrinin MySQL variantları ilə müqayisə edir.
Ənənəvi SQL verilənlər bazası həllini əvəz edən Cloud Spanner-dan istifadə
Ətraf mühitdə ənənəvi verilənlər bazası sorğusuna cavab müddəti əvvəlcədən müəyyən edilmiş tətbiq hədlərinə yaxınlaşdıqda və ya hətta onları aşdıqda (əsasən istifadəçilərin və/və ya sorğuların sayının artması səbəbindən), cavab müddətini məqbul səviyyələrə endirməyin bir neçə yolu var. Bununla belə, bu həllərin əksəriyyəti əl ilə müdaxiləni əhatə edir.
Məsələn, atılacaq ilk addım müxtəlif performansla əlaqəli verilənlər bazası parametrlərinə baxmaq və onları tətbiqdən istifadə nümunələrinə ən yaxşı uyğunlaşdırmaq üçün tənzimləməkdir. Bu kifayət deyilsə, verilənlər bazasını şaquli və ya üfüqi olaraq miqyasını seçə bilərsiniz.
Tətbiqin şaquli şəkildə miqyasının dəyişdirilməsi adətən daha çox prosessor/nüvə, daha çox RAM, daha sürətli yaddaş və s. əlavə etməklə server instansiyasının təkmilləşdirilməsini nəzərdə tutur. Daha çox aparat resurslarının əlavə edilməsi verilənlər bazası performansının artması ilə nəticələnir, ilk növbədə ikinci əməliyyatlarda və OLTP sistemləri üçün əməliyyat gecikməsi ilə ölçülür. MySQL kimi əlaqəli verilənlər bazası sistemləri (çox yivli yanaşmadan istifadə edir) şaquli olaraq yaxşı miqyaslanır.
Bu yanaşmanın bir sıra çatışmazlıqları var, lakin ən bariz olanı bazarda maksimum server ölçüsüdür. Ən böyük server nümunəsinin limitinə çatdıqdan sonra yalnız bir seçim qalır: üfüqi miqyaslama.
Üfüqi miqyaslama, klasterə daha çox serverin əlavə olunduğu bir yanaşmadır və ideal olaraq serverlərin sayı əlavə olunduqca xətti olaraq performansı artırır. Çoxluq ənənəvi Verilənlər bazası sistemləri üfüqi olaraq yaxşı ölçülənmir və ya ümumiyyətlə miqyaslanmır. Məsələn, MySQL qul oxuyucuları əlavə etməklə oxu əməliyyatları üçün üfüqi şəkildə miqyaslandıra bilər, lakin yazılar üçün üfüqi miqyaslaya bilməz.
Digər tərəfdən, təbiətinə görə, Cloud Spanner minimal müdaxilə ilə asanlıqla üfüqi şəkildə miqyaslaya bilir.
Tam xüsusiyyətli DBMS bir xidmət kimi müxtəlif rakurslardan qiymətləndirilməlidir. Əsas olaraq biz buludda ən populyar DBMS-ni götürdük - Google, GCP Cloud SQL və Amazon, AWS RDS üçün. Qiymətləndirməmizdə biz aşağıdakı kateqoriyalara diqqət yetirdik:
- Xüsusiyyətlərin xəritələşdirilməsi: genişlik SQL, DDL, DML; əlaqə kitabxanaları/konnektorları, əməliyyat dəstəyi və s.
- İnkişaf dəstəyi: asan inkişaf və sınaq.
- İnzibati dəstək: instansiyanın idarə edilməsi - məsələn, nümunələri böyütmək/aşağılamaq və təkmilləşdirmək; SLA, ehtiyat nüsxə və bərpa; təhlükəsizlik/giriş nəzarəti.
Bulud Açarının OLAP-a əsaslanan OLTP həlli kimi istifadə edilməsi
Google Cloud Spanner-ın analitik emal üçün nəzərdə tutulduğunu açıq şəkildə iddia etməsə də, bəzi atributları OLAP iş yükləri üçün nəzərdə tutulmuş Apache Impala & Kudu və YugaByte kimi digər mühərriklərlə paylaşır.
Cloud Spanner-a (az və ya çox) istifadə edilə bilən OLAP funksiya dəsti ilə ardıcıl miqyaslı HTAP (hibrid əməliyyat/analitik emal) mühərriki daxil etmək şansı az olsa belə, biz onun diqqətimizə layiq olacağını düşünürük.
Bunu nəzərə alaraq, aşağıdakı kateqoriyalara baxdıq:
- Məlumatların yüklənməsi, indekslər və bölmə dəstəyi
- Sorğu Performansı və DML
2. Qısaca Cloud Spanner
Google Spanner, Google-un bir neçə öz xidmətləri üçün istifadə etdiyi klasterləşdirilmiş əlaqəli verilənlər bazası idarəetmə sistemidir (RDBMS). Google onu ümumiyyətlə 2017-ci ilin əvvəlində Google Bulud Platforması istifadəçilərinə təqdim etdi.
Cloud Spanner atributlarından bəziləri bunlardır:
- Yüksək Ardıcıl Ölçəklənən RDBMS Klasteri: Məlumatların ardıcıllığını təmin etmək üçün aparat vaxtının sinxronizasiyasından istifadə edir.
- Cədvəllərarası əməliyyat dəstəyi: Əməliyyatlar birdən çox cədvəli əhatə edə bilər - mütləq bir cədvəllə məhdudlaşmır (Apache HBase və ya Apache Kudu-dan fərqli olaraq).
- İlkin açara əsaslanan cədvəllər: Bütün cədvəllərdə cədvəldə bir neçə sütundan ibarət ola bilən elan edilmiş əsas açar (PC) olmalıdır. Cədvəl məlumatları PC üçün ardıcıllıqla saxlanılır, bu da onu PC axtarışı üçün çox səmərəli və sürətli edir. Digər PC-əsaslı sistemlər kimi, həyata keçirilməsi də nail olmaq üçün əvvəlcədən hazırlanmış istifadə halları nəzərə alınmaqla modelləşdirilməlidir .
- Zolaqlı cədvəllər: Cədvəllərin bir-birindən fiziki asılılığı ola bilər. Uşaq cədvəlindəki sətirlər əsas cədvəldəki sətirlərlə uyğunlaşdırıla bilər. Bu yanaşma, müştərilərin və onların hesab-fakturalarının birgə yerləşdirilməsi kimi verilənlərin modelləşdirilməsi mərhələsində müəyyən edilə bilən əlaqələrin axtarışını sürətləndirir.
- İndekslər: Cloud Spanner ikinci dərəcəli indeksləri dəstəkləyir. İndeks indekslənmiş sütunlardan və bütün PC sütunlarından ibarətdir. İstəyirsinizsə, indeks digər indeksləşdirilməmiş sütunları da ehtiva edə bilər. Sorğuları sürətləndirmək üçün indeks əsas cədvəllə birləşdirilə bilər. İndekslərə bir neçə məhdudiyyət tətbiq olunur, məsələn, indeksdə saxlanılan əlavə sütunların maksimum sayı. Həmçinin, indekslər vasitəsilə sorğular digər RDBMS-lərdə olduğu kimi sadə olmaya bilər.
“Cloud Spanner yalnız nadir hallarda indeksi avtomatik seçir. Xüsusilə, sorğuda saxlanmayan sütunlar tələb olunarsa, Cloud Spanner avtomatik olaraq ikinci dərəcəli indeks seçmir. .
- Xidmət Səviyyəsi Müqaviləsi (SLA): 99,99% SLA ilə bir regionda yerləşdirmə; 99,999% SLA ilə çox regionlu yerləşdirmələr. SLA-nın özü hər hansı bir zəmanət olmasa da, sadəcə bir razılaşma olsa da, mən inanıram ki, Google-dakı insanlar belə güclü bir iddia irəli sürmək üçün bəzi çətin məlumatlara sahibdirlər. (İstinad üçün, 99,999% ayda 26,3 saniyə xidmət əlçatmazlığı deməkdir.)
- Daha çox:
Qeyd: Apache Tephra layihəsi Apache HBase-ə təkmilləşdirilmiş əməliyyat dəstəyi əlavə edir (həmçinin indi Apache Phoenix-də beta olaraq həyata keçirilir).
3. Qiymətləndirməmiz
Beləliklə, biz hamımız Google-un Cloud Spanner-in üstünlükləri haqqında iddialarını oxumuşuq - yüksək ardıcıllığı və çox yüksək SLA-nı qoruyarkən faktiki olaraq qeyri-məhdud üfüqi miqyaslama. Bu tələblərə nail olmaq hər halda son dərəcə çətin olsa da, məqsədimiz onları təkzib etmək deyildi. Bunun əvəzinə, verilənlər bazası istifadəçilərinin əksəriyyətinin əhəmiyyət verdiyi digər şeylərə diqqət yetirək: paritet və istifadə qabiliyyəti.
Cloud Spanner-ı Sharded MySQL-in əvəzi kimi qiymətləndirdik
Bulud bazarında ən populyar OLTP DBMS-lərdən ikisi olan Google Cloud SQL və Amazon AWS RDS çox geniş xüsusiyyətlərə malikdir. Bununla belə, bu verilənlər bazalarını tək bir node ölçüsündən kənara çıxarmaq üçün proqram bölmələrini yerinə yetirməlisiniz. Bu yanaşma həm tətbiqlər, həm də idarəetmə üçün əlavə mürəkkəblik yaradır. Biz Spanner-in birdən çox parçanı bir nümunədə birləşdirmək ssenarisinə necə uyğun gəldiyini və hansı xüsusiyyətlərin (əgər varsa) qurban verilməli olduğunu nəzərdən keçirdik.
SQL, DML və DDL dəstəyi, eləcə də konnektor və kitabxanalar?
Birincisi, hər hansı bir verilənlər bazası ilə işə başladıqda, məlumat modelini yaratmalısınız. JDBC Spanner-ı sevimli SQL alətinizə qoşa biləcəyinizi düşünürsünüzsə, onunla məlumatlarınızı sorğulaya biləcəyinizi görəcəksiniz, lakin siz onu cədvəl yaratmaq və ya dəyişdirmək (DDL) və ya hər hansı əlavə etmək/yeniləmə/silmək üçün istifadə edə bilməyəcəksiniz. əməliyyatlar (DML). Google-un rəsmi JDBC bunların heç birini dəstəkləmir.
"Sürücülər hazırda DML və ya DDL ifadələrini dəstəkləmir."
Açar sənədləri
GCP konsolu ilə vəziyyət yaxşı deyil - siz yalnız SELECT sorğuları göndərə bilərsiniz. Xoşbəxtlikdən, əməliyyatlar da daxil olmaqla icma tərəfindən DML və DDL dəstəyi ilə bir JDBC sürücüsü var . Bu sürücü son dərəcə faydalı olsa da, Google-un öz JDBC sürücüsünün olmaması təəccüblüdür. Xoşbəxtlikdən, Google müştəri kitabxanaları üçün kifayət qədər geniş dəstək təklif edir (gRPC əsasında): C#, Go, Java, node.js, PHP, Python və Ruby.
Cloud Spanner fərdi API-lərinin demək olar ki, məcburi istifadəsi (JDBC-də DDL və DML olmaması səbəbindən) əlaqə hovuzları və ya verilənlər bazası bağlama çərçivələri (məsələn, Spring MVC) kimi əlaqəli kod sahələri üçün bəzi məhdudiyyətlərlə nəticələnir. Tipik olaraq, JDBC-dən istifadə edərkən sınaqdan keçirilmiş və yaxşı işləyən sevimli əlaqə hovuzunuzu (məsələn, HikariCP, DBCP, C3PO və s.) seçməkdə sərbəstsiniz. Xüsusi Spanner API-ləri vəziyyətində, özümüz yaratdığımız çərçivələrə/məcburi hovuzlara/sessiyalara etibar etməliyik.
İlkin açarın (PC) mərkəzləşdirilmiş dizaynı Cloud Spanner-ə PC vasitəsilə məlumat əldə edərkən çox sürətli olmağa imkan verir, həm də bəzi sorğu problemlərini təqdim edir.
- Siz əsas açar dəyərini yeniləyə bilməzsiniz; Əvvəlcə girişi orijinal PC-dən silməli və onu yeni dəyərlə yenidən daxil etməlisiniz. (Bu, digər PC yönümlü verilənlər bazası/saxlama mühərriklərinə bənzəyir.)
- İstənilən UPDATE və DELETE ifadələri PC-ni HARADA-da göstərməlidir, buna görə də bütün ifadələri DELETE boş ola bilməz - həmişə alt sorğu olmalıdır, məsələn: YENİLƏNİB xxx WHERE id IN (Cədvəl1-DƏN SEÇ id)
- Avtomatik artım seçimi və ya PC sahəsi üçün ardıcıllığı təyin edən oxşar bir şeyin olmaması. Bunun işləməsi üçün tətbiq tərəfində müvafiq dəyər yaradılmalıdır.
İkinci dərəcəli indekslər?
Google Cloud Spanner ikinci dərəcəli indekslər üçün daxili dəstəyə malikdir. Bu, digər texnologiyalarda həmişə mövcud olmayan çox gözəl xüsusiyyətdir. Apache Kudu hazırda ikinci dərəcəli indeksləri dəstəkləmir və Apache HBase birbaşa indeksləri dəstəkləmir, lakin onları Apache Phoenix vasitəsilə əlavə edə bilər.
Kudu və HBase-dəki indekslər ilkin açarların fərqli tərkibi ilə ayrıca cədvəl kimi modelləşdirilə bilər, lakin əsas cədvəl və əlaqəli indeks cədvəllərində yerinə yetirilən əməliyyatların atomikliyi tətbiq səviyyəsində aparılmalıdır və düzgün həyata keçirmək üçün əhəmiyyətsiz deyil.
Cloud Spanner icmalında qeyd edildiyi kimi, onun indeksləri MySQL indekslərindən fərqli ola bilər. Buna görə də, lazımi indeksin lazım olduğu yerdə istifadə edilməsini təmin etmək üçün sorğular və profillər qurarkən xüsusi diqqət yetirilməlidir.
Nümayəndəlik?
Verilənlər bazasında çox məşhur və faydalı obyekt baxışlardır. Onlar çox sayda istifadə halları üçün faydalı ola bilər; mənim iki sevimlilərim məntiqi abstraksiya təbəqəsi və təhlükəsizlik təbəqəsidir. Təəssüf ki, Cloud Spanner baxışları DƏSTƏKLƏMİR. Bununla belə, bu, bizi yalnız qismən məhdudlaşdırır, çünki baxışların məqsədəuyğun həll ola biləcəyi sütun səviyyəsində giriş icazələri üçün heç bir detal yoxdur.
Kvota və məhdudiyyətləri təfərrüatlandıran bölmə üçün Cloud Spanner sənədlərinə baxın (), bəzi tətbiqlər üçün problem yarada bilən bir xüsusiyyət var: Qutudan çıxarılan Cloud Spanner bir nümunə üçün maksimum 100 verilənlər bazası limitinə malikdir. Aydındır ki, bu, 100-dən çox verilənlər bazası üçün miqyas almaq üçün nəzərdə tutulmuş verilənlər bazası üçün böyük darboğaz ola bilər. Xoşbəxtlikdən, Google texniki nümayəndəmizlə danışdıqdan sonra biz bildik ki, bu limit Google Dəstəyi vasitəsilə demək olar ki, istənilən dəyərə qədər artırıla bilər.
İnkişafa dəstək?
Cloud Spanner, API ilə işləmək üçün olduqca layiqli proqramlaşdırma dili dəstəyi təklif edir. Rəsmi olaraq dəstəklənən kitabxanalar C#, Go, Java, node.js, PHP, Python və Ruby sahələrindədir. Sənədlər olduqca təfərrüatlıdır, lakin digər qabaqcıl texnologiyalarda olduğu kimi, icma ən populyar verilənlər bazası texnologiyaları ilə müqayisədə olduqca kiçikdir və bu, daha az ümumi istifadə hallarının və ya problemlərin həllinə daha çox vaxt sərf edilməsinə səbəb ola bilər.
Bəs yerli inkişafı dəstəkləmək necə?
Yerində Cloud Spanner nümunəsi yaratmaq üçün bir yol tapmamışıq. Əldə etdiyimiz ən yaxın şey Docker şəkli idi. , prinsipcə oxşardır, lakin praktikada çox fərqlidir. Məsələn, CockroachDB PostgreSQL JDBC-dən istifadə edə bilər. İnkişaf mühiti istehsal mühitinə mümkün qədər yaxın olmalı olduğundan, Cloud Spanner ideal deyil, çünki o, tam Spanner nümunəsinə etibar etməlidir. Xərclərə qənaət etmək üçün bir region nümunəsi seçə bilərsiniz.
İdarə dəstəyi?
Cloud Spanner nümunəsini yaratmaq çox sadədir. Siz sadəcə olaraq çox regionlu və ya tək regionlu nümunə yaratmaq arasında seçim etməli, region(lar)ı və qovşaqların sayını göstərməlisiniz. Bir dəqiqədən az müddətdə nümunəniz işə düşəcək.
Bir neçə ibtidai ölçülərə birbaşa Google Konsolunda Spanner səhifəsindən daxil olmaq mümkündür. Daha ətraflı görünüşlər Stackdriver vasitəsilə mövcuddur, burada siz həmçinin metrik hədləri və xəbərdarlıq siyasətlərini təyin edə bilərsiniz.
Resurslara giriş?
MySQL istifadəçi icazələri/rolları üçün geniş və çox detallı parametrlər təklif edir. Siz asanlıqla müəyyən bir cədvələ və ya hətta onun sütunlarının bir alt çoxluğuna girişi konfiqurasiya edə bilərsiniz. Cloud Spanner yalnız çox yüksək səviyyədə siyasət və icazələr təyin etməyə imkan verən Google-un Şəxsiyyət və Giriş İdarəetmə (IAM) alətindən istifadə edir. Ən zərif seçim verilənlər bazası səviyyəsində qətnamədir ki, bu da əksər istehsalat istifadə hallarına uyğun gəlmir. Bu məhdudiyyət sizi Spanner resurslarından icazəsiz istifadənin 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.
Yedəkləmələr?
Sadə dillə desək, Cloud Spanner-də ehtiyat nüsxələri yoxdur. Baxmayaraq ki, Google-un yüksək SLA tələbləri aparat və ya verilənlər bazası nasazlığı, insan səhvləri, tətbiq qüsurları və s. səbəblərdən heç bir məlumatı itirməməyinizi təmin edə bilər. Biz hamımız qaydanı bilirik: yüksək əlçatanlıq sağlam ehtiyat nüsxə strategiyasını əvəz edə bilməz. Hazırda məlumatların ehtiyat nüsxəsini çıxarmağın yeganə yolu proqramlı şəkildə verilənlər bazasından ayrı saxlama mühitinə axın etməkdir.
Sorğu performansı?
Biz məlumat və test sorğularını yükləmək üçün Yahoo-dan istifadə etdik. Bulud Xidməti Testi. Aşağıdakı cədvəldə YCSB iş yükü B 95% oxunuş və 5% yazma nisbəti ilə göstərilir.
* Yük testi n1-standart-32 Compute Engine (CE) (32 vCPU, 120 GB yaddaş) üzərində aparılıb və sınaq nümunəsi heç vaxt sınaqlarda darboğaz yaratmayıb.
** Tək YCSB instansiyasında başlıqların maksimum sayı 400-dür. Cəmi 2400 başlıq əldə etmək üçün YCSB testlərinin cəmi altı paralel nümunəsi icra edilməli idi.
Benchmark nəticələrinə, xüsusən də CPU yükü və TPS birləşməsinə baxsaq, Cloud Spanner-in kifayət qədər yaxşı ölçüləndiyini aydın görə bilərik. Çox sayda ipin yaratdığı ağır yük Cloud Spanner klasterindəki çoxlu sayda qovşaqla əvəzlənir. Xüsusilə 2400 iplə işləyərkən gecikmə olduqca yüksək görünsə də, daha dəqiq rəqəmlər əldə etmək üçün hesablama mühərrikinin 6 kiçik nümunəsi ilə yenidən sınaqdan keçmək lazım ola bilər. Hər bir nümunə 6 paralel testlə bir böyük CE nümunəsi əvəzinə bir YCSB testi keçirəcək. Bu yolla, Cloud Spanner sorğusu gecikməsi ilə Cloud Spanner və testi həyata keçirən CE nümunəsi arasında şəbəkə bağlantısı tərəfindən əlavə edilən gecikmə arasında fərq qoymaq daha asan olacaq.
Cloud Spanner OLAP kimi necə işləyir?
Bölmə?
Məlumatların arakəsmələr adlanan fiziki və/yaxud məntiqi cəhətdən müstəqil seqmentlərə bölünməsi əksər OLAP mühərriklərində tapılan çox məşhur bir anlayışdır. Bölmələr sorğu performansını və verilənlər bazası saxlanmasını əhəmiyyətli dərəcədə yaxşılaşdıra bilər. Bölmələrə daha dərindən getmək ayrıca məqalə(lər) olardı, ona görə də gəlin bölmə və alt bölmə sxeminə malik olmağın vacibliyini qeyd edək. Məlumatları bölmələrə və hətta daha da alt bölmələrə bölmək bacarığı analitik sorğunun performansının açarıdır.
Cloud Spanner belə bölmələri dəstəkləmir. Məlumatları daxili olaraq sözdə bölür parçalanması-s əsas açar diapazonlarına əsaslanır. Cloud Spanner klasterində yükü tarazlaşdırmaq üçün bölmə avtomatik olaraq həyata keçirilir. Cloud Spanner-in çox faydalı xüsusiyyəti, ana cədvəlin əsas yükünün (başqası ilə qarışdırılmayan cədvəl) bölünməsidir. Spanner avtomatik olaraq onun tərkibində olub-olmadığını müəyyən edir parçalanması başqalarına nisbətən daha tez-tez oxunan məlumatlar parçalanması-ah, və daha da ayrılmağa qərar verə bilər. Bu yolla sorğuya daha çox qovşaq cəlb oluna bilər ki, bu da ötürmə qabiliyyətini effektiv şəkildə artırır.
Data yüklənir?
Cloud Spanner-in toplu məlumat üçün metodu normal yükləmə ilə eynidir. Maksimum performansa nail olmaq üçün bəzi qaydalara əməl etməlisiniz, o cümlədən:
- Məlumatlarınızı əsas açara görə çeşidləyin.
- Onları 10-a bölün*qovşaqların sayı ayrı bölmələr.
- Paralel olaraq məlumatları yükləyən bir sıra iş tapşırıqları yaradın.
Bu məlumatların yüklənməsi bütün Bulud Açar qovşaqlarından istifadə edir.
10M sətirdən ibarət məlumat dəstini yaratmaq üçün YCSB iş yükü A-dan istifadə etdik.
* Yük sınağı n1-standart-32 hesablama mühərrikində (32 vCPU, 120 GB yaddaş) həyata keçirilib və sınaq nümunəsi heç vaxt sınaqlarda darboğaz yaratmayıb.
**Hər hansı istehsal iş yükü üçün tək node quraşdırma tövsiyə edilmir.
Yuxarıda qeyd edildiyi kimi, Cloud Spanner bölmələri onların yükündən asılı olaraq avtomatik emal edir, beləliklə, bir neçə ardıcıl sınaq təkrarından sonra nəticələr yaxşılaşır. Burada təqdim olunan nəticələr əldə etdiyimiz ən yaxşı nəticələrdir. Yuxarıdakı rəqəmlərə baxsaq, klasterdəki qovşaqların sayı artdıqca Cloud Spanner-in necə ölçüləndiyini (yaxşı) görə bilərik. Diqqət çəkən rəqəmlər yuxarıdakı bölmədə təsvir olunduğu kimi qarışıq iş yükləri (95% oxumaq və 5% yazma) üçün nəticələrlə ziddiyyət təşkil edən olduqca aşağı orta gecikmələrdir.
Ölçəkləmə?
Cloud Spanner qovşaqlarının sayını artırmaq və azaltmaq bir klik işidir. Əgər məlumatı tez yükləmək istəyirsinizsə, nümunənizi maksimuma yüksəltməyi düşünə bilərsiniz (bizim halda bu, ABŞ-ŞƏRQİ regionda 25 qovşaq idi) və bütün məlumatlar daxil olduqdan sonra normal yükləməniz üçün uyğun olan qovşaqların sayını azalda bilərsiniz. verilənlər bazası , 2TB/qovşaq limitinə istinad edir.
Hətta daha kiçik verilənlər bazası ilə belə bu limiti xatırlatdıq. Bir neçə yükləmə testindən sonra verilənlər bazamızın ölçüsü təxminən 155 GB idi və 1 node nümunəsinə qədər kiçildikdə aşağıdakı xətanı aldıq:
Biz 25-dən 2 nümunəyə endirməyi bacardıq, lakin iki qovşaqda ilişib qaldıq.
Cloud Spanner klasterində qovşaqların sayını artırmaq və azaltmaq REST API-dən istifadə etməklə avtomatlaşdırıla bilər. Bu, sıx iş saatlarında artan sistem yükünü azaltmaq üçün xüsusilə faydalı ola bilər.
OLAP sorğularının performansı?
Biz əvvəlcə bu hissədə Spannerin qiymətləndirilməsinə xeyli vaxt sərf etməyi planlaşdırmışdıq. Bir neçə SELECT COUNT-dan sonra biz dərhal başa düşdük ki, test qısa olacaq və Spanner OLAP üçün uyğun mühərrik OLMAYACAQ. Klasterdəki qovşaqların sayından asılı olmayaraq, sadəcə olaraq 10M cərgə cədvəlində sətirlərin sayını seçmək 55 ilə 60 saniyə çəkdi. Əlavə olaraq, aralıq nəticələri saxlamaq üçün daha çox yaddaş tələb edən hər hansı sorğu OOM xətası ilə uğursuz oldu.
SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.
TPC-H sorğuları üçün bəzi nömrələri Todd Lipconun məqaləsində tapmaq olar , slaydlar 42 və 43. Bu rəqəmlər bizim öz nəticələrimizə uyğundur (təəssüf ki).
4. Nəticələrimiz
Cloud Spanner-in xüsusiyyətlərinin hazırkı vəziyyətini nəzərə alsaq, onun mövcud OLTP həllinizin sadə əvəzi olduğunu təsəvvür etmək çətindir, xüsusən də ehtiyaclarınız ondan artıq olduqda. Cloud Spanner-in çatışmazlıqları ətrafında həll yolu yaratmaq üçün xeyli vaxt sərf edilməlidir.
Cloud Spanner-ı qiymətləndirməyə başlayanda biz onun idarəetmə xüsusiyyətlərinin digər Google SQL həlləri ilə bərabər və ya heç olmasa onlardan çox da uzaqda olmamasını gözləyirdik. Ancaq ehtiyat nüsxələrin tam olmaması və resurslara giriş üzərində çox məhdud nəzarət bizi təəccübləndirdi. Heç bir baxış, heç bir yerli inkişaf mühiti, dəstəklənməyən ardıcıllıq, DML və DDL dəstəyi olmayan JDBC və s.
Beləliklə, tranzaksiya verilənlər bazasını genişləndirməyə ehtiyacı olan biri hara gedir? Bazarda bütün istifadə hallarına uyğun bir həll yolu yoxdur. Bir çox qapalı və açıq mənbə həlləri var (bunlardan bəziləri bu məqalədə qeyd olunub), hər birinin öz güclü və zəif tərəfləri var, lakin onların heç biri 99,999% SLA və yüksək ardıcıllıqla SaaS təklif etmir. Yüksək SLA əsas məqsədinizdirsə və fərdi çoxlu bulud həlli yaratmağa meylli deyilsinizsə, Cloud Spanner axtardığınız həll yolu ola bilər. Ancaq onun bütün məhdudiyyətlərini bilməlisiniz.
Ədalətli olmaq üçün, Cloud Spanner yalnız 2017-ci ilin yazında ictimaiyyətə təqdim edildi, ona görə də onun bəzi mövcud çatışmazlıqlarının sonda aradan qalxacağını gözləmək ağlabatandır (inşallah) və onlar getdikdə, bu, oyun dəyişdirici ola bilər. Axı, Cloud Spanner yalnız Google üçün yan layihə deyil. Google onu digər Google məhsulları üçün əsas kimi istifadə edir. Və Google bu yaxınlarda Google Bulud Yaddaşında Megastore-u Cloud Spanner ilə əvəz etdikdə, bu, Google Bulud Yaddaşının qlobal miqyasda obyektlərin siyahıları üçün yüksək dərəcədə ardıcıl olmasına imkan verdi (bu, hələ də belə deyil. ).
Deməli, hələ də ümid var... ümid edirik.
Hamısı budur. Məqalə müəllifi kimi biz də ümid etməyə davam edirik, amma bu barədə nə düşünürsünüz? Şərhlərdə yazın
Hər kəsi ziyarətə dəvət edirik ərzində sizə kurs haqqında ətraflı məlumat verəcəyik OTUS-dan.
Mənbə: www.habr.com