Get best of the week

Google Cloud Spanner: baik, buruk, jahat

Hai, Habrovsk. Secara tradisional, kami terus membagikan materi yang menarik untuk mengantisipasi peluncuran kursus baru. Hari ini, khusus untuk Anda, kami telah menerbitkan artikel tentang Google Cloud Spanner, yang waktunya bertepatan dengan peluncuran kursus AWS untuk Pengembang .



Awalnya diposting di blog Lightspeed HQ .

Sebagai perusahaan yang menawarkan banyak solusi POS berbasis cloud untuk pengecer, pemilik restoran, dan pengecer online di seluruh dunia, Lightspeed menggunakan beberapa jenis platform basis data yang berbeda untuk berbagai kasus transaksi, analitik, dan pencarian. Masing-masing platform basis data ini memiliki kekuatan dan kelemahannya sendiri. Akibatnya, ketika Google memperkenalkan Cloud Spanner di pasar, fitur-fitur yang menjanjikan belum pernah terjadi sebelumnya di dunia basis data relasional, seperti skalabilitas horisontal yang hampir tidak terbatas dan perjanjian tingkat layanan (SLA) 99,999%. - kita tidak bisa melewatkan kesempatan untuk mendapatkannya di tangan kita!

Untuk memberikan ikhtisar komprehensif pengalaman kami dengan Cloud Spanner, serta kriteria evaluasi yang kami gunakan, kami akan membahas topik-topik berikut:

  1. Kriteria evaluasi kami
  2. Singkatnya Cloud Spanner
  3. Peringkat kami
  4. Temuan kami



1. Kriteria evaluasi kami


Sebelum mempelajari fitur-fitur Cloud Spanner, persamaan dan perbedaannya dengan solusi lain di pasaran, pertama-tama mari kita bicara tentang kasus-kasus pengguna utama yang kami pikirkan ketika mempertimbangkan di mana akan menggunakan Cloud Spanner dalam infrastruktur kami:

  • Sebagai pengganti untuk solusi database SQL tradisional (yang berlaku)
  • Bagaimana Solusi OLTP dengan Dukungan OLAP

Catatan: Untuk kesederhanaan dan kemudahan perbandingan, artikel ini membandingkan Cloud Spanner dengan MySQL GCP Cloud SQL dan keluarga solusi Amazon AWS RDS.

Menggunakan Cloud Spanner sebagai pengganti solusi database SQL tradisional


Dalam lingkungan basis data tradisional , ketika waktu respons terhadap permintaan basis data mendekati atau bahkan melebihi ambang batas aplikasi yang telah ditentukan (terutama karena peningkatan jumlah pengguna dan / atau kueri), ada beberapa cara untuk mengurangi waktu respons ke tingkat yang dapat diterima. Namun, sebagian besar solusi ini termasuk intervensi manual.

Misalnya, langkah pertama yang perlu Anda ambil adalah untuk melihat berbagai parameter basis data yang terkait dengan kinerja dan mengkonfigurasinya agar sesuai dengan pola penggunaan aplikasi. Jika ini tidak cukup, Anda dapat memilih untuk menskalakan basis data secara vertikal atau horizontal.

Meningkatkan aplikasi memerlukan pembaruan instance server, biasanya dengan menambahkan lebih banyak prosesor / core, lebih banyak RAM, penyimpanan lebih cepat, dll. Menambahkan lebih banyak sumber daya perangkat keras mengarah pada peningkatan kinerja basis data, terutama diukur dalam transaksi di kedua, dan penundaan transaksi untuk sistem OLTP. Sistem basis data relasional (yang menggunakan pendekatan multi-threaded), seperti MySQL, skala dengan baik secara vertikal.

Pendekatan ini memiliki beberapa kelemahan, tetapi yang paling jelas adalah ukuran server maksimum di pasar. Setelah batas instance server terbesar tercapai, hanya ada satu cara: penskalaan horizontal.

