Karşılaştırma veritabanları

Db 'x' performansıyla ilgili olarak veya 'x' 'den' y 'ye geçiş hakkında birçok tartışmanın site performansımızı iyileştirdiğini görüyorum.

Farklı veri tabanlarında çalışan doğru karşılaştırmayı henüz göremiyorum.

1. İlişkisel, Belge odaklı, vb. Gibi birden fazla db tipinde kullanılabilecek anlamlı bir kıyaslama yazmak mümkün müdür?

2. Böyle bir ölçüt tasarlamak nasıl olur?

Kısa cevap

Evet , çalışılan bir vakanın anlamlı bir ölçütünü yazabilirsiniz, eğer dikkatli bir şekilde yaparsanız ve belirli bir durumla ilgiliyse, diğer durumlar için olmayabilir. Bu, aynı türdeki (ilişkisel veritabanı ile başka bir ilişkisel veritabanı) veya farklı türdeki veritabanları karşılaştırılırken eşit derecede geçerlidir.

Hayır , belirli bir veritabanının her durumda, her uygulama için diğerinden daha iyi olduğunu sihirli bir şekilde kanıtlayacak bir kıyaslama yazamazsınız.

Uzun cevap

"Veritabanından diğerine geçmenin site performansımızı artırdığını" söylemek kesinlikle mümkün.

1. Sorgular ve bunların ne kadar hızlı oldukları hakkında yeterli bilgi toplayarak profilleme veya çalışma zamanı istatistikleriyle önceki veritabanının performansını ölçersiniz.

2. Uygulamayı yeni veritabanına taşıyın.

3. Aynı önlemleri alıyorsunuz.

4. Karşılaştırırsınız.

Örneğin, 3 182 432 ürünün tam listesi 2.834 s'de yüklüyse. eski bir veritabanı üzerinde ve 0.920 s yükler. yeni bir veritabanında, her iki durumda da uygulamanın boş bir önbelleğe sahip olduğu göz önüne alındığında, bu bir kazançtır: yeni veritabanı bu sorgu ile ilgili site performansınızı iyileştirdi.

Şimdi, herhangi bir performans ölçütü olarak, önyargılı:

• Kabul edildi, yeni sorgu daha hızlı. Ancak bekleyin, DBA'nız daha önce sahip olduğunuz veritabanını nasıl kullanacağını bilmiyordu , bu nedenle tüm ürünleri yükleyen sorgu optimize edilmedi . Bu şekilde yeniden yazarsanız, bu ürünleri 0.855 s'de yükleyebilirsiniz. 2.834 yerine.

• Tamam, daha iyi bir sonucun var. Ancak, bir veritabanını , son bakım planının üç yıl önce çalıştırıldığı 10 yıllık bir veritabanıyla temizlenmiş taze verilerle karşılaştırmanın adil olmadığını düşünüyor musunuz? Bu arada, veritabanı ürününü son dört yılda en az bir kez güncellemeniz gerektiğini düşünmüyor musunuz ?

• Bazı sorgular daha hızlıdır. Bazıları daha yavaş. Yeni veritabanına geçerken genel olarak performans kazandığınızı bilmek için ortalama sonucu nasıl hesaplarsınız? Tamam, 3 182 432 ürünlerinin tümünü yüklediğiniz zaman daha hızlı. Ancak sorun, bir yönetici belirli bir görevi yerine getirirken nadir bir durumda web sitesinde yürütülürken son on yılda sadece iki kez gerçekleştirdi mi? Öte yandan, yeni bir kullanıcı için ana sayfada tüm sorguları yürütmek 0.281 s. yeni veritabanı ile, 0.207 iken. eski veritabanı ile. Bu sonuç, özellikle bu sorgular uzun süre önbelleğe alınamadığından ve günde on binlerce kez yürütüldüğünden çok daha önemlidir.

• Her iki veritabanı da aynı sunucularda , aynı donanımda, aynı yapıda test edilmelidir . Örneğin, bir veritabanını tek bir sabit sürücüde, diğerini iki SSD'nin RAID1'inde test edemezsiniz. Büyük bir projeyi yeni bir veritabanına geçirdiğinizde, önceki veritabanının önceki makinelerde kalmaya devam etmesi durumunda, yeni veritabanını yeni dağıtılan yüz raf sunucusunda daha barındırmanız mümkündür.

Özetlemek gerekirse, bir uygulamanın veritabanı sorgularını karşılaştırabilir ve kesin metrikler elde edebilirsiniz . Ama sonra sayılara bir anlam vermelisin. Bu durumda, site performansı kazandığınızı söylemek caziptir: aksi takdirde yönetim, işleri yavaşlatmak için binlerce dolar ve ay harcadığınızı öğrenmek için öfkeli olacaktır.

En korkunç hata bu sonuçları ölçütlerden almak ve "Microsoft SQL Server Oracle'dan üç kat daha hızlı" gibi aptallıkları sonuçlandırmak: "Java PHP'den daha iyi" demek gibi. Daha iyi tanımlayın. Hangi durumlarda daha iyi? Ne tür uygulamalar için? Hangi geliştirici ekibi için?

Ne kadar çok yorum ve genelleme yaparsanız, o kadar önemsiz ve anlamsız hale gelir.

select [...]Dosya # 832 revizyonunda bulabileceğiniz sorgu ProductFactory.cs, satır 117, 0,5 sn'nin altında yürütülür. fonksiyonel olmayan gereksinimler ek M, durum 3'te belirtilen koşullar altında test edildiğinde yeni veritabanı ile çalışır. Bu, fonksiyonel olmayan gereksinimin 527 geçmesine izin verir (bkz. sayfa 80, revizyon 9). Test gereklilikleri 0.9..1.3 s aralığındayken, aynı gereksinim önceki veritabanından memnun değildi. aynı koşullarda.

