全部产品
Search
文档中心

Lindorm:Menyimpan Data Panas dan Data Dingin Secara Terpisah Berdasarkan Timestamp

更新时间:Jul 02, 2025

Topik ini menjelaskan cara menyimpan data panas dan data dingin secara terpisah di Lindorm berdasarkan timestamp.

Informasi Latar Belakang

Lindorm dapat mengarsipkan data ke penyimpanan dingin berdasarkan timestamp dan batas data panas-dingin yang ditentukan. Jika Anda tidak menentukan timestamp, waktu saat data ditulis ke tabel digunakan untuk menentukan apakah akan mengarsipkan data ke penyimpanan dingin.

Prasyarat

Prosedur

Metode 1: Gunakan Apache HBase Shell untuk menerapkan pemisahan data panas-dingin

  1. Buat tabel dan tentukan batas data panas-dingin untuk tabel tersebut.

    HBase(main):002:0> create 'chsTable', {NAME=>'f', COLD_BOUNDARY=>'86400'}

    Parameter

    • NAME: Nama keluarga kolom tempat Anda ingin menerapkan pemisahan data panas-dingin.

    • COLD_BOUNDARY: Batas berdasarkan mana pemisahan data panas-dingin dilakukan. Satuan nilai parameter ini adalah detik. Misalnya, jika nilai parameter COLD_BOUNDARY diatur menjadi 86400, data diarsipkan ke penyimpanan dingin setelah disimpan di penyimpanan panas selama 86.400 detik, yaitu sama dengan satu hari.

  2. (Opsional) Ubah batas data panas-dingin.

    HBase(main):005:0> alter 'chsTable', {NAME=>'f', COLD_BOUNDARY=>'42300'}
  3. (Opsional) Nonaktifkan pemisahan data panas-dingin.

    HBase(main):004:0> alter 'chsTable', {NAME=>'f', COLD_BOUNDARY=>""}
    Catatan

    Setelah Anda mengubah batas data panas-dingin atau menonaktifkan pemisahan data panas-dingin, data dipindahkan dari penyimpanan dingin ke penyimpanan panas setelah Lindorm melakukan operasi compaction. Untuk segera memindahkan data dari penyimpanan dingin ke penyimpanan panas, jalankan perintah major_compact secara manual.

Metode 2: Gunakan ApsaraDB for HBase API for Java untuk menerapkan pemisahan data panas-dingin

  1. Buat tabel dan tentukan batas data panas-dingin untuk tabel tersebut.

    Admin admin = connection.getAdmin();
    TableName tableName = TableName.valueOf("chsTable");
    HTableDescriptor descriptor = new HTableDescriptor(tableName);
    HColumnDescriptor cf = new HColumnDescriptor("f");
    cf.setValue(AliHBaseConstants.COLD_BOUNDARY, "86400");
    descriptor.addFamily(cf);
    admin.createTable(descriptor);                        
  2. (Opsional) Ubah batas data panas-dingin.

    HTableDescriptor descriptor = admin
        .getTableDescriptor(tableName);
    HColumnDescriptor cf = descriptor.getFamily("f".getBytes());
    cf.setValue(AliHBaseConstants.COLD_BOUNDARY, "86400");
    admin.modifyTable(tableName, descriptor);
  3. (Opsional) Nonaktifkan pemisahan data panas-dingin.

    HTableDescriptor descriptor = admin
        .getTableDescriptor(tableName);
    HColumnDescriptor cf = descriptor.getFamily("f".getBytes());
    cf.setValue(AliHBaseConstants.COLD_BOUNDARY, null);
    admin.modifyTable(tableName, descriptor);
    Catatan

    Setelah Anda mengubah batas data panas-dingin atau menonaktifkan pemisahan data panas-dingin, data dipindahkan dari penyimpanan dingin ke penyimpanan panas setelah Lindorm melakukan operasi compaction.

Metode 3: Gunakan lindorm-cli untuk menerapkan pemisahan data panas-dingin

  1. Buat tabel dan tentukan batas data panas-dingin untuk tabel tersebut.

    • Aktifkan pemisahan data panas-dingin dan tentukan batas data panas-dingin untuk tabel saat Anda membuat tabel.

      CREATE TABLE dt (  
        p1 integer, p2 integer, c1 varchar, c2 bigint,  constraint pk primary key(p1 desc)) WITH
      (COMPRESSION = 'ZSTD', CHS = '86400', CHS_L2 = 'storagetype=COLD');

      Parameter

      • CHS: Batas data panas-dingin untuk tabel. Data yang telah disimpan dalam tabel selama periode lebih lama dari periode ini diarsipkan di penyimpanan dingin. Satuan nilai parameter ini adalah detik. Misalnya, jika nilai parameter ini adalah 86400, data diarsipkan ke penyimpanan dingin setelah ditulis ke tabel selama 86.400 detik, yaitu sama dengan satu hari.

      • COMPRESSION: Algoritma yang digunakan untuk mengompresi data. Parameter ini berlaku untuk semua data dalam tabel. Nilai parameter ini tidak peka huruf besar/kecil. Nilai default: NONE.

      • CHS_L2: Atribut layer-2. Secara umum, parameter ini dikonfigurasi untuk menentukan tipe penyimpanan. Atur parameter ini ke storagetype=COLD.

    • Gunakan sintaks ALTER TABLE untuk menentukan batas data panas-dingin untuk tabel yang sudah ada.

      -- Dalam contoh ini, pemisahan data panas-dingin tidak diaktifkan untuk tabel sampel dt saat tabel dibuat.
      -- CREATE TABLE dt (p1 integer, p2 integer, c1 varchar, c2 bigint,  constraint pk primary key(p1 desc)) WITH (COMPRESSION = 'ZSTD');
      
      -- Aktifkan pemisahan data panas-dingin untuk tabel dt.
      ALTER TABLE dt SET 'CHS' ='86400', 'CHS_L2' = 'storagetype=COLD';
  2. (Opsional) Ubah batas data panas-dingin.

    ALTER TABLE dt SET 'CHS'='1000';
  3. (Opsional) Nonaktifkan pemisahan data panas-dingin.

    ALTER TABLE dt SET 'CHS'='', 'CHS_L2' = '';
    Catatan

    Setelah Anda mengubah batas data panas-dingin atau menonaktifkan pemisahan data panas-dingin, data dipindahkan dari penyimpanan dingin ke penyimpanan panas setelah Lindorm melakukan operasi compaction. Untuk segera memindahkan data dari penyimpanan dingin ke penyimpanan panas, jalankan perintah major_compact secara manual. Untuk informasi lebih lanjut tentang sintaks yang digunakan untuk melakukan operasi ini, lihat ALTER TABLE.

Tulis Data

Anda dapat menulis data ke tabel lebar yang menyimpan data panas dan data dingin secara terpisah dengan cara yang sama seperti Anda menulis data ke tabel standar. Secara default, timestamp data adalah waktu sistem saat ini ketika data ditulis. Jika Anda menggunakan ApsaraDB for HBase API untuk menulis data, Anda dapat menentukan timestamp kustom sesuai kebutuhan. Saat data ditulis ke tabel yang menyimpan data panas dan data dingin secara terpisah, data pertama kali disimpan di penyimpanan panas bertipe Standar atau Performa. Ketika data telah disimpan selama periode yang lebih lama dari nilai yang ditentukan oleh COLD_BOUNDARY atau CHS, data diarsipkan ke penyimpanan dingin saat Lindorm melakukan operasi compaction.

Catatan

