Kumusta, mga Khabrovites. Ayon sa kaugalian, patuloy kaming nagbabahagi ng mga kawili-wiling materyal sa bisperas ng pagsisimula ng mga bagong kurso. Ngayon, lalo na para sa iyo, nagsalin kami ng isang artikulo tungkol sa Google Cloud Spanner, na nag-time na kasabay ng paglulunsad ng kurso .
Orihinal na nai-publish sa .
Bilang isang kumpanyang nag-aalok ng iba't ibang cloud-based na solusyon sa POS para sa mga retailer, restaurateur, at online na merchant sa buong mundo, gumagamit ang Lightspeed ng ilang iba't ibang uri ng mga platform ng database para sa iba't ibang transactional, analytics, at search use case. Ang bawat isa sa mga platform ng database na ito ay may sariling mga lakas at kahinaan. Samakatuwid, noong ipinakilala ng Google ang Cloud Spanner sa merkado - mga magagandang feature na hindi nakikita sa mundo ng mga relational na database, gaya ng halos walang limitasyong pahalang na scalability at isang 99,999% service level agreement (SLA) , Hindi namin maaaring palampasin ang pagkakataon na mapasakamay namin siya!
Upang magbigay ng komprehensibong pangkalahatang-ideya ng aming karanasan sa Cloud Spanner, pati na rin ang pamantayan sa pagsusuri na ginamit namin, sasaklawin namin ang mga sumusunod na paksa:
- Ang aming pamantayan sa pagsusuri
- Cloud Spanner sa madaling sabi
- Ang aming pagtatasa
- Ang aming mga natuklasan
1. Ang aming pamantayan sa pagsusuri
Bago suriin ang mga detalye ng Cloud Spanner, ang mga pagkakatulad at pagkakaiba nito sa iba pang mga solusyon sa merkado, pag-usapan muna natin ang tungkol sa mga pangunahing kaso ng paggamit na nasa isip namin kapag isinasaalang-alang kung saan i-deploy ang Cloud Spanner sa aming imprastraktura:
- Bilang isang kapalit para sa (nangingibabaw) tradisyonal na solusyon sa database ng SQL
- Bilang isang solusyon sa OLTP na pinagana ng OLAP
Tandaan: Para sa kadalian ng paghahambing, ikinukumpara ng artikulong ito ang Cloud Spanner sa mga variant ng MySQL ng mga pamilya ng solusyon sa GCP Cloud SQL at Amazon AWS RDS.
Paggamit ng Cloud Spanner bilang kapalit ng tradisyonal na solusyon sa database ng SQL
Sa kapaligiran tradisyonal mga database, kapag ang oras ng pagtugon para sa isang query sa database ay lumalapit o lumampas pa sa mga paunang natukoy na threshold ng application (pangunahin dahil sa pagtaas ng bilang ng mga user at/o mga kahilingan), mayroong ilang mga paraan upang bawasan ang oras ng pagtugon sa mga katanggap-tanggap na antas. Gayunpaman, karamihan sa mga solusyong ito ay may kasamang manu-manong interbensyon.
Halimbawa, ang unang hakbang na dapat gawin ay tingnan ang iba't ibang mga setting ng database na nauugnay sa pagganap at ibagay ang mga ito upang pinakamahusay na tumugma sa mga pattern ng senaryo ng paggamit ng application. Kung hindi ito sapat, maaari mong piliing i-scale ang database nang patayo o pahalang.
Ang pag-scale ng isang application ay nangangailangan ng pag-update sa instance ng server, kadalasan sa pamamagitan ng pagdaragdag ng higit pang mga processor/core, higit pang RAM, mas mabilis na storage, atbp. Ang pagdaragdag ng higit pang mga mapagkukunan ng hardware ay nagreresulta sa mas mataas na pagganap ng database, na sinusukat pangunahin sa mga transaksyon sa bawat segundo, at latency ng transaksyon para sa mga OLTP system. Relational database system (na gumagamit ng multi-threaded na diskarte) tulad ng MySQL scale nang patayo.
Mayroong ilang mga kakulangan sa diskarteng ito, ngunit ang pinaka-halata ay ang maximum na laki ng server sa merkado. Kapag naabot na ang pinakamalaking limitasyon ng Server Instance, isang path na lang ang natitira: scale out.
Ang Scale-out ay isang diskarte na nagdaragdag ng higit pang mga server sa isang kumpol upang perpektong pataasin ang pagganap nang linear habang mas maraming mga server ang idinaragdag. Karamihan tradisyonal Ang mga sistema ng database ay hindi nasusukat nang maayos o hindi nasusukat. Halimbawa, ang MySQL ay maaaring mag-scale out para sa mga nabasa sa pamamagitan ng pagdaragdag ng mga mambabasa ng alipin, ngunit hindi nito mai-scale out para sa mga pagsusulat.
Sa kabilang banda, dahil sa likas na katangian nito, ang Cloud Spanner ay madaling mag-scale nang pahalang na may kaunting interbensyon.
Buong itinatampok DBMS bilang isang serbisyo dapat suriin mula sa iba't ibang pananaw. Bilang batayan, kinuha namin ang pinakasikat na DBMS sa cloud - para sa Google, GCP Cloud SQL at para sa Amazon, AWS RDS. Sa aming pagsusuri, nakatuon kami sa mga sumusunod na kategorya:
- Tampok na pagmamapa: SQL lawak, DDL, DML; mga library/konektor ng koneksyon, suporta sa transaksyon, at iba pa.
- Suporta sa Pag-unlad: Dali ng pag-unlad at pagsubok.
- Suporta sa Administrasyon: Pamamahala ng instance tulad ng pag-scale pataas/pababa at pag-upgrade ng mga pagkakataon; SLA, backup at pagbawi; kontrol sa seguridad/access.
Paggamit ng Cloud Spanner bilang isang OLAP-Enabled OLTP Solution
Bagama't hindi tahasang sinasabi ng Google na ang Cloud Spanner ay para sa analytics, nagbabahagi ito ng ilang katangian sa iba pang mga engine gaya ng Apache Impala & Kudu at YugaByte na idinisenyo para sa mga OLAP na workload.
Kahit na maliit lang ang pagkakataon na isinama ng Cloud Spanner ang isang pare-parehong scale-out na HTAP (Hybrid Transactional/Analytic Processing) engine na may (higit pa o mas kaunti) na magagamit na hanay ng feature ng OLAP, sa tingin namin ay karapat-dapat ito sa aming atensyon.
Sa pag-iisip na iyon, tiningnan namin ang mga sumusunod na kategorya:
- Pag-load ng data, pag-index at suporta sa partitioning
- Pagganap ng query at DML
2. Cloud Spanner sa madaling sabi
Ang Google Spanner ay isang clustered relational database management system (RDBMS) na ginagamit ng Google para sa ilan sa sarili nitong mga serbisyo. Ginawa itong available ng Google sa publiko sa mga user ng Google Cloud Platform noong unang bahagi ng 2017.
Narito ang ilan sa mga katangian ng Cloud Spanner:
- Highly Consistent, Scalable RDBMS Cluster: Gumagamit ng hardware time synchronization para matiyak ang pagkakapare-pareho ng data.
- Suporta sa transaksyon sa cross-table: Ang mga transaksyon ay maaaring sumasaklaw sa maraming talahanayan - hindi kinakailangang limitado sa isang talahanayan (hindi tulad ng Apache HBase o Apache Kudu).
- Mga Talahanayan na Batay sa Pangunahing Key: Ang lahat ng mga talahanayan ay dapat na may idineklarang Pangunahing Susi (PC), na maaaring binubuo ng maraming column ng talahanayan. Ang tabular na data ay iniimbak sa PC order, na ginagawang napakahusay at mabilis para sa mga paghahanap sa PC. Tulad ng iba pang mga sistemang nakabatay sa PC, ang pagpapatupad ay dapat na mamodelo laban sa naunang mga kaso ng paggamit upang makamit .
- Mga striped na talahanayan: Ang mga talahanayan ay maaaring magkaroon ng mga pisikal na dependency sa isa't isa. Maaaring itugma ang mga row ng child table sa mga row ng parent table. Pinapabilis ng diskarteng ito ang paghahanap para sa mga relasyon na maaaring matukoy sa yugto ng pagmomodelo ng data, halimbawa, kapag pinagsasama-sama ang mga customer at ang kanilang mga invoice.
- Mga Index: Sinusuportahan ng Cloud Spanner ang mga pangalawang index. Ang isang index ay binubuo ng mga naka-index na column at lahat ng PC column. Opsyonal, ang index ay maaari ding maglaman ng iba pang mga hindi naka-index na column. Maaaring i-interleaved ang index sa parent table para mapabilis ang mga query. Nalalapat ang ilang paghihigpit sa mga index, gaya ng maximum na bilang ng mga karagdagang column na maaaring iimbak sa isang index. Gayundin, ang mga query sa pamamagitan ng mga index ay maaaring hindi kasing diretso tulad ng sa ibang mga RDBMS.
βAwtomatikong pumipili ng index ang Cloud Spanner sa mga bihirang kaso. Sa partikular, hindi awtomatikong pumipili ng pangalawang index ang Cloud Spanner kung humiling ang query ng anumang mga column na hindi nakaimbak sa '.
- Service Level Agreement (SLA): Pag-deploy ng solong rehiyon na may 99,99% SLA; multi-region deployment na may 99,999% SLA. Bagama't ang mismong SLA ay isang kasunduan lamang at hindi isang garantiya ng anumang uri, naniniwala ako na ang mga tao sa Google ay may ilang mahirap na data upang gumawa ng ganoong malakas na paghahabol. (Para sa sanggunian, ang 99,999% ay nangangahulugang 26,3 segundo ng downtime ng serbisyo bawat buwan.)
- Higit pa:
Tandaan: Ang proyekto ng Apache Tephra ay nagdaragdag ng advanced na suporta sa transaksyon sa Apache HBase (na ipinapatupad din ngayon sa Apache Phoenix bilang isang beta).
3. Ang aming pagtatasa
Kaya, nabasa nating lahat ang mga pahayag ng Google tungkol sa mga benepisyo ng Cloud Spanner - halos walang limitasyong pahalang na pag-scale habang pinapanatili ang mataas na pagkakapare-pareho at napakataas na SLA. Bagama't ang mga paghahabol na ito ay, sa anumang kaso, napakahirap na makamit, ang aming layunin ay hindi pabulaanan ang mga ito. Sa halip, tumuon tayo sa iba pang mga bagay na pinapahalagahan ng karamihan sa mga gumagamit ng database: pagkakapareho at kakayahang magamit.
Ni-rate namin ang Cloud Spanner bilang kapalit ng Sharded MySQL
Ang Google Cloud SQL at Amazon AWS RDS, dalawa sa pinakasikat na OLTP database sa cloud market, ay may napakalaking set ng feature. Gayunpaman, upang ma-scale ang mga database na ito nang higit sa laki ng isang node, kailangan mong magsagawa ng paghahati ng application. Ang diskarte na ito ay lumilikha ng karagdagang kumplikado para sa parehong mga aplikasyon at pangangasiwa. Tiningnan namin kung paano umaangkop si Spanner sa senaryo ng pagsasama-sama ng maraming shards sa isang pagkakataon at kung anong mga feature (kung mayroon) ang maaaring isakripisyo.
Suporta para sa SQL, DML at DDL, pati na rin ang connector at mga aklatan?
Una, kapag nagsisimula sa anumang database, kailangan mong lumikha ng modelo ng data. Kung sa tingin mo ay maaari mong ikonekta ang JDBC Spanner sa iyong paboritong SQL tool, makikita mo na maaari mong i-query ang iyong data dito, ngunit hindi mo ito magagamit upang lumikha ng isang talahanayan o pag-update (DDL) o anumang pagsingit/pag-update/pagtanggal. mga operasyon (DML). Hindi rin sinusuportahan ng opisyal na JDBC ng Google.
"Kasalukuyang hindi sinusuportahan ng mga driver ang mga pahayag ng DML o DDL."
Dokumentasyon ng Spanner
Ang sitwasyon ay hindi mas mahusay sa GCP console - maaari ka lamang magpadala ng SELECT query. Sa kabutihang palad mayroong isang driver ng JDBC na may suporta sa DML at DDL mula sa komunidad kasama ang mga transaksyon . Bagama't lubhang kapaki-pakinabang ang driver na ito, nakakagulat ang kawalan ng sariling JDBC driver ng Google. Sa kabutihang palad, nag-aalok ang Google ng medyo malawak na suporta sa library ng kliyente (batay sa gRPC): C#, Go, Java, node.js, PHP, Python, at Ruby.
Ang halos ipinag-uutos na paggamit ng mga custom na API ng Cloud Spanner (dahil sa kakulangan ng DDL at DML sa JDBC) ay nagreresulta sa ilang mga limitasyon para sa mga nauugnay na bahagi ng code gaya ng pagsasama-sama ng koneksyon o mga framework na nagbubuklod ng database (tulad ng Spring MVC). Sa pangkalahatan, kapag gumagamit ng JDBC, malaya kang pumili ng iyong paboritong pool ng koneksyon (hal. HikariCP, DBCP, C3PO, atbp.) na nasubok at gumagana nang maayos. Sa kaso ng mga custom na Spanner API, kailangan nating umasa sa mga frameworks/binding/session pool na tayo mismo ang gumawa.
Ang pangunahing key (PC) oriented na disenyo ay nagbibigay-daan sa Cloud Spanner na maging napakabilis kapag nag-a-access ng data sa pamamagitan ng PC, ngunit nagpapakilala rin ng ilang isyu sa query.
- Hindi mo maaaring i-update ang halaga ng isang pangunahing key; Dapat mo munang tanggalin ang orihinal na entry sa PC at muling ipasok ito gamit ang bagong halaga. (Ito ay katulad ng ibang PC oriented database/storage engine.)
- Ang anumang UPDATE at DELETE na mga pahayag ay dapat tukuyin ang PC sa WHERE, samakatuwid, hindi maaaring walang laman ang DELETE lahat ng mga pahayag - dapat palaging may subquery, halimbawa: I-UPDATE xxx WHERE id IN (SELECT id FROM table1)
- Kakulangan ng opsyon sa auto-increment o katulad na bagay na nagtatakda ng sequence para sa field ng PC. Para gumana ito, dapat gawin ang katumbas na halaga sa gilid ng application.
Mga pangalawang indeks?
Ang Google Cloud Spanner ay may built-in na suporta para sa mga pangalawang index. Ito ay isang napakagandang tampok na hindi palaging naroroon sa iba pang mga teknolohiya. Kasalukuyang hindi sinusuportahan ng Apache Kudu ang mga pangalawang index, at hindi direktang sinusuportahan ng Apache HBase ang mga index, ngunit maaaring idagdag ang mga ito sa pamamagitan ng Apache Phoenix.
Ang mga index sa Kudu at HBase ay maaaring i-modelo bilang isang hiwalay na talahanayan na may iba't ibang komposisyon ng mga pangunahing key, ngunit ang atomicity ng mga operasyon na isinagawa sa parent table at mga kaugnay na index table ay dapat isagawa sa antas ng aplikasyon at hindi mahalaga na ipatupad nang tama.
Gaya ng nabanggit sa pagsusuri sa Cloud Spanner, maaaring iba ang mga index nito sa mga index ng MySQL. Kaya, ang espesyal na pangangalaga ay dapat gawin sa pagbuo ng query at pag-profile upang matiyak na ang tamang index ay ginagamit kung saan ito kinakailangan.
Representasyon?
Ang isang napaka-tanyag at kapaki-pakinabang na bagay sa isang database ay mga view. Maaari silang maging kapaki-pakinabang para sa isang malaking bilang ng mga kaso ng paggamit; ang aking dalawang paborito ay ang logical abstraction layer at ang security layer. Sa kasamaang palad HINDI sinusuportahan ng Cloud Spanner ang mga view. Gayunpaman, ito ay bahagyang naglilimita sa amin, dahil walang column-level granularity para sa mga pahintulot sa pag-access kung saan ang mga view ay maaaring maging isang katanggap-tanggap na solusyon.
Tingnan ang dokumentasyon ng Cloud Spanner para sa isang seksyong nagdedetalye ng mga quota at limitasyon (), mayroong isa sa partikular na maaaring maging problema para sa ilang mga application: Cloud Spanner out of the box ay may maximum na 100 database bawat pagkakataon. Malinaw, ito ay maaaring maging isang pangunahing hadlang para sa isang database na idinisenyo upang masukat sa higit sa 100 mga database. Sa kabutihang palad, pagkatapos makipag-usap sa aming teknikal na kinatawan ng Google, nalaman namin na ang limitasyong ito ay maaaring tumaas sa halos anumang halaga sa pamamagitan ng Google Support.
Suporta sa pag-unlad?
Nag-aalok ang Cloud Spanner ng medyo disenteng suporta sa programming language para sa pagtatrabaho sa API nito. Ang mga opisyal na sinusuportahang aklatan ay nasa lugar ng C#, Go, Java, node.js, PHP, Python, at Ruby. Ang dokumentasyon ay medyo detalyado, ngunit tulad ng iba pang mga makabagong teknolohiya, ang komunidad ay medyo maliit kumpara sa pinakasikat na mga teknolohiya ng database, na maaaring magresulta sa mas maraming oras na ginugol sa hindi gaanong karaniwang mga kaso ng paggamit o mga problema.
Kaya paano ang suporta sa lokal na pag-unlad?
Hindi kami nakahanap ng paraan para gumawa ng instance ng Cloud Spanner sa lugar. Ang pinakamalapit na nakuha namin ay isang imahe ng Docker na katulad sa prinsipyo, ngunit ibang-iba sa pagsasagawa. Halimbawa, maaaring gamitin ng CockroachDB ang PostgreSQL JDBC. Dahil ang development environment ay dapat na mas malapit hangga't maaari sa production environment, hindi perpekto ang Cloud Spanner dahil kailangan mong umasa sa isang buong instance ng Spanner. Upang makatipid ng mga gastos, maaari kang pumili ng isang instance ng rehiyon.
Suporta sa administrasyon?
Napakasimple ng paglikha ng isang Cloud Spanner instance. Kailangan mo lang pumili sa pagitan ng paglikha ng isang multi-region o isang solong rehiyon na instance, tukuyin ang (mga) rehiyon at ang bilang ng mga node. Wala pang isang minuto, gagana na ang instance.
Maraming elementarya na sukatan ang direktang available sa pahina ng Spanner sa Google Console. Available ang mas detalyadong view sa pamamagitan ng Stackdriver, kung saan maaari ka ring magtakda ng mga metric threshold at mga patakaran sa alerto.
Access sa mga mapagkukunan?
Nag-aalok ang MySQL ng malawak at napakabutil na mga setting ng pahintulot/papel ng user. Madali mong mako-customize ang access sa isang partikular na talahanayan, o kahit isang subset lang ng mga column nito. Ginagamit ng Cloud Spanner ang tool ng Google Identity & Access Management (IAM), na nagbibigay-daan lamang sa iyong magtakda ng mga patakaran at pahintulot sa napakataas na antas. Ang pinakabutil na opsyon ay ang pahintulot sa antas ng database, na hindi akma sa karamihan ng mga kaso ng produksyon. Pinipilit ka ng paghihigpit na ito na magdagdag ng mga karagdagang hakbang sa seguridad sa iyong code, imprastraktura, o pareho upang maiwasan ang hindi awtorisadong paggamit ng mga mapagkukunan ng Spanner.
Mga backup?
Sa madaling salita, walang mga backup sa Cloud Spanner. Bagama't matitiyak ng mataas na kinakailangan ng Google sa SLA na hindi ka mawawalan ng anumang data dahil sa mga pagkabigo sa hardware o database, error ng tao, mga depekto sa application, atbp. Alam nating lahat ang panuntunan: walang kapalit ang mataas na kakayahang magamit para sa isang matalinong diskarte sa pag-backup. Sa kasalukuyan, ang tanging paraan upang i-back up ang data ay ang programmatically stream nito mula sa database patungo sa isang hiwalay na storage environment.
Query performance?
Ginamit namin ang Yahoo! para mag-load ng data at mga kahilingan sa pagsubok. Benchmark ng Cloud Serving. Ipinapakita ng talahanayan sa ibaba ang workload ng B YCSB na may 95% read to 5% write ratio.
* Ang pagsubok sa pag-load ay pinatakbo sa n1-standard-32 Compute Engine (CE) (32 vCPU, 120 GB memory) at ang pagsubok na halimbawa ay hindi kailanman naging bottleneck sa mga pagsubok.
** Ang maximum na bilang ng mga thread sa isang YCSB instance ay 400. Sa kabuuan, anim na parallel instance ng YCSB test ang kinailangang patakbuhin upang makakuha ng kabuuang 2400 thread.
Kung titingnan ang mga resulta ng benchmark, lalo na ang kumbinasyon ng pag-load ng CPU at TPS, malinaw nating nakikita na ang Cloud Spanner ay kumikilos nang maayos. Ang malaking load na ginawa ng malaking bilang ng mga thread ay na-offset ng malaking bilang ng mga node sa Cloud Spanner cluster. Bagama't mukhang medyo mataas ang latency, lalo na kapag tumatakbo sa 2400 na mga thread, maaaring kailanganin itong muling suriin gamit ang 6 na mas maliliit na pagkakataon ng compute engine upang makakuha ng mas tumpak na mga numero. Ang bawat instance ay tatakbo ng isang YCSB test sa halip na isang malaking CE instance na may 6 na parallel na pagsubok. Gagawin nitong mas madaling makilala ang pagitan ng mga pagkaantala ng kahilingan sa Cloud Spanner at mga pagkaantala na idinagdag ng koneksyon sa network sa pagitan ng Cloud Spanner at ng CE instance na nagpapatakbo ng pagsubok.
Paano gumaganap ang Cloud Spanner bilang isang OLAP?
Paghati?
Ang paghahati ng data sa pisikal at/o lohikal na independiyenteng mga segment, na tinatawag na mga partisyon, ay isang napakasikat na konsepto na matatagpuan sa karamihan ng mga OLAP engine. Ang mga partisyon ay maaaring lubos na mapabuti ang pagganap ng query at pagpapanatili ng database. Ang karagdagang pagsasaliksik sa partitioning ay magiging isang hiwalay na (mga) artikulo, kaya banggitin na lang natin ang kahalagahan ng pagkakaroon ng partitioning scheme at sub-partitioning. Ang kakayahang hatiin ang data sa mga partisyon at higit pa sa mga sub-partition ay susi sa pagganap ng mga analytical na query.
Hindi sinusuportahan ng Cloud Spanner ang mga partition per se. Ito ay naghihiwalay ng data sa loob ng tinatawag na pagsibak-s batay sa mga pangunahing hanay ng key. Awtomatikong ginagawa ang partitioning para balansehin ang load sa Cloud Spanner cluster. Ang isang napaka-madaling gamitin na feature ng Cloud Spanner ay ang paghahati sa base load ng isang parent table (isang table na walang interleaved sa isa pa). Awtomatikong nade-detect ng Spanner kung naglalaman ito pagsibak data na mas madalas basahin kaysa sa data sa iba pagsibak-ah, at maaaring magpasya sa isang karagdagang paghihiwalay. Kaya, mas maraming mga node ang maaaring kasangkot sa isang kahilingan, na epektibo ring nagpapataas ng throughput.
Loading data?
Ang paraan ng Cloud Spanner para sa maramihang data ay kapareho ng para sa isang regular na pag-upload. Para sa maximum na pagganap, kailangan mong sundin ang ilang mga alituntunin, kabilang ang:
- Pagbukud-bukurin ang iyong data ayon sa pangunahing key.
- Hatiin sila ng 10*bilang ng mga node indibidwal na mga seksyon.
- Gumawa ng isang hanay ng mga gawain ng manggagawa na naglo-load ng data nang magkatulad.
Ginagamit ng pag-load ng data na ito ang lahat ng Cloud Spanner node.
Ginamit namin ang A YCSB workload para bumuo ng 10M row dataset.
* Ang pagsubok sa pag-load ay pinatakbo sa n1-standard-32 compute engine (32 vCPU, 120 GB memory) at ang pagsubok na halimbawa ay hindi kailanman naging bottleneck sa mga pagsubok.
** Hindi inirerekomenda ang 1 node setup para sa anumang workload sa produksyon.
Gaya ng nabanggit sa itaas, awtomatikong pinoproseso ng Cloud Spanner ang mga split depende sa pag-load ng mga ito, kaya bumuti ang mga resulta pagkatapos ng ilang magkakasunod na pag-ulit ng pagsubok. Ang mga resultang ipinakita dito ay ang pinakamahusay na mga resulta na aming natanggap. Kung titingnan ang mga numero sa itaas, makikita natin kung paano nasusukat (na rin) ang Cloud Spanner habang tumataas ang bilang ng mga node sa cluster. Ang mga numerong namumukod-tangi ay napakababang average na latency, na naiiba sa mga resulta mula sa magkahalong workload (95% read at 5% write) gaya ng inilarawan sa seksyon sa itaas.
Pagsusukat?
Ang pagtaas at pagpapababa ng bilang ng mga Cloud Spanner node ay isang gawaing isang pag-click. Kung gusto mong mabilis na mag-load ng data, maaaring gusto mong isaalang-alang ang pagpapalakas ng instance sa maximum (sa aming kaso, ito ay 25 node sa rehiyon ng US-EAST) at pagkatapos ay bawasan ang bilang ng mga node na angkop para sa iyong normal na pagkarga pagkatapos ng lahat ng data. sa database , isinasaisip ang 2 TB/node na limitasyon.
Pinaalalahanan kami ng limitasyong ito kahit na may mas maliit na database. Pagkatapos ng ilang pagsubok sa pag-load, ang aming database ay humigit-kumulang 155 GB ang laki, at kapag na-scale pababa sa isang 1 node na instance, nakuha namin ang sumusunod na error:
Nagawa naming i-scale pababa mula 25 hanggang 2 mga pagkakataon, ngunit kami ay natigil sa dalawang node.
Ang pagtaas at pagbabawas ng bilang ng mga node sa isang Cloud Spanner cluster ay maaaring i-automate gamit ang REST API. Maaari itong maging kapaki-pakinabang lalo na para sa pagbabawas ng tumaas na pagkarga sa system sa mga oras ng abalang.
Pagganap ng query sa OLAP?
Kami ay orihinal na nagplano na maglaan ng malaking oras sa aming pagsusuri ng Spanner sa bahaging ito. Pagkatapos ng ilang SELECT COUNTs, napagtanto namin kaagad na maikli lang ang pagsubok at HINDI magiging angkop na makina ang Spanner para sa OLAP. Anuman ang bilang ng mga node sa cluster, ang pagpili lang ng bilang ng mga row sa isang 10M row table ay tumagal ng 55 hanggang 60 segundo. Gayundin, nabigo ang anumang query na nangangailangan ng higit pang memory upang mag-imbak ng mga intermediate na resulta na may error sa OOM.
SELECT COUNT(DISTINCT(field0)) FROM usertable; β (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.
Ang ilang numero para sa mga query sa TPC-H ay matatagpuan sa artikulo ni Todd Lipcon , mga slide 42 at 43. Ang mga numerong ito ay pare-pareho sa aming sariling mga resulta (sa kasamaang palad).
4. Ang aming mga natuklasan
Dahil sa kasalukuyang estado ng mga feature ng Cloud Spanner, mahirap itong makita bilang isang simpleng kapalit para sa isang umiiral nang solusyon sa OLTP, lalo na kapag nahihigitan ito ng iyong mga pangangailangan. Malaking tagal ng oras ang kailangang gugulin sa pagbuo ng solusyon sa mga pagkukulang ng Cloud Spanner.
Noong sinimulan naming suriin ang Cloud Spanner, inaasahan namin na ang mga feature ng pamamahala nito ay kapantay ng, o hindi bababa sa hindi kalayuan, sa iba pang mga solusyon sa Google SQL. Ngunit nagulat kami sa kumpletong kakulangan ng mga backup at napakalimitadong kontrol sa pag-access sa mga mapagkukunan. Hindi banggitin ang walang mga view, walang lokal na kapaligiran sa pag-unlad, hindi suportadong mga pagkakasunud-sunod, JDBC na walang suporta sa DML at DDL, at iba pa.
Kaya, saan pupunta para sa isang taong kailangang mag-scale ng transactional database? Mukhang wala pang isang solusyon sa merkado na umaangkop sa lahat ng mga kaso ng paggamit. Maraming mga closed at open source na solusyon (ang ilan sa mga ito ay binanggit sa artikulong ito), bawat isa ay may kanya-kanyang lakas at kahinaan, ngunit wala sa mga ito ang nag-aalok ng SaaS na may 99,999% SLA at isang mataas na antas ng pagkakapare-pareho. Kung ang isang mataas na SLA ang iyong pangunahing layunin at hindi ka hilig na bumuo ng sarili mong solusyon para sa maraming ulap, maaaring ang Cloud Spanner ang solusyon na hinahanap mo. Ngunit dapat mong malaman ang lahat ng mga limitasyon nito.
Upang maging patas, ang Cloud Spanner ay inilabas lamang sa publiko noong tagsibol ng 2017, kaya makatwirang asahan na ang ilan sa mga kasalukuyang mga bahid nito ay maaaring tuluyang mawala (sana), at kapag nangyari ito, maaari itong maging isang game-changer. Pagkatapos ng lahat, ang Cloud Spanner ay hindi lamang isang side project para sa Google. Ginagamit ito ng Google bilang batayan para sa iba pang mga produkto ng Google. At nang pinalitan kamakailan ng Google ang Megastore sa Google Cloud Storage ng Cloud Spanner, pinahintulutan nito ang Google Cloud Storage na maging lubos na pare-pareho para sa mga listahan ng mga bagay sa buong mundo (na hindi pa rin ito ang kaso para sa ).
So, may pag-asa pa... umaasa tayo.
Iyon lang. Tulad ng may-akda ng artikulo, patuloy din kaming umaasa, ngunit ano ang palagay mo tungkol dito? Sumulat sa mga komento
Inaanyayahan namin ang lahat na bisitahin ang aming kung saan sasabihin namin sa iyo nang detalyado ang tungkol sa kurso mula sa OTUS.
Pinagmulan: www.habr.com