bir geliştirici için anlamlıdır ve neyin test edildiğini, nasıl ve sonuçların ne olduğunu bilmek için yeterince hassastır. Bu, 2. soruya cevap verir.

Ne yazık ki, yönetim için bir anlam ifade etmiyor. Yerine:

Ürünümün MySQL'den Microsoft SQL Server'ın en yeni sürümüne geçirilmesi, ürünümüzün genel performansını beş puan artırdı, aynı zamanda maliyetleri ikiye ve çevresel etki alanını üç katına çıkardı. Gelecek yıl tüm uygulamalarımızı Microsoft SQL Server'a taşımanın daha iyi sonuçlar vereceğine ve pazar rekabetçiliğimizi artıracağına inanıyoruz.

saf bir pazarlama jibber-jabberidir ve teknik olarak hiçbir şey ifade etmez, ancak şaşırtıcı bir şekilde yönetim ve pazarlama departmanları için bir değere sahiptir.

Son olarak, farklı veri tabanı türlerini karşılaştırabilir miyiz? Tamamen mümkün olduğunu söyleyebilirim. Diyelim ki büyük fotoğraflar barındıran bir web sitem var. Bu fotoğraflar varbinary(max)Microsoft SQL Server 2005'te depolanır (bu yüzden kullanamıyorum filestream). Bu fotoğrafları yüklerken performans konusunda endişeliyim, bu yüzden dosyaları yeni veritabanım olarak kullanarak dosyaları dosya olarak depolamaya karar verdim. İlk olarak, bu dosyalar veritabanıyla aynı makinede saklanır. Yeni çözümün profilini oluşturuyorum ve benim durumumda, dosyaların dosya sisteminden Microsoft SQL Server'dan% 4 daha hızlı yüklendiğini gösteren sonucu elde ediyorum. Benchmark çok açık. Şimdi Microsoft SQL Server için optimize edilmiş sunucuyu kullanmak yerine doğrudan dosya depolama için optimize edilmiş özel bir sunucu dağıtmayı düşünebilirim.

1. Açık kaynak db uygulamalarında büyük veritabanı şirketleri ve geliştiriciler büyük grup ile söz konusu olan tüm para ile, bunu yapmanın bir yolu olsaydı, şimdiye kadar anladım (Ve tüm internet üzerinden sonuçları patlattı. ).

2. Yapmazdım. Bunun yerine, özel ihtiyaçlar ve ortamlar için özel ölçütler oluşturun.

Bir noktada, mevcut para miktarı ve tasarımcının belirli bir veritabanındaki uzmanlığı, sınırlamaları her şeyden çok belirleyebilir. İyi bir Oracle dba, hangi platformu seçtiklerinden bağımsız olarak çoğu genç geliştiriciyi gerçekleştirecektir.

Hayır, aralarındaki farklar, herhangi bir karşılaştırmanın önyargılı olacağı şekildedir.

Bununla birlikte, geniş bir test yelpazesi içeren ve testleri karşılaştırmayı kolaylaştıran (dilden dile özgü testler veya birçok dilden oluşan kompozitler) Bilgisayar Dili Deneyleri Oyunu gibi bir site geliştirmenin bazı faydaları olacaktır ( özellikle de toplumun çözümler sunabilmesi ve şema veya sorgulardaki kısa gelişmeleri iyileştirebilmesi için kurulmuşsa.

DB karşılaştırma sitesi durumunda, algoritmalar uygulamak yerine (dil çekimi durumunda olduğu gibi) testler, belirli kısıtlamalara göre depolanması ve daha sonra alınması gereken ham verilerden oluşabilir. Örneğin, bir topluluk kütüphanesinin kullanıcıları ve kitapları izlemek için neler kullanabileceğini temsil eden basit bir şema temsil eden bilgileri içeren bir dizi ham veri olabilir. Her DB, 1 milyon kaydın tümünü saklamalı ve ardından kısıtlamaları karşılayan verilerin bazı alt kümelerini almalıdır. Daha sonra, 100 milyon kayıt içeren çok basit bir yapı / ilişki (belki de tipik olarak ESPN gibi siteler için kullanılan bir yorum sistemi) temsil eden ve yapılması gereken kendi sorgu kümesine sahip bir veri kümesi de olabilir. . Vb.

DB'leri geniş bir yelpazedeki veri kümelerinde test etmek (karmaşıktan basit ilişkilere, küçük kümelerden humongoza kadar) çok yararlı olabilir, çünkü en azından bulunduğunuz projeye benzer nitelikler taşıyan veriler için genel eğilimleri görebileceksiniz. şu anda değerlendiriliyor.

Birkaç neden daha eklemek istiyorum, neden her türlü veritabanını kıyaslayamıyorsunuz?

1. Veritabanı sistemlerinin iki ana yönü vardır: OLAP ve OLTP ( karşılaştırmaya bakın ).

2. Söylediğiniz gibi, ilişkisel ve belge odaklı veritabanı sistemleri de vardır. RDBS kesinlikle ACID prensibini uygularken , çoğu belge yönelimli DBS'de zayıf verilerin uygulamanız için yeterli olduğuna karar verebilirsiniz. Bu, kilitleme ve zamanlamayı çok daha kolay hale getirir.

Kısacası: Lamborghini'nin dünyanın en iyi arabası olduğunu iddia edemezsiniz . Bagajın hacmini, koltuk sayısını veya kilometreyi düşünün.

Bir yan not olarak: İşte OLTP veritabanı sistemleri için bir kıyaslama.