Саламатсыздарбы, Хабаровск шаарынын тургундары. Адаттагыдай эле, биз жаңы курстардын башталышынын алдында кызыктуу материалдар менен бөлүшүүнү улантабыз. Бүгүн, өзгөчө, сиз үчүн, биз курстун башталышына тушташ 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 варианттары менен салыштырылат.
салттуу SQL маалымат базасын чечүү үчүн алмаштыруу катары Cloud Spanner колдонуу
Айлана-чөйрөдө салттуу берилиштер базасы, маалымат базаларынын суроо-жооп убактысы алдын ала аныкталган тиркеме босогосуна жакындаганда же ал тургай ашып кетсе (негизинен колдонуучулардын жана/же суроо-талаптардын санынын көбөйүшүнө байланыштуу), жооп берүү убактысын алгылыктуу деңгээлге чейин кыскартуунун бир нече жолу бар. Бирок, бул чечимдердин көбү кол менен кийлигишүүнү камтыйт.
Мисалы, биринчи кадам - бул өндүрүмдүүлүккө байланыштуу ар кандай маалымат базасынын параметрлерин карап чыгуу жана аларды тиркемени колдонуу учурунун үлгүлөрүнө эң жакшы дал келүүгө тууралоо. Бул жетишсиз болсо, анда сиз маалымат базасын вертикалдуу же туурасынан масштабда тандай аласыз.
Тиркемени вертикалдуу масштабдоо сервердин инстанциясын жаңыртууну талап кылат, адатта, көбүрөөк процессорлорду/ядролорду, көбүрөөк оперативдүү эстутум, тезирээк сактоо ж.б. кошуу аркылуу. Көбүрөөк аппараттык ресурстарды кошуу, биринчи кезекте, экинчи транзакциялар менен өлчөнгөн маалымат базасынын натыйжалуулугун жогорулатат жана OLTP тутумдары үчүн транзакциянын кечигүү убактысы. Реляциялык маалымат базасы системалары (көп агымдуу ыкманы колдонушат), мисалы MySQL вертикалдуу масштабда.
Бул ыкманын бир нече кемчиликтери бар, бирок эң айкыны - бул рыноктогу сервердин максималдуу өлчөмү. Эң чоң сервер инстанциясынын чегине жеткенден кийин, бир гана вариант калат: горизонталдуу масштабдоо.
Горизонталдуу масштабдоо - бул кластерге көбүрөөк серверлер кошулган ыкма, серверлердин саны кошулган сайын сызыктуу түрдө иштеши жогорулайт. Көпчүлүк салттуу Берилиштер базасы системалары горизонталдык жактан жакшы эмес же такыр масштабдабайт. Мисалы, MySQL кул окурмандарды кошуу менен окуу операциялары үчүн горизонталдуу масштабдата алат, бирок жазуу үчүн горизонталдуу масштабда боло албайт.
Башка жагынан алганда, анын табиятынан улам, Cloud Spanner минималдуу кийлигишүү менен горизонталдуу масштабда оңой болот.
Толугу менен өзгөчөлөнгөн DBMS кызмат катары ар кандай бурчтардан бааланышы керек. Негиз катары биз булуттагы эң популярдуу DBMS алдык - Google, GCP Cloud SQL жана Amazon, AWS RDS үчүн. Баалоодо биз төмөнкү категорияларга басым жасадык:
- Функциянын картасы: масштаб SQL, DDL, DML; байланыш китепканалары/коннекторлор, транзакцияларды колдоо ж.б.у.с.
- Өнүктүрүү колдоо: жеңил иштеп чыгуу жана сыноо.
- Администрациялык колдоо: инстанцияларды башкаруу - мисалы, инстанцияларды чоңойтуу/кичирейтүү жана өркүндөтүү; SLA, резервдик көчүрүү жана калыбына келтирүү; коопсуздук/кирүү мүмкүнчүлүгүн көзөмөлдөө.
Cloud Spannerди OLAP иштетилген OLTP чечими катары колдонуу
Google Cloud Spanner аналитикалык иштетүү үчүн иштелип чыккан деп ачык ырастабаса да, OLAP жүктөөлөрү үчүн иштелип чыккан Apache Impala & Kudu жана YugaByte сыяктуу башка кыймылдаткычтар менен кээ бир атрибуттарды бөлүшөт.
Cloud Spanner ырааттуу масштабдуу HTAP (гибриддик транзакция/аналитика иштетүү) кыймылдаткычын (аздыр-көптүр) колдонууга жарамдуу OLAP функцияларын камтыган аз гана мүмкүнчүлүк болсо да, биз ага көңүл бурууга татыктуу деп ойлойбуз.
Муну эске алып, биз төмөнкү категорияларды карап чыктык:
- Маалыматтарды жүктөө, индекстер жана бөлүү колдоо
- Query Performance жана DML
2. Кыскача Cloud Spanner
Google Spanner – бул Google өзүнүн бир нече кызматтары үчүн колдонгон кластердик реляциялык маалымат базасын башкаруу системасы (RDBMS). Google аны Google Cloud Platform колдонуучуларына 2017-жылдын башында жалпысынан жеткиликтүү кылган.
Бул жерде Cloud Spanner атрибуттарынын айрымдары:
- Жогорку ырааттуу масштабдалуучу RDBMS кластери: Маалыматтардын ырааттуулугун камсыз кылуу үчүн аппараттык убакыт синхрондоштурууну колдонот.
- Таблицалар аралык транзакцияларды колдоо: Транзакциялар бир нече таблицаларды камтышы мүмкүн - сөзсүз түрдө бир таблица менен чектелбейт (Apache HBase же Apache Kudu айырмаланып).
- Негизги ачкычка негизделген таблицалар: Бардык таблицаларда таблицада бир нече тилкеден турушу мүмкүн болгон жарыяланган баштапкы ачкыч (PC) болушу керек. Таблица маалыматтары PC тартибинде сакталат, бул аны PC издөө үчүн абдан натыйжалуу жана тез кылат. Башка PC негизделген системалар сыяктуу эле, ишке ашыруу жетүү үчүн алдын ала иштелип чыккан колдонуу учурлары менен моделдештирилиши керек .
- Сызык столдор: Таблицалар бири-бирине физикалык көз каранды болушу мүмкүн. Бала таблицадагы саптарды ата-энелик таблицадагы саптарга дал келтирсе болот. Бул ыкма кардарларды жана алардын эсеп-фактураларын чогуу жайгаштыруу сыяктуу маалыматтарды моделдөө баскычында аныктала турган мамилелерди издөөнү тездетет.
- Индекстер: Cloud Spanner кошумча индекстерди колдойт. Индекс индекстелген тилкелерден жана бардык ЖК мамычаларынан турат. Кааласаңыз, индекс башка индекстелбеген тилкелерди да камтышы мүмкүн. Суроолорду тездетүү үчүн индексти ата-энелик таблица менен аралаштырса болот. Индекстерге бир нече чектөөлөр колдонулат, мисалы, индексте сакталган кошумча тилкелердин максималдуу саны. Ошондой эле, индекстер аркылуу суроо-талаптар башка RDBMSs сыяктуу жөнөкөй болушу мүмкүн эмес.
"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 DBMS эки, өзгөчөлүктөрдүн абдан чоң топтомун камтыйт. Бирок, бул маалымат базаларын бир түйүндүн өлчөмүнөн жогору масштабдоо үчүн, сиз тиркемени бөлүштүрүү керек. Бул ыкма колдонмолор үчүн да, башкаруу үчүн дагы кошумча татаалдыкты жаратат. Биз Спаннер бир нече сыныктарды бир инстанцияга бириктирүү сценарийине кандай туура келерин жана кайсы функцияларды (эгер бар болсо) курмандыкка чалыш керектигин карап чыктык.
SQL, DML жана DDL колдоосу, ошондой эле туташтыргыч жана китепканалар?
Биринчиден, кандайдыр бир маалымат базасын баштаганда, маалымат моделин түзүү керек. Эгер сиз JDBC Spannerди сүйүктүү SQL куралыңызга туташтыра алам деп ойлосоңуз, анда сиз аны менен берилиштериңизди сурасаңыз болот, бирок аны таблица түзүү же өзгөртүү (DDL) же кандайдыр бир киргизүү/жаңыртуу/жок кылуу үчүн колдоно албайсыз. операциялар (DML). Google'дун расмий JDBC булардын бирин да колдобойт.
"Айдоочулар учурда DML же DDL билдирүүлөрүн колдобойт."
Spanner Documentation
GCP консолунда абал жакшы эмес - сиз SELECT сурамдарын гана жөнөтө аласыз. Бактыга жараша, коомчулуктун DML жана DDL колдоосу менен JDBC драйвери бар, анын ичинде транзакциялар . Бул драйвер абдан пайдалуу болгону менен, Google'дун өзүнүн JDBC драйверинин жоктугу таң калтырат. Бактыга жараша, Google кардарлардын китепканалары үчүн (gRPC негизинде) кыйла кеңири колдоону сунуштайт: C#, Go, Java, node.js, PHP, Python жана Ruby.
Cloud Spanner ыңгайлаштырылган API'лерин дээрлик милдеттүү түрдө колдонуу (JDBCде DDL жана DML жоктугуна байланыштуу) байланыштуу код аймактарына, мисалы, туташуу бассейндери же маалымат базасын байланыштыруучу алкактары (мисалы, Spring MVC) үчүн кээ бир чектөөлөргө алып келет. Адатта, JDBC колдонуп жатканда, сиз сүйүктүү байланыш пулун (мисалы, HikariCP, DBCP, C3PO ж.б.) тандай аласыз, ал сыналган жана жакшы иштейт. Ыңгайлаштырылган Spanner API'леринде, биз өзүбүз түзгөн алкактарга/милдеттүү бассейндерге/сессияларга таянышыбыз керек.
Негизги ачкыч (PC) борборлоштурулган дизайны Cloud Spanner'ге компьютер аркылуу берилиштерге жетүүдө абдан тез болууга мүмкүндүк берет, бирок ошондой эле кээ бир суроо маселелерин киргизет.
- Негизги ачкыч маанисин жаңырта албайсыз; Сиз адегенде баштапкы компьютерден жазууну жок кылып, аны жаңы маани менен кайра киргизишиңиз керек. (Бул башка компьютерге багытталган маалымат базасы/сактоо кыймылдаткычтарына окшош.)
- Ар кандай UPDATE жана DELETE операторлору КАЙДА ЖКны көрсөтүшү керек, андыктан бардык билдирүүлөрдү DELETE бош болбошу керек - ар дайым подсуроо болушу керек, мисалы: UPDATE xxx WHERE id IN (таблицадан ИДЕНТИФИКТИ ТАҢДАҢЫЗ)
- Автоматтык өсүү опциясынын же PC талаасынын ырааттуулугун орноткон ушуга окшош нерсенин жоктугу. Бул иштеши үчүн, колдонмо тарапта тиешелүү маани түзүлүшү керек.
Экинчи даражадагы көрсөткүчтөр?
Google Cloud Spanner кошумча индекстер үчүн орнотулган колдоосуна ээ. Бул башка технологияларда дайыма боло бербеген абдан жакшы өзгөчөлүк. Apache Kudu учурда экинчи даражадагы индекстерди колдобойт, ал эми Apache HBase индекстерди түз колдобойт, бирок аларды Apache Phoenix аркылуу кошо алат.
Kudu жана HBaseдеги индекстерди баштапкы ачкычтардын башка курамы менен өзүнчө таблица катары моделдештирүүгө болот, бирок ата-энелик таблицада жана ага байланышкан индекс таблицаларында аткарылган операциялардын атомдуулугу колдонмо деңгээлинде аткарылышы керек жана туура ишке ашыруу үчүн анча маанилүү эмес.
Cloud Spanner кароосунда айтылгандай, анын индекстери MySQL индекстеринен айырмаланышы мүмкүн. Ошондуктан, суроо-талаптарды курууда жана профилдештирүү учурунда тийиштүү индекстин керектүү жерде колдонулушун камсыз кылуу үчүн өзгөчө кылдаттык керек.
өкүлчүлүк?
Маалыматтар базасындагы абдан популярдуу жана пайдалуу объект бул көрүнүштөр. Алар көп сандагы колдонуу учурлары үчүн пайдалуу болушу мүмкүн; Менин эки сүйүктүүлөрүм - логикалык абстракция катмары жана коопсуздук катмары. Тилекке каршы, Cloud Spanner көрүүлөрдү КОЛДОЙТ. Бирок, бул бизди жарым-жартылай гана чектейт, анткени мамыча деңгээлинде кирүү уруксаттары үчүн эч кандай майда-бараттуулук жок, мында көрүнүштөр жашоого ылайыктуу чечим болушу мүмкүн.
Квоталарды жана чектөөлөрдү (), кээ бир колдонмолор үчүн көйгөйлүү болушу мүмкүн болгон өзгөчө бирөө бар: кутудан чыккан Cloud Spanner бир инстанцияда эң көп дегенде 100 маалымат базасынын чегине ээ. Албетте, бул 100дөн ашык маалымат базасына чейин масштабдалуу үчүн иштелип чыккан маалымат базасы үчүн чоң тоскоолдук болушу мүмкүн. Бактыга жараша, Google'дун техникалык өкүлү менен сүйлөшкөндөн кийин, биз бул чекти Google Колдоо аркылуу дээрлик бардык мааниге чейин жогорулатууга болорун билдик.
Өнүктүрүү колдоо?
Cloud Spanner анын API менен иштөө үчүн абдан татыктуу программалоо тилин колдоону сунуш кылат. Расмий түрдө колдоого алынган китепканалар C#, Go, Java, node.js, PHP, Python жана Ruby аймактарында. Документация кыйла деталдуу, бирок башка алдыңкы технологиялар сыяктуу эле, коомчулук эң популярдуу маалымат базасы технологияларына салыштырмалуу абдан кичинекей, бул азыраак колдонулган учурларды же көйгөйлөрдү чечүүгө көбүрөөк убакытты талап кылат.
Анда жергиликтүү өнүгүүнү колдоо жөнүндө эмне айтууга болот?
Cloud Spanner инстанциясын жер-жерлерде түзүүнүн жолун таба элекпиз. Бизге эң жакын нерсе Docker сүрөтү болду. , бул принцип боюнча окшош, бирок иш жүзүндө абдан айырмаланат. Мисалы, 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. Төмөнкү таблицада 95% окуу жана 5% жазуу катышы менен YCSB жумуш жүгү B көрсөтүлгөн.
* Жүктөлгөн сыноо n1-стандартты-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 мындай бөлүктөрдү колдобойт. Ал ички маалыматтарды деп аталганга бөлөт жаруу-s негизги ачкыч диапазондоруна негизделген. Cloud Spanner кластериндеги жүктү тең салмактоо үчүн бөлүү автоматтык түрдө аткарылат. Cloud Spannerдин абдан пайдалуу өзгөчөлүгү - бул ата-энелик таблицанын негизги жүгүн (башка менен аралаштырылбаган таблица) бөлүү. Spanner анын камтылганын автоматтык түрдө аныктайт жаруу башкаларга караганда көбүрөөк окулуучу маалыматтар жаруу-аа, жана андан ары бөлүү жөнүндө чечим кабыл алышы мүмкүн. Ошентип, суроо-талапка көбүрөөк түйүндөр тартылышы мүмкүн, бул да өткөрүү жөндөмдүүлүгүн натыйжалуу жогорулатат.
Дайындар жүктөлүп жатабы?
Жаппай берилиштер үчүн Cloud Spanner ыкмасы кадимки жүктөөдөгүдөй. максималдуу аткарууга жетүү үчүн, сиз, анын ичинде кээ бир көрсөтмөлөрдү аткаруу керек:
- Дайындарыңызды негизги ачкыч боюнча иреттеңиз.
- Аларды 10го бөлүңүз*түйүндөрдүн саны өзүнчө бөлүмдөр.
- Дайындарды параллелдүү жүктөй турган жумуш тапшырмаларынын топтомун түзүңүз.
Бул дайындарды жүктөө бардык Cloud Spanner түйүндөрүн колдонот.
Биз 10 миллион саптан турган берилиштер топтомун түзүү үчүн YCSB жумуш жүгүн колдондук.
* Жүктөлгөн сыноо n1-standard-32 эсептөө кыймылдаткычында (32 vCPU, 120 ГБ эстутум) аткарылган жана сыноо инстанциясы эч качан сыноолордо тоскоолдук болгон эмес.
**Бир түйүн орнотуу ар кандай өндүрүштүк жүктөм үчүн сунушталбайт.
Жогоруда айтылгандай, Cloud Spanner автоматтык түрдө бөлүнүүлөрдү алардын жүгүнө жараша иштетет, андыктан натыйжалар бир нече ирет кайталанган сыноодон кийин жакшырат. Бул жерде берилген жыйынтыктар биз алган эң жакшы натыйжалар. Жогорудагы сандарды карап, кластердеги түйүндөрдүн саны көбөйгөн сайын Cloud Spanner кандай масштабда (жакшы) экенин көрө алабыз. Жогорудагы бөлүмдө сүрөттөлгөндөй, аралаш жүктөмдөрдүн (95% окуу жана 5% жазуу) натыйжаларынан айырмаланып турган өтө төмөн орточо кечигүү сандары өзгөчөлөнөт.
Масштабтоо?
Cloud Spanner түйүндөрүнүн санын көбөйтүү жана азайтуу бир чыкылдатуу менен аткарыла турган иш. Дайындарды тез жүктөөнү кааласаңыз, инстанцияңызды максималдуу жогорулатууну (биздин учурда бул АКШ-Чыгыш аймагында 25 түйүн болгон) жана бардык маалыматтар киргизилгенден кийин кадимки жүктөө үчүн жарамдуу түйүндөрдүн санын азайтууну ойлонушуңуз мүмкүн. маалымат базасы , 2TB/түйүн чегине шилтеме.
Бизге бул чекти бир топ кичинекей маалымат базасы менен да эске салдык. Бир нече жүктөө сыноолорунан кийин, биздин маалымат базабыздын көлөмү болжол менен 155 ГБ болгон жана 1 түйүн инстанциясына чейин кичирейткенде, биз төмөнкү катаны алдык:
Биз 25тен 2 инстанцияга чейин кыскарта алдык, бирок биз эки түйүндө тыгылып калдык.
Cloud Spanner кластериндеги түйүндөрдүн санын көбөйтүү жана азайтуу REST API аркылуу автоматташтырылышы мүмкүн. Бул өзгөчө жумуш убактысында системанын жүгүн көбөйтүү үчүн пайдалуу болушу мүмкүн.
OLAP сурамдарынын аткарылышы?
Биз башында бул бөлүгүндө Спаннерди баалоого көп убакыт коротууну пландаштырганбыз. Бир нече SELECT COUNTs өткөндөн кийин, биз тестирлөө кыска болорун жана 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дан.
Source: www.habr.com