All Products
Search

This Product

    Lindorm:Indeks sekunder

    Document Center

    Lindorm:Indeks sekunder

    Last Updated:Sep 17, 2026

    LindormTable mendukung indeks sekunder dalam model Tabular. Indeks sekunder memungkinkan Anda melakukan kueri data pada kolom non-primary-key tanpa mengubah logika penulisan aplikasi—Lindorm secara otomatis menangani pemeliharaan indeks dan menjamin konsistensi antara tabel utama dan semua tabel indeks.

    Prasyarat

    Sebelum memulai, pastikan Anda telah memiliki:

    Konsep utama

    Hubungan antara indeks dan tabel utama

    Setiap indeks sekunder dipetakan ke tabel data fisik independen yang terpisah dari tabel utama. Anda dapat membuat beberapa indeks untuk satu tabel utama, termasuk indeks gabungan yang dibangun berdasarkan satu atau lebih kolom. Saat Anda menulis ke tabel utama, Lindorm secara otomatis memperbarui semua tabel indeks terkait. Saat melakukan kueri, tentukan kondisi dalam klausa WHERE terhadap tabel utama—Lindorm secara otomatis memilih indeks terbaik, termasuk kembali menggunakan tabel utama jika tidak ada indeks yang sesuai.

    Perubahan Skema Online

    Modifikasi indeks—menambahkan, menonaktifkan, atau menghapus indeks—tidak memengaruhi operasi baca atau tulis normal pada tabel utama. Anda dapat menambah, menghapus, atau memperbarui indeks kapan saja tanpa downtime.

    Konsistensi kuat

    Konsistensi data antara tabel utama dan tabel indeks memiliki batasan berikut:

    • Isolasi snapshot tidak didukung. Data yang ditulis ke tabel utama mungkin tidak langsung terlihat di tabel indeks. Setelah server mengembalikan respons sukses, data menjadi terlihat di keduanya.

    • Perilaku timeout klien atau error I/O. Jika penulisan gagal karena timeout klien atau error I/O, data mungkin tidak muncul baik di tabel utama maupun tabel indeks. Konsistensi akhir (eventual consistency) antara keduanya tetap dijamin.

    Mutabilitas

    Setiap penulisan ke tabel yang diindeks lebih mahal daripada penulisan ke tabel biasa karena indeks harus dipelihara. Biaya aktual bergantung pada apakah workload Anda memperbarui atau menghapus baris yang sudah ada.

    Properti MUTABILITY memberi tahu Lindorm jenis operasi yang dilakukan oleh workload Anda sehingga dapat meminimalkan overhead pemeliharaan indeks. Atur properti ini menggunakan Table_Options saat membuat atau memodifikasi tabel. Lihat Sintaks CREATE TABLE.

    Pilih pengaturan mutabilitas berdasarkan pola penulisan Anda:

    • Hanya tambah (append-only), tanpa pembaruan atau penghapusan: gunakan IMMUTABLE

    • Tambah dan hapus per baris, tanpa pembaruan: gunakan IMMUTABLE_ROWS

    • Pembaruan dan penghapusan, tanpa timestamp kustom: gunakan MUTABLE_LATEST (direkomendasikan)

    • Pembaruan dan penghapusan dengan timestamp kustom: gunakan MUTABLE_UDT

    Pola workload

    Pengaturan

    Biaya operasi

    Catatan

    Tidak ada indeks

    —

    1

    Menulis langsung ke tabel utama

    Hanya insert, tidak pernah update atau delete

    IMMUTABLE

    2

    Biaya terendah. Tidak direkomendasikan: tidak ada perlindungan yang mencegah pembaruan—jika terjadi pembaruan, indeks diam-diam menjadi tidak konsisten dengan tabel utama

    Insert dan delete berdasarkan baris, tidak pernah update

    IMMUTABLE_ROWS

    2–3

    Biaya terendah kedua. Tidak direkomendasikan: peringatan yang sama—pembaruan menyebabkan ketidakkonsistenan diam-diam

    Update dan delete, tanpa timestamp kustom

    MUTABLE_LATEST (direkomendasikan)

    4

    Default untuk LindormTable 2.7.9 dan versi lebih baru. Keseimbangan terbaik antara keamanan dan kinerja

    Update dan delete, timestamp kustom diperlukan

    MUTABLE_UDT

    4

    Versi teroptimalkan dari MUTABLE_ALL. Memerlukan LindormTable 2.6.7 atau versi lebih baru

    Update dan delete, timestamp kustom, tanpa batasan versi

    MUTABLE_ALL

    4

    Tanpa batasan; gunakan MUTABLE_UDT sebagai gantinya untuk kinerja lebih baik

    MUTABLE_LATEST adalah pengaturan yang direkomendasikan. Untuk LindormTable 2.7.9 dan versi lebih baru, ini merupakan nilai default. Jika instans Anda menjalankan versi sebelumnya, atur MUTABILITY='MUTABLE_LATEST' secara eksplisit.

    Untuk menulis data dengan timestamp kustom, gunakan MUTABLE_UDT (memerlukan LindormTable 2.6.7 atau versi lebih baru). Rencanakan hal ini sebelum membuat indeks—properti mutabilitas berlaku saat pembuatan indeks.

    Penting

    Jika Anda menulis data dengan timestamp kustom tetapi belum mengatur mutabilitas ke MUTABLE_UDT atau MUTABLE_ALL sebelum membuat indeks, kueri terhadap indeks akan langsung gagal setelah pembuatan indeks. Untuk langkah pemulihan, lihat FAQ.

    IMMUTABLE dan IMMUTABLE_ROWS tidak memiliki penegakan di sisi server. Jika workload Anda memperbarui data tetapi tabel diatur ke IMMUTABLE atau IMMUTABLE_ROWS, server tidak mengembalikan error—tetapi data indeks menjadi tidak konsisten dengan tabel utama. Gunakan pengaturan ini hanya jika Anda yakin tidak akan terjadi pembaruan. Karena tabel IMMUTABLE tidak melibatkan penghapusan, mereka sepenuhnya mendukung penerapan aktif-aktif multi-Internet Data Center (IDC).

    Indeks cakupan

    Tanpa indeks cakupan, kueri yang cocok dengan entri indeks tetap perlu mengambil seluruh baris dari tabel utama. Kunci baris (rowkeys) yang dikembalikan oleh indeks mungkin tersebar di seluruh tabel utama, memerlukan beberapa panggilan prosedur jarak jauh (RPC) dan meningkatkan waktu respons (RT) seiring pertambahan ukuran set hasil.

    Indeks cakupan menyertakan kolom tabel utama secara langsung dalam tabel indeks, sehingga menghilangkan pencarian ke tabel utama untuk kolom-kolom tersebut. Lindorm mendukung tiga mode cakupan:

    • Specific columns: Daftarkan kolom yang akan direplikasi dari tabel utama.

    • Semua kolom skema (COVERED_ALL_COLUMNS_IN_SCHEMA): Menyertakan semua kolom yang saat ini didefinisikan dalam skema tabel utama. Saat kolom baru ditambahkan ke tabel utama, indeks secara otomatis menyertakannya—tidak perlu pengindeksan ulang.

    • Kolom dinamis (DYNAMIC): Menyertakan semua kolom dinamis dari tabel utama, ditambah semua kolom yang didefinisikan dalam skema.

    Timestamp kustom (User-Defined Timestamp, UDT)

    Lindorm mendukung timestamp kustom tingkat kolom. Menulis data dengan timestamp kustom umum digunakan dalam sistem berbasis HBase untuk mengontrol Time to Live (TTL) dan menangani penulisan out-of-order atau idempoten. Indeks sekunder di Lindorm juga mendukung pembaruan data indeks saat menggunakan timestamp kustom—kemampuan yang jarang ditemukan dalam sistem NoSQL.

    Dua kasus penggunaan penting:

    • Impor konkuren dan pembaruan real-time: Gunakan waktu saat ini untuk penulisan real-time dan timestamp sebelumnya (misalnya, 23:59:59 hari sebelumnya) untuk impor historis. Penulisan real-time memiliki prioritas lebih tinggi; impor historis hanya mengisi data yang belum diperbarui.

    • Penangkapan pesan (message catch-up): Saat sistem melewatkan pesan yang terakumulasi dan memproses pesan terbaru terlebih dahulu, setiap pesan membawa timestamp-nya sendiri. Menangkap pesan lama kemudian menerapkan urutan overwrite yang benar, terlepas dari urutan pemrosesan.

    Buat indeks sekunder

    Setelah membuat tabel utama Lindorm, buat indeks sekunder pada kolom-kolomnya menggunakan pernyataan CREATE INDEX.

    Contoh berikut menggunakan tabel orders. Indeks pada kolom user_id memungkinkan Anda melakukan kueri pesanan berdasarkan pengguna tanpa memindai seluruh tabel.

    -- Buat tabel utama
