Google Cloud Spanner: yaxshi, yomon, xunuk

Salom, Xabrovitlar. An'anaga ko'ra, biz yangi kurslar boshlanishi arafasida qiziqarli materiallar bilan bo'lishishda davom etamiz. Bugun, ayniqsa siz uchun, biz Google Cloud Spanner haqidagi maqolani tarjima qildik, bu kursning boshlanishiga to'g'ri keldi. "Ishlab chiquvchilar uchun AWS".

Google Cloud Spanner: yaxshi, yomon, xunuk

Dastlab nashr etilgan Lightspeed HQ blogi.

Butun dunyo bo'ylab chakana sotuvchilar, restavratorlar va onlayn savdogarlar uchun bulutga asoslangan turli xil POS yechimlarini taklif qiluvchi kompaniya sifatida Lightspeed turli tranzaksiya, tahliliy va qidiruvdan foydalanish holatlari uchun turli xil ma'lumotlar bazasi platformalaridan foydalanadi. Ushbu ma'lumotlar bazasi platformalarining har biri o'zining kuchli va zaif tomonlariga ega.Demak, Google Cloud Spanner-ni bozorga taqdim etganida - relyatsion ma'lumotlar bazasi dunyosida ilgari hech qachon ko'rilmagan istiqbolli xususiyatlar, masalan, deyarli cheksiz gorizontal o'lchov va 99,999% xizmat ko'rsatish darajasidagi kelishuv (SLA) , Biz uni qo'limizda bo'lish imkoniyatini qo'ldan boy bera olmadik!

Cloud Spanner bilan ishlash tajribamiz, shuningdek, biz qo‘llagan baholash mezonlari haqida to‘liq ma’lumot berish uchun biz quyidagi mavzularni ko‘rib chiqamiz:

  1. Bizning baholash mezonlarimiz
  2. Qisqacha aytganda Cloud Spanner
  3. Bizning baholashimiz
  4. Bizning topilmalarimiz

Google Cloud Spanner: yaxshi, yomon, xunuk

1. Bizning baholash mezonimiz

Cloud Spanner-ning o'ziga xos xususiyatlari, uning bozordagi boshqa echimlar bilan o'xshashliklari va farqlari bilan tanishishdan oldin, keling, infratuzilmamizda Cloud Spanner-ni qayerga joylashtirishni ko'rib chiqishda asosiy foydalanish holatlari haqida gapiraylik:

  • An'anaviy SQL ma'lumotlar bazasi yechimining o'rnini bosuvchi sifatida
  • OLAP yoqilgan OLTP yechimi sifatida

Eslatma: Taqqoslash qulayligi uchun ushbu maqola Cloud Spanner’ni GCP Cloud SQL va Amazon AWS RDS yechimlari oilalarining MySQL variantlari bilan solishtiradi.

Cloud Spanner'dan an'anaviy SQL ma'lumotlar bazasi yechimi o'rniga foydalanish

Atrof muhitda an'anaviy ma'lumotlar bazalari, agar ma'lumotlar bazasi so'roviga javob berish muddati oldindan belgilangan dastur chegaralariga yaqinlashganda yoki hatto oshib ketganda (birinchi navbatda foydalanuvchilar va/yoki so'rovlar sonining ko'payishi tufayli), javob vaqtini maqbul darajalarga qisqartirishning bir necha yo'li mavjud. Biroq, bu echimlarning aksariyati qo'lda aralashuvni o'z ichiga oladi.

Misol uchun, birinchi qadam ishlashga bog'liq bo'lgan turli xil ma'lumotlar bazasi sozlamalarini ko'rib chiqish va ularni ilovalardan foydalanish stsenariy naqshlariga eng mos keladigan tarzda sozlashdir. Agar bu etarli bo'lmasa, siz ma'lumotlar bazasini vertikal yoki gorizontal ravishda o'lchashni tanlashingiz mumkin.

Ilova masshtabini kengaytirish odatda qoʻshimcha protsessorlar/yadrolar, koʻproq RAM, tezroq saqlash va h.k.larni qoʻshish orqali server namunasini yangilashni talab qiladi. Koʻproq apparat resurslari qoʻshilishi maʼlumotlar bazasi unumdorligini oshiradi, birinchi navbatda soniyada tranzaksiyalar bilan oʻlchanadi va OLTP tizimlari uchun tranzaksiya kechikishi. MySQL kabi relyatsion ma'lumotlar bazasi tizimlari (ko'p tarmoqli yondashuvdan foydalanadi) vertikal ravishda yaxshi o'lchaydi.

