Halo warga Khabrovsk. Seperti biasa, kami terus berbagi materi menarik menjelang dimulainya kursus baru. Hari ini, khusus untuk Anda, kami telah menerbitkan artikel tentang Google Cloud Spanner bertepatan dengan peluncuran kursus .
Awalnya diterbitkan di .
Sebagai perusahaan yang menawarkan berbagai solusi POS berbasis cloud kepada pengecer, pemilik restoran, dan penjual online di seluruh dunia, Lightspeed menggunakan beberapa jenis platform database untuk berbagai kasus penggunaan transaksional, analitis, dan pencarian. Masing-masing platform basis data ini memiliki kekuatan dan kelemahan masing-masing. Oleh karena itu, ketika Google memperkenalkan Cloud Spanner ke pasar - fitur-fitur menjanjikan yang belum pernah ada dalam dunia basis data relasional, seperti skalabilitas horizontal yang hampir tidak terbatas dan perjanjian tingkat layanan (SLA) 99,999%. β kami tidak boleh melewatkan kesempatan untuk mendapatkannya!
Untuk memberikan gambaran menyeluruh tentang pengalaman kami dengan Cloud Spanner, serta kriteria evaluasi yang kami gunakan, kami akan membahas topik berikut:
- Kriteria evaluasi kami
- Singkatnya, Cloud Spanner
- Penilaian kami
- Temuan kami
1. Kriteria evaluasi kami
Sebelum mendalami secara spesifik Cloud Spanner, persamaan dan perbedaannya dengan solusi lain yang ada di pasaran, mari kita bahas dulu kasus penggunaan utama yang ada dalam pikiran kami saat mempertimbangkan lokasi penerapan Cloud Spanner di infrastruktur kami:
- Sebagai pengganti solusi database SQL tradisional (dominan).
- Bagaimana solusi OLTP dengan dukungan OLAP
Catatan: Untuk kesederhanaan dan kemudahan perbandingan, artikel ini membandingkan Cloud Spanner dengan varian MySQL dari rangkaian solusi GCP Cloud SQL dan Amazon AWS RDS.
Menggunakan Cloud Spanner sebagai pengganti solusi database SQL tradisional
Di lingkungan tradisional database, ketika waktu respons kueri database mendekati atau bahkan melebihi ambang batas aplikasi yang telah ditentukan (terutama karena peningkatan jumlah pengguna dan/atau permintaan), ada beberapa cara untuk mengurangi waktu respons ke tingkat yang dapat diterima. Namun, sebagian besar solusi ini melibatkan intervensi manual.
Misalnya, langkah pertama yang harus diambil adalah melihat berbagai parameter database terkait kinerja dan menyesuaikannya agar paling cocok dengan pola kasus penggunaan aplikasi. Jika ini tidak cukup, Anda dapat memilih untuk menskalakan database secara vertikal atau horizontal.
Penskalaan aplikasi secara vertikal memerlukan peningkatan instans server, biasanya dengan menambahkan lebih banyak prosesor/inti, lebih banyak RAM, penyimpanan lebih cepat, dll. Menambahkan lebih banyak sumber daya perangkat keras menghasilkan peningkatan kinerja basis data, terutama diukur dalam transaksi dalam hitungan detik, dan latensi transaksi untuk sistem OLTP. Sistem database relasional (yang menggunakan pendekatan multi-threaded) seperti MySQL berskala vertikal dengan baik.
Ada beberapa kelemahan dari pendekatan ini, namun yang paling jelas adalah ukuran server maksimum yang ada di pasaran. Setelah batas instance server terbesar tercapai, hanya ada satu pilihan yang tersisa: penskalaan horizontal.
Penskalaan horizontal adalah pendekatan di mana lebih banyak server ditambahkan ke sebuah cluster, idealnya meningkatkan kinerja secara linier seiring dengan bertambahnya jumlah server. Mayoritas tradisional Sistem basis data tidak dapat diskalakan secara horizontal dengan baik atau tidak dapat diskalakan sama sekali. Misalnya, MySQL dapat menskalakan secara horizontal untuk operasi baca dengan menambahkan pembaca budak, namun tidak dapat menskalakan secara horizontal untuk operasi tulis.
Di sisi lain, karena sifatnya, Cloud Spanner dapat dengan mudah melakukan penskalaan secara horizontal dengan intervensi minimal.
Berfitur lengkap DBMS sebagai layanan harus dinilai dari sudut yang berbeda. Sebagai dasar, kami mengambil DBMS paling populer di cloud - untuk Google, GCP Cloud SQL dan untuk Amazon, AWS RDS. Dalam penilaian kami, kami fokus pada kategori berikut:
- Pemetaan fitur: sejauh mana SQL, DDL, DML; perpustakaan/konektor koneksi, dukungan transaksi, dan sebagainya.
- Dukungan pengembangan: pengembangan dan pengujian yang mudah.
- Dukungan administrasi: manajemen instans - misalnya, meningkatkan/menurunkan skala dan meningkatkan instans; SLA, pencadangan dan pemulihan; kontrol keamanan/akses.
Menggunakan Cloud Spanner sebagai solusi OLTP yang mendukung OLAP
Meskipun Google tidak secara eksplisit mengklaim bahwa Cloud Spanner dirancang untuk pemrosesan analitis, Google memiliki beberapa atribut yang sama dengan mesin lain seperti Apache Impala & Kudu dan YugaByte, yang dirancang untuk beban kerja OLAP.
Meskipun kecil kemungkinannya Cloud Spanner menyertakan mesin HTAP (pemrosesan transaksional/analitik hibrid) yang diperluas secara konsisten dengan rangkaian fitur OLAP (kurang lebih) yang dapat digunakan, menurut kami hal ini layak untuk diperhatikan.
Dengan mengingat hal ini, kami melihat kategori berikut:
- Pemuatan data, indeks dan dukungan partisi
- Performa Kueri dan DML
2. Singkatnya, Cloud Spanner
Google Spanner adalah sistem manajemen basis data relasional berkerumun (RDBMS) yang digunakan Google untuk beberapa layanannya sendiri. Google menyediakannya secara umum untuk pengguna Google Cloud Platform pada awal tahun 2017.
Berikut beberapa atribut Cloud Spanner:
- Cluster RDBMS yang Sangat Konsisten dan Dapat Diskalakan: Menggunakan sinkronisasi waktu perangkat keras untuk memastikan konsistensi data.
- Dukungan transaksi lintas tabel: Transaksi dapat mencakup beberapa tabel - tidak harus terbatas pada satu tabel (tidak seperti Apache HBase atau Apache Kudu).
- Tabel berbasis kunci utama: Semua tabel harus memiliki kunci utama (PC) yang dideklarasikan, yang dapat terdiri dari beberapa kolom dalam tabel. Data tabular disimpan dalam urutan PC, sehingga sangat efisien dan cepat untuk pencarian PC. Seperti sistem berbasis PC lainnya, implementasinya harus dimodelkan dengan mempertimbangkan kasus penggunaan yang telah dirancang sebelumnya untuk mencapainya .
- Tabel bergaris: Tabel dapat memiliki ketergantungan fisik satu sama lain. Baris dalam tabel anak dapat dicocokkan dengan baris dalam tabel induk. Pendekatan ini mempercepat pencarian hubungan yang dapat diidentifikasi selama fase pemodelan data, seperti penempatan pelanggan dan faktur mereka.
- Indeks: Cloud Spanner mendukung indeks sekunder. Indeks terdiri dari kolom yang diindeks dan semua kolom PC. Jika diinginkan, indeks juga dapat berisi kolom lain yang tidak diindeks. Indeks dapat disisipkan dengan tabel induk untuk mempercepat kueri. Beberapa batasan berlaku pada indeks, seperti jumlah maksimum kolom tambahan yang disimpan dalam indeks. Selain itu, kueri melalui indeks mungkin tidak semudah di RDBMS lainnya.
βCloud Spanner memilih indeks secara otomatis hanya dalam kasus yang jarang terjadi. Secara khusus, Cloud Spanner tidak secara otomatis memilih indeks sekunder jika kueri meminta kolom apa pun yang tidak disimpan '.
- Service Level Agreement (SLA): Penerapan dalam satu wilayah dengan SLA 99,99%; penerapan multi-regional dengan SLA 99,999%. Meskipun SLA itu sendiri hanyalah perjanjian dan bukan jaminan apa pun, saya yakin orang-orang di Google memiliki data yang kuat untuk membuat klaim yang kuat. (Sebagai referensi, 99,999% berarti tidak tersedianya layanan selama 26,3 detik per bulan.)
- Lebih lanjut:
Catatan: Proyek Apache Tephra menambahkan dukungan transaksi yang ditingkatkan ke Apache HBase (sekarang juga diterapkan di Apache Phoenix sebagai beta).
3. Penilaian kami
Jadi, kita semua telah membaca klaim Google tentang manfaat Cloud Spanner - penskalaan horizontal yang hampir tidak terbatas dengan tetap menjaga konsistensi tinggi dan SLA yang sangat tinggi. Meskipun persyaratan ini, bagaimanapun juga, sangat sulit untuk dicapai, tujuan kami bukanlah untuk menyangkalnya. Sebaliknya, mari kita fokus pada hal lain yang menjadi perhatian sebagian besar pengguna database: paritas dan kegunaan.
Kami mengevaluasi Cloud Spanner sebagai pengganti Sharded MySQL
Google Cloud SQL dan Amazon AWS RDS, dua DBMS OLTP paling populer di pasar cloud, memiliki serangkaian fitur yang sangat banyak. Namun, untuk menskalakan database ini melebihi ukuran satu node, Anda perlu melakukan partisi aplikasi. Pendekatan ini menciptakan kompleksitas tambahan baik untuk aplikasi maupun administrasi. Kami melihat bagaimana Spanner cocok dengan skenario menggabungkan beberapa shard ke dalam satu instance dan fitur apa (jika ada) yang mungkin perlu dikorbankan.
Dukungan SQL, DML dan DDL, serta konektor dan perpustakaan?
Pertama, saat memulai dengan database apa pun, Anda perlu membuat model data. Jika Anda berpikir Anda dapat menghubungkan JDBC Spanner ke alat SQL favorit Anda, Anda akan menemukan bahwa Anda dapat menanyakan data Anda dengannya, namun Anda tidak dapat menggunakannya untuk membuat tabel atau memodifikasi (DDL) atau menyisipkan/memperbarui/menghapus operasi (DML). JDBC resmi Google tidak mendukung keduanya.
"Pengemudi saat ini tidak mendukung pernyataan DML atau DDL."
Dokumentasi Kunci Pas
Situasinya tidak lebih baik dengan konsol GCP - Anda hanya dapat mengirim kueri SELECT. Beruntung ada driver JDBC dengan dukungan DML dan DDL dari komunitas, termasuk transaksi . Meskipun driver ini sangat berguna, kurangnya driver JDBC milik Google cukup mengejutkan. Untungnya, Google menawarkan dukungan yang cukup luas untuk perpustakaan klien (berdasarkan gRPC): C#, Go, Java, node.js, PHP, Python, dan Ruby.
Penggunaan API kustom Cloud Spanner yang hampir diwajibkan (karena kurangnya DDL dan DML di JDBC) mengakibatkan beberapa keterbatasan untuk area kode terkait seperti kumpulan koneksi atau kerangka pengikatan database (misalnya Spring MVC). Biasanya, saat menggunakan JDBC, Anda bebas memilih kumpulan koneksi favorit Anda (misalnya HikariCP, DBCP, C3PO, dll.) yang telah diuji dan berfungsi dengan baik. Dalam kasus API Spanner khusus, kita harus mengandalkan kerangka kerja/kumpulan pengikatan/sesi yang kita buat sendiri.
Desain yang berpusat pada kunci utama (PC) memungkinkan Cloud Spanner menjadi sangat cepat saat mengakses data melalui PC, namun juga menimbulkan beberapa masalah kueri.
- Anda tidak dapat memperbarui nilai kunci utama; Anda harus menghapus entri dari PC asli terlebih dahulu dan memasukkannya kembali dengan nilai baru. (Ini mirip dengan mesin database/penyimpanan berorientasi PC lainnya.)
- Setiap pernyataan UPDATE dan DELETE harus menentukan PC di WHERE, oleh karena itu tidak boleh ada pernyataan DELETE all yang kosong - harus selalu ada subquery, misalnya: UPDATE xxx WHERE id IN (SELECT id FROM table1)
- Kurangnya opsi kenaikan otomatis atau hal serupa yang mengatur urutan bidang PC. Agar ini berfungsi, nilai yang sesuai harus dibuat di sisi aplikasi.
Indeks sekunder?
Google Cloud Spanner memiliki dukungan bawaan untuk indeks sekunder. Ini adalah fitur yang sangat bagus yang tidak selalu ada di teknologi lain. Apache Kudu saat ini tidak mendukung indeks sekunder sama sekali, dan Apache HBase tidak mendukung indeks secara langsung, tetapi dapat menambahkannya melalui Apache Phoenix.
Indeks di Kudu dan HBase dapat dimodelkan sebagai tabel terpisah dengan komposisi kunci utama yang berbeda, namun atomisitas operasi yang dilakukan pada tabel induk dan tabel indeks terkait harus dilakukan pada tingkat aplikasi dan tidak mudah untuk diterapkan dengan benar.
Seperti disebutkan dalam ulasan Cloud Spanner, indeksnya mungkin berbeda dari indeks MySQL. Oleh karena itu, perhatian khusus harus diberikan saat membuat kueri dan pembuatan profil untuk memastikan bahwa indeks yang tepat digunakan jika diperlukan.
Perwakilan?
Objek yang sangat populer dan berguna dalam database adalah tampilan. Mereka dapat berguna untuk sejumlah besar kasus penggunaan; dua favorit saya adalah lapisan abstraksi logis dan lapisan keamanan. Sayangnya, Cloud Spanner TIDAK mendukung tampilan. Namun, hal ini hanya membatasi sebagian kami karena tidak ada rincian izin akses pada tingkat kolom di mana tampilan mungkin merupakan solusi yang tepat.
Lihat dokumentasi Cloud Spanner untuk bagian yang merinci kuota dan batasan (), ada satu hal khusus yang dapat menjadi masalah untuk beberapa aplikasi: Cloud Spanner biasanya memiliki batas maksimal 100 database per instance. Tentu saja, hal ini dapat menjadi hambatan besar bagi database yang dirancang untuk menskalakan hingga lebih dari 100 database. Untungnya, setelah berbicara dengan perwakilan teknis Google, kami menemukan bahwa batas ini dapat ditingkatkan ke hampir semua nilai melalui Dukungan Google.
Dukungan pembangunan?
Cloud Spanner menawarkan dukungan bahasa pemrograman yang cukup baik untuk bekerja dengan API-nya. Pustaka yang didukung secara resmi ada di bidang C#, Go, Java, node.js, PHP, Python, dan Ruby. Dokumentasinya cukup rinci, namun seperti teknologi canggih lainnya, komunitasnya cukup kecil dibandingkan dengan teknologi database terpopuler, sehingga dapat menghabiskan lebih banyak waktu untuk menyelesaikan kasus atau masalah penggunaan yang kurang umum.
Lalu bagaimana dengan mendukung pembangunan lokal?
Kami belum menemukan cara untuk membuat instance Cloud Spanner lokal. Hal terdekat yang kami dapatkan adalah image Docker. , yang pada prinsipnya serupa, tetapi praktiknya sangat berbeda. Misalnya, CockroachDB dapat menggunakan PostgreSQL JDBC. Karena lingkungan pengembangan harus sedekat mungkin dengan lingkungan produksi, Cloud Spanner tidak ideal karena harus bergantung pada instance Spanner penuh. Untuk menghemat biaya, Anda dapat memilih instans wilayah tunggal.
Dukungan administrasi?
Membuat instance Cloud Spanner sangatlah sederhana. Anda hanya perlu memilih antara membuat instance multi-wilayah atau satu wilayah, menentukan wilayah dan jumlah node. Dalam waktu kurang dari satu menit, instance Anda akan aktif dan berjalan.
Beberapa metrik dasar dapat diakses langsung dari laman Spanner di Konsol Google. Tampilan yang lebih detail tersedia melalui Stackdriver, tempat Anda juga dapat menetapkan ambang batas metrik dan kebijakan pemberitahuan.
Akses terhadap sumber daya?
MySQL menawarkan pengaturan yang luas dan sangat terperinci untuk izin/peran pengguna. Anda dapat dengan mudah mengonfigurasi akses ke tabel tertentu, atau bahkan hanya sebagian kolomnya. Cloud Spanner menggunakan alat Manajemen Identitas & Akses (IAM) Google, yang hanya memungkinkan Anda menetapkan kebijakan dan izin pada tingkat yang sangat tinggi. Opsi yang paling terperinci adalah resolusi tingkat database, yang tidak sesuai dengan sebagian besar kasus penggunaan produksi. Batasan ini memaksa Anda untuk menambahkan tindakan keamanan tambahan pada kode, infrastruktur, atau keduanya untuk mencegah penggunaan sumber daya Spanner tanpa izin.
Cadangan?
Sederhananya, tidak ada cadangan di Cloud Spanner. Meskipun persyaratan SLA Google yang tinggi dapat memastikan bahwa Anda tidak kehilangan data apa pun karena kegagalan perangkat keras atau basis data, kesalahan manusia, cacat aplikasi, dll. Kita semua tahu aturannya: ketersediaan tinggi bukanlah pengganti strategi pencadangan yang baik. Saat ini, satu-satunya cara untuk mencadangkan data adalah dengan mengalirkannya secara terprogram dari database ke lingkungan penyimpanan terpisah.
Performa kueri?
Kami menggunakan Yahoo! untuk memuat data dan menguji pertanyaan. Tolok Ukur Pelayanan Cloud. Tabel di bawah menunjukkan beban kerja B YCSB dengan rasio baca hingga 95% tulis.
* Uji beban dijalankan pada Compute Engine (CE) n1-standard-32 (32 vCPU, memori 120 GB), dan instance pengujian tidak pernah menjadi hambatan dalam pengujian.
** Jumlah maksimum thread dalam satu instance YCSB adalah 400. Sebanyak enam instance paralel pengujian YCSB harus dijalankan untuk mendapatkan total 2400 thread.
Melihat hasil benchmark, khususnya kombinasi beban CPU dan TPS, kami dapat melihat dengan jelas bahwa skala Cloud Spanner cukup baik. Beban berat yang ditimbulkan oleh banyaknya thread diimbangi oleh banyaknya node di cluster Cloud Spanner. Meskipun latensinya terlihat cukup tinggi, terutama saat dijalankan dengan 2400 thread, pengujian ulang dengan 6 instance mesin komputasi yang lebih kecil mungkin diperlukan untuk mendapatkan angka yang lebih akurat. Setiap instans akan menjalankan satu pengujian YCSB, bukan satu instans CE besar dengan 6 pengujian paralel. Dengan cara ini, akan lebih mudah untuk membedakan antara latensi permintaan Cloud Spanner dan latensi yang ditambahkan oleh koneksi jaringan antara Cloud Spanner dan instance CE yang menjalankan pengujian.
Bagaimana kinerja Cloud Spanner sebagai OLAP?
Mempartisi?
Membagi data menjadi segmen yang independen secara fisik dan/atau logika, yang disebut partisi, adalah konsep yang sangat populer yang ditemukan di sebagian besar mesin OLAP. Partisi dapat secara signifikan meningkatkan kinerja kueri dan pemeliharaan basis data. Mempelajari lebih dalam tentang partisi akan menjadi artikel tersendiri, jadi mari kita bahas saja pentingnya memiliki skema partisi dan sub-partisi. Kemampuan untuk memecah data menjadi beberapa partisi dan lebih jauh lagi menjadi subpartisi adalah kunci kinerja kueri analitik.
Cloud Spanner tidak mendukung partisi seperti itu. Ini membagi data secara internal menjadi apa yang disebut membagi-s berdasarkan rentang kunci utama. Partisi dilakukan secara otomatis untuk menyeimbangkan beban di cluster Cloud Spanner. Fitur Cloud Spanner yang sangat berguna adalah pemisahan beban dasar tabel induk (tabel yang tidak disisipkan dengan tabel lain). Spanner secara otomatis mendeteksi apakah berisi membagi data yang dibaca lebih sering dibandingkan data lainnya membagi-ah, dan mungkin memutuskan perpisahan lebih lanjut. Dengan cara ini, lebih banyak node dapat dilibatkan dalam permintaan, yang juga secara efektif meningkatkan throughput.
Memuat data?
Metode Cloud Spanner untuk data massal sama dengan metode pemuatan normal. Untuk mencapai performa maksimal, Anda perlu mengikuti beberapa panduan, antara lain:
- Urutkan data Anda berdasarkan kunci utama.
- Bagilah dengan 10*jumlah node bagian yang terpisah.
- Buat serangkaian tugas kerja yang memuat data secara paralel.
Pemuatan data ini menggunakan semua node Cloud Spanner.
Kami menggunakan beban kerja A YCSB untuk menghasilkan kumpulan data 10 juta baris.
* Uji beban dijalankan pada mesin komputasi n1-standard-32 (32 vCPU, memori 120 GB), dan instance pengujian tidak pernah menjadi hambatan dalam pengujian.
**Penyiapan node tunggal tidak disarankan untuk beban kerja produksi apa pun.
Seperti disebutkan di atas, Cloud Spanner secara otomatis memproses pemisahan berdasarkan bebannya, sehingga hasilnya meningkat setelah beberapa kali pengulangan pengujian berturut-turut. Hasil yang disajikan di sini adalah hasil terbaik yang kami peroleh. Melihat angka-angka di atas, kita dapat melihat bagaimana Cloud Spanner berkembang dengan baik seiring dengan bertambahnya jumlah node dalam cluster. Angka-angka yang menonjol adalah latensi rata-rata yang sangat rendah, berbeda dengan hasil untuk beban kerja campuran (95% baca dan 5% tulis) seperti dijelaskan pada bagian di atas.
Penskalaan?
Menambah dan mengurangi jumlah node Cloud Spanner sangatlah mudah. Jika Anda ingin memuat data dengan cepat, Anda dapat mempertimbangkan untuk meningkatkan instans Anda hingga maksimum (dalam kasus kami, jumlah node di wilayah AS-Timur adalah 25 node) dan kemudian mengurangi jumlah node yang memenuhi syarat untuk memuat normal setelah semua data masuk. database , mengacu pada batas 2TB/node.
Kami diingatkan akan batasan ini bahkan dengan database yang jauh lebih kecil. Setelah beberapa kali uji beban, database kami berukuran sekitar 155 GB, dan ketika diperkecil menjadi 1 node, kami menerima kesalahan berikut:
Kami berhasil menurunkan skala dari 25 menjadi 2 instance, namun kami terjebak di dua node.
Menambah dan mengurangi jumlah node dalam cluster Cloud Spanner dapat diotomatisasi menggunakan REST API. Hal ini khususnya berguna untuk mengurangi peningkatan beban sistem selama jam kerja sibuk.
Kinerja kueri OLAP?
Kami awalnya berencana menghabiskan banyak waktu dalam evaluasi Spanner pada bagian ini. Setelah beberapa kali SELECT COUNT, kami segera menyadari bahwa pengujian akan singkat dan Spanner TIDAK akan menjadi mesin yang cocok untuk OLAP. Terlepas dari jumlah node dalam cluster, memilih jumlah baris dalam tabel baris 10 juta memerlukan waktu antara 55 dan 60 detik. Selain itu, kueri apa pun yang memerlukan lebih banyak memori untuk menyimpan hasil antara gagal karena kesalahan OOM.
SELECT COUNT(DISTINCT(field0)) FROM usertable; β (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.
Beberapa nomor untuk pertanyaan TPC-H dapat ditemukan di artikel Todd Lipcon , slide 42 dan 43. Angka-angka ini sesuai dengan hasil kami (sayangnya).
4. Kesimpulan kami
Mengingat kondisi fitur Cloud Spanner saat ini, sulit membayangkannya sebagai pengganti sederhana untuk solusi OLTP Anda yang sudah ada, terutama ketika kebutuhan Anda melebihi solusi tersebut. Banyak waktu yang harus dihabiskan untuk membangun solusi mengatasi kekurangan Cloud Spanner.
Saat kami mulai mengevaluasi Cloud Spanner, kami berharap fitur pengelolaannya setara dengan, atau setidaknya tidak terlalu jauh dari, solusi Google SQL lainnya. Namun kami terkejut dengan kurangnya cadangan dan sangat terbatasnya kontrol atas akses ke sumber daya. Belum lagi tidak ada tampilan, tidak ada lingkungan pengembangan lokal, urutan tidak didukung, JDBC tanpa dukungan DML dan DDL, dan sebagainya.
Jadi kemana perginya seseorang yang perlu menskalakan database transaksional? Tampaknya tidak ada satu solusi pun di pasaran yang cocok untuk semua kasus penggunaan. Ada banyak solusi sumber tertutup dan terbuka (beberapa di antaranya disebutkan dalam artikel ini), masing-masing dengan kekuatan dan kelemahannya masing-masing, namun tidak satupun yang menawarkan SaaS dengan SLA 99,999% dan konsistensi tinggi. Jika SLA tinggi adalah tujuan utama Anda dan Anda tidak ingin membangun solusi multi-cloud khusus, Cloud Spanner mungkin merupakan solusi yang Anda cari. Namun Anda harus menyadari semua keterbatasannya.
Agar adil, Cloud Spanner baru dirilis ke publik pada musim semi tahun 2017, jadi masuk akal untuk memperkirakan bahwa beberapa kekurangan yang ada saat ini pada akhirnya akan hilang (mudah-mudahan), dan ketika hal tersebut terjadi, hal ini bisa menjadi sebuah terobosan baru. Bagaimanapun, Cloud Spanner bukan sekadar proyek sampingan bagi Google. Google menggunakannya sebagai dasar untuk produk Google lainnya. Dan ketika Google baru-baru ini mengganti Megastore di Google Cloud Storage dengan Cloud Spanner, hal ini memungkinkan Google Cloud Storage menjadi sangat konsisten untuk daftar objek dalam skala global (yang masih belum berlaku untuk ).
Jadi, masih ada harapan⦠kami harap.
Itu saja. Seperti penulis artikel tersebut, kami juga terus berharap, namun bagaimana pendapat Anda mengenai hal ini? Tulis di komentar
Kami mengundang semua orang untuk mengunjungi kami di dalamnya kami akan memberi tahu Anda secara rinci tentang kursus tersebut dari OTUS.
Sumber: www.habr.com