MySQL veritabanı hangi noktada performansı kaybetmeye başlar?
Neredeyse 2GB alan yaklaşık 15M kayıtları ile büyük bir veritabanı olduğuna inandığım bir şey var. Bu rakamlara dayanarak, verileri temizlemem için herhangi bir teşvik var mı, yoksa birkaç yıl daha ölçeklendirmeye devam etmesine izin vermem güvenli mi?
Yanıtlar:
Fiziksel veritabanı boyutu önemli değil. Kayıt sayısı önemli değil.
Deneyimlerime göre, çalışacağınız en büyük sorun boyut değil, aynı anda ele alabileceğiniz sorgu sayısıdır. Büyük olasılıkla, okuma sorgularının slave'lere ve yazma sorgularının master'a karşı çalışabilmesi için bir master / slave yapılandırmasına geçmeniz gerekecektir. Ancak henüz buna hazır değilseniz, yanıt sürelerini hızlandırmak için çalıştırdığınız sorgular için dizinlerinizi her zaman değiştirebilirsiniz. Ayrıca, Linux'ta ağ yığınına ve çekirdeğine yapabileceğiniz bir çok ayar var.
Ben sadece ılımlı sayıda bağlantı ile, 10GB kadar benim almak vardı ve istekleri iyi ele.
Önce dizinlerinize odaklanırım, daha sonra işletim sisteminize bir sunucu yöneticisine bakarım ve yardımcı olmayan her şey bir master / slave yapılandırması uygulama zamanı olabilir.
Genel olarak bu çok ince bir konudur ve önemsiz değildir. Mysqlperformanceblog.com ve Yüksek Performanslı MySQL'i okumanızı tavsiye ederim . Gerçekten bunun genel bir cevabı olmadığını düşünüyorum.
Neredeyse 1 TB veri ile MySQL veritabanı olan bir proje üzerinde çalışıyorum. En önemli ölçeklenebilirlik faktörü RAM'dir. Tablolarınızın dizinleri belleğe sığıyorsa ve sorgularınız oldukça optimize edilmişse, ortalama bir makineyle makul miktarda istek sunabilirsiniz.
Kayıt sayısı, tablolarınızın nasıl göründüğüne bağlı olarak önemlidir. Çok fazla varchar alanı veya sadece birkaç ints veya uzunluğa sahip olmak bir fark.
Veritabanının fiziksel boyutu da önemlidir: örneğin yedekleri düşünün. Motorunuza bağlı olarak, fiziksel db dosyalarınız büyür, ancak küçültmeyin, örneğin innodb ile. Bu nedenle, çok sayıda satırı silmek, fiziksel dosyalarınızı küçültmenize yardımcı olmaz.
Bu konularda çok şey var ve çoğu durumda şeytan ayrıntılarda gizlidir.
Veritabanı boyutu önemlidir . Bir milyondan fazla kaydı olan birden fazla tablonuz varsa, performans gerçekten düşmeye başlar. Kayıt sayısı elbette performansı etkiler: MySQL büyük tablolarla yavaş olabilir . Bir milyon rekor vurursanız, endeksler doğru ayarlanmazsa performans sorunları elde edersiniz (örneğin, "WHERE ifadeleri" veya "birleştirme koşullarında" AÇIK koşulları "içindeki alanlar için herhangi bir endeks yoktur). 10 milyon rekor vurursanız, tüm endeksleriniz doğru olsa bile performans problemleri almaya başlayacaksınız. Donanım yükseltmeleri - daha fazla bellek ve daha fazla işlemci gücü, özellikle de bellek - çoğu zaman performansı en azından belirli bir dereceye kadar artırarak en ciddi sorunları azaltmaya yardımcı olur. Örneğin37 sinyal 32 GB RAM'den 128 GB RAM'e Basecamp veritabanı sunucusu için gitti.
Öncelikle dizinlerinize odaklanacağım, bir sunucu yöneticisinin işletim sisteminize bakmasını sağlayın ve yardımcı olmayan her şey bir master / slave yapılandırması için zaman olabilir.
Bu doğru. Genellikle işe yarayan başka bir şey de, tekrar tekrar çalışılan veri miktarını azaltmaktır. "Eski verileriniz" ve "yeni verileriniz" varsa ve sorgularınızın% 99'u yeni verilerle çalışıyorsa, tüm eski verileri başka bir tabloya taşıyın; bakmayın;)
-> Bölümlemeye bir göz atın .
"Veritabanı performansı" hakkında konuşmak anlamsız, "sorgu performansı" burada daha iyi bir terim. Cevap: soruna, üzerinde çalıştığı verilere, dizinlere, donanıma vb. Bağlıdır. EXPLAIN sözdizimi ile kaç satırın taranacağı ve hangi dizinlerin kullanılacağı hakkında bir fikir edinebilirsiniz.
2GB gerçekten "büyük" bir veritabanı olarak sayılmaz - daha çok orta büyüklüktedir.
Şu anda Amazon'un 160 GB'a kadar büyüyen bulut altyapısında bir MySQL veritabanı yönetiyorum. Sorgu performansı iyi. Kabus haline gelen şey yedekleme, geri yükleme, köle ekleme veya tüm veri kümesiyle ilgilenen herhangi bir şey, hatta büyük tablolarda DDL'dir. Bir döküm dosyasının temiz bir şekilde içe aktarılması sorunlu hale geldi. Süreci otomatikleştirecek kadar kararlı hale getirmek için, performansa göre kararlılığa öncelik vermek için çeşitli seçimlerin yapılması gerekiyordu. Bir SQL yedeği kullanarak bir felaketten kurtulmamız gerekirse, günlerce dururduk.
Yatay olarak ölçeklendirmek SQL de oldukça acı vericidir ve çoğu durumda verilerinizi SQL'e koymayı seçtiğinizde muhtemelen istemediğiniz şekillerde kullanmaya yol açar. Kırıklar, okuma köleleri, çoklu-master, ve diğerleri, hepsi DB ile yaptığınız her şeye karmaşıklık katan gerçekten boktan çözümlerdir ve bunlardan biri sorunu çözmez; sadece bazı açılardan hafifletir. Bu tür şeylerin sorun haline geldiği boyuttaki bir veri kümesine yaklaşmaya başladığınızda, bazı verilerinizi MySQL'den (veya gerçekten herhangi bir SQL'den) taşımayı şiddetle öneririm.
Ayrıca karmaşık birleşimlere de dikkat edin. İşlem karmaşıklığı, işlem hacmine ek olarak büyük bir faktör olabilir.
Yoğun sorguları yeniden düzenlemek bazen büyük bir performans artışı sağlar.
Bir kez "çalışmayı durdurdu" bir mysql bakmak için çağrıldı. DB dosyalarının NFS2 ve maksimum 2 GB dosya boyutuna sahip bir Network Appliance dosyasında bulunduğunu keşfettim. Ve tabii ki, işlemleri kabul etmeyi bırakan tablo tam olarak 2GB'dı. Ama performans eğrisiyle ilgili olarak bana hiç çalışmayana kadar bir şampiyon gibi çalıştığını söyledim! Bu deneyim benim için her zaman doğal bir şekilde şüphelendiğiniz boyutun üstünde ve altında boyutlar olduğunu hatırlatmaktadır.
Dikkate alınması gereken bir nokta da sistemin amacı ve günlük verilerdir.
Örneğin, araçların GPS izlemesine sahip bir sistem için, önceki aylarda otomobilin konumlarından gelen sorgu verileri ilgili değildir.
Bu nedenle, veriler olası konsültasyon için diğer geçmiş tablolarına aktarılabilir ve günlük sorguların yürütme sürelerini azaltabilir.
Veritabanı düzgün tasarlanmamışsa, performans birkaç bin satırda düşebilir.
Uygun dizinleriniz varsa, uygun motorları kullanın (birden fazla DML'nin beklendiği yerde MyISAM kullanmayın), bölümleme kullanın, kullanıma bağlı olarak doğru belleği ayırın ve elbette iyi sunucu yapılandırmasına sahip olun, MySQL terabaytlarda bile verileri işleyebilir!
Her zaman veritabanı performansını artırmak için yollar vardır.
Sorgunuza ve doğrulamanıza bağlıdır.
Örneğin, bu tablodaki her ilaç için 15'ten fazla karakter içeren bir sütun genel adına sahip 100.000 ilacın bulunduğu bir tablo ile çalıştım. İki tablo arasındaki ilaçların genel adını karşılaştırmak için bir sorgu koydum. Aynı, ilaçları bir ilaç sütunu kullanarak (yukarıda belirtildiği gibi) ilaç endeksini kullanarak karşılaştırırsanız, sadece birkaç saniye sürer.
Veritabanı boyutu bayt ve tablonun satır sayısı açısından önemlidir. Hafif bir veritabanı ile dolu bir veritabanı arasında büyük bir performans farkı göreceksiniz. Bir kez uygulamam sıkıştı çünkü ben ikili görüntüleri diskteki dosyalarda tutmak ve veritabanına sadece dosya adları koymak yerine alanların içine koymak. Diğer yandan, çok sayıda satırı yinelemek ücretsiz değildir.
Hayır, gerçekten önemli değil. MySQL hızı saniyede yaklaşık 7 Milyon satırdır. Böylece biraz ölçeklendirebilirsiniz
Sorgu performansı temel olarak taraması gereken kayıt sayısına bağlıdır, dizinler bu dizinde yüksek bir rol oynar ve dizin veri boyutu satır sayısı ve dizin sayısı ile orantılıdır.
Dizinlenmiş alan koşullarıyla birlikte tam değer içeren sorgular genellikle 1 ms olarak döndürülür, ancak başlar_with, IN, Arasında, açıkçası daha fazla kayıt ile koşulların daha fazla zaman alacağı taranması daha fazla zaman alabilir.
Ayrıca DDL ile ALTER gibi birçok bakım sorunuyla karşılaşacaksınız, DROP bir dizin veya yeni sütunlar eklemek için bile daha canlı trafik ile yavaş ve zor olacak.
Genel olarak Veritabanını gerektiği kadar küme halinde kümelendirmesi tavsiye edilir (500GB genel bir kıyaslama olacaktır, diğerleri tarafından söylendiği gibi birçok faktöre bağlıdır ve kullanım durumlarına göre değişebilir), böylece daha iyi izolasyon sağlar ve ölçeğe özgü bağımsızlık verir kümeler (B2B durumunda daha uygundur)