Ushbu yondashuvning bir nechta kamchiliklari mavjud, ammo eng aniqi bozordagi maksimal server hajmi. Eng katta Server Instance chegarasiga erishilgandan so'ng, faqat bitta yo'l qoladi: miqyosni kengaytirish.

Masshtabni kichraytirish - bu ko'proq serverlar qo'shilganda unumdorlikni chiziqli ravishda oshirish uchun klasterga qo'shimcha serverlar qo'shadigan yondashuv. Ko'pchilik an'anaviy ma'lumotlar bazasi tizimlari yaxshi miqyosda emas yoki umuman miqyosda emas. Masalan, MySQL qul o'quvchilarni qo'shish orqali o'qish operatsiyalari uchun masshtabni kengaytirishi mumkin, lekin yozish operatsiyalari uchun kengaytira olmaydi.

Boshqa tomondan, tabiatiga ko'ra, Cloud Spanner minimal aralashuv bilan osongina gorizontal ravishda o'lchaydi.

To'liq xususiyatli DBMS xizmat sifatida turli nuqtai nazardan baholanishi kerak. Asos sifatida biz bulutdagi eng mashhur DBMSni oldik - Google, GCP Cloud SQL va Amazon, AWS RDS uchun. Baholashda biz quyidagi toifalarga e'tibor qaratdik:

  • Xususiyatlarni xaritalash: SQL hajmi, DDL, DML; ulanish kutubxonalari/ulagichlari, tranzaktsiyalarni qo'llab-quvvatlash va boshqalar.
  • Rivojlanishni qo'llab-quvvatlash: ishlab chiqish va sinovdan o'tkazish qulayligi.
  • Ma'muriyatni qo'llab-quvvatlash: misollarni kattalashtirish/pasaytirish va yangilash kabi misollarni boshqarish; SLA, zaxira va tiklash; xavfsizlik/kirish nazorati.

Cloud Spanner'dan OLAP yoqilgan OLTP yechimi sifatida foydalanish

Google Cloud Spanner analitika uchun ekanligini aniq aytmasa-da, u OLAP ish yuklari uchun moʻljallangan Apache Impala & Kudu va YugaByte kabi boshqa dvigatellar bilan baʼzi atributlarni baham koʻradi.

