Kebijakan partisi data dan cara menggunakannya - Lindorm

Pengindeksan partisi adalah fitur yang dirancang untuk mengatasi tantangan penyimpanan dan akses konkurensi tinggi pada tabel lebar besar. Saat membuat indeks pencarian, Anda dapat menentukan kebijakan partisi data. Server kemudian secara otomatis membagi dan menyimpan data tersebut. Selama kueri, sistem secara otomatis melakukan pemangkasan partisi. Topik ini menjelaskan kebijakan partisi data dan cara menggunakannya.

Prasyarat

Anda telah mengaktifkan fitur indeks pencarian.
Anda telah terhubung ke mesin tabel lebar menggunakan Lindorm-cli.

Skenario

Lindorm search index menyediakan dua kebijakan partisi: partisi hash dan partisi berdasarkan waktu. Pilih kebijakan yang sesuai berdasarkan skenario bisnis berikut.

Partisi hash
- Pemangkasan partisi saat kueri: Jika kondisi kueri Anda selalu mencakup kueri kesetaraan pada kolom tertentu, pertimbangkan menggunakan partisi hash pada kolom tersebut. Metode ini memastikan bahwa nilai yang identik selalu diarahkan ke grup partisi yang sama. Selama kueri, pemangkasan partisi memungkinkan pengambilan data hanya dari partisi-partisi yang berisi nilai kueri tersebut. Misalnya, pada tabel perangkat, jika kondisi kueri selalu mencakup ID perangkat, tetapkan kolom ID perangkat sebagai kunci partisi hash.
- Penyimpanan partisi yang seimbang: Saat memilih kunci partisi hash, pertimbangkan juga distribusi data. Jika kunci partisi yang dipilih menyebabkan titik panas data (data hot spots), gunakan fitur partisi hash multi-level untuk mendistribusikan data lebih merata ke beberapa partisi.
Partisi berdasarkan waktu
- Pemangkasan partisi saat kueri: Jika data bisnis Anda memiliki atribut waktu—seperti data dari Internet of Vehicles (IoV), detail pesanan, atau log pesan—dan kueri Anda sering menggunakan rentang waktu, gunakan partisi berdasarkan waktu. Misalnya, Anda mungkin melakukan kueri data pesanan dari 7 hari terakhir atau bulan lalu. Fitur ini mempersempit cakupan kueri ke shard tertentu berdasarkan rentang waktu yang ditentukan.
- Mengontrol batas penyimpanan satu shard: Jika satu indeks atau shard menyimpan volume data yang sangat besar, performa penulisan dan kueri dapat terpengaruh. Jika data indeks Anda tumbuh dengan cepat, gunakan kebijakan partisi berdasarkan waktu untuk mengontrol jumlah data dalam satu shard.

Persiapan

Sebelum menggunakan pengindeksan partisi, buat tabel uji menggunakan pernyataan berikut:

CREATE TABLE IF NOT EXISTS search_table (user_id BIGINT, storeId VARCHAR, goodsId VARCHAR, goodsPrice SMALLINT, orderTime BIGINT, info VARCHAR, PRIMARY KEY (user_id asc));

Partisi hash

Lindorm search index mendukung hingga tiga level partisi. Konfigurasi partisi hash tidak dapat diubah setelah dibuat. Contoh berikut menunjukkan sintaks untuk partisi hash.

Partisi primer

Buat indeks pencarian. Secara default, partisi hash didasarkan pada kunci primer tabel lebar. Jumlah partisi default adalah dua kali jumlah node pencarian.
```
CREATE INDEX IF NOT EXISTS idx USING SEARCH ON search_table (storeId, goodsId, goodsPrice);
```
Buat indeks pencarian dengan partisi hash pada kolom storeId dan 64 partisi. Klausul PARTITION BY hash(storeId) menentukan storeId sebagai kunci partisi, sedangkan klausul partitions 64 menetapkan jumlah partisi menjadi 64.
```
CREATE INDEX IF NOT EXISTS idx USING SEARCH ON search_table (storeId, goodsId, goodsPrice) PARTITION BY hash(storeId) PARTITIONS 64;
```
Catatan
Saat menggunakan partisi hash, perkirakan jumlah partisi yang diperlukan berdasarkan volume data. Satu partisi idealnya berisi 50 juta hingga 100 juta catatan dengan ukuran penyimpanan 30 GB hingga 50 GB.

Partisi multi-level

Jika volume total data indeks sangat besar (puluhan miliar catatan atau lebih) dan kunci partisi primer menyebabkan distribusi data yang tidak merata, gunakan partisi multi-level untuk mengoptimalkan distribusi data.

Penting

Mesin tabel lebar harus versi 2.8.1 atau lebih baru. Mesin pencarian harus versi 3.9.22 atau lebih baru.
Partisi multi-level tidak dapat digunakan bersamaan dengan partisi berdasarkan waktu.

Buat indeks pencarian dengan partisi hash berdasarkan kolom storeId dan goodsId dari tabel lebar. Tetapkan faktor salt (salt_factor) untuk kolom-kolom ini masing-masing menjadi 2 dan 4. Klausul partitions 64 menetapkan jumlah total partisi menjadi 64.
```
CREATE INDEX IF NOT EXISTS idx USING SEARCH ON search_table (storeId, goodsId, goodsPrice) PARTITION BY hash(storeId(salt_factor=2), goodsId(salt_factor=4)) partitions 64;
```
Catatan
Faktor salt partisi (salt_factor) adalah bilangan bulat kecil yang mengontrol tingkat penghashan untuk nilai-nilai kunci partisi yang berbeda. Ikuti langkah-langkah berikut untuk menentukan jumlah total partisi dan faktor salt untuk setiap kunci partisi:
1. Perkirakan jumlah partisi yang diperlukan berdasarkan volume total data. Kemudian, pilih pangkat dari 2 ( $2^{N}$ ) yang mendekati perkiraan Anda sebagai jumlah total partisi. Misalnya, jika volume total data adalah 2 miliar entri dan setiap partisi berisi sekitar 50 juta entri, Anda memerlukan sekitar 40 partisi. Dalam kasus ini, pilih $64 = 2^{6}$ sebagai jumlah total partisi.
2. Jika jumlah total partisi adalah $2^{6}$ , jumlah faktor salt untuk semua kunci partisi harus 6. Anda dapat menetapkan faktor salt untuk mengontrol rentang penghashan untuk kunci partisi yang berbeda.
  Sebagai contoh, jika faktor salt untuk storeId adalah 2 dan faktor salt untuk goodsId adalah 4, data dengan nilai storeId yang sama tetapi nilai goodsId yang berbeda akan didistribusikan ke $1/ 2^{2} = 1/4$ dari total partisi. Jika faktor salt untuk storeId adalah 3 dan faktor salt untuk goodsId adalah 3, data dengan nilai storeId yang sama tetapi nilai goodsId yang berbeda akan didistribusikan ke $1/ 2^{3} = 1/8$ dari total partisi.
Buat indeks partisi dengan _id sebagai kunci partisi sekunder.
Catatan
Jika kunci partisi primer menyebabkan distribusi data yang tidak merata dan tidak tersedia kunci partisi sekunder yang sesuai untuk bisnis Anda, tentukan _id sebagai kunci partisi sekunder. `_id` berkorespondensi dengan kunci primer komposit dari tabel lebar.
```
CREATE INDEX IF NOT EXISTS idx USING SEARCH ON search_table (storeId, goodsId, goodsPrice) PARTITION BY hash(storeId(salt_factor=2), _id(salt_factor=4)) partitions 64;
```

Partisi berdasarkan waktu

Untuk data deret waktu, seperti data pesanan atau log pesan, Anda dapat menentukan kolom waktu untuk mempartisi data berdasarkan rentang waktu. Misalnya, Anda dapat mempartisi data berdasarkan minggu atau bulan. Data dalam rentang waktu yang sama disimpan dalam partisi yang sama, dan data dalam partisi lama dapat dihapus secara otomatis berdasarkan kebijakan TTL.

Buat indeks dan partisikan berdasarkan kolom waktu bisnis orderTime. RANGE_TIME_PARTITION_START='30' menentukan bahwa partisi dibuat mulai dari 30 hari yang lalu. RANGE_TIME_PARTITION_INTERVAL='7' secara otomatis membuat partisi baru setiap 7 hari. RANGE_TIME_PARTITION_TTL='90' menetapkan Time to Live (TTL) default untuk data partisi menjadi 90 hari. Data yang lebih tua dari 90 hari akan dihapus secara otomatis.
```
CREATE INDEX idx USING SEARCH ON search_table (storeId, goodsId, goodsPrice, orderTime)
PARTITION BY RANGE time(orderTime) partitions 4
WITH (
  indexState=ACTIVE, 
  RANGE_TIME_PARTITION_START='30',
  RANGE_TIME_PARTITION_INTERVAL='7',
  RANGE_TIME_PARTITION_TTL='90'
);
```
Penting
Parameter RANGE_TIME_PARTITION_START mengontrol waktu mulai untuk partisi. Parameter ini menentukan jumlah hari sebelum tanggal saat ini dari mana pembuatan partisi dimulai.
Sebagai contoh, asumsikan tanggal paling awal dalam kolom `orderTime` adalah 16 Maret 2021. Untuk menyimpan semua data historis, hitung jumlah hari antara 16 Maret 2021 dan hari saat Anda membuat indeks. Kemudian, tetapkan angka tersebut sebagai nilai parameter RANGE_TIME_PARTITION_START. Setelah waktu mulai ditetapkan, catatan dengan nilai `orderTime` yang lebih awal dari waktu mulai tidak akan diindeks.

Buat indeks yang dipartisi berdasarkan kolom waktu bisnis orderTime, dengan partisi baru dibuat secara otomatis setiap bulan mulai dari enam bulan yang lalu. Secara default, data disimpan selama enam bulan dan satuan untuk bidang partisi diatur ke detik (s).

CREATE INDEX idx USING SEARCH ON search_table (storeId, goodsId, goodsPrice, orderTime)
partition by range time(orderTime) partitions 4 
with (
  indexState=ACTIVE,
  RANGE_TIME_PARTITION_START='180',
  RANGE_TIME_PARTITION_INTERVAL='30',
  RANGE_TIME_PARTITION_TTL='180',
  RANGE_TIME_PARTITION_FIELD_TIMEUNIT='s'
);

Tabel berikut menjelaskan parameter untuk partisi berdasarkan rentang waktu.

Parameter	Wajib	Deskripsi
RANGE_TIME_PARTITION_START	Ya	Menentukan jumlah hari sebelum pembuatan indeks untuk mulai membuat partisi. Ini berlaku untuk skenario dengan data historis. Jika stempel waktu data historis lebih awal dari waktu mulai partisi, kesalahan akan dilaporkan.
RANGE_TIME_PARTITION_INTERVAL	Ya	Menentukan interval dalam hari untuk membuat partisi baru. Misalnya, `RANGE_TIME_PARTITION_INTERVAL='7'` berarti partisi baru dibuat setiap minggu.
RANGE_TIME_PARTITION_TTL	Tidak	Menentukan jumlah hari untuk menyimpan data partisi. Misalnya, `RANGE_TIME_PARTITION_TTL='180'` berarti data partisi disimpan selama enam bulan. Data partisi historis akan dihapus secara otomatis.
RANGE_TIME_PARTITION_FIELD_TIMEUNIT	Tidak	Menentukan satuan bidang partisi waktu untuk bisnis Anda. Satuan default adalah milidetik (ms). Jika satuan diatur ke detik (s), angkanya terdiri dari 10 digit. Jika satuan diatur ke milidetik (ms), angkanya terdiri dari 13 digit.
RANGE_TIME_PARTITION_MAX_OVERLAP	Tidak	Jika data yang sedang ditulis memiliki stempel waktu masa depan, parameter ini menentukan interval maksimum yang diizinkan antara stempel waktu masa depan dan waktu saat ini, dalam satuan hari. Jika tidak ditentukan, tidak ada batasan.
RANGE_TIME_PARTITION_FORMAT	Tidak	Menentukan format penulisan bidang partisi waktu untuk bisnis Anda. Nilai default adalah `date_optional_time\|\|epoch_millis`. Parameter ini berlaku ketika bidang partisi waktu dalam tabel utama bertipe VARCHAR.