DB'de işlevselliğe sahip olmak ölçeklenebilirliğe giden bir yol engeli midir?


17

Soruya doğru başlığı veremeyebilirim. Ama işte burada,

Varlık yönetimi için mali portal geliştiriyoruz. Uygulamayı kullanmak için 10000'den fazla müşteri bekliyoruz. Portal, borsa teknik analizine dayanarak çeşitli performans analizlerini hesaplar.

Depolanmış prosedürler, kullanıcı tanımlı işlevler, tetikleyiciler vb. Aracılığıyla Veritabanı üzerinden birçok işlevsellik geliştirdik. Biz doğrudan veritabanında C # kodu yerine şeyler yaparak büyük performans artışı elde edebilirsiniz düşündüm. Ve aslında büyük bir performans artışı elde ettik.

CTO'muzun başarısı hakkında övünmeye çalıştığımda, kodun yerine veritabanında işlevsellik uygulanma kararımı sorguladı. Ona göre bu tür uygulamalar ölçeklenebilirlik sorunlarına maruz kalmaktadır. Onun sözleriyle "Bugünlerde işler bellekte / önbellekte tutuluyor. Kümelenmiş verilerin zaman içinde yönetilmesi zor. Facebook, Google'ın veritabanında hiçbir şey yok. İnce sunucuların ve kalın istemcilerin dönemi. DB sadece düz veri depolamak için kullanılıyor ve işlevsellik veritabanından tamamen ayrılmalıdır. "

Lütfen bana söylediklerinin doğru olup olmadığı konusunda bazı önerilerde bulunabilir misiniz? Mimar böyle bir uygulama nasıl yapılır?


3
"ve biz aslında büyük bir performans artışı elde ettik" ne ile karşılaştırıldığında? Aynı işlevi bir istemciye hiç uygulamadığınızda, nasıl biliyorsunuz?
Doc Brown

3
Bence olağan olacak - projeye, veri uygulamasına ve ekibin becerisine bağlı.
Daniel Iankov

1
CTO'nuza, veritabanlarının tercih ettiği teknikleri kullanmadığını ve saklı yordamların neden "kod" olarak nitelendirilmediğini düşünmesini sağlayan şeyi sormalısınız.
Blrfl

3
Facebook ve Google'ın çoğu uygulamadan tamamen farklı bir ölçekte sorunları var - pazardaki veriler açısından uğraşmanız gereken veri miktarı ile ilgili bir sorun olabilir, ancak şaşırtıcı miktarda veriyle başa çıkmak için çağdaş SQL veritabanları oluşturulmuştur.
Murph

1
Çözümünün performansının yetersiz olduğunu ve onu yönetmenin başka yolları olmadığı sürece CTO'nuzla aynı şekilde düşünürdüm. Saklı yordamlar, özellikle sayıları büyüdüğünde, gerektiğinde diğer DB'lere çok büyük bir engele neden olur ... geleceği tahmin edemez.
Rig

Yanıtlar:


23

Kısacası, CTO'nuza katılıyorum. Muhtemelen ölçeklenebilirlik pahasına bir miktar performans kazandınız (eğer bu terimler kafa karıştırıcıysa, aşağıda açıklayacağım). En büyük iki endişem, sürdürülebilirlik ve yatay ölçeklendirme seçeneklerinin olmaması (buna ihtiyacınız olacağını varsayarak) olacaktır.

Verilere yakınlık: Bir adım geri gidelim. Bir DB içine kod itmek için bazı iyi nedenler vardır. En büyüğünün verilere yakınlık olacağını iddia ediyorum - örneğin, bir hesaplamanın bir avuç değer döndürmesini bekliyorsanız, ancak bunlar milyonlarca kayıt (talep üzerine) göndererek milyonlarca kayıt toplanıyor başka bir yerde toplanacak olan ağ son derece israflıdır ve sisteminizi kolayca öldürebilir. Bunu söyledikten sonra, verilerin bir kısmına, başka bir yolla, esas olarak, toplamanın bir kısmının önceden yapıldığı önbellekleri veya analiz DB'lerini kullanarak ulaşabilirsiniz.

