All Products
Search

This Product

    Lindorm:Penyebab umum hasil query yang tidak terduga

    Document Center

    Lindorm:Penyebab umum hasil query yang tidak terduga

    Last Updated:Jul 02, 2025

    Jika Anda menggunakan LindormTable secara tidak tepat, hasil query mungkin tidak sesuai dengan harapan. Topik ini menjelaskan penyebab umum hasil query yang tidak terduga untuk membantu Anda menangani masalah dan mengoptimalkan kondisi query.

    Masalah

    LindormTable adalah mesin data NoSQL yang kompatibel dengan Apache HBase. Model penyimpanannya diimplementasikan berdasarkan Log-Structured Merge Tree (LSM-Tree). Saat melakukan operasi penulisan pada LindormTable, data pertama kali ditulis ke log Write-Ahead Log (WAL) sebelum dikomit ke database. Jika tidak ada kesalahan selama operasi penulisan, data berhasil ditulis. Dalam hal ini, data dapat dipulihkan dari log WAL dalam skenario seperti kegagalan server, memastikan daya tahan data dan mencegah hilangnya data secara tak terduga. Namun, LindormTable menyediakan fitur kompleks seperti versi, timestamp, dan TTL data. Jika fitur-fitur ini tidak dikonfigurasi dengan benar, masalah tak terduga dapat terjadi, seperti data yang tidak dapat ditimpa, data yang dihapus karena kedaluwarsa, atau hasil query yang tidak sesuai dengan harapan. Masalah-masalah ini disebabkan oleh faktor-faktor berikut:

    Penyebab umum

    Data tidak berhasil ditulis atau query dilakukan sebelum data ditulis

    Di LindormTable, data tidak langsung terlihat setelah ditulis.

    Tabel lebar Lindorm sering digunakan dalam skenario data besar. Jika tautan penulisan data gagal, data mungkin tidak berhasil ditulis atau tertunda. Dalam hal ini, data yang ingin Anda query mungkin tidak ditemukan karena belum ditulis ke tabel.

    Jika data tidak dapat di-query hingga beberapa waktu setelah ditulis, kami sarankan Anda menambahkan petunjuk dalam kondisi query untuk mendapatkan timestamp data yang di-query dalam hasil. Kemudian, Anda dapat memeriksa apakah query dilakukan sebelum data ditulis berdasarkan timestamp. Untuk informasi lebih lanjut tentang cara mendapatkan timestamp dalam hasil query, lihat Gunakan petunjuk untuk menerapkan versioning data.

    Catatan

    Jika tidak ada timestamp yang ditentukan saat menulis data, timestamp yang dikembalikan menunjukkan waktu ketika baris data ditulis ke tabel.

    Kolom STRING berisi karakter stop atau karakter tak terlihat

    Saat meng-query kolom tipe data STRING, jika kolom tersebut berisi karakter tak terlihat, hasil query yang tidak terduga mungkin dikembalikan. Misalnya, kolom orderID sebuah tabel berisi data tipe STRING dan karakter tak terlihat secara tidak sengaja ditambahkan ke nilai 1000 dari sebuah field dalam kolom tersebut karena bug program. Nilai sebenarnya dari field tersebut menjadi 1000 (karakter tak terlihat).

    Dalam hal ini, jika Anda menentukan kondisi where oderID="1000" dalam query, field tersebut tidak dapat di-query karena nilainya tidak sesuai dengan kondisi. Anda dapat menentukan kondisi where orderID > "1000" limit 1 dalam query untuk memeriksa apakah jenis masalah ini terjadi.

    Selain itu, Lindorm tidak mendukung karakter stop di tengah nilai STRING. Jika Anda menulis string "1000\stop character\1000" ke tabel, pengecualian encoding mungkin terjadi dan string tersebut tidak dapat di-query.

    Nama kolom yang salah ditentukan dalam kondisi query

    Hasil query yang tidak terduga mungkin dikembalikan jika huruf besar/kecil nama kolom salah atau keluarga kolom tidak ditentukan dalam kondisi query.

    • Huruf besar/kecil nama kolom yang ditentukan salah: Nama kolom dalam Lindorm bersifat case-sensitive. Oleh karena itu, pastikan kolom yang ditentukan dalam kondisi query konsisten dengan nama kolom sebenarnya.

    • Keluarga kolom tidak ditentukan: Tabel lebar Lindorm mendukung beberapa keluarga kolom. Jika Anda tidak menentukan keluarga kolom saat membuat tabel, kolom tabel secara otomatis ditambahkan ke keluarga kolom bernama f secara default. Dalam hal ini, Anda tidak perlu menentukan keluarga kolom dalam kondisi query. Namun, jika Anda mengonfigurasi beberapa keluarga kolom untuk tabel, Anda harus menentukan keluarga kolom dalam kondisi query saat meng-query data dalam tabel. Jika Anda tidak menentukan keluarga kolom dalam kondisi, hanya data dalam keluarga kolom default f yang di-query. Dalam hal ini, hasil yang dikembalikan mungkin tidak sesuai dengan harapan. Misalnya, Anda membuat keluarga kolom bernama meta dan menambahkan kolom bernama column1 ke keluarga kolom tersebut. Saat Anda meng-query data dalam column1, Anda harus menentukan keluarga kolom meta dalam kondisi query dalam format berikut: where meta:column1=xxx. Jika Anda tidak menentukan keluarga kolom meta dalam kondisi query (seperti where column1=xxx), Lindorm hanya mencari column1 dalam keluarga kolom default f. Dalam hal ini, hasil yang dikembalikan mungkin tidak sesuai dengan harapan.

    Data yang di-query telah kedaluwarsa berdasarkan TTL yang dikonfigurasi untuk tabel

    LindormTable memungkinkan Anda menentukan time-to-live (TTL) data dalam detik untuk tabel. Selain itu, Anda dapat menentukan timestamp dalam milidetik saat menulis data ke tabel.

    Jika Anda tidak menentukan timestamp saat menulis data ke tabel, data akan kedaluwarsa ketika telah disimpan selama periode lebih lama dari TTL yang ditentukan. Misalnya, jika Anda menyetel TTL tabel menjadi 86400 detik (yang sama dengan 1 hari), data yang ditulis ke tabel hari ini akan kedaluwarsa besok dan tidak dapat di-query.

    Jika Anda menentukan timestamp yang lebih awal saat menulis data dan selisih antara timestamp dan waktu saat ini lebih besar dari parameter TTL yang ditentukan, data mungkin dihapus segera setelah ditulis ke tabel. Akibatnya, data tersebut tidak dapat di-query.

    Penting

    Dalam LindormTable, nomor versi pasangan key-value setara dengan timestamp. Jika Anda menentukan nilai kecil (seperti 1, 2, dan 3) sebagai nomor versi kustom, data rentan untuk dibersihkan berdasarkan TTL yang ditentukan. Demikian pula, jika Anda menentukan nilai besar, seperti timestamp dalam mikrodetik atau nanodetik alih-alih dalam milidetik, sebagai timestamp atau nomor versi kustom, data tidak dapat dibersihkan sesuai harapan berdasarkan TTL yang ditentukan.

    Anda dapat memeriksa TTL tabel dalam sistem manajemen kluster dengan langkah-langkah berikut: Masuk ke sistem manajemen kluster. Di halaman Overview, klik nama tabel yang ingin Anda periksa TTL-nya. Di bagian Current table details, klik View table properties. Di halaman yang muncul, periksa nilai TTL. Untuk informasi lebih lanjut tentang cara masuk ke sistem manajemen kluster, lihat Masuk ke sistem manajemen kluster.

    Anda dapat menggunakan Lindorm Shell atau menjalankan pernyataan ALTER TABLE untuk memodifikasi nilai TTL. Untuk informasi lebih lanjut, lihat dokumentasi berikut:

    Data yang di-query telah kedaluwarsa berdasarkan TTL sel yang dikonfigurasi

    LindormTable memungkinkan Anda mengonfigurasi TTL dalam milidetik untuk pasangan key-value. TTL ini juga disebut sebagai TTL sel.

    Jika Anda mengonfigurasi TTL sel untuk pasangan key-value, waktu kedaluwarsa pasangan key-value dapat dihitung berdasarkan rumus berikut: min{Waktu kedaluwarsa berdasarkan TTL sel, Waktu kedaluwarsa berdasarkan TTL tabel}. Waktu kedaluwarsa pasangan key-value dihitung berdasarkan timestamp atau nomor versi pasangan key-value. Jika timestamp atau nomor versi terlalu kecil atau terlalu besar, pasangan key-value mungkin dibersihkan lebih awal dari waktu yang diharapkan atau tidak dapat dibersihkan sesuai harapan. Dalam hal ini, hasil query yang dikembalikan mungkin tidak sesuai dengan harapan.

    Sebagai contoh, sebuah kolom berisi dua pasangan key-value bernama KV1 dan KV2. TTL sel dikonfigurasi untuk KV1 dan tidak ada TTL sel yang dikonfigurasi untuk KV2. Jika Anda meng-query data dalam kolom sebelum KV1 dan KV2 kedaluwarsa, KV1 yang timestamp-nya diperbarui mungkin dikembalikan. Jika Anda meng-query data dalam kolom setelah KV1 kedaluwarsa berdasarkan TTL sel-nya, KV1 dibersihkan dan KV2 dikembalikan, yang tidak sesuai dengan harapan.

    Catatan

    Apakah KV2 dapat di-query bergantung pada atribut VERSIONS tabel, apakah KV1 dan KV2 disimpan dalam file yang berbeda, dan apakah KV1 dan KV2 digabungkan oleh operasi major compaction. Sebagai contoh, jika Anda menyetel atribut VERSIONS tabel menjadi 1, KV2 dihapus setelah operasi major compaction karena hanya satu versi data yang disimpan berdasarkan atribut VERSIONS. Dalam hal ini, KV2 tidak dapat di-query bahkan jika KV1 dibersihkan setelah kedaluwarsa.

    Timestamp yang tidak tepat ditentukan dalam permintaan penghapusan

    LindormTable memungkinkan Anda mengonfigurasi timestamp atau nomor versi dalam permintaan penghapusan. Data yang ditulis ke kolom atau baris lebih awal dari waktu yang ditentukan oleh timestamp atau nomor versi dihapus. Jika Anda tidak mengonfigurasi timestamp atau nomor versi dalam permintaan, data yang ditulis ke kolom atau baris lebih awal dari waktu atau versi saat ini dihapus. Misalnya, waktu saat ini adalah 16:00:00, 16 Januari 2024. Jika Anda menjalankan pernyataan DELETE FROM sensor WHERE p1 = 10; untuk menghapus baris yang ditulis sebelum waktu saat ini dan nilai dalam kolom p1 adalah 10.

    Jika waktu ketika baris data ditulis ke tabel lebih lambat dari waktu yang ditentukan oleh timestamp dalam permintaan penghapusan, baris tersebut tidak dihapus. Dalam hal ini, baris ini termasuk dalam hasil query saat Anda meng-query data dalam tabel.

    Jika timestamp atau nomor versi yang ditentukan dalam permintaan penghapusan besar, timestamp data yang ditulis setelah operasi penghapusan masih lebih kecil dari timestamp atau nomor versi dalam permintaan. Dalam hal ini, data dihapus segera setelah ditulis dan tidak dapat di-query.

    Catatan

    Timestamp tidak dapat ditentukan menggunakan pernyataan SQL.

    Data dihapus segera setelah ditulis karena masalah koneksi

    Dalam skenario data besar, jika operasi penulisan dan penghapusan dilakukan dalam program atau proses yang berbeda, data mungkin dihapus segera setelah ditulis.

    Selain itu, jika Anda menggunakan versi Lindorm connector yang lebih lama yang disediakan oleh Realtime Compute for Apache Flink untuk memperbarui tabel lebar Lindorm, perhatikan masalah bahwa operasi penulisan mungkin ditimpa oleh operasi penghapusan yang dilakukan jika kedua operasi dilakukan hampir bersamaan. Anda dapat menyelesaikan masalah ini dengan mengonfigurasi ignoreDelete=true dalam Flink.

    Untuk informasi lebih lanjut, lihat Lindorm connector.

    Data dihapus karena atribut VERSIONS tabel disetel ke 0

    Jika nilai atribut VERSIONS tabel lebar disetel ke 0, data dalam tabel tidak disimpan. Data apa pun yang ditulis ke tabel segera dihapus dan tidak dapat di-query. Jika Anda tidak mengonfigurasi atribut VERSIONS untuk tabel saat membuat tabel, nilai atribut ini adalah 1 secara default, yang menunjukkan bahwa hanya satu versi data yang disimpan dalam tabel. Untuk informasi lebih lanjut, lihat Gunakan petunjuk untuk menerapkan versioning data.

    Jika Anda secara tidak sengaja menyetel atribut VERSIONS ke 0, kami sarankan Anda menghapus tabel saat ini dan membuat tabel baru, atau mengubah atribut VERSIONS ke nilai lebih besar dari atau sama dengan 1.

    Anda dapat memeriksa nilai atribut VERSIONS tabel dalam sistem manajemen kluster dengan langkah-langkah berikut: Masuk ke sistem manajemen kluster. Di halaman Overview, klik nama tabel yang ingin Anda periksa. Di bagian Current table details, klik View table properties. Di halaman yang muncul, periksa nilai VERSIONS. Untuk informasi lebih lanjut tentang cara masuk ke sistem manajemen kluster, lihat Masuk ke sistem manajemen kluster.

    Anda dapat menggunakan Lindorm Shell atau menjalankan pernyataan ALTER TABLE untuk memodifikasi nilai atribut VERSIONS. Untuk informasi lebih lanjut, lihat dokumentasi berikut:

    Catatan

    Atribut MIN_VERSIONS menentukan jumlah minimum versi yang dapat disimpan dalam tabel dan disetel ke 0 secara default. Atribut ini tidak menyebabkan masalah bahwa data dihapus dan tidak dapat di-query setelah ditulis ke tabel.

    Data dalam tabel immutable diperbarui

    Jika atribut MUTABILITY tabel disetel ke IMMUTABLE, Anda hanya dapat menulis baris data ke tabel dengan menjalankan pernyataan UPSERT tunggal. Data yang ditulis ke tabel tidak diizinkan untuk diperbarui atau dihapus. Namun, Lindorm tidak sepenuhnya melarang operasi pembaruan dan penghapusan yang dilakukan pada tabel immutable. Oleh karena itu, operasi semacam itu dapat menyebabkan inkonsistensi data antara tabel indeks dan tabel dasar. Akibatnya, data yang memenuhi kondisi query berbeda dalam tabel indeks dan tabel dasar.

    Dalam hal ini, kami sarankan Anda membangun kembali tabel indeks dan berhenti memperbarui atau menghapus data dalam tabel immutable.