Cloud Spanner-da (ko'proq yoki kamroq) foydalanish mumkin bo'lgan OLAP funktsiyalari to'plamiga ega izchil kengaytirilgan HTAP (gibrid tranzaksiya/analitik ishlov berish) dvigatelini o'z ichiga olishi uchun ozgina imkoniyat bo'lsa ham, bizning e'tiborimizga loyiq deb o'ylaymiz.

Shuni hisobga olib, biz quyidagi toifalarni ko'rib chiqdik:

  • Ma'lumotlarni yuklash, indekslar va bo'limlarni qo'llab-quvvatlash
  • So'rovlar samaradorligi va DML

2. Qisqacha aytganda Cloud Spanner

Google Spanner - bu Google o'zining bir nechta xizmatlari uchun foydalanadigan klasterli relyatsion ma'lumotlar bazasini boshqarish tizimi (RDBMS). Google uni 2017 yil boshida Google Cloud Platform foydalanuvchilari uchun ochiq qildi.

Cloud Spanner atributlaridan ba'zilari:

  • Yuqori darajada izchil, kengaytiriladigan RDBMS klasteri: ma'lumotlar izchilligini ta'minlash uchun apparat vaqtini sinxronlashtirishdan foydalanadi.
  • Jadvallar o'rtasidagi tranzaksiyani qo'llab-quvvatlash: Tranzaktsiyalar bir nechta jadvallarni qamrab olishi mumkin - bu faqat bitta jadval bilan cheklanmaydi (Apache HBase yoki Apache Kududan farqli o'laroq).
  • Birlamchi kalitlarga asoslangan jadvallar: Barcha jadvallar bir nechta jadval ustunlaridan iborat bo'lishi mumkin bo'lgan e'lon qilingan asosiy kalitga (PC) ega bo'lishi kerak. Jadval ma'lumotlari shaxsiy kompyuter tartibida saqlanadi, bu esa uni kompyuterda qidirish uchun juda samarali va tez qiladi. Boshqa shaxsiy kompyuterga asoslangan tizimlarda bo'lgani kabi, amalga oshirish maqsadga erishish uchun oldindan o'ylab topilgan foydalanish holatlariga nisbatan modellashtirilishi kerak eng yaxshi ishlash.
  • Chiziqli jadvallar: jadvallar bir-biriga jismoniy bog'liqliklarga ega bo'lishi mumkin. Bolalar jadvalining satrlari ota-jadvalning qatorlari bilan mos kelishi mumkin. Ushbu yondashuv ma'lumotlarni modellashtirish bosqichida aniqlanishi mumkin bo'lgan munosabatlarni qidirishni tezlashtiradi, masalan, mijozlar va ularning hisob-fakturalarini bir joyga joylashtirishda.
  • Indekslar: Cloud Spanner ikkinchi darajali indekslarni qo'llab-quvvatlaydi. Indeks indekslangan ustunlar va kompyuterning barcha ustunlaridan iborat. Majburiy emas, indeks boshqa indekslanmagan ustunlarni ham o'z ichiga olishi mumkin. So'rovlarni tezlashtirish uchun indeksni ota-jadvalga qo'shish mumkin. Indekslarga bir nechta cheklovlar qo'llaniladi, masalan, indeksda saqlanishi mumkin bo'lgan qo'shimcha ustunlarning maksimal soni. Bundan tashqari, indekslar orqali so'rovlar boshqa RDBMSlardagi kabi oddiy bo'lmasligi mumkin.

"Cloud Spanner faqat kamdan-kam hollarda indeksni avtomatik ravishda tanlaydi. Xususan, Cloud Spanner avtomatik ravishda ikkinchi darajali indeksni tanlamaydi, agar so‘rovda saqlanmaydigan ustunlar so‘ralsa. indeks ".

  • Xizmat ko'rsatish darajasi bo'yicha kelishuv (SLA): 99,99% SLA bilan yagona hududda joylashtirish; 99,999% SLA bilan ko'p mintaqada joylashtirish. SLA-ning o'zi shunchaki kelishuv bo'lib, hech qanday kafolat bo'lmasa-da, men ishonamanki, Google odamlari bunday kuchli da'vo qilish uchun juda qattiq ma'lumotlarga ega. (Ma'lumot uchun, 99,999% oyiga 26,3 soniya xizmat ko'rsatish muddatini bildiradi.)
  • Ko'proq: https://cloud.google.com/spanner/

Eslatma: Apache Tephra loyihasi Apache HBase-ga ilg'or tranzaksiyani qo'llab-quvvatlaydi (shuningdek, endi Apache Phoenix-da beta-versiya sifatida joriy qilingan).

3. Bizning baholashimiz

Shunday qilib, biz hammamiz Google’ning Cloud Spanner’ning afzalliklari haqidagi bayonotlarini o‘qib chiqdik – yuqori mustahkamlik va juda yuqori SLAni saqlab qolgan holda deyarli cheksiz gorizontal masshtablash. Garchi bu da'volarga erishish, har holda, nihoyatda qiyin bo'lsa-da, bizning maqsadimiz ularni rad etish emas edi. Buning o'rniga, ko'pchilik ma'lumotlar bazasi foydalanuvchilarini qiziqtiradigan boshqa narsalarga e'tibor qarataylik: paritet va foydalanish qulayligi.

Biz Cloud Spanner-ni Sharded MySQL o'rnini bosuvchi sifatida baholadik

Google Cloud SQL va Amazon AWS RDS bulutli bozordagi eng mashhur OLTP maʼlumotlar bazalaridan ikkitasi juda katta funksiyalar toʻplamiga ega. Biroq, ushbu ma'lumotlar bazalarini bitta tugunning o'lchamidan tashqariga o'tkazish uchun siz ilovalarni ajratishni amalga oshirishingiz kerak. Ushbu yondashuv ilovalar va boshqaruv uchun qo'shimcha murakkablik yaratadi. Biz Spanner bir nechta parchalarni bir nusxada birlashtirish stsenariysiga qanday mos kelishini va qanday xususiyatlarni (agar mavjud bo'lsa) qurbon qilish kerakligini ko'rib chiqdik.

SQL, DML va DDL, shuningdek, ulagich va kutubxonalarni qo'llab-quvvatlash?

Birinchidan, har qanday ma'lumotlar bazasini ishga tushirishda siz ma'lumotlar modelini yaratishingiz kerak. Agar siz JDBC Spanner-ni sevimli SQL vositangizga ulashingiz mumkin deb hisoblasangiz, u yordamida ma'lumotlaringizni so'rashingiz mumkinligini topasiz, lekin siz undan jadval yaratish yoki yangilash (DDL) yoki biron bir qo'shish/yangilash/o'chirish uchun foydalana olmaysiz. operatsiyalar (DML). Google rasmiy JDBC ham qo'llab-quvvatlamaydi.

"Haydovchilar hozirda DML yoki DDL bayonotlarini qo'llab-quvvatlamaydi."
Spanner hujjatlari

GCP konsolida vaziyat yaxshi emas - siz faqat SELECT so'rovlarini yuborishingiz mumkin. Yaxshiyamki, hamjamiyat tomonidan DML va DDL yordamiga ega JDBC drayveri mavjud, shu jumladan tranzaksiyalar github.com/olavloite/spanner-jdbc. Ushbu drayver juda foydali bo'lsa-da, Google-ning JDBC drayveri yo'qligi ajablanarli. Yaxshiyamki, Google juda keng mijozlar kutubxonasini qo'llab-quvvatlaydi (gRPC asosida): C#, Go, Java, node.js, PHP, Python va Ruby.

Cloud Spanner-ning maxsus API-laridan deyarli majburiy foydalanish (JDBC-da DDL va DML yo'qligi sababli) ulanishni birlashtirish yoki ma'lumotlar bazasini ulash ramkalari (masalan, Spring MVC) kabi tegishli kod sohalari uchun ba'zi cheklovlarga olib keladi. Umuman olganda, JDBC dan foydalanayotganda, sinovdan o'tgan va yaxshi ishlaydigan sevimli ulanish pulingizni (masalan, HikariCP, DBCP, C3PO va boshqalar) tanlashingiz mumkin. Maxsus Spanner API-lar bo'lsa, biz o'zimiz yaratgan ramkalar/bog'lash/sessiya hovuzlariga tayanishimiz kerak.

Asosiy kalitga (Kompyuter) yo'naltirilgan dizayn Cloud Spanner-ga shaxsiy kompyuter orqali ma'lumotlarga kirishda juda tez bo'lishiga imkon beradi, lekin ba'zi so'rovlar bilan bog'liq muammolarni ham keltirib chiqaradi.

  • Siz asosiy kalitning qiymatini yangilay olmaysiz; Avval kompyuterning asl yozuvini o'chirishingiz va uni yangi qiymat bilan qayta kiritishingiz kerak. (Bu boshqa kompyuterga yo'naltirilgan ma'lumotlar bazasi/saqlash mexanizmlariga o'xshaydi.)
  • Har qanday UPDATE va DELETE iboralari WHERE da shaxsiy kompyuterni ko'rsatishi kerak, shuning uchun barcha bayonotlarni DELETE bo'sh bo'lishi mumkin emas - har doim quyi so'rov bo'lishi kerak, masalan: UPDATE xxx WHERE ID IN (1-jadvaldan identifikatorni tanlang)
  • Kompyuter maydoni uchun ketma-ketlikni belgilaydigan avtomatik o'sish opsiyasi yoki shunga o'xshash narsa yo'qligi. Buning ishlashi uchun dastur tomonida tegishli qiymat yaratilishi kerak.

Ikkilamchi indekslar?

Google Cloud Spanner ikkilamchi indekslar uchun o'rnatilgan yordamga ega. Bu boshqa texnologiyalarda har doim ham mavjud bo'lmagan juda yoqimli xususiyat. Apache Kudu hozirda ikkilamchi indekslarni umuman qo'llab-quvvatlamaydi va Apache HBase to'g'ridan-to'g'ri indekslarni qo'llab-quvvatlamaydi, lekin ularni Apache Phoenix orqali qo'shishi mumkin.

Kudu va HBase-dagi indekslarni birlamchi kalitlarning turli tarkibiga ega bo'lgan alohida jadval sifatida modellashtirish mumkin, ammo asosiy jadval va tegishli indeks jadvallarida bajarilgan operatsiyalarning atomligi dastur darajasida bajarilishi kerak va uni to'g'ri amalga oshirish uchun ahamiyatsiz emas.

Cloud Spanner sharhida aytib o'tilganidek, uning indekslari MySQL indekslaridan farq qilishi mumkin. Shunday qilib, to'g'ri indeks kerak bo'lganda ishlatilishini ta'minlash uchun so'rovlarni yaratish va profilni yaratishda alohida e'tibor berish kerak.

Vakillikmi?

Ma'lumotlar bazasidagi juda mashhur va foydali ob'ekt - bu ko'rinishlar. Ular ko'p sonli foydalanish holatlari uchun foydali bo'lishi mumkin; Mening ikkita sevimli narsam - mantiqiy abstraksiya qatlami va xavfsizlik qatlami. Afsuski, Cloud Spanner ko'rishlarni qo'llab-quvvatlamaydi. Biroq, bu bizni faqat qisman cheklaydi, chunki ko'rinishlar maqbul yechim bo'lishi mumkin bo'lgan kirish ruxsatlari uchun ustunlar darajasida aniqlik yo'q.

Kvota va chegaralar haqida batafsil ma'lumot olish uchun Cloud Spanner hujjatlariga qarang (kalit/kvota), xususan, ba'zi ilovalar uchun muammoli bo'lishi mumkin bo'lgan bitta narsa bor: Cloud Spanner qutisidan tashqarida har bir misol uchun maksimal 100 ta ma'lumotlar bazasi mavjud. Shubhasiz, bu 100 dan ortiq ma'lumotlar bazasiga mo'ljallangan ma'lumotlar bazasi uchun katta to'siq bo'lishi mumkin. Yaxshiyamki, Google texnik vakilimiz bilan gaplashganimizdan so'ng, biz ushbu chegarani Google Support orqali deyarli har qanday qiymatga oshirish mumkinligini bilib oldik.

Rivojlanishni qo'llab-quvvatlash?

Cloud Spanner o'zining API bilan ishlash uchun juda yaxshi dasturlash tilini qo'llab-quvvatlaydi. Rasmiy ravishda qo'llab-quvvatlanadigan kutubxonalar C#, Go, Java, node.js, PHP, Python va Ruby sohasida. Hujjatlar juda batafsil, ammo boshqa ilg'or texnologiyalarda bo'lgani kabi, hamjamiyat eng mashhur ma'lumotlar bazasi texnologiyalariga nisbatan ancha kichikdir, bu esa kamroq foydalanish holatlari yoki muammolariga ko'proq vaqt sarflashga olib kelishi mumkin.

Xo'sh, mahalliy rivojlanishni qo'llab-quvvatlash haqida nima deyish mumkin?

Cloud Spanner nusxasini mahalliy yaratish usulini topa olmadik. Bizga eng yaqin bo'lgan Docker tasviri HamamböceğiDBbu printsipial jihatdan o'xshash, lekin amalda juda farq qiladi. Masalan, CockroachDB PostgreSQL JDBC dan foydalanishi mumkin. Rivojlanish muhiti ishlab chiqarish muhitiga imkon qadar yaqin bo'lishi kerakligi sababli, Cloud Spanner ideal emas, chunki siz to'liq Spanner nusxasiga tayanishingiz kerak. Xarajatlarni tejash uchun siz bitta mintaqaviy misolni tanlashingiz mumkin.

Ma'muriy yordam?

Cloud Spanner misolini yaratish juda oddiy. Siz shunchaki ko'p mintaqali yoki bitta mintaqaviy misol yaratish o'rtasida tanlov qilishingiz kerak, mintaqa(lar) va tugunlar sonini ko'rsating. Bir daqiqadan kamroq vaqt ichida instansiya ishga tushadi.

Bir nechta elementar ko'rsatkichlar to'g'ridan-to'g'ri Google Console'dagi Spanner sahifasida mavjud. Batafsilroq koʻrinishlarni Stackdriver orqali olish mumkin, bu yerda siz metrik chegaralar va ogohlantirish siyosatlarini ham oʻrnatishingiz mumkin.

Resurslarga kirish mumkinmi?

MySQL keng va juda batafsil foydalanuvchi ruxsati/rol sozlamalarini taklif etadi. Siz ma'lum bir jadvalga yoki hatto uning ustunlarining kichik to'plamiga kirishni osongina sozlashingiz mumkin. Cloud Spanner Google Identity & Access Management (IAM) vositasidan foydalanadi, bu sizga faqat siyosat va ruxsatlarni juda yuqori darajada o'rnatish imkonini beradi. Eng aniq variant - bu ma'lumotlar bazasi darajasidagi ruxsat bo'lib, u ko'pchilik ishlab chiqarish holatlariga mos kelmaydi. Ushbu cheklov Spanner resurslaridan ruxsatsiz foydalanishni oldini olish uchun kodingizga, infratuzilmangizga yoki ikkalasiga qo'shimcha xavfsizlik choralarini qo'shishga majbur qiladi.

Zaxira nusxalarmi?

Oddiy qilib aytganda, Cloud Spanner-da zaxira nusxalari mavjud emas. Googlening yuqori SLA talablari apparat yoki maʼlumotlar bazasidagi nosozliklar, inson xatosi, dastur nuqsonlari va hokazolar tufayli hech qanday maʼlumotlarni yoʻqotmaslikni taʼminlay olsa-da. Biz hammamiz qoidani bilamiz: yuqori mavjudlik aqlli zaxira strategiyasini almashtirib boʻlmaydi. Hozirgi vaqtda ma'lumotlarni zaxiralashning yagona yo'li - uni ma'lumotlar bazasidan alohida saqlash muhitiga dasturiy ravishda oqimlash.

So'rov unumdorligi?

Biz Yahoo-dan ma'lumotlarni yuklash va so'rovlarni tekshirish uchun foydalandik. Bulutli xizmat ko‘rsatish mezonlari. Quyidagi jadvalda 95% o'qish va 5% yozish nisbati bilan B YCSB ish yuki ko'rsatilgan.

Google Cloud Spanner: yaxshi, yomon, xunuk

* Yuklash sinovi n1-standart-32 Compute Engine (CE) da (32 vCPU, 120 GB xotira) o'tkazildi va sinov namunasi hech qachon sinovlarda qiyinchilik tug'dirmadi.
** Bitta YCSB instansiyasidagi iplarning maksimal soni 400 ta. Jami 2400 ta mavzuni olish uchun YCSB testlarining oltita parallel nusxasini bajarish kerak edi.

Benchmark natijalariga, xususan, protsessor yuki va TPS kombinatsiyasiga qarab, biz Cloud Spanner juda yaxshi miqyosda ekanligini aniq ko'rishimiz mumkin. Ko'p sonli iplar tomonidan yaratilgan katta yuk Cloud Spanner klasteridagi ko'p sonli tugunlar bilan qoplanadi. Garchi kechikish juda yuqori ko'rinadi, ayniqsa 2400 ta ipda ishlaganda, aniqroq raqamlarni olish uchun hisoblash mexanizmining 6 ta kichik nusxasi bilan qayta sinovdan o'tish kerak bo'lishi mumkin. Har bir misol 6 ta parallel test bilan bitta yirik Idoralar namunasi o'rniga bitta YCSB testini o'tkazadi. Bu Cloud Spanner soʻrovi kechikishlari va Cloud Spanner va testni oʻtkazayotgan CE namunasi oʻrtasidagi tarmoq ulanishi tomonidan qoʻshilgan kechikishlarni farqlashni osonlashtiradi.

Cloud Spanner OLAP sifatida qanday ishlaydi?

Bo'linishmi?

Ma'lumotlarni bo'limlar deb ataladigan jismoniy va/yoki mantiqiy jihatdan mustaqil segmentlarga bo'lish ko'pchilik OLAP dvigatellarida mavjud bo'lgan juda mashhur tushunchadir. Bo'limlar so'rovlar unumdorligini va ma'lumotlar bazasini saqlashni sezilarli darajada yaxshilaydi. Bo'limlarga bo'lish haqida keyingi o'rganish alohida maqola(lar) bo'ladi, shuning uchun keling, bo'linish sxemasi va bo'linishning muhimligini eslatib o'tamiz. Ma'lumotni bo'limlarga va hatto kichik bo'limlarga bo'lish qobiliyati analitik so'rovlarni bajarish uchun kalit hisoblanadi.

Cloud Spanner o'z-o'zidan bo'limlarni qo'llab-quvvatlamaydi. U ma'lumotlarni ichki deb atalmishlarga ajratadi Split-s asosiy kalit diapazonlariga asoslangan. Cloud Spanner klasteridagi yukni muvozanatlash uchun bo'linish avtomatik ravishda amalga oshiriladi. Cloud Spanner-ning juda qulay xususiyati - bu ota-ona jadvalining asosiy yukini ajratish (boshqasi bilan aralashmagan jadval). Spanner avtomatik ravishda uning mavjudligini aniqlaydi Split boshqa ma'lumotlarga qaraganda tez-tez o'qiladigan ma'lumotlar Split-ah, va yana ajralish haqida qaror qabul qilishi mumkin. Shunday qilib, so'rovda ko'proq tugunlar ishtirok etishi mumkin, bu ham o'tkazish qobiliyatini samarali oshiradi.

Maʼlumotlar yuklanmoqdami?

Ommaviy ma'lumotlar uchun Cloud Spanner usuli odatdagi yuklash bilan bir xil. Maksimal samaradorlik uchun siz ba'zi ko'rsatmalarga amal qilishingiz kerak, jumladan:

  • Maʼlumotlaringizni asosiy kalit boʻyicha tartiblang.
  • Ularni 10 ga bo'ling *tugunlar soni alohida bo'limlar.
  • Ma'lumotlarni parallel ravishda yuklaydigan ishchi vazifalar to'plamini yarating.

Bu maʼlumotlarni yuklash barcha Cloud Spanner tugunlaridan foydalanadi.

Biz 10M qatorli ma'lumotlar to'plamini yaratish uchun A YCSB ish yukidan foydalandik.

Google Cloud Spanner: yaxshi, yomon, xunuk

* Yuklash sinovi n1-standart-32 hisoblash dvigatelida (32 vCPU, 120 GB xotira) o'tkazildi va sinov namunasi hech qachon sinovlarda qiyinchilik tug'dirmadi.
** Har qanday ishlab chiqarish ish yuki uchun 1 tugunni sozlash tavsiya etilmaydi.

Yuqorida aytib o'tilganidek, Cloud Spanner bo'linishlarni ularning yukiga qarab avtomatik ravishda qayta ishlaydi, shuning uchun testning bir necha ketma-ket takrorlanishidan keyin natijalar yaxshilanadi. Bu erda keltirilgan natijalar biz olgan eng yaxshi natijalardir. Yuqoridagi raqamlarga nazar tashlasak, klasterdagi tugunlar soni ortib borishi bilan Cloud Spanner qanday o'lchamini (yaxshi) ko'rishimiz mumkin. Ko'zga tashlanadigan raqamlar juda past o'rtacha kechikishdir, bu yuqoridagi bo'limda tavsiflanganidek, aralash ish yuklari (95% o'qish va 5% yozish) natijalaridan farq qiladi.

Masshtablash?

Cloud Spanner tugunlari sonini ko'paytirish va kamaytirish bir marta bosish bilan bajariladigan vazifadir. Agar siz ma'lumotlarni tezda yuklamoqchi bo'lsangiz, misolni maksimal darajaga ko'tarishni o'ylab ko'rishingiz mumkin (bizning holatlarimizda bu AQSH-SHARQ mintaqasida 25 tugun edi) va keyin barcha ma'lumotlardan so'ng normal yuklash uchun mos bo'lgan tugunlar sonini kamaytiring. ma'lumotlar bazasida 2 TB/tugun chegarasini yodda tutgan holda.

Bizga bu chegarani hatto ancha kichikroq ma'lumotlar bazasi bilan ham eslatib qo'ydik. Bir nechta yuk sinovlaridan so'ng, bizning ma'lumotlar bazamiz hajmi taxminan 155 GB edi va 1 tugun namunasiga kichraytirilganda, biz quyidagi xatoga yo'l qo'ydik:

Google Cloud Spanner: yaxshi, yomon, xunuk

Biz 25 tadan 2 tagacha kichraytirishga muvaffaq bo'ldik, lekin biz ikkita tugunga yopishib qoldik.

Cloud Spanner klasteridagi tugunlar sonini oshirish va kamaytirish REST API yordamida avtomatlashtirilishi mumkin. Bu, ayniqsa, gavjum soatlarda tizimdagi yukni ko'paytirishni kamaytirish uchun foydali bo'lishi mumkin.

OLAP so'rovi samaradorligi?

Biz dastlab bu qismda Spannerni baholashga ko'p vaqt ajratishni rejalashtirgan edik. Bir necha SELECT COUNT-dan so'ng, biz darhol sinov qisqa bo'lishini va Spanner OLAP uchun mos dvigatel bo'lmasligini angladik. Klasterdagi tugunlar sonidan qat'iy nazar, 10M qatorli jadvaldagi qatorlar sonini tanlash 55-60 soniya vaqtni oladi. Bundan tashqari, oraliq natijalarni saqlash uchun ko'proq xotira talab qiladigan har qanday so'rov OOM xatosi bilan muvaffaqiyatsiz tugadi.

SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.

TPC-H so'rovlari uchun ba'zi raqamlarni Todd Lipconning maqolasida topish mumkin nosql-kudu-spanner-slides.html, slaydlar 42 va 43. Bu raqamlar bizning natijalarimizga mos keladi (afsuski).

Google Cloud Spanner: yaxshi, yomon, xunuk

4. Bizning topilmalarimiz

Cloud Spanner funksiyalarining hozirgi holatini hisobga olsak, uni mavjud OLTP yechimini oddiy almashtirish sifatida ko‘rish qiyin, ayniqsa sizning ehtiyojlaringiz undan oshib ketganda. Cloud Spanner kamchiliklarini hal qilish uchun ko'p vaqt sarflash kerak bo'ladi.

Cloud Spanner-ni baholashni boshlaganimizda, biz uning boshqaruv xususiyatlari boshqa Google SQL yechimlari bilan teng yoki hech bo'lmaganda ulardan uzoqda bo'lishini kutgan edik. Ammo zaxira nusxalarining to'liq yo'qligi va resurslarga kirishni nazorat qilishning juda cheklanganligi bizni hayratda qoldirdi. Ko'rinishlar yo'q, mahalliy rivojlanish muhiti yo'q, qo'llab-quvvatlanmaydigan ketma-ketliklar, DML va DDL qo'llab-quvvatlanmaydigan JDBC va boshqalar haqida gapirmaslik kerak.

Xo'sh, tranzaktsion ma'lumotlar bazasini kengaytirish kerak bo'lgan odam uchun qaerga borish kerak? Bozorda hali barcha foydalanish holatlariga mos keladigan yagona yechim yo'qdek. Ko'plab yopiq va ochiq manbali echimlar mavjud (ularning ba'zilari ushbu maqolada aytib o'tilgan), ularning har biri o'zining kuchli va zaif tomonlariga ega, ammo ularning hech biri 99,999% SLA va yuqori darajadagi mustahkamlik bilan SaaSni taklif qilmaydi. Agar yuqori SLA sizning asosiy maqsadingiz bo'lsa va siz bir nechta bulutlar uchun o'z yechimingizni yaratishga moyil bo'lmasangiz, Cloud Spanner siz izlayotgan yechim bo'lishi mumkin. Ammo siz uning barcha cheklovlarini bilishingiz kerak.

Adolat uchun, Cloud Spanner faqat 2017 yilning bahorida ommaga chiqarildi, shuning uchun uning ba'zi mavjud kamchiliklari oxir-oqibat o'tib ketishini kutish o'rinli (umid qilamanki) va bu o'yinni o'zgartiruvchi bo'lishi mumkin. Axir, Cloud Spanner Google uchun shunchaki yon loyiha emas. Google uni boshqa Google mahsulotlari uchun asos sifatida ishlatadi. Google yaqinda Google Cloud Storage’dagi Megastore’ni Cloud Spanner’ga almashtirganida, bu Google Cloud Storage’ga global miqyosdagi ob’yektlar ro‘yxatlari uchun juda mos bo‘lishiga imkon berdi (bu hali ham shunday emas. Amazonlar S3).

Demak, hali umid bor... umid qilamiz.

Ana xolos. Maqola muallifi singari, biz ham umid qilishda davom etamiz, ammo bu haqda qanday fikrdasiz? Izohlarda yozing

Barchani bizning uyimizga tashrif buyurishga taklif qilamiz bepul vebinar unda biz sizga kurs haqida batafsil aytib beramiz "Ishlab chiquvchilar uchun AWS" OTUSdan.

Manba: www.habr.com

a Izoh qo'shish