Timestamp data digunakan oleh Lindorm untuk menentukan apakah data perlu diarsipkan ke penyimpanan dingin. Lindorm membandingkan waktu saat ini dan timestamp data. Jika timestamp data adalah titik waktu tiga hari setelah waktu sistem saat ini, data diarsipkan ke penyimpanan dingin tiga hari lebih lambat daripada data yang timestamp-nya adalah waktu sistem saat ini. Jika timestamp data adalah titik waktu tiga hari sebelum waktu sistem saat ini dan batas data panas-dingin diatur menjadi tiga hari, data diarsipkan secara asinkron ke penyimpanan dingin setelah ditulis ke tabel.

Kueri Data

Lindorm menggunakan tabel yang sama untuk menyimpan data panas dan data dingin. Dengan cara ini, Anda dapat mengkueri semua data dalam satu tabel. Saat Anda mengkueri data, Anda dapat mengonfigurasi parameter TimeRange untuk menentukan rentang waktu untuk kueri. Lindorm menentukan apakah hanya akan mengkueri penyimpanan panas atau penyimpanan dingin, atau mengkueri kedua penyimpanan panas dan dingin berdasarkan rentang waktu yang Anda tentukan. Jika Anda tidak menentukan rentang waktu dalam kueri, data dingin mungkin akan dikueri. Dalam hal ini, throughput kueri dibatasi oleh spesifikasi penyimpanan dingin. Untuk informasi lebih lanjut, lihat Ikhtisar.

Jika Anda ingin mengkueri data di penyimpanan panas, Anda dapat menggunakan petunjuk _l_hot_only_ dalam kueri atau mengonfigurasi parameter HOT_ONLY untuk hanya mengkueri data di penyimpanan panas.

Penting
  • Data di penyimpanan dingin dimaksudkan untuk pengarsipan dan harus jarang diakses. Jika data di penyimpanan dingin sering diakses oleh banyak permintaan, periksa apakah batas data panas-dingin yang ditentukan oleh COLD_BOUNDARY dikonfigurasi dengan benar. Jika sejumlah besar data yang perlu sering dikueri diarsipkan ke penyimpanan dingin berdasarkan batas tersebut, kinerja kueri mungkin akan dibatasi.

  • Jika bidang dalam baris data yang disimpan di penyimpanan dingin diperbarui, bidang yang diperbarui disimpan di penyimpanan panas. Jika Anda menentukan parameter HOT_ONLY atau TimeRange untuk hanya mengkueri data di penyimpanan panas, hanya bidang yang diperbarui yang dikembalikan. Jika Anda ingin LindormTable mengembalikan data seluruh baris, Anda harus melakukan kueri tanpa menentukan parameter HOT_ONLY atau TimeRange, atau pastikan bahwa rentang waktu yang ditentukan oleh TimeRange mencakup periode waktu dari titik waktu saat baris dimasukkan hingga titik waktu saat baris terakhir diperbarui. Oleh karena itu, kami merekomendasikan agar Anda tidak memperbarui data yang disimpan di penyimpanan dingin.

Saat ini, metode GET dan SCAN didukung untuk mengkueri data.