Penskalaan horizontal adalah suatu pendekatan di mana lebih banyak server ditambahkan ke kluster untuk secara ideal meningkatkan kinerja dengan penambahan jumlah server. Sebagian besar sistem basis data tradisional tidak skala baik secara horizontal atau tidak skala sama sekali. Sebagai contoh, MySQL dapat skala secara horizontal untuk operasi membaca dengan menambahkan pembaca budak, tetapi tidak dapat skala secara horizontal untuk operasi menulis.

Di sisi lain, karena sifatnya, Cloud Spanner dapat dengan mudah skala secara horizontal dengan gangguan minimal. DBMS

berfitur lengkap sebagai layananharus dievaluasi 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: Tingkat SQL, DDL, DML; perpustakaan koneksi / konektor, dukungan transaksi, dan sebagainya.
  • Dukungan pengembangan: kemudahan pengembangan dan pengujian.
  • Dukungan administrasi: manajemen instance - misalnya, meningkatkan / menurunkan dan meningkatkan instance; SLA, backup dan restore; kontrol keamanan / akses.

Menggunakan Cloud Spanner sebagai OLTP dengan Dukungan OLAP


Meskipun Google tidak secara eksplisit mengklaim bahwa Cloud Spanner adalah untuk pemrosesan analitik, Google membagikan beberapa atribut dengan mekanisme lain, seperti Apache Impala & Kudu dan YugaByte, yang dirancang untuk beban kerja OLAP.

Bahkan jika hanya ada kemungkinan kecil bahwa Cloud Spanner menyertakan HTAP (pemrosesan transaksional / analisis analitik) yang konsisten dan dapat diskalakan secara horizontal dengan serangkaian fitur OLAP yang dapat digunakan (kurang lebih), kami berpikir bahwa itu akan pantas mendapatkan perhatian kami.

Dengan mengingat hal ini, kami memeriksa kategori berikut:

  • Pemuatan data, indeks, dan dukungan partisi
  • Performa Permintaan dan DML

2. Cloud Spanner secara singkat


Google Spanner adalah sistem manajemen basis data relasional klaster (RDBMS) yang digunakan Google untuk beberapa layanannya sendiri. Google membuatnya tersedia untuk umum bagi pengguna Google Cloud Platform pada awal 2017.

Berikut adalah beberapa atribut Cloud Spanner:

  • Cluster RDBMS scalable yang sangat konsisten: Menggunakan sinkronisasi waktu perangkat keras untuk memastikan konsistensi data.
  • Dukungan transaksi lintas tabel: transaksi dapat menjangkau beberapa tabel - tidak harus terbatas pada satu tabel (tidak seperti Apache HBase atau Apache Kudu).
  • : (), . , . , .
  • : . . , , , -.
  • : Cloud Spanner . . . . , , , . , .

«Cloud Spanner . , Cloud Spanner , - , ».


: Apache Tephra Apache HBase ( Apache Phoenix -).

3.


Jadi, kita semua membaca pernyataan Google tentang manfaat Cloud Spanner - penskalaan horizontal hampir tak terbatas sambil mempertahankan konsistensi tinggi dan SLA sangat tinggi. Meskipun persyaratan ini, bagaimanapun juga, sangat sulit untuk dicapai, tujuan kami bukanlah untuk membantahnya. Sebagai gantinya, mari kita fokus pada hal-hal lain yang paling dipedulikan pengguna database: paritas dan kegunaan.

Kami memberi peringkat Cloud Spanner sebagai pengganti untuk Sharded MySQL


Google Cloud SQL dan Amazon AWS RDS, dua DBMS OLTP paling populer di pasar cloud, memiliki serangkaian fitur yang sangat besar. Namun, untuk skala basis data ini di luar ukuran satu node, Anda perlu melakukan partisi aplikasi. Pendekatan ini menciptakan kompleksitas tambahan untuk aplikasi dan administrasi. Kami melihat bagaimana Spanner cocok dengan skenario menggabungkan beberapa segmen menjadi satu contoh dan fitur mana (jika ada) yang harus dikorbankan.

Dukungan untuk SQL, DML dan DDL, serta konektor dan pustaka?


Pertama, ketika memulai dengan basis data apa pun, Anda harus membuat model data. Jika Anda berpikir bahwa Anda dapat menghubungkan JDBC Spanner ke alat SQL favorit Anda, Anda akan menemukan bahwa Anda dapat meminta data Anda dengannya, tetapi Anda tidak dapat menggunakannya untuk membuat tabel atau mengubah (DDL) atau operasi menyisipkan / memperbarui / menghapus ( DML). JDBC resmi Google juga tidak mendukung.
"Driver saat ini tidak mendukung DML atau DDL."
Dokumentasi spanner

Dengan konsol GCP, situasinya tidak lebih baik - Anda hanya dapat mengirim kueri SELECT. Untungnya, ada driver JDBC dengan dukungan DML dan DDL dari komunitas, termasuk transaksi github.com/olavloite/spanner-jdbc . Meskipun driver ini sangat berguna, kurangnya driver JDBC Google sendiri mengejutkan. Untungnya, Google menawarkan dukungan yang cukup luas untuk pustaka klien (berdasarkan gRPC): C #, Go, Java, node.js, PHP, Python, dan Ruby.

Penggunaan API pengguna Cloud Spanner yang hampir wajib (karena kurangnya DDL dan DML di JDBC) mengarah ke beberapa batasan untuk area kode terkait, seperti kumpulan koneksi atau kerangka kerja pengikatan basis data (mis. Spring MVC). Biasanya, ketika menggunakan JDBC, Anda dapat dengan bebas memilih kumpulan koneksi favorit Anda (mis. HikariCP, DBCP, C3PO, dll.), Yang diuji dan berfungsi dengan baik. Dalam kasus API Spanner khusus, kita harus mengandalkan kerangka / kumpulan / sesi mengikat yang kita buat sendiri.

Desain primary key (PC) memungkinkan Cloud Spanner menjadi sangat cepat ketika mengakses data melalui PC, tetapi juga mengarah pada beberapa masalah kueri.

  • ; . ( / .)
  • UPDATE DELETE WHERE, , DELETE all — , : UPDATE xxx WHERE id IN (SELECT id FROM table1)
  • - , . , .

?


Google Cloud Spanner memiliki dukungan bawaan untuk indeks sekunder. Ini adalah fitur yang sangat bagus yang tidak selalu hadir dalam 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 dalam Kudu dan HBase dapat dimodelkan sebagai tabel terpisah dengan komposisi kunci primer yang berbeda, tetapi atomicity operasi yang dilakukan pada tabel induk dan tabel indeks terkait harus dilakukan pada tingkat aplikasi dan tidak sepele dalam implementasi yang benar.

Seperti yang disebutkan dalam ulasan Cloud Spanner, indeksnya mungkin berbeda dari indeks MySQL. Oleh karena itu, perhatian khusus harus diberikan ketika membangun kueri dan pembuatan profil untuk memastikan bahwa indeks yang tepat digunakan di tempat yang diperlukan.

Perwakilan?


Objek yang sangat populer dan berguna dalam database adalah view. Mereka dapat berguna untuk sejumlah besar kasus pengguna; dua favorit saya adalah tingkat abstraksi logis dan tingkat keamanan. Sayangnya, Cloud Spanner TIDAK mendukung pengiriman. Namun, ini hanya membatasi sebagian kami, karena untuk izin akses tidak ada rincian di tingkat kolom di mana representasi mungkin merupakan solusi yang dapat diterima.

Dokumentasi Cloud Spanner memiliki bagian yang merinci kuota dan batasan ( spanner / kuota), ada, khususnya, yang mungkin bermasalah untuk beberapa aplikasi: Cloud Spanner di luar kotak memiliki batas maksimum 100 basis data per instance. Jelas, ini bisa menjadi hambatan serius untuk database yang dirancang untuk skala ke lebih dari 100 database. Untungnya, setelah berbicara dengan perwakilan teknis Google kami, kami mengetahui bahwa batas ini dapat ditingkatkan ke hampir semua nilai melalui dukungan Google.

Dukungan pengembangan?


Cloud Spanner menawarkan dukungan yang cukup baik untuk bahasa pemrograman agar dapat bekerja dengan API-nya. Perpustakaan yang didukung secara resmi berada di area C #, Go, Java, node.js, PHP, Python, dan Ruby. Dokumentasinya cukup terperinci, tetapi, seperti halnya teknologi canggih lainnya, komunitas ini cukup kecil dibandingkan dengan teknologi basis data yang paling populer, yang dapat menyebabkan peningkatan waktu yang dihabiskan untuk menyelesaikan kasus atau masalah penggunaan yang kurang umum.

Jadi bagaimana dengan dukungan pembangunan lokal?


Kami tidak menemukan cara untuk membuat instance Cloud Spanner di lingkungan lokal. Yang paling dekat yang kami dapatkan adalah gambar CockroachDB Docker , yang pada prinsipnya mirip, tetapi dalam praktiknya sangat berbeda. Sebagai contoh, CockroachDB dapat menggunakan PostgreSQL JDBC. Karena lingkungan pengembangan harus sedekat mungkin dengan lingkungan kerja, Cloud Spanner tidak ideal, karena Anda harus bergantung pada instance Spanner penuh. Untuk menghemat biaya, Anda dapat memilih contoh untuk satu wilayah.

Dukungan Administrasi?


Membuat instance Cloud Spanner mudah. Anda hanya perlu memilih antara membuat multi-regional atau instance untuk satu region, tentukan region (s) dan jumlah node. Dalam waktu kurang dari satu menit, mesin virtual akan aktif dan berjalan.

Beberapa metrik dasar tersedia langsung di halaman Spanner di konsol Google. Tampilan lebih rinci tersedia melalui Stackdriver, di mana Anda juga dapat menetapkan metrik ambang batas dan kebijakan peringatan.

Akses ke sumber daya?


MySQL menawarkan pengaturan izin / peran pengguna yang luas dan sangat terperinci. Anda dapat dengan mudah mengkonfigurasi akses ke tabel tertentu, atau bahkan hanya sebagian dari kolomnya. Cloud Spanner menggunakan alat Google Identity & Access Management (IAM), yang memungkinkan Anda untuk menetapkan kebijakan dan izin hanya pada tingkat yang sangat tinggi. Opsi paling terperinci adalah resolusi tingkat basis data yang tidak sesuai dengan kebanyakan kasus produksi. Pembatasan ini memaksa Anda untuk menambahkan langkah-langkah keamanan tambahan ke kode Anda, infrastruktur, atau keduanya untuk mencegah penggunaan sumber daya Spanner yang tidak sah.

Cadangan?


Secara sederhana, tidak ada cadangan di Cloud Spanner. Meskipun persyaratan tinggi dari Google SLA dapat menjamin bahwa Anda tidak akan kehilangan data apa pun karena kegagalan perangkat keras atau database, kesalahan manusia, cacat aplikasi, dll. Kita semua tahu aturannya: ketersediaan tinggi tidak menggantikan strategi cadangan yang masuk akal. Saat ini, satu-satunya cara untuk mencadangkan data adalah dengan secara terprogram mengalirkannya dari database ke lingkungan penyimpanan yang terpisah.

Performa permintaan?


Kami menggunakan Yahoo! untuk mengunduh data dan menguji kueri. Benchmark Penyajian Cloud. Tabel di bawah ini menunjukkan beban kerja YCSB B dengan rasio membaca 95% dan rasio tulis 5%.



* Tes beban dilakukan pada engine komputasi n1-standar-32 (CE) (32 vCPU, 120 GB memori), dan mesin uji tidak pernah menjadi hambatan dalam pengujian.
** Jumlah maksimum utas dalam satu contoh YCSB adalah 400. Secara total, enam contoh paralel dari pengujian YCSB harus dijalankan untuk mendapatkan total 2.400 utas.

Melihat hasil pengujian, khususnya kombinasi antara beban prosesor dan TPS, kami melihat dengan jelas bahwa Cloud Spanner berskala cukup baik. Beban besar yang dibuat oleh sejumlah besar thread dikompensasi oleh sejumlah besar node di cluster Cloud Spanner. Meskipun keterlambatan terlihat agak tinggi, terutama ketika bekerja dengan 2.400 benang, pengujian ulang dengan 6 mesin contoh yang lebih kecil mungkin diperlukan untuk mendapatkan angka yang lebih akurat. Setiap instance akan menjalankan satu tes YCSB alih-alih satu instance CE besar dengan 6 tes paralel. Dengan demikian, akan lebih mudah untuk membedakan antara penundaan permintaan Cloud Spanner dan penundaan yang ditambahkan oleh koneksi jaringan antara Cloud Spanner dan mesin virtual CE tempat pengujian dijalankan.

Bagaimana cara Cloud Spanner menangani OLAP?


Partisi?


Membagi data menjadi segmen-segmen yang secara fisik dan / atau independen secara logis, yang disebut partisi, adalah konsep yang sangat populer yang melekat dalam sebagian besar mekanisme OLAP. Partisi dapat secara signifikan meningkatkan kinerja kueri dan dukungan basis data. Pendalaman lebih lanjut dalam partisi akan muncul dalam artikel yang terpisah, jadi mari kita menyebutkan pentingnya memiliki skema partisi dan sub-partisi. Kemampuan untuk mempartisi data menjadi partisi dan lebih jauh lagi ke dalam sub-partisi adalah kunci kinerja query analitik.

Cloud Spanner tidak mendukung partisi per se. Ini membagi data secara internal menjadi apa yang disebut splitberdasarkan rentang kunci primer. Pemisahan dilakukan secara otomatis untuk menyeimbangkan beban di kluster Cloud Spanner. Fitur Cloud Spanner yang sangat mudah digunakan adalah dengan membagi beban dasar tabel induk (tabel yang tidak bergantian dengan yang lain). Spanner secara otomatis menentukan apakah split berisi data yang dibaca lebih sering daripada data di split lain , dan dapat memutuskan pemisahan lebih lanjut. Dengan demikian, lebih banyak node dapat terlibat dalam permintaan, yang juga secara efektif meningkatkan throughput.

Memuat data?


Metode Cloud Spanner untuk data massal sama dengan untuk unduhan biasa. Untuk mencapai kinerja maksimum, Anda harus mengikuti beberapa rekomendasi, termasuk:

  • Urutkan data Anda dengan kunci utama.
  • Membagi mereka dengan 10 * jumlah node masing - masing bagian.
  • Buat satu set tugas kerja yang memuat data secara paralel.

Dengan unduhan data ini, semua node Cloud Spanner digunakan.

Kami menggunakan beban kerja A YCSB untuk menghasilkan dataset 10M baris.



* Uji beban dilakukan pada mesin komputasi n1-standard-32 (32 vCPU, 120 GB memori), dan mesin uji tidak pernah menjadi hambatan dalam pengujian.
** Konfigurasi 1-simpul tidak disarankan untuk beban produksi apa pun.

Seperti yang disebutkan di atas, Cloud Spanner secara otomatis memproses pemisahan-s tergantung pada bebannya, sehingga hasilnya meningkat setelah beberapa kali pengulangan pengujian. Hasil yang disajikan di sini adalah hasil terbaik yang kami terima. Melihat angka-angka di atas, kita dapat melihat bagaimana Cloud Spanner menskala (baik) dengan peningkatan jumlah node dalam cluster. Angka-angka yang menonjol adalah keterlambatan rata-rata yang sangat rendah yang kontras dengan hasil dari beban kerja campuran (95% untuk membaca dan 5% untuk menulis), seperti yang dijelaskan dalam bagian di atas.

Penskalaan?


Menambah dan mengurangi jumlah node Cloud Spanner adalah tugas sekali klik. Jika Anda ingin memuat data dengan cepat, Anda dapat mempertimbangkan untuk meningkatkan instance ke maksimum (dalam kasus kami, itu adalah 25 node di wilayah AS-EAST), dan kemudian mengurangi jumlah node yang sesuai untuk beban reguler Anda, setelah semua data dalam database mengingat keterbatasan 2 TB / simpul.

Kami diingatkan akan batas ini bahkan dengan basis data yang jauh lebih kecil. Setelah beberapa kali menjalankan tes beban, basis data kami berukuran sekitar 155 GB, dan ketika direduksi menjadi 1 simpul, kami mendapatkan kesalahan berikut:



Kami berhasil mengurangi skala dari 25 hingga 2 instance, tetapi kami terjebak pada dua node.

Menambah dan mengurangi jumlah node dalam kluster Cloud Spanner dapat diotomatisasi menggunakan REST API. Ini bisa sangat berguna untuk mengurangi peningkatan beban pada sistem selama jam sibuk.

Performa permintaan OLAP?


Awalnya, kami berencana untuk mencurahkan banyak waktu untuk evaluasi Spanner kami untuk bagian ini. Setelah beberapa COUNT SELECT, kami segera menyadari bahwa pengujian akan singkat dan bahwa Spanner TIDAK akan menjadi mesin OLAP. Terlepas dari jumlah node dalam cluster, pemilihan sederhana jumlah baris dalam tabel 10M baris membutuhkan waktu 55 hingga 60 detik. Selain itu, permintaan apa pun yang membutuhkan lebih banyak memori untuk menyimpan hasil antara gagal dengan kesalahan OOM.

SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.

Beberapa angka untuk permintaan TPC-H dapat ditemukan dalam artikel Todd Lipcon Nosql-kudu-spanner-slides.html , slide 42 dan 43. Angka-angka ini konsisten dengan hasil kami sendiri (sayangnya).



4. Temuan kami


Mengingat kondisi Cloud Spanner saat ini, sulit untuk membayangkannya sebagai pengganti sederhana untuk solusi OLTP yang ada, terutama ketika kebutuhan Anda melebihi itu. Sejumlah besar waktu harus dihabiskan untuk membangun solusi yang memperhitungkan kelemahan Cloud Spanner.

Ketika kami mulai mengevaluasi Cloud Spanner, kami berharap fitur manajemennya setidaknya atau tidak jauh dari solusi Google SQL lainnya. Tetapi kami terkejut dengan kurangnya cadangan dan kontrol yang sangat terbatas atas akses ke sumber daya. Belum lagi kurangnya pandangan, kurangnya lingkungan pengembangan lokal, urutan yang tidak didukung, JDBC tanpa dukungan DML dan DDL, dan sebagainya.

Jadi, kemana perginya orang yang perlu menskalakan basis data transaksional? Tampaknya tidak ada solusi tunggal di pasar yang cocok untuk semua kasus penggunaan. Ada banyak solusi tertutup dan sumber terbuka (beberapa di antaranya disebutkan dalam artikel ini), yang masing-masing memiliki kekuatan dan kelemahannya sendiri, tetapi tidak satu pun dari mereka menawarkan SaaS dengan SLA 99,999% dan konsistensi tingkat tinggi. Jika SLA tinggi adalah tujuan utama Anda dan Anda tidak cenderung untuk membuat solusi sendiri untuk beberapa lingkungan cloud, Cloud Spanner mungkin menjadi solusi yang Anda cari. Tetapi Anda harus menyadari semua keterbatasannya.

Dalam keadilan, perlu dicatat bahwa Cloud Spanner tidak dirilis ke publik hanya pada musim semi 2017, jadi masuk akal untuk mengharapkan bahwa beberapa kekurangan saat ini pada akhirnya akan hilang (saya harap), dan ketika itu terjadi, itu dapat mengubah permainan. Lagi pula, Cloud Spanner bukan hanya proyek pihak ketiga untuk Google. Google menggunakannya sebagai dasar untuk produk Google lainnya. Dan ketika Google baru-baru ini menggantikan Megastore di Google Cloud Storage dengan Cloud Spanner, itu memungkinkan Google Cloud Storage untuk sepenuhnya konsisten untuk daftar objek secara global (yang masih tidak berlaku untuk Amazon S3 ).

Jadi, masih ada harapan ... kami harap.

Itu saja. Seperti penulis artikel, kami juga terus berharap, tetapi bagaimana menurut Anda tentang ini? Menulis di komentar.

Setiap orang diundang untuk mengunjungi webinar gratis kami , dalam kerangka yang akan kami bicarakan secara rinci tentang kursus AWS OTUS untuk Pengembang .

More articles:


All Articles