Business key aggregated storage adalah peningkatan penyimpanan LogStore di Simple Log Service yang menyimpan log dari satu business key—seperti trace ID atau session ID—ke dalam ShardGroup yang sama. Tanpa fitur ini, log tersebut tersebar di seluruh shard, dan setiap point query memindai seluruh LogStore, yang semakin melambat seiring pertumbuhan data. Aktifkan fitur ini untuk memangkas shard yang tidak relevan saat kueri, tanpa mengubah metode penulisan atau sintaks kueri Anda.
Business key aggregated storage saat ini hanya tersedia di wilayah ap-southeast-8. Pastikan wilayah LogStore Anda sebelum merencanakan kebijakan business key.
Skenario
Business key aggregated storage mengurangi jumlah shard yang dipindai oleh kueri ketika kondisi kueri Anda secara konsisten mencakup kondisi kesetaraan (equality) pada bidang business key yang sama. Tabel berikut mencantumkan skenario umum dan kombinasi business key yang direkomendasikan.
Skenario | Business key yang direkomendasikan | Manfaat |
Trace troubleshooting |
| Mempersempit rentang pemindaian shard saat Anda melakukan kueri pada satu rantai panggilan, sehingga log trace dikembalikan lebih cepat. |
Observabilitas aplikasi Agent |
| Menyimpan panggilan model, panggilan tool, operasi pengambilan (retrieval), operasi memori, dan anomali dari satu eksekusi agent secara bersamaan, sehingga mempercepat kueri trace. |
Analisis sesi pengguna |
| Mengembalikan log perilaku lengkap dari satu pengguna atau satu sesi dengan cepat. |
Troubleshooting pesanan dan transaksi |
| Menemukan pengecualian pesanan, kegagalan pembayaran, dan masalah rantai transaksi dengan cepat. |
Log akses Host dan client |
| Mengelompokkan log akses dari sumber, client, atau nama domain yang sama untuk troubleshooting. |
Log IoT dan perangkat |
| Mengembalikan log operasi, peringatan (alert), dan koneksi dari satu perangkat dengan cepat. |
Audit keamanan dan pelacakan serangan |
| Melacak log perilaku dari alamat IP, akun, AccessKey, atau pengguna tertentu. |
Skenario yang tidak cocok
Pada skenario berikut, business key aggregated storage memberikan manfaat terbatas atau menyebabkan hotspot penulisan. Evaluasi pola kueri dan distribusi data Anda sebelum mengaktifkannya.
Skenario | Alasan |
Kueri jarang berisi business key tetap | Simple Log Service tidak dapat memangkas shard berdasarkan business key, sehingga manfaatnya terbatas. |
LogStore memiliki terlalu sedikit shard | Setiap ShardGroup berisi terlalu sedikit shard yang dapat ditulis, sehingga membatasi kemampuan disaster recovery. |
Nilai business key sangat miring (skewed) | Nilai bidang business key didistribusikan secara tidak merata, sehingga menyebabkan write skew. Misalnya, jika satu |
Jika LogStore Anda sesuai dengan salah satu skenario ini, periksa konfigurasi shard yang dapat ditulis di bagian Prasyarat serta distribusi nilai dan cakupan bidang business key kandidat sebelum memutuskan untuk mengaktifkan fitur ini.
Prasyarat
Buat proyek dan LogStore. Untuk petunjuknya, lihat Manage projects dan Manage LogStores.
Rencanakan bidang business key, seperti
trace_id,session_id,user_id, atauorder_id. Pilih bidang yang selalu ada di log Anda, sering digunakan sebagai filter kueri, dan memiliki selektivitas tinggi.Periksa jumlah shard yang dapat ditulis di LogStore target. Konfigurasi yang direkomendasikan adalah 8 shard yang dapat ditulis, karena setiap ShardGroup kemudian menyimpan sekitar 2 shard yang dapat ditulis dan memiliki kemampuan disaster recovery yang wajar. Anda juga dapat mengaktifkan fitur ini dengan 4 shard yang dapat ditulis, tetapi setiap ShardGroup hanya menyimpan sekitar 1 shard yang dapat ditulis dan kemampuan disaster recovery menjadi terbatas. Untuk melihat dan menyesuaikan jumlah shard, lihat Manage shards.
Batasan
Batasan berikut berlaku untuk business key aggregated storage:
Wilayah yang didukung — Business key aggregated storage saat ini hanya tersedia di wilayah ap-southeast-8. Wilayah lain tidak didukung.
Sumber daya yang didukung — Hanya LogStore yang mendukung business key aggregated storage.
Jumlah bidang business key — Anda harus mengonfigurasi minimal satu dan maksimal dua bidang business key.
Urutan bidang — Urutan bidang ikut serta dalam perhitungan entri rute. Mengubah urutan bidang dianggap sebagai perubahan kebijakan.
Nilai yang hilang atau kosong — Jika bidang business key tidak ada atau nilainya kosong, string kosong digunakan dalam perhitungan hash.
Jumlah ShardGroup — Jumlah ShardGroup harus merupakan pangkat dari 2, seperti 4, 8, 16, 32, atau 64.
Dampak perubahan kebijakan — Kebijakan baru berlaku setelah jeda singkat dan hanya berlaku untuk log yang ditulis setelah kebijakan tersebut aktif. Simple Log Service tidak mendistribusikan ulang data historis.
Konfigurasi business key aggregated storage
Aktifkan business key aggregated storage saat membuat LogStore, atau konfigurasikan di halaman properti LogStore yang sudah ada. Kedua titik masuk ini menampilkan item konfigurasi yang sama, dan bidang business key serta jumlah ShardGroup memiliki makna identik di keduanya.
Aktifkan business key aggregated storage pada LogStore baru
Login ke Simple Log Service console.
Di daftar Project, klik proyek target.
Di tab Log Storage > Logstores, klik ikon +.
Di halaman Create Logstore, temukan item konfigurasi Business key aggregated storage.
Nyalakan sakelar Business key aggregated storage, lalu konfigurasikan Business key fields dan Number of ShardGroups. Untuk membiarkan konsol mengisi jumlah ShardGroup yang disarankan berdasarkan jumlah shard yang dapat ditulis saat ini, klik Use recommended value.
Klik OK.
Ubah atau nonaktifkan business key aggregated storage pada LogStore yang sudah ada
Login ke Simple Log Service console.
Di daftar Project, klik proyek target.
Di tab Log Storage > Logstores, arahkan pointer ke LogStore target dan pilih Modify.
Di panel navigasi sebelah kiri halaman properti LogStore, klik Business key aggregated storage.
Konfigurasikan pengaturan dengan salah satu cara berikut:
Untuk mengaktifkan fitur atau mengubah pengaturannya, nyalakan sakelar Business key aggregated storage dan konfigurasikan Business key fields dan Number of ShardGroups. Mengubah bidang business key, urutannya, atau jumlah ShardGroup dianggap sebagai perubahan kebijakan, dan kebijakan baru hanya berlaku untuk log yang ditulis setelah perubahan tersebut aktif.
Untuk menonaktifkan fitur, matikan sakelar Business key aggregated storage. Log baru kemudian tidak lagi diagregasi berdasarkan business key, dan pemangkasan berdasarkan business key tidak lagi berlaku untuk log tersebut.
Klik Save.
Setelah Anda menonaktifkan business key aggregated storage, log yang sudah ditulis tetap berada di shard aslinya. Simple Log Service tidak memigrasi atau mendistribusikan ulang log tersebut, sehingga menonaktifkan fitur ini tidak menyebabkan kehilangan data maupun penulisan ulang data.
Parameter
Tabel berikut menjelaskan item konfigurasi business key aggregated storage di halaman pembuatan LogStore dan di halaman properti LogStore.
Parameter | Deskripsi |
Business key aggregated storage | Menentukan apakah business key aggregated storage diaktifkan. Setelah Anda menyalakan sakelar, Simple Log Service menuliskan log yang memiliki business key yang sama ke dalam ShardGroup yang sama. |
Business key fields | Bidang yang menentukan ShardGroup tempat log ditulis. Konfigurasikan satu atau dua bidang. |
Number of ShardGroups | Jumlah kelompok logis yang digunakan untuk agregasi business key. Nilainya harus merupakan pangkat dari 2. (Direkomendasikan) Gunakan nilai yang disarankan oleh konsol. |
Use recommended value | Menghitung jumlah ShardGroup yang disarankan berdasarkan jumlah shard yang dapat ditulis saat ini. |
Shard data range balance status | Menunjukkan apakah rentang data shard LogStore saat ini seimbang, yang membantu Anda memutuskan apakah diperlukan data rerange. |
Data rerange | Mendistribusikan ulang rentang data shard untuk memperbaiki ketidakseimbangan rentang data shard. Sebelum menjalankan data rerange, periksa apakah log ditulis dengan kunci hash tertentu, misalnya melalui SDK. |
Pilih jumlah ShardGroup
Jumlah ShardGroup menentukan granularitas pemangkasan kueri: semakin banyak ShardGroup yang Anda konfigurasi, semakin sedikit shard yang dipindai setiap kueri, tetapi semakin sedikit shard yang dapat ditulis di setiap grup, sehingga mengurangi kemampuan disaster recovery dan meningkatkan risiko hotspot. Konsol menyarankan nilai berdasarkan jumlah shard yang dapat ditulis saat ini di LogStore, dan nilai yang disarankan menyeimbangkan efisiensi pemangkasan kueri, kemampuan disaster recovery, dan risiko hotspot.
Shard yang dapat ditulis saat ini | ShardGroup yang direkomendasikan | Deskripsi |
4 | 4 | Sekitar 1 shard yang dapat ditulis per grup. Kueri dapat dipangkas, tetapi kemampuan disaster recovery terbatas. |
8 | 4 | Sekitar 2 shard yang dapat ditulis per grup. Cocok saat Anda mulai menggunakan fitur ini. |
16 | 4 atau 8 | Pilih nilai berdasarkan kebutuhan percepatan kueri Anda. |
32 | 8 atau 16 | Cocok untuk kueri titik berfrekuensi tinggi. |
64 | 16 atau 32 | Cocok untuk kueri titik skala besar, troubleshooting trace, dan analisis sesi. |
Klik Use recommended value untuk menerapkan nilai yang disarankan. Dalam rentang nilai, nilai yang lebih tinggi memberikan pemangkasan kueri yang lebih halus, sedangkan nilai yang lebih rendah menyimpan lebih banyak shard yang dapat ditulis di setiap ShardGroup.
Kondisi hit dan fallback kueri
Setelah Anda mengaktifkan business key aggregated storage, kueri mencapai pemangkasan berbasis business key jika berisi kondisi kesetaraan pada semua bidang business key. Simple Log Service menghitung ShardGroup target dari nilai business key dan hanya memindai shard dari grup tersebut, bukan semua shard di LogStore, sehingga mengurangi volume data yang terlibat dalam komputasi.
Sebagai contoh, bidang business key adalah tenant_id dan agent_run_id, dan kueri berisi kondisi berikut:
tenant_id = 'tenant-a' AND agent_run_id = 'run-001'Simple Log Service menentukan satu ShardGroup target dari nilai-nilai tersebut dan hanya memindai shard dari grup tersebut.
Dalam kasus berikut, kueri tidak dapat memanfaatkan business key aggregated storage dan kembali ke pemindaian seluruh shard:
Bidang business key tidak lengkap — Kueri tidak berisi salah satu bidang business key.
Pencocokan non-kesetaraan — Bidang business key dicocokkan menggunakan pencocokan kabur (fuzzy match), pencocokan rentang, atau ekspresi reguler, bukan kondisi kesetaraan.
Nilai business key ambigu — Ekspresi kueri tidak menghasilkan nilai business key yang unik.
Perubahan kebijakan dalam rentang waktu — Rentang waktu kueri mencakup perubahan kebijakan atau log yang ditulis sebelum kebijakan saat ini berlaku, sehingga satu kebijakan tidak dapat digunakan untuk pemangkasan.
Fitur tidak diaktifkan — Business key aggregated storage tidak diaktifkan untuk LogStore tersebut.
Penagihan
Business key aggregated storage tidak mengubah metode penagihan LogStore. Setelah Anda mengaktifkannya, biaya penulisan, penyimpanan, kueri, dan analisis tetap dikenakan berdasarkan metode penagihan LogStore saat ini.
Ketika kueri mencapai pemangkasan berbasis business key, volume data yang dipindai dan durasi kueri berkurang, sehingga biaya kueri dan analisis terkait juga dapat berkurang. Manfaat aktual tergantung pada apakah kueri berisi business key lengkap, jumlah ShardGroup, distribusi data, dan rentang waktu kueri.
FAQ
Mengapa kueri saya tidak terasa lebih cepat setelah mengaktifkan business key aggregated storage?
Pertama-tama periksa apakah kueri Anda memenuhi kondisi hit yang dijelaskan di bagian Query hit and fallback conditions. Jika kueri memang memenuhi kondisi tersebut, periksa penyebab konfigurasi berikut:
Bidang business key tidak ada di sebagian besar log, sehingga efek agregasi lemah.
Jumlah ShardGroup terlalu sedikit, sehingga hanya sedikit shard yang dipangkas.
Apa yang terjadi jika bidang business key tidak ada?
Simple Log Service menggunakan string kosong dalam perhitungan hash, sehingga semua log dengan nilai yang hilang atau kosong ditulis ke ShardGroup yang sama. Jika bidang business key tidak ada di banyak log, terjadi write skew. Periksa cakupan bidang business key sebelum mengaktifkan business key aggregated storage.
Kapan saya perlu melakukan data rerange?
Pertimbangkan data rerange ketika Shard data range balance status menunjukkan bahwa rentang data shard tidak seimbang. Sebelum menjalankannya, periksa apakah log ditulis dengan kunci hash tertentu, misalnya melalui SDK. Jika aplikasi Anda terus menulis dengan kunci hash tertentu, hotspot mungkin tetap ada setelah rerange.