Lindorm:FAQ Pemisahan data panas dan dingin

Lindorm secara asinkron mengarsipkan data dingin dari penyimpanan panas ke penyimpanan dingin melalui proses compaction. Secara default, sistem memicu proses ini dengan interval setengah dari batas waktu antara data panas dan dingin. Interval minimum adalah 1 hari, dan maksimum adalah setengah dari periode major compaction. Periode default major compaction adalah 20 hari. Sebagai contoh, jika batas waktu data panas-dingin adalah 3 hari, tugas pengarsipan compaction akan dipicu secara otomatis setiap 1,5 hari. Jika batasnya 1 hari, tugas compaction dipicu sekali sehari.

Ya. Anda dapat menjalankan perintah major_compact 'tableName' di HBase Shell untuk memaksa compaction. Tindakan ini akan mengarsipkan data dingin dari penyimpanan panas ke penyimpanan dingin.

Hal ini dapat terjadi jika data yang Anda tulis belum disimpan ke disk. Pertama-tama, jalankan operasi flush untuk menulis data ke disk, lalu jalankan operasi compaction untuk memindahkan data tersebut ke penyimpanan dingin. Anda dapat memicu operasi compaction sebagai berikut:

• Di HBase Shell, jalankan perintah major_compact.

• Jika Anda terhubung menggunakan Lindorm-cli, lihat sintaks yang benar di ALTER TABLE.

• Jika terjadi backlog compaction, hal ini memengaruhi kecepatan pemindahan data panas ke penyimpanan dingin. Dalam kasus ini, Anda perlu menambah sumber daya CPU dengan melakukan scaling out atau peningkatan konfigurasi untuk mengatasi backlog compaction.

  Catatan

  Anda dapat memeriksa adanya backlog compaction di halaman Pemantauan Instance. Buka bagian Table Metrics-Cluster Load dan periksa metrik Compaction Queue Size(count). Jika nilainya terus-menerus lebih besar dari 0 dan meningkat, berarti terdapat backlog compaction. Untuk informasi selengkapnya, lihat Lihat informasi pemantauan.

• Jika Anda belum menggunakan versi terbaru LindormTable, lakukan upgrade ke versi terbaru. Versi yang lebih baru mengarsipkan data dingin lebih cepat. Untuk melihat versi saat ini atau melakukan upgrade, lihat Catatan rilis LindormTable dan Pembaruan versi minor.

• Jika Anda memiliki pertanyaan lain, hubungi dukungan teknis.

Jika pembaruan tidak mengubah nilai kolom waktu kustom, data tetap dingin. Namun, jika Anda memperbarui nilai pada kolom waktu kustom tersebut, sistem akan mengevaluasi ulang apakah data tersebut termasuk panas atau dingin berdasarkan nilai waktu barunya. Sebagai contoh, pertimbangkan sebuah tabel dengan kolom kunci primer p1 dan p2, serta kolom non-primer c1 dan c2. Sebuah baris memiliki nilai: p1=row1, p2=2023-01-28, c1="c1", dan c2="c2". Batas waktu data panas-dingin adalah 1 hari, dan tanggal saat ini adalah 2023-01-30. Baris ini dianggap sebagai data dingin. Jika Anda memperbarui nilai kolom c1 dan c2, baris tersebut tetap menjadi data dingin. Namun, jika Anda mengubah nilai p2 menjadi 2023-01-30, baris tersebut menjadi data panas. Data ini akan diklasifikasikan ulang sebagai data dingin pada 1 Februari 2023, ketika usianya melebihi batas 1 hari.

Tidak. Sistem bergantung pada kolom waktu kustom untuk memisahkan data panas dan dingin. Jika suatu baris tidak memiliki nilai pada kolom ini, data tersebut selalu tetap berada di penyimpanan panas.

Tidak, data tersebut menjadi data panas. Memperbarui data juga memperbarui timestamp-nya.

Anda dapat menggunakan pengaturan HOT_ONLY atau petunjuk _l_hot_only_ dalam kueri Anda untuk hanya mengambil data panas. Namun, proses pengarsipan data ke penyimpanan dingin bersifat periodik. Artinya, beberapa data yang seharusnya sudah dingin mungkin masih berada di penyimpanan panas saat Anda menjalankan kueri, sehingga ikut muncul dalam hasil. Untuk mencegah hal ini, tambahkan filter rentang waktu untuk data panas ke dalam kondisi kueri Anda. Contohnya:

// Untuk mengkueri rentang waktu tertentu, atur _l_ts_min_ (Waktu mulai) dan _l_ts_max_ (Waktu akhir).
// Pastikan menggunakan satuan waktu yang konsisten.
SELECT /*+ _l_hot_only_(true), _l_ts_min_(1000), _l_ts_max_(2001) */ * FROM test WHERE p1>1;

Hal ini biasanya terjadi setelah migrasi data atau setelah Anda mengaktifkan pemisahan data panas dan dingin pada tabel yang sudah ada. Dalam skenario ini, sistem mungkin belum memicu proses pengarsipan, sehingga sejumlah besar data dingin masih tersimpan di penyimpanan panas. Hal ini meningkatkan volume total data yang dipindai dan dapat memperlambat kueri hingga menyebabkan timeout. Untuk mengatasinya, jalankan major compaction pada tabel tersebut. Untuk sintaks spesifiknya, lihat ALTER TABLE.

Hal ini terjadi karena tabel utama dan tabel indeks memiliki proses pengarsipan data dingin yang independen. Karena proses pengarsipan bersifat periodik untuk kedua tabel, jumlah data dingin yang tersisa di penyimpanan panas masing-masing tabel bisa berbeda. Hal ini dapat menyebabkan hasil kueri yang tidak konsisten. Untuk menghindari masalah ini, tambahkan filter rentang waktu untuk data panas ke dalam kondisi kueri Anda.

Sistem memicu compaction untuk mengarsipkan data dingin ketika usia file data tertua melebihi periode pengarsipan yang dikonfigurasi. Apakah compaction dijalankan segera atau tidak bergantung pada selisih antara waktu saat ini dan waktu pembuatan file tertua tersebut.

Ya. Anda dapat mengkueri data dingin dengan menentukan rentang waktu dalam operasi Scan Anda. Untuk detail selengkapnya, lihat Kueri data yang dipisahkan berdasarkan timestamp dan Scan dan kueri data yang dipisahkan berdasarkan kolom waktu kustom. Perlu diperhatikan bahwa IOPS baca untuk jenis penyimpanan capacity-optimized dan archive relatif rendah, yang dapat memperlambat kueri semacam ini.