Halo, warga Khabrovsk. Sapertos biasa, urang teraskeun ngabagi bahan anu pikaresepeun sateuacan ngamimitian kursus-kursus énggal. Dinten ayeuna, khususna pikeun anjeun, kami parantos nyebarkeun tulisan ngeunaan Google Cloud Spanner pikeun pas sareng peluncuran kursus .
Asalna diterbitkeun dina .
Salaku parusahaan nu nawarkeun rupa-rupa solusi POS dumasar-awan ka retailers, restaurateurs, sarta sellers online sakuliah dunya, Lightspeed ngagunakeun sababaraha tipena béda platform database pikeun rupa-rupa transactional, analitik, jeung kasus pamakéan pilarian. Masing-masing platform database ieu gaduh kaunggulan sareng kalemahan sorangan. Lantaran kitu, nalika Google ngenalkeun Cloud Spanner ka pasar - fitur ngajangjikeun anu teu katingali di dunya basis data relasional, sapertos skalabilitas horizontal anu ampir henteu terbatas sareng perjanjian tingkat layanan (SLA) 99,999%. - urang teu bisa sono kasempetan pikeun meunang leungeun kami dina eta!
Pikeun masihan gambaran komprehensif ngeunaan pangalaman urang sareng Cloud Spanner, sareng kriteria evaluasi anu kami anggo, kami bakal nutupan topik ieu:
- Kriteria evaluasi urang
- Awan Spanner dina nutshell
- Penilaian urang
- Papanggihan urang
1. Kritéria meunteun urang
Sateuacan nyilem kana spésifik Cloud Spanner, kamiripan sareng bédana sareng solusi anu sanés di pasar, hayu urang bahas heula ngeunaan kasus pamakean utama anu urang émut nalika nimbang-nimbang dimana nyebarkeun Cloud Spanner dina infrastruktur urang:
- Salaku gaganti pikeun (utama) solusi database SQL tradisional
- Kumaha solusi OLTP kalayan dukungan OLAP
Catetan: Pikeun kesederhanaan sareng gampang ngabandingkeun, tulisan ieu ngabandingkeun Cloud Spanner sareng varian MySQL tina kulawarga solusi GCP Cloud SQL sareng Amazon AWS RDS.
Ngagunakeun Cloud Spanner salaku gaganti pikeun solusi database SQL tradisional
Di lingkungan tradisional basis data, nalika waktu respon query database ngadeukeutan atawa malah ngaleuwihan thresholds aplikasi nu tos disetel (utamana alatan kanaékan jumlah pamaké jeung / atawa requests), aya sababaraha cara pikeun ngurangan waktu respon kana tingkat ditarima. Nanging, kalolobaan solusi ieu ngalibatkeun campur tangan manual.
Salaku conto, lengkah munggaran anu kedah dilakukeun nyaéta ningali rupa-rupa parameter database anu aya hubunganana sareng kinerja sareng nyaluyukeunana pikeun cocog sareng pola kasus panggunaan aplikasi. Upami ieu henteu cekap, anjeun tiasa milih skala database sacara vertikal atanapi horisontal.
Skala vertikal hiji aplikasi merlukeun ningkatkeun conto server, ilaharna ku nambahkeun leuwih prosesor / cores, RAM leuwih, gudang gancang, jsb Nambahkeun leuwih sumberdaya hardware ngakibatkeun kanaékan kinerja database, diukur utamana dina transaksi di detik, sarta latency transaksi pikeun sistem OLTP. Sistem basis data relasional (anu ngagunakeun pendekatan multi-threaded) sapertos skala MySQL sacara vertikal.
Aya sababaraha kalemahan pikeun pendekatan ieu, tapi anu paling jelas nyaéta ukuran pangladén maksimum dina pasaran. Sakali wates conto pangladén panggedena kahontal, ngan aya hiji pilihan anu tinggaleun: skala horizontal.
Skala horisontal mangrupikeun pendekatan dimana langkung seueur server nambihkeun kana kluster, idéal ningkatkeun kinerja sacara linier nalika jumlah server nambihkeun. mayoritas tradisional Sistem database henteu skala sacara horisontal atanapi henteu skala pisan. Contona, MySQL tiasa skala horisontal pikeun operasi maca ku nambahkeun pamiarsa budak, tapi teu bisa skala horisontal pikeun nulis.
Di sisi anu sanés, kusabab sifatna, Cloud Spanner tiasa gampang skala sacara horisontal kalayan intervensi minimal.
Pinuh diulas DBMS salaku jasa kudu ditaksir tina sudut anu béda. Salaku dasar, kami nyandak DBMS anu pang populerna di awan - pikeun Google, GCP Cloud SQL sareng pikeun Amazon, AWS RDS. Dina evaluasi kami fokus kana kategori ieu:
- pemetaan fitur: extent SQL, DDL, DML; perpustakaan sambungan / panyambungna, rojongan transaksi, jeung saterusna.
- Pangrojong pamekaran: pamekaran gampang sareng uji.
- Pangrojong administrasi: manajemén instansi - contona, skala kaluhur/handap sareng ningkatkeun instansi; SLA, cadangan tur recovery; kaamanan / kontrol aksés.
Ngagunakeun Cloud Spanner salaku solusi OLTP-diaktipkeun OLAP
Sanaos Google henteu sacara eksplisit ngaku yén Cloud Spanner dirancang pikeun ngolah analitis, éta ngabagi sababaraha atribut sareng mesin sanés sapertos Apache Impala & Kudu sareng YugaByte, anu dirancang pikeun beban kerja OLAP.
Malah lamun aya ngan leutik kasempetan nu Cloud Spanner kaasup skala-kaluar konsisten HTAP (hybrid transactional / processing analytics) mesin jeung (leuwih atawa kurang) bisa dipaké set fitur OLAP, kami pikir eta bakal pantes perhatian urang.
Dina pikiran ieu, urang nempo kategori handap:
- Data loading, indéks jeung rojongan partitioning
- Performance Query jeung DML
2. Awan Spanner dina nutshell
Google Spanner mangrupakeun clustered relational database management system (RDBMS) nu Google ngagunakeun pikeun sababaraha layanan sorangan. Google ngajantenkeun umumna sayogi pikeun pangguna Google Cloud Platform dina awal 2017.
Ieu sababaraha atribut Cloud Spanner:
- Kacida Konsisten Scalable RDBMS Cluster: Ngagunakeun hardware sinkronisasi waktos pikeun mastikeun konsistensi data.
- Rojongan urus cross-tabel: Transaksi bisa bentang sababaraha tabel - teu merta dugi ka méja tunggal (teu kawas Apache HBase atanapi Apache Kudu).
- tabél dumasar konci primér: Sadaya tabel kudu boga konci primér nyatakeun (PC), nu bisa diwangun ku sababaraha kolom dina tabél. Data tabular disimpen dina urutan PC, sahingga efisien pisan sareng gancang pikeun milarian PC. Sapertos sistem basis PC anu sanés, palaksanaanna kedah dimodelkeun sareng kasus pamakean anu tos dirancang dina pikiran pikeun ngahontal .
- tabél belang: Tables bisa mibanda kagumantungan fisik dina unggal lianna. Baris dina tabel anak bisa loyog jeung baris dina tabel indungna. Pendekatan ieu nyepetkeun milarian hubungan anu tiasa diidentifikasi salami fase modeling data, sapertos co-locating konsumén sareng invoice na.
- Indéks: Cloud Spanner ngadukung indéks sékundér. Indéks diwangun ku kolom indéks sareng sadaya kolom PC. Upami hoyong, indéks ogé bisa ngandung kolom non-indéks séjén. indéks bisa interleaved kalawan tabel indungna pikeun nyepetkeun queries. Sababaraha larangan dilarapkeun ka indéks, kayaning jumlah maksimum kolom tambahan disimpen dina indéks. Oge, queries ngaliwatan indexes bisa jadi salaku lugas sakumaha dina RDBMSs lianna.
"Cloud Spanner milih indéks sacara otomatis ngan dina kasus anu jarang. Khususna, Cloud Spanner henteu otomatis milih indéks sekundér upami patarosan menta kolom naon waé anu henteu disimpen dina ".
- Service Level pasatujuan (SLA): Deployment dina hiji wewengkon kalawan SLA 99,99%; deployments multi-régional jeung 99,999% SLA. Bari SLA sorangan ngan hiji perjangjian teu jaminan nanaon, abdi yakin folks di Google do gaduh sababaraha data teuas pikeun nyieun klaim kuat misalna. (Pikeun rujukan, 99,999% hartosna 26,3 detik henteu sayogi jasa per bulan.)
- langkung:
Catetan: Proyék Apache Tephra nambihan dukungan transaksi anu ditingkatkeun ka Apache HBase (ogé ayeuna dilaksanakeun di Apache Phoenix salaku béta).
3. Penilaian urang
Janten, urang sadayana parantos maca klaim Google ngeunaan mangpaat Cloud Spanner - skala horisontal ampir henteu terbatas bari ngajaga konsistensi anu luhur sareng SLA anu luhur pisan. Sanaos sarat ieu, dina hal naon waé, sesah pisan pikeun dihontal, tujuan kami henteu ngabantah aranjeunna. Gantina, hayu urang difokuskeun hal séjén anu paling pamaké database paduli: parity na usability.
Kami ngaevaluasi Cloud Spanner salaku gaganti Sharded MySQL
Google Cloud SQL sareng Amazon AWS RDS, dua tina OLTP DBMS anu pang populerna di pasar awan, gaduh set fitur anu ageung pisan. Najan kitu, pikeun skala database ieu saluareun ukuran hiji titik tunggal, Anjeun kudu ngalakukeun partisi aplikasi. Pendekatan ieu nyiptakeun pajeulitna tambahan pikeun aplikasi sareng administrasi. Kami ningali kumaha Spanner pas kana skenario ngagabungkeun sababaraha beling kana hiji conto sareng fitur naon (upami aya) anu kedah dikorbankeun.
Pangrojong SQL, DML sareng DDL, ogé konektor sareng perpustakaan?
Kahiji, nalika dimimitian ku database mana wae, Anjeun kudu nyieun model data. Upami anjeun pikir anjeun tiasa nyambungkeun JDBC Spanner kana alat SQL paporit anjeun, anjeun bakal mendakan yén anjeun tiasa naroskeun data anjeun sareng éta, tapi anjeun henteu tiasa nganggo éta pikeun nyiptakeun méja atanapi ngarobih (DDL) atanapi sisipan / update / ngahapus. operasi (DML). JDBC resmi Google henteu ngadukung salah sahiji ieu.
"Supir ayeuna henteu ngadukung pernyataan DML atanapi DDL."
Dokuméntasi Spanner
Kaayaan henteu langkung saé sareng konsol GCP - anjeun ngan ukur tiasa ngirim patarosan PILIH. Kabeneran aya supir JDBC anu ngadukung DML sareng DDL ti masarakat, kalebet transaksi . Sanaos supir ieu mangpaat pisan, kurangna supir JDBC Google nyalira heran. Kabeneran, Google nawiskeun dukungan anu cukup lega pikeun perpustakaan klien (dumasar kana gRPC): C#, Go, Java, node.js, PHP, Python, sareng Ruby.
Pamakéan Awan Spanner custom API ampir wajib (kusabab kurangna DDL na DML di JDBC) ngakibatkeun sababaraha watesan pikeun wewengkon kode patali kayaning pools sambungan atanapi frameworks database mengikat (misalna Spring MVC). Ilaharna, lamun maké JDBC, anjeun bébas milih kolam renang sambungan favorit anjeun (misalna HikariCP, DBCP, C3PO, jsb) anu diuji sarta gawéna ogé. Dina kasus API Spanner custom, urang kudu ngandelkeun frameworks / pools mengikat / sesi nu urang geus dijieun sorangan.
Desain centric konci primér (PC) ngamungkinkeun Cloud Spanner jadi gancang pisan nalika ngakses data via PC, tapi ogé ngawanohkeun sababaraha masalah query.
- Anjeun teu bisa ngamutahirkeun nilai konci primér; Anjeun mimitina kudu mupus entri ti PC aslina tur selapkeun deui kalawan nilai anyar. (Ieu sami sareng mesin database / panyimpen anu berorientasi PC sanés.)
- Sakur pernyataan UPDATE sareng DELETE kedah netepkeun PC dina WHERE, janten teu tiasa kosong DELETE sadaya pernyataan - kedah aya subquery, contona: UPDATE xxx WHERE id IN (PILIH id FROM table1)
- Kurangna pilihan otomatis-increment atawa nanaon sarupa nu susunan runtuyan pikeun widang PC. Jang ngalampahkeun ieu, nilai saluyu kudu dijieun di sisi aplikasi.
indéks sekundér?
Google Cloud Spanner geus diwangun-di rojongan pikeun indexes sekundér. Ieu mangrupikeun fitur anu saé anu henteu salawasna aya dina téknologi sanés. Apache Kudu ayeuna henteu ngadukung indéks sékundér pisan, sareng Apache HBase henteu ngadukung indéks langsung, tapi tiasa nambihanana ngalangkungan Apache Phoenix.
Indéks di Kudu sareng HBase tiasa dimodelkeun salaku méja anu misah sareng komposisi konci primér anu béda, tapi atomicity tina operasi anu dilakukeun dina tabel induk sareng tabel indéks anu aya hubunganana kedah dilakukeun dina tingkat aplikasi sareng henteu sepele pikeun dilaksanakeun kalayan leres.
Sakumaha anu disebatkeun dina ulasan Cloud Spanner, indéksna tiasa bénten sareng indéks MySQL. Ku alatan éta, perawatan husus kudu dilaksanakeun nalika ngawangun queries na profil pikeun mastikeun yén indéks ditangtoskeun dipaké dimana eta diperlukeun.
Répréséntasi?
Obyék anu pang populerna sareng mangpaat dina pangkalan data nyaéta pintonan. Éta tiasa mangpaat pikeun sajumlah ageung kasus pamakean; dua karesep kuring nyaéta lapisan abstraksi logis sareng lapisan kaamanan. Hanjakal, Cloud Spanner NOT ngarojong pintonan. Nanging, ieu ngan ukur sawaréh ngabatesan kami kusabab henteu aya granularitas pikeun idin aksés dina tingkat kolom dimana pintonan tiasa janten solusi anu lumayan.
Tempo dokuméntasi Cloud Spanner pikeun bagian nu rinci kuota jeung larangan (), aya hiji hususna anu tiasa janten masalah pikeun sababaraha aplikasi: Cloud Spanner out of the box ngabogaan wates maksimum 100 database per conto. Jelas, ieu tiasa janten bottleneck utama pikeun database anu dirancang pikeun skala ka langkung ti 100 database. Kabeneran, saatos nyarios sareng wawakil téknis Google kami, kami mendakan yén wates ieu tiasa dironjatkeun ka ampir sagala nilai ngalangkungan Google Support.
Pangrojong pangwangunan?
Cloud Spanner nawiskeun dukungan basa pamrograman anu lumayan pikeun damel sareng API na. Perpustakaan anu dirojong sacara resmi aya dina daérah C #, Go, Java, node.js, PHP, Python sareng Ruby. Dokuméntasina cukup lengkep, tapi sapertos téknologi canggih anu sanés, komunitasna rada alit dibandingkeun sareng téknologi database anu pang populerna, anu tiasa nyababkeun langkung seueur waktos pikeun ngarengsekeun kasus pamakean atanapi masalah anu jarang.
Janten kumaha upami ngadukung pangwangunan lokal?
Kami henteu acan mendakan cara pikeun nyiptakeun instance Cloud Spanner di tempat. Hal anu paling caket anu kami kéngingkeun nyaéta gambar Docker. , nu sarupa prinsipna, tapi pisan béda dina praktekna. Contona, CockroachDB tiasa nganggo PostgreSQL JDBC. Kusabab lingkungan pamekaran kedah caket pisan sareng lingkungan produksi, Cloud Spanner henteu idéal sabab kedah ngandelkeun conto Spanner pinuh. Pikeun ngahemat biaya, anjeun tiasa milih conto hiji-wewengkon.
Pangrojong administrasi?
Nyiptakeun conto Cloud Spanner saderhana pisan. Anjeun ngan kudu milih antara nyieun hiji multi-wilayah atawa single-wilayah conto, tangtukeun wewengkon (s) jeung jumlah titik. Dina waktu kurang ti hiji menit, instance anjeun bakal dijalankeun.
Sababaraha métrik dasar tiasa diaksés langsung tina halaman Spanner dina Google Console. Pamandangan anu langkung rinci sayogi ngalangkungan Stackdriver, dimana anjeun ogé tiasa nyetél ambang métrik sareng kawijakan waspada.
Aksés ka sumber daya?
MySQL nawarkeun setélan éksténsif jeung pisan granular pikeun idin / kalungguhan pamaké. Anjeun tiasa sacara gampil ngonpigurasikeun aksés ka tabel husus, atawa malah ngan sawaréh ti kolom na. Cloud Spanner nganggo alat Identity & Access Management (IAM) Google, anu ngan ukur ngamungkinkeun anjeun nyetél kawijakan sareng idin dina tingkat anu luhur. Pilihan anu paling granular nyaéta résolusi tingkat database, anu henteu cocog sareng kalolobaan kasus panggunaan produksi. Watesan ieu maksa anjeun pikeun nambahkeun ukuran kaamanan tambahan kana kode anjeun, infrastruktur, atawa duanana pikeun nyegah pamakéan teu sah sumberdaya Spanner.
Cadangan?
Pikeun nempatkeun éta, teu aya cadangan dina Cloud Spanner. Sanajan syarat SLA tinggi Google bisa mastikeun yén anjeun teu leungit data wae alatan hardware atawa database gagal, kasalahan manusa, defects aplikasi, jsb Urang kabeh terang aturan: kasadiaan tinggi teu diganti pikeun strategi cadangan sora. Ayeuna, hiji-hijina jalan pikeun nyadangkeun data nyaéta pikeun ngalirkeun data sacara program tina pangkalan data ka lingkungan panyimpen anu misah.
Kinerja patarosan?
Kami nganggo Yahoo! pikeun ngamuat data sareng patarosan uji. Awan porsi Patokan. Tabel di handap ieu nunjukkeun beban kerja YCSB B kalayan rasio baca 95% dugi ka 5%.
* Tes beban dijalankeun dina n1-standar-32 Compute Engine (CE) (32 vCPU, 120 memori GB), sareng conto uji henteu pernah janten bottleneck dina tés.
** Jumlah maksimum threads dina conto YCSB tunggal nyaeta 400. Jumlahna aya genep instansi paralel tina tés YCSB kungsi ngajalankeun pikeun meunangkeun jumlahna aya 2400 threads.
Ningali hasil patokan, khususna kombinasi beban CPU sareng TPS, urang tiasa jelas ningali yén skala Cloud Spanner lumayan. Beban beurat anu diciptakeun ku sajumlah ageung benang diimbangi ku jumlah ageung titik dina klaster Cloud Spanner. Bari latency Sigana rada luhur, utamana lamun ngajalankeun kalawan 2400 threads, ulang nguji jeung 6 instansi leutik tina mesin komputasi bisa jadi diperlukeun pikeun meunangkeun angka nu leuwih akurat. Unggal conto bakal ngajalankeun hiji tés YCSB tinimbang hiji conto CE badag kalayan 6 tés paralel. Ku cara ieu, bakal langkung gampang ngabédakeun antara latensi pamundut Cloud Spanner sareng latensi anu ditambah ku sambungan jaringan antara Cloud Spanner sareng instansi CE anu ngajalankeun tés.
Kumaha Cloud Spanner ngalaksanakeun salaku OLAP?
ngabagi?
Ngabagi data kana bagéan fisik jeung/atawa bebas logis, disebut partitions, mangrupakeun konsép populér pisan kapanggih dina lolobana mesin OLAP. Partisi tiasa sacara signifikan ningkatkeun kinerja query sareng pangropéa database. Bade deeper kana partitioning bakal jadi artikel misah (s), jadi hayu urang ngan nyebut pentingna boga skéma partisi jeung sub-partitioning. Kamampuh ngarecah data kana partisi komo salajengna kana subpartitions mangrupakeun konci pikeun kinerja query analitik.
Cloud Spanner henteu ngadukung partisi sapertos kitu. Ieu ngabagi data internal kana disebut Beulah-s dumasar kana rentang konci primér. Partisi dilakukeun sacara otomatis pikeun nyaimbangkeun beban dina klaster Cloud Spanner. Fitur anu pohara kapaké tina Cloud Spanner nyaéta pamisahan beban dasar tabel indungna (tabel anu henteu aya hubunganana sareng anu sanés). Spanner otomatis ngadeteksi naha éta ngandung Beulah data nu dibaca leuwih sering ti data di batur Beulah-ah, sarta bisa mutuskeun dina separation salajengna. Ku cara ieu, langkung seueur titik tiasa kalibet dina pamundut, anu ogé sacara efektif ningkatkeun throughput.
Ngamuat data?
Métode Cloud Spanner pikeun data massal sami sareng unggah biasa. Pikeun ngahontal prestasi maksimal, anjeun kedah nuturkeun sababaraha pedoman, kalebet:
- Susun data anjeun ku konci primér.
- Bagikeun aranjeunna ku 10 *jumlah titik bagian misah.
- Jieun sakumpulan tugas gawé anu ngamuat data paralel.
Pemuatan data ieu nganggo sadaya titik Cloud Spanner.
Kami nganggo beban kerja YCSB A pikeun ngahasilkeun set data 10M baris.
* Tes beban dijalankeun dina mesin komputasi n1-standar-32 (32 vCPU, 120 memori GB), sareng conto tés henteu pernah janten bottleneck dina tés.
** Setélan titik tunggal henteu disarankeun pikeun beban kerja produksi.
Sakumaha didadarkeun di luhur, Cloud Spanner otomatis ngolah pamisah dumasar kana bebanna, janten hasilna ningkat saatos sababaraha pangulangan tés berturut-turut. Hasil anu disayogikeun di dieu mangrupikeun hasil anu pangsaéna. Ningali nomer di luhur, urang tiasa ningali kumaha skala Cloud Spanner (ogé) nalika jumlah titik dina kluster naék. Angka-angka anu menonjol nyaéta latén rata-rata anu handap pisan, anu kontras sareng hasil pikeun beban kerja anu dicampur (95% maca sareng 5% nyerat) sapertos anu dijelaskeun dina bagian di luhur.
Scaling?
Ngaronjatkeun sareng ngirangan jumlah titik Cloud Spanner mangrupikeun tugas hiji-klik. Upami anjeun hoyong ngamuat data gancang, anjeun tiasa mertimbangkeun ningkatkeun instance anjeun ka maksimal (dina hal kami éta 25 titik di daérah AS-EAST) teras ngirangan jumlah titik anu cocog pikeun beban normal anjeun saatos sadaya data aya dina. pangkalan data, ngarujuk kana wates 2TB/node.
Kami ngingetkeun wates ieu sanaos ku database anu langkung alit. Saatos sababaraha tés beban, databés kami ukuranana sakitar 155 GB, sareng nalika diturunkeun kana conto 1 titik, kami nampi kasalahan ieu:
Urang junun skala turun tina 25 ka 2 instansi, tapi kami nyangkut dina dua titik.
Ngaronjatkeun sareng ngirangan jumlah titik dina klaster Cloud Spanner tiasa otomatis nganggo REST API. Ieu tiasa hususna kapaké pikeun ngirangan beban sistem nalika jam kerja sibuk.
Kinerja patarosan OLAP?
Kami mimitina ngarencanakeun nyéépkeun waktos anu penting dina evaluasi Spanner dina bagian ieu. Saatos sababaraha SELECT COUNTs, urang langsung sadar yén tés bakal pondok sareng Spanner moal janten mesin anu cocog pikeun OLAP. Paduli jumlah titik dina klaster, cukup milih jumlah baris dina tabel baris 10M nyandak antara 55 jeung 60 detik. Salaku tambahan, naon waé pamundut anu peryogi langkung seueur mémori pikeun nyimpen hasil panengah gagal sareng kasalahan OOM.
SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.
Sababaraha nomer pikeun patarosan TPC-H tiasa dipendakan dina tulisan Todd Lipcon , slides 42 jeung 43. Jumlah ieu konsisten kalayan hasil urang sorangan (hanjakalna).
4. Kacindekan urang
Kusabab kaayaan fitur Cloud Spanner ayeuna, sesah ngabayangkeun éta mangrupikeun gaganti saderhana pikeun solusi OLTP anjeun anu tos aya, khususna nalika kabutuhan anjeun langkung ageung. Sajumlah ageung waktos kedah diséépkeun pikeun ngawangun solusi ngeunaan kakurangan Cloud Spanner.
Nalika urang mimiti ngaevaluasi Cloud Spanner, kami ngarepkeun fitur manajeménna sajajar sareng, atanapi sahenteuna henteu jauh teuing tina, solusi Google SQL anu sanés. Tapi kami kaget ku kurangna cadangan lengkep sareng kontrol anu terbatas pikeun aksés kana sumber daya. Teu nyebut euweuh pintonan, euweuh lingkungan ngembangkeun lokal, urutan unsupported, JDBC tanpa rojongan DML na DDL, jeung saterusna.
Janten dimana saha waé anu peryogi skala database transaksional? Sigana henteu aya solusi tunggal di pasar anu cocog sareng sadaya kasus pamakean. Aya loba solusi katutup sarta open source (sababaraha nu disebutkeun dina artikel ieu), unggal mibanda kaunggulan jeung kalemahan sorangan, tapi taya sahijina nawiskeun SaaS kalawan 99,999% SLA jeung konsistensi tinggi. Upami SLA anu luhur mangrupikeun tujuan utama anjeun sareng anjeun henteu condong ngawangun solusi multi-awan khusus, Cloud Spanner tiasa janten solusi anu anjeun milarian. Tapi anjeun kedah sadar kana sagala watesanana.
Janten adil, Cloud Spanner ngan dileupaskeun ka umum di cinyusu 2017, jadi wajar mun nyangka yén sababaraha shortcomings na ayeuna pamustunganana bisa dileungitkeun (mudahan), sarta lamun maranehna ngalakukeun, éta bisa jadi hiji changer kaulinan. Barina ogé, Cloud Spanner sanés ngan ukur proyék samping pikeun Google. Google migunakeun eta salaku dadasar pikeun produk Google lianna. Sareng nalika Google nembé ngagentos Megastore di Google Cloud Storage sareng Cloud Spanner, éta ngamungkinkeun Google Cloud Storage janten konsisten pisan pikeun daptar objék dina skala global (anu masih henteu kasus pikeun ).
Ku kituna, masih aya harepan ... urang miharep.
Éta hungkul. Sapertos panulis tulisan, urang ogé terus ngarepkeun, tapi kumaha saur anjeun ngeunaan ieu? Tulis dina komentar
Kami ngajak sadayana nganjang ka kami di jerona kami bakal nyarioskeun anjeun sacara rinci ngeunaan kursus ti OTUS.
sumber: www.habr.com