From: Serdar KÖYLÜ (serdarkoylu@fisek.com.tr)
Date: Thu 16 Dec 2004 - 09:26:24 EET
Selamlar..
> Merhaba,
> Çok rahatlıkla kullanılabilir derken, firmanızın veritabanının kaba bir
> hesapla 1 GB ın altında olduğunu kabul ediyorum. Yine de verdiğim cevap
> kabataslak bir cevaptır, sizin için bağlayıcı olmasını istemem.
1 yerine 10GB olsa neyi değiştirir ki?
Yanlış bilinen bir husus, veri tabanı boyu arttıkça performansın
kötüleşeceğidir. Halbuki, iyi yazılmış bir uygulama, veri tabanı boyu ne
kadar artarsa artsın aynı performansı gösterebilmelidir.
Şimdi, "Efendim rapor çekiyoruz, bu rapor db küçükken 10KB idi, şimdi
1GB oluyor. Bunun yükleme/transfer vs. aynı olabilir mi?" gibi bir soru
aklınıza gelir hemen. Siz kullanıcının önüne asla bu kadar veriyi tek
seferde koymadınız/koymayacaksınız. Örneğin bir defada sadece bir
sayfayı gösteriyorsunuz eli mahkum. Elbette, bir Grid koyar, Bunu da
select * diyerek küt diye doldurursanız, ne o grid dayanır bu yüke nede
veritabanı. Sadece göstereceğiniz kadarını sorgular, o kadarını
yüklersiniz olur biter.
Bir diğer soru da şu olur: "Peki eskiden hesabın borç/alacak
bakiyelerini bulmak için 10 kayıt okuyordu. Şimdi 1.000.000 kayıt
okuyor?" Cache diye bir şey var. Gidip her defasında bu kasmaya sistemi
zorlayacağınıza, ana hesap tablosuna "BB - AB" gibi iki field
eklersiniz, her hesap hareketinde bunları güncellersiniz. Bu sayede
bakiyeleri cache'ye koymuş olursunuz. Yada duruma göre uygun bir
mekanizma koyarsınız. Bir update işleminin işlem başına 2 ms gecikmesini
kullanıcı hissetmez, ama rapor alırken şak diye çıkıvermesini sağır
sultan bile duyar.
Benzer tonla sorun vardır. Ama hepsinin de çözümleri vardır. Vay efendim
veri tabanı büyüdü de yavaşlıyor o yüzden demek "Benim programcılık
kabiliyetim bu kadarcık, işinize gelirse.." Demekle eşanlamlıdır.
Kaldı ki MySQL için 1GB ile 10GB arasında çok bir farkta yoktur. Ama
konu şudur. 1GB veritabanı demek yazma yükünün yüksek olması (birim
zamanda daha çok yazma işlemi) demek. MySQL ise yapısı gereği böyle
yoğun yazma işlemlerine yönelik değil. Zaten felsefesi olan "DB
işlevlerinin sadece %80'i kullanılıyor, geri kalan %20'si için ise
sistemi darboğaza sokacak yapıya ihtiyaç yok." kavramı, yoğun
yazma/update işlevlerinin kırpılmasına yol açıyor. Bu sayede de az
sayıda veri eklenip, çok sayıda okuma yapılan, web sayfası gibi yerlerde
çok çok iyi performans sağlıyor. Kısacası, dizayn edilirken "Düşük
yazma, yüksek okuma" durumuna göre optimize edilmiş.
Sonuçta, MySQL olmazsa Postgress veya Firebird de bir seçenek. Hem de
iyi seçenekler. Ama bir muhasebe programı için, ölçek ne olursa olsun,
mysql'in yetersiz olacağını hiç mi hiç zannetmiyorum. Belki programcı
yetersiz olabilir. Ama o programcıya ORACLE CLuster bile yetmeyebilir..
Saygı ve sevgiler..
_______________________________________________
Linux mailing list
Linux@liste.linux.org.tr
http://liste.linux.org.tr/mailman/listinfo/linux