Indeks penelusuran

Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.

Halaman ini menjelaskan cara menambahkan dan menggunakan indeks penelusuran. Penelusuran teks lengkap dijalankan terhadap entri di indeks penelusuran.

Cara menggunakan indeks penelusuran

Anda dapat membuat indeks penelusuran pada kolom apa pun yang ingin Anda jadikan tersedia untuk penelusuran teks lengkap. Untuk membuat indeks penelusuran, gunakan pernyataan DDL CREATE SEARCH INDEX. Untuk memperbarui indeks, gunakan pernyataan DDL ALTER SEARCH INDEX. Spanner otomatis membuat dan mengelola indeks penelusuran, termasuk menambahkan dan memperbarui data di indeks penelusuran segera setelah berubah di database.

Partisi indeks penelusuran

Indeks penelusuran dapat dipartisi atau tidak dipartisi, bergantung pada jenis kueri yang ingin Anda percepat.

• Contoh saat indeks yang dipartisi adalah pilihan terbaik adalah saat aplikasi membuat kueri kotak surat email. Setiap kueri dibatasi untuk kotak surat tertentu.

• Contoh saat kueri yang tidak dipartisi adalah pilihan terbaik adalah saat ada kueri di semua kategori produk dalam katalog produk.

Kasus penggunaan indeks penelusuran

Selain penelusuran teks lengkap, indeks penelusuran Spanner mendukung hal berikut:

• Penelusuran JSON, yang merupakan cara yang efisien untuk mengindeks dan membuat kueri dokumen JSON dan JSONB.
• Penelusuran substring, yang merupakan jenis kueri yang mencari string yang lebih pendek (substring) dalam isi teks yang lebih besar.
• Menggabungkan kondisi pada subset data yang diindeks, termasuk pencocokan persis dan numerik, ke dalam satu pemindaian indeks.

Untuk mengetahui informasi selengkapnya tentang kasus penggunaan, lihat Indeks penelusuran versus indeks sekunder.

Contoh indeks penelusuran

Untuk menampilkan kemampuan indeks penelusuran, misalkan ada tabel yang menyimpan informasi tentang album musik:

CREATE TABLE Albums (
  AlbumId STRING(MAX) NOT NULL,
  AlbumTitle STRING(MAX)
) PRIMARY KEY(AlbumId);

CREATE TABLE albums (
  albumid character varying NOT NULL,
  albumtitle character varying,
PRIMARY KEY(albumid));

Spanner memiliki beberapa fungsi tokenize yang membuat token. Untuk mengubah tabel sebelumnya agar pengguna dapat menjalankan penelusuran teks lengkap untuk menemukan judul album, gunakan fungsi TOKENIZE_FULLTEXT untuk membuat token dari judul album. Kemudian, buat kolom yang menggunakan jenis data TOKENLIST untuk menyimpan output tokenisasi dari TOKENIZE_FULLTEXT. Untuk contoh ini, kita membuat kolom AlbumTitle_Tokens.

ALTER TABLE Albums
  ADD COLUMN AlbumTitle_Tokens TOKENLIST
  AS (TOKENIZE_FULLTEXT(AlbumTitle)) HIDDEN;

ALTER TABLE albums
  ADD COLUMN albumtitle_tokens spanner.tokenlist
    GENERATED ALWAYS AS (spanner.tokenize_fulltext(albumtitle)) VIRTUAL HIDDEN;

Contoh berikut menggunakan DDL CREATE SEARCH INDEX untuk membuat indeks penelusuran (AlbumsIndex) pada token AlbumTitle (AlbumTitle_Tokens):

CREATE SEARCH INDEX AlbumsIndex
  ON Albums(AlbumTitle_Tokens);

CREATE SEARCH INDEX albumsindex ON albums(albumtitle_tokens);

Setelah menambahkan indeks penelusuran, gunakan kueri SQL untuk menemukan album yang cocok dengan kriteria penelusuran. Contoh:

SELECT AlbumId
FROM Albums
WHERE SEARCH(AlbumTitle_Tokens, "fifth symphony")