CREATE TABLE orders (
  order_id VARCHAR NOT NULL,
  user_id  VARCHAR,
  status   VARCHAR,
  amount   DOUBLE,
  created  BIGINT,
  PRIMARY KEY(order_id)
) WITH (CONSISTENCY = 'strong', MUTABILITY = 'MUTABLE_LATEST');

-- Buat indeks cakupan pada user_id, mencakup semua kolom skema
-- Kueri yang difilter berdasarkan user_id akan menggunakan indeks ini dan menghindari pencarian ke tabel utama
CREATE INDEX idx_user ON orders(user_id) WITH (INDEX_COVERED_TYPE = 'COVERED_ALL_COLUMNS_IN_SCHEMA');

-- Kueri ini secara otomatis menggunakan idx_user
SELECT * FROM orders WHERE user_id = 'u123';
    Pilih pembuatan indeks sinkron atau asinkron berdasarkan ukuran tabel utama Anda. Gunakan pembuatan sinkron untuk tabel kecil dan asinkron untuk tabel besar. Lihat CREATE INDEX untuk detail sintaks.
    Saat menambahkan indeks ke tabel yang sudah berisi data, CREATE INDEX menyinkronkan data historis dari tabel utama ke tabel indeks. Proses ini bisa memakan waktu lama untuk tabel besar. Sinkronisasi berjalan di sisi server—menghentikan proses Lindorm Shell tidak mengganggunya.
    Jika pemisahan data panas dan dingin diaktifkan, pantau Pembatasan kecepatan baca penyimpanan kapasitas selama pembuatan indeks. Pembatasan kecepatan baca penyimpanan dingin mengurangi kecepatan pembuatan indeks dan dapat menyebabkan tekanan balik pada operasi tulis.

    Lihat indeks sekunder

    Gunakan SHOW INDEX untuk melihat indeks pada tabel, termasuk nama dan statusnya saat ini.

    SHOW INDEX FROM orders;

    Ubah status indeks

    Gunakan ALTER INDEX untuk mengaktifkan atau menonaktifkan indeks sekunder.

    -- Aktifkan indeks
