Yüksek Eşzamanlı, Yüksek Yazma DB Altyapısı

Gereksinimlerim:

• 3000 Bağlantılar
• % 70-85 Yazma vs Okuma

Şu anda, 700 bağlantıda bir Yüksek CPU, Ekstra Büyük Örnek'i maksimize ediyoruz. 8 çekirdeğin tümü maks. Bellek iyi olduğundan eşzamanlı bağlantı sayısı olduğunu düşünüyoruz. Yazmanın kendisi çok basittir (validasyonlar yavaş şeyler). 3000'e ölçeklendirmek için birden fazla sunucuya, mevcut seçeneklere gitmemiz gerekiyor:

• MySQL Parçalaması
• MongoDB Kümesi
• kötü olayları önceden haber veren kimse
• Hadoop ve MySQL (Hadoop önbellekleri, MySQL'e tek dökümü)
• MongoDB ve MySQL (Hadoop yerine önbellek için mongo kullanıyoruz)

Bu sayıda bağlantıyı ele almak için bir dizi soru:

1. MySQL Sharding eşzamanlı bağlantıları işleyebilir mi?
2. Tek bir master bu eşzamanlı bağlantıları idare edebilir mi, yoksa Mongo gibi çok kafalı daha iyi bir seçenek midir?

Sorunumu iyi tanımlamazsam özür dilerim. Lütfen sorular sorun.

Ana veritabanı olarak MySQL kullanıyorsanız, MySQL Çoğaltma yoluyla bir Yıldız Topolojisi kullanmayı düşünebilirsiniz.

Şimdi, UGHHH, ROFL ve OMG'yi MySQL Replication'a söylemeden önce beni dinleyin.

Yıldız topolojisi bir DB sunucusuna (Dağıtım Mster [DM] adı verilir) yazmanıza ve SQL komutlarını birkaç DB sunucusuna göndermenize olanak tanır. Böyle bir DB altyapısını nasıl kurarsınız?

İşte Açıklama

5 DB sunucunuz var (sunucu A, B, C, D, E)

Sunucu A

• MySQL Replication kurulumunda Master olacak
• DM olarak özel bir rol oynar
• B, C, D, E sunucularının yöneticisi
• Tüm tablolar BLACKHOLE (/ dev / null) depolama motorunu kullanır
• Yalnızca ikili günlükleri depolar
• Çıplak Metal Makinesi
• Yararları
  • DM'deki tüm tablolar BLACKHOLE kullandığından çok hızlı yazıyor
  • Okumalar DB Etkinliğinin% 15-30'u olduğundan Ağ Gecikmesi daha az sorun yaratır
  • Tüm köleler kesinlikle DM'den güncellenir

Sunucular B, C, D, E

• Köle bu bir
• Ağır SELECT'ler için bir taban sunucu
• Sunucu Sanal veya Çıplak Metal Olabilir
• Kullanıcı tabloları InnoDB depolama motorunu kullanan tüm sunucular için
  • Sıcak bir bekleme DB Server olarak sunucu olabilir
  • Araya girmeyen yedekler çalıştırılabilir
• Kullanıcı tabloları MyISAM depolama motorunu kullanan tüm sunucular için
  • Salt okunur seçenekle kurulum
  • Tablolar okumaları hızlandırmak için satır biçimlerini yeniden yapabilir

Bu konuda daha önce yazı yazdım

• /server/264374/mysql-in-star-topology/264444#264444
• /programming/5273043/mysql-in-star-topology/5781504#5781504

MySQL Çoğaltmasını en üstte tutmak için

• MySQL 5.5 kullanın
• Yarı Senkronize Çoğaltma Kullan
• InnoDB'yi daha fazla CPU ile çalışacak şekilde ayarlayın

MySQL Kümesi, parçalamaya başka bir yaklaşım olabilir. Gönderiyi buradan kontrol edin .

Ben de Cassandra'nın büyük bir hayranıyım, ancak veri modelinize ve gerçekleştirmek istediğiniz sorgulara çok bağlı. Cassandra hızlı yazıyor, çünkü her zaman diskte sıralılar.

Eğer çok başlı gidecekseniz (muhtemelen 3K aktif bağlantıya ihtiyacınız varsa, muhtemelen Riak veya belki Cassandra'ya bakarsınız). Bu, uygulamanızın ne kadar iyi uyduğuna bağlı olarak ne yaptığına bağlıdır, ancak tarif ettiğinizden Riak gibi bir şeye sığacağını düşünüyorum.

Bununla birlikte, verileri segmentlere ayırmanın iyi bir yolunu bulabilir ve çapraz kırık parçalarına olan ihtiyacı en aza indirebilirseniz, parçalanmış bir yaklaşım oldukça yapılabilir görünüyor. Ben mysql içinde halka / yıldız / mmm şeyler uzak kalmak ve sadece düz parçalama için sopa. Aslında, Postgres'i kullanmaya istekli olsaydınız, heroku gibi bir şeyde şemalar kullanarak kolayca prototip yapabilir ve daha sonra tek tek düğümleri büyütmeye başlarken veritabanlarını çatallayabilir ve bölebilirsiniz.

Oh, ve böyle bir şeyi dikey olarak ölçeklemeye çalışabileceğinizi düşünürken (tüm 3K konilerini işleyen tek düğüm), bulutta yapabileceğinizi sanmıyorum.

Özel uygulamanız için bir seçenekse, veritabanınıza (iş kuyruğu, toplu ekler ...) veri yazmak ve / veya önündeki bazı proxy'lerle birçok istemci bağlantısını veritabanınızdan kaldırmak için eşzamansız bir yol kullanabilirsiniz. .

Parçalama ile genellikle iyi ölçeklendirebilirsiniz (2x db-sunucular == 2x bağlantı), ancak veri kümenizin doğasına ve parçalara nasıl ayırabileceğinize bağlıdır.

Ben kişisel olarak yönetim kolaylığı, ölçeklenebilirliği, genel kullanım kolaylığı nedeniyle MongoDB'yi tercih ediyorum. Ayrıca, aslında bir RDBMS gerekmedikçe, bir no-SQL kullanacağım.

Bununla birlikte, uygulamanız için en anlamlı DB'yi seçin. İşlemlere ihtiyacınız varsa veya uygulamanızı Katılmadan tasarlayamıyorsanız (veya sadece onlarla daha mantıklıysa) bir RDBMS (MySQL, PostGres, vb.)

Ben şahsen MongoDB'yi tercih etsem de, MySQL'in yüksek bir işlem oranını ölçeklemediği veya işleme koyamayacağı fikri tamamen yanlıştır. Facebook Mühendislik ekibi (ve içindeki MySQL ekibi) onunla çok ayrıntılı bir şekilde ilgileniyor. Ayrıca Etsy Ops ekip bloguna da göz atın; MySQL'i de seviyorlar.

Son olarak, bir MySQL önbellek için MongoDB kullanmak olmaz; Memcached kullanın.

Redis ayrıca, belirli kullanım durumlarını ele almak için iyi olan RAM içi bir anahtar / değer deposu. Blog.agoragames.com sitesinde bazı kullanım durumlarını açıklayan bazı blog girişleri vardır.

Ayrıca No-SQL düşünüyorsanız CouchDB'ye de göz atmalısınız. Sadece düzenli maint gerektirdiğini unutmayın 's disk kullanımını aşağı tutmak için. (Disk kullanımı için hız ve kolaylık sağlar ...)

Son olarak, kapasite planlamasını tahmin etmek kolay değildir. Mümkün olduğunca gerçekçi koşullarda test etmeniz ve gördüklerinize göre düzeltmeye hazır olmanız gerekir. Ne yazık ki "Bilgisayar Bilimi" Bilim kadar Sanattır.