SELECT albumid
FROM albums
WHERE spanner.search(albumtitle_tokens, 'fifth symphony')

Konsistensi data

Saat indeks dibuat, Spanner menggunakan proses otomatis untuk mengisi ulang data guna memastikan konsistensi. Saat operasi tulis di-commit, indeks akan diperbarui dalam transaksi yang sama. Spanner secara otomatis melakukan pemeriksaan konsistensi data.

Definisi skema indeks penelusuran

Indeks penelusuran ditentukan pada satu atau beberapa kolom TOKENLIST tabel. Indeks penelusuran memiliki komponen berikut:

• Tabel dasar: tabel Spanner yang memerlukan pengindeksan.
• Kolom TOKENLIST: kumpulan kolom yang menentukan token yang memerlukan pengindeksan. Urutan kolom ini tidak penting.

Misalnya, dalam pernyataan berikut, tabel dasarnya adalah Albums. Kolom TOKENLIST dibuat di AlbumTitle (AlbumTitle_Tokens) dan Rating (Rating_Tokens).

CREATE TABLE Albums (
  AlbumId STRING(MAX) NOT NULL,
  SingerId INT64 NOT NULL,
  ReleaseTimestamp INT64 NOT NULL,
  AlbumTitle STRING(MAX),
  Rating FLOAT64,
  AlbumTitle_Tokens TOKENLIST AS (TOKENIZE_FULLTEXT(AlbumTitle)) HIDDEN,
  Rating_Tokens TOKENLIST AS (TOKENIZE_NUMBER(Rating)) HIDDEN
) PRIMARY KEY(AlbumId);

CREATE TABLE albums (
  albumid character varying NOT NULL,
  singerid bigint NOT NULL,
  releasetimestamp bigint NOT NULL,
  albumtitle character varying,
  rating double precision,
  albumtitle_tokens spanner.tokenlist GENERATED ALWAYS AS (spanner.tokenize_fulltext(albumtitle)) VIRTUAL HIDDEN,
  rating_tokens spanner.tokenlist GENERATED ALWAYS AS (spanner.tokenize_fulltext(rating)) VIRTUAL HIDDEN,
PRIMARY KEY(AlbumId));

Gunakan pernyataan CREATE SEARCH INDEX berikut untuk membuat indeks penelusuran menggunakan token untuk AlbumTitle dan Rating:

CREATE SEARCH INDEX AlbumsIndex
ON Albums(AlbumTitle_Tokens, Rating_Tokens)
PARTITION BY SingerId
ORDER BY ReleaseTimestamp DESC

CREATE SEARCH INDEX albumsindex
ON albums(albumtitle_tokens, rating_tokens)
PARTITION BY singerid
ORDER BY releasetimestamp DESC

Indeks penelusuran memiliki opsi berikut:

• Partisi: grup kolom opsional yang membagi indeks penelusuran. Membuat kueri indeks yang dipartisi sering kali jauh lebih efisien daripada membuat kueri indeks yang tidak dipartisi. Untuk mengetahui informasi selengkapnya, lihat Mempartisi indeks penelusuran.
• Kolom urutan pengurutan: kolom INT64 opsional yang menetapkan urutan pengambilan dari indeks penelusuran. Untuk informasi selengkapnya, lihat Urutan pengurutan indeks penelusuran.
• Interleaving: seperti indeks sekunder, Anda dapat melakukan interleaving pada indeks penelusuran. Indeks penelusuran yang diselingi menggunakan lebih sedikit resource untuk menulis dan bergabung dengan tabel dasar. Untuk mengetahui informasi selengkapnya, lihat Indeks penelusuran interleaved.
• Opsi klausa: daftar pasangan nilai kunci yang mengganti setelan default indeks penelusuran.

Tata letak internal indeks penelusuran

Elemen penting dari representasi internal indeks penelusuran adalah docid, yang berfungsi sebagai representasi penyimpanan yang efisien dari kunci utama tabel dasar yang dapat panjangnya tidak ditentukan. Ini juga yang membuat urutan untuk tata letak data internal sesuai dengan kolom ORDER BY yang disediakan pengguna dari pernyataan CREATE SEARCH INDEX. Nilai ini direpresentasikan sebagai satu atau dua bilangan bulat 64-bit.

Indeks penelusuran diterapkan secara internal sebagai pemetaan dua tingkat:

1. Token ke docid
2. Docid ke kunci utama tabel dasar

Skema ini menghasilkan penghematan penyimpanan yang signifikan karena Spanner tidak perlu menyimpan kunci utama tabel dasar lengkap untuk setiap pasangan <token, document>.

Ada dua jenis indeks fisik yang menerapkan dua tingkat pemetaan:

1. Indeks sekunder yang memetakan kunci partisi dan docid ke kunci utama tabel dasar. Dalam contoh di bagian sebelumnya, tindakan ini memetakan {SingerId, ReleaseTimestamp, uid} ke {AlbumId}. Indeks sekunder juga menyimpan semua kolom yang ditentukan dalam klausa STORING dari CREATE SEARCH INDEX.
2. Indeks token yang memetakan token ke docid, mirip dengan indeks terbalik dalam literatur pengambilan informasi. Spanner mempertahankan indeks token terpisah untuk setiap TOKENLIST indeks penelusuran. Secara logis, indeks token mempertahankan daftar docid untuk setiap token dalam setiap partisi (dikenal dalam pengambilan informasi sebagai daftar postingan). Daftar diurutkan oleh token untuk pengambilan yang cepat, dan dalam daftar, docid digunakan untuk pengurutan. Setiap indeks token adalah detail implementasi yang tidak ditampilkan melalui Spanner API.

Spanner mendukung empat opsi berikut untuk docid.

Catatan penggunaan:

• Kolom UID internal tidak ditampilkan melalui Spanner API.
• Dalam indeks tempat UID tidak ditambahkan, transaksi yang menambahkan baris dengan yang sudah ada (partisi,urutan pengurutan) akan gagal.

Misalnya, pertimbangkan data berikut:

Dengan asumsi kolom prapengurutan dalam urutan menaik, konten indeks token yang dipartisi oleh SingerId akan mempartisi konten indeks token dengan cara berikut:

Sharding indeks penelusuran

Saat membagi tabel, Spanner akan mendistribusikan data indeks penelusuran sehingga semua token dalam baris tabel dasar tertentu berada dalam bagian yang sama. Dengan kata lain, indeks penelusuran di-shard dokumen. Strategi sharding ini memiliki implikasi performa yang signifikan:

1. Jumlah server yang dikomunikasikan oleh setiap transaksi tetap konstan, terlepas dari jumlah token atau jumlah kolom TOKENLIST yang diindeks.
2. Kueri penelusuran yang melibatkan beberapa ekspresi kondisional dijalankan secara independen pada setiap bagian, sehingga menghindari overhead performa yang terkait dengan join terdistribusi.

Indeks penelusuran memiliki dua mode distribusi:

• Sharding seragam (default). Dalam sharding seragam, data yang diindeks untuk setiap baris tabel dasar ditetapkan secara acak ke bagian indeks partisi.
• Sharding urutan pengurutan. Dalam sharding urutan pengurutan, data untuk setiap baris tabel dasar ditetapkan ke pemisahan indeks partisi berdasarkan kolom ORDER BY (yaitu, kolom prapengurutan). Misalnya, dalam kasus urutan pengurutan menurun, semua baris dengan nilai urutan pengurutan terbesar akan muncul pada bagian indeks pertama dari partisi, dan grup nilai urutan pengurutan terbesar berikutnya pada bagian berikutnya.

Mode sharding ini memiliki kompromi antara risiko hotspot dan biaya kueri:

• Indeks penelusuran dengan shard seragam direkomendasikan jika pola baca atau tulis ke indeks penelusuran dapat menyebabkan hotspot. Sharding seragam mengurangi hotspot dengan mendistribusikan beban baca dan tulis secara merata di seluruh bagian, tetapi hal ini dapat meningkatkan penggunaan resource selama eksekusi kueri sebagai kompromi. Dalam indeks penelusuran shard yang seragam, kueri harus membaca semua bagian dalam partisi, karena data yang didistribusikan secara acak. Saat mengakses indeks yang di-shard secara seragam, Spanner membaca semua pemisahan secara paralel untuk mengurangi latensi kueri secara keseluruhan.

• Indeks penelusuran yang di-shard urutan pengurutan lebih disukai jika pola baca atau tulis tidak mungkin menyebabkan hotspot. Pendekatan ini dapat mengurangi biaya kueri yang ORDER BY-nya cocok dengan ORDER BY indeks, dan menentukan LIMIT yang relatif rendah. Saat mengeksekusi kueri tersebut, Spanner membaca mulai dari bagian pertama partisi secara bertahap, dan kueri dapat diselesaikan tanpa membaca semua bagian saat LIMIT dapat dipenuhi lebih awal.

CREATE SEARCH INDEX AlbumsIndex
ON Albums(AlbumTitle_Tokens, Rating_Tokens)
PARTITION BY SingerId
ORDER BY ReleaseTimestamp DESC
OPTIONS (sort_order_sharding = true);

CREATE SEARCH INDEX albumsindex
ON albums(albumtitle_tokens, rating_tokens)
PARTITION BY singerid
ORDER BY releasetimestamp DESC
WITH (sort_order_sharding = true);

Jika sort_order_sharding=false ditetapkan atau tidak ditentukan, indeks penelusuran akan dibuat menggunakan sharding seragam.

Indeks penelusuran yang diselang-seling

Seperti indeks sekunder, Anda dapat menyelang-seling indeks penelusuran di tabel induk tabel dasar. Alasan utama menggunakan indeks penelusuran interleaved adalah untuk menempatkan data tabel dasar dengan data indeks untuk partisi kecil. Kolokasi oportunistik ini memiliki keunggulan berikut:

• Operasi tulis tidak perlu melakukan commit dua fase.
• Join balik indeks penelusuran dengan tabel dasar tidak didistribusikan.

Indeks penelusuran yang diselingi memiliki batasan berikut:

1. Hanya indeks susunan urutan yang di-shard yang dapat diselang-seling.
2. Indeks penelusuran hanya dapat diselang-seling di tabel tingkat atas (bukan di tabel turunan).
3. Seperti tabel yang diselingi dan indeks sekunder, buat kunci tabel induk menjadi awalan kolom PARTITION BY dalam indeks penelusuran yang diselingi.

Menentukan indeks penelusuran yang diselang-seling

Contoh berikut menunjukkan cara menentukan indeks penelusuran yang diselingi:

CREATE TABLE Singers (
  SingerId INT64 NOT NULL
) PRIMARY KEY(SingerId);

CREATE TABLE Albums (
  SingerId INT64 NOT NULL,
  AlbumId STRING(MAX) NOT NULL,
  AlbumTitle STRING(MAX),
  AlbumTitle_Tokens TOKENLIST AS (TOKENIZE_FULLTEXT(AlbumTitle)) HIDDEN
) PRIMARY KEY(SingerId, AlbumId),
INTERLEAVE IN PARENT Singers ON DELETE CASCADE;

CREATE SEARCH INDEX AlbumsIndex
ON Albums(AlbumTitle_Tokens)
PARTITION BY SingerId,
INTERLEAVE IN Singers
OPTIONS (sort_order_sharding = true);

CREATE TABLE singers(
  singerid bigint NOT NULL
PRIMARY KEY(singerid));

CREATE TABLE albums(
  singerid bigint NOT NULL,
  albumid character varying NOT NULL,
  albumtitle character varying,
  albumtitle_tokens spanner.tokenlist
  GENERATED ALWAYS
AS (
  spanner.tokenize_fulltext(albumtitle)
) VIRTUAL HIDDEN,
  PRIMARY KEY(singerid, albumid)),
INTERLEAVE IN PARENT singers ON DELETE CASCADE;

CREATE
  SEARCH INDEX albumsindex
ON
  albums(albumtitle_tokens)
  PARTITION BY singerid INTERLEAVE IN singers WITH(sort_order_sharding = true);

Urutan pengurutan indeks penelusuran

Persyaratan untuk definisi urutan pengurutan indeks penelusuran berbeda dengan indeks sekunder.

Misalnya, pertimbangkan tabel berikut:

CREATE TABLE Albums (
  AlbumId STRING(MAX) NOT NULL,
  ReleaseTimestamp INT64 NOT NULL,
  AlbumName STRING(MAX),
  AlbumName_Token TOKENLIST AS (TOKEN(AlbumName)) HIDDEN
) PRIMARY KEY(AlbumId);

CREATE TABLE albums (
  albumid character varying NOT NULL,
  releasetimestamp bigint NOT NULL,
  albumname character varying,
  albumname_token spanner.tokenlist
      GENERATED ALWAYS AS(spanner.token(albumname)) VIRTUAL HIDDEN,
PRIMARY KEY(albumid));

Aplikasi dapat menentukan indeks sekunder untuk mencari informasi menggunakan AlbumName yang diurutkan menurut ReleaseTimestamp:

CREATE INDEX AlbumsSecondaryIndex ON Albums(AlbumName, ReleaseTimestamp DESC);

Indeks penelusuran yang setara terlihat seperti berikut (ini menggunakan tokenisasi pencocokan persis, karena indeks sekunder tidak mendukung penelusuran teks lengkap):

CREATE SEARCH INDEX AlbumsSearchIndex
ON Albums(AlbumName_Token)
ORDER BY ReleaseTimestamp DESC;

Urutan pengurutan indeks penelusuran harus sesuai dengan persyaratan berikut:

1. Hanya gunakan kolom INT64 untuk urutan pengurutan indeks penelusuran. Kolom yang memiliki ukuran arbitrer menggunakan terlalu banyak resource dalam indeks penelusuran karena Spanner perlu menyimpan docid di samping setiap token. Secara khusus, kolom urutan pengurutan tidak dapat menggunakan jenis TIMESTAMP karena TIMESTAMP menggunakan presisi nanosekon yang tidak sesuai dengan bilangan bulat 64-bit.

2. Kolom urutan pengurutan tidak boleh berupa NULL. Ada dua cara untuk memenuhi persyaratan ini:

   1. Deklarasikan kolom urutan pengurutan sebagai NOT NULL.
   2. Konfigurasikan indeks untuk mengecualikan nilai NULL.

Stempel waktu sering digunakan untuk menentukan urutan pengurutan. Praktik yang umum adalah menggunakan mikrodetik sejak epoch Unix untuk stempel waktu tersebut.

Aplikasi biasanya mengambil data terbaru terlebih dahulu menggunakan indeks penelusuran yang diurutkan dalam urutan menurun.

Indeks penelusuran yang difilter dengan NULL

Indeks penelusuran dapat menggunakan sintaksis WHERE column_name IS NOT NULL untuk mengecualikan baris tabel dasar. Pemfilteran NULL dapat diterapkan ke kunci partisi, kolom urutan pengurutan, dan kolom yang disimpan. Pemfilteran NULL pada kolom array yang disimpan tidak diizinkan.

Contoh

CREATE SEARCH INDEX AlbumsIndex
ON Albums(AlbumTitle_Tokens)
STORING (Genre)
WHERE Genre IS NOT NULL

CREATE SEARCH INDEX albumsindex
ON albums(albumtitle_tokens)
INCLUDE (genre)
WHERE genre IS NOT NULL

Kueri harus menentukan kondisi pemfilteran NULL (Genre IS NOT NULL untuk contoh ini) dalam klausa WHERE. Jika tidak, Pengoptimal Kueri tidak dapat menggunakan indeks penelusuran. Untuk informasi selengkapnya, lihat persyaratan kueri SQL.

Gunakan pemfilteran NULL pada kolom yang dihasilkan untuk mengecualikan baris berdasarkan kriteria arbitrer. Untuk mengetahui informasi selengkapnya, lihat Membuat indeks parsial menggunakan kolom yang dihasilkan.

Langkah berikutnya

• Pelajari tokenisasi dan tokenizer Spanner.
• Pelajari indeks numerik.
• Pelajari indeks JSON.
• Pelajari partisi indeks.