Halo, warga Khabrovsk. Kaya biasane, kita terus nuduhake materi sing menarik sadurunge miwiti kursus anyar. Dina iki, utamane kanggo sampeyan, kita wis nerbitake artikel babagan Google Cloud Spanner pas karo peluncuran kursus kasebut .
Originally diterbitake ing .
Minangka perusahaan sing nawakake macem-macem solusi POS berbasis awan kanggo pengecer, restoran, lan penjual online ing saindenging jagad, Lightspeed nggunakake macem-macem jinis platform database kanggo macem-macem kasus panggunaan transaksional, analitis, lan telusuran. Saben platform basis data kasebut nduweni kaluwihan lan kelemahane dhewe-dhewe. Mula, nalika Google ngenalake Cloud Spanner menyang pasar - fitur sing njanjeni sing ora katon ing donya basis data relasional, kayata skalabilitas horisontal sing meh ora ana watesan lan perjanjian tingkat layanan (SLA) 99,999%. — kita ora bisa kantun kesempatan kanggo njaluk tangan kita ing!
Kanggo menehi ringkesan lengkap babagan pengalaman kita karo Cloud Spanner, uga kritéria evaluasi sing digunakake, kita bakal nyakup topik ing ngisor iki:
- Kriteria evaluasi kita
- Cloud Spanner ing ringkesan
- Assessment kita
- Temuan kita
1. Kriteria evaluasi kita
Sadurunge nyilem menyang spesifik Cloud Spanner, persamaan lan bedane karo solusi liyane ing pasar, ayo ngomong babagan kasus panggunaan utama sing dipikirake nalika nimbang ing ngendi arep nyebarake Cloud Spanner ing infrastruktur kita:
- Minangka panggantos kanggo (utama) solusi database SQL tradisional
- Carane solusi OLTP karo dhukungan OLAP
Wigati: Kanggo gamblang lan gampang mbandhingake, artikel iki mbandhingake Cloud Spanner karo varian MySQL saka kulawarga solusi GCP Cloud SQL lan Amazon AWS RDS.
Nggunakake Cloud Spanner minangka panggantos kanggo solusi database SQL tradisional
Ing lingkungan tradisional database, nalika wektu respon query database nyedhaki utawa malah ngluwihi batesan aplikasi sing wis ditemtokake (utamané amarga Tambah ing jumlah pangguna lan / utawa panjalukan), ana sawetara cara kanggo ngurangi wektu respon kanggo tingkat ditrima. Nanging, umume solusi kasebut kalebu intervensi manual.
Contone, langkah pisanan sing kudu ditindakake yaiku ndeleng macem-macem parameter database sing gegandhengan karo kinerja lan nyetel supaya cocog karo pola kasus panggunaan aplikasi. Yen iki ora cukup, sampeyan bisa milih ukuran database vertikal utawa horisontal.
Vertikal scaling aplikasi entails upgrade Kayata server, biasane kanthi nambah liyane prosesor / intine, RAM liyane, panyimpenan luwih cepet, etc. Nambahake sumber daya hardware liyane asil ing kinerja database tambah, diukur utamané ing transaksi ing kaloro, lan latensi transaksi kanggo sistem OLTP. Sistem basis data relasional (sing nggunakake pendekatan multi-threaded) kayata skala MySQL kanthi vertikal.
Ana sawetara kekurangan kanggo pendekatan iki, nanging sing paling jelas yaiku ukuran server maksimal ing pasar. Sawise watesan conto server paling gedhe wis tekan, mung ana siji pilihan: skala horisontal.
Skala horisontal minangka pendekatan ing ngendi luwih akeh server ditambahake menyang kluster, kanthi becik nambah kinerja kanthi linear nalika jumlah server ditambahake. mayoritas tradisional Sistem basis data ora skala horisontal utawa ora ukurane. Contone, MySQL bisa skala horisontal kanggo operasi maca kanthi nambahake pembaca budak, nanging ora bisa skala horisontal kanggo nulis.
Ing sisih liya, amarga sifate, Cloud Spanner bisa kanthi gampang skala horisontal kanthi intervensi minimal.
Fitur lengkap DBMS minangka layanan kudu ditaksir saka macem-macem sudut. Minangka basis, kita njupuk DBMS sing paling populer ing awan - kanggo Google, GCP Cloud SQL lan kanggo Amazon, AWS RDS. Ing penilaian kita fokus ing kategori ing ngisor iki:
- Pemetaan fitur: ukuran SQL, DDL, DML; perpustakaan sambungan / konektor, dhukungan transaksi, lan liya-liyane.
- Dhukungan pangembangan: pangembangan lan tes sing gampang.
- Dhukungan administrasi: manajemen conto - contone, nggedhekake / mudhun lan nganyarke instan; SLA, serep lan Recovery; keamanan / kontrol akses.
Nggunakake Cloud Spanner minangka solusi OLTP sing aktif OLAP
Nalika Google ora nyatakake kanthi jelas yen Cloud Spanner dirancang kanggo pangolahan analitis, nanging nuduhake sawetara atribut karo mesin liyane kayata Apache Impala & Kudu lan YugaByte, sing dirancang kanggo beban kerja OLAP.
Sanajan mung ana kemungkinan cilik yen Cloud Spanner nyakup mesin HTAP (transaksi/analisis) skala-metu sing konsisten kanthi set fitur OLAP sing bisa digunakake (luwih utawa kurang), kita mikir bakal dadi perhatian kita.
Kanthi atine, kita ndeleng kategori ing ngisor iki:
- Pemuatan data, indeks lan dhukungan partisi
- Kinerja Query lan DML
2. Cloud Spanner ing Cekakipun
Google Spanner minangka sistem manajemen basis data relasional clustered (RDBMS) sing digunakake Google kanggo sawetara layanan dhewe. Google nggawe umume kasedhiya kanggo pangguna Google Cloud Platform ing awal 2017.
Ing ngisor iki sawetara atribut Cloud Spanner:
- Kluster RDBMS Scalable Highly Konsisten: Nggunakake sinkronisasi wektu hardware kanggo njamin konsistensi data.
- Dhukungan transaksi lintas-meja: Transaksi bisa mbentang pirang-pirang tabel - ora kudu diwatesi ing siji meja (ora kaya Apache HBase utawa Apache Kudu).
- Tabel adhedhasar tombol utama: Kabeh tabel kudu duwe kunci utama (PC), sing bisa kalebu pirang-pirang kolom ing tabel. Data tabular disimpen ing urutan PC, dadi efisien banget lan cepet kanggo nggoleki PC. Kaya sistem basis PC liyane, implementasine kudu dimodelake kanthi kasus panggunaan sing wis dirancang kanggo entuk .
- Tabel belang: Tabel bisa duwe dependensi fisik ing saben liyane. Baris ing tabel anak bisa dicocogake karo baris ing tabel induk. Pendekatan iki nyepetake panelusuran kanggo hubungan sing bisa diidentifikasi sajrone fase modeling data, kayata co-locating pelanggan lan invoice.
- Indeks: Cloud Spanner ndhukung indeks sekunder. Indeks kasebut kalebu kolom sing diindeks lan kabeh kolom PC. Yen dikarepake, indeks uga bisa ngemot kolom liyane sing ora diindeks. Indeks bisa interleaved karo tabel induk kanggo nyepetake pitakon. Sawetara watesan ditrapake kanggo indeks, kayata jumlah maksimum kolom tambahan sing disimpen ing indeks. Uga, pitakon liwat indeks bisa uga ora gampang kaya ing RDBMS liyane.
"Cloud Spanner milih indeks kanthi otomatis mung ing kasus sing jarang. Utamane, Cloud Spanner ora kanthi otomatis milih indeks sekunder yen pitakonan njaluk kolom sing ora disimpen ing ".
- Service Level Agreement (SLA): Penyebaran ing siji wilayah kanthi SLA 99,99%; penyebaran multi-regional karo 99,999% SLA. Nalika SLA dhewe mung minangka persetujuan lan dudu jaminan apa wae, aku yakin wong-wong ing Google duwe data sing angel kanggo nggawe klaim sing kuat. (Kanggo referensi, 99,999% tegese 26,3 detik ora kasedhiya layanan saben wulan.)
- Liyane:
Wigati: Proyek Apache Tephra nambahake dhukungan transaksi sing ditingkatake menyang Apache HBase (uga saiki ditindakake ing Apache Phoenix minangka beta).
3. Assessment kita
Dadi, kita kabeh wis maca pratelan Google babagan keuntungan Cloud Spanner - skala horisontal sing meh ora ana watesan nalika njaga konsistensi sing dhuwur lan SLA sing dhuwur banget. Sanajan syarat kasebut, ing kasus apa wae, angel banget digayuh, tujuane ora kanggo mbantah. Nanging, ayo fokus ing bab liyane sing paling disenengi pangguna database: paritas lan kegunaan.
Kita ngevaluasi Cloud Spanner minangka panggantos kanggo Sharded MySQL
Google Cloud SQL lan Amazon AWS RDS, loro saka OLTP DBMS sing paling populer ing pasar maya, duwe fitur sing akeh banget. Nanging, kanggo skala database iki ngluwihi ukuran simpul siji, sampeyan kudu nindakake partisi aplikasi. Pendekatan iki nggawe kerumitan tambahan kanggo aplikasi lan administrasi. Kita ndeleng kepiye Spanner cocog karo skenario nggabungake pirang-pirang pecahan dadi siji lan fitur apa (yen ana) sing kudu dikorbanake.
Dhukungan SQL, DML lan DDL, uga konektor lan perpustakaan?
Pisanan, nalika miwiti karo database apa wae, sampeyan kudu nggawe model data. Yen sampeyan mikir sampeyan bisa nyambungake JDBC Spanner kanggo alat SQL favorit, sampeyan bakal nemokake sing bisa takon data karo, nanging sampeyan ora bisa nggunakake aplikasi iku kanggo nggawe tabel utawa ngowahi (DDL) utawa sembarang sisipan / nganyari / mbusak. operasi (DML). JDBC resmi Google ora ndhukung salah siji saka iki.
"Driver saiki ora ndhukung DML utawa DDL statements."
Dokumentasi Spanner
Kahanan ora luwih apik karo konsol GCP - sampeyan mung bisa ngirim pitakon PILIH. Untunge ana driver JDBC kanthi dhukungan kanggo DML lan DDL saka masyarakat, kalebu transaksi . Nalika pembalap iki migunani banget, kekurangan driver JDBC Google dhewe kaget. Untunge, Google nawakake dhukungan sing cukup jembar kanggo perpustakaan klien (adhedhasar gRPC): C#, Go, Java, node.js, PHP, Python, lan Ruby.
Panggunaan API adat Cloud Spanner sing meh wajib (amarga kekurangan DDL lan DML ing JDBC) nyebabake sawetara watesan kanggo wilayah kode sing gegandhengan kayata blumbang sambungan utawa kerangka kerja database (f.eks. Spring MVC). Biasane, nalika nggunakake JDBC, sampeyan bisa milih blumbang sambungan favorit (contone, HikariCP, DBCP, C3PO, etc.) sing dites lan bisa digunakake kanthi apik. Ing kasus API Spanner khusus, kita kudu ngandelake kerangka kerja / pools / sesi sing wis digawe dhewe.
Desain sentris kunci utama (PC) ngidini Cloud Spanner dadi cepet banget nalika ngakses data liwat PC, nanging uga ngenalake sawetara masalah pitakon.
- Sampeyan ora bisa nganyari nilai kunci utama; Sampeyan kudu mbusak entri saka PC asli lan lebokake maneh karo nilai anyar. (Iki padha karo database / mesin panyimpenan berorientasi PC liyane.)
- Sembarang statement UPDATE lan DELETE kudu nemtokake PC ing WHERE, mula ora bisa kosong DELETE kabeh statement - mesthi ana subquery, contone: UPDATE xxx WHERE id IN (PILIH id FROM table1)
- Lack opsi otomatis nambah utawa apa padha sing nyetel urutan kanggo lapangan PC. Kanggo nindakake iki, nilai sing cocog kudu digawe ing sisih aplikasi.
Indeks sekunder?
Google Cloud Spanner duwe dhukungan kanggo indeks sekunder. Iki minangka fitur sing apik banget sing ora tansah ana ing teknologi liyane. Apache Kudu saiki ora ndhukung indeks sekunder, lan Apache HBase ora ndhukung indeks langsung, nanging bisa ditambahake liwat Apache Phoenix.
Indeks ing Kudu lan HBase bisa dimodelake minangka tabel kapisah kanthi komposisi kunci primer sing beda, nanging atomisitas operasi sing ditindakake ing tabel induk lan tabel indeks sing gegandhengan kudu ditindakake ing tingkat aplikasi lan ora pati penting kanggo dileksanakake kanthi bener.
Kaya sing kasebut ing review Cloud Spanner, indeks kasebut bisa uga beda karo indeks MySQL. Mulane, ati-ati khusus kudu dijupuk nalika mbangun pitakon lan profil kanggo mesthekake yen indeks sing tepat digunakake ing ngendi perlu.
Perwakilan?
Objek sing populer lan migunani ing basis data yaiku tampilan. Padha bisa migunani kanggo akeh kasus panggunaan; loro favorit iku lapisan abstraksi logis lan lapisan keamanan. Sayange, Cloud Spanner ora ndhukung tampilan. Nanging, iki mung mbatesi sebagian amarga ora ana granularitas kanggo ijin akses ing tingkat kolom ing ngendi tampilan bisa dadi solusi sing bisa ditindakake.
Deleng dokumentasi Cloud Spanner kanggo bagean sing rincian kuota lan watesan (), ana siji khusus sing bisa dadi masalah kanggo sawetara aplikasi: Cloud Spanner metu saka kothak duwe watesan maksimal 100 database saben conto. Temenan, iki bisa dadi bottleneck utama kanggo database sing dirancang kanggo skala luwih saka 100 database. Untunge, sawise ngomong karo wakil teknis Google, kita nemokake manawa watesan iki bisa ditambah nganti meh kabeh nilai liwat Dhukungan Google.
Dhukungan pangembangan?
Cloud Spanner nawakake dhukungan basa pamrograman sing apik kanggo nggarap API. Pustaka sing didhukung resmi ana ing wilayah C#, Go, Java, node.js, PHP, Python lan Ruby. Dokumentasi kasebut cukup rinci, nanging kaya teknologi canggih liyane, komunitas cukup cilik dibandhingake karo teknologi basis data sing paling populer, sing bisa nyebabake luwih akeh wektu kanggo ngrampungake kasus utawa masalah panggunaan sing kurang umum.
Dadi, apa yen ndhukung pembangunan lokal?
Kita durung nemokake cara kanggo nggawe instance Cloud Spanner ing papan. Sing paling cedhak yaiku gambar Docker. , sing padha ing asas, nanging beda banget ing laku. Contone, CockroachDB bisa nggunakake PostgreSQL JDBC. Amarga lingkungan pangembangan kudu cedhak karo lingkungan produksi, Cloud Spanner ora cocog amarga kudu ngandelake conto Spanner lengkap. Kanggo ngirit biaya, sampeyan bisa milih conto wilayah siji.
Dhukungan administrasi?
Nggawe instance Cloud Spanner gampang banget. Sampeyan mung kudu milih antarane nggawe multi-wilayah utawa siji-wilayah Kayata, nemtokake wilayah (s) lan nomer simpul. Kurang saka siji menit, conto sampeyan bakal aktif.
Sawetara metrik dhasar bisa diakses langsung saka kaca Spanner ing Google Console. Tampilan sing luwih rinci kasedhiya liwat Stackdriver, ing ngendi sampeyan uga bisa nyetel ambang metrik lan kabijakan tandha.
Akses menyang sumber daya?
MySQL nawakake setelan ekstensif lan banget granular kanggo ijin / peran pangguna. Sampeyan bisa kanthi gampang ngatur akses menyang tabel tartamtu, utawa malah mung subset saka kolom sawijining. Cloud Spanner nggunakake alat Identity & Access Management (IAM) Google, sing mung ngidini sampeyan nyetel kabijakan lan ijin ing tingkat sing dhuwur banget. Pilihan sing paling granular yaiku resolusi tingkat basis data, sing ora cocog karo akeh kasus panggunaan produksi. Watesan iki meksa sampeyan nambah langkah keamanan tambahan menyang kode, infrastruktur, utawa loro-lorone kanggo nyegah panggunaan sumber daya Spanner sing ora sah.
Gawe serep?
Cukup, ora ana serep ing Cloud Spanner. Senajan syarat SLA dhuwur Google bisa mesthekake yen sampeyan ora kelangan data amarga hardware utawa database gagal, kesalahan manungsa, cacat aplikasi, etc.. Kita kabeh ngerti aturan: kasedhiyan dhuwur ora sulih kanggo strategi serep swara. Saiki, siji-sijine cara kanggo nggawe serep data yaiku kanthi program stream saka database menyang lingkungan panyimpenan sing kapisah.
Kinerja pitakon?
Kita nggunakake Yahoo! kanggo mbukak data lan nguji pitakon. Benchmark Layanan Cloud. Tabel ing ngisor iki nuduhake beban kerja YCSB B kanthi rasio nulis 95% nganti 5%.
* Test mbukak iki mbukak ing n1-standar-32 Compute Engine (CE) (32 vCPU, 120 memori GB), lan conto test tau bottleneck ing tes.
** Jumlah maksimum utas ing conto YCSB siji yaiku 400. Total enem conto paralel saka tes YCSB kudu ditindakake kanggo entuk total 2400 utas.
Deleng asil pathokan, utamane kombinasi beban CPU lan TPS, kita bisa ndeleng kanthi jelas manawa Cloud Spanner skala cukup apik. Beban abot sing digawe kanthi jumlah benang sing akeh diimbangi karo jumlah node sing akeh ing kluster Cloud Spanner. Nalika latensi katon cukup dhuwur, utamane nalika nganggo 2400 utas, tes maneh karo 6 mesin komputasi sing luwih cilik bisa uga dibutuhake kanggo entuk angka sing luwih akurat. Saben conto bakal mbukak siji tes YCSB tinimbang siji conto CE gedhe kanthi 6 tes paralel. Kanthi cara iki, bakal luwih gampang mbedakake antarane latensi panyuwunan Cloud Spanner lan latensi sing ditambahake dening sambungan jaringan antarane Cloud Spanner lan instance CE sing nindakake tes kasebut.
Kepiye Cloud Spanner nindakake minangka OLAP?
Pemisahan?
Dibagi data dadi bagean fisik lan / utawa logis independen, disebut partisi, iku konsep banget populer ditemokaké ing paling mesin OLAP. Partisi bisa ningkatake kinerja query lan maintainability database. Yen luwih jero babagan pemisahan bakal dadi artikel sing kapisah, mula ayo nyritakake pentinge nduwe skema pemisahan lan subpartisi. Kemampuan kanggo ngrusak data dadi partisi lan malah dadi subpartisi minangka kunci kinerja query analitik.
Cloud Spanner ora ndhukung partisi kaya ngono. Dibagi data internal dadi-disebut pamisah-s adhedhasar kisaran tombol utami. Pemisahan ditindakake kanthi otomatis kanggo ngimbangi beban ing kluster Cloud Spanner. A fitur banget migunani Cloud Spanner punika pamisahan saka beban dhasar tabel tiyang sepah (tabel sing ora interleaved karo liyane). Spanner kanthi otomatis ndeteksi manawa ngemot pamisah data sing luwih kerep diwaca tinimbang data liyane pamisah-ah, lan bisa mutusaké ing misahake luwih. Kanthi cara iki, luwih akeh simpul bisa melu panjaluk, sing uga kanthi efektif nambah throughput.
Loading data?
Cara Cloud Spanner kanggo data akeh padha karo muatan normal. Kanggo entuk kinerja maksimal, sampeyan kudu ngetutake sawetara pedoman, kalebu:
- Urut data miturut kunci utama.
- Dibagi kanthi 10 *jumlah node bagean kapisah.
- Nggawe sakumpulan tugas kerja sing ngemot data kanthi paralel.
Pemuatan data iki nggunakake kabeh simpul Cloud Spanner.
Kita nggunakake beban kerja YCSB A kanggo ngasilake set data saka 10M baris.
* Tes beban ditindakake ing mesin komputasi n1-standar-32 (32 vCPU, memori 120 GB), lan conto tes ora nate dadi bottleneck ing tes kasebut.
** Persiyapan simpul tunggal ora dianjurake kanggo beban kerja produksi apa wae.
Kaya sing kasebut ing ndhuwur, Cloud Spanner kanthi otomatis ngolah pamisah adhedhasar bebane, saengga asile nambah sawise sawetara pengulangan tes berturut-turut. Asil sing ditampilake ing kene minangka asil paling apik sing dipikolehi. Deleng nomer ing ndhuwur, kita bisa ndeleng kepiye Cloud Spanner skala (uga) amarga jumlah kelenjar ing kluster mundhak. Angka sing katon yaiku latensi rata-rata sing sithik banget, sing kontras karo asil kanggo beban kerja campuran (95% diwaca lan 5% nulis) kaya sing diterangake ing bagean ndhuwur.
Scaling?
Nambah lan nyuda jumlah simpul Cloud Spanner minangka tugas siji-klik. Yen sampeyan pengin mbukak data kanthi cepet, sampeyan bisa uga nimbang nggedhekake conto sampeyan kanthi maksimal (ing kasus kita, 25 simpul ing wilayah AS-EAST) banjur nyuda jumlah simpul sing layak kanggo muatan normal yen kabeh data wis ana. database , nuduhake watesan 2TB/node.
Kita dielingake babagan watesan iki sanajan database sing luwih cilik. Sawise sawetara tes beban, database kita ukurane udakara 155 GB, lan nalika dikurangi dadi conto 1 simpul, kita nampa kesalahan ing ngisor iki:
Kita bisa nyuda saka 25 dadi 2 kedadeyan, nanging kita macet ing rong simpul.
Nambah lan nyuda jumlah simpul ing kluster Cloud Spanner bisa kanthi otomatis nggunakake REST API. Iki bisa migunani utamane kanggo nyuda beban sistem nalika jam kerja sing sibuk.
Kinerja pitakon OLAP?
We Originally ngrancang kanggo nglampahi jumlah pinunjul saka wektu ing kita evaluasi Spanner ing bagean iki. Sawise sawetara PILIH COUNT, kita langsung nyadari yen tes bakal cendhak lan Spanner ora bakal dadi mesin sing cocog kanggo OLAP. Preduli saka jumlah simpul ing kluster, mung milih nomer larik ing tabel baris 10M njupuk antarane 55 lan 60 detik. Kajaba iku, pitakon apa wae sing mbutuhake memori luwih akeh kanggo nyimpen asil penengah gagal karo kesalahan OOM.
SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.
Sawetara nomer kanggo pitakon TPC-H bisa ditemokake ing artikel Todd Lipcon , minger 42 lan 43. Nomer iki konsisten karo asil kita dhewe (sayangé).
4. Kesimpulan kita
Amarga kahanan saiki fitur Cloud Spanner, angel mbayangno minangka panggantos sing gampang kanggo solusi OLTP sing wis ana, utamane yen kabutuhan sampeyan ngluwihi. Jumlah wektu sing signifikan kudu digunakake kanggo mbangun solusi babagan kekurangan Cloud Spanner.
Nalika kita miwiti ngevaluasi Cloud Spanner, kita ngarepake fitur-fitur manajemen sing cocog karo, utawa paling ora adoh saka solusi Google SQL liyane. Nanging kita padha kaget dening lack lengkap serep lan kontrol winates banget liwat akses kanggo sumber daya. Ora ana tampilan, ora ana lingkungan pangembangan lokal, urutan sing ora didhukung, JDBC tanpa dhukungan DML lan DDL, lan liya-liyane.
Dadi ing ngendi wong sing kudu ngukur basis data transaksional? Ora ana solusi siji ing pasar sing cocog karo kabeh kasus panggunaan. Ana akeh solusi sumber tertutup lan mbukak (sawetara sing kasebut ing artikel iki), saben duwe kekuwatan lan kelemahane dhewe, nanging ora ana sing menehi SaaS kanthi SLA 99,999% lan konsistensi dhuwur. Yen SLA dhuwur minangka tujuan utama lan sampeyan ora pengin nggawe solusi multi-cloud khusus, Cloud Spanner bisa dadi solusi sing sampeyan goleki. Nanging sampeyan kudu ngerti kabeh watesan.
Kanggo adil, Cloud Spanner mung dirilis kanggo umum ing musim semi 2017, saengga bisa nyana manawa sawetara kekurangan saiki bisa uga ilang (muga-muga), lan nalika nindakake, bisa dadi pangowahan game. Sawise kabeh, Cloud Spanner ora mung proyek sampingan kanggo Google. Google nggunakake minangka basis kanggo produk Google liyane. Lan nalika Google bubar ngganti Megastore ing Google Cloud Storage karo Cloud Spanner, iki ngidini Google Cloud Storage dadi konsisten banget kanggo dhaptar obyek ing skala global (sing isih ora kaya ngono. ).
Dadi, isih ana pangarep-arep ... kita ngarep-arep.
Mekaten. Kaya penulis artikel kasebut, kita uga terus ngarep-arep, nanging apa sampeyan mikir babagan iki? Tulis ing komentar
Kita ngajak kabeh wong kanggo ngunjungi kita ing ngendi kita bakal ngandhani kanthi rinci babagan kursus kasebut saka OTUS.
Source: www.habr.com