Membuat pembaruan skema

Spanner memungkinkan Anda membuat pembaruan skema tanpa waktu non-operasional. Anda dapat memperbarui skema database yang ada dengan beberapa cara:

Pembaruan skema yang didukung

Spanner mendukung pembaruan skema berikut pada database yang ada:

  • Menambahkan atau menghilangkan skema bernama.
  • Buat tabel baru. Kolom dalam tabel baru dapat berupa NOT NULL.
  • Menghapus tabel, jika tidak ada tabel lain yang disisipkan di dalamnya, dan tidak memiliki indeks sekunder.
  • Membuat atau menghapus tabel dengan kunci asing.
  • Menambahkan atau menghapus kunci asing dari tabel yang ada.
  • Tambahkan kolom non-kunci ke tabel mana pun. Kolom non-kunci baru tidak boleh NOT NULL.
    • Menghapus kolom non-kunci dari tabel mana pun, kecuali jika digunakan oleh indeks sekunder, kunci asing, kolom yang dihasilkan tersimpan, atau batasan pemeriksaan.
  • Tambahkan NOT NULL ke kolom non-kunci, tidak termasuk kolom ARRAY.
  • Menghapus NOT NULL dari kolom non-kunci.
  • Ubah kolom STRING menjadi kolom BYTES atau kolom BYTES menjadi kolom STRING.
  • Ubah kolom PROTO menjadi kolom BYTES atau kolom BYTES menjadi kolom PROTO.
  • Mengubah jenis pesan proto kolom PROTO.
  • Tambahkan nilai baru ke definisi ENUM dan ganti nama nilai yang ada menggunakan ALTER PROTO BUNDLE.
  • Mengubah pesan yang ditentukan dalam PROTO BUNDLE dengan cara apa pun, asalkan kolom yang diubah dari pesan tersebut tidak digunakan sebagai kunci dalam tabel apa pun dan data yang ada memenuhi batasan baru.
  • Menaikkan atau menurunkan batas panjang untuk jenis STRING atau BYTES (termasuk MAX), kecuali jika merupakan kolom kunci utama yang diwarisi oleh satu atau beberapa tabel turunan.
  • Naikkan atau turunkan batas panjang untuk kolom ARRAY<STRING>, ARRAY<BYTES>, atau ARRAY<PROTO> ke batas maksimum yang diizinkan.
  • Aktifkan atau nonaktifkan stempel waktu penerapan di kolom nilai dan kunci utama.
  • Menambahkan atau menghapus indeks sekunder.
  • Menambahkan atau menghapus batasan pemeriksaan dari tabel yang ada.
  • Menambahkan atau menghapus kolom yang dihasilkan tersimpan dari tabel yang ada.
  • Buat paket statistik pengoptimal baru.
  • Membuat dan mengelola tampilan.
  • Membuat dan mengelola urutan.
  • Buat peran database dan berikan hak istimewa.
  • Menetapkan, mengubah, atau menghapus nilai default kolom.
  • Ubah opsi database (misalnya, default_leader atau version_retention_period).
  • Membuat dan mengelola aliran perubahan.
  • Membuat dan mengelola model ML.

Update skema yang tidak didukung

Spanner tidak mendukung pembaruan skema berikut pada database yang ada:

  • Jika ada kolom PROTO jenis ENUM yang direferensikan oleh kunci tabel atau indeks, Anda tidak dapat menghapus nilai ENUM dari proto enum. (Penghapusan nilai ENUM dari enum yang digunakan oleh kolom ENUM<> didukung, termasuk saat kolom tersebut digunakan sebagai kunci.)

  • Ubah kolom STRING(36) menjadi kolom UUID atau kolom UUID menjadi kolom STRING(36).

Performa update skema

Pembaruan skema di Spanner tidak memerlukan periode nonaktif. Saat menerbitkan tumpukan pernyataan DDL ke database Spanner, Anda dapat terus menulis dan membaca dari database tanpa gangguan sementara Spanner menerapkan pembaruan sebagai operasi yang berjalan lama.

Waktu yang diperlukan untuk mengeksekusi pernyataan DDL bergantung pada apakah pembaruan memerlukan validasi data yang ada atau pengisian ulang data apa pun. Misalnya, jika Anda menambahkan anotasi NOT NULL ke kolom yang ada, Spanner harus membaca semua nilai dalam kolom untuk memastikan bahwa kolom tidak berisi nilai NULL. Langkah ini dapat memerlukan waktu lama jika ada banyak data yang akan divalidasi. Contoh lainnya adalah jika Anda menambahkan indeks ke database: Spanner mengisi ulang indeks menggunakan data yang ada, dan proses tersebut dapat memakan waktu lama, bergantung pada definisi indeks dan ukuran tabel dasar yang sesuai. Namun, jika Anda menambahkan kolom baru ke tabel, tidak ada data yang ada untuk divalidasi, sehingga Spanner dapat melakukan pembaruan dengan lebih cepat.

Singkatnya, update skema yang tidak mengharuskan Spanner memvalidasi data yang ada dapat terjadi dalam beberapa menit. Pembaruan skema yang memerlukan validasi dapat memerlukan waktu lebih lama, bergantung pada jumlah data yang ada yang perlu divalidasi, tetapi validasi data terjadi di latar belakang dengan prioritas yang lebih rendah daripada traffic produksi. Update skema yang memerlukan validasi data akan dibahas lebih mendetail di bagian berikutnya.

Pembaruan skema divalidasi terhadap definisi tampilan

Saat Anda melakukan pembaruan skema, Spanner akan memvalidasi bahwa pembaruan tersebut tidak akan membatalkan kueri yang digunakan untuk menentukan tampilan yang ada. Jika validasi berhasil, pembaruan skema akan berhasil. Jika validasi tidak berhasil, update skema akan gagal. Lihat Praktik terbaik saat membuat tampilan untuk mengetahui detailnya.

Pembaruan skema yang memerlukan validasi data

Anda dapat melakukan pembaruan skema yang memerlukan validasi bahwa data yang ada memenuhi batasan baru. Jika pembaruan skema memerlukan validasi data, Spanner tidak mengizinkan pembaruan skema yang bertentangan pada entitas skema yang terpengaruh dan memvalidasi data di latar belakang. Jika validasi berhasil, pembaruan skema akan berhasil. Jika validasi tidak berhasil, update skema tidak akan berhasil. Operasi validasi dijalankan sebagai operasi yang berjalan lama. Anda dapat memeriksa status operasi ini untuk menentukan apakah operasi berhasil atau gagal.

Misalnya, Anda telah menentukan file music.proto berikut dengan enum RecordLabel dan pesan protokol Songwriter:

  enum RecordLabel {
    COOL_MUSIC_INC = 0;
    PACIFIC_ENTERTAINMENT = 1;
    XYZ_RECORDS = 2;
  }

  message Songwriter {
    required string nationality   = 1;
    optional int64  year_of_birth = 2;
  }

Untuk menambahkan tabel Songwriters dalam skema Anda:

GoogleSQL 

CREATE PROTO BUNDLE (
  googlesql.example.music.Songwriter,
  googlesql.example.music.RecordLabel,
);

CREATE TABLE Songwriters (
  Id         INT64 NOT NULL,
  FirstName  STRING(1024),
  LastName   STRING(1024),
  Nickname   STRING(MAX),
  OpaqueData BYTES(MAX),
  SongWriter googlesql.example.music.Songwriter
) PRIMARY KEY (Id);

CREATE TABLE Albums (
  SongwriterId     INT64 NOT NULL,
  AlbumId          INT64 NOT NULL,
  AlbumTitle       STRING(MAX),
  Label            INT32
) PRIMARY KEY (SongwriterId, AlbumId);

Pembaruan skema berikut diizinkan, tetapi memerlukan validasi dan mungkin membutuhkan waktu lebih lama untuk diselesaikan, bergantung pada jumlah data yang ada:

  • Menambahkan anotasi NOT NULL ke kolom non-kunci. Contoh:

    ALTER TABLE Songwriters ALTER COLUMN Nickname STRING(MAX) NOT NULL;

  • Mengurangi panjang kolom. Contoh:

    ALTER TABLE Songwriters ALTER COLUMN FirstName STRING(10);

  • Mengubah dari BYTES menjadi STRING. Contoh:

    ALTER TABLE Songwriters ALTER COLUMN OpaqueData STRING(MAX);

  • Mengubah dari INT64/INT32 menjadi ENUM. Contoh:

    ALTER TABLE Albums ALTER COLUMN Label googlesql.example.music.RecordLabel;

  • Menghapus nilai yang ada dari definisi enum RecordLabel.

  • Mengaktifkan stempel waktu commit di kolom TIMESTAMP yang ada. Contoh:

    ALTER TABLE Albums ALTER COLUMN LastUpdateTime SET OPTIONS (allow_commit_timestamp = true);

  • Menambahkan batasan pemeriksaan ke tabel yang ada.

  • Menambahkan kolom yang disimpan dan dibuat ke tabel yang ada.

  • Membuat tabel baru dengan kunci asing.

  • Menambahkan kunci asing ke tabel yang ada.

Update skema ini akan gagal jika data pokok tidak memenuhi batasan baru. Misalnya, pernyataan ALTER TABLE Songwriters ALTER COLUMN Nickname STRING(MAX) NOT NULL gagal jika ada nilai di kolom Nickname yang NULL, karena data yang ada tidak memenuhi batasan NOT NULL dari definisi baru.

Validasi data dapat memerlukan waktu beberapa menit hingga beberapa jam. Waktu yang diperlukan untuk menyelesaikan validasi data bergantung pada:

  • Ukuran set data
  • Kapasitas komputasi instance
  • Beban pada instance

Beberapa pembaruan skema dapat mengubah perilaku permintaan ke database sebelum pembaruan skema selesai. Misalnya, jika Anda menambahkan NOT NULL ke kolom, Spanner akan hampir segera menolak penulisan untuk permintaan baru yang menggunakan NULL untuk kolom tersebut. Jika update skema baru pada akhirnya gagal karena validasi data, akan ada jangka waktu saat penulisan diblokir, meskipun akan diterima oleh skema lama.

Anda dapat membatalkan operasi validasi data yang berjalan lama menggunakan metode projects.instances.databases.operations.cancel atau menggunakan gcloud spanner operations.

Versi skema yang dibuat selama pembaruan skema

Spanner menggunakan pembuatan versi skema sehingga tidak ada waktu non-operasional selama pembaruan skema ke database besar. Spanner mempertahankan versi skema yang lebih lama untuk mendukung pembacaan saat pembaruan skema diproses. Kemudian, Spanner membuat satu atau beberapa versi baru skema untuk memproses pembaruan skema. Setiap versi berisi hasil pengumpulan pernyataan dalam satu perubahan atomik.

Versi skema tidak selalu berkorespondensi satu-ke-satu dengan batch pernyataan DDL atau pernyataan DDL individual. Beberapa pernyataan DDL individual, seperti pembuatan indeks untuk tabel dasar yang ada atau pernyataan yang memerlukan validasi data, menghasilkan beberapa versi skema. Dalam kasus lain, beberapa pernyataan DDL dapat dikelompokkan bersama dalam satu versi. Versi skema lama dapat menggunakan resource server dan penyimpanan yang signifikan, dan dipertahankan hingga berakhir (tidak lagi diperlukan untuk melayani pembacaan data versi sebelumnya).

Tabel berikut menunjukkan waktu yang dibutuhkan Spanner untuk memperbarui skema.

Operasi skema Estimasi durasi
CREATE TABLE Menit
CREATE INDEX

Beberapa menit hingga beberapa jam, jika tabel dasar dibuat sebelum indeks.

Menit, jika pernyataan dieksekusi pada saat yang sama dengan pernyataan CREATE TABLE untuk tabel dasar.
DROP TABLE Menit
DROP INDEX Menit
ALTER TABLE ... ADD COLUMN Menit
ALTER TABLE ... ALTER COLUMN

Beberapa menit hingga beberapa jam, jika validasi latar belakang diperlukan.

Menit, jika validasi latar belakang tidak diperlukan.
ALTER TABLE ... DROP COLUMN Menit
ANALYZE

Beberapa menit hingga beberapa jam, bergantung pada ukuran database.

Perubahan jenis data dan aliran perubahan

Jika Anda mengubah jenis data kolom yang dipantau oleh aliran perubahan, kolom column_types dari rekaman aliran perubahan berikutnya yang relevan akan mencerminkan jenis barunya, begitu juga dengan data JSON old_values dalam kolom mods rekaman.

new_values kolom mods dalam rekaman aliran perubahan selalu cocok dengan jenis kolom saat ini. Mengubah jenis data kolom yang dipantau tidak memengaruhi catatan aliran perubahan yang mendahului perubahan tersebut.

Dalam kasus khusus perubahan BYTES ke STRING, Spanner memvalidasi nilai lama kolom sebagai bagian dari pembaruan skema. Akibatnya, Spanner telah mendekode nilai jenis BYTES lama menjadi string dengan aman pada saat menulis rekaman aliran perubahan berikutnya.