ALTER INDEX IF EXISTS idx_user ON orders ACTIVE;

-- Nonaktifkan indeks
ALTER INDEX idx_user ON orders DISABLED;
    Penting

    Jangan ubah langsung indeks DISABLED menjadi ACTIVE—hal ini menyebabkan kehilangan data. Jalankan operasi BUILD INDEX terlebih dahulu untuk membangun ulang data indeks, lalu aktifkan.

    Jika tabel utama berisi data historis setelah pembuatan indeks, jalankan operasi rebuild pada indeks sebelum mengaktifkannya. Lihat BUILD INDEX.

    Hapus indeks sekunder

    Gunakan DROP INDEX untuk menghapus indeks sekunder dari tabel utama.

    DROP INDEX IF EXISTS idx_user ON orders;
    Menghapus indeks memerlukan izin Trash. Jika kueri aktif sedang menggunakan indeks tersebut, hapus dengan hati-hati.

    Pengoptimalan kueri

    Lindorm memilih indeks menggunakan Optimasi Berbasis Aturan (Rule Based Optimization/RBO). Sistem ini mencocokkan awalan (prefix) setiap indeks dengan klausa WHERE kueri dan memilih indeks dengan tingkat kecocokan tertinggi.

    Contoh berikut menunjukkan cara pengoptimal memilih indeks untuk tabel dengan beberapa indeks:

    CREATE TABLE dt (rowkey VARCHAR, c1 VARCHAR, c2 VARCHAR, c3 VARCHAR, c4 VARCHAR, c5 VARCHAR, PRIMARY KEY(rowkey));
