Zaten ve cevap gönderildi, ve yararlı ve geçerli bir cevap olduğu için, kendi kullanışlılığından uzaklaşmak istemiyorum, ancak gerçekten kısa bir yorumun ötesine geçecek noktalar var. Bu yüzden umarım geçerli olan ancak öncelikle söylenenlere ek olarak bu "büyütme" yi düşünün.
Gerçek şu ki, "uygulamanızın verileri nasıl kullandığını" düşünmek ve "gölgeli bir ortam" daki faktörlerin yanı sıra bunu etkileyen önerilen "kap ortamınız" da farkında olmaktır.
Arkaplan Örneği
mongosSürecin uygulama örneği ile birlikte konumlandırılması için uygulama önerisinin genel olarak alınması, uygulamanın bu mongossüreçle iletişim kurması için gereken tüm ağ yükünü ortadan kaldırmaktır . Tabii ki mongos, "en yakın" düğümün herhangi bir nedenle mevcut olmaması gerektiğinde, uygulama bağlantı dizesinde bir dizi örneği belirtmek de "önerilen uygulama" dır . uzak düğüm.
Bahsettiğiniz "liman işçisi" vakası biraz keyfi görünüyor. Konteynırların birincil hedeflerinden birinin (ve bundan önce BSD hapishaneleri veya hatta kroot gibi) genellikle bir miktar "süreç izolasyonu" elde etmek olduğu doğru olsa da, sürece çok sayıda işlem yürütmenin gerçekten yanlış bir yanı yoktur. çıkarımları anlamak.
Bu özel durumda, mongos"hafif" olması ve uygulama işlemine, uygulamanın kendisinin "eşleştirilmiş" bir parçası olacak şekilde "ek bir işlev" olarak çalışması amaçlanmaktadır. Dolayısıyla docker görüntülerinin kendilerinin "initd" benzeri bir süreci yoktur, ancak konteynır için ana işlem olarak süpervizör (örneğin) gibi bir işlem denetleyicisinin çalıştırılmasıyla ilgili yanlış bir şey yoktur, bu da size daha fazla işlem kontrolü noktası verir. o kabı da. Bu "eşleştirilmiş süreçler" durumu makul bir durumdur ve bunun için resmi bir belge olduğunu yeterince yaygın bir şekilde sorun .
Bu tür bir "eşleştirilmiş" işlemi dağıtım için seçtiyseniz, aslında mongosaynı ağ bağlantısında bir örneği korumanın ve aslında uygulama sunucusunun kendisi ile "sunucu örneği" nin birincil noktasını ele alır . Aynı zamanda bir şekilde "bütün kapsayıcı" nın başarısız olacağı bir durum olarak görülebilir, o zaman kendi içindeki düğüm basitçe geçersiz olur. Bunu tavsiye edemem ve aslında mongosyalnızca gecikmeyi artıran bir ağ bağlantısı üzerinden erişilebilir olsa bile bağlantıları başka örnekleri arayacak şekilde yapılandırmanız gerekir .
Sürüme Özel / Kullanıma Özel
Şimdi bu noktaya değinildiğine göre, buradaki diğer husus, mongossürecin ağ gecikmesi amaçları için uygulama ile birlikte konumlandırılması konusundaki ilk düşünceye dayanmaktadır . MongoDB'nin 2.6'dan önceki versiyonlarında ve özellikle toplama çerçevesi gibi operasyonlarla ilgili olarak, o zaman çok daha fazla ağ trafiği olacak ve daha sonra mongosfarklı parçalardan gelen verilerle ilgilenmek için işlem tarafından gerçekleştirilen işlemden sonra olacaktı. . Şu anda böyle bir durum söz konusu değil, çünkü işleme iş yükünün büyük bir kısmı artık "yönlendiriciye" damıtmadan önce bu parçaların kendileri üzerinde gerçekleştirilebiliyor.
Diğeri ise kırma ile ilgili uygulama kullanım alışkanlıklarınızdır. Bu, birincil iş yükünün "yazmaların birden çok parçaya dağıtılması" veya gerçekten de okuma isteklerinin birleştirilmesinde "dağılma" yaklaşımı olup olmadığı anlamına gelir. Bu senaryolarda
Test Et, Test Et ve Tekrar Test Et
Dolayısıyla buradaki son nokta gerçekten açıklayıcıdır ve sorunuza herhangi bir aklı başında yanıtın temel fikir birliğine varır. Bu, MongoDB veya başka bir depolama çözümü için yeni bir şey değildir, ancak gerçek dağıtım ortamınızın, çekirdek bileşenlerden beklenen işlevsellikten herhangi bir "birim testi" kadar gerçek kullanım düzeyine yakın bir şekilde "kullanım modelleri" üzerinde test edilmesi gerekir. genel sonuçlar ihtiyacı test edilecek.
"Bu şekilde yapılandır" veya "bu şekilde kullan" demek için "kesin" bir ifade yoktur; bu, uygulama performansınız ve güvenilirliğiniz için beklendiği gibi "gerçekte en iyi olanı" test etmekten ayrıdır.
Tabii ki "en iyi durum" her zaman mongos"çok" uygulama sunucusu kaynaklarından gelen taleplerle örnekleri "kalabalıklaştırmamak" olacaktır . Ancak daha sonra onlara, seçilebilecek "en azından" bir "kaynak havuzuna" sahip olmak için mevcut olan kaynak iş yükleri tarafından dağıtılabilecek bazı doğal "eşlik" e izin vermek ve gerçekten de birçok durumda ideal olmakla birlikte, ek bir indükleme ihtiyacını ortadan kaldırmak msgstr "ağ aktarım yükü".
Amaç budur, ancak ideal olarak, nihai dağıtım çözümünüz için "en uygun" çözüme ulaşmak için farklı algılanan yapılandırmaları "laboratuvarda test edebilirsiniz".
Ben de "ücretsiz" (bira gibi) kursları zaten belirtildiği gibi mevcut ve ne düzeyde olursa olsun bilgi şiddetle tavsiye ediyorum. Çeşitli ders materyali kaynaklarının, dikkate almadığınız veya göz ardı ettiğiniz şeyler hakkında daha fazla bilgi vermek için genellikle "gizli taşlar" sunduğunu görüyorum. M102 Serisi inşa tarafından yürütülür belirtildiği gibi Adam Commerford kimi I can için durumu doğrular MongoDB büyük ölçekli dağıtımları ve diğer veri mimarileri bilginin yüksek düzeyde bulunur. En azından zaten bildiğinizi düşünebileceğiniz yeni bir perspektifi düşünmek için zaman ayırmaya değer.