Сайн байна уу, Хабровчууд. Уламжлал ёсоор бид шинэ хичээлүүд эхлэхийн өмнөхөн сонирхолтой материалыг хуваалцсаар байна. Өнөөдөр, ялангуяа танд зориулж бид Google Cloud Spanner-ийн тухай нийтлэлийг орчуулсан бөгөөд энэ нь сургалт эхлэхтэй давхцах болно. .
Анх хэвлэгдсэн .
Дэлхий даяарх жижиглэн худалдаачид, ресторанууд болон онлайн худалдаачдад зориулсан олон төрлийн үүлэнд суурилсан POS шийдлүүдийг санал болгодог компанийн хувьд Lightspeed нь төрөл бүрийн гүйлгээ, дүн шинжилгээ, хайлтын хэрэглээний тохиолдлуудад хэд хэдэн төрлийн мэдээллийн сангийн платформыг ашигладаг. Эдгээр мэдээллийн баазын платформ тус бүр өөрийн гэсэн давуу болон сул талуудтай. Тиймээс Google Cloud Spanner-ийг зах зээлд нэвтрүүлсэн нь бараг хязгааргүй хэвтээ өргөтгөх чадвар, 99,999% үйлчилгээний түвшний гэрээ (SLA) зэрэг харилцааны мэдээллийн санд урьд өмнө хэзээ ч байгаагүй боломжуудыг бий болгосон. , Бид түүнийг гартаа байлгах боломжийг алдаж чадаагүй!
Cloud Spanner-тэй хийсэн туршлага, мөн бидний ашигласан үнэлгээний шалгууруудын талаар иж бүрэн тойм өгөхийн тулд бид дараах сэдвүүдийг авч үзэх болно.
- Бидний үнэлгээний шалгуур
- Товчхондоо Cloud Spanner
- Бидний үнэлгээ
- Бидний олдворууд
1. Бидний үнэлгээний шалгуур
Cloud Spanner-ийн онцлог, зах зээл дээрх бусад шийдлүүдтэй ижил төстэй болон ялгаатай талуудын талаар ярихаасаа өмнө Cloud Spanner-ийг дэд бүтцэд хаана байрлуулах талаар бодож байсан үндсэн хэрэглээнийхээ талаар ярилцъя.
- Уламжлалт SQL өгөгдлийн сангийн шийдлийг (зонхилох) орлуулах
- OLAP дэмжлэгтэй OLTP шийдэл болгон
Тайлбар: Харьцуулахад хялбар болгох үүднээс энэ нийтлэл нь Cloud Spanner-ийг GCP Cloud SQL болон Amazon AWS RDS шийдлийн бүлгүүдийн MySQL хувилбаруудтай харьцуулсан болно.
Cloud Spanner-ийг уламжлалт SQL өгөгдлийн сангийн шийдлийг орлуулах зорилгоор ашиглах
Байгаль орчинд уламжлалт Өгөгдлийн сангийн асуулгад хариу өгөх хугацаа нь урьдчилан тодорхойлсон хэрэглээний босго хэмжээнд ойртож эсвэл бүр давсан тохиолдолд (ялангуяа хэрэглэгчдийн тоо болон/эсвэл хүсэлтийн өсөлтөөс шалтгаалж) хариу өгөх хугацааг зөвшөөрөгдөх хэмжээнд хүртэл бууруулах хэд хэдэн арга байдаг. Гэсэн хэдий ч эдгээр шийдлүүдийн ихэнх нь гар ажиллагаатай холбоотой байдаг.
Жишээ нь, хийх эхний алхам бол гүйцэтгэлтэй холбоотой янз бүрийн мэдээллийн баазын тохиргоог харж, тэдгээрийг програмын ашиглалтын хувилбарт хамгийн сайн тохируулахын тулд тохируулах явдал юм. Хэрэв энэ нь хангалтгүй бол та өгөгдлийн санг босоо болон хэвтээ байдлаар өргөжүүлж болно.
Програмыг томруулах нь ихэвчлэн илүү процессор/цөм, илүү их RAM, илүү хурдан хадгалах гэх мэт серверийн инстанцыг шинэчлэхийг шаарддаг. Илүү их техник хангамжийн нөөцийг нэмснээр мэдээллийн сангийн гүйцэтгэлийг голчлон секундэд хийх гүйлгээгээр хэмждэг ба OLTP системийн гүйлгээний хоцролтыг нэмэгдүүлдэг. MySQL зэрэг харилцааны өгөгдлийн сангийн системүүд (олон урсгалт хандлагыг ашигладаг) босоо байдлаар сайн масштабтай.
Энэ арга нь хэд хэдэн сул талуудтай боловч хамгийн тодорхой нь зах зээл дээрх серверийн хамгийн дээд хэмжээ юм. Server Instance-ийн хамгийн том хязгаарт хүрмэгц зөвхөн нэг зам үлдэнэ: масштабыг багасгах.
Хэмжээг багасгах нь илүү олон сервер нэмэгдэхийн хэрээр гүйцэтгэлийг шугаман байдлаар нэмэгдүүлэхийн тулд кластерт илүү олон сервер нэмдэг арга юм. Олонхи уламжлалт өгөгдлийн сангийн систем нь сайн масштабтай байдаггүй эсвэл огт масштабтай байдаггүй. Жишээлбэл, MySQL нь боол уншигчийг нэмснээр уншилтын хэмжээг багасгаж болох боловч бичихэд зориулж өргөтгөх боломжгүй.
Нөгөөтэйгүүр, Cloud Spanner нь мөн чанараасаа шалтгаалан хамгийн бага хөндлөнгийн оролцоотойгоор хэвтээ чиглэлд хялбархан масштаблах боломжтой.
Бүрэн онцлогтой DBMS нь үйлчилгээ юм өөр өөр өнцгөөс дүгнэх ёстой. Үүний үндэс болгон бид Google, GCP Cloud SQL болон Amazon, AWS RDS-д зориулсан үүлэн дэх хамгийн алдартай DBMS-ийг авсан. Үнэлгээ хийхдээ бид дараахь ангилалд анхаарлаа хандуулсан.
- Онцлогын зураглал: SQL цар хүрээ, DDL, DML; холболтын сан/холбогч, гүйлгээний дэмжлэг гэх мэт.
- Хөгжлийн дэмжлэг: Хөгжүүлэх, туршихад хялбар.
- Захиргааны дэмжлэг: Инстанцуудыг өргөжүүлэх/багасгах, сайжруулах зэрэг инстанцийн удирдлага; SLA, нөөцлөх, сэргээх; аюулгүй байдал/хандалтын хяналт.
Cloud Spanner-ийг OLAP-ийг идэвхжүүлсэн OLTP шийдэл болгон ашиглах
Google нь Cloud Spanner нь аналитик шинж чанартай гэж тодорхой заагаагүй ч OLAP ажлын ачаалалд зориулагдсан Apache Impala & Kudu, YugaByte зэрэг бусад хөдөлгүүрүүдтэй зарим шинж чанаруудыг хуваалцдаг.
Cloud Spanner-д (илүү бага) ашиглах боломжтой OLAP функц бүхий HTAP (Hybrid Transactional/Analytic Processing) хөдөлгүүрийг багтаасан байх магадлал бага байсан ч энэ нь бидний анхаарлыг татахуйц байх болно гэж бид бодож байна.
Үүнийг харгалзан бид дараахь ангиллыг авч үзсэн.
- Өгөгдөл ачаалах, индексжүүлэх, хуваах дэмжлэг
- Асуулгын гүйцэтгэл ба DML
2. Товчхондоо Cloud Spanner
Google Spanner нь Google-ийн өөрийн хэд хэдэн үйлчилгээндээ ашигладаг кластерт хамааралтай мэдээллийн удирдлагын систем (RDBMS) юм. Google үүнийг 2017 оны эхээр Google Cloud Platform-ын хэрэглэгчдэд нээлттэй болгосон.
Cloud Spanner-ийн зарим шинж чанарууд энд байна:
- Өндөр тууштай, өргөтгөх боломжтой RDBMS кластер: Өгөгдлийн тогтвортой байдлыг хангахын тулд техник хангамжийн цагийн синхрончлолыг ашигладаг.
- Хүснэгт хоорондын гүйлгээний дэмжлэг: Гүйлгээ нь олон хүснэгтийг хамрах боломжтой - зөвхөн нэг хүснэгтээр хязгаарлагдах албагүй (Apache HBase эсвэл Apache Kudu-аас ялгаатай).
- Үндсэн түлхүүрт суурилсан хүснэгтүүд: Бүх хүснэгтүүд нь зарлагдсан үндсэн түлхүүртэй байх ёстой (PC) бөгөөд энэ нь олон хүснэгтийн баганаас бүрдэх боломжтой. Хүснэгтийн өгөгдлийг компьютерийн дарааллаар хадгалдаг бөгөөд энэ нь компьютер хайлт хийхэд маш үр дүнтэй бөгөөд хурдан болгодог. Бусад компьютерт суурилсан системүүдийн нэгэн адил үр дүнд хүрэхийн тулд хэрэгжилтийг урьдчилан таамагласан хэрэглээний тохиолдлуудад загварчлах ёстой .
- Судалчлагдсан хүснэгтүүд: Хүснэгтүүд бие биенээсээ хамааралтай байж болно. Хүүхдийн хүснэгтийн мөрүүдийг эцэг эхийн хүснэгтийн мөрүүдтэй тааруулж болно. Энэ арга нь өгөгдлийн загварчлалын үе шатанд, жишээлбэл, үйлчлүүлэгчид болон тэдний нэхэмжлэхийг хамтад нь байрлуулах үед тодорхойлж болох харилцааг хайх ажлыг хурдасгадаг.
- Индексүүд: Cloud Spanner нь хоёрдогч индексүүдийг дэмждэг. Индекс нь индексжүүлсэн баганууд болон PC-ийн бүх баганаас бүрдэнэ. Сонголтоор, индекс нь бусад индексжүүлээгүй багануудыг агуулж болно. Асуултыг хурдасгахын тулд индексийг эх хүснэгттэй холбож болно. Индексэд хадгалах боломжтой нэмэлт баганын дээд хэмжээ гэх мэт хэд хэдэн хязгаарлалтууд индексүүдэд хамаарна. Түүнчлэн, индексээр дамжуулан асуулга хийх нь бусад RDBMS-тэй адил хялбар биш байж магадгүй юм.
"Cloud Spanner нь зөвхөн ховор тохиолдолд индексийг автоматаар сонгодог. Ялангуяа, асуулгад хадгалагдаагүй баганыг хүссэн тохиолдолд Cloud Spanner нь хоёрдогч индексийг автоматаар сонгохгүй. ".
- Үйлчилгээний түвшний гэрээ (SLA): 99,99% SLA-тай нэг бүс нутагт байршуулах; 99,999% SLA-тай олон бүс нутагт байршуулалт. Хэдийгээр SLA нь зөвхөн гэрээ бөгөөд ямар нэгэн баталгаа биш боловч Google-ийн хүмүүст ийм хүчтэй нэхэмжлэл гаргахад хэцүү мэдээлэл байгаа гэдэгт би итгэдэг. (Лавлах үүднээс 99,999% гэдэг нь сард 26,3 секундын үйлчилгээний зогсолтыг хэлнэ.)
- Дэлгэрэнгүй:
Тайлбар: Apache Tephra төсөл нь Apache HBase-д гүйлгээний дэвшилтэт дэмжлэгийг нэмдэг (мөн одоо Apache Phoenix-д бета хувилбараар хэрэгжиж байна).
3. Бидний үнэлгээ
Тиймээс бид бүгдээрээ Google-ийн Cloud Spanner-ийн ашиг тусын талаарх мэдэгдлүүдийг уншсан - бараг хязгааргүй хэвтээ масштаблахын зэрэгцээ өндөр тогтвортой байдал, маш өндөр SLA. Хэдийгээр эдгээр мэдэгдлийг биелүүлэхэд туйлын хэцүү боловч бидний зорилго бол тэдгээрийг няцаах явдал биш байв. Үүний оронд ихэнх мэдээллийн баазын хэрэглэгчдийн анхаардаг бусад зүйлс дээр анхаарлаа хандуулцгаая: паритет ба ашиглах боломжтой.
Бид Cloud Spanner-ийг Sharded MySQL-ийн орлуулалт гэж үнэлэв
Google Cloud SQL болон Amazon AWS RDS нь үүлэн зах зээл дээрх хамгийн алдартай OLTP мэдээллийн баазууд нь маш том функцтэй. Гэсэн хэдий ч эдгээр мэдээллийн сангуудыг нэг зангилааны хэмжээнээс хэтрүүлэхийн тулд та програмыг хуваах хэрэгтэй. Энэ арга нь хэрэглээ болон удирдлагын аль алинд нь нэмэлт төвөгтэй байдлыг бий болгодог. Бид олон хэлтэрхийг нэг жишээ болгон нэгтгэх хувилбарт Спаннер хэрхэн нийцэж байгаа болон ямар шинж чанаруудыг (хэрэв байгаа бол) золиослох шаардлагатайг харлаа.
SQL, DML болон DDL, түүнчлэн холбогч болон номын сангуудыг дэмжих үү?
Нэгдүгээрт, аливаа мэдээллийн сангаас эхлэхдээ та өгөгдлийн загвар үүсгэх хэрэгтэй. Хэрэв та JDBC Spanner-ийг өөрийн дуртай SQL хэрэглүүрт холбож чадна гэж бодож байгаа бол түүгээр өгөгдлөө асууж болох боловч хүснэгт үүсгэх, шинэчлэх (DDL) эсвэл ямар нэгэн оруулах/шинэчлэх/устгахад ашиглах боломжгүй гэдгийг олж мэдэх болно. үйл ажиллагаа (DML). Google-ийн албан ёсны JDBC нь бас дэмждэггүй.
"Драйверууд одоогоор DML эсвэл DDL мэдэгдлийг дэмждэггүй."
Түлхүүрийн баримт бичиг
GCP консол дээр нөхцөл байдал дээрдсэнгүй - та зөвхөн SELECT асуулга илгээх боломжтой. Аз болоход гүйлгээг оролцуулаад олон нийтийн зүгээс DML болон DDL дэмжлэгтэй JDBC драйвер байдаг . Хэдийгээр энэ драйвер нь маш ашигтай боловч Google-ийн өөрийн JDBC драйвер байхгүй байгаа нь гайхмаар юм. Аз болоход Google нь C#, Go, Java, node.js, PHP, Python болон Ruby зэрэг (gRPC дээр суурилсан) үйлчлүүлэгчийн номын сангийн өргөн хүрээний дэмжлэгийг санал болгодог.
Cloud Spanner-ийн захиалгат API-г бараг зайлшгүй ашиглах нь (JDBC-д DDL болон DML байхгүйн улмаас) холболтын нэгдэл эсвэл мэдээллийн баазыг холбох хүрээ (Spring MVC гэх мэт) зэрэг кодын холбогдох хэсэгт зарим хязгаарлалтыг бий болгодог. Ерөнхийдөө JDBC-г ашиглахдаа та өөрийн дуртай холболтын сан (жишээ нь HikariCP, DBCP, C3PO гэх мэт) шалгагдсан, сайн ажилладаг сонгох боломжтой. Захиалгат Spanner API-ийн хувьд бид өөрсдийн бүтээсэн фреймворк/холбох/сессийн санд найдах ёстой.
Анхдагч түлхүүр (PC) чиглүүлсэн загвар нь Cloud Spanner-ийг компьютерээр дамжуулан өгөгдөлд хандах үед маш хурдан ажиллах боломжийг олгодог боловч асуулгын зарим асуудлуудыг танилцуулдаг.
- Та үндсэн түлхүүрийн утгыг шинэчлэх боломжгүй; Та эхлээд компьютерийн анхны оруулгыг устгаж, шинэ утгаараа дахин оруулах ёстой. (Энэ нь бусад компьютерт чиглэсэн мэдээллийн сан/хадгалах системтэй төстэй юм.)
- Аливаа UPDATE болон DELETE хэллэгүүд нь WHERE-д компьютерийг зааж өгөх ёстой тул бүх мэдэгдлийг DELETE хоосон байж болохгүй - үргэлж дэд асуулга байх ёстой, жишээ нь: UPDATE xxx WHERE id IN (Хүснэгт 1-ээс SELECT id)
- Компьютерийн талбарын дарааллыг тохируулах автоматаар нэмэгдүүлэх сонголт эсвэл үүнтэй төстэй зүйл байхгүй байна. Үүнийг ажиллуулахын тулд програмын тал дээр харгалзах утгыг үүсгэсэн байх ёстой.
Хоёрдогч индексүүд үү?
Google Cloud Spanner нь хоёрдогч индексийг дэмждэг. Энэ бол бусад технологид үргэлж байдаггүй маш сайхан шинж чанар юм. Apache Kudu нь одоогоор хоёрдогч индексийг огт дэмждэггүй бөгөөд Apache HBase нь индексүүдийг шууд дэмждэггүй ч Apache Phoenix-ээр дамжуулан нэмэх боломжтой.
Kudu болон HBase дахь индексүүдийг үндсэн түлхүүрүүдийн өөр өөр найрлагатай тусдаа хүснэгт болгон загварчилж болох боловч эх хүснэгт болон холбогдох индексийн хүснэгтүүд дээр гүйцэтгэсэн үйлдлүүдийн атомыг програмын түвшинд гүйцэтгэх ёстой бөгөөд үүнийг зөв хэрэгжүүлэхэд тийм ч чухал биш юм.
Cloud Spanner тоймд дурдсанчлан түүний индексүүд MySQL индексүүдээс ялгаатай байж болно. Тиймээс, шаардлагатай үед зөв индексийг ашиглахын тулд асуулга үүсгэх, профайл үүсгэхэд онцгой анхаарал хандуулах хэрэгтэй.
Төлөөлөл?
Өгөгдлийн сангийн маш алдартай бөгөөд хэрэгтэй объект бол үзэл бодол юм. Эдгээр нь олон тооны хэрэглээний тохиолдлуудад ашигтай байж болно; Миний дуртай хоёр зүйл бол логик хийсвэр давхарга ба хамгаалалтын давхарга юм. Харамсалтай нь Cloud Spanner нь үзэл бодлыг дэмждэггүй. Гэсэн хэдий ч, үзэл бодол нь хүлээн зөвшөөрөгдөх шийдэл байж болох хандалтын зөвшөөрлийн баганын түвшний нарийвчлал байхгүй тул энэ нь биднийг хэсэгчлэн хязгаарладаг.
Квот болон хязгаарыг нарийвчлан харуулсан хэсгийг Cloud Spanner баримтаас харна уу (), зарим програмын хувьд асуудалтай байж болох нэг зүйл байдаг: Cloud Spanner нь нэг жишээнд хамгийн ихдээ 100 мэдээллийн сантай байдаг. Мэдээжийн хэрэг, энэ нь 100 гаруй мэдээллийн сантай ажиллахад зориулагдсан мэдээллийн санд томоохон саад учруулдаг. Аз болоход, Google-ийн техникийн төлөөлөгчтэй ярилцсаны дараа бид энэ хязгаарыг Google-ийн тусламжаар бараг ямар ч үнэ цэнэ болгон нэмэгдүүлэх боломжтой гэдгийг олж мэдсэн.
Хөгжлийн дэмжлэг?
Cloud Spanner нь API-тай ажиллахад тохиромжтой програмчлалын хэлний дэмжлэгийг санал болгодог. Албан ёсоор дэмжигдсэн номын сангууд нь C#, Go, Java, node.js, PHP, Python, Ruby зэрэгт байдаг. Баримт бичгүүд нь нэлээд нарийвчилсан боловч бусад дэвшилтэт технологийн нэгэн адил олон нийтийн мэдээллийн сангийн хамгийн түгээмэл технологитой харьцуулахад маш бага байдаг нь нийтлэг хэрэглээний тохиолдол, асуудалд илүү их цаг зарцуулдаг.
Тэгвэл орон нутгийн хөгжлийг дэмжих талаар юу хэлэх вэ?
Бид газар дээр нь Cloud Spanner жишээ үүсгэх арга олоогүй байна. Бидэнд хамгийн ойр байгаа нь Докерын зураг юм Энэ нь зарчмын хувьд ижил төстэй боловч бодит байдал дээр тэс өөр. Жишээлбэл, CockroachDB нь PostgreSQL JDBC ашиглаж болно. Хөгжлийн орчин нь үйлдвэрлэлийн орчинд аль болох ойр байх ёстой тул Cloud Spanner нь тийм ч тохиромжтой биш тул та бүрэн Spanner жишээн дээр найдах хэрэгтэй. Зардлаа хэмнэхийн тулд та нэг бүс нутгийн жишээг сонгож болно.
Захиргааны дэмжлэг?
Cloud Spanner жишээ үүсгэх нь маш энгийн. Та зүгээр л олон бүс эсвэл нэг бүсийн жишээ үүсгэхийн аль нэгийг сонгох хэрэгтэй, бүс(үүд) болон зангилааны тоог зааж өгөх хэрэгтэй. Нэг минут хүрэхгүй хугацаанд инстанс ажиллаж эхлэх болно.
Хэд хэдэн энгийн хэмжигдэхүүнийг Google Консол дахь Spanner хуудаснаас шууд авах боломжтой. Илүү нарийвчилсан харагдацыг Stackdriver-ээр дамжуулан авах боломжтой бөгөөд та метрийн босго болон анхааруулах бодлогыг тохируулах боломжтой.
Эх сурвалжид хандах уу?
MySQL нь өргөн, маш нарийн хэрэглэгчийн зөвшөөрөл/үүргийн тохиргоог санал болгодог. Та тодорхой хүснэгт, тэр ч байтугай баганын дэд хэсэг рүү хандах хандалтыг хялбархан өөрчлөх боломжтой. Cloud Spanner нь Google Identity & Access Management (IAM) хэрэгслийг ашигладаг бөгөөд энэ нь зөвхөн бодлого, зөвшөөрлийг маш өндөр түвшинд тохируулах боломжийг олгодог. Хамгийн нарийн сонголт бол мэдээллийн сангийн түвшний зөвшөөрөл бөгөөд ихэнх үйлдвэрлэлийн тохиолдолд тохирохгүй. Энэхүү хязгаарлалт нь таныг Spanner нөөцийг зөвшөөрөлгүй ашиглахаас сэргийлэхийн тулд код, дэд бүтэц эсвэл хоёуланд нь аюулгүй байдлын нэмэлт арга хэмжээ авахыг шаарддаг.
Нөөцлөлт үү?
Энгийнээр хэлэхэд Cloud Spanner-д нөөцлөлт байхгүй. Google-ийн өндөр SLA шаардлагууд нь техник хангамж эсвэл мэдээллийн сангийн алдаа, хүний алдаа, програмын согог гэх мэтийн улмаас таныг ямар ч өгөгдөл алдахгүй байх баталгааг хангаж чадна. Бид бүгд дүрмийг мэддэг: өндөр хүртээмжтэй байх нь ухаалаг нөөцлөлтийн стратегийг орлож чадахгүй. Одоогийн байдлаар өгөгдлийг нөөцлөх цорын ганц арга бол мэдээллийн сангаас тусдаа хадгалах орчин руу программын дагуу дамжуулах явдал юм.
Гүйцэтгэлийг асуух уу?
Бид Yahoo!-г өгөгдөл ачаалах болон тестийн асуулгад ашигласан. Cloud Service Benchmark. Доорх хүснэгтэд B YCSB-ийн ажлын ачааллыг 95% унших ба 5% бичих харьцаатай харуулав.
* Ачааллын туршилтыг n1-standard-32 Compute Engine (CE) (32 vCPU, 120 ГБ санах ой) дээр явуулсан бөгөөд туршилтын жишээ нь туршилтын саад бэрхшээл болж байгаагүй.
** Нэг YCSB инстанс дахь хэлхээний хамгийн их тоо нь 400 байна. Нийтдээ 2400 хэлхээ авахын тулд YCSB тестийн зургаан зэрэгцээ туршилтыг ажиллуулах шаардлагатай болсон.
Жишиг үр дүнг, ялангуяа CPU-ийн ачаалал ба TPS-ийн хослолыг харахад Cloud Spanner нь маш сайн масштабтай байгааг бид тодорхой харж болно. Олон тооны утаснаас үүссэн их ачааллыг Cloud Spanner кластерын олон тооны зангилаагаар нөхдөг. Хэдийгээр хоцролтын хугацаа нэлээд өндөр мэт харагддаг, ялангуяа 2400 урсгалтай үед илүү нарийвчлалтай тоо гаргахын тулд тооцоолох хөдөлгүүрийн 6 жижиг тохиолдлоор дахин тест хийх шаардлагатай байж магадгүй юм. Инстанц бүр 6 зэрэгцээ тест бүхий нэг том CE жишээний оронд нэг YCSB тестийг явуулна. Энэ нь Cloud Spanner хүсэлтийн саатал болон Cloud Spanner болон туршилтыг явуулж буй CE жишээ хоорондын сүлжээний холболтоор нэмэгдсэн сааталуудыг ялгахад хялбар болгодог.
Cloud Spanner нь OLAP байдлаар хэрхэн ажилладаг вэ?
Хуваах уу?
Мэдээллийг хуваалт гэж нэрлэгддэг физик ба/эсвэл логикийн хувьд бие даасан сегментүүдэд хуваах нь ихэнх OLAP хөдөлгүүрт байдаг маш түгээмэл ойлголт юм. Хуваалтууд нь асуулгын гүйцэтгэл болон мэдээллийн баазын засвар үйлчилгээг ихээхэн сайжруулж чадна. Цаашид хуваалтын талаар судлах нь тусдаа өгүүлэл байх тул хуваах схем болон дэд хуваалттай байхын ач холбогдлыг дурдъя. Өгөгдлийг хуваалтууд болон цаашлаад дэд хуваалтууд болгон хуваах чадвар нь аналитик асуулгын гүйцэтгэлийн түлхүүр юм.
Cloud Spanner нь хуваалтыг бие даан дэмждэггүй. Энэ нь өгөгдлийг дотооддоо гэж нэрлэгддэг зүйл болгон хуваадаг хуваах-ууд нь үндсэн түлхүүрийн мужид суурилсан. Cloud Spanner кластер дээрх ачааллыг тэнцвэржүүлэхийн тулд хуваалтыг автоматаар хийдэг. Cloud Spanner-ийн маш ашигтай шинж чанар бол эх хүснэгтийн үндсэн ачааллыг (өөр хүснэгттэй холбодоггүй хүснэгт) хуваах явдал юм. Түлхүүр нь агуулж байгаа эсэхийг автоматаар илрүүлдэг хуваах бусад өгөгдлөөс илүү олон удаа уншдаг өгөгдөл хуваах-аа, цаашлаад салах шийдвэр гаргаж магадгүй. Тиймээс хүсэлтэд илүү олон зангилаа оролцож болох бөгөөд энэ нь дамжуулалтыг үр дүнтэй нэмэгдүүлдэг.
Өгөгдлийг ачаалж байна уу?
Бөөн өгөгдөлд зориулсан Cloud Spanner арга нь ердийн байршуулалттай адил байна. Хамгийн их гүйцэтгэлтэй байхын тулд та дараах зөвлөмжийг дагаж мөрдөх шаардлагатай.
- Өгөгдлөө үндсэн түлхүүрээр эрэмбэлэх.
- Тэдгээрийг 10* хуваа.зангилааны тоо бие даасан хэсгүүд.
- Өгөгдлийг зэрэгцүүлэн ачаалах ажилчдын багц ажлыг үүсгэ.
Энэ өгөгдлийн ачаалал нь бүх Cloud Spanner зангилааг ашигладаг.
Бид A YCSB ажлын ачааллыг ашиглан 10 сая мөр өгөгдлийн багц үүсгэсэн.
* Ачааллын туршилтыг n1-стандарт-32 тооцоолох хөдөлгүүр (32 vCPU, 120 ГБ санах ой) дээр явуулсан бөгөөд туршилтын жишээ нь хэзээ ч туршилтанд саад болж байгаагүй.
** Үйлдвэрлэлийн аливаа ачаалалд 1 зангилаа тохируулахыг зөвлөдөггүй.
Дээр дурдсанчлан Cloud Spanner нь ачааллаас хамааран хуваалтыг автоматаар боловсруулдаг тул туршилтын хэд хэдэн дараалсан давталтын дараа үр дүн сайжирдаг. Энд үзүүлсэн үр дүн нь бидний хүлээн авсан хамгийн сайн үр дүн юм. Дээрх тоонуудыг харвал бид кластер дахь зангилааны тоо нэмэгдэхийн хэрээр Cloud Spanner хэрхэн томорч байгааг (сайн) харж болно. Онцлох тоонууд нь хэт бага дундаж хоцролт бөгөөд энэ нь дээрх хэсэгт тайлбарласны дагуу холимог ачааллын үр дүнгээс (95% унших, 5% бичих) ялгаатай юм.
Томруулах уу?
Cloud Spanner зангилааны тоог нэмэгдүүлэх, багасгах нь нэг товшилтоор хийх ажил юм. Хэрэв та өгөгдлийг хурдан ачаалахыг хүсч байвал инстанцыг хамгийн дээд хэмжээнд хүртэл нэмэгдүүлэх талаар бодож үзээрэй (манай тохиолдолд энэ нь АНУ-ЗҮҮН бүс нутагт 25 зангилаа байсан), дараа нь бүх өгөгдлийн дараа таны хэвийн ачаалалд тохирох зангилааны тоог багасгаж болно. өгөгдлийн санд 2 TB/зангилааны хязгаарыг анхаарч үзээрэй.
Илүү жижиг мэдээллийн сантай байсан ч энэ хязгаарыг бидэнд сануулсан. Хэд хэдэн ачааллын туршилт хийсний дараа манай мэдээллийн сан 155 ГБ хэмжээтэй байсан бөгөөд 1 зангилааны жишээ болгон багасгахад дараах алдаа гарсан:
Бид 25-аас 2 тохиолдол болгон бууруулж чадсан ч хоёр цэг дээр гацсан.
Cloud Spanner кластер дахь зангилааны тоог нэмэгдүүлэх, багасгах ажлыг REST API ашиглан автоматжуулж болно. Энэ нь ялангуяа ачаалал ихтэй үед системийн ачааллыг бууруулахад тустай байж болно.
OLAP асуулгын гүйцэтгэл?
Бид анх энэ хэсэгт Спаннерын үнэлгээнд ихээхэн цаг зарцуулахаар төлөвлөж байсан. Хэд хэдэн SELECT COUNT-ийн дараа бид туршилт богино байх бөгөөд Spanner нь OLAP-д тохирохгүй гэдгийг шууд ойлгосон. Кластер дахь зангилааны тооноос үл хамааран 10М мөрийн хүснэгтийн мөрийн тоог сонгоход 55-60 секунд зарцуулдаг. Мөн завсрын үр дүнг хадгалахын тулд илүү их санах ой шаардсан аливаа асуулга OOM алдаагаар бүтэлгүйтсэн.
SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.
TPC-H асуулгын зарим тоог Тодд Липконы нийтлэлээс олж болно , слайд 42 ба 43. Эдгээр тоо нь бидний өөрсдийн үр дүнтэй нийцэж байна (харамсалтай нь).
4. Бидний олж мэдсэн зүйл
Cloud Spanner-ийн онцлогуудын өнөөгийн байдлыг харгалзан үзэхэд үүнийг одоо байгаа OLTP шийдлийг энгийн орлуулах, ялангуяа таны хэрэгцээ илүү их байх үед үүнийг харахад хэцүү байдаг. Cloud Spanner-ийн дутагдалтай талуудыг арилгахад ихээхэн цаг хугацаа шаардагдана.
Бид Cloud Spanner-ийг үнэлж эхлэхдээ түүний удирдлагын онцлог нь Google-ийн бусад SQL шийдлүүдтэй эн зэрэгцэх эсвэл ядаж л тэднээс холгүй байх болно гэж найдаж байсан. Гэхдээ нөөц хуулбар байхгүй, нөөцөд хандах хандалтын хяналт маш хязгаарлагдмал байгаад бид гайхсан. Үзэл бодол байхгүй, орон нутгийн хөгжлийн орчин байхгүй, дэмжигдээгүй дараалал, DML болон DDL дэмжлэггүй JDBC гэх мэт.
Тэгэхээр, гүйлгээний мэдээллийн санг өргөжүүлэх шаардлагатай хүн хаана хандах вэ? Бүх хэрэглээнд тохирсон ганц шийдэл зах зээл дээр хараахан гараагүй бололтой. Хаалттай, нээлттэй эхийн олон шийдлүүд байдаг (заримыг нь энэ нийтлэлд дурдсан) тус бүр өөрийн гэсэн давуу болон сул талуудтай боловч тэдгээрийн аль нь ч 99,999% SLA, өндөр тогтвортой байдлын түвшинтэй SaaS-ийг санал болгодоггүй. Хэрэв өндөр SLA бол таны үндсэн зорилго бөгөөд та олон үүлэнд зориулсан өөрийн шийдлийг бүтээх хүсэлгүй байгаа бол Cloud Spanner нь таны хайж буй шийдэл байж магадгүй юм. Гэхдээ та түүний бүх хязгаарлалтыг мэдэж байх ёстой.
Шударга байхын тулд Cloud Spanner нь зөвхөн 2017 оны хавар олон нийтэд гарсан тул одоо байгаа зарим дутагдлууд нь яваандаа арилж магадгүй (найдвартай байна) мөн арилвал тоглоомыг өөрчилнө гэж найдаж байна. Эцсийн эцэст, Cloud Spanner нь Google-ийн зөвхөн хажуугийн төсөл биш юм. Google үүнийг бусад Google бүтээгдэхүүний үндэс болгон ашигладаг. Google саяхан Google Cloud Storage дахь Megastore-г Cloud Spanner-ээр сольсноор Google Cloud Storage нь дэлхийн хэмжээний объектын жагсаалтад маш их нийцэх боломжийг олгосон (энэ нь одоо ч тийм биш юм. ).
Тэгэхээр итгэл найдвар байсаар л байна... бид найдаж байна.
Тэгээд л болоо. Өгүүллийн зохиогчийн нэгэн адил бид ч бас найдаж байна, гэхдээ та энэ талаар юу гэж бодож байна вэ? Сэтгэгдэл дээр бичээрэй
Хүн бүрийг манайхаар зочлохыг урьж байна Бид танд сургалтын талаар дэлгэрэнгүй ярих болно OTUS-аас.
Эх сурвалж: www.habr.com