Lindorm:Rangkuman Masalah

Mengapa Lindorm-cli gagal terhubung ke LindormTable?

Periksa hal-hal berikut:

• Apakah ini koneksi jaringan publik? Jika ya, dapatkan alamat IP publik dan tambahkan ke daftar putih Lindorm.

• Apakah Anda menggunakan proxy seperti VPN tetapi belum menambahkannya ke daftar putih?

• Apakah port layanan tersedia? Anda dapat menggunakan perintah telnet untuk menguji konektivitas ke port Lindorm.

• Jika Anda menggunakan ECS untuk terhubung ke LindormTable, lihat masalah koneksi Lindorm dan solusinya.

Apa saja nomor port umum untuk LindormTable?

Apa dampak dari pembaruan versi minor? Berapa lama waktu yang dibutuhkan?

Pembaruan versi minor akan memutus koneksi satu node secara bergiliran. Setiap server menjalankan restart bergulir. Selama pembaruan, Region akan offline lalu kembali online. Setelah pembaruan selesai, sistem melakukan rebalance muatan.

Dampak: Instans dengan muatan rendah hampir tidak terpengaruh. Instans dengan muatan tinggi atau sensitif terhadap latensi mungkin terganggu. Lakukan pembaruan selama jam sepi.

Perkiraan durasi: Sekitar 5–30 menit per node. Waktu aktual tergantung pada jumlah Region dan muatan saat ini.

Operasi compaction

Mengapa penggunaan penyimpanan terus meningkat meskipun TTL telah diatur?

Gunakan pemantauan instans untuk memeriksa Compaction queue length (count) di bawah Metrik LindormTable — beban kluster. Jika banyak tugas yang tertunda, pembersihan data tertunda. Jika utilisasi CPU kurang dari 40%, versi LindormTable 2.6.5 ke atas menyesuaikan parameter secara otomatis berdasarkan beban. Cukup perbarui ke versi minor yang lebih baru. Jika utilisasi CPU lebih dari 40%, tambahkan lebih banyak node LindormTable.

Jika antrian kosong, compaction berjalan normal. Jika beban I/O rendah, picu compaction secara manual atau sesuaikan interval major compaction. Misalnya, atur menjadi 2 hari: ALTER TABLE <tableName> SET 'COMPACTION_MAJOR_PERIOD'='172800000';.

Interval default adalah 20 hari. Dalam skenario TTL, interval default adalah min(ttl,20 days).

Bagaimana cara mengurangi ruang penyimpanan dengan mengatur algoritma kompresi dan codec?

Atur algoritma kompresi tabel COMPRESSION ke ZSTD dan codec DATA_BLOCK_ENCODING ke INDEX. Lalu jalankan major compaction.

Detail:

• SQL: Hubungkan ke LindormTable menggunakan Lindorm-cli atau gunakan sistem manajemen kluster (Lindorm Insight) untuk menjalankan pernyataan SQL.

  -- Atur kompresi ke ZSTD dan encoding ke INDEX
  ALTER TABLE <tablename> SET 'COMPRESSION' = 'ZSTD','DATA_BLOCK_ENCODING' = 'INDEX';
  ALTER TABLE <tablename> COMPACT;
  -- Tunggu jika tabel memiliki banyak Region 

  Gunakan pemantauan instans untuk memeriksa Compaction queue length (count) di bawah Metrik LindormTable — beban kluster untuk melacak progres.

• HBase API: Buat tabel dan masukkan data

  alter 'ns:tablename', {NAME=>'family', DATA_BLOCK_ENCODING => 'INDEX',COMPRESSION => 'ZSTD'}
  // Tunggu jika tabel memiliki banyak Region
  major_compact 'ns:tablename'
  // Tunggu jika tabel memiliki banyak Region

  Gunakan pemantauan instans untuk memeriksa Compaction queue length (count) di bawah Metrik LindormTable — beban kluster untuk melacak progres.

• Gunakan sistem manajemen kluster (Lindorm Insight):

  Gunakan manajemen perubahan tabel untuk mengatur kompresi ke ZSTD. Lalu buka halaman Overview untuk melihat detail tabel. Gulir ke bawah untuk melihat detail tugas compaction.

Apa yang harus saya lakukan ketika disk (storage space) mencapai kapasitas penuh?

Anda dapat melakukan salah satu dari hal berikut:

• Perluas kapasitas penyimpanan panas.

• Gunakan DROP TABLE untuk menghapus tabel yang tidak digunakan dan langsung membebaskan ruang penyimpanan.

• Gunakan TRUNCATE TABLE untuk mengosongkan semua data dari tabel dan langsung membebaskan ruang penyimpanan.

