MySQL Sharding ve MySQL Kümesi

Yalnızca performans göz önüne alındığında , bir MySQL Kümesi MySQL çözümünü parçalayan özel bir veriyi yenebilir mi? parçalama = yatay bölümleme

Parçalamaya atıfta bulunduğumda, örneğin uygulama katmanında yapılan parçalanmayı, örneğin kayıtları bağımsız MySQL örnekleri arasında eşit olarak dağıtmayı düşünüyorum. İki sunucu için olabilir (anahtar mod 2).

Açıklama: MySQL Kümesi üzerinde çalışan bir MySQL çalışanıyım.

MySQL Kümesinin, MySQL + InnoDB'nin kırılandan daha yüksek verim / ana bilgisayar elde edebileceğini söyleyebilirim:

• Sorgular basit
• Tüm veriler hafızaya sığar

Gecikme açısından, MySQL Kümesi, parçalanmış MySQL'den daha kararlı bir gecikmeye sahip olmalıdır. Yalnızca bellek içi veriler için gerçek gecikme benzer olabilir.

Sorgular daha karmaşık hale geldikçe ve veriler diskte depolandıkça, performans karşılaştırması daha karmaşık hale gelir. Daha spesifik bir yanıt almak için, uygulamanız ve gerçekleştirdiğiniz sorgular ile ana bilgisayar sayısı ve veri hacmi hakkında daha fazla bilgi vermeniz gerekir. MySQL Kümesi yakın zamanda paralel yerelleştirilmiş sorgu yürütme (AQL) kazanmıştır.

MySQL Kümesi şu anda 48 ana bilgisayardan 'parçalama' ile sınırlıdır. Parçalanmış MySQL'in teoride sınırı yoktur. Ancak, belirli bir hedef işlem hacmi için, parçalanmış MySQL ana bilgisayarlarından daha az MySQL Kümesi ana bilgisayarı gerekebilir.

Performans dışındaki alanlara baktığınızda daha ilginç farklılıklar vardır:

• MySQL Kümesi tüm kırıklarda rasgele sorguları destekler
• MySQL Kümesi tüm kırıklarda rasgele işlemleri destekler
• MySQL Kümesi, parçaların otomatik yük devretme ve kurtarma ile senkronize çoğaltılmasını destekler
• MySQL Kümesi çevrimiçi ekleme düğümünü (küme genişletme) destekler
• Sharded MySQL, daha çok 'kendiniz yapın'

Uygulamanızın içinde parçalama yapmak size maksimum ölçeklendirme potansiyeli verir, ancak karmaşıklık ekler ve çapraz parça sorguları ve işlemleri açısından esnekliğinizi sınırlar. Parçalarınız erkenyse, sizin için bazı sorunların kökü olabilir. MySQL Kümesi, uygulamanızı yalnızca tek parça olarak sınırlamak zorunda kalmadan parçalamanın bazı avantajlarından yararlanmanızı sağlar.

Önceki cevapla ilgili olarak, birkaç açıklama:

"MySQL Kümesi ACID-şikayeti olsa da, bileşik anahtarlı veriler için uygun bir depolama motoru sağlamaz."

MySQL Kümesi bileşik birincil ve ikincil anahtarları destekler. Bu konuda 'neyin uygun' olmadığından emin değilim. Belki bir önceki poster açıklayabilir?

"Belirli bir veri düğümü kümesinde aynı anahtar özelliklere sahip verilerin depolanması için aşağıdakileri yapabilirsiniz:

1. Yalnızca aynı temel özelliklere sahip verileri barındırmak istediğiniz veri düğümlerini bırakarak tüm veri düğümlerini çevrimdışına alın.
2. Yalnızca seçili veri düğümlerinizi dolduran MySQL Kümesine verilerinizi yükleyin
3. Tüm veri düğümlerini tekrar çevrimiçi duruma getirin "

Bu yanlış. Veri dağıtımı, hangi düğümlerin herhangi bir zamanda çevrimiçi olacağından bağımsızdır. MySQL Kümesi, tanımladığınız optimizasyonları desteklemek için çeşitli veri dağıtım şemalarını destekler. MySQL Kümesi'ndeki veri dağıtımını bir blog yazısında açıklarım: MySQL Kümesi'ndeki veri dağıtımı