From: BULENT AYDIN (bull_aydin@yahoo.com)
Date: Thu 09 Dec 2004 - 11:46:32 EET
Merhaba,
Sn. Köylü elinize saglik diyelim enfes bir aciklama
olmus...
Sadece kisa bir ek bilgi arkadaslara vermek istiyorum
.
Veritabani sistemleri bu analizi kendileri
gerceklestirip ( Query Optimizer ) , yazilimcilari bu
yüklerden birazda olsa kurtarirlar... Tabi büyük
sorgular da yine düsünmek lazim .. mesela güzel söyle
10 15 tabloluk bir join varsa, query optimizer ters
teper.
kolay gele...
--- Serdar KÖYLÜ <serdarkoylu@fisek.com.tr> wrote:
> Selamlar..
>
> Optimizasyon denen şey, her zaman her sorguda
> (mesela) en iyiyi veren
> şey demek değil ki? Zaten kilit noktası burası. Her
> zaman en iyi olan
> şey, optimizasyon değil, bir kural olur. Hatta bunu
> DB yazanlar
> kendileri koyar sisteme.
>
> Optimizasyon, belli durumlarda (ki bu tamamen veya
> büyük oranda
> uygulamanın doğasına bağlıdır, veritabanı,
> programlama dili, kullanıcı
> alışkanlıkları ileriye yönelik öngörüler vs.)
> istenen en iyi sonucu
> vermek üzere kullanılır. Burada optimum durumu
> yakalamak için bir takım
> işler yapılır. Hatta, bazı durumlarda bu işler
> tersine etki
> gösterebilir. Optimizasyon bir bütündür, GUI'den
> başlar seçilen dosya
> sisteminde biter. Ve aslolarak, öyle büyük, dudak
> uçuklatacak farklar da
> yaratmaz. Ama bir kaç optimizasyon birleşir çoğu
> durumda gerçekten güzel
> olabilir.
>
> Şimdi verdiğimiz örneğe ve senin örnek datana
> bakalım.
>
> f1=d1 or f2=d2 or f3=d3
>
> Bu satır parse edilip işletirken, "or" işleminin
> doğası gereği, ilk
> işlem doğru ise, takip eden karşılaştırma işlemleri
> yapılmaz. Buda benim
> söylediğim optimizasyon örneğinin dayanağıdır. Şimdi
> senin datalara bir
> bakalım:
>
> >p1 p2 ve p4'ten 4'er tane, p3'ten 7 tane girdim
> tabloya.
>
> p1 -> 4
> p2 -> 4
> p3 -> 7
> p4 -> 4
>
> Toplam : 19 Kayıt. Bu halde, bunların frekansları
>
> p1 -> 4/19 -> 21%
> p2 -> 4/19 -> 21%
> p3 -> 7/19 -> 37%
> p4 -> 4/19 -> 21%
>
> Şimdi bu durumda, eğer f1=="p3" cond.u öne koyarsak,
>
> f1="p3" or f1="p1" or f1="p2" or f1="p4"
>
> İşlenen kayıtların
> %37'sinde 1 or işlemi (1ms olsun).
> %21'inde 2 or işlemi (2ms)
> %21'inde 3 or işlemi (3ms)
> %21'inde 4 or işlemi (4ms)
>
> Hesaplarsak:
> 7 * 1ms = 7ms.
> 4 * 2ms = 8ms
> 4 * 3ms = 12ms
> 4 * 4ms = 16ms
>
> Toplam, 43ms sürecek bu WHERE part için gereken
> işlemler.
>
> Şimdi bu ne kadar optimizasyon. Dikkat edersek,
> f1="p3" kuralı, geriye
> kalan %63 için bir tür bariyer oluşturuyor. Bu
> durumda başa bunu
> koyarsan, sorgunun %63'ünde gereksiz yere 1 or
> işlemi fazladan
> yapacaksın. Ama sona koyarsan, bu "en fazla" ama
> frekansı düşük olan
> değer en son bakılarak sorguyu rahatlatacak mı,
> bakalım:
>
> 4 * 1ms = 4ms.
> 4 * 2ms = 8ms
> 4 * 3ms = 12ms
> 7 * 4ms = 28ms
>
> Toplam 52 ms. Bak işte sana optimizasyon. Peki 2.
> Sırada koyarsak:
>
> 4 * 1ms = 4ms
> 7 * 2ms = 14ms
> 4 * 3ms = 12ms
> 4 * 4ms = 16ms
>
> 46ms etti bu kez. Asıl soru şu. Sistem her zaman
> aynı kondisyon içinde
> mi bulunuyor? Çoğu zaman bir önceki sorgu bir
> sonraki sorgunun
> sonuçlarını etkiler. Nasıl dersen, mesela cache'leri
> doldurur/boşaltır.
> Mesela önceki sorgu bufferleri doldurur, sonra gelen
> hazır bulur vs.
> Ayrıca, bu kadar kısa süren bir işlem esnasında
> makinede göremediğin bir
> çok işlemde seni yavaşlatabilir. Her iki sorgu
> arasında makinenin aynı
> interrupt, scheduling, L1/L2 Cache durumlarına sahip
> olduğunu öngörmek
> zor. Sonuç olarak belki böyle 19 kayıt değil, 19bin
> kayıt olsaydı, bu
> optimizasyon anlamlı olacaktı. Fakat, mesela, o
> zaman da Disk I/O ciddi
> bir bootleneck olacak, onun şişirdiği zaman
> nedeniyle bu optimizasyondan
> kazanacağınız mikrosaniyeler önemsiz olabilirdi.
> İşlem optimizasyonla 1
> sn sürsün (=1000 ms, 1000000 mikrosn.), bu
> optimizasyonla atıyorum
> 50mikrosaniye kazanacaktınız. Peki bu tür bir
> optimizasyon nerede
> faydalı olur?
>
> Bir teknik serviste, 1 yıllık kayıt olsun. Bu
> kayıtların çoğu "TESLİM
> EDİLDİ" durumunda olacaktır. Ancak 1-2 haftalık
> işlemler "PARÇA
> BEKLİYOR", "HAZIR", "ARIZASI ARANIYOR" gibi başka
> durumlarda olacaktır.
> Sonuçta kayıtların ilk 1 hafta %2'si "TE" iken,
> örneğin, 4 Ayda %90 "TE"
> olacak, 9. Ayda %99 TE olacak. Eğer siz 1 yıl için
> optimizasyon
> yaparsanız bu or işleminde, yılbaşında bu
> optimizasyon tersine
> yavaşlatacak, ama mesela 3.Aydan sonra, 6.Aydan
> sonra işi
> hızlandıracaktır. Bu bir öngörü. Ama sanırım sallama
> değil makul bir
> öngörü. En azından benim servisimde böyleydi.
>
> Burada programcılığın "analiz" damarına basmanız
> gerekir. Şimdi bir
> haftada 20 iş alıyorsanız, bunların 15'ini 1 haftada
> yapıp, 3'ünü 1 ay
> içinde yapıp, 1'ini 3 ay içinde yapıp, 1'ini hiç
> yapamıyorsanız, bu
> güzel bir havuz problemi olur. Bir havuza vanadan
> haftada 20 ton su
> giriyor. Bir başka vana haftada 15 ton su
> boşaltıyor. Bir diğeri 3 ayda
> 1 ton su boşaltıyor... yıl sonunda havuza giren
> toplam su miktarı,
> havuzda biriken su miktarı...
>
> Gördünüzmü havuz problemleri aslında ne kadar
> mantıklıymış :) "Eeeh, ula
> genemi havuz problemi" derseniz, ne güzel çöpcü
> kardeşlerimiz hiç havuz
> problemi çözmedikleri gibi şu anki hayatlarında da
> havuz problemi ile
> uğraşmıyorlar. Her daim söylemişimdir, kafam
> çalışsaydı çöpcü olurdum.
> Kısaca programcılık böyle bir zenaat, kafa kırmadan
> olmuyor.
>
> Neyse, şimdi havuzumuzda 10000 kayıt olsun. Bunların
> 4. Ayda %90'ı (gibi
> bir değer) "Teslim Edildi" olacak. Bunu
> hesaplayabiliyoruz istatistik
> olarak. Bizim optimizasyon faydalı olacakmı:
>
> %90 of 10000 = 9000 * 1ms = 9 sn.
> %10 of 10000 = 1000 * 2ms = 2 sn.
>
> Toplam sorgu en fazla 11 sn sürecek (daha doğrusu bu
> WHERE part için bu
> kadar zaman kaybedecek). Tersine bakalım:
>
> %10 of 10000 = 1000 * 1ms = 9 sn.
> %90 of 10000 = 9000 * 2ms = 18 sn.
>
> Sadece "a='b' or a='c'" gibi iki ardışık or işlevi
> olsa bile, toplam
> 27sn kaybedecek. 11 ve 27. Sizce bu optimizasyon
> faydalı mı?
>
> Örnekten iyice görülüyordur sanırım.
> Optimizasyonlar, çoğu zaman, çoğu
> durumda ince hesap gerektiren, sistemi, veri
> yapısını iyice analiz
> etmeyi gerektiren bir konudur. Dahası her zaman iyi
> olan
> optimizasyonlarda olmayabilir. Bizim örneğimiz, ilk
> haftalarda işi
> yavaşlatan bir optimizasyon mesela.
>
>
=== message truncated ===
__________________________________
Do you Yahoo!?
The all-new My Yahoo! - Get yours free!
http://my.yahoo.com
_______________________________________________
Linux-programlama mailing list
Linux-programlama@liste.linux.org.tr
http://liste.linux.org.tr/mailman/listinfo/linux-programlama