Hello, Khabrovites. Secara tradisinya, kami terus berkongsi bahan menarik pada malam permulaan kursus baharu. Hari ini, khas untuk anda, kami telah menterjemah artikel tentang Google Cloud Spanner, bertepatan dengan pelancaran kursus .
Asalnya diterbitkan dalam .
Sebagai sebuah syarikat yang menawarkan pelbagai penyelesaian POS berasaskan awan untuk peruncit, restoran dan pedagang dalam talian di seluruh dunia, Lightspeed menggunakan beberapa jenis platform pangkalan data yang berbeza untuk pelbagai kes penggunaan transaksi, analitik dan carian. Setiap platform pangkalan data ini mempunyai kekuatan dan kelemahan tersendiri. Oleh itu, apabila Google memperkenalkan Cloud Spanner ke pasaran - ciri yang menjanjikan yang tidak dilihat dalam dunia pangkalan data hubungan, seperti kebolehskalaan mendatar yang hampir tidak terhad dan perjanjian tahap perkhidmatan (SLA) 99,999% , Kami tidak boleh melepaskan peluang untuk memilikinya dalam tangan kami!
Untuk memberikan gambaran menyeluruh tentang pengalaman kami dengan Cloud Spanner, serta kriteria penilaian yang kami gunakan, kami akan merangkumi topik berikut:
- Kriteria penilaian kami
- Sepana Awan secara ringkas
- Penilaian kami
- Penemuan kami
1. Kriteria penilaian kami
Sebelum menyelami spesifik Cloud Spanner, persamaan dan perbezaannya dengan penyelesaian lain di pasaran, mari kita bincangkan dahulu tentang kes penggunaan utama yang kami fikirkan semasa mempertimbangkan tempat untuk menggunakan Cloud Spanner dalam infrastruktur kami:
- Sebagai pengganti untuk penyelesaian pangkalan data SQL tradisional (lazim).
- Sebagai penyelesaian OLTP dengan sokongan OLAP
Nota: Untuk memudahkan perbandingan, artikel ini membandingkan Cloud Spanner dengan varian MySQL bagi keluarga penyelesaian GCP Cloud SQL dan Amazon AWS RDS.
Menggunakan Cloud Spanner sebagai pengganti penyelesaian pangkalan data SQL tradisional
Dalam persekitaran tradisional pangkalan data, apabila masa tindak balas untuk pertanyaan pangkalan data menghampiri atau bahkan melebihi ambang aplikasi yang dipratentukan (terutamanya disebabkan oleh peningkatan dalam bilangan pengguna dan/atau permintaan), terdapat beberapa cara untuk mengurangkan masa tindak balas kepada tahap yang boleh diterima. Walau bagaimanapun, kebanyakan penyelesaian ini melibatkan campur tangan manual.
Sebagai contoh, langkah pertama yang perlu diambil ialah melihat pelbagai tetapan pangkalan data berkaitan prestasi dan menalanya agar sesuai dengan corak senario penggunaan aplikasi. Jika ini tidak mencukupi, anda boleh memilih untuk menskalakan pangkalan data secara menegak atau mendatar.
Menaikkan skala aplikasi memerlukan pengemaskinian contoh pelayan, biasanya dengan menambahkan lebih banyak pemproses/teras, lebih banyak RAM, storan lebih pantas, dsb. Menambah lebih banyak sumber perkakasan menghasilkan peningkatan prestasi pangkalan data, diukur terutamanya dalam transaksi sesaat dan kependaman transaksi untuk sistem OLTP. Sistem pangkalan data hubungan (yang menggunakan pendekatan berbilang benang) seperti skala MySQL dengan baik secara menegak.
Terdapat beberapa kelemahan untuk pendekatan ini, tetapi yang paling jelas ialah saiz pelayan maksimum di pasaran. Setelah had Instance Server terbesar dicapai, hanya ada satu laluan yang tinggal: skala keluar.
Scale-out ialah pendekatan yang menambahkan lebih banyak pelayan pada kluster untuk secara ideal meningkatkan prestasi secara linear apabila lebih banyak pelayan ditambahkan. Majoriti tradisional sistem pangkalan data tidak berskala dengan baik atau tidak berskala sama sekali. Sebagai contoh, MySQL boleh menskalakan bacaan dengan menambahkan pembaca hamba, tetapi ia tidak boleh mengecilkan untuk menulis.
Sebaliknya, disebabkan sifatnya, Cloud Spanner boleh menskala secara mendatar dengan mudah dengan campur tangan yang minimum.
Ciri penuh DBMS sebagai perkhidmatan mesti dinilai dari perspektif yang berbeza. Sebagai asas, kami mengambil DBMS paling popular dalam awan - untuk Google, GCP Cloud SQL dan untuk Amazon, AWS RDS. Dalam penilaian kami, kami memberi tumpuan kepada kategori berikut:
- Pemetaan ciri: Tahap SQL, DDL, DML; perpustakaan sambungan/penyambung, sokongan transaksi, dan sebagainya.
- Sokongan Pembangunan: Kemudahan pembangunan dan ujian.
- Sokongan Pentadbiran: Pengurusan instance seperti menaik/turun dan menaik taraf kejadian; SLA, sandaran dan pemulihan; kawalan keselamatan/akses.
Menggunakan Cloud Spanner sebagai Penyelesaian OLTP Didayakan OLAP
Walaupun Google tidak menyatakan secara eksplisit bahawa Cloud Spanner adalah untuk analitis, ia berkongsi beberapa atribut dengan enjin lain seperti Apache Impala & Kudu dan YugaByte yang direka untuk beban kerja OLAP.
Walaupun hanya terdapat sedikit peluang bahawa Cloud Spanner menyertakan enjin HTAP (Pemprosesan Transaksi/Analitik Hibrid) skala keluar yang konsisten dengan set ciri OLAP yang boleh digunakan (lebih atau kurang), kami fikir ia akan mendapat perhatian kami.
Dengan itu, kami melihat kategori berikut:
- Pemuatan data, indeks dan sokongan pembahagian
- Prestasi pertanyaan dan DML
2. Sepana Awan Secara Ringkasnya
Google Spanner ialah sistem pengurusan pangkalan data hubungan berkelompok (RDBMS) yang digunakan Google untuk beberapa perkhidmatannya sendiri. Google menjadikannya tersedia secara terbuka kepada pengguna Google Cloud Platform pada awal tahun 2017.
Berikut ialah beberapa atribut Cloud Spanner:
- Kluster RDBMS Sangat Konsisten, Boleh Skala: Menggunakan penyegerakan masa perkakasan untuk memastikan ketekalan data.
- Sokongan transaksi merentas jadual: Transaksi boleh merangkumi berbilang jadual - tidak semestinya terhad kepada satu jadual (tidak seperti Apache HBase atau Apache Kudu).
- Jadual Berdasarkan Kunci Utama: Semua jadual mesti mempunyai Kunci Utama (PC) yang diisytiharkan, yang boleh terdiri daripada berbilang lajur jadual. Data jadual disimpan dalam susunan PC, yang menjadikannya sangat cekap dan pantas untuk carian PC. Seperti sistem berasaskan PC yang lain, pelaksanaan mesti dimodelkan terhadap kes penggunaan prasangka untuk mencapainya .
- Jadual berjalur: Jadual boleh mempunyai kebergantungan fizikal antara satu sama lain. Barisan jadual anak boleh dipadankan dengan baris jadual induk. Pendekatan ini mempercepatkan carian untuk perhubungan yang boleh ditentukan pada peringkat pemodelan data, contohnya, apabila meletakkan pelanggan dan invois mereka bersama-sama.
- Indeks: Cloud Spanner menyokong indeks sekunder. Indeks terdiri daripada lajur diindeks dan semua lajur PC. Secara pilihan, indeks juga boleh mengandungi lajur tidak diindeks lain. Indeks boleh disisipkan dengan jadual induk untuk mempercepatkan pertanyaan. Beberapa sekatan dikenakan pada indeks, seperti bilangan maksimum lajur tambahan yang boleh disimpan dalam indeks. Juga, pertanyaan melalui indeks mungkin tidak semudah dalam RDBMS lain.
βCloud Spanner memilih indeks secara automatik hanya dalam kes yang jarang berlaku. Khususnya, Cloud Spanner tidak memilih indeks kedua secara automatik jika pertanyaan meminta mana-mana lajur yang tidak disimpan dalam '.
- Perjanjian Tahap Perkhidmatan (SLA): Pengerahan wilayah tunggal dengan 99,99% SLA; penempatan berbilang wilayah dengan 99,999% SLA. Walaupun SLA itu sendiri hanyalah perjanjian dan bukan jaminan dalam apa jua bentuk, saya percaya bahawa orang Google mempunyai beberapa data yang sukar untuk membuat tuntutan yang begitu kuat. (Sebagai rujukan, 99,999% bermakna 26,3 saat masa berhenti perkhidmatan setiap bulan.)
- Lebih banyak:
Nota: Projek Apache Tephra menambah sokongan transaksi lanjutan kepada Apache HBase (juga kini dilaksanakan dalam Apache Phoenix sebagai beta).
3. Penilaian kami
Jadi, kita semua telah membaca kenyataan Google tentang faedah Cloud Spanner - penskalaan mendatar hampir tanpa had sambil mengekalkan konsistensi yang tinggi dan SLA yang sangat tinggi. Walaupun dakwaan ini, dalam apa jua keadaan, amat sukar untuk dicapai, matlamat kami bukanlah untuk menyangkalnya. Sebaliknya, mari kita fokus pada perkara lain yang kebanyakan pengguna pangkalan data mengambil berat tentang: pariti dan kebolehgunaan.
Kami menilai Cloud Spanner sebagai pengganti Sharded MySQL
Google Cloud SQL dan Amazon AWS RDS, dua daripada pangkalan data OLTP paling popular dalam pasaran awan, mempunyai set ciri yang sangat besar. Walau bagaimanapun, untuk menskalakan pangkalan data ini melebihi saiz satu nod, anda perlu melakukan pemisahan aplikasi. Pendekatan ini mewujudkan kerumitan tambahan untuk kedua-dua aplikasi dan pentadbiran. Kami melihat cara Spanner sesuai dengan senario menggabungkan berbilang serpihan menjadi satu contoh dan ciri (jika ada) yang mungkin perlu dikorbankan.
Sokongan untuk SQL, DML dan DDL, serta penyambung dan perpustakaan?
Pertama, apabila bermula dengan mana-mana pangkalan data, anda perlu mencipta model data. Jika anda fikir anda boleh menyambungkan JDBC Spanner ke alat SQL kegemaran anda, anda akan mendapati anda boleh menanyakan data anda dengannya, tetapi anda tidak boleh menggunakannya untuk membuat jadual atau kemas kini (DDL) atau sebarang sisipan/kemas kini/padam operasi (DML). JDBC rasmi Google tidak menyokong sama ada.
"Pemandu tidak menyokong kenyataan DML atau DDL pada masa ini."
Dokumentasi Spanner
Keadaan tidak lebih baik dengan konsol GCP - anda hanya boleh menghantar pertanyaan SELECT. Nasib baik ada pemandu JDBC dengan sokongan DML dan DDL daripada komuniti termasuk transaksi . Walaupun pemandu ini sangat berguna, ketiadaan pemandu JDBC Google sendiri adalah mengejutkan. Nasib baik, Google menawarkan sokongan perpustakaan pelanggan yang agak luas (berdasarkan gRPC): C#, Go, Java, node.js, PHP, Python dan Ruby.
Penggunaan hampir mandatori API tersuai Cloud Spanner (disebabkan kekurangan DDL dan DML dalam JDBC) menyebabkan beberapa pengehadan untuk bidang kod yang berkaitan seperti pengumpulan sambungan atau rangka kerja mengikat pangkalan data (seperti Spring MVC). Secara amnya, apabila menggunakan JDBC, anda bebas memilih kumpulan sambungan kegemaran anda (cth HikariCP, DBCP, C3PO, dll.) yang diuji dan berfungsi dengan baik. Dalam kes API Spanner tersuai, kita perlu bergantung pada kumpulan rangka kerja/pengikat/sesi yang telah kita cipta sendiri.
Reka bentuk berorientasikan kunci utama (PC) membolehkan Cloud Spanner menjadi sangat pantas apabila mengakses data melalui PC, tetapi juga memperkenalkan beberapa isu pertanyaan.
- Anda tidak boleh mengemas kini nilai kunci utama; Anda mesti memadamkan entri PC asal dahulu dan memasukkannya semula dengan nilai baharu. (Ini serupa dengan pangkalan data/enjin storan berorientasikan PC lain.)
- Sebarang kenyataan UPDATE dan DELETE mesti menyatakan PC dalam WHERE, oleh itu, tidak boleh kosong DELETE semua kenyataan - mesti sentiasa ada subquery, contohnya: KEMASKINI xxx WHERE id IN (PILIH id DARI jadual1)
- Kekurangan pilihan autokenaikan atau sesuatu yang serupa yang menetapkan urutan untuk medan PC. Untuk ini berfungsi, nilai yang sepadan mesti dibuat pada bahagian aplikasi.
Indeks sekunder?
Google Cloud Spanner mempunyai sokongan terbina dalam untuk indeks sekunder. Ini adalah ciri yang sangat bagus yang tidak selalu ada dalam teknologi lain. Apache Kudu sama sekali tidak menyokong indeks sekunder pada masa ini, dan Apache HBase tidak menyokong indeks secara langsung, tetapi boleh menambahkannya melalui Apache Phoenix.
Indeks dalam Kudu dan HBase boleh dimodelkan sebagai jadual berasingan dengan komposisi kunci primer yang berbeza, tetapi atomicity operasi yang dilakukan pada jadual induk dan jadual indeks yang berkaitan mesti dilakukan pada tahap aplikasi dan tidak remeh untuk dilaksanakan dengan betul.
Seperti yang dinyatakan dalam ulasan Cloud Spanner, indeksnya mungkin berbeza daripada indeks MySQL. Oleh itu, penjagaan khusus mesti diambil dalam pembinaan pertanyaan dan pemprofilan untuk memastikan bahawa indeks yang betul digunakan di mana ia diperlukan.
Perwakilan?
Objek yang sangat popular dan berguna dalam pangkalan data ialah pandangan. Mereka boleh berguna untuk sejumlah besar kes penggunaan; dua kegemaran saya ialah lapisan abstraksi logik dan lapisan keselamatan. Malangnya Cloud Spanner TIDAK menyokong paparan. Walau bagaimanapun, ini hanya sebahagiannya mengehadkan kami, kerana tiada butiran peringkat lajur untuk kebenaran akses yang pandangan boleh menjadi penyelesaian yang boleh diterima.
Lihat dokumentasi Cloud Spanner untuk bahagian yang memperincikan kuota dan had (), terdapat satu khususnya yang boleh menjadi masalah untuk sesetengah aplikasi: Cloud Spanner di luar kotak mempunyai maksimum 100 pangkalan data bagi setiap contoh. Jelas sekali, ini boleh menjadi halangan utama untuk pangkalan data yang direka untuk skala kepada lebih 100 pangkalan data. Nasib baik, selepas bercakap dengan wakil teknikal Google kami, kami mendapati bahawa had ini boleh ditingkatkan kepada hampir mana-mana nilai melalui Sokongan Google.
Sokongan pembangunan?
Cloud Spanner menawarkan sokongan bahasa pengaturcaraan yang cukup baik untuk bekerja dengan APInya. Perpustakaan yang disokong secara rasmi berada dalam kawasan C#, Go, Java, node.js, PHP, Python dan Ruby. Dokumentasi ini agak terperinci, tetapi seperti teknologi canggih yang lain, komunitinya agak kecil berbanding dengan kebanyakan teknologi pangkalan data yang popular, yang boleh mengakibatkan lebih banyak masa dihabiskan untuk kes penggunaan atau masalah yang kurang biasa.
Jadi bagaimana dengan sokongan pembangunan tempatan?
Kami tidak menemui cara untuk membuat contoh Cloud Spanner di premis. Yang paling dekat yang kami dapat ialah imej Docker yang serupa pada dasarnya, tetapi sangat berbeza dalam amalan. Contohnya CockroachDB boleh menggunakan PostgreSQL JDBC. Memandangkan persekitaran pembangunan harus sedekat mungkin dengan persekitaran pengeluaran, Cloud Spanner tidak sesuai kerana anda perlu bergantung pada tika Spanner penuh. Untuk menjimatkan kos, anda boleh memilih satu contoh wilayah.
Sokongan pentadbiran?
Membuat tika Spanner Awan adalah sangat mudah. Anda hanya perlu memilih antara membuat contoh berbilang wilayah atau satu wilayah, nyatakan wilayah dan bilangan nod. Dalam masa kurang daripada satu minit, contoh akan tersedia dan berjalan.
Beberapa metrik asas tersedia secara langsung pada halaman Spanner dalam Google Console. Paparan lebih terperinci tersedia melalui Stackdriver, di mana anda juga boleh menetapkan ambang metrik dan dasar makluman.
Akses kepada sumber?
MySQL menawarkan tetapan kebenaran/peranan pengguna yang luas dan sangat terperinci. Anda boleh dengan mudah menyesuaikan akses kepada jadual tertentu, atau bahkan hanya subset lajurnya. Cloud Spanner menggunakan alat Pengurusan Identiti & Akses (IAM) Google, yang hanya membenarkan anda menetapkan dasar dan kebenaran pada tahap yang sangat tinggi. Pilihan yang paling terperinci ialah kebenaran peringkat pangkalan data, yang tidak sesuai dalam kebanyakan kes pengeluaran. Sekatan ini memaksa anda menambah langkah keselamatan tambahan pada kod, infrastruktur anda atau kedua-duanya untuk menghalang penggunaan sumber Spanner tanpa kebenaran.
Sandaran?
Ringkasnya, tiada sandaran dalam Cloud Spanner. Walaupun keperluan SLA yang tinggi Google boleh memastikan anda tidak kehilangan sebarang data akibat kegagalan perkakasan atau pangkalan data, ralat manusia, kecacatan aplikasi, dll. Kita semua tahu peraturannya: ketersediaan tinggi bukan pengganti untuk strategi sandaran pintar. Pada masa ini, satu-satunya cara untuk membuat sandaran data adalah dengan menstrimkannya secara pemrograman daripada pangkalan data ke persekitaran storan yang berasingan.
Prestasi pertanyaan?
Kami menggunakan Yahoo! untuk memuatkan data dan permintaan ujian. Penanda Aras Servis Awan. Jadual di bawah menunjukkan beban kerja B YCSB dengan nisbah tulis 95% baca hingga 5%.
* Ujian beban dijalankan pada n1-standard-32 Compute Engine (CE) (32 vCPU, memori 120 GB) dan contoh ujian tidak pernah menjadi halangan dalam ujian.
** Bilangan maksimum utas dalam satu tika YCSB ialah 400. Secara keseluruhannya, enam tikas selari ujian YCSB terpaksa dijalankan untuk mendapatkan sejumlah 2400 utas.
Melihat kepada hasil penanda aras, khususnya gabungan beban CPU dan TPS, kita dapat melihat dengan jelas bahawa Cloud Spanner berskala agak baik. Beban besar yang dihasilkan oleh sebilangan besar utas diimbangi oleh sejumlah besar nod dalam gugusan Cloud Spanner. Walaupun kependaman kelihatan agak tinggi, terutamanya apabila berjalan pada 2400 utas, anda mungkin perlu menguji semula dengan 6 kejadian enjin pengiraan yang lebih kecil untuk mendapatkan nombor yang lebih tepat. Setiap kejadian akan menjalankan satu ujian YCSB dan bukannya satu contoh CE yang besar dengan 6 ujian selari. Ini memudahkan untuk membezakan antara kelewatan permintaan Cloud Spanner dan kelewatan yang ditambahkan oleh sambungan rangkaian antara Cloud Spanner dan tika CE yang menjalankan ujian.
Bagaimanakah Cloud Spanner berfungsi sebagai OLAP?
Pembahagian?
Membahagikan data kepada segmen bebas secara fizikal dan/atau logik, dipanggil sekatan, ialah konsep yang sangat popular yang terdapat dalam kebanyakan enjin OLAP. Pemisahan boleh meningkatkan prestasi pertanyaan dan kebolehselenggaraan pangkalan data. Mempelajari lebih lanjut tentang pembahagian akan menjadi artikel yang berasingan, jadi mari kita sebutkan kepentingan mempunyai skim pembahagian dan pembahagian kecil. Keupayaan untuk membahagikan data kepada partition dan lebih jauh lagi kepada sub-partition adalah kunci kepada prestasi pertanyaan analitikal.
Cloud Spanner tidak menyokong partition per se. Ia memisahkan data secara dalaman kepada apa yang dipanggil berpecah-s berdasarkan julat kunci utama. Pembahagian dilakukan secara automatik untuk mengimbangi beban pada gugusan Cloud Spanner. Ciri Cloud Spanner yang sangat berguna ialah membahagikan beban asas jadual induk (jadual yang tidak bersilang dengan yang lain). Spanner secara automatik mengesan jika ia mengandungi berpecah data yang dibaca lebih kerap daripada data lain berpecah-ah, dan boleh memutuskan perpisahan selanjutnya. Oleh itu, lebih banyak nod boleh terlibat dalam permintaan, yang juga berkesan meningkatkan daya pemprosesan.
Memuatkan data?
Kaedah Cloud Spanner untuk data pukal adalah sama seperti untuk muat naik biasa. Untuk prestasi maksimum, anda perlu mengikuti beberapa garis panduan, termasuk:
- Isih data anda mengikut kunci utama.
- Bahagikannya dengan 10*bilangan nod bahagian individu.
- Buat satu set tugas pekerja yang memuatkan data secara selari.
Pemuatan data ini menggunakan semua nod Cloud Spanner.
Kami menggunakan beban kerja A YCSB untuk menjana set data baris 10M.
* Ujian beban dijalankan pada enjin pengiraan n1-standard-32 (32 vCPU, memori 120 GB) dan contoh ujian tidak pernah menjadi halangan dalam ujian.
** Persediaan 1 nod tidak disyorkan untuk sebarang beban kerja pengeluaran.
Seperti yang dinyatakan di atas, Cloud Spanner secara automatik memproses pemisahan bergantung pada bebannya, jadi hasilnya bertambah baik selepas beberapa lelaran ujian berturut-turut. Keputusan yang dibentangkan di sini adalah hasil terbaik yang kami terima. Melihat nombor di atas, kita dapat melihat cara Cloud Spanner berskala (dengan baik) apabila bilangan nod dalam kelompok meningkat. Angka yang menonjol ialah kependaman purata yang sangat rendah, yang berbeza dengan hasil daripada beban kerja bercampur (95% membaca dan 5% menulis) seperti yang diterangkan dalam bahagian di atas.
Penskalaan?
Menambah dan mengurangkan bilangan nod Spanner Awan ialah tugas satu klik. Jika anda ingin memuatkan data dengan cepat, anda mungkin ingin mempertimbangkan untuk meningkatkan contoh kepada maksimum (dalam kes kami, ia adalah 25 nod di rantau AS-EAST) dan kemudian mengurangkan bilangan nod yang sesuai untuk beban biasa anda selepas semua data dalam pangkalan data , dengan mengingati had 2 TB/nod.
Kami diingatkan tentang had ini walaupun dengan pangkalan data yang lebih kecil. Selepas beberapa ujian beban dijalankan, pangkalan data kami bersaiz kira-kira 155 GB dan apabila dikecilkan kepada contoh 1 nod, kami mendapat ralat berikut:
Kami dapat menurunkan skala daripada 25 kepada 2 kejadian, tetapi kami terperangkap pada dua nod.
Menaikkan dan mengurangkan bilangan nod dalam gugusan Cloud Spanner boleh diautomasikan menggunakan API REST. Ini amat berguna untuk mengurangkan beban yang meningkat pada sistem semasa waktu sibuk.
Prestasi pertanyaan OLAP?
Kami pada asalnya merancang untuk menumpukan banyak masa untuk penilaian kami Spanner pada bahagian ini. Selepas beberapa KIRAAN PILIH, kami segera menyedari bahawa ujian itu akan menjadi pendek dan Spanner TIDAK akan menjadi enjin yang sesuai untuk OLAP. Tanpa mengira bilangan nod dalam kelompok, hanya memilih bilangan baris dalam jadual baris 10M mengambil masa 55 hingga 60 saat. Selain itu, sebarang pertanyaan yang memerlukan lebih banyak memori untuk menyimpan hasil perantaraan gagal dengan ralat OOM.
SELECT COUNT(DISTINCT(field0)) FROM usertable; β (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.
Beberapa nombor untuk pertanyaan TPC-H boleh didapati dalam artikel Todd Lipcon , slaid 42 dan 43. Nombor ini konsisten dengan keputusan kami sendiri (malangnya).
4. Penemuan kami
Memandangkan keadaan semasa ciri Cloud Spanner, sukar untuk melihatnya sebagai pengganti mudah untuk penyelesaian OLTP sedia ada, terutamanya apabila keperluan anda mengatasinya. Sebilangan besar masa perlu dibelanjakan untuk membina penyelesaian mengenai kelemahan Cloud Spanner.
Apabila kami mula menilai Cloud Spanner, kami menjangkakan ciri pengurusannya setanding dengan, atau sekurang-kurangnya tidak jauh dari, penyelesaian Google SQL yang lain. Tetapi kami terkejut dengan kekurangan sandaran sepenuhnya dan kawalan akses yang sangat terhad kepada sumber. Apatah lagi tiada pandangan, tiada persekitaran pembangunan tempatan, urutan tidak disokong, JDBC tanpa sokongan DML dan DDL, dan sebagainya.
Jadi, ke mana hendak pergi bagi seseorang yang perlu menskalakan pangkalan data transaksi? Nampaknya masih belum ada penyelesaian tunggal di pasaran yang sesuai untuk semua kes penggunaan. Terdapat banyak penyelesaian sumber tertutup dan terbuka (beberapa daripadanya disebut dalam artikel ini), masing-masing mempunyai kekuatan dan kelemahan mereka sendiri, tetapi tiada satu pun daripada mereka menawarkan SaaS dengan SLA 99,999% dan tahap konsistensi yang tinggi. Jika SLA yang tinggi ialah matlamat utama anda dan anda tidak cenderung untuk membina penyelesaian anda sendiri untuk berbilang awan, Cloud Spanner mungkin merupakan penyelesaian yang anda cari. Tetapi anda harus sedar tentang semua batasannya.
Untuk bersikap adil, Cloud Spanner hanya dikeluarkan kepada umum pada musim bunga 2017, jadi wajar untuk menjangkakan beberapa kelemahan semasanya akhirnya akan hilang (mudah-mudahan), dan apabila ia berlaku, ia boleh menjadi pengubah permainan. Lagipun, Cloud Spanner bukan sekadar projek sampingan untuk Google. Google menggunakannya sebagai asas untuk produk Google yang lain. Dan apabila Google baru-baru ini menggantikan Megastore dalam Google Cloud Storage dengan Cloud Spanner, ia membenarkan Google Cloud Storage menjadi sangat konsisten untuk senarai objek di seluruh dunia (yang masih tidak berlaku untuk ).
Jadi, masih ada harapan... kita harap.
Itu sahaja. Seperti penulis artikel, kami juga terus berharap, tetapi apa pendapat anda tentang perkara ini? Tulis dalam komen
Kami menjemput semua orang untuk melawat kami di mana kami akan memberitahu anda secara terperinci tentang kursus tersebut daripada OTUS.
Sumber: www.habr.com