Diagnostik Penyimpanan - AnalyticDB

Diagnostik Penyimpanan membantu Anda mengidentifikasi kesenjangan data, kunci partisi yang tidak optimal, indeks berlebihan, serta masalah konfigurasi tabel lainnya di kluster AnalyticDB for MySQL. Pada halaman Storage Diagnostics, Anda dapat mengevaluasi kesesuaian kunci partisi, kunci distribusi, dan tabel replikasi, serta mengidentifikasi peluang pemisahan data panas dan dingin serta menerima saran optimasi indeks. Dengan menerapkan saran tersebut, Anda dapat mengoptimalkan skema database, mengurangi biaya kluster, dan meningkatkan efisiensi.

Catatan penting

Optimasi tabel panas-dingin dan diagnostik indeks hanya didukung pada kluster yang menjalankan Milvus versi 3.1.4 atau lebih baru.
Saran optimasi untuk optimasi tabel panas-dingin dan diagnostik indeks didasarkan pada analisis historis pola data dan kueri. Saran ini tetap efektif selama pola data dan kueri stabil. Jika pola tersebut berubah secara signifikan, efektivitas saran akan berkurang. Sebelum menggunakan fitur ini, Anda harus mengevaluasi apakah saran tersebut sesuai dengan workload bisnis Anda saat ini.

Diagnostik tabel

Diagnosis kesenjangan data

Saat Anda membuat tabel, gunakan DISTRIBUTED BY HASH untuk menentukan kunci distribusi. Setelah kunci distribusi ditentukan, AnalyticDB for MySQL menghitung hash dari nilai kunci distribusi dan mendistribusikan baris ke berbagai shard. Distribusi data yang tidak merata di node penyimpanan menyebabkan ketimpangan penggunaan ruang disk, yang dapat mengisi disk lebih awal dan memblokir penulisan data.

Kriteria diagnosis

AnalyticDB for MySQL mendiagnosis kesenjangan data untuk tabel yang memiliki lebih dari 10.000 baris. Metode perhitungannya sebagai berikut:

Kecualikan shard terbesar dan hitung ukuran rata-rata shard.
Jika ada shard yang lebih besar dari ukuran rata-rata shard × ambang batas atau lebih kecil dari ukuran rata-rata shard / ambang batas, tabel tersebut dianggap miring. Ambang batas default adalah 3, dan rentang validnya [0, 10000000000]. Anda dapat menyesuaikan ambang batas dengan menjalankan perintah berikut: SET ADB_CONFIG RC_DATA_SKEW_THRESHOLD=Value;.

Prosedur

Masuk ke Konsol AnalyticDB for MySQL. Di pojok kiri atas konsol, pilih wilayah. Di panel navigasi sebelah kiri, klik Clusters. Temukan kluster yang ingin Anda kelola dan klik ID kluster tersebut.
Di panel navigasi sebelah kiri, pilih Storage Analysis > Storage Diagnostics.
Klik tab Table Diagnostics untuk melihat detail di bagian Table Skew Diagnostics.
Storage Node Disk Usage
Gunakan grafik untuk memeriksa penggunaan disk di seluruh storage node dan mengidentifikasi ketimpangan ruang disk. Jika terjadi ketimpangan, optimalkan tabel miring yang tercantum di bawah Top 10 Skewed Tables. Bahkan jika ruang disk tampak seimbang tetapi tabel miring muncul di Top 10 Skewed Tables, optimalkan tabel tersebut untuk menghindari penurunan performa kueri kluster.
Top 10 Skewed Tables
Bagian ini mencantumkan tabel dengan kesenjangan data, diurutkan berdasarkan total volume data dari yang terbesar ke terkecil. Untuk melihat jumlah baris per shard dan menilai tingkat kesenjangan, klik View Skew Details di kolom Actions.

Metode optimasi

Anda dapat mengatasi masalah ini dengan salah satu metode berikut:

Tingkatkan kapasitas penyimpanan.
- Kluster Enterprise Edition memerlukan penskalaan sumber daya reserved. Untuk informasi selengkapnya, lihat Scale an Enterprise Edition cluster.
- Kluster Basic Edition memerlukan penskalaan sumber daya komputasi. Untuk informasi selengkapnya, lihat Scale a Basic Edition cluster.
- Kluster Data Lakehouse Edition memerlukan penskalaan sumber daya penyimpanan reserved. Untuk informasi selengkapnya, lihat Scale a Data Lakehouse Edition cluster.
- Kluster Data Warehouse Edition (elastic mode) memerlukan penskalaan elastic I/O unit. Untuk informasi selengkapnya, lihat Scale a Data Warehouse Edition (elastic mode) cluster.
- Kluster Data Warehouse Edition (reserved mode) memerlukan penskalaan node groups. Untuk informasi selengkapnya, lihat Scale a Data Warehouse Edition (reserved mode) cluster.
Hapus indeks atau partisi yang tidak aktif untuk mengurangi penggunaan penyimpanan. Untuk informasi selengkapnya, lihat Index diagnostics.
Buat ulang tabel dan migrasikan datanya. Untuk informasi selengkapnya, lihat CREATE TABLE.

Optimasi tabel panas dan dingin

AnalyticDB for MySQL menganalisis frekuensi akses tabel untuk mengidentifikasi tabel yang jarang diakses dan memberikan saran optimasi. Anda dapat menerapkan saran tersebut untuk menyesuaikan kebijakan pemisahan data panas dan dingin pada tabel Anda. Untuk informasi selengkapnya tentang pemisahan data panas dan dingin, lihat Hot and cold data separation.

Kriteria diagnosis

AnalyticDB for MySQL memberikan saran optimasi untuk tabel yang tidak diakses dalam 15 hari terakhir dan memiliki laju akses kurang dari 1%.

Prosedur

Masuk ke Konsol AnalyticDB for MySQL. Di pojok kiri atas konsol, pilih wilayah. Di panel navigasi sebelah kiri, klik Clusters. Temukan kluster yang ingin Anda kelola dan klik ID kluster tersebut.
Di panel navigasi sebelah kiri, pilih Storage Analysis > Storage Diagnostics.
Pada tab Table Diagnostics, klik Hot and Cold Table Optimization.
Pada tab Available Optimization Suggestions, klik Disable untuk mengaktifkan fitur optimasi tabel panas-dingin. Jika fitur ini sudah diaktifkan untuk kluster saat ini, Anda dapat melewati langkah ini.

Klik tab Available Optimization Suggestions dan Applied Optimization Suggestions untuk melihat saran yang tersedia dan yang telah diterapkan.

Parameter	Deskripsi
Suggestion ID	ID saran optimasi.
SQL	Perubahan tabel dan definisi yang diperlukan oleh saran.
Optimization Type	Optimasi tabel panas dan dingin.
Optimization Suggestion	Rekomendasi detail untuk jenis optimasi tersebut.
Expected Optimization Benefits	Manfaat yang diharapkan setelah menerapkan saran. Catatan Manfaat yang diharapkan merupakan perkiraan berdasarkan statistik historis, bukan nilai akurat real-time. Gunakan hanya sebagai referensi.
Actions	Anda dapat menerapkan saran saat ini menggunakan Apply. Catatan Setelah mengklik Apply, AnalyticDB for MySQL mengubah kebijakan penyimpanan tabel menjadi COLD. Untuk mengubahnya menjadi MIXED atau HOT, jalankan pernyataan ALTER secara manual. Untuk detailnya, lihat Storage policies. Klik Apply untuk menerapkan saran optimasi. Setelah Anda mengklik Apply, kluster yang sesuai akan mengeksekusi perubahan SQL, dan saran tersebut akan muncul di tab Applied Optimization Suggestions. Apply memiliki efek yang sama seperti menjalankan SQL di client. Tindakan ini tidak dapat dibatalkan. Gunakan dengan hati-hati. Setelah SQL dikeluarkan, tabel harus menyelesaikan operasi Build agar perubahan berlaku. Sistem database memicu Build secara otomatis berdasarkan aturan internal. Sebelum dipicu, status saran tetap "running". Setelah dipicu, status berubah menjadi "completed".

Diagnostik tabel replikasi

Saat membuat tabel di AnalyticDB for MySQL, Anda dapat menentukan distribusi broadcast menggunakan DISTRIBUTED BY BROADCAST. Tabel tersebut kemudian dibuat sebagai tabel replikasi, yang menyimpan salinan identik datanya di setiap shard. Jika workload kueri Anda melibatkan join konkurensi tinggi antara tabel besar dan kecil, seperti menggabungkan tabel fakta besar dengan tabel dimensi kecil, Anda dapat membuat tabel yang lebih kecil sebagai tabel replikasi. Hal ini dapat mengurangi transmisi data melalui jaringan internal kluster dan meningkatkan konkurensi kueri. Namun, tabel replikasi memiliki performa penulisan yang buruk dan mengonsumsi banyak ruang penyimpanan, yang dapat berdampak negatif pada performa penulisan keseluruhan kluster AnalyticDB for MySQL.

Kriteria diagnosis

Tabel replikasi dianggap tidak efisien jika berisi lebih dari 20.000 baris.

Prosedur

Masuk ke Konsol AnalyticDB for MySQL. Di pojok kiri atas konsol, pilih wilayah. Di panel navigasi sebelah kiri, klik Clusters. Temukan kluster yang ingin Anda kelola dan klik ID kluster tersebut.
Di panel navigasi sebelah kiri, pilih Storage Analysis > Storage Diagnostics.
Pada tab Table Diagnostics, klik Replicated Table Diagnostics.

Metode optimasi

Buat tabel standar dan migrasikan datanya. Untuk informasi selengkapnya, lihat CREATE TABLE.

Diagnostik partisi

Diagnostik tabel partisi

Jika Anda tidak mengatur field partisi dengan benar saat membuat tabel partisi, masalah berikut dapat terjadi:

Partisi yang terlalu besar, seperti partisi tahunan di mana data setiap tahun berada dalam satu partisi, menghasilkan jumlah partisi sedikit dengan volume data sangat besar. Jika tugas Build dijalankan pada partisi semacam itu, sumber daya berlebihan seperti CPU node penyimpanan dan disk I/O akan dikonsumsi, yang memengaruhi stabilitas kluster.
Partisi yang terlalu kecil, seperti partisi per jam di mana data setiap jam berada dalam satu partisi, menghasilkan banyak partisi yang berisi data minimal. Kluster harus menyimpan metadata partisi dalam jumlah besar di cache, yang mengonsumsi memori signifikan. Kueri juga perlu memindai banyak partisi, yang menurunkan performa kueri.

Berapa ukuran partisi yang wajar?

Ukuran partisi diukur berdasarkan jumlah baris¹ dan berskala proporsional dengan jumlah shard². Jika sebuah kluster memiliki N shard, ukuran partisi yang wajar adalah jumlah baris antara [1 juta × N] hingga [5 juta × N].

Sebagai contoh, jika kluster memiliki 64 shard, jumlah baris partisi yang wajar berkisar antara 64 juta hingga 320 juta.

Catatan

¹Untuk menanyakan jumlah baris per partisi, jalankan perintah berikut: SELECT partition_id, row_count FROM information_schema.kepler_partitions WHERE schema_name = '$DB' AND table_name ='$TABLE' AND partition_id > 0;
²Untuk menanyakan jumlah shard, jalankan perintah berikut: SELECT COUNT(1) FROM information_schema.kepler_meta_shards;

Mendiagnosis apakah field partisi wajar

Kriteria diagnosis

Field partisi dianggap tidak wajar jika 10% atau lebih partisi dalam suatu tabel memiliki ukuran yang tidak wajar.

Sebagai contoh, jika suatu tabel memiliki 100 partisi dan 10 atau lebih di antaranya memiliki ukuran tidak wajar, field partisi tersebut ditandai sebagai tidak wajar.

Prosedur

Masuk ke Konsol AnalyticDB for MySQL. Di pojok kiri atas konsol, pilih wilayah. Di panel navigasi sebelah kiri, klik Clusters. Temukan kluster yang ingin Anda kelola dan klik ID kluster tersebut.
Di panel navigasi sebelah kiri, pilih Storage Analysis > Storage Diagnostics.
Klik tab Partition Diagnostics untuk melihat tabel partisi yang tidak wajar dan nama partisi spesifiknya di bagian Partitioned Table Diagnostics.

Cara menyesuaikan ukuran partisi ke dalam rentang wajar

Jika alat diagnostik partisi mengidentifikasi partisi yang tidak wajar, Anda dapat menggunakan metode berikut untuk menyesuaikannya.

Jika jumlah baris partisi berada di bawah batas bawah rentang wajar, partisi tersebut terlalu kecil. Dalam kasus ini, Anda dapat meningkatkan granularitas partisi. Sebagai contoh, jika kluster memiliki 64 shard, rentang wajar adalah 64 juta hingga 320 juta baris. Jika suatu partisi memiliki kurang dari 64 juta baris, Anda dapat mengubah partisi dari harian menjadi bulanan.
Jika jumlah baris dalam suatu partisi melebihi batas atas yang direkomendasikan, partisi tersebut dianggap terlalu besar, dan Anda harus mengurangi granularitasnya. Sebagai contoh, jika Anda memiliki 64 shard, jumlah baris yang direkomendasikan per partisi adalah antara 64 juta hingga 320 juta. Jika suatu partisi berisi lebih dari 320 juta baris, kami menyarankan Anda mengubah partisi dari bulanan menjadi harian.
Untuk informasi selengkapnya tentang cara mengubah granularitas partisi, lihat Change the partition function format.
Jika jumlah total baris suatu tabel berada di bawah batas bawah rentang wajar dan tidak diharapkan tumbuh ke dalam rentang tersebut, Anda dapat membuat tabel non-partisi dan memigrasikan data dari tabel partisi.

Diagnostik tabel non-partisi

Jika Anda menghilangkan klausa PARTITION BY saat membuat tabel, tabel tersebut dibuat sebagai tabel non-partisi. Operasi DML, seperti INSERT, UPDATE, dan DELETE, pada tabel non-partisi sering memicu tugas Build seluruh tabel. Jika tabel berisi data dalam jumlah besar, tugas Build ini mengonsumsi banyak ruang disk temporary, yang meningkatkan penggunaan disk di node dan dapat menyebabkan disk terkunci. Tugas Build pada tabel besar juga mengonsumsi banyak sumber daya disk I/O dan CPU, yang menurunkan performa keseluruhan kluster.

Kriteria diagnosis

Tabel non-partisi dianggap tidak efisien jika berisi lebih dari 1 miliar baris.

Prosedur

Masuk ke Konsol AnalyticDB for MySQL. Di pojok kiri atas konsol, pilih wilayah. Di panel navigasi sebelah kiri, klik Clusters. Temukan kluster yang ingin Anda kelola dan klik ID kluster tersebut.
Di panel navigasi sebelah kiri, pilih Storage Analysis > Storage Diagnostics.
Klik tab Partition Diagnostics untuk melihat informasi Non-partitioned Table Diagnostics.

Metode optimasi

Buat tabel partisi dan migrasikan data dari tabel non-partisi. Untuk informasi selengkapnya, lihat CREATE TABLE.

Diagnostik indeks

AnalyticDB for MySQL menganalisis penggunaan indeks dan secara otomatis memberikan saran optimasi untuk indeks yang tidak digunakan dalam waktu lama. Anda dapat menerapkan saran tersebut untuk menghapus indeks yang tidak aktif dan mengurangi biaya penyimpanan.

Diagnostik indeks tidak aktif

Kriteria diagnosis

Indeks dianggap tidak aktif jika tidak digunakan dalam 15 hari terakhir dan laju penggunaannya kurang dari 1%.

Prosedur

Masuk ke Konsol AnalyticDB for MySQL. Di pojok kiri atas konsol, pilih wilayah. Di panel navigasi sebelah kiri, klik Clusters. Temukan kluster yang ingin Anda kelola dan klik ID kluster tersebut.
Di panel navigasi sebelah kiri, pilih Storage Analysis > Storage Diagnostics.
Klik tab Index Diagnostics untuk melihat detail Indexes to Remove.
Pada tab Available Optimization Suggestions, klik Enable untuk mengaktifkan diagnostik indeks. Anda dapat melewati langkah ini jika fitur ini sudah diaktifkan.

Klik tab Available Optimization Suggestions dan Applied Optimization Suggestions untuk melihat saran yang tersedia dan yang telah diterapkan.

Parameter	Deskripsi
Suggestion ID	ID saran optimasi.
SQL	Perubahan tabel dan definisi yang diperlukan oleh saran.
Optimization Type	Optimasi indeks.
Optimization Suggestion	Rekomendasi detail untuk jenis optimasi tersebut.
Expected Optimization Benefits	Manfaat yang diharapkan setelah menerapkan saran. Catatan Manfaat yang diharapkan merupakan perkiraan berdasarkan statistik historis, bukan nilai akurat real-time. Gunakan hanya sebagai referensi.
Actions	Anda dapat menerapkan saran saat ini menggunakan Apply. Catatan Setelah menghapus indeks, kueri yang melakukan filter pada kolom tersebut akan membutuhkan waktu lebih lama. Apply menunjukkan bahwa Anda setuju untuk menerapkan saran optimasi ini. Setelah Anda mengklik Apply, kluster yang sesuai akan mengeksekusi perubahan SQL, dan saran ini akan muncul di tab Applied Optimization Suggestions. Apply memiliki efek yang sama seperti menjalankan SQL di client. Tindakan ini tidak dapat dibatalkan. Gunakan dengan hati-hati. Setelah SQL dikeluarkan, tabel harus menyelesaikan operasi Build agar perubahan berlaku. Sistem database memicu Build secara otomatis berdasarkan aturan internal. Sebelum dipicu, status saran tetap "running". Setelah dipicu, status berubah menjadi "completed".

Diagnostik indeks baru

Kriteria diagnosis

Diagnostik ini mengidentifikasi field yang digunakan sebagai filter dalam kueri selama 15 hari terakhir tetapi tidak didefinisikan sebagai indexed fields.

Prosedur

Masuk ke Konsol AnalyticDB for MySQL. Di pojok kiri atas konsol, pilih wilayah. Di panel navigasi sebelah kiri, klik Clusters. Temukan kluster yang ingin Anda kelola dan klik ID kluster tersebut.
Di panel navigasi sebelah kiri, pilih Storage Analysis > Storage Diagnostics.
Klik tab Index Diagnostics untuk melihat detail Indexes to Create.
Pada tab Available Optimization Suggestions, klik Enable untuk mengaktifkan diagnostik indeks. Anda dapat melewati langkah ini jika fitur ini sudah diaktifkan.

Klik tab Available Optimization Suggestions dan Applied Optimization Suggestions untuk melihat saran yang tersedia dan yang telah diterapkan.

Parameter	Deskripsi
Suggestion ID	ID saran optimasi.
Index Fields	Field yang akan ditambahkan sebagai indeks.
SQL	Pernyataan SQL untuk membuat indeks.
Optimization Type	Saran pembuatan indeks.
Optimization Suggestion	Menjelaskan seberapa sering field tersebut digunakan baru-baru ini, yang menunjukkan potensinya sebagai indexed field. Anda dapat menerapkan saran saat ini menggunakan Batch Create. Catatan Setelah Indexes to Create, tabel harus menyelesaikan operasi Build agar perubahan berlaku. Sistem database memicu Build secara otomatis berdasarkan aturan internal. Sebelum dipicu, status saran tetap "running". Setelah dipicu, status berubah menjadi "completed".

Diagnostik indeks kunci utama

Kriteria diagnosis

Suatu tabel dianggap memiliki jumlah kunci utama berlebihan jika memiliki lebih dari tiga field kunci utama dan field-field tersebut menyusun setidaknya separuh dari seluruh field dalam tabel.

Prosedur

Masuk ke Konsol AnalyticDB for MySQL. Di pojok kiri atas konsol, pilih wilayah. Di panel navigasi sebelah kiri, klik Clusters. Temukan kluster yang ingin Anda kelola dan klik ID kluster tersebut.
Di panel navigasi sebelah kiri, pilih Storage Analysis > Storage Diagnostics.
Klik tab Index Diagnostics untuk melihat detail Primary Key Diagnostics.
Pada tab Available Optimization Suggestions, klik Enable untuk mengaktifkan diagnostik indeks. Anda dapat melewati langkah ini jika fitur ini sudah diaktifkan.
Lihat tabel yang memiliki jumlah kunci utama berlebihan. Tabel menampilkan kolom berikut: Database, Table Name, Table Fields, dan Primary Key Fields.

FAQ

Mengapa status tugas optimasi tetap "running" setelah mengklik Apply now untuk saran optimasi tabel panas-dingin?

Penyebab: Setelah Anda mengklik Apply, AnalyticDB for MySQL mengubah kebijakan penyimpanan tabel menjadi COLD. Perubahan ini memerlukan operasi Build agar berlaku. Fitur optimasi panas-dingin tidak langsung memicu tugas Build. Sistem akan memicu tugas ini secara otomatis di waktu berikutnya.

Solusi: Anda dapat menunggu sistem secara otomatis memicu tugas Build, atau Anda dapat menyalin pernyataan SQL yang memicu tugas Build dari konsol dan mengeksekusinya secara manual. Setelah tugas Build dijalankan, Anda dapat memeriksa statusnya dengan menjalankan perintah berikut: SELECT table_name, schema_name, status FROM INFORMATION_SCHEMA.KEPLER_META_BUILD_TASK ORDER BY create_time DESC LIMIT 10;.

API Terkait

API	Deskripsi
DescribeExcessivePrimaryKeys	Lihat tabel dengan kunci utama berlebihan di kluster Enterprise Edition, Basic Edition, dan Data Lakehouse Edition.
DescribeTablePartitionDiagnose	Lihat diagnostik partisi untuk kluster Data Warehouse Edition.