Birden fazla veritabanı erişimi veya bir toplu erişim?

Performans ve optimum kaynak kullanımı söz konusu olduğunda daha iyi bir yaklaşım: AJAX ile bir veritabanına yalnızca ihtiyaç duyulduğunda tam olarak gereken bilgileri elde etmek için birden çok kez erişmek veya gerekli olabilecek tüm bilgileri içeren bir nesneyi almak için bir erişim gerçekleştirmek , aslında hepsi gerekli değil yüksek bir olasılık ile ?

Gerçek sorguları nasıl kıyaslayacağımı biliyorum, ancak binlerce kullanıcı aynı anda veritabanına erişirken veritabanı bağlantısına gelince ve bağlantı havuzunun nasıl devreye girdiğini en iyi şekilde nasıl test edeceğimi bilmiyorum.

Buna doğru bir cevap yok; Herhangi bir optimizasyonda olduğu gibi, büyük oranda içerik / kullanıma bağlıdır.

Ancak, aşağıdakileri genel kural olarak düşünün:

x
+: Data is stable / static
-: Data is dynamic / volatile

y
+: Data is frequently used
-: Data is infrequently used

++: fetch large chunks in the fewest number of fetches 
    and persist the data as long as possible within tolerances for staleness.

+-: do what is expedient to the logic & usage; if it is convenient to 
    fetch / calc as needed do so, if it is convenient to pre-fetch and 
    persist then do so. Seek to optimize only if absolutely necessary.

-+: fetch / calc as needed; but if optimization is required consider 
    pre-fetching or pre-calculating if possible, or negotiate a tolerance 
    for less than real time accuracy to reduce volatility.

--: fetch / calc as needed and don't worry about it further unless a 
    specific case is unacceptably expensive; if so see -+.

İlk optimizasyon kuralını hatırlayın: ölçün, tahmin etmeyin . Her ikisini de deneyin, onları bir tür kronometre koduyla çalın ve ne kadar uzun sürdüğünü görün.

Ayrıca eski şakayı da “bilgisayar biliminde sadece iki zor sorun var: önbellek geçersiz kılmak ve bir şeyleri iyi adlandırmak” olduğunu da aklınızda bulundurun. Her şeyi DB'den aynı anda çekip bellekte tutarsanız, önbelleğiniz olur. Ve şimdi yeni bir probleminiz var: sistemin herhangi bir yerinde herhangi bir şey değiştiğinde , iki yerde aynı değişikliği yapması gerekir: veritabanı ve önbellek. DB ile konuşurken birden fazla sunucunuz veya sunucunun verilerini değiştirmesini sağlamak için birden fazla API'niz varsa, bu çok hızlı bir şekilde zor olabilir.

Bu soruya NO gümüş kurşun çözümü yoktur. Muhtemel değiş tokuşları denemeniz ve sunucularınızı en iyi şekilde kullanabilmeniz için ayarlamalar yapmanız gerektiğini düşünüyorum.

Birinci nokta: Herhangi bir iyileştirme yapmaya başlamadan önce mevcut performans ölçütünüzü ayarlamanız , ölçmeniz ve iyileştirmek için olası çözümleri karşılaştırırken bir temel almanız gerekir.

İkincisi, uygulama kullanımının izlenmesi gerekiyor. Uygulamanın son kullanıcılar tarafından nasıl kullanıldığı. Aşağı Kesme döndürülen verilerin ham numaralar son kullanıcıya gerekli değildir (ler) olabilir size çok değerli sunucu kaynaklarını kurtarmak . Örneğin: kullanıcılar ilk 50 ile ilgilenirken 5000 kayıt döndürmenin anlamı yoktur.

Üçüncü nokta: Arama sıklığını ve olası sonuçları anlamak zorundasınız. Örneğin: çoğu çağrı arama değeri tablosu sorgusu ise, muhtemelen bu çağrıları önbelleğe almak için bir altyapı oluşturabilirsiniz . Başka bir deyişle, verileriniz çok sık değişmiyorsa, önbelleğe alma seçeneğini göz önünde bulundurun. Ve elbette, çağrı sayısının en aza indirilmesi her zaman performansı artırmaya yardımcı olmalıdır.

Her şeyi bir kerede almak, "her şey", BLOB'lar veya benzer şekilde büyük veri nesneleri gibi şeyler içermedikçe, size daha iyi performans verecektir. Her şeyi serileştirmek, telin üzerinden taşımak, ardından diğer ucundan seri hale getirmek için kullanılan genel performans, ağ gecikmesi büyük bir parçası olarak oldukça önemlidir. Bellek, ağ bant genişliğinden daha ucuzdur ve büyük olasılıkla bir süre daha kalacaktır. Tek gerçek cevabınız bir kriterden gelecek, ama eğer sadece diğerini ölçmeye çalışıyorsanız, yalın kalmamın yolu budur.

Mimari bir karar veriyorsanız, REST bir seçenektir. REST ile, her zaman bir kaynak için her zaman birden çok istek istersiniz, yani her nesnenin kendi URL'sine sahip olduğundan 2 nesne alma isteği göndermezsiniz. Bu tarzın yapılması ile ilgili performans endişesi, muhtemelen HTTP / 2.0 çıktığında çözülecek. Aksi takdirde, sadece olabildiğince hızlı hale getirmek için en iyi duruma getirirsiniz. Birçok şirket bu şekilde yapıyor.