Bagaimana ukuran basis data memengaruhi kinerja: Teori vs kenyataan

Ada banyak hal di luar sana yang mengatakan bahwa ukuran basis data seharusnya tidak memengaruhi kinerja hingga tingkat yang luar biasa. Selama indeks pada tabel sesuai dengan memori, basis data harus tetap berkinerja baik.

Namun apa kenyataannya? Jika arsitektur database bukan yang terbaik, indeks tidak sesuai dengan memori, dan ada potensi banyak data yang berlebihan apakah ada keuntungan signifikan yang bisa dibuat hanya dengan menghapus data yang berlebihan? Saya memperkirakan bahwa 60-80% data dalam basis data saya dapat dihapus.

Saya percaya bahwa mengurangi ukuran basis data dan meningkatkan RAM sehingga indeks dapat masuk dalam memori akan memberikan peningkatan kinerja yang signifikan yang akan memberikan ruang bernapas selama beberapa bulan untuk menata ulang sistem.

Apakah ada juga faktor-faktor lain seperti IO, fragmentasi, dataset dll yang mempengaruhi kinerja berdasarkan ukuran basis data?

Itu sepenuhnya tergantung pada apa yang Anda lakukan dengan data.

Untuk dasar memasukkan / memperbarui / menghapus transaksi yang memengaruhi hanya beberapa baris, maka pertumbuhan ukuran data mungkin bukan pertimbangan besar. Basis data akan menggunakan indeks dalam memori untuk mengakses halaman yang benar. Anda mendapatkan lebih banyak cache cache ketika tabel tidak lagi sesuai dengan memori. Namun, overhead mungkin sedikit - tergantung pada database, konfigurasi database, dan konfigurasi perangkat keras.

Jika Anda melakukan kueri yang memerlukan pemindaian tabel penuh, maka kinerja Anda akan tumbuh secara linear atau lebih buruk dengan ukuran data. Indeks benar-benar dapat membuat situasi lebih buruk, dengan mengacak akses halaman, yang kemudian menjamin cache hilang.

Alternatif untuk lebih banyak memori ditingkatkan kecepatan disk - disk solid state dapat memberikan peningkatan luar biasa.

Hanya memiliki lebih banyak data tidak akan memengaruhi kinerja kecuali tabel digunakan dalam kueri. Apakah data tersebut berlebihan dalam suatu tabel atau lintas tabel? Memiliki tabel besar yang tidak pernah digunakan itu berantakan, tetapi memiliki dampak minimal pada kinerja. Dapat dibayangkan bahwa jika Anda memiliki miliaran tabel yang tidak perlu, maka kompilasi pertanyaan dapat mulai memakan waktu lebih banyak.

Aturan penyetelan nomor satu AMM (Add More Memory) sederhana. Ini juga salah satu yang sangat mahal dan pada akhirnya yang tidak efektif ketika ada masalah dalam selektivitas. Sekalipun sebuah basis data benar-benar sesuai dengan memori, kinerja aplikasi bisa buruk. Dalam skenario terburuk karena mengunci dan mengunci selama eksekusi SQL yang sangat selektif. Itu harus diperbaiki dulu. Salah satu alasannya adalah konkurensi yang seperti memukul - dan menahan - istirahat jika setiap SQL mengakses semua data dalam tabel setiap waktu.

Pastikan tidak ada SQL mengakses lebih banyak baris dari yang dibutuhkan. Itu adalah memberikan cara paling efektif untuk menjaga kinerja tetap baik. Database normal tahu cara menangani io dan melakukan beberapa bentuk caching dari data yang paling sering digunakan.

Jika aplikasi Anda telah meminimalkan semua kemungkinan akses, dan Anda sudah menggunakan sistem disk tercepat, pertimbangkan untuk menggunakan array memori flash nyata. Mereka dapat meningkatkan kinerja di level lain.

Silakan lihat posting ini:

• Seberapa besar basis data MySQL sebelum kinerja mulai menurun
• Mengapa MySQL bisa lambat dengan tabel besar?

Petunjuk untuk membuat Data Anda Sekecil Mungkin:

Rancang tabel Anda untuk meminimalkan ruang pada disk. Ini dapat menghasilkan peningkatan besar dengan mengurangi jumlah data yang ditulis dan dibaca dari disk. Tabel yang lebih kecil biasanya membutuhkan lebih sedikit memori utama saat isinya sedang diproses secara aktif selama eksekusi permintaan. Setiap pengurangan ruang untuk data tabel juga menghasilkan indeks yang lebih kecil yang dapat diproses lebih cepat.

