Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Beban gudang

Meningkatkan waktu respons dan meningkatkan sumber daya yang tersedia untuk alur kerja penting mungkin memerlukan penghapusan beban asing. Banyak solusi yang tercakup dalam bagian ini adalah keputusan trade-off. Mereka memiliki konsekuensi terhadap aplikasi, dan mereka harus dipertimbangkan dengan cermat. Pertimbangkan ini menggunakan solusi ini dalam situasi berikut:

Perubahan langsung meliputi yang berikut:

Sebelum melakukan tindakan ini, evaluasi mereka dalam konteks tujuan dan risiko bisnis jangka panjang.

Pisahkan beban kerja baca dan tulis

Teknik umum saat menjalankan aplikasi yang didukung oleh MySQL adalah dengan membongkar operasi baca dari instance database penulis (primer) dan ke satu atau lebih replika database read-only. Dengan membongkar pembacaan, Anda dapat mengurangi beban keseluruhan pada instance database utama dan memberi ruang untuk penulisan. Pastikan untuk menargetkan hanya pembacaan yang tidak bergantung pada read-after-writekonsistensi langsung untuk replika. Pendekatan yang lebih efisien adalah memindahkan semua lalu lintas baca ke replika dan berencana untuk mencoba kembali jika read-after-write terjadi penundaan replikasi. Ada beban kerja baca independen yang dapat diturunkan, seperti layanan pelaporan. Pembacaan lain akan memerlukan perubahan pada tingkat aplikasi, di mana konteks mengapa pembacaan dikeluarkan sudah diketahui dengan baik.

Pendekatan alternatif adalah menerapkan solusi proxy database sebagai perantara antara aplikasi dan database, yang dapat menyediakan fungsi pemisahan baca-tulis dan perutean kueri, tanpa kesadaran aplikasi. ProxySQL, MariaDB, ScaleArc MaxScaledan Heimdall Data adalah beberapa solusi proxy kompatibel MySQL yang tersedia. Produk ini menawarkan beberapa fitur tambahan, seperti caching atau multiplexing koneksi. Ketika Anda mengalami lonjakan lalu lintas yang tiba-tiba dan menerapkan teknologi baru di tumpukan aplikasi Anda, sebaiknya mulai dengan fungsionalitas dasar untuk memisahkan read/write kueri dan menguji perilaku dan kinerja sebelum menggunakan fitur tambahan yang mungkin memiliki efek samping yang tidak diinginkan.

Arsipkan atau bersihkan data lama

Teknik lain untuk meningkatkan kinerja database adalah dengan membongkar data historis ke tabel lain, database, atau Amazon Simple Storage Service (Amazon S3). Banyak database menyimpan semua data sebaris untuk seluruh riwayat aplikasi. Dalam keadaan normal dalam aplikasi yang dihadapi pengguna biasa, ini memberi pengguna kemampuan untuk melihat semua pesanan historis mereka. Ketika permintaan melonjak tiba-tiba, banyak pengguna yang aktif pada aplikasi mungkin baru atau fokus untuk menempatkan pesanan baru. Jika data historis berada online, dalam satu tabel yang berisi miliaran baris, senyawa ini. Tabel tersebut kemungkinan juga memiliki indeks yang besar. Baik data tabel dan indeks disimpan dalam struktur pohon. Memiliki lebih banyak entri dalam tabel membutuhkan lebih banyak level pada pohon, yang membutuhkan lebih banyak I/O operasi untuk mengakses baris. Ini meningkatkan waktu akses untuk menemukan catatan individu. Lebih penting lagi, ini menyebabkan sebagian besar indeks yang tidak dibutuhkan menjadi penduduk di cache halaman database (kumpulan buffer InnoDB).

Mengarsipkan data lama ke tabel terpisah, database terpisah, atau Amazon S3 dapat mengurangi waktu akses bagi pengguna akhir, membebaskan cache berharga, dan meningkatkan kinerja aplikasi secara keseluruhan. Mengarsipkan data yang lebih lama, sebelum acara (misalnya, mempertahankan hanya 30 atau 90 hari) membatasi ukuran tabel dan indeks pada tabel kritis. Perubahan ini mengharuskan aplikasi dimodifikasi untuk menanyakan data lama dari lokasi sekunder hanya untuk sebagian kecil pengguna yang secara eksplisit meminta untuk melihat data historis.

Menunda proses ETL yang tidak kritis

Ekstraksi dari sistem database utama untuk proses ETL dapat menghadirkan risiko stabilitas untuk beban kerja yang sangat transaksional dan bersamaan selama kondisi hyperscale. Proses ETL dikenal dengan karakteristik berikut:

Proses ETL yang bervariasi atau tidak dapat diprediksi (misalnya, kueri seperti INSERT INTO ... SELECT FROM ...;) menambah variabilitas keseluruhan dalam beban dan pertengkaran, meningkatkan risiko stabilitas.

Jika memungkinkan, tunda atau kurangi frekuensi di mana proses ETL berjalan, terutama jika mereka tidak menyediakan fungsi penting. Untuk proses ETL kritis, modifikasi mereka sehingga mereka beroperasi dalam unit kerja terbatas, seperti batch pemrosesan jumlah baris tetap (misalnya, menggunakan LIMIT klausa), menggunakan transaksi terpisah, atau menarik sejumlah kecil data selama periode waktu yang lama untuk mengurangi permintaan sumber daya puncak dari instans DB.

Matikan fitur aplikasi yang kurang kritis

Dengan anggun merendahkan pengalaman pengguna atau menghapus fitur noncore saat menangani lonjakan permintaan menghemat sumber daya database untuk fungsi penting. Ini mungkin memerlukan sedikit perubahan dalam pengalaman pelanggan, tetapi aliran yang berbeda lebih baik daripada situs yang sedang down. Mungkin personalisasi di halaman depan situs yang selalu melakukan panggilan database dapat dinonaktifkan sementara. Atau Anda dapat berhenti menyajikan penawaran khusus kepada pelanggan yang kembali saat memilih produk. Mematikan sementara fitur dapat memungkinkan halaman untuk di-cache atau dikirimkan tanpa memerlukan akses database.

Contoh lain termasuk frontend yang memiliki mekanisme polling memeriksa perubahan data yang memerlukan panggilan database. Mengurangi frekuensi polling akan segera menghasilkan lebih sedikit panggilan database. Antarmuka pengguna yang memerlukan pagination atau memberi pengguna opsi untuk mengambil set hasil yang diurutkan lebih jauh dari hasil teratas memerlukan panggilan database yang semakin mahal. Batasi jumlah halaman dalam set hasil untuk melindungi database dari panggilan database yang paling mahal. Gunakan bendera fitur di lapisan aplikasi untuk memungkinkan tim operasi mematikan atau menurunkan fitur saat beban aplikasi atau basis data meningkat.