Gunakan Metode GET untuk Mengkueri Data

  • Metode 1: Gunakan Apache HBase Shell untuk Mengkueri Data

    • Kueri data tanpa menentukan parameter HOT_ONLY. Dalam hal ini, data di penyimpanan dingin mungkin akan dikueri.

      HBase(main):013:0> get 'chsTable', 'row1'
    • Kueri data dengan menentukan parameter HOT_ONLY. Dalam hal ini, hanya data di penyimpanan panas yang dikueri.

      HBase(main):015:0> get 'chsTable', 'row1', {HOT_ONLY=>true}
    • Kueri data dengan menentukan parameter TimeRange. Lindorm membandingkan nilai TimeRange dan COLD_BOUNDARY untuk menentukan apakah hanya akan mengkueri penyimpanan panas atau penyimpanan dingin, atau mengkueri kedua penyimpanan panas dan dingin.

      HBase(main):016:0> get 'chsTable', 'row1', {TIMERANGE => [0, 1568203111265]}

      Parameter

      TimeRange: rentang waktu di mana kueri dilakukan. Waktu dalam rentang adalah timestamp UNIX yang mewakili jumlah milidetik yang telah berlalu sejak waktu epoch 1 Januari 1970, 00:00:00 UTC.

  • Metode 2: Gunakan ApsaraDB for HBase API for Java untuk Mengkueri Data

    • Kueri data tanpa menentukan parameter HOT_ONLY. Dalam hal ini, data di penyimpanan dingin mungkin akan dikueri.

      Get get = new Get("row1".getBytes());
      System.out.println("result: " + table.get(get));
    • Kueri data dengan menentukan parameter HOT_ONLY. Dalam hal ini, hanya data di penyimpanan panas yang dikueri.

      get = new Get("row1".getBytes());
      get.setAttribute(AliHBaseConstants.HOT_ONLY, Bytes.toBytes(true));
    • Kueri data dengan menentukan parameter TimeRange. Lindorm membandingkan nilai TimeRange dan COLD_BOUNDARY untuk menentukan apakah hanya akan mengkueri penyimpanan panas atau penyimpanan dingin, atau mengkueri kedua penyimpanan panas dan dingin.

      get = new Get("row1".getBytes());
      get.setTimeRange(0, 1568203111265)
  • Metode 3: Gunakan Lindorm SQL untuk Mengkueri Data

    SELECT /*+ _l_hot_only_ */ * FROM dt WHERE pk IN (1, 2, 3);

Gunakan Metode SCAN untuk Mengkueri Data dalam Rentang Tertentu

Catatan
  • Jika Anda tidak mengonfigurasi parameter HOT_ONLY dan TimeRange, atau nilai TimeRange mencakup timestamp data di penyimpanan dingin, Lindorm mengkueri data di penyimpanan dingin dan penyimpanan panas serta menggabungkan hasil kueri.

  • Hanya Apache HBase Shell dan ApsaraDB for HBase API for Java yang mendukung kueri dalam rentang tertentu.

  • Metode 1: Gunakan Apache HBase Shell untuk Mengkueri Data

    • Kueri data tanpa menentukan parameter HOT_ONLY. Dalam hal ini, data di penyimpanan dingin dikueri.

      Lindorm(main):017:0> scan 'chsTable', {STARTROW =>'row1', STOPROW=>'row9'}
    • Kueri data dengan menentukan parameter HOT_ONLY. Dalam hal ini, hanya data di penyimpanan panas yang dikueri.

      Lindorm(main):018:0> scan 'chsTable', {STARTROW =>'row1', STOPROW=>'row9', HOT_ONLY=>true}
    • Kueri data dengan menentukan parameter TimeRange. Lindorm membandingkan nilai TimeRange dan COLD_BOUNDARY untuk menentukan apakah hanya akan mengkueri penyimpanan panas atau penyimpanan dingin, atau mengkueri kedua penyimpanan panas dan dingin.

      Lindorm(main):019:0> scan 'chsTable', {STARTROW =>'row1', STOPROW=>'row9', TIMERANGE => [0, 1568203111265]}
  • Metode 2: Gunakan ApsaraDB for HBase API for Java untuk Mengkueri Data

    TableName tableName = TableName.valueOf("chsTable");
    Table table = connection.getTable(tableName);
    // Dalam contoh ini, parameter HOT_ONLY tidak dikonfigurasi. Data di penyimpanan dingin dikueri.
    Scan scan = new Scan();
    ResultScanner scanner = table.getScanner(scan);
    for (Result result : scanner) {
        System.out.println("scan result:" + result);
    }
    // Dalam contoh ini, parameter HOT_ONLY dikonfigurasi. Hanya data di penyimpanan panas yang dikueri.
    scan = new Scan();
    scan.setAttribute(AliLindormConstants.HOT_ONLY, Bytes.toBytes(true));
    // Dalam contoh ini, parameter TimeRange dikonfigurasi. Lindorm membandingkan nilai TimeRange dan COLD_BOUNDARY untuk menentukan apakah hanya akan mengkueri penyimpanan panas atau penyimpanan dingin, atau mengkueri kedua penyimpanan panas dan dingin.
    scan = new Scan();
    scan.setTimeRange(0, 1568203111265);

