Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. # Cara kerja penagihan di Aurora DSQL Dengan Amazon Aurora DSQL, Anda hanya membayar untuk apa yang Anda gunakan tanpa biaya di muka. Bagian ini menjelaskan bagaimana Aurora DSQL mengukur aktivitas database Anda dan menerjemahkannya ke dalam tagihan Anda. AWS Untuk harga saat ini menurut Wilayah, lihat halaman harga [Aurora DSQL](https://aws.amazon.com/rds/aurora/dsql/pricing/). **Topics** + [Cara kerja metering](#billing-how-metering-works) + [Pengukuran komponen DPU dijelaskan](#billing-dpu-components) + [Penagihan Multi-Region](#billing-multiregion-write-dpu) + [Memantau penggunaan DPU dengan CloudWatch](#billing-cloudwatch-monitoring) + [Menggunakan EXPLORE ANALYZE VERBOSE untuk kesadaran biaya](#billing-explain-analyze) + [Praktik terbaik estimasi biaya](#billing-best-practices) ## Cara kerja metering Tidak seperti database tradisional yang mengenakan biaya untuk kapasitas yang disediakan, Aurora DSQL mengenakan biaya hanya untuk pekerjaan aktual yang dilakukan. Aurora DSQL meter dua komponen utama: aktivitas database, diukur dalam Unit Pemrosesan Terdistribusi (DPUs), dan penyimpanan, diukur dalam bulan GIB. DPUs mengukur berapa banyak pekerjaan yang dilakukan sistem untuk menjalankan beban kerja SQL Anda dan terdiri dari tiga komponen untuk kluster Single-region: DPUs Compute, Read, dan Write. DPUs DPUs Cluster Multi-Region mengeluarkan komponen MultiRegion Write DPU tambahan. Untuk detailnya, lihat [Penagihan Multi-Wilayah](#billing-multiregion-write-dpu). Tabel berikut merangkum komponen yang Aurora DSQL gunakan untuk mengukur aktivitas database Anda. Pada tagihan Anda, Anda hanya melihat dua item baris: satu untuk penyimpanan dan satu untuk DPU, yang merupakan jumlah dari masing-masing komponen. | Unit pengukuran | Jenis aktivitas | Pengukuran | | --- | --- | --- | | Hitung DPU | Pemrosesan kueri | Waktu CPU | | Baca DPU | Membaca data dari database Anda | Byte dibaca dari penyimpanan | | Tulis DPU | Menulis data ke database Anda | Byte ditulis ke penyimpanan | | Penyimpanan | Penyimpanan meja | GIB-bulan | ## Pengukuran komponen DPU dijelaskan Untuk setiap transaksi, Aurora DSQL menghitung total DPU sebagai jumlah dari tiga komponen: Compute DPU, Read DPU, dan Write DPU. Bagian berikut menjelaskan bagaimana Aurora DSQL meter setiap komponen. ``` Total DPU = ComputeDPU + ReadDPU + WriteDPU ``` ### ComputedPU Komputasi DPUs diukur menggunakan total waktu pemrosesan yang dihabiskan untuk mengeksekusi kueri Anda, termasuk gabungan, fungsi, agregasi, pengurutan, dan perencanaan kueri. Karena bagian dari kueri Anda dapat diproses secara paralel, DPU Komputasi mencerminkan jumlah semua waktu pemrosesan — bukan waktu jam dinding kueri. Rumus berikut merangkum cara menghitung Compute DPUs: ``` ComputeDPU = Total Compute time (in seconds) ``` ### DitulisPU Untuk setiap transaksi, Aurora DSQL mengukur Write DPUs dengan total byte yang ditulis ke penyimpanan. Tulis DPUs sertakan total data yang ditulis ke tabel dasar Anda serta indeks sekunder apa pun. Aurora DSQL menagih setiap baris yang ditulis ke tabel dasar Anda dan indeks sekunder yang lebih kecil dari 128 byte seolah-olah itu adalah 128 byte. Aurora DSQL menagih transaksi tulis yang menulis kurang dari 1.024 byte seolah-olah menulis 1.024 byte. **catatan** Operasi tulis juga dikenakan biaya readDPU karena Aurora DSQL membaca indeks kunci utama untuk memverifikasi keunikan sebelum menulis. Rumus berikut menunjukkan langkah-langkah untuk menghitung Tulis DPUs: **Langkah 1: Hitung byte tertulis** ``` Bytes Written = Sum of max(size of each row, 128 bytes) for all rows written ``` **Langkah 2: Hitung WritedPU** ``` WriteDPU = max(Bytes Written, 1024) × 0.00004883 ``` ### bacaDPU Untuk setiap transaksi, Aurora DSQL mengukur Read DPUs by total byte yang dibaca dari penyimpanan. Baca DPUs termasuk data yang dibaca dari tabel dasar Anda serta indeks sekunder apa pun. **Minimum per partisi: Aurora** DSQL mengukur byte baca per partisi penyimpanan, bukan per baris. Jika permintaan baca ke partisi penyimpanan mengembalikan kurang dari 128 byte, Aurora DSQL membulatkannya hingga 128 byte. Misalnya, jika kueri Anda membaca dari 4 partisi — 200 byte dari satu partisi dan 50 byte dari masing-masing tiga partisi lainnya — tiga pembacaan 50 byte masing-masing dibulatkan menjadi 128 byte, menghasilkan total 200 \+ 128 \+ 128 \+ 128 = 584 byte yang ditagih. **Minimum transaksi:** Aurora DSQL menagih transaksi baca yang berbunyi kurang dari 2.048 byte secara total seolah-olah membaca 2.048 byte. Rumus berikut menunjukkan langkah-langkah untuk menghitung Baca DPUs: **Langkah 1: Hitung byte yang dibaca** ``` Bytes Read = # of rows read × size of each row ``` **catatan** Pembacaan byte sebenarnya tergantung pada bagaimana data Anda didistribusikan di seluruh partisi penyimpanan, karena minimum 128-byte per partisi diterapkan per partisi. Jika semua ukuran baris Anda di atas 128 byte, Anda cukup mengalikan jumlah baris yang dibaca dengan ukuran setiap baris. **Langkah 2: Hitung ReadDPU** ``` ReadDPU = max(Bytes Read, 2048) × 0.00000183105 ``` ### Contoh penagihan Contoh berikut menunjukkan bagaimana Aurora DSQL menghitung DPUs untuk operasi umum. Nilai biaya dalam contoh ini menggunakan harga Wilayah us-east-1. Untuk harga di Wilayah lain, lihat halaman harga [Aurora DSQL](https://aws.amazon.com/rds/aurora/dsql/pricing/). #### Contoh: Pencarian titik sederhana (baca) Contoh ini menunjukkan pencarian titik perhitungan ReadDPU di mana minimum transaksi berlaku. **Skema:** ``` CREATE TABLE orders ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), customer_id VARCHAR(50) NOT NULL, order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP, total_amount DECIMAL(10,2), status VARCHAR(20) ); -- Average row size: ~100 bytes ``` **Permintaan:** ``` SELECT * FROM orders WHERE customer_id = 'cust-12345'; ``` **Skenario:** Query mengembalikan 5 baris, masing-masing sekitar 100 byte. Dengan asumsi semua baris berada dalam satu partisi penyimpanan, total byte yang dibaca adalah 5 × 100 = 500 byte. Karena 500 byte melebihi minimum 128-byte per partisi, tidak ada minimum per partisi yang berlaku. **Hitung ReadDPU:** ``` ReadDPU = max(500, 2048) × 0.00000183105 = 2048 × 0.00000183105 = 0.00375 ``` Minimal transaksi 2.048 byte berlaku sejak 500 < 2.048. **Total biaya transaksi:** Dengan asumsi waktu eksekusi kueri 3 ms (0,003 detik): ``` ComputeDPU: 0.003 ReadDPU: 0.00375 WriteDPU: 0.0 ------------------- Total DPU: 0.00675 ``` #### Contoh: Pemindaian rentang yang difilter (baca) **Skema:** ``` CREATE TABLE orders ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), customer_id VARCHAR(50) NOT NULL, order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP, total_amount DECIMAL(10,2), status VARCHAR(20) ); -- Average row size: ~100 bytes -- Table contains 100 orders for customer 'cust-12345' ``` **Permintaan:** ``` SELECT * FROM orders WHERE customer_id = 'cust-12345' AND total_amount > 500.00; ``` **Skenario:** Kueri memindai 100 baris untuk pelanggan 'cust-12345', tetapi `total_amount > 500.00` filter mengurangi hasilnya menjadi hanya 10 baris yang dikembalikan. Tagihan Aurora DSQL untuk semua 100 baris yang dipindai. Dengan asumsi semua baris berada dalam satu partisi penyimpanan, total byte yang dibaca adalah 100 × 100 = 10.000 byte. **Hitung ReadDPU:** ``` ReadDPU = max(10000, 2048) × 0.00000183105 = 10000 × 0.00000183105 = 0.01831 ``` Karena 10.000 byte melebihi minimum transaksi 2.048-byte, byte yang sebenarnya dibaca digunakan. **Total biaya transaksi:** Dengan asumsi waktu eksekusi kueri 8 ms (0,008 detik): ``` ComputeDPU: 0.008 ReadDPU: 0.01831 WriteDPU: 0.0 ------------------- Total DPU: 0.02631 ``` **penting** Untuk meminimalkan biaya readDPU, desain kueri dan indeks untuk memindai hanya baris yang Anda butuhkan. Dalam contoh ini, menambahkan indeks pada `(customer_id, total_amount)` dapat memungkinkan kueri untuk memindai lebih sedikit baris. #### Contoh: Sisipan tunggal (baca dan tulis) **Skema:** ``` CREATE TABLE orders ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), customer_id VARCHAR(50) NOT NULL, order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP, total_amount DECIMAL(10,2), status VARCHAR(20) ); -- Average row size: ~100 bytes ``` **Permintaan:** ``` INSERT INTO orders (customer_id, total_amount, status) VALUES ('cust-67890', 150.00, 'pending'); ``` **Skenario:** Sisipkan 1 baris, sekitar 100 byte. **Perhitungan WritedPU:** *Langkah 1 - Hitung byte yang ditulis:* ``` 1 row × max(100 bytes, 128 bytes) = 1 × 128 = 128 bytes ``` *Langkah 2 - Hitung WritedPU:* ``` WriteDPU = max(128, 1024) × 0.00004883 = 1024 × 0.00004883 = 0.05 ``` Minimal transaksi 1.024 byte berlaku sejak 128 < 1.024. **ReadDPU (pemeriksaan kunci utama):** Aurora DSQL membaca indeks kunci utama untuk memverifikasi keunikan sebelum menulis. Ini menimbulkan biaya baca minimum transaksi. ``` ReadDPU = 0.00375 (transaction minimum) ``` **Total biaya transaksi:** Dengan asumsi waktu eksekusi kueri 8 ms (0,008 detik): ``` ComputeDPU: 0.008 ReadDPU: 0.00375 WriteDPU: 0.05 ------------------- Total DPU: 0.06175 ``` #### Contoh: Sisipan massal (baca dan tulis) **Skema:** ``` CREATE TABLE orders ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), customer_id VARCHAR(50) NOT NULL, order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP, total_amount DECIMAL(10,2), status VARCHAR(20) ); -- Average row size: ~100 bytes ``` **Permintaan:** ``` INSERT INTO orders (customer_id, total_amount, status) VALUES ('cust-001', 100.00, 'pending'), ('cust-002', 150.00, 'pending'), ... -- 100 rows total ('cust-100', 200.00, 'pending'); ``` **Skenario:** Masukkan 100 baris, masing-masing sekitar 100 byte. **Perhitungan WritedPU:** *Langkah 1 - Hitung byte yang ditulis:* ``` 100 rows × max(100 bytes, 128 bytes) = 100 × 128 = 12,800 bytes ``` *Langkah 2 - Hitung WritedPU:* ``` WriteDPU = max(12800, 1024) × 0.00004883 = 12800 × 0.00004883 = 0.625 ``` **ReadDPU (pemeriksaan kunci utama):** Aurora DSQL membaca indeks kunci utama untuk setiap baris untuk memverifikasi keunikan. Dengan asumsi semua 100 pencarian kunci berada dalam satu partisi penyimpanan, total byte yang dibaca adalah 100 × 16 byte (UUID) = 1.600 byte: ``` ReadDPU = max(1600, 2048) × 0.00000183105 = 2048 × 0.00000183105 = 0.00375 ``` Minimal transaksi 2.048 byte berlaku sejak 1.600 < 2.048. **Total biaya transaksi:** Dengan asumsi waktu eksekusi kueri 80 ms (0,08 detik): ``` ComputeDPU: 0.08 ReadDPU: 0.00375 WriteDPU: 0.625 ------------------- Total DPU: 0.70875 ``` ## Penagihan Multi-Region Cluster Multi-Region mengeluarkan komponen MultiRegion Write DPU tambahan di atas Compute, Read, dan Write standar. DPUs Bagian ini hanya berlaku untuk klaster Multi-wilayah. Cluster Single-Region tidak dikenakan biaya ini. MultiRegion Tulis DPUs ukur total byte yang ditulis ke Wilayah yang diintip. Karena Aurora DSQL secara sinkron mereplikasi data yang Anda tulis ke Wilayah peered, nilai Write DPU setara dengan MultiRegion Write DPU. Aurora DSQL membebankan DPU ini di Wilayah tempat penulisan berasal, bukan di Wilayah yang diintip. ``` MultiRegionWriteDPU = WriteDPU ``` ## Memantau penggunaan DPU dengan CloudWatch Aurora DSQL menerbitkan metrik penggunaan ke Amazon CloudWatch, memungkinkan Anda memantau konsumsi dalam waktu dekat. ### Metrik DPU yang tersedia **Metrik DPU** | CloudWatch metrik | Deskripsi | Dimensi | | --- | --- | --- | | WriteDPU | Tulis komponen penggunaan | ClusterId | | ReadDPU | Baca komponen penggunaan | ClusterId | | ComputeDPU | Komponen pemrosesan kueri | ClusterId | | MultiRegionWriteDPU | Replikasi Multi-Wilayah (Cluster multi-wilayah saja) | ClusterId | | TotalDPU | Jumlah semua komponen DPU | ClusterId | ### Melihat metrik DPU **Untuk melihat metrik DPU di CloudWatch** 1. Buka [konsol CloudWatch](https://console.aws.amazon.com/cloudwatch). 1. Arahkan ke **Metrik**, lalu **AuroraDSql**. **ClusterId** 1. Pilih klaster Anda dan metrik DPU yang ingin Anda pantau. **Tip** Gunakan statistik **Jumlah** untuk metrik DPU untuk melihat penggunaan total selama periode waktu tertentu. Tambahkan label **LAST** untuk melihat nilai terbaru. ### Metrik observabilitas tambahan Untuk daftar lengkap metrik Aurora DSQL dan kemampuan pemantauan, lihat. [Pemantauan dan pencatatan untuk Aurora DSQL](monitoring-overview.md) **Metrik observabilitas** | Metrik | Deskripsi | | --- | --- | | ClusterStorageSize | Ukuran penyimpanan saat ini dalam byte | | TotalTransactions | Total transaksi yang dieksekusi | | ReadOnlyTransactions | Transaksi hanya-baca dieksekusi | | QueryTimeouts | Kueri yang melebihi batas waktu | | OccConflicts | Transaksi dibatalkan karena konflik OCC | | BytesWritten | Byte mentah ditulis ke penyimpanan | | BytesRead | Byte mentah dibaca dari penyimpanan | ## Menggunakan EXPLORE ANALYZE VERBOSE untuk kesadaran biaya Aurora DSQL diperluas `EXPLAIN ANALYZE VERBOSE` untuk menyertakan perkiraan penggunaan DPU tingkat pernyataan pada akhir output. Ini memberikan visibilitas langsung ke biaya kueri, membantu Anda mengidentifikasi driver biaya beban kerja, menyesuaikan kinerja kueri, dan perkiraan penggunaan sumber daya yang lebih baik. **catatan** Anda harus menggunakan `EXPLAIN ANALYZE VERBOSE` (dengan VERBOSE) untuk melihat perkiraan DPU. Polos `EXPLAIN ANALYZE` tanpa VERBOSE tidak menampilkan informasi DPU. ### Contoh 1: SELECT query ``` EXPLAIN ANALYZE VERBOSE SELECT * FROM test_table; ``` ``` QUERY PLAN ---------------------------------------------------- Index Only Scan using test_table_pkey on public.test_table (cost=125100.05..171100.05 rows=1000000 width=36) (actual time=2.973..4.482 rows=120 loops=1) Output: id, context -> Storage Scan on test_table_pkey (cost=125100.05..171100.05 rows=1000000 width=36) (actual rows=120 loops=1) Projections: id, context -> B-Tree Scan on test_table_pkey (cost=125100.05..171100.05 rows=1000000 width=36) (actual rows=120 loops=1) Query Identifier: qymgw1m77maoe Planning Time: 11.415 ms Execution Time: 4.528 ms Statement DPU Estimate: Compute: 0.01607 DPU Read: 0.04312 DPU Write: 0.00000 DPU Total: 0.05919 DPU ``` Dalam contoh ini, pernyataan SELECT melakukan pemindaian indeks saja, sehingga sebagian besar biaya berasal dari Baca DPU (0,04312), mewakili data yang diambil dari penyimpanan dan Compute DPU (0,01607), yang mencerminkan sumber daya komputasi yang digunakan untuk memproses dan mengembalikan hasilnya. Tidak ada Write DPU karena kueri tidak mengubah data. Total DPU (0,05919) adalah jumlah dari Compute \+ Read\+Write. ### Contoh 2: Insert query ``` EXPLAIN ANALYZE VERBOSE INSERT INTO test_table VALUES (1, 'name1'), (2, 'name2'), (3, 'name3'); ``` ``` QUERY PLAN ---------------------------------------------------- Insert on public.test_table (cost=0.00..0.04 rows=0 width=0) (actual time=0.055..0.056 rows=0 loops=1) -> Values Scan on "*VALUES*" (cost=0.00..0.04 rows=3 width=122) (actual time=0.003..0.008 rows=3 loops=1) Output: "*VALUES*".column1, "*VALUES*".column2 Query Identifier: jtkjkexhjotbo Planning Time: 0.068 ms Execution Time: 0.543 ms Statement DPU Estimate: Compute: 0.01550 DPU Read: 0.00307 DPU (Transaction minimum: 0.00375) Write: 0.01875 DPU (Transaction minimum: 0.05000) Total: 0.03732 DPU ``` Pernyataan ini terutama melakukan penulisan, sehingga sebagian besar biaya dikaitkan dengan Tulis DPU. Compute DPU (0,01550) mewakili pekerjaan yang dilakukan untuk memproses dan menyisipkan nilai. DPU Baca (0,00307) mencerminkan pembacaan sistem minor (untuk pencarian katalog atau pemeriksaan indeks). Perhatikan minimum transaksi yang ditunjukkan dalam tanda kurung di sebelah Baca dan Tulis. DPUs Minimum ini berlaku pada tingkat transaksi, artinya total DPU Baca atau Tulis untuk seluruh transaksi tidak pernah kurang dari nilai-nilai ini. Jika Anda menggunakan `EXPLAIN ANALYZE VERBOSE` untuk memperkirakan biaya dan ini adalah satu-satunya pernyataan dalam transaksi, gunakan nilai minimum transaksi daripada perkiraan pernyataan mentah. Jika transaksi berisi beberapa pernyataan, minimum berlaku untuk agregat di semua pernyataan. Karena `EXPLAIN ANALYZE VERBOSE` melaporkan perkiraan tingkat pernyataan saat penagihan berlaku minimum tingkat transaksi, nilainya mungkin tidak sama persis dengan metrik atau data penagihan. CloudWatch ### Menggunakan informasi DPU untuk optimasi Perkiraan DPU per pernyataan memberi Anda cara yang ampuh untuk mengoptimalkan kueri di luar waktu eksekusi. Kasus penggunaan umum meliputi: + **Kesadaran biaya:** Memahami seberapa mahal kueri relatif terhadap orang lain. + **Optimasi skema:** Bandingkan dampak indeks atau perubahan skema pada kinerja dan efisiensi sumber daya. + **Perencanaan anggaran: Perkirakan** biaya beban kerja berdasarkan penggunaan DPU yang diamati. + **Perbandingan kueri:** Evaluasi pendekatan kueri alternatif dengan konsumsi DPU relatifnya. ### Menafsirkan informasi DPU Ingatlah praktik terbaik berikut saat menggunakan data DPU dari`EXPLAIN ANALYZE VERBOSE`: + **Gunakan secara terarah:** Perlakukan DPU yang dilaporkan sebagai cara untuk memahami biaya *relatif* kueri daripada kecocokan persis dengan CloudWatch metrik atau data penagihan. Perbedaan diharapkan karena `EXPLAIN ANALYZE VERBOSE` melaporkan biaya tingkat pernyataan, sementara CloudWatch agregat aktivitas tingkat transaksi. CloudWatch juga mencakup operasi latar belakang (seperti ANALISIS asinkron atau pemadatan) dan overhead transaksi (`BEGIN`/`COMMIT`) yang sengaja dikecualikan. `EXPLAIN ANALYZE VERBOSE` + **Uji dengan data representatif untuk bukti konsep:** Saat menjalankan bukti konsep untuk mengevaluasi biaya, pastikan tabel Anda berisi volume data dan distribusi yang serupa dengan beban kerja produksi yang Anda harapkan. Perkiraan DPU — baik dari `EXPLAIN ANALYZE VERBOSE` atau CloudWatch metrik — yang didasarkan pada tabel kosong atau jarang penduduknya tidak akan mencerminkan biaya dunia nyata. + **Variabilitas DPU di seluruh proses normal** dalam sistem terdistribusi dan tidak menunjukkan kesalahan. Faktor-faktor seperti caching, perubahan rencana eksekusi, konkurensi, operasi latar belakang seperti analisis asinkron, atau pergeseran dalam distribusi data semuanya dapat menyebabkan kueri yang sama mengkonsumsi sumber daya yang berbeda dari satu proses ke yang berikutnya. + **Operasi kecil Batch:** Jika beban kerja Anda mengeluarkan banyak pernyataan kecil, pertimbangkan untuk mengelompokkannya ke dalam operasi penulisan yang lebih besar dalam satu transaksi (modifikasi tidak boleh melebihi 10 MB per transaksi, meskipun pembacaan hanya dibatasi oleh batas waktu transaksi 5 menit). Ini mengamortisasi minimum transaksi di lebih banyak pekerjaan dan menghasilkan perkiraan biaya yang lebih berarti. + **Gunakan untuk penyetelan, bukan penagihan:** Data DPU `EXPLAIN ANALYZE VERBOSE` dirancang untuk kesadaran biaya, penyetelan kueri, dan pengoptimalan. Ini bukan metrik tingkat penagihan. Selalu mengandalkan CloudWatch metrik atau laporan penagihan bulanan untuk biaya otoritatif dan data penggunaan. ## Praktik terbaik estimasi biaya + **Pantau sebelum mengoptimalkan:** Gunakan CloudWatch metrik untuk memahami pola penggunaan Anda saat ini sebelum membuat keputusan pengoptimalan. Lihat perinciannya di [Memantau penggunaan DPU dengan CloudWatch](#billing-cloudwatch-monitoring). + **Fokus pada efisiensi transaksi:** Karena minimum berlaku pada tingkat transaksi, operasi terkait batch bersama-sama untuk mengamortisasi biaya minimum. + **Gunakan EXPLORE ANALYZE VERBOSE selama pengembangan:** Jalankan `EXPLAIN ANALYZE VERBOSE` pada kueri kritis selama pengembangan untuk memahami karakteristik biayanya. Saat menjalankan bukti konsep untuk mengevaluasi biaya, uji terhadap tabel dengan volume dan distribusi data yang representatif — perkiraan berdasarkan tabel kosong atau jarang penduduknya tidak akan mencerminkan biaya produksi. Lihat perinciannya di [Menggunakan EXPLORE ANALYZE VERBOSE untuk kesadaran biaya](#billing-explain-analyze). + **Setel CloudWatch alarm:** Buat alarm pada metrik DPU untuk mendapatkan pemberitahuan tentang lonjakan penggunaan yang tidak terduga.