Google BigTable'larda (ve diğer entegre DB'lerde) performans testi alın ve koyun

Özellikle veritabanlarının kendilerine ayrılmış araçlar sunmadığı ortamlarda, veritabanı işlemlerinde programlı performans testi gerçekleştirmenin etkili yolları nelerdir?

Örneğin, Google App Engine'de tüm sayfa yüklemeleri, belirli veritabanı işlemlerini içerebilecek tek bir işlem olarak değerlendirilir. Bu sorun SQLite ve diğer tümleşik DB'lerde de vardır. Test edilmesi gereken (eşdeğer) seçimleri ve ekleri tamamen soyutlamak zor olduğundan, bu tür sorgularda daha kapsamlı tanılama yapmak için önerilen veritabanı araçları var mı?

— Brian Ballsun-Stanton
kaynak

Söz konusu veritabanına doğrudan erişiminiz var mı?

— Stingervz

Evet, uygulamayı yazan benim. Ve uygulama performansı farklı bir soru olsa da, yazdığım kötü bir sorguda oldukça ciddi performans hitleri alıyorum.

— Brian Ballsun-Stanton

Bazen bir düzine göz çifti, bir sorgu analizcisinden daha iyi bir

— tanıdır

@Brian DBA'dan daha çok bir programlama sorusu olduğundan Stackoverflow üzerinde bu tür bir soru ile daha iyi yapacağınızı düşünüyorum.

— IamIC

@IanC Drat. Ben bir bütün olarak performans yerine bigtable underlay almaya çalışıyorum. Ancak insanlar soruyu uygun bulmazlarsa silerim. (Ayrıca sitenin her zaman oracle / sql-server / mysql olmadığından emin olmaya çalışıyorum)

— Brian Ballsun-Stanton

Yanıtlar:

Bana göre sorun, temel db iyi desteklenmeyen performans metriklerini test etmeye çalışıyor olmasıdır. Bu, sistemler arasındaki performansı karşılaştırmayı çok zorlaştırır, çünkü temeldeki yaklaşımlar çok farklıdır. RDBMS türü yaklaşımlar için ORDBMS türü yaklaşımların karşılaştırılması için elma ile elma karşılaştırması yapabileceğinizi düşünmediğim için elma ile elma karşılaştırması yapmanın mümkün olduğunu düşünmüyorum. Performans kaygıları çok farklıdır ve Stonebraker, TPC-C testleri için bir ORDBMS'yi optimize etmek noktayı kaçırırsa, o zaman daha da uzak olan sistemler için bu imkansız olacaktır. (Ancak, sadece ORDBMS işlevselliğinin devreye girdiği yerde olduğunu düşünüyorum.)

Dürüst olmak gerekirse, her sistemi nasıl kullanacağınıza bakmak ve her biriyle alacağınız yaklaşıma dayalı bir kıyaslama aracı oluşturmak olduğunu düşünüyorum. Ardından, en azından bu iş akışı için karşılaştırmanın belirli bir şey gösterdiğini söyleyebilirsiniz. Ancak nasıl genelleme yapabileceğinizi anlamıyorum. Çeşitli motorlarda test çalışmasında zamanın nerede geçtiği hakkında ek bilgi almak için bir profiler içinde çalıştırabilirsiniz.

Bununla birlikte, db kıyaslamasının en iyi koşullarda anlamlı hale getirilmesi çok zordur ve benzer sistemleri karşılaştırdığınızda genelleme yapmak imkansız hale gelir.

— Chris Travers
kaynak

Appstats , App Engine'deki performansı ölçmek için temel araçtır. Grafiksel bir grafikte veri deposu, memcache, urlfetch ve posta istekleri dahil olmak üzere her RPC için kullanılan zamanı gösterir. Normalde istekler, her isteğin, bir sonraki satırın aşağısında bir önceki isteğin sona erdiği noktada başladığı bir "merdiven" olarak görünür.

Ndb'de gelişmiş eşzamansız istekleri kullanırsanız, isteklerin paralel olarak gerçekleştiğini görebilirsiniz.

Bu araç, zamanın nerede harcandığını ve sorguların nasıl optimize edileceğini görmemde bana çok yardımcı oldu.

— Brent Washburne
kaynak