Prioritaskan Kueri Data Panas

Dalam kueri SCAN yang dilakukan untuk mengkueri informasi seperti semua pesanan atau catatan obrolan pelanggan, LindormTable mungkin memindai data di penyimpanan panas dan penyimpanan dingin. Hasil kueri dipaginasi berdasarkan timestamp saat baris data ditulis ke tabel dalam urutan menurun. Dalam kebanyakan kasus, data panas muncul sebelum data dingin. Jika Anda tidak mengonfigurasi parameter HOT_ONLY dalam kueri SCAN, LindormTable memindai data panas dan data dingin. Akibatnya, waktu respons kueri meningkat. Jika Anda mengaktifkan fitur prioritas data panas, LindormTable memprioritaskan kueri data di penyimpanan panas. Data di penyimpanan dingin hanya dikueri ketika jumlah barisdi penyimpanan panas kurang dari jumlah minimum baris data yang akan dikueri. Dengan cara ini, akses ke data di penyimpanan dingin berkurang dan kecepatan respons meningkat.

Catatan

Anda hanya dapat menggunakan Apache HBase Shell atau ApsaraDB for HBase API for Java untuk memprioritaskan kueri data panas.

  • Metode 1: Gunakan Apache HBase Shell untuk Mengkueri Data

    Lindorm(main):002:0> scan 'chsTable', {COLD_HOT_MERGE=>true}

    Parameter

    COLD_HOT_MERGE: Menentukan apakah akan mengaktifkan fitur prioritas data panas.

    • true: aktifkan fitur prioritas data panas. Saat parameter COLD_HOT_MERGE diatur menjadi true, LindormTable memprioritaskan memindai data panas. LindormTable hanya memindai data dingin ketika jumlah baris data di penyimpanan panas kurang dari jumlah baris yang ingin Anda kueri.

    • false: nonaktifkan fitur prioritas data panas.

  • Metode 2: Gunakan ApsaraDB for HBase API for Java untuk Mengkueri Data

    scan = new Scan();
    scan.setAttribute(AliHBaseConstants.COLD_HOT_MERGE, Bytes.toBytes(true));
    scanner = table.getScanner(scan);

Catatan Penggunaan

  • Dalam skenario di mana data di bidang tertentu dari baris diperbarui, baris menyimpan data panas dan data dingin pada saat yang bersamaan. Jika Anda mengaktifkan fitur prioritas data panas, hasil kueri dikembalikan dalam dua batch. Anda dapat menemukan dua hasil dengan kunci baris yang sama dalam set hasil.

  • Setelah Anda mengaktifkan fitur prioritas data panas, data panas dikembalikan sebelum data dingin. Oleh karena itu, nilai kunci baris dari baris dingin tertentu yang dikembalikan mungkin lebih kecil daripada nilai kunci baris dari baris panas tertentu yang dikembalikan karena LindormTable mengembalikan data panas sebelum data dingin. Hasil yang dikembalikan untuk kueri SCAN tidak diurutkan secara berurutan. Baris data panas dan baris data dingin diurutkan secara terpisah berdasarkan nilai kunci baris. Untuk informasi lebih lanjut tentang bagaimana baris yang dikembalikan diurutkan, lihat hasil sampel berikut. Dalam beberapa skenario, Anda dapat menentukan kunci baris untuk memastikan urutan hasil kueri SCAN. Misalnya, jika Anda menggunakan tabel untuk menyimpan informasi tentang pesanan yang dibuat pelanggan Anda, Anda dapat menentukan kunci baris yang terdiri dari kolom yang menyimpan ID pelanggan dan kolom yang menyimpan waktu pembuatan pesanan. Dengan cara ini, ketika Anda mengkueri pesanan yang dibuat oleh pelanggan, pesanan yang dikembalikan diurutkan berdasarkan titik waktu saat pesanan dibuat.

    // Dalam contoh berikut, baris dengan nilai kunci baris coldRow menyimpan data dingin dan baris dengan nilai kunci baris hotRow menyimpan data panas.
    // Dalam kebanyakan kasus, baris coldRow dikembalikan sebelum baris hotRow karena baris di Lindorm diurutkan dalam urutan leksikografis. 
    HBase(main):001:0> scan 'chsTable'
    ROW                                                                COLUMN+CELL
     coldRow                                                              column=f:value, timestamp=1560578400000, value=cold_value
     hotRow                                                               column=f:value, timestamp=1565848800000, value=hot_value
    2 row(s)
    
    // Jika Anda mengatur nilai parameter COLD_HOT_MERGE menjadi true, LindormTable memindai baris dengan nilai kunci baris hotRow terlebih dahulu. Akibatnya, baris hotRow dikembalikan sebelum baris coldRow.
    HBase(main):002:0> scan 'chsTable', {COLD_HOT_MERGE=>true}
    ROW                                                                COLUMN+CELL
     hotRow                                                               column=f:value, timestamp=1565848800000, value=hot_value
     coldRow                                                              column=f:value, timestamp=1560578400000, value=cold_value
    2 row(s)

FAQ

  • P: Apakah baris data dingin tetap menjadi data dingin setelah diperbarui?

    J: Tidak. Setelah baris data dingin diperbarui, timestamp baris tersebut diperbarui. Oleh karena itu, data dingin menjadi data panas.

  • P: Mengapa data dingin dikembalikan untuk kueri saya meskipun saya ingin mengkueri hanya data panas?

    J: Anda dapat mengonfigurasi parameter HOT_ONLY atau petunjuk _l_hot_only_ untuk mengkueri hanya data panas. Data secara berkala diarsipkan ke penyimpanan dingin berdasarkan timestamp-nya. Oleh karena itu, beberapa data dingin mungkin belum diarsipkan ke penyimpanan dingin saat Anda mengkueri data tersebut. Dalam hal ini, data dingin akan dikembalikan. Untuk menyelesaikan masalah ini, Anda dapat menentukan rentang waktu untuk data panas yang ingin Anda kueri. Contoh berikut menunjukkan cara menggunakan fungsi ini:

    // Anda harus menggunakan petunjuk _l_ts_min_ dan _l_ts_max_ untuk menentukan rentang waktu. Petunjuk _l_ts_min_ menunjukkan selisih antara waktu sistem saat ini dan batas data panas-dingin. Petunjuk _l_ts_max_ menunjukkan waktu sistem saat ini. Satuan petunjuk harus sama.
    SELECT /*+ _l_hot_only_(true), _l_ts_min_(1000), _l_ts_max_(2001) */ * FROM test WHERE p1>1;
  • P: Mengapa kueri saya habis waktu meskipun saya menentukan rentang waktu dan menggunakan petunjuk HOT_ONLY dalam kueri saya?

    J: Masalah ini umumnya terjadi setelah Anda memigrasi data ke tabel atau mengaktifkan pemisahan panas-dingin untuk tabel. Dalam hal ini, data dingin belum sepenuhnya diarsipkan ke penyimpanan dingin dan sejumlah besar data dingin masih disimpan di penyimpanan panas. Oleh karena itu, kueri mungkin habis waktu. Untuk menyelesaikan masalah ini, Anda harus melakukan operasi major compaction pada tabel. Untuk informasi lebih lanjut tentang sintaks yang digunakan untuk melakukan operasi ini, lihat ALTER TABLE.