Pada titik apa database MySQL mulai kehilangan kinerja?
Saya memiliki apa yang saya yakini sebagai basis data besar, dengan sekitar 15 juta catatan yang menghabiskan hampir 2GB. Berdasarkan angka-angka ini, apakah ada insentif bagi saya untuk membersihkan data, atau apakah saya aman untuk membiarkannya melanjutkan penskalaan untuk beberapa tahun lagi?
Jawaban:
Ukuran basis data fisik tidak masalah. Jumlah catatan tidak masalah.
Dalam pengalaman saya, masalah terbesar yang akan Anda hadapi bukanlah ukuran, tetapi jumlah kueri yang bisa Anda tangani sekaligus. Kemungkinan besar Anda harus pindah ke konfigurasi master / slave sehingga kueri baca dapat berjalan melawan para budak dan kueri penulisan dijalankan melawan master. Namun jika Anda belum siap untuk ini, Anda selalu dapat mengubah indeks Anda untuk kueri yang Anda jalankan untuk mempercepat waktu respons. Juga ada banyak penyesuaian yang dapat Anda lakukan untuk tumpukan jaringan dan kernel di Linux yang akan membantu.
Saya telah mendapatkan milik saya hingga 10GB, dengan hanya sejumlah koneksi moderat dan itu menangani permintaan dengan baik.
Saya akan fokus dulu pada indeks Anda, kemudian minta admin server melihat OS Anda, dan jika semua itu tidak membantu mungkin sudah waktunya untuk mengimplementasikan konfigurasi master / slave.
Secara umum ini adalah masalah yang sangat halus dan tidak sepele sama sekali. Saya mendorong Anda untuk membaca mysqlperformanceblog.com dan MySQL Kinerja Tinggi . Saya benar-benar berpikir tidak ada jawaban umum untuk ini.
Saya sedang mengerjakan proyek yang memiliki database MySQL dengan data hampir 1TB. Faktor skalabilitas yang paling penting adalah RAM. Jika indeks tabel Anda sesuai dengan memori dan kueri Anda sangat dioptimalkan, Anda dapat melayani jumlah permintaan yang wajar dengan mesin rata-rata.
Jumlah catatan memang penting, tergantung bagaimana tabel Anda terlihat. Bedanya memiliki banyak bidang varchar atau hanya beberapa int atau panjang.
Ukuran fisik dari basis data juga penting: pikirkan tentang cadangan, misalnya. Tergantung pada mesin Anda, file db fisik Anda tumbuh, tetapi jangan menyusut, misalnya dengan innodb. Jadi menghapus banyak baris, tidak membantu mengecilkan file fisik Anda.
Ada banyak masalah ini dan seperti dalam banyak kasus iblis ada dalam rinciannya.
Ukuran basis data memang penting . Jika Anda memiliki lebih dari satu tabel dengan lebih dari satu juta catatan, maka kinerja mulai menurun. Jumlah catatan tentu saja mempengaruhi kinerja: MySQL bisa lambat dengan tabel besar . Jika Anda menekan satu juta rekaman, Anda akan mendapatkan masalah kinerja jika indeks tidak disetel dengan benar (misalnya tidak ada indeks untuk bidang dalam "pernyataan WHERE" atau "kondisi ON" dalam gabungan). Jika Anda mencapai 10 juta catatan, Anda akan mulai mendapatkan masalah kinerja meskipun Anda memiliki semua indeks dengan benar. Pembaruan perangkat keras - menambah lebih banyak memori dan lebih banyak daya prosesor, terutama memori - sering membantu mengurangi masalah paling parah dengan meningkatkan kinerja lagi, setidaknya sampai tingkat tertentu. Sebagai contoh37 sinyal beralih dari 32 GB RAM ke 128GB RAM untuk server database Basecamp.
Saya akan fokus dulu pada indeks Anda, daripada meminta admin server melihat OS Anda, dan jika semua itu tidak membantu mungkin sudah waktunya untuk konfigurasi master / slave.
Itu benar. Hal lain yang biasanya berhasil adalah mengurangi jumlah data yang berulang kali digunakan. Jika Anda memiliki "data lama" dan "data baru" dan 99% kueri Anda berfungsi dengan data baru, cukup pindahkan semua data lama ke tabel lain - dan jangan melihatnya;)
-> Lihatlah partisi .
Agak ada gunanya membicarakan "kinerja basis data", "kinerja permintaan" adalah istilah yang lebih baik di sini. Dan jawabannya adalah: itu tergantung pada kueri, data yang beroperasi, indeks, perangkat keras, dll. Anda bisa mendapatkan ide tentang berapa baris yang akan dipindai dan indeks apa yang akan digunakan dengan sintaks EXPLAIN.
2GB tidak benar-benar dianggap sebagai basis data "besar" - ini lebih dari ukuran sedang.
Saat ini saya mengelola database MySQL pada infrastruktur cloud Amazon yang telah tumbuh hingga 160 GB. Performa query baik-baik saja. Apa yang menjadi mimpi buruk adalah mencadangkan, mengembalikan, menambah budak, atau apa pun yang berhubungan dengan seluruh dataset, atau bahkan DDL pada tabel besar. Mendapatkan impor file dump yang bersih menjadi masalah. Untuk membuat proses cukup stabil untuk diotomatisasi, berbagai pilihan perlu dibuat untuk memprioritaskan stabilitas daripada kinerja. Jika kami harus pulih dari bencana menggunakan cadangan SQL, kami akan turun selama berhari-hari.
Scaling horizontal SQL juga cukup menyakitkan, dan dalam banyak kasus mengarah ke menggunakannya dengan cara yang Anda mungkin tidak bermaksud ketika Anda memilih untuk meletakkan data Anda di SQL di tempat pertama. Pecahan, baca budak, multi-master, dan lain-lain, mereka semua adalah solusi yang benar-benar menyebalkan yang menambah kompleksitas pada semua yang pernah Anda lakukan dengan DB, dan tidak satu pun dari mereka menyelesaikan masalah; hanya mengurangi dalam beberapa hal. Saya sangat menyarankan melihat memindahkan beberapa data Anda dari MySQL (atau benar-benar SQL) ketika Anda mulai mendekati dataset dengan ukuran di mana hal-hal semacam ini menjadi masalah.
Juga hati-hati untuk bergabung kompleks. Kompleksitas transaksi dapat menjadi faktor besar selain volume transaksi.
Refactoring pertanyaan berat terkadang menawarkan peningkatan kinerja besar.
Saya pernah dipanggil untuk melihat mysql yang telah "berhenti bekerja". Saya menemukan bahwa file DB berada di filer Network Appliance terpasang dengan NFS2 dan dengan ukuran file maksimum 2GB. Dan tentu saja, tabel yang berhenti menerima transaksi persis sebesar 2GB pada disk. Tetapi sehubungan dengan kurva kinerja saya diberitahu bahwa itu bekerja seperti juara sampai itu tidak bekerja sama sekali! Pengalaman ini selalu bermanfaat bagi saya sebagai pengingat yang baik bahwa selalu ada dimensi di atas dan di bawah yang Anda duga.
Poin yang perlu dipertimbangkan juga adalah tujuan sistem dan data dalam sehari-hari.
Misalnya, untuk sistem dengan pemantauan GPS mobil tidak relevan dengan data permintaan dari posisi mobil pada bulan-bulan sebelumnya.
Oleh karena itu, data dapat dikirimkan ke tabel historis lainnya untuk kemungkinan konsultasi dan mengurangi waktu eksekusi dari kueri sehari-hari.
Kinerja dapat menurun dalam hitungan beberapa ribu baris jika basis data tidak dirancang dengan benar.
Jika Anda memiliki indeks yang tepat, gunakan mesin yang tepat (jangan gunakan MyISAM di mana beberapa DML diharapkan), gunakan partisi, alokasikan memori yang benar tergantung pada penggunaan dan tentu saja memiliki konfigurasi server yang baik, MySQL dapat menangani data bahkan dalam terabyte!
Selalu ada cara untuk meningkatkan kinerja database.
Itu tergantung pada permintaan dan validasi Anda.
Misalnya, saya bekerja dengan tabel 100.000 obat yang memiliki nama generik kolom di mana ia memiliki lebih dari 15 karakter untuk setiap obat dalam tabel itu. Saya menaruh kueri untuk membandingkan nama obat generik antara dua tabel. Permintaan mengambil menit lagi untuk berjalan. Sama, jika Anda membandingkan obat menggunakan indeks obat, menggunakan kolom id (seperti yang disebutkan di atas), hanya perlu beberapa detik.
Ukuran basis data TIDAK penting dalam hal byte dan nomor baris tabel. Anda akan melihat perbedaan kinerja yang sangat besar antara database yang ringan dan yang diisi dengan gumpalan. Setelah aplikasi saya macet karena saya meletakkan gambar biner di dalam bidang alih-alih menyimpan gambar dalam file pada disk dan hanya menempatkan nama file dalam database. Di sisi lain, mengulang sejumlah besar baris tidak gratis.
Tidak itu tidak masalah. Kecepatan MySQL sekitar 7 Juta baris per detik. Jadi Anda bisa menskalakannya sedikit
Kinerja kueri terutama tergantung pada jumlah catatan yang perlu dipindai, indeks memainkan peran tinggi di dalamnya dan ukuran data indeks sebanding dengan jumlah baris dan jumlah indeks.
Kueri dengan kondisi bidang yang diindeks bersama dengan nilai penuh akan dikembalikan dalam 1 ms secara umum, tetapi begin_with, IN, Di antara, jelas berisi kondisi yang mungkin memerlukan lebih banyak waktu dengan lebih banyak catatan untuk dipindai.
Anda juga akan menghadapi banyak masalah pemeliharaan dengan DDL, seperti ALTER, DROP akan lambat dan sulit dengan lebih banyak lalu lintas langsung bahkan untuk menambahkan indeks atau kolom baru.
Secara umum disarankan untuk mengelompokkan Database menjadi sebanyak mungkin cluster yang diperlukan (500GB akan menjadi patokan umum, seperti yang dikatakan oleh orang lain itu tergantung pada banyak faktor dan dapat bervariasi berdasarkan pada kasus penggunaan) dengan cara itu memberikan isolasi yang lebih baik dan memberikan independensi pada skala spesifik cluster (lebih cocok untuk B2B)