Tuesday, October 30, 2001

SQL veri analizi nasıl hızlandırılır

Veri inclemek icin SQL dilini kullanan programcilar icin yaziyoruz. Ozellikle CRM, yani veri ambari olan programlarda, SQL dilini cok kullanacaksiniz. Servis programlarinda genelde SQL veri analizi 30,000 satirlik veriyi gecmez.

Veri ambarlari daha cok veri isler, o yuzden daha degisik tekniklere ihtiyac duyarlar.

Eger ambar SQL kodunu, internet sitelerinde kullanilan SQL kodu gibi yazarsaniz, saatlerce ekran basinda beklersiniz, SQL kodu katiyen isini bitirip geri gelmez.

Bu yuzden, SQL kodunuzu hizlandirmanin yolunu bulmaniz lazim. Kullanilan metodlar arasinda


* Tablo uzerinde dizin yaratma
* SQL koduna 'dizin' kullandirtma
* 'Gecici' tablo olurturma

Dizin nedir, acele isleyelim. Bildiginiz gibi veri tabani kayit tutar. Bu kayitlar tablolar icinde tutulur. Tablo ne oldugunu anlamak icin, diger yazilarimiza bakabilirsiniz. Hemen ornek bir veri tabani tablosu gosterelim.
MUSTERI
(
ISIM VARCHAR2(100),
SOYAD VARCHAR2(100),
EMAIL VARCHAR2(100)
)

Tablo veri turudur. Yani veri tabanina diyorsunuzki "Bu sekilde verileri bu tablo adi altinda girecegim, hazir ol". Bundan sonra veri tabanina SQL dilini kullanarak veri girebilirsiniz. Mesela
INSERT INTO MUSTERI ('Burak', 'Bayramli', 'burakbayramli@sk.com');

Eger veriye erismek istiyorsaniz, (mesela butun verileri ekranda gosterelim), o zaman tekrar SQL dilinde
SELECT * from MUSTERI;
.. diye bir kod isletmeniz yeterlidir.

Fakat, sadece belli kayitlara erismek istiyorsaniz, o zaman 'secici' SQL kodu kullanmaniz lazim. Mesela sadece ismi 'burak' olan kayitlari bulalim.
SELECT * from MUSTERI WHERE ISIM = 'Burak';

Iste dizinler, bu gibi SQL kodu hizlandirmak icin isinize yarar. dizinler kutuphanelerde olan kitap kartlari gibidir, hani bir kitabi bulmak icin once o kartlara bakip, nerede oldugunu ogrenirsiniz, ve direk o bolume gidersiniz. Veri tabani dizinleri ayni sekilde isler. Her tablo uzerinde dizin yaratabilirsiniz. Bir tabloda birden fazla dizin olabilir. Dizin yaratmak icin bir ornek verelim.
CREATE INDEX MUSTERI_DIZIN ON MUSTERI(ISIM)

Bu komutu isleterek veri tabanina dedinizki "Eger isim hanesini kullanara musteri tablosuna erisenler olursa, islemi dizin kullanarak yap". Dizin kullanan SQL kodu daha cabuk isler. Genelde dizinler otomatik olarak bulunur ve kullanilir veri tabani tarafindan. SQL programinizin degismesi gerekmez.

Not: Veri tabanlarinda tabii ki hicbir sey bir baska sey kaybetmeden kazanilmaz. Dizinlerin surekli guncel tutulmasi gereklidir, buda zaman alir. O yuzden her INSERT kodu artik daha yavas olacaktir. Alin size muazzam bir muhendislik problemi: "Programiniz daha cok analizmi yapiyor, yoksa verimi ekliyor". Eger analiz yapiyorsaniz, cok dizin eklemenin pek zarari olmaz. Ekleme yapiyorsa, dizinleri azaltin.

Gelelim ikinci metoda: Dizin kullandirma. Biraz once bahsettik, dizinlerin kullanilmasi otomatik olarak veri tabani tarafindan yapilir. Fakat bazen Oracle gibi gelismis veri tabanlari bile, hangi dizini kullancagini karistirabilir. Bu aslinda cok normal, sonucta milyonlarca kodluk programlar olsada, SQL programcilarinin beynini okuyacak seviyede degiller. Bazen Oracle cok kotu analiz karari alabilir.

Iste bu gibi vahim zamanlarda, SQL kodunuza "tiyo" vermeniz gerekir. Yani diyeceksinizki "Sayin oracle, biraz kafan karisti galiba, hangi dizin kullanacagini unuttun, al bunu kullan". Bunun kod olarak sekli:
SELECT /*+ INDEX (MUSTERI_DIZIN) */ ISIM FROM MUSTERI WHERE ISIM = 'burak';

Boylece Oracle, dogru dizini bularak veriye hizli sekilde erisebilir.

Ucuncu teknik, gecici tablo olusturma. Gecici tablolari, cok zor gorunuslu SQL kodunu parcalamak icin kullanin. Unutmayin, eger 3~4 sayfalik SQL kodu yazmissaniz, Oracle perde arkasinda komik seyler yapabilir. Veri tabanini belli sekilde isleme 'zorlamak' icin, SQL kodunuz parcalara ayirin, ve gecici tablolar olusturun, o tablolari alip sonraki tabloya koyun, vs. Unutmayin, eger gecici tabloyu siz olusturduysaniz kontrol sizde, eger Oracle olusturursa, sistemin vefasina kaldiniz demektir. Kontrolun elde olmasi her zaman daha iyidir.

No comments: