Google Cloud Spanner

by

Google cloud spanner adalah SQL Database enterprise dari Google dengan fitur berikut:

  • Managed SQL – compliant DB, menggunakan standard SQL ANSI 2011schema dan queries dengan ACID transactions.
  • Horizontally scalable.
  • Tingkat availability tinggi, global replication secara otomatis, hampir tidak ada downtime (99.999% SLA sering disebut juga five nine).

CAP Theorem menyatakan terdapat 3 fundamental prinsipal dalam distributed system yang menyimpan data:

  • Consistency, perubahan data harus mengikuti rule tertentu.
  • Availability, system tersedia untuk melayani query.
  • Partition Tolerance, distributed system harus toleransi bila terdapat partisi yang hilang.

Umumnya sistem hanya dapat memenuhi 2 prinsip diatas, misanya CA, AP atau CP.

Google spanner melakukan pendekatan CA system, namun untuk mentoleransi partition lost, kadang Spanner akan memilih consistency diatas avaibility, menjadi CP system. Jadi Google spanner menjanjikan 99.999% availbility dengan system yang consistent dan partition tolerance.

Spanner Instance

Untuk menggunakan Cloud Spanner, perlu membuat instance. Instance berupa alokasi resources. Sebuah intance dapat memiliki banyak database.

Instance configuration berguna untuk mendefinisikan:

  • Apakah sebuah instance regional atau multi-regional.
  • Inisial jumlah nodes, minimal 1 node berupa virtual machine yang menjalankan instance.

Regional Configuration

Misalnya dalam sebuah region terndapat 3 zone. Maka Google akan membuat 3 R/W replica.

Ketika kita menentukan konfigurasi 1 node, maka setiap intance akan memiliki 1 virtual machine. Pada contoh diatas jumlah node yang digunakan adalah 3. (perhatikan, jumlah node tidak sama dengan jumlah instance).

Seperti yang dijelaskan pada gambar diatas, Setiap node dapat melayani

  • 10.000 query per second (qps) read.
  • atau 2.000 qps writes.
  • 2 TB storage.

Regional Replication

  • Terdapat 3 R/W replicas
  • Setiap perubahan data membutuhkan write quorum dari mayoritas replica yaitu 2 dari 3 replica. Untuk informasi lebih lanjut lihat Distributed database quorum.

Best Practice Regional Spanner

  • Design performant schema, hindari pembuatan schema yang konflik dengan architecture Spanner. Spanner adalah distributed system, untuk mendapatkan performa terbaik, kita harus mendistribusikan operasi read dan write.
  • Gunakan region yang sama untuk compute workload dan spanner. Misalnya jika Anda menjalankan virtual machine di asia, tentu logisnya Instance spanner juga disimpan di asia.
  • Pastikan tersedia cukup node agar CPU utilization dibawah 65%.

Untuk bacaan lebih lanjut mengenai Best Practice Regional Spanner, silakan kunjungi disini.

Multi Regional Configuration

Tersedia dengan predefined configuration. Terdapat 4 konfigurasi yang disediakan oleh Google, yaitu EUR3, NAM3, NAM-EUR-ASIA1 dan NAM6 configuration.

Keuntungan Multi Regional Configuration

  • Availability 99.999% SLA.
  • Mengurangi latency untuk distributed data.
  • External consistency

Multi-regional replication

  • Replikasi pada multi-regional bervariasi tergantung konfigurasi yang Anda pilih.
  • Sama dengan regional replication, setiap perubahan data, memerlukan write quorum. Quorum harus berasal dari 1 replica leader region dan 2 dari replica lainnya.

Multi-regional best practice

  • Design performant schema.
  • Simpan write-heavy workload dalam region yang sama dengan leader region.
  • Sebarkan critical workload kedalam 2 regions.
  • Pastikan tersedia cukup node untuk menjaga CPU utilization dibawah 45%.

Untuk bacaan lebih lanjut, kunjungi Google Spanner Multi-regional best practice.

Data Model

  • Menggunakan relational database tables, artinya memiliki rows, columns, values, primary keys.
  • Strongly typed.
  • Strict schema.
  • Memiliki parent-child relationship. Bertujuan menempatkan data pada node yang sama untuk efisiensi. Dicapai dengan membuat interleaved table. Lihat table dibawah, misalnya table ship dengan table crew sebagai child. Mencari data crew dari ship tertentu akan lebih efisien.
IDName
SHIP(1)Enterprise
CREW(1, 1)Jean-Luc Picard
CREW(1, 2)William Riker
SHIP(2)Voyager
CREW(2, 1)Kathryn Janeway
CREW(2, 2)Tuvok

Spanner Transaction Type

  • Locking read-write, transaksi yang mendukung proses write ke database.
  • Read only.
  • Partitioned DML (Data <anipulation Language), didesain untuk bulk update dan delete.
  • Regular transaction biasanya dilakukan melalui client library atau menggunakan ANSI SQL. Untuk informasi lebih lanjut lihat ANSI SQL Best Practice.

Connecting to Cloud Spanner

Koneksi ke cloud spanner melalui public API, dapat dilakukan melalui:

  • Compute Engine.
  • Cloud Functions.
  • Cloud Dataflow connector.

External Docs

Sharing is caring: