Kebijakan dan metode untuk penyimpanan data panas dan dingin - AnalyticDB

AnalyticDB for MySQL mendukung penyimpanan bertingkat data panas dan dingin. Anda dapat memindahkan data panas dan dingin ke media penyimpanan yang berbeda untuk memastikan kinerja query tinggi pada data panas dan mengurangi biaya penyimpanan data dingin.

Ikhtisar

Dalam skenario data besar, tabel bisnis sering kali berisi volume data yang signifikan, seperti data log, data pesanan, atau data pemantauan. Seiring waktu, sebagian data menjadi jarang diakses dan dianggap sebagai data dingin. Namun, data ini tetap menempati ruang penyimpanan, sehingga meningkatkan biaya penyimpanan.

AnalyticDB for MySQL menyediakan solusi penyimpanan bertingkat data panas dan dingin untuk tabel yang dipartisi berdasarkan tanggal dan waktu. Kluster AnalyticDB for MySQL mengurutkan partisi secara menurun berdasarkan jumlah partisi panas yang ditentukan dan nilai kunci partisi. N partisi terbesar dianggap sebagai partisi panas, sementara sisanya dianggap sebagai partisi dingin. Data dari partisi dingin dapat dipindahkan ke Object Storage Service (OSS) yang lebih hemat biaya untuk mengurangi biaya penyimpanan. Data dari partisi panas tetap berada di SSD untuk memastikan kinerja query tinggi.

Prasyarat

Sebelum menggunakan fitur penyimpanan bertingkat data panas dan dingin dalam kluster AnalyticDB for MySQL, pastikan persyaratan berikut terpenuhi:

Kluster harus berupa Enterprise Edition, Basic Edition, Data Lakehouse Edition, atau Data Warehouse Edition dalam mode elastis.

Versi minor kluster harus 3.1.3.3 atau lebih baru.
Catatan
Untuk melihat dan memperbarui versi minor kluster AnalyticDB for MySQL, masuk ke konsol AnalyticDB for MySQL dan buka bagian Configuration Information pada halaman Cluster Information.

Aturan penagihan

Saat menggunakan kluster, Anda akan dikenakan biaya untuk penyimpanan data panas dan dingin berdasarkan metode penagihan bayar sesuai pemakaian. Untuk informasi lebih lanjut, lihat Harga.

Catatan

Anda dapat menggunakan rencana penyimpanan untuk mengimbangi biaya penyimpanan data di AnalyticDB for MySQL.

Kebijakan penyimpanan data panas dan dingin

AnalyticDB for MySQL menyediakan tiga kebijakan untuk penyimpanan data panas dan dingin: penyimpanan dingin, penyimpanan panas, dan penyimpanan campuran.

Penyimpanan dingin adalah kebijakan hemat biaya. Saat menggunakan kebijakan ini, semua data disimpan di OSS dalam mode penyimpanan zona redundan (ZRS).
Penyimpanan panas adalah kebijakan yang memenuhi persyaratan kinerja akses tinggi. Saat menggunakan kebijakan ini, semua data disimpan di SSD. Kebijakan ini memberikan kinerja query terbaik tetapi memiliki biaya penyimpanan tertinggi.
Penyimpanan campuran memungkinkan partisi panas disimpan di SSD dan partisi dingin disimpan di OSS. Kebijakan ini memastikan kinerja query tinggi pada partisi panas dan mengurangi biaya penyimpanan partisi dingin. Berikut adalah prinsip kebijakan penyimpanan campuran:
Saat menggunakan kebijakan penyimpanan campuran, Anda harus menentukan jumlah partisi panas. Partisi diurutkan berdasarkan nilai kunci partisi secara menurun. Jika jumlah partisi panas diatur menjadi N, N partisi pertama yang disimpan di SSD adalah partisi panas, dan sisanya yang disimpan di OSS adalah partisi dingin. Distribusi partisi panas dan dingin mungkin berubah saat jumlah partisi berubah. Untuk informasi lebih lanjut, lihat bagian "Dampak Perubahan Jumlah Partisi terhadap Distribusi Partisi Panas dan Dingin" dari topik ini.

Dampak perubahan jumlah partisi terhadap distribusi partisi panas dan dingin

Anggaplah jumlah partisi panas adalah N. Saat partisi baru dimasukkan, semua partisi diurutkan ulang untuk memastikan hanya ada N partisi panas.
Klik untuk melihat diagram
Seperti ditunjukkan pada gambar berikut, jumlah partisi panas diatur menjadi 5, dan partisi baru 20241226 dimasukkan ke dalam tabel. Partisi ini memiliki nilai kunci partisi terbesar di antara semua partisi tabel. Setelah pekerjaan BUILD, partisi ini harus ditempatkan di antara partisi panas. Untuk memastikan bahwa jumlah partisi panas adalah 5, sistem memindahkan partisi 20241221 yang memiliki nilai kunci partisi terkecil dari partisi panas ke partisi dingin dan menempatkan partisi 20241226 di antara partisi panas.
Anggaplah jumlah partisi panas adalah N dan Anda ingin mengubah jumlah partisi panas menjadi M.
- Jika M lebih besar dari N, data dari M - N partisi dipindahkan dari partisi dingin ke partisi panas.
  Klik untuk melihat diagram
  Seperti ditunjukkan pada gambar berikut, jumlah partisi panas diubah dari 5 menjadi 6. Dengan cara ini, sistem memindahkan partisi 20241220 yang memiliki nilai kunci partisi terbesar dari partisi dingin ke partisi panas.
- Jika M lebih kecil dari N, data dari N - M partisi dipindahkan dari partisi panas ke partisi dingin.
  Klik untuk melihat diagram
  Sebagai contoh, jumlah partisi panas diubah dari 5 menjadi 4. Dengan cara ini, sistem memindahkan partisi 20241221 yang memiliki nilai kunci partisi terkecil dari partisi panas ke partisi dingin.

Tentukan kebijakan penyimpanan data panas dan dingin

Saat Anda membuat tabel, Anda dapat menentukan kebijakan penyimpanan data panas dan dingin dengan menggunakan parameter storage_policy.
Untuk tabel yang sudah ada, Anda dapat menentukan kebijakan penyimpanan data panas dan dingin dengan menjalankan pernyataan ALTER TABLE.

Kueri kebijakan penyimpanan data panas dan dingin

Sintaksis

Mengkueri kebijakan penyimpanan data panas dan dingin untuk semua tabel.
```
SELECT * FROM information_schema.table_usage;
```

Mengkueri kebijakan penyimpanan data panas dan dingin untuk tabel tertentu.

SELECT * FROM information_schema.table_usage WHERE table_schema='<schema_name>' AND table_name='<table_name>';

Parameter respons

Parameter	Deskripsi
table_schema	Nama database.
table_name	Nama tabel.
storage_policy	Kebijakan penyimpanan. Nilai valid: HOT COLD MIXED
hot_partition_count	Jumlah partisi panas.
cold_partition_count	Jumlah partisi dingin.
rt_total_size	Total ukuran data real-time, yaitu jumlah parameter rt_data_size dan rt_index_size. Satuan: byte.
rt_data_size	Ukuran data real-time. Satuan: byte.
rt_index_size	Ukuran data kunci utama dan indeks dalam data real-time. Satuan: byte.
hot_total_size	Total ukuran data dalam partisi panas, yaitu jumlah parameter hot_data_size dan hot_index_size. Satuan: byte.
hot_data_size	Ukuran data dalam partisi panas. Satuan: byte.
hot_index_size	Ukuran data kunci utama dan indeks dalam partisi panas. Satuan: byte.
cold_total_size	Total ukuran data dalam partisi dingin, yaitu jumlah parameter cold_data_size dan cold_index_size. Satuan: byte.
cold_data_size	Ukuran data dalam partisi dingin. Satuan: byte.
cold_index_size	Ukuran data kunci utama dan indeks dalam partisi dingin. Satuan: byte.

Catatan:

Nilai parameter rt_total_size, rt_data_size, rt_index_size, hot_total_size, hot_data_size, hot_index_size, cold_total_size, cold_data_size, dan cold_index_size bervariasi berdasarkan eksekusi pernyataan INSERT, UPDATE, DELETE, dan BUILD.
Jika nilai parameter hot_total_size dan cold_total_size keduanya 0 setelah Anda menulis data, data disinkronkan secara real-time. Parameter rt_total_size menunjukkan ukuran data real-time. Anda dapat menjalankan pernyataan BUILD untuk mengonversi data real-time menjadi data historis. Setelah pekerjaan BUILD selesai, Anda dapat melihat parameter hot_total_size dan cold_total_size.
Parameter hot_partition_count yang ditentukan menentukan jumlah partisi panas dalam satu shard, sedangkan parameter hot_partition_count yang dikueri menunjukkan jumlah partisi panas setelah shard digabungkan. Jika partisi data didistribusikan secara berbeda di seluruh shard, nilai parameter hot_partition_count yang dikueri mungkin lebih besar dari nilai parameter hot_partition_count yang ditentukan.
Sebagai contoh, Tabel A berisi Shard 1 dan Shard 2, dan hot_partition_count diatur menjadi 2. Gambar berikut menunjukkan distribusi partisi data di Tabel A.
Shard 1: P4 dan P5 adalah partisi panas. P1, P2, dan P3 adalah partisi dingin.
Shard 2: P3 dan P4 adalah partisi panas. P1 dan P2 adalah partisi dingin.
Jumlah sebenarnya dari partisi panas dihitung dengan menggunakan rumus berikut: (P4, P5) Union (P3, P4) = (P3, P4, P5). Oleh karena itu, nilai sebenarnya dari parameter hot_partition_count adalah 3.

Kueri kemajuan perubahan kebijakan penyimpanan data panas dan dingin

Setelah Anda mengubah kebijakan penyimpanan data panas dan dingin dengan menjalankan pernyataan ALTER TABLE, Anda dapat mengkueri kemajuan perubahan kebijakan penyimpanan dari tabel storage_policy_modify_progress.

Sintaksis

Mengkueri kemajuan perubahan kebijakan penyimpanan data panas dan dingin untuk semua tabel.
```
SELECT * FROM information_schema.storage_policy_modify_progress;
```

Mengkueri kemajuan perubahan kebijakan penyimpanan data panas dan dingin untuk tabel tertentu.

SELECT * FROM information_schema.storage_policy_modify_progress WHERE table_schema='<schema_name>' AND table_name='<table_name>';

Parameter respons

Parameter	Deskripsi
table_schema	Nama database.
table_name	Nama tabel.
task_id	ID pekerjaan perubahan kebijakan penyimpanan.
source_storage_policy	Kebijakan penyimpanan asli. Nilai valid: HOT COLD MIXED
source_hot_partition_count	Jumlah partisi panas asli.
dest_storage_policy	Kebijakan penyimpanan baru. Nilai valid: HOT COLD MIXED
dest_hot_partition_count	Jumlah partisi panas baru.
hot_to_cold_partition_count	Jumlah partisi yang diubah dari partisi panas menjadi partisi dingin.
cold_to_hot_partition_count	Jumlah partisi yang diubah dari partisi dingin menjadi partisi panas.
hot_to_cold_data_size	Ukuran data yang diubah dari partisi panas menjadi partisi dingin. Satuan: byte.
cold_to_hot_data_size	Ukuran data yang dipindahkan dari partisi hot ke partisi cold. Satuan: byte.
hot_data_size_before_change	Ukuran data panas sebelum kebijakan penyimpanan diubah. Satuan: byte.
cold_data_size_before_change	Ukuran data dingin sebelum kebijakan penyimpanan diubah. Satuan: byte.
hot_data_size_after_change	Ukuran data panas setelah kebijakan penyimpanan diubah. Satuan: byte.
cold_data_size_after_change	Ukuran data dingin setelah kebijakan penyimpanan diubah. Satuan: byte.
start_time	Awal rentang waktu ketika kebijakan penyimpanan diubah.
update_time	Akhir rentang waktu ketika kebijakan penyimpanan diubah.
progress	Kemajuan perubahan kebijakan penyimpanan. Satuan: %.
status	Status perubahan kebijakan penyimpanan. Nilai valid: INIT: Tidak ada perubahan yang dimulai. RUNNING: Perubahan sedang berlangsung. FINISH: Perubahan selesai.