mySQL’de Veri Girerken Gitgide Büyüyen Sorgu Zamanları Hakkında

Yazan: Faruk Enes | Tarih 30 Mart 2006 | Yorum  2 Yorum
BerbatKötüOrtaGüzelHarika Henüz puan verilmemiş
Loading ... Loading ...

Daha önce biraz not düştüğüm nested hiyerarşi modelini son günlerde geliştirdiğim bir uygulama için kullanıyordum. Uygulamın bir parçası daha önce hazırlamış olduğum bir takım verileri dönüştürmekten oluşuyordu. Yani daha önce nested modele göre hazırlanmamış olan hiyerarşik verilerimi bu modele uygun olarak dönüştürmem gerekiyordu. Bu yaklaşık 50 bin satır veri, girilen veri başına ortalama 4 sorgu anlamına geliyordu.

Ancak şöyle bir sorun 4-5 gündür beni son derece uğraştırmakta. Sorun şu : İlk girilen veriler birkaç milisaniye ile girilirken, girilecek veri boyutu arttıkca veri girmeden önce yaptığımız SELECT ve UPDATE sorgularının hızı oldukça düşmekteydi. Veri büyüdükçe daha çok büyüyordu ( Her ne kadar zaman saniyeyinin 100′de 1′i gibi gözükse de çoklu sorguda bunun yaklaşık olarak iki ile çarpılarak gitmesi gerçekten 50. sorguya yaklaşık 6-8 saatte ulaşmanızı sağlıyor. ( 1.7 celeron, 1Gb ram, 5400 rpm harddiskte 6-8 saatken 3K AMD, 2GB ram ve 7200 rpm bir canavar makinede bu 3-4 saate düşüyor ki çok büyük bir rakam ) ).

Hızın aklınızda canlanması için basitçe yazayım :

Birinci elemanda hız şu şekilde : ( SELECT/UPDATE/INSERT nested modele göre yapılan sorguları, yanındaki rakam kaç satırın etkilendiğini/eklendiği son sayı ise saniye cinsinden tutan zamanı veriyor )

SELECT : 1 0.00029993057251
UPDATE : 1 0.000178098678589
INSERT : 1 0.000231027603149

6000. elemanda süre şu şekilde oluyor :

SELECT : 1 0.00906920433044
UPDATE : 2 0.0255489349365
INSERT : 1 0.000332117080688

12000. elemanda ise süre şu şekilde oluyor :

SELECT : 1 0.0215570926666
UPDATE : 1 0.0501120090485
INSERT : 1 0.00169897079468

Gördüğünüz gibi insert sorgularindaki hiz pek degismekten SELECT ve UPDATE katlanarak gidiyor. 50 binlere geldiğinizde ise saniyeyi buluyor.

Sorunun nedenine gelirsek…

Acikcasi bana komik geldi. Cunku ben indeksler veri girmeyi uzatmasin diye sadece primary indeks kullanmistim. Sagda solda soruma cevap ararken manual’da Speed of SELECT Queries kismina gozum takildi. Burada yazan bir cumle yaptigim hatayi anlamama neden oldu :

the first thing to check is whether you can add an index

Bu cümleyi görene kadar sanki herşeyi doğru yapıyormuşum gibi, hatta insert sorgularini cok hizlandirdigimi dusunerek en iyisini yaptigim gibi dusunuyordum. Ama bu cumleyi gorunce “Ansugo! Sen select ve update yaparken 5 farkli kolondan AND ile kontrol yapmiyor musun?” diye dusundum. Ama olur mu canim? Ben indeksleri kaldirarak veri girisini (insert sorgularini) hizlandirmamis miydim?

Maalesef hizlandirmamisim! Cunku sorgulama yaptigim alanlarin hepsine indeks tanimladiktan sonra yaptigim insert sorgularida indekssiz olanla saniyenin 10binde biri kadar fark yaratti. Ama muthis bir fark daha yaratti : 8 saat bekledigim sorgu 3 dakikada bitmisti!

Konuyu toparlarsak; ‘de insert sorgularinda performans kaybi yaratan indeks tipi anladigim kadariyla FULLTEXT indeksler. Onun haricinde rakam olan indeksler bir performans kaybi yasatmiyor.

Bununla beraber sorgulama yapilan alanlar indeksli degilse veri buyudukce muthis bir performans kaybi yasaniyor. Bu performans kaybi 1. kayit ile 50 bin kayit arasinda ortalama 3000 kat fark ediyor!

Yazdır Yazdır | 171 Görüntülenme | Kategori: Veritabanları & SQL | Trackback  Geri İzleme
Etiketler  Etiketler: ,

Benzer Yazılar


Yorum Yap


(gerekli)

(gerekli,yayınlanmaz)




XHTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>