CREATE INDEX idx1 ON dt(c1);
CREATE INDEX idx2 ON dt(c2, c3, c4);
CREATE INDEX idx3 ON dt(c3) INCLUDE(c1, c2, c4);
CREATE INDEX idx4 ON dt(c5 DESC) WITH (INDEX_COVERED_TYPE = 'COVERED_ALL_COLUMNS_IN_SCHEMA');

    Kueri

    Indeks yang dipilih

    Mengapa

    SELECT rowkey FROM dt WHERE c1 = 'a'

    idx1

    Kecocokan awalan tepat pada c1

    SELECT rowkey FROM dt WHERE c2 = 'b' AND c4 = 'd'

    idx2

    Cocok dengan awalan c2; c3 tidak ada dalam klausa WHERE, sehingga c4 difilter per baris setelah pemindaian indeks

    SELECT * FROM dt WHERE c2 = 'b' AND c3 >= 'c' AND c3 < 'f'

    idx2

    Cocok dengan awalan c2, c3; SELECT * memerlukan pencarian ke tabel utama karena idx2 tidak mencakup semua kolom—kunci baris yang tersebar dapat menghasilkan beberapa RPC, meningkatkan RT untuk set hasil besar

    SELECT * FROM dt WHERE c5 = 'c'

    idx4

    idx4 adalah indeks cakupan penuh; SELECT * tidak memerlukan pencarian ke tabel utama

    Satu kueri hanya dapat menggunakan satu indeks—penggabungan indeks tidak didukung.

    Untuk memengaruhi pemilihan indeks, gunakan petunjuk kueri (query hints). Lihat CREATE INDEX.

    Batasan

    • Nama indeks harus unik per tabel utama. Nama indeks yang sama dapat digunakan pada tabel utama berbeda.

    • Indeks hanya didukung pada tabel versi tunggal. Tabel multi-versi tidak mendukung indeks.

    • TTL tingkat sel tidak didukung. Tabel indeks mewarisi TTL dari tabel utama; Anda tidak dapat mengatur TTL terpisah untuk tabel indeks.

    • Untuk LindormTable 2.8.6 dan versi lebih baru: hingga 10 indeks per tabel utama, hingga 8 kolom indeks per indeks. Untuk versi sebelumnya: hingga 5 indeks dan hingga 3 kolom indeks.

    • Panjang gabungan kolom indeks dan kunci utama tidak boleh melebihi 30 KB. Hindari penggunaan kolom yang lebih besar dari 100 byte sebagai kolom indeks.

    • Satu kueri hanya menggunakan satu indeks. Kueri penggabungan indeks tidak didukung.

    • Indeks sekunder tidak mendukung fitur peningkatan batch.

    • Urutan hasil dari kueri indeks sekunder berbeda dari urutan tabel utama.

    • Indeks tidak dapat dibangun untuk data yang diimpor melalui Bulkload. Indeks hanya berlaku untuk data yang ditulis melalui SQL atau API.

    • Membuat indeks pada tabel besar menyebabkan CREATE INDEX berjalan lama saat data historis disinkronkan.

    FAQ

    Mengapa muncul error User-Defined-Timestamp(UDT) is not supported by table in MUTABLE_LATEST mode?

    Anda membuat indeks saat mutabilitas tabel diatur ke MUTABLE_LATEST, tetapi aplikasi Anda menulis data dengan timestamp kustom. MUTABLE_LATEST tidak mendukung timestamp kustom.

    Untuk memperbaikinya:

    1. Hapus indeks pada tabel utama.

    2. Ubah properti mutabilitas menjadi MUTABLE_UDT.

    3. Buat ulang indeks tersebut.

    Penting

    Jika kueri aktif sedang menggunakan indeks tersebut, menghapusnya akan memengaruhi kueri tersebut. Rencanakan dengan matang sebelum melanjutkan.

    Untuk masalah terkait indeks lainnya, bergabunglah dengan grup DingTalk Lindorm atau ajukan tiket. Lihat Dukungan teknis.

    Langkah selanjutnya