Mevcut seçenekler hakkında ÇOK okuma yapıyorum. Ayrıca kesinlikle tavsiye ettiğim Yüksek Performanslı MySQL 2. sürümüne de sahibim.
Bir araya getirmeyi başardığım şey bu:
Kümeleme
Genel anlamda kümeleme, yükü bir dış uygulamaya tek bir sunucu gibi görünen birçok sunucuya dağıtmaktır.
MySQL NDB Kümesi
MySQL NDB Kümesi, eşzamanlı çoğaltma ve otomatik veri bölümleme özelliğine sahip dağıtılmış, bellek içi, paylaşılmayan bir depolama motorudur (kusura bakmayın, Yüksek Performans kitabından tam anlamıyla ödünç alıyorum, ama oraya çok hoş bir şekilde koydular). Bazı uygulamalar için yüksek performanslı bir çözüm olabilir, ancak web uygulaması genellikle bunun üzerinde iyi çalışmaz.
En büyük sorun, çok basit sorguların (yalnızca bir tabloya dokunan) ötesinde, kümenin genellikle birkaç düğümde veri aramak zorunda kalması ve ağ gecikmesinin sorgular için tamamlanma süresini önemli ölçüde yavaşlatmasıdır. Uygulama, kümeyi tek bir bilgisayar olarak ele aldığından, verileri hangi düğümden alacağını söyleyemez.
Ek olarak, bellek içi gereksinimi birçok büyük veritabanı için uygulanabilir değildir.
Kıta Sekoya
Bu, MySQL sunucusunun üstünde bir ara katman yazılımı görevi gören MySQL için başka bir kümeleme çözümüdür. Eşzamanlı çoğaltma, yük dengeleme ve yük devretme sunar. Ayrıca, isteklerin her zaman verileri en son kopyadan almasını ve yeni verilere sahip bir düğümü otomatik olarak seçmesini sağlar.
Üzerinde güzel şeyler okudum ve genel olarak oldukça umut verici geliyor.
Federasyon
Federasyon kümelemeye benzer, bu yüzden burada da çektim. MySQL, birleşik depolama motoru aracılığıyla federasyon sunar. NDB küme çözümüne benzer şekilde, yalnızca basit sorgularla iyi çalışır - ancak karmaşık olanlar için küme daha da kötüdür (çünkü ağ gecikmesi çok daha yüksektir).
Çoğaltma ve yük dengeleme
MySQL, farklı sunucularda bir veritabanının kopyalarını oluşturmak için yerleşik kapasiteye sahiptir. Bu birçok şey için kullanılabilir - yükü sunucular arasında bölmek, sıcak yedeklemeler, test sunucuları oluşturmak ve yük devretme.
Çoğaltmanın temel kurulumu, çoğunlukla yazma işlemlerini ve yalnızca okumaları işlemeyi bir veya daha fazla ikincil sunucunun işlemesini içerir. Daha gelişmiş bir varyasyon, aynı anda birden fazla sunucu yazarak yazma işlemlerini ölçeklendirmeye izin veren ana-ana yapılandırmanın varyasyonudur .
Her yapılandırmanın avantajları ve dezavantajları vardır, ancak hepsinin paylaştığı bir sorun, çoğaltma gecikmesidir - MySQL çoğaltma eşzamansız olduğundan, tüm düğümler her zaman en yeni verilere sahip değildir. Bu, uygulamanın çoğaltmanın farkında olmasını ve beklendiği gibi çalışması için çoğaltmaya duyarlı sorguları dahil etmesini gerektirir. Bazı uygulamalar için bu bir sorun olmayabilir, ancak her zaman en yeni verilere ihtiyacınız varsa işler biraz karmaşıklaşır.
Çoğaltma, yükü düğümler arasında bölmek için biraz yük dengeleme gerektirir. Bu, uygulama kodunda yapılan bazı değişiklikler veya özel yazılım ve donanım çözümleri kullanmak kadar basit olabilir.
Parçalama ve bölme
Sharding, veritabanı çözümlerini ölçeklendirmek için yaygın olarak kullanılan bir yaklaşımdır. Verileri daha küçük parçalara böler ve farklı sunucu düğümlerine dağıtırsınız. Bu, uygulamanın, ihtiyaç duyduğu bilgileri nerede bulacağını bilmesi gerektiğinden, verimli bir şekilde çalışması için veri depolamasında yapılan değişikliklerin farkında olmasını gerektirir.
Hibernate ORM'nin bir uzantısı olan Hibernate Shards (maalesef Java'da. PHP kullanıyorum) gibi veri parçalama ile başa çıkmaya yardımcı olacak soyutlama çerçeveleri mevcuttur . HiveDB , parça yeniden dengelemesini de destekleyen başka bir çözümdür.
Diğerleri
Sfenks
Sphinx , test aramalarından çok daha fazlası için kullanılabilen tam metin arama motorudur. Birçok sorgu için MySQL'den çok daha hızlıdır (özellikle gruplama ve sıralama için) ve uzaktaki sistemleri paralel olarak sorgulayabilir ve sonuçları bir araya getirebilir - bu da onu parçalama ile kullanımda çok yararlı kılar.
Genel olarak sfenks, mevcut donanım ve altyapının daha fazlasını elde etmek için diğer ölçeklendirme çözümleriyle birlikte kullanılmalıdır. Olumsuz yanı, sfenks'in akıllıca kullanılması için uygulama kodunun farkında olmanız gerektiğidir.
Özet
Ölçeklendirme çözümleri, ihtiyaç duyan uygulamanın ihtiyaçlarına göre farklılık gösterir. Bizim için ve çoğu web uygulaması için, çoğaltmanın (muhtemelen çoklu ana bilgisayar) yükü dağıtan bir yük dengeleyiciyle gitmenin yolu olduğuna inanıyorum. Belirli sorun alanlarının (büyük tablolar) parçalanması da yatay olarak ölçeklenebilmesi için bir zorunluluktur.
Ayrıca Continuent Sequoia'ya bir şans vereceğim ve uygulama kodunda en az miktarda değişiklik içereceği için söz verdiği şeyi gerçekten yapıp yapamayacağına bakacağım.