MySQL mendukung berbagai mesin penyimpanan (tipe tabel) dan format baris. Untuk setiap tabel, Anda dapat memutuskan metode penyimpanan dan pengindeksan mana yang akan digunakan. Memilih format tabel yang tepat untuk aplikasi Anda dapat memberi Anda keuntungan kinerja yang besar.

Anda bisa mendapatkan kinerja yang lebih baik untuk tabel dan meminimalkan ruang penyimpanan dengan menggunakan teknik yang tercantum di sini: - Gunakan tipe data yang paling efisien (terkecil). MySQL memiliki banyak tipe khusus yang menghemat ruang disk dan memori. Misalnya, gunakan tipe integer yang lebih kecil jika mungkin untuk mendapatkan tabel yang lebih kecil. MEDIUMINT seringkali merupakan pilihan yang lebih baik daripada INT karena kolom MEDIUMINT menggunakan 25% lebih sedikit ruang.

• Nyatakan kolom untuk TIDAK NULL jika memungkinkan. Itu membuat semuanya lebih cepat dan Anda menghemat satu bit per kolom. Jika Anda benar-benar membutuhkan NULL dalam aplikasi Anda, Anda harus menggunakannya. Hanya menghindari memilikinya di semua kolom secara default.

• Untuk tabel MyISAM, jika Anda tidak memiliki kolom panjang variabel (VARCHAR, TEXT, atau BLOB), format baris ukuran tetap digunakan.

• Tabel InnoDB menggunakan format penyimpanan ringkas. Dalam versi MySQL lebih awal dari 5.0.3, baris InnoDB berisi beberapa informasi yang berlebihan, seperti jumlah kolom dan panjang setiap kolom, bahkan untuk kolom ukuran tetap. Secara default, tabel dibuat dalam format ringkas (ROW_FORMAT = COMPACT). Kehadiran format baris kompak mengurangi ruang penyimpanan baris sekitar 20% dengan biaya peningkatan penggunaan CPU untuk beberapa operasi. Jika beban kerja Anda adalah tipikal yang dibatasi oleh tingkat hit cache dan kecepatan disk, itu kemungkinan akan lebih cepat. Jika ini adalah kasus yang jarang terjadi yang dibatasi oleh kecepatan CPU, mungkin lebih lambat.

Format InnoDB yang ringkas juga mengubah cara kolom CHAR yang berisi data UTF-8 disimpan. Dengan ROW_FORMAT = REDUNDANT, UTF-8 CHAR (N) menempati 3 × N byte, mengingat bahwa panjang maksimum karakter yang dikodekan UTF-8 adalah tiga byte. Banyak bahasa dapat ditulis terutama menggunakan karakter single-byte UTF-8, sehingga panjang penyimpanan yang tetap sering menghabiskan ruang. Dengan ROW_FORMAT = format COMPACT, InnoDB mengalokasikan jumlah penyimpanan variabel dalam rentang dari N hingga 3 × N byte untuk kolom ini dengan menghapus spasi tambahan jika perlu. Panjang penyimpanan minimum disimpan sebagai N byte untuk memfasilitasi pembaruan di tempat dalam kasus-kasus tertentu.

• Indeks utama tabel harus sesingkat mungkin. Ini membuat identifikasi setiap baris mudah dan efisien

• Buat hanya indeks yang benar-benar Anda butuhkan. Indeks baik untuk pengambilan tetapi buruk saat Anda perlu menyimpan data dengan cepat. Jika Anda mengakses tabel sebagian besar dengan mencari pada kombinasi kolom, buat indeks pada mereka. Bagian pertama dari indeks adalah kolom yang paling banyak digunakan. Jika Anda selalu menggunakan banyak kolom saat memilih dari tabel, kolom pertama dalam indeks haruslah yang memiliki duplikat terbanyak untuk mendapatkan kompresi indeks yang lebih baik.

• Dalam beberapa keadaan, akan bermanfaat untuk membagi menjadi dua tabel yang dipindai sangat sering. Ini terutama benar jika itu adalah tabel format dinamis dan dimungkinkan untuk menggunakan tabel format statis yang lebih kecil yang dapat digunakan untuk menemukan baris yang relevan saat memindai tabel.