Müşteri başına veri tabanı oluştururken ne gibi sorunlar yaşayacağım?

O stackoverflow podcast'lerdeki hatırlamak Sis Creek için müşteri başına bir veritabanını kullanmak FogBugz . Bunun, Fogbugz On Demand sunucularının 10 binlerce veritabanının olduğu anlamına geldiğini düşünüyorum.

Bir web uygulaması geliştirmeye yeni başlıyoruz ve çözmek için benzer bir sorun yaşıyoruz (kendi izole verileriyle çok sayıda müşteri).

Müşteri başına veri tabanı kullanırken ne gibi problemler beklemeliyim? Onları nasıl çözebilirim?

İlk Düşüncelerim

Veritabanının müşteri başına avantajları

• Basit veritabanı şeması
• Daha basit yedeklemeler - her müşteriyi diğer müşterileri etkilemeden sırayla yedekleyebilirsiniz.
• Belirli bir müşteri verisini dışa aktarmayı kolaylaştırır.
• Daha iyi önbellek performansı - daha etkin tablolardan birine yapılan bir yazı, yalnızca bu işlemi yazan o müşteriyi etkiler.
• Donanım arasında ölçeklendirmek daha kolaydır. Örneğin, 1 ila 2 sunucu arasında gitmemiz gerektiğinde, müşterilerimizin yarısını yeni sunucuya taşıyoruz.

Dezavantajları

• MySQL 5.000 veritabanıyla başa çıkabilir mi? Performans berbat olur mu?
• Şemada yapılan değişikliklerin tüm veritabanlarında çoğaltılması zor olabilir. Şema sürümü ve bir veritabanından bir sürümden diğerine nasıl bir veritabanı alınacağını anlayan bir komut dosyası gibi gerçekten bunun için otomatik bir plana sahip olmalıyız.
• Tüm müşterilerimiz için ortak olan her şeyi yapmak garip veya imkansız olabilir
• Yukarıdakine benzer, ancak tüm müşterilerimiz arasında yapmak istediğimiz herhangi bir analitik mümkün olmayabilir. Örneğin tüm müşteriler arasında kullanımı nasıl izlemeliyiz?

Bu çözüm, her kiracının (müşterinin) kendi veritabanına sahip olduğu çok kiracılı bir tasarım olarak adlandırılır. Bu göz önüne alındığında, tek bir veritabanı olan alternatif yaklaşıma ilişkin başka düşünceler var:

1. Tek bir veritabanı ile, ne olursa olsun herkes aynı sürümde olmalı. Bazı müşterileri değil, diğerlerini yükseltmek mümkün değildir. Bir müşteri geniş sürüm için hazır olmayan bir uygulamanın düzeltmesini istiyorsa, bu sorunlu olabilir.
2. Tek bir veritabanı ile, yükseltme yaptığınızda, her müşteri kapalıdır. Eğer bir şeyler ters giderse, her müşteri mahvolur.
3. Tek bir veritabanıyla, kaynakları kısmak çok daha zordur. Yani, eğer bir müşteri veri tabanını kırıyorsa, onlara diğerlerinden daha fazla kaynak vermek daha zordur.
4. Kullanıcıların uygulamanızın kendi sürümlerini barındırmasına izin vermek çok daha zordur. Büyük işletmeler tarafından kullanılacak bir çözüm inşa ediyorsanız, bu genellikle başlangıçsızdır. IT departmanları sisteme erişim üzerinde tam kontrol istiyor.
5. Veritabanlarını ölçeklendirmek yerine ölçeklendirmek muhtemelen daha ucuzdur. Diğer bir deyişle, hepsini yönetmek için bir veritabanını barındırmak için daha hızlı donanıma yatırım yapmak, müşterileri daha küçük ve daha ucuz veritabanı sunucularına göre ölçeklendirmekten daha pahalıdır. Bunu kesin olarak söyleyemem çünkü bu büyük ölçüde sunucu yazılımına bağlı. MySQL'e sadık kalırsanız, lisans masrafları ihmal edilebilir olduğundan, bu muhtemelen doğrudur. Bununla birlikte, örneğin, SQL Server'a geçerseniz, bir VPS ortamı kullanmazsanız ve ölçeklendirmenin karşılaştırılması ve faydaları değiştiğinde değişiklik yapmazsanız ölçeklendirme daha pahalı olur. Ancak, veritabanınız çok genişlediğinde, yönetimin daha fazla uzmanlık düzeyi gerektirdiğini söyleyebilirim. Çok büyük veritabanları, daha iyi performans elde etmek için birden fazla dosya grubuyla uğraşmayı ve belirli dizinleri farklı iş millerine itmeyi gerektirir. Kısacası, çok çabuk karmaşıklaşabiliyorlar.

Ayrı veritabanlarına sahip olmak, veritabanı sürümüyle uygulama / site sürümüyle eşleşen bir güncelleme mekanizması oluşturmanız gerektiği anlamına gelir. Ancak, ayrı veritabanları üstün veri yalıtımı sağlar ve IMO daha düşük bir barındırma maliyetine sahiptir. Tüm senaryolar için bir çözüm değildir. Sisteminiz hiçbir zaman barındırma sunucunuzun dışında barındırılmayacaksa ve müşterilerin hızlıca ölçeklendirilmesi gerekiyorsa ve tüm kullanıcıların uygulamanın ve veritabanı şemasının aynı sürümünde olması isteniyorsa, kesinlikle tek bir veritabanına sahip olmak daha iyi bir yaklaşımdır.

Deneyimlerime göre müşteri başına bir veritabanı oluşturmamalısınız. Sana bir örnek vereyim:

Geçen yıl, her biri aynı şemaya ve hepsine sahip 70 veritabanıyla (5000'den az) çalıştım. Teoride, işler planlandığı gibi gider (avantajlar bölümünde dediğiniz gibi), ama gerçekte pek değil. Güncelleme şemaları, kullanıcı desteği, yazılım güncellemesi ile ilgili birçok sorun yaşadık. Berbattı.

Firebird'i kullandık ve ürün gönderildikten sonra çok işe alındım, ama bu bana asla ayrı veritabanları ile çalışmama bilgisi verdi.

Bunu kaldıramayacağınızı söylemiyorum, işler çok yanlış gidebilir ve dürüst olmak gerekirse, avantaj listeniz riski alabilecek kadar çekici gelmedi. Bunların çoğu tek bir veritabanı ile sağlanabilir.

Her müşterinin hangi sürümde olduğunu izlemek için başka bir veri tabanını tutmak isteyebilirsiniz, böylece hangisinin son değişiklik turunda olduğunu veya hangilerini geçemediğini takip edebilirsiniz.

Yükseltmeleri yazmak o kadar zor olmazdı ... veritabanlarının kataloguna bakan bir şey yazabilir ve her bir veritabanını en son sürüme ulaştırmak için gerekli değişiklikleri uygulayabilir, muhtemelen bir nedenden dolayı yükseltilmemesi gerekenleri atlayabilirsiniz.

MySQL 'veritabanları' sadece şemalar olduğundan, Gaius'un belirttiği gibi, hepsi aynı sunucu örneğinden çalışıyorsa, değiştirmeye çalıştığınız tabloların adını nitelendirebilir veya bilgi alabilirsiniz:

alter schema.table ...
select ... from schema.table

...

Birden fazla sunucuya bir şeyleri ayırmaya başlarsanız, birden fazla sunucuya bağlantı kuran bir şeyi kodlayabilir, böylece tüm değişiklikleri uygulayabilirsiniz; Analitikler için, yine, tablolardan okurken verilere erişmek için ana veritabanınızdaki federasyon tablolarını kullanarak bir grup veritabanı bağlantısı kurabilirsiniz .

...

Ayrıca, mySQL'i yığın değişimi için kullanmadıklarını, SQL Server kullandıklarını unutmayın.

Ve bu ölçekte mysql'de ne tür bir performans artışı olacağı hakkında hiçbir fikrim yok, mysql'de 30 veritabanını geçmiş olduğumu sanmıyorum.

Aynı masa (162) ve aynı masa yapılarına sahip 750'den fazla müşteri veritabanına sahip bir Web / DB Hosting istemcisine sahibim. Kombine, müşterimin tüm müşteri verileri toplam 524GB (% 95 InnoDB)

Dairesel çoğaltma yoluyla dokuz DB sunucusunda 13 G innodb arabellek havuzu için rekabet eden tüm bu veritabanları düşünün. Bu donanım yapılandırmasıyla ölçeklendirme yeterli değildi. Hemen, müşteriye ölçek büyütmesini tavsiye ettik.

Yakın zamanda bu müşteriyi çok daha fazla beygir gücüne sahip 3 DB sunucusuna taşıdık (Her ne pahasına olursa olsun, yüksek yazma ortamlarında, HER ZAMAN !!!) SSD'den uzak durun.). Onları MySQL 5.0.90'dan MySQL 5.5.9'a yükselttik. Dramatik Farklılıklar neredeyse anında görüldü.

Aynı bellek ve disk kaynaklarına vuran yüzlerce müşteriniz varsa, ölçeklendirmek de kullanımlarını doğrusal olarak azaltıyor (n, bir multimaster ortamdaki DB sunucularının sayısına dayanıyorsa (O (n))).

Müşterim durumunda, şirketim onu ​​9 DB sunucusundan (Quad Code, 32GB RAM, 824G RAID10) daha hızlı DB sunucularına (Dual HexaCore [bu doğru 12 CPU], 192GB RAM, 1.7TB RAID10) düşürüyor. .9 (tabloya, çoklu CPU'lardan faydalanma). Ek olarak, her biri 3 GB'lik 50 bölümdeki 150 GB'lik innodb tampon havuzunu hayal edin (Multiple InnoDB tampon havuzları, MySQL 5.5'teki yeni bir özelliktir). Müvekkilimin benzersiz altyapısı için daha küçük bir ölçek, ancak büyük bir ölçek, çalışmıştı.

ÖYKÜSÜN MORALARI : Ölçeklendirmek veya küçültmek , kötü tasarlanmış masalara sahipseniz her zaman çözüm değildir. Demek istediğim şudur: Çok sayfalı dizinler için dizin sayfalarının işaretsiz anahtar popülasyonu varsa, dizinlerin parçalanmış bölümlerinden anahtarları sorgulamak, tablo taramasından sonra tablo taramasına veya en azından MySQL Sorgusu tarafından göz ardı edildiğinden asla kullanılmayan dizinlere yol açar. Doktoru. Doğru tasarımın yerini hiçbir şey tutamaz.

MySQL, ayrı dizinlerde veri tabanları oluşturur, bu nedenle çoğu, temel işletim sistemine ve kaç tane klasör / dosya tutacağının işleyebileceğine bağlıdır. Modern işletim sistemlerinde bir sorun olmamalı, ancak buradaki birçok darboğazın geleceği yer.

Veritabanının veya uygulamanın farklı sürümlerini barındırmanız gerektiğini söyleyen hiçbir şey yok. Müşteri başına bir db yaparak ve veritabanının ve uygulamanın bir sürümüne sahip olarak verileri basitçe izole etmenin nesi yanlış? Tabii ki her müşteri db'nin mevcut çalışma versiyonunun bir şablonundan klonlanması gerekecekti. Güvenlik ve veri izolasyonu açısından, bunun ideal olduğunu düşünüyorum.

Görebileceğim tek dezavantajı, yeni bir sürüm oluştururken her veritabanını el ile güncellemeniz gerektiğidir. Bu olsa kolayca otomatikleştirilebilir.