Mengapa saya tidak dapat menghapus data setelah disk (storage space) mencapai kapasitas penuh?

Jangan gunakan DELETE untuk menghapus data secara langsung. Berikut alasannya:

Lindorm memprioritaskan performa tulis. Operasi hapus tidak membaca data terlebih dahulu. Sebaliknya, operasi tersebut menulis penanda hapus (Delete Marker) sehingga data menjadi tidak terlihat dalam kueri. Data hanya dihapus secara fisik selama operasi compaction berikutnya. Untuk interval pemicu, lihat interval pemicu otomatis untuk operasi compaction.

Selain itu, ketika disk mencapai batas kapasitasnya, sistem melarang semua operasi penulisan data, termasuk penulisan penanda hapus. Karena penanda hapus tidak dapat ditulis, data yang akan dihapus tidak dapat dibersihkan oleh operasi Compaction. Oleh karena itu, operasi ini tidak dapat langsung membebaskan ruang.

Apakah LindormTable mendukung perubahan jumlah node atau penskalaan kapasitas disk?

Mengubah jumlah node merupakan operasi tingkat engine. Penskalaan kapasitas disk merupakan operasi tingkat instans.

• Instans berbasis local-disk maupun cloud-disk mendukung perubahan jumlah node LindormTable.

• Instans local-disk tidak mendukung penskalaan kapasitas disk. Instans cloud-disk mendukung penskalaan kapasitas penyimpanan panas dan penskalaan kapasitas penyimpanan dingin. Penskalaan turun memerlukan penyalinan data dan membutuhkan waktu. Harap tunggu.

Satuan apa yang harus saya gunakan untuk properti tabel umum?

• major compaction interval: Parameter COMPACTION_MAJOR_PERIOD mengatur interval major compaction. Unitnya adalah milidetik (ms). Anda dapat menentukan interval ini saat membuat tabel menggunakan interval major compaction.

• Timestamp: Unitnya adalah milidetik (ms). Beberapa hint menggunakan detik (s), misalnya /*+ _l_ts_(%s) */.

• TTL (time-to-live): Unitnya adalah detik (s). Anda dapat menentukan TTL saat membuat tabel menggunakan kedaluwarsa data.

Bagaimana cara mengatur parameter NUMREGIONS saat membuat tabel?

Jika Anda tidak menentukan NUMREGIONS, nilai default-nya adalah 1 partisi. Kami merekomendasikan mengatur NUMREGIONS ke jumlah node Server × 4 pada awalnya. Partisi akan terpisah secara otomatis ketika datanya mencapai 8 GB. Atau, jika QPS baca/tulis gabungan untuk partisi tersebut melebihi 1000, sistem akan mendeteksi hot spot dan memutuskan apakah akan melakukan pemisahan.

Kami merekomendasikan memperbarui ke versi minor LindormTable yang lebih baru (2.4.x atau lebih baru) untuk self-healing hot-spot yang lebih baik.

Apa dampak dari memodifikasi properti tabel dengan ALTER TABLE?

ALTER TABLE menutup dan membuka kembali semua Region tabel tersebut. Dampaknya minimal. Jika aplikasi Anda sensitif terhadap latensi baca — misalnya memerlukan waktu respons dalam milidetik — lakukan operasi ini selama jam sepi.

Mengapa operasi tulis saya melebihi batas ukuran kolom maksimum?

Saat operasi tulis Anda melebihi batas ukuran kolom maksimum, sistem mengembalikan error berikut:

com.alibaba.lindorm.client.exception.IllegalDataException: Column [xxx] is too big, max length is 2097152 bytes but has 7621168 bytes.

Kolom VARBINARY tidak memiliki batas panjang. Untuk batasan lainnya, lihat kuota dan batasan.

Secara default, satu sel tidak boleh melebihi 2 MB. Pertimbangkan muatan dan ruang penyimpanan instans Anda. Jika muatannya rendah, Anda dapat sementara menaikkan ukuran maksimum kolom non-primary-key menggunakan SQL (tidak disarankan): ALTER TABLE <tablename> SET 'MAX_NONPK_LEN'='4194304'; (unit: byte).

Apa saja metode dan pertimbangan untuk menghapus data?

Lindorm mendukung dua cara untuk menghapus data: gunakan TRUNCATE TABLE untuk mengosongkan semua data dari tabel, atau hapus baris tertentu menggunakan primary key lengkap. Setelah penghapusan, jika aplikasi Anda sensitif terhadap RT baca, jalankan major compaction secara manual. Jika tidak, tunggu siklus compaction terjadwal.

Bagaimana cara memverifikasi bahwa data telah dipindahkan ke cold storage?