Kodun DB'deki performansı:"İcra planlarının önbelleğe alınması" gibi ikincil performans etkilerinin tartışılması daha zordur. Bazen, yanlış yürütme planı önbelleğe alınmışsa, önbelleğe alınmış yürütme planları çok olumsuz bir şey olabilir. RDBMS'nize bağlı olarak, bunlardan en iyi şekilde yararlanabilirsiniz, ancak çoğu durumda parametreli SQL'den fazla bir şey elde edemezsiniz (bu planlar da genellikle önbelleğe alınır). Ayrıca en derlenmiş veya JIT'ed dillerinin genellikle temel işlemler ve ilişkisel olmayan programlama (dize manipülasyonu, döngüler, vb.) İçin SQL eşdeğerlerinden (T-SQL veya PL / SQL gibi) daha iyi performans gösterdiğini iddia ediyorum. Sayıda çatırtı yapmak için Java veya C # gibi bir şey kullandıysanız, orada hiçbir şey kaybetmeyin. İnce taneli optimizasyon da oldukça zordur - DB'de, genellikle tek veri yapınız olarak genel bir B-ağacı (dizin) ile takılır. Adil olmak gerekirse, daha uzun süren işlemlere sahip olma, kilit yükseltme vb. Gibi tam bir analiz, kitapları doldurabilir.

Sürdürülebilirlik: SQL, yapmak için tasarlandığı harika bir dildir. Bunun uygulama mantığına çok uygun olduğundan emin değilim. Hayatımızı katlanılabilir kılan araç ve uygulamaların çoğunu (TDD, refactoring, vb.) Veritabanı programlamaya uygulamak zordur.

Performans ve ölçeklenebilirlik karşılaştırması:Bu terimleri açıklığa kavuşturmak için şunu kastediyorum: performans, düşük yük olduğu varsayılırken, tek bir isteğin sisteminizden geçmesini (ve kullanıcıya geri dönmesini) ne kadar hızlı beklediğinizdir. Bu genellikle geçtiği fiziksel katman sayısı, bu katmanların ne kadar iyi optimize edildiği vb. İle sınırlı olacaktır. Ölçeklenebilirlik, artan kullanıcı / yük ile performansın nasıl değiştiğidir. Orta / düşük performansa sahip olabilirsiniz (örneğin, bir istek için 5 saniye +), ancak harika ölçeklenebilirlik (milyonlarca kullanıcıyı destekleyebilir) olabilir. Sizin durumunuzda, muhtemelen iyi bir performans yaşayacaksınız, ancak ölçeklenebilirliğiniz, bir sunucunun fiziksel olarak ne kadar büyük oluşturabileceğiyle sınırlandırılacaktır. Bir noktada, bu sınıra vuracak ve uygulamanın doğasına bağlı olarak mümkün olmayabilecek parçalanma gibi şeylere yönelmek zorunda kalacaksınız.

Erken Optimizasyon: Sonuçta, zamanından önce optimizasyon hatası yaptığınızı düşünüyorum. Diğerlerinin de belirttiği gibi, diğer yaklaşımların nasıl çalışacağını gösteren ölçümleriniz yok. Bir teoriyi kanıtlamak veya çürütmek için her zaman tam ölçekli prototipler oluşturamayız ... Ama genel olarak, performans için sürdürülebilirliği (muhtemelen uygulamanın en önemli kalitesini) gören bir yaklaşım seçmekte her zaman tereddüt ederdim. .

EDIT: Olumlu bir not, dikey ölçekleme bazı durumlarda oldukça uzayabilir. Bildiğim kadarıyla, SO oldukça uzun bir süre tek bir sunucu üzerinde koştu. 10.000 kullanıcınızla nasıl eşleştiğinden emin değilim (sanırım sisteminizde ne yaptıklarının doğasına bağlı olacaktır), ancak size ne yapılabileceği hakkında bir fikir verir (aslında, çok uzak daha etkileyici örnekler, bu sadece insanların kolayca anlayabileceği popüler bir şeydir).

DÜZENLEME 2: Başka yerlerde gündeme getirilen birkaç şeyi açıklığa kavuşturmak ve yorum yapmak için:

  • Re: Atomik tutarlılık - ASİT tutarlılığı sistemin bir zorunluluğu olabilir. Yukarıdakiler buna karşı değildir ve ASID tutarlılığının tüm iş mantığınızı DB içinde çalıştırmanızı gerektirmediğini fark etmelisiniz. DB'ye girmesi gerekmeyen kodu taşıyarak , onu DB'nin geri kalanının fiziksel ortamında çalışacak şekilde kısıtlıyorsunuz - DB'nizin gerçek veri yönetimi bölümü ile aynı donanım kaynakları için rekabet ediyor. Kodu diğer DB sunucularına ölçeklemek için (gerçek verileri değil) - elbette, bu mümkün olabilir , ancak çoğu durumda ek lisanslama maliyetleri dışında tam olarak ne kazanıyorsunuz? DB üzerinde olması gerekmeyen şeyleri DB'den uzak tutun.
  • Re: SQL / C # performans - bu bir ilgi konusu gibi göründüğü için, tartışmaya biraz ekleyelim. Kesinlikle yerel / Java / C # kodunu DB'ler içinde çalıştırabilirsiniz, ancak bildiğim kadarıyla burada tartışılan şey bu değildir - tipik uygulama kodunu C # gibi bir şeye kıyasla T-SQL gibi bir uygulamada karşılaştırıyoruz. Geçmişte ilişkisel kodla çözülmesi zor olan bir takım sorunlar var - örneğin, bir oturum açma veya oturum kapatmayı ve zamanı gösteren kayıtlara sahip olduğunuz "maksimum eşzamanlı oturum açma" sorununu düşünün ve herhangi bir zamanda giriş yapan maksimum kullanıcı sayısı. Mümkün olan en basit çözüm, kayıtlar arasında yineleme yapmak ve giriş / çıkışlarla karşılaştıkça bir sayacı arttırmak / azaltmak ve bu değerin maksimumunu takip etmektir.Mayıs, Bilmiyorum), yapabileceğiniz en iyi şey bir CURSOR (tamamen ilişkisel çözümlerin hepsi farklı karmaşıklık düzenleri üzerindedir ve bir while döngüsü kullanarak çözmeye çalışmak daha kötü performansla sonuçlanır). Bu durumda, evet, C # çözümü aslında T-SQL'de elde edebileceğinizden daha hızlıdır. Bu çok zor gibi görünebilir, ancak göreceli değişiklikleri temsil eden satırlarla çalışıyorsanız ve bunlar üzerindeki pencereli toplamaları hesaplamanız gerekiyorsa, bu sorun finansal sistemlerde kolayca kendini gösterebilir. Depolanan proc çağrıları da daha pahalı olma eğilimindedir - önemsiz bir SP'yi milyon kez çağırır ve bunun bir C # işlevini çağırmakla nasıl karşılaştırıldığını görün. Yukarıdaki birkaç diğer örnek ima - henüz C # yapmak oldukça kolay iken, kimsenin T-SQL (aslında bazı faydalar verir) uygun bir karma tablo uygulamak karşılaşmadım. Yine, DB'lerin harika olduğu şeyler ve çok da harika olmadıkları şeyler var. Tıpkı C # 'da JOIN, SUM ve GROUP BYs yapmak istemeyeceğim gibi, T-SQL'de özellikle CPU yoğun bir şey yazmak istemiyorum.

Ben veritabanına işlevselliği itme eğilimi nedenlerinden biri uygulama seviyesi kodu çok daha az arabası olmasıdır. SQL açıklayıcıdır ve zorunlu dillerin yaptığı birçok sorundan muzdarip değildir.
wobbily_col

Sürdürülebilirlik ile ilgili olarak, SQL Server Veri Araçları'nın kullanımı sürdürülebilirlik anlamına gelir. Aslında herhangi bir önemsiz veritabanı (bir fazla 5 tablo ile) için bir gereklilik düşünecektim.
Jon49

4

Ölçeklenebilirliğin, verilerin nerede oturduğu veya hesaplamanın nasıl gerçekleştiği ile ilgisi yoktur. Ölçeklenebilirlik, küresel durumu ve veri bağımlılığını nasıl yönettiğinizle ilgilidir. Mimariniz her türlü veri birbirine bağımlılığı ile kıvrımlıysa, o veriyi dönüştürmek için kodu nereye koyduğunuz önemli değildir. Bağımlılıklar, elinizi zorlayacak ve şeyleri ölçeklendirme potansiyelini azaltacaktır. Öte yandan, verileriniz gevşek bir şekilde bağlanmışsa ve çok az küresel bir durum varsa ya da hiç çok az şey varsa, o zaman bir kez daha hesaplamanın nerede gerçekleştiği önemli değildir. Bir şeyleri ölçeklendirmek çok daha kolay olacak.

CTO'nuzun ölçeklenebilirlik sorunları hakkındaki bilgilerini nereden aldığından emin değilim, ancak söylediklerinizden, yazılım moda trendleri dışındaki mevcut mimari kararı sorgulamak için gerçek bir nedeni yok gibi görünmüyor. Mimari kararları bu eğilimlere dayandırmak genellikle kötü bir fikirdir.


1
+1 içinScalability is all about how you manage global state and data inter-dependence.
Estefany Velez

2

Ve aslında büyük bir performans artışı elde ettik.

Bence bir performans ölçütü belirlemeniz ve önce prototipinizi oluşturmaya başlamanız gerekiyor. DB tüm mantık tutmak istemci-sunucu mimarisi ile ilgili eski bir okul (imho, buna karşı bir şey yok). Avantajları olmasına rağmen, dikkate alınması gereken dezavantajlar vardır.

Bu tür satılabilir uygulamalar için olağan yaklaşım SOA aracılığıyla yapılır . Çünkü uzun vadede, projenize yeni istemci uygulamaları eklemenin en kolay yolu budur.

Ayrıca tetikleyicilerden de bahsettiniz. Tetikleyici kullanımı, uygulamanın destek yaşam döngüsünde daha sonra büyük bir gotchas olabilir, bununla iki kat dikkatli olurum ve hatta kullanımını atlamaya çalışırım.


2

CTO'nuz% 100 Yanlış.

Finansal numaralarınız her zaman toplanmalıdır ZORUNLU . Yani ACID ihtiyacınız var ve ilişkisel DB bunu sağlamak için en iyi yerdir. NoSQL DB Performans kazançları pahasına genellikle ASİT ve Google ve Facebook için ANCAK mali içeren bir sistem için sorun yok.

C # SQL kodu daha iyi performans söylemek de aptallık olduğunu söylemek ...


C # SQL kodu daha iyi performans söylemek de aptallık olduğunu ... - Ama C # kodu daha ölçeklenebilir olduğunu inkar değil, doğru mu?
Jim G.

Hayır, daha ölçeklenebilir değil, çünkü şişe boynunun olmadığı yerde, yatay olarak C # kodunu ölçekleyebildiğim kadar Sql kodunu (verileri değil) yatay olarak ölçekleyebilirim.
Moronlar

@JimG. Sadece açıklığa kavuşturmak için, "Sql kodunu (veriyi değil) yatay olarak C # kodunu yatay olarak ölçekleyebildiğim kadar kolayca ölçekleyebilirim" bunu yapmak için tasarlanmışsa ... C # ile aynı şekilde ölçeklendirilmelidir. Sadece C # ölçeklerini daha iyi ölçekleyemezsiniz, bu dili değil planlama meselesidir.
Morons

@JimG .: Ölçeklenmeyen yazılım C # dahil herhangi bir dilde yazılabilir. Tuz değerine sahip herhangi bir veritabanı, yerel SQL ish uygulaması dışında dillerde yazılmış prosedürleri saklayabilir ve ACID gerektiren durumlarda NoSQL ile derin uçtan gelen insanlar genellikle güzel olan tekerleklerin çoğunu yeniden icat ederler. DBMS tarafından uygulanır.
Blrfl

@Morons: Sanırım katılıyorum. Ben idi "SQL" ile veri conflating aslında. Veritabanını ölçeklendirmek çok daha pahalı.
Jim G.

2

Herkes ölçeklenebilirlikten ve Google / Facebook / Twitter / vb'den bahsettiğinde, kırmızı bir ringa balığıdır. Aynı hizmeti vermedikçe, onlar için işe yarayanlar sizin için uygun olmayabilir. Genel olarak, tek bir makineden sekiz makine kümesine ölçeklenebilirseniz, muhtemelen tüm üslerinizi kapsamış olursunuz. Günde 20 milyon sayfa görüntüleme sunmak için zor bir iş gereksiniminiz olmadığı sürece hiper ölçeklendirme konusunda endişelenmeyin. Uygulamanızın gerçek gereksinimleri için mantıklı olanı yapın ve ihtiyacınız olduğunda belirgin hale geldiğinde ölçeklendirme konusunda endişelenin. Unutmayın, çoğu veritabanı sunucusu da kümelenebilir, bu yüzden hepsi bir veritabanında olduğu için tek bir sunucuda olduğu anlamına gelmez.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.