“Ölçeklendirmek” yerine ne tür sistemlerin “ölçeklendirilmesi” gerekir?

Çok daha küçük sunucular arasında bölünerek "ölçeklendirmek" yerine "ölçeklendirmek" (daha güçlü, daha pahalı bir sunucu üzerine) sistemleri varsa uzun zamandır merak ediyorum.

Bu tür sistemler mevcut mu ve eğer öyleyse, sistemlerin ölçeklendirilmek yerine ölçeklendirilmesine neden olma eğilimi olan herhangi bir şey var mı? (Örneğin, belki ACID şikayet veritabanı işlemleri veya diğer güçlü veri bütünlüğü gereksinimleri bu ihtiyacı yaratır.)

Ölçeklendirme, ölçeklendirmekten çok daha yüksek donanım maliyetleri getireceği gibi göründüğünden, mümkünse kaçınmak istediğiniz bir şey gibi görünüyor, ancak her zaman önlenebilir olup olmadığından emin değilim.

Peki, ölçeklenemeyen ve bunun yerine ölçeklendirilmesi gereken sistemler var mı? Buna ne neden olabilir ve böyle bir sistemi nasıl tanımlarsınız? (Genellikle daha kolay tanımlanabilecek bazı ortak özellikleri paylaşıyorlar mı?)

Öncelikle sıfır yatay ölçekleme potansiyeli olan bir uygulama ile çalışıyorum . Linux üzerinde çalışmasına rağmen, uygulama, veri yapıları ve G / Ç gereksinimleri, artan kullanıcı iş yüklerini karşılamak için beni giderek daha büyük sistemlere "ölçeklendirmeye" zorluyor.

Birçok eski iş kolu ve işlemsel uygulama bu tür kısıtlamalara sahiptir. Endüstrinin bulut çözümlerine odaklandığını ve DevOps tabanlı web ölçeği mimarilerinin bilgisayar dünyasının büyük bir yüzdesini göz ardı ettiğini vurgulamamın bir nedeni de bu.

Maalesef, tanımladığım ölçeklendirme sistemleri gerçekten unsexy'dir , bu nedenle endüstri, değerlerini göz ardı etme veya büyük, kritik sistemlere (örneğin evcil hayvanlara karşı sığır ) hitap etmek için gerekli becerileri vurgulama eğilimindedir .

Bir geliştirici perspektifinden, hemen hemen her geleneksel ana veritabanı motorunun sadece ölçeklendirilebildiğini ve ölçeklendirilebileceğini söyleyebilirim.

Son yıllarda daha fazla ölçeklenebilirlik ve yüksek oranda kullanılabilir sistemlere ihtiyaç duyulduğunda, mevcut veritabanlarının ölçeklendirilmesine yönelik çabalar olmuştur. Ancak tasarımlar eski kod tarafından engellendiğinden, tasarımın temelinden ziyade çok fazla cıvatalı. İyi bilinen veritabanı motorlarının çoğunu ölçeklendirmeye çalışırsanız, bununla karşılaşırsınız. Slave sunucuları eklemek oldukça zor olabilir ve bazılarının veritabanı tablolarınızı yeniden hizalamayı gerektirebilecek önemli sınırlamalarla geldiğini fark edeceksiniz.

Örneğin, çoğu çoklu-master tasarımlar yerine master / (multi-) köle. Başka bir deyişle, sadece orada oturan ve sorguları işleyemeyen bir sunucunuzun tamamı olabilir. Bazıları bunu yapar, ancak sınırlamalarla ... örneğin sadece çoklu-bağımlı tasarım okuyun. Bu nedenle, yazma işlemleri yapan bir sunucunuz olabilir ve diğerlerinin tümü salt okunur veri sağlar. Bu sistemleri kurduğunuzda her zaman basit bir işlem olmadığını ve iyi çalışmanın zor olduğunu fark edeceksiniz. Pek çok durumda ilave üzerine bir cıvata hissediyor.

Öte yandan, başlangıçtan beri eşzamanlılık ve çok master tasarımlı yeni veritabanı motorları geliştirilmektedir. NOSQL ve NewSQL yeni tasarım sınıflarıdır.

Bu yüzden geleneksel bir SQL sunucusundan daha iyi performans almanın en iyi yolu büyümüştür! NOSQL ve NewSQL ile hem ölçeklenir hem de ölçeklenir.

Geleneksel RDBMS sistemlerinin birbirine sıkı sıkıya bağlı olmasının nedeni, hepsinin aynı verilerin tutarlı bir görünümüne ihtiyaç duymasıdır. Farklı istemcilerden aynı verilerle ilgili güncellemeleri kabul eden birden fazla sunucunuz olduğunda hangisine güveniyorsunuz? Verilerin bir tür kilitleme mekanizmasıyla tutarlı olmasını sağlamaya çalışan herhangi bir yöntem, bir istemciden okunan herhangi bir verinin güncel olmaması nedeniyle performansı düşüren veya veri kalitesini etkileyen diğer sunuculardan işbirliği gerektirir. Ve sunucuların kendi aralarında aynı kayda yazarken hangi verilerin en güncel olduğuna karar vermeleri gerekir. Gördüğünüz gibi, iş yükünün sadece verilere erişimin hala oldukça hızlı olduğu süreçler veya iş parçacıkları arasında değil, sunucular arasında yayılması karmaşık bir sorundur.

Kanımca ölçek büyütme / küçültme, bir iş akışının ne kadar paralel olabileceği ve paralel ipliklerin birbirleriyle ne kadar sıkı bir şekilde koordine edilmesi gerektiğine bağlıdır.

Tek Dişli
Bu nedenle, bu iş akışı yalnızca tek bir iş parçacığında çalışabilir.

Bir diş araçlarının bir sistem aracı ölçek yukarı daha hızlı gitmek yapmak.

Sıkıca bağlı paralellik
Bu, dişlerin birbirine sıkıca bağlanması gereken çok iş parçacıklı bir sistemdir. Belki de süreçler arası iletişimin çok hızlı olması ya da hepsinin tek bir bellek yöneticisi aracılığıyla yönetilmesi gerekir. Çoğu RDBMS sistemi bu tür paralel hesaplamadır.

Çoğunlukla, bu sistemler ölçek olduğu olanlardır yukarı daha iyi dışarı istisnalar da vardır gerçi. Örneğin, Tek Sistem Görüntüsü stil kümesi, tek bellek alanı ancak iş parçacıkları arasındaki yüksek gecikme süresi üzerinde çalışacak iş akışları, ölçeklendirmeyi kolaylaştırabilir. Ancak bu tür SSI sistemleri ile çalışmak çok zordur, bu nedenle çoğu mühendis daha büyük bir kutu oluşturur.

Gevşek bağlanmış paralellik
Bu, dişlerin birbirleri arasında yüksek gecikmelerle tamamlandığı çok iş parçacıklı / işlem sistemidir. Ya da birbirinizle konuşmanıza gerek yok. Ölçeklendirilmiş web sunumu ve render-çiftlikleri bu tür sistemlerin klasik örnekleridir. Bu tür sistemler, sıkı bir şekilde bağlanmış paralellikten daha büyük hale getirmek için çok daha kolaydır, bu nedenle bu sistem tarzı hakkında çok fazla heyecan vardır.

Bu ölçek tarzıdır dışarı çok daha kolaydır.