Bir web sitesini yüksek oranda ölçeklenebilir olacak şekilde tasarlamanın en iyi yolu nedir?


35

Facebook gibi sosyal ağlar gibi yüksek düzeyde ölçeklenebilir olması gereken web siteleri için web sitesini tasarlamanın en iyi yolu nedir?

  1. Sitenin ihtiyaç duyduğu verileri almak için sorduğu bir web hizmetine sahip olmalı mıyım?

    veya

  2. Site doğrudan veritabanlarını sorgulamalı mı? (tabloları otomatik olarak doldurmak için yerleşik dil yapıları kullanılarak yapılabilir).

Merkezileştirilmiş veri erişimi sağladığından ve önbellek ve benzeri şeylerin kontrolünün çok daha kolay hale geldiğinden web servisinin daha iyi bir tasarım olduğunu düşünüyorum, ama diğerleri ne düşünüyor?


Hangi mimarinin kullanılacağı sorusu da (MVC veya benzeri gibi) var.
Ivan

Tam olarak neyi başlatacağınız hakkında daha fazla bilgi sahibi olmadan, cevabı vermek çok zordur, ancak "Bulut hizmetleri" ni aklınızda bulundurun, muhtemelen uygulamanız bir çeşit SaaS uygulamasına uyar. (Bu merkezileştirilmiştir).
deepcell

genel olarak konuşursak, aklında belirli bir şey olmadığını söyleyebilirim ..
Daniel

1
'Bulutta' oluştur ve HighScalability.com'u okuyarak çok zaman harca.
Evan Plaice

Yanıtlar:


37

Vay canına, bu çok büyük bir olası cevap dizisi olan basit bir soru. Sorunuzun daha açık bir kısmı, veritabanınızla doğrudan mı yoksa bir web servisi aracılığıyla mı daha fazla arabirim oluşturabileceğinizi sorar. Bu cevap basit: veritabanını doğrudan sorgula. Web servisine göz atmak, bir güvenlik duvarının arkasında (büyük ve büyük) çalışan kod için tamamen gereksiz olan bir miktar gecikme ekler. Örneğin bir web servisi, bir istek almak, seriyi kaldırmak, DB'yi sorgulamak, yanıtı seri hale getirmek ve iade etmek için bazı bileşenler gerektirir. Bu nedenle, kodunuzun tümü bir güvenlik duvarının arkasında çalışıyorsa, sorununuzu kaydedin ve yalnızca DB'yi sorgulayın.

Ancak bir web sitesini ölçeklenebilir yapmak, başlangıçta gönderdiğiniz sorunun ötesine geçer. Bu yüzden bir teğete gidersem beni affet, ama özellikle Facebook'tan bahsettiğini düşünmenin yararlı olabileceğini düşündüm.

Brad Fitzpatrick (LiveJournal'in kurucusu ve şimdi Google'da) tarafından yapılan çalışmaları ve araçları okumanızı tavsiye ederim. Six Apart'da onunla çalıştığımda, ondan öğrendiğim şeylerden bazıları ve LiveJournal'ın bu denli ölçeklendirilebilir mimarisi hakkında.

  1. Geniş olanların aksine dar veritabanı tabloları kullanın . Bu konuda büyüleyici olan, bu mimariyi neyin motive ettiğini, kolayca ve hızlı bir şekilde bir sistem yaratarak öğrenmesiydi.yükseltti. Geniş bir tablo veya her alanın veya özelliğin tablodaki bir sütun olduğu tabloları kullanırsanız, örneğin veritabanı şemasını yükseltme zamanı geldiğinde, örneğin yeni bir sütun eklenirse, sistemin tabloyu şema sırasında kilitlemesi gerekir. değişim uygulanır. Ölçekte çalışırken, bu veritabanı şemasında yapılan basit bir değişiklik büyük bir veritabanı kesintisine neden olabilir. Hangi açıkça berbat. Öte yandan dar bir tablo, bir nesneyle ilişkilendirilmiş olan her bir özelliği, veritabanında tek bir satır olarak saklar. Bu nedenle veritabanına yeni bir sütun eklemek istediğinizde tek yapmanız gereken kilitleme işlemi olmayan bir tabloya INSERT kayıtları koymaktır. Tamam, bu biraz arka plandır, hadi bu modelin LiveJournal gibi çalışan bir sistemde nasıl çevirdiğini görelim.

    Diyelim ki son 10 günlük girişini bir kişinin bloguna yüklemek istiyorsunuz ve her günlük girişinin on özelliği olduğunu varsayalım. Klasik geniş bir tablo düzeninde, her özellik bir tablodaki bir sütunla ilişkilendirilir. Bir kullanıcı daha sonra ihtiyaç duyduğu tüm verileri almak için tabloyu bir kez sorgulayacaktır. Sorgu 10 satır döndürür ve her satır ihtiyaç duydukları tüm verilere sahip olur (örneğin, SELECT * FROM girdileri SİPARİŞ TARİHİ SINIR 10). Dar masa düzeninde ise işler biraz farklı. Bu örnekte aslında iki tablo vardır: ilk tablo (tablo A), örneğin girişin kimliği, yazarın kimliği, girişin tarihi vb. Tarafından aranacak basit kriterleri saklar. İkinci bir tablo (Tablo B) daha sonra bir girişle ilişkili tüm özellikleri saklar. Bu ikinci tablonun üç sütunu vardır: entry_id, anahtar ve değer. Tablo A'daki her satır için, Tablo B'de 10 satır olacaktır (her özellik için bir satır). Bu nedenle, son on girişi alıp görüntülemek için 11 sorguya ihtiyacınız olacak. İlk sorgu size giriş kimlikleri listesini verir ve sonraki on sorgu ilk sorguda döndürülen girişlerin her biri ile ilgili özellikleri getirir.

    "Kutsal moly!" “Dünyadakiler nasıl daha ölçeklenebilir olabilir?” diyorsunuz. Tamamen karşı sezgisel bir hak? İlk senaryoda sadece bir veritabanı sorgumuz vardı, fakat ikinci "daha ölçeklenebilir" çözümde 11 veritabanı sorgusu var. Bu hiç mantıklı değil. Bu sorunun cevabı tamamen bir sonraki kurşuna dayanıyor.

  2. Memcache'i liberal olarak kullanın. Farkında değilseniz, memcache dağıtık, durumsuz, düşük gecikmeli, ağ tabanlı bir önbellekleme sistemidir. Facebook, Google, Yahoo ve gezegendeki hemen hemen her popüler ve ölçeklenebilir web sitesi tarafından kullanılıyor. Bu, Brad Fitzpatrick tarafından dar bir masa veritabanı tasarımında yerleşik olan ek yükün mahsup edilmesine yardımcı olmak için kısmen icat edildi. Yukarıda # 1'de açıklananla aynı örneğe bir göz atalım, ancak bu sefer memcache'i tanıtalım.

    Kullanıcı bir sayfayı ilk ziyaret ettiğinde ve önbellekte hiçbir şey olmadığında başlayalım. Sayfada görüntülemek istediğiniz 10 girişin kimliklerini döndüren tablo A'yı sorgulayarak başlayın. Bu girişlerin her biri için, daha sonra bu girişle ilişkili özellikleri almak üzere veritabanını sorgularsınız ve daha sonra bu özellikleri kullanmak, kodunuzun arayüzle bağlanabileceği bir nesneyi (örneğin bir nesneyi) oluşturur. Daha sonra bu nesneyi (veya o nesnenin seri hale getirilmiş bir formunu) memcache'de saklarsınız.

    İkinci kez bir kişi aynı sayfayı yüklediğinde, aynı şekilde başlarsınız: Gireceğiniz girişlerin listesi için tablo A'yı sorgulayarak. Her giriş için önce memcache'e gidin ve "önbellekte #X girişiniz var mı?" Eğer öyleyse, memcache giriş nesnesini size geri verir. Değilse, özelliklerini almak, nesneyi oluşturmak ve memcache içinde saklamak için veritabanını tekrar sorgulamanız gerekir. Çoğu zaman, ikinci kez birileri aynı sayfayı ziyaret ettiğinde yalnızca bir veritabanı sorgusu vardır, diğer tüm veriler daha sonra doğrudan memcache'den çıkarılır.

    Uygulamada, LiveJournal’ın çoğu için ortaya çıkan, sistem verilerinin çoğunun, özellikle de daha az değişken olan verilerin memcache’de önbelleğe alındığı ve dar tablo şemasını desteklemek için gereken veri tabanına yapılan ilave sorguların tamamen telafi edildiğidir.

    Bu tasarım, tüm arkadaşlarınızla ilgili bir gönderi listesinin bir dere veya "duvar" içine yerleştirilmesiyle ilgili problemi çözmeyi çok daha kolay hale getirdi .

  3. Ardından, veritabanınızı bölümlemeyi düşünün. Yukarıda tartışılan model bir başka problemi ortaya çıkardı ve bu da sizin dar masalarınız çok büyük / uzun olma eğiliminde. Ve bu tabloların sırası ne kadar fazla olursa diğer idari görevlerin zorlaşmasına neden olur. Bunu dengelemek için, kullanıcıların kümelerini tek bir veritabanında, başka bir kullanıcı kümesini ayrı bir veritabanında sunduğunu belirtmek için, tablolarınızın boyutunu bir şekilde bölümlere ayırarak tablolarınızın boyutunu yönetmek mantıklı olabilir. Bu, veritabanındaki yükü dağıtır ve sorguları verimli tutar.

  4. Sonunda harika indekslere ihtiyacınız var. Sorgularınızın hızı büyük ölçüde veritabanınızın tablolarının ne kadar iyi dizine alındığına bağlı olacaktır. Bir dizinin ne olduğunu tartışmak için fazla zaman harcamam, bunun dışında bir samanlıkta iğneleri bulmayı daha verimli hale getirmenin dev kart katalog sistemi gibi bir şey olduğunu söylemekten başka. MySQL kullanıyorsanız, yerine getirmek için uzun süren sorguları izlemek için yavaş sorgu günlüğünü açmanızı öneririz. Radarınızda bir sorgu belirdiğinde (örneğin yavaş olduğu için), tabloyu hızlandırmak için hangi dizini eklemeniz gerektiğini öğrenin.