• Anda dapat terlebih dahulu menentukan primary key untuk mengkueri semua data yang akan diverifikasi, lalu gunakan primary key yang sama untuk mengkueri hanya data panas menggunakan HINT. Bandingkan hasil kueri: jika hasilnya sama, data belum masuk cold storage. Jika hasil kueri semua data dan kueri hanya data panas menggunakan HINT berbeda, dan Anda tidak dapat menemukan data dingin saat mengkueri semua data, hal ini menunjukkan bahwa data telah masuk cold storage.

• Sebelum memverifikasi, gunakan sistem manajemen kluster (Lindorm Insight) dan halaman Overview untuk memeriksa ukuran cold storage dan hot storage. Bandingkan ukuran tersebut sebelum dan sesudah pengarsipan.

Mengapa data saya belum dipindahkan ke cold storage?

Lihat mengapa data belum dipindahkan ke cold storage setelah compaction.

Alasan utamanya meliputi hal berikut:

• Flush belum dilakukan

  Jalankan flush untuk menulis data ke disk sebelum menjalankan compaction.

• Tunggakan Pemadatan

  Anda dapat menambah sumber daya CPU dengan skala keluar atau peningkatan untuk mengatasi masalah antrian compaction yang menumpuk.

  Catatan

  Anda dapat menentukan apakah terjadi penumpukan antrian compaction dengan melihat informasi pemantauan di Lihat informasi pemantauan, khususnya LindormTable Metrics – Cluster Load > Compaction Queue Length (items). Jika nilainya tetap lebih besar dari 0 dan terus meningkat, berarti terjadi penumpukan antrian compaction.

• Data memiliki timestamp

Mengapa kueri indeks sekunder tidak mengembalikan nilainull?

Saat menggunakan pengurutan ulang primary key dan indeks multi-kolom, sistem tidak membangun indeks sekunder jika nilai kolom non-primary-key pertama adalah NULL. Hanya kolom non-primary-key dengan nilai aktual yang muncul di tabel indeks.

Apa penyebab hasil kueri yang tidak sesuai ekspektasi?

Alasan umum mengapa hasil kueri tidak sesuai ekspektasi

Apa arti metrik token cold storage dalam pemantauan?

Cold storage digunakan untuk data arsip yang jarang diakses. Minimalkan pembacaan dari cold storage. Metrik token cold storage memantau pembatasan laju untuk cold storage. Penurunan jumlah token yang terus-menerus berarti beberapa permintaan telah dikendalikan alirannya.

Apa konfigurasi pemantauan yang direkomendasikan?

Lihat praktik terbaik pemantauan dan peringatan.

FAQ pemantauan tingkat tabel

Apa perbedaan antara tabel SQL dan tabel HBase? Bagaimana cara membedakannya?

Tabel SQL dan tabel HBase berbeda dalam struktur dan operasi data. Tabel SQL memiliki skema tetap (nama dan tipe kolom ditentukan sebelumnya) dan hanya mendukung operasi SQL. Tabel HBase tidak memiliki skema tetap (mendukung kolom dinamis) dan menggunakan API HBase (tetapi juga memungkinkan kueri SQL). Untuk membedakannya:

• Metode pembuatan

  • Tabel HBase: Dibuat menggunakan hbase shell atau alat sinkronisasi HBase lainnya (juga disebut "tabel lebar").

  • Tabel SQL: Dibuat menggunakan perintah SQL (SQL tidak dapat membuat tabel HBase).

• Ciri struktural

  • Tabel HBase: Tidak memiliki skema. Mendukung kolom dinamis.

  • Tabel SQL: Skema tetap. Tipe kolom didefinisikan secara ketat.

• Batasan operasi

  • Tabel HBase: Hanya dapat ditulis melalui API HBase (dapat dibaca melalui SQL, lihat dokumentasi pemetaan Htype).

  • Tabel SQL: Hanya dapat dibaca dan ditulis melalui API SQL.

• Metode verifikasi
  Jalankan perintah SQL berikut untuk memeriksa properti IS_HBASE_LIKE:
  

  SHOW TABLE VARIABLES FROM <database_name> LIKE 'IS_HBASE_LIKE';  

  • true: Tabel HBase

  • false: Tabel SQL

Apakah ApsaraDB for HBase Performance-enhanced Edition mendukung SQL?

ApsaraDB for HBase Performance-enhanced Edition menggunakan engine LindormTable (kompatibel dengan HBase atau Cassandra). Penggunaannya sama dengan LindormTable. Layanan ini mendukung SQL. Anda dapat terhubung ke LindormTable menggunakan Lindorm-cli:

./lindorm-cli -url jdbc:lindorm:table:url=http://ld-bp17j28j2y7pm****-proxy-lindorm-pub.lindorm.rds.aliyuncs.com:30060 -username xxx -password xxx
# Setelah terhubung
lindorm:default> show databases;

Apa yang perlu diketahui pengguna client HBase open-source?

Client HBase open-source tidak mendukung otentikasi atau penerapan multi-zona. Sebelum terhubung ke LindormTable, instal SDK HBase.

Bagaimana cara mengaktifkan penghapusan batch?

Gunakan perintah berikut untuk mengaktifkan dan memeriksa pengaturan penghapusan batch.

-- Aktifkan atau nonaktifkan menggunakan SQL
ALTER SYSTEM SET `lindorm.allow.range.delete`=TRUE;
-- Periksa pengaturan saat ini    
SHOW SYSTEM variables LIKE 'lindorm.allow.range.delete';

Mengapa pembaruan batch tidak didukung, atau mengapa muncul errorUpdate's WHERE clause can only contain PK columns?

Pembaruan baris tunggal diaktifkan secara default. Gunakan perintah berikut untuk mengaktifkan dan memeriksa pengaturan pembaruan batch.

Jika pembaruan batch pada tabel menyebabkan timeout kueri, lihat solusi.

-- Aktifkan atau nonaktifkan menggunakan SQL 
ALTER SYSTEM SET `lindorm.allow.batch.update`=TRUE;
-- Periksa pengaturan saat ini    
SHOW SYSTEM variables LIKE 'lindorm.allow.batch.update';

Timeout kueri setelah penghapusan batch pada tabel

• Cara kerja penghapusan
  Lindorm memprioritaskan throughput tulis tinggi. Operasi hapus tidak langsung menghapus data. Sebaliknya, operasi tersebut menulis Delete Marker. Hal ini transparan bagi pengguna — data yang dihapus tidak terlihat dalam operasi baca, tetapi sistem harus melewati marker dan data yang dihapus selama pembacaan. Penghapusan normal jarang menimbulkan masalah. Penghapusan skala besar mengakumulasi banyak Delete Marker. Contoh: Membaca rentang dengan 100.000 baris valid, 1.000.000 baris yang dihapus, dan 1.000.000 Delete Marker memaksa sistem memindai ~2,1 juta catatan untuk memfilter hasil valid. Hal ini secara signifikan meningkatkan waktu baca dan dapat menyebabkan timeout.
  

• Alasan timeout kueri
  Kueri yang memindai rentang dengan banyak penghapusan tertunda menghasilkan banyak deleteMarker. Melewati marker tersebut menambah overhead dan menyebabkan timeout.
  

• Solusi
  Jalankan compaction untuk menghapus permanen data kedaluwarsa dan deleteMarker. Compaction dipicu secara otomatis atau manual. Untuk detailnya, lihat operasi compaction.
  

Timeout kueri setelah pembaruan batch pada tabel dengan indeks sekunder

• Alasan timeout kueri

  Indeks sekunder adalah tabel indeks terpisah. Format primary key-nya adalah [nilai kolom yang diindeks] + [RowKey tabel utama]. Saat catatan tabel utama diperbarui atau dihapus, Lindorm secara otomatis:

  Menghapus entri indeks lama (menulis Delete Marker) dan memasukkan entri indeks baru (jika berlaku).

  Oleh karena itu, pembaruan skala besar pada kolom yang diindeks menghasilkan banyak Delete Marker di tabel indeks. Kueri yang menggunakan indeks harus memindai semua RowKey untuk nilai indeks target dan melewati entri yang dihapus. Jika hanya sedikit entri yang valid, overhead pemindaian dan penyaringan meningkat tajam. Hal ini meningkatkan latensi kueri dan mengurangi throughput.

• Cara kerja penghapusan
  Lindorm memprioritaskan throughput tulis tinggi. Operasi hapus tidak langsung menghapus data. Sebaliknya, operasi tersebut menulis Delete Marker. Hal ini transparan bagi pengguna — data yang dihapus tidak terlihat dalam operasi baca, tetapi sistem harus melewati marker dan data yang dihapus selama pembacaan. Penghapusan normal jarang menimbulkan masalah. Penghapusan skala besar mengakumulasi banyak Delete Marker. Contoh: Membaca rentang dengan 100.000 baris valid, 1.000.000 baris yang dihapus, dan 1.000.000 Delete Marker memaksa sistem memindai ~2,1 juta catatan untuk memfilter hasil valid. Hal ini secara signifikan meningkatkan waktu baca dan dapat menyebabkan timeout.
  

• Solusi
  Jalankan compaction untuk menghapus permanen data kedaluwarsa dan deleteMarker. Compaction dipicu secara otomatis atau manual. Untuk detailnya, lihat operasi compaction.