"Tüm bu harika geçmiş için teşekkür ederim, ama kutsal kabil, yazmam gereken çok fazla kod var."

Şart değil. Memcache ile arayüz oluşturmayı gerçekten kolaylaştıran birçok kütüphane yazılmıştır. Yine de diğer kütüphaneler yukarıda tarif edilen tüm süreci kodlamışlardır; Data :: Perl'deki ObjectDriver böyle bir kütüphanedir. Diğer dillere gelince, kendi araştırmanızı yapmanız gerekecektir.

Umarım bu cevabı faydalı bulmuşsunuzdur. Bulmadığımdan çok daha fazla bulduğum şey, bir sistemin ölçeklenebilirliğinin sıklıkla koda daha az ve daha az ve daha da çok, sağlam bir veri depolama ve yönetim stratejisi / teknik tasarımına inmesidir.


3
+1 Bu Vay'i
Pankaj Upadhyay 16:11

1
'Veritabanını doğrudan sorgula' ile tamamen aynı fikirde değilim. API arayüzü ile tek yöneticili bir çoklu bağımlı mimarisini uygulamanın daha kolay olacağı durumlarda, performans için veritabanını bölümlendirmekten bahsediyorsunuz. Veritabanını uygulamadan ayırmanın faydası, API katmanı istekleri ancak istediğiniz gibi dağıtabilir. API, temeldeki uygulamayı değiştirmenize ve / veya uygulamayı bozmadan verileri yeniden kullanmanıza izin veren bir soyutlamadır.
Evan Plaice

1
(devamı) Seri hale getirme her zaman ek yükler ekler, ancak yalnızca eşzamanlı olarak çalışan birden fazla örnekten oluşacak olan API katmanında. Kablo üzerinden aktarım hızları konusunda endişeleniyorsanız, JSON'a dönüştürün; büyük olasılıkla yine de gzip ile sıkıştırılacaktır. En kolay performans kazancı, işler sunucudan istemciye iletildiğinde bulunabilir. Sorulması gereken önemli soru, uygulama içinde veya sunucu düzeyinde istekleri dağıtmak mı istiyorsunuz? Çoğaltmak hangisi daha kolaydır?
Evan Plaice

1
@EvanPlaice - Hizmetleri kullanırken yeniden kullanılabilirlik ve hizmet mantığı uygulamasını değiştirmede harika noktalar. Ek olarak, önbellek altyapısı, doğrudan veritabanı çağrıları yerine servisler tarafından da kullanılabilir.
Ashish Gupta

1
@AshishGupta Tam olarak, verileri ayrı bir hizmete bölümlemedeki tek fark, kullanıcının aldığı şeydir. Bunun yerine html + içeriğini sunucuda birleştirmek. Kullanıcı verileri ve ayrı ayrı html dosyasını alır ve istemci tarayıcısı yeniden birleştirmeyi gerçekleştirir. Ayrı bir hizmet olarak verilerle, mobil uygulamalar veya web tabanlı olmayan diğer müşteriler için de kullanılabilir (eski akıllı TV uygulamaları).
Evan Plaice

13

Facebook gibi sosyal ağlar gibi yüksek ölçeklendirilebilir olması gereken web siteleri için web sitesini tasarlamanın en iyi yolu nedir?

Ölçün.

Ben düşünürdüm ki ...

Kötü politika

Gerçek ölçüm gereklidir.


Kantitatif Metrikler FTW.
bhagyas

1
Tamam ... peki ölçümden sonra ne olacak?
Pacerier

9

Ölçeklenebilirlik, belirli uygulama stratejilerinin bir işlevi değil, veri erişim katmanının büyük yeniden düzenleme ve yeniden yazma olmadan gelişebilmesi için uygulama mimarinizi tasarlamak yerine bir işlevdir.

Ölçeklendiren bir sistem inşa etmede önemli bir teknik, yüksek seviyeli veri erişim gereksinimlerinizi anlamak ve onların etrafında bir arayüz sözleşmesi oluşturmaktır. Örneğin, bir kullanıcıyı alma veya herhangi bir kullanıcı tarafından en son gönderilen 50 fotoğrafı listeleme gereksiniminiz olabilir .

Uygulama iş mantığınız ve veri erişim mantığınız arasında mutlaka bir ağ kanalına ihtiyacınız yoktur; Her mantıksal işlem başına bir yöntem ile bir yöntem çağrısı dolaylı çalıştırma, sadece başlatmak için iyi yapardı.

Bu veri erişim yöntemlerini başlangıçta mümkün olduğunca basit hale getirin. Uygulamanızın gerçek kullanım modellerini sunmasını ve darboğazlarınızın bulunduğu yerle ilgili verileri toplamak için performans sorunlarının nerede olacağını tahmin etmek çok zordur.

İyi tanımlanmış bir veri erişim arayüzüne sahip olarak, tüm uygulamanızda geniş değişiklikler yapmadan veri erişim uygulamanızı geliştirebilirsiniz. Ayrıca, iş mantığınıza şeffaf bir şekilde bir web servis mimarisine geçmeye karar verebilirsiniz.

Yukarıdaki cevapların birçoğu performans darboğazlarınızı keşfettikten sonra nasıl devam edeceğiniz konusunda harika tavsiyeler verir, ancak bunları çok erken uygularsanız, bu karmaşıklığın gerekli olup olmadığını bile bilmeden önce kodunuzun karmaşıklığına bağlı kalabilirsiniz.


4

Basit bir web sitesi geliştir ve trafik seviyesine ulaşmasına izin ver. Çizgiler boyunca, ölçeklenebilir web sitelerinin nasıl yapıldığını öğreneceksiniz.

Sorunla yüzleşinceye kadar çözümü düşünemezsiniz .

Güven bana, sitenin haddeleme ve ölçeklendirme gereksinimi ile karşı karşıya kaldıktan sonra, nasıl yapılacağını kesinlikle bileceksiniz. :-)


Iyi fiyat !!!!!!!!!!
AmirHossein

2

Web uygulamalarının varsayılan olarak üç katmanla tasarlanması gerektiği kabul edilir - web (sunum), uygulama ve veritabanı katmanları. Bu bölüm, her bir katmandaki farklı gereksinimlerden kaynaklanmaktadır - genellikle veritabanı için kaliteli disk erişimi / depolaması, uygulama katmanında yüksek CPU / Bellek ve web katmanında yüksek harici bant genişliği / bellek / coğrafi dağılım. Uygulama / veritabanı katmanı, genellikle uygulama yaşam döngüsünde çok daha sonraya birleştirilir, çünkü veritabanı makineleri genellikle erken uygulama yükünü idare edecek şekilde oluşturulabilecek devasa sunucular olma eğilimindedir.

Uygulamanız için belirli katman sayısı ve uygun mimari, bununla veya başka bir modelle eşleşmek zorunda değildir.

Sisteminizdeki tüm etkinlikleri ölçmeniz ve izlemeniz gerektiğini planlayın. İki veya üç katmanlı bir tasarımdan başlayın ve onu oluştururken en fazla miktarda kaynak gerektirecek gibi görünen kısımlarına odaklanın. Çalışan uygulamanın tasarımınızı bu düzeyde yönlendirmesine izin verin. Ne kadar çok bilgi toplarsanız ve o kadar doğru ve ayrıntılı ise, uygulamayı büyüdükçe tasarlamaya ilişkin daha iyi kararlar verebilirsiniz.

Daha sonra, gerekli değişiklikleri olabildiğince çabuk ve acısız bir şekilde döndürmenize / yapmanızı sağlayacak bir çerçeve ve mimari seçin. Veri erişim / depolama / işleme ve uygulama işlemleriniz aynı çalıştırılabilirde gerçekleştirilse bile, düzgün bir şekilde faktoring olmaları durumunda, örneğin daha sonra iki katmana ayrılması zor olmayacaktır.


2

Veritabanına bağlanmak için herhangi bir ek adım, sadece bir ek yüküdür. Örneğin, UI -> Business Facade -> Business -> Data Access -> Databaseve arasında UI -> Database, ikinci yaklaşım daha hızlıdır. Ancak, ne kadar çok adım kaldırırsanız, sisteminiz o kadar az bakım görülebilir hale gelir ve çoğaltma görünür. Profildeki, giriş sayfasındaki, arkadaşların yönetim sayfasındaki, arkadaşların listesini almak için gerekli kodu yazdığını düşün.

Bu nedenle, burada daha yüksek performans (elbette daha yüksek ölçeklenebilirliği doğrudan etkiler) ve daha iyi bakım yapılabilirlik arasında bir denge kurmalısınız .

Ancak, yüksek düzeyde ölçeklenebilir web siteleri oluşturmayı düşündüğünüzde veritabanı bağlantısı ile sınırlı kalmayın . Bu maddeleri de göz önünde bulundurun:

  1. Doğru platformun seçilmesi (PHP, komut dosyası niteliğinden dolayı daha hızlıdır, ancak ASP.NET'in işlem yapmak ve bir şey sunmak için istenen dosyayı derlemesi gerekir. Ayrıca node.js'nin geri arama nedeniyle daha ölçeklenebilir olduğu iddia edilir. tabanlı mimari )
  2. Web servis modeli yerine RESTful mimarisini kullanma (SOA)
  3. XML yerine veri aktarımı için JSON kullanımı (aktarılan daha az bayt ile sonuçlanan)
  4. Yahoo'nun performans yönergelerine uymak
  5. Yük dengeleme veya katman mimarisi gibi ağ ve donanım konuları

2
PHP'nin daha hızlı olduğunu söyleyemezsiniz. Düzgün yazılmış ASP.NET uygulamaları birçok durumda PHP'den daha iyi performans gösterebilir. naspinski.net/post/AspNet-vs-php--speed-comparison.aspx
Andrew Lewis

+1 Aslında, 'basit' çözümünüz UI -> Veri Erişimi -> Veri Tabanı olacaktır. 2 REST 'kolaydır' çünkü çoğu tarayıcıda yerleşiktir. Komut yanıtı API tekerleğini yeniden oluşturmanıza gerek yok. 3 Sadece JSON daha küçük değil aynı zamanda seri hale getirmek için seri hale getirmek için daha az adım gerektirir, çünkü HTML varlıklarını kontrol etmeniz gerekmez. İyi şeyler.
Evan Plaice

1

Ölçeklendirmenin, büyütmenin ve çıkarmanın iki temel yolu vardır.

Ölçeklendirmek, bir makineyi daha güçlü bir makineyle değiştirmektir. Ölçeklendirme, mevcut makinelerin yaptığı işi yapmak için başka bir makine eklemek anlamına gelir.

Herhangi bir yüksek trafikli web sitesinin ölçeklenebilmesi gerekir. Yapılması gereken yazılım mimarisi öyle bir yoldur ki, daha fazla makine kolayca sitenin aldığı busier'e kolayca eklenebilir.

Genellikle bu, uygulamanın katmanlara bölünmesi anlamına gelir, böylece kişi her katmanda daha fazla sunucu takıp oynayabilir.

1. seçeneği yaparım, doğrudan yapmak yerine bir hizmetim olur. Şimdiye kadar sadece monolitik bir uygulamayı ölçeklendirebilirsiniz.


0

Sitenizi, bulut için tamamen entegre desteği olan bir teknoloji platformu kullanarak geliştirin.

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.