index konusu (profesyonel kullanım)

[tsamim]

merhaba arkadaşlar ;

Benim sorgularımda bir yavaşlık var bu yüzden index ile ilgili arama yaptım sitede sanki index konusu detaylı konuşulmamış gibi geldi bana.

Firebird'de primary key ve foreign key tanımlamaları var ;

Ancak ben daha önceki veritabanlarından alışkanlığım üzerine ve gereklilik olarak birden fazla alanı kullanarak indexler oluştururum.

Daha önce kullandığım veritabanlarında eğer database'de bir arama yapacaksak use-index kullanarak istediğimiz indexe göre sorgulama yapıyorduk.Buda profosyenel yazılımların hızlı çalışması için olmazsa olmaz şartlardan biridir bence.

Şimdi benim sorunum firebird'de indexleme mantığının nasıl çalıştığı ve mesala ibquery'lerde istediğimiz bir index-name'e göre sorgulama yapabiliyormuyuz şeklinde artı where şartında index'de olmayan bir field kullandığımızda firebird nasıl bir mantık kullanıyor.
Benim özellikle dikkatimi çeken mesala sorgu için kullanıdğımız ibquery'lerde index-name seçimi gibi özellik olmaması query'nin select cümlesini delphi hangi indexe göre çalıştıracağını nasıl belirliyor yada böyle bir kullanımda hep primary key'e göremi sorgulama yapıyor.

Umarım benim bu sorum üzerine bana ve yeni firebird ve delphiye geçen arkadaşlar için daha ayrıntılı bir refarans olacak bir forum olması dileğiyle ilgi gösteren arkadaşların hepsine şimdiden çok teşekkürler ve çalışmalarında başarılar dilerim.

[vedatkaba]

Öncelikle kolay gelsin..

Primarykey:birincil anahtar,bir alanı primarykey olarak tanımlamak o alanın uniqe (yani eşsizlik) olduğunu size garanti eder.tablolar fiziksel olarak primary key alana göre sıralanırlar.
index:index uniqe ve uniqe olmayabilir bu sizin tercihiniz.özellikle tablolarda arama gibi işlemlerde fonksiyonu tartışılmayan bir araç.

firebirde herkes bunu söyler primarykey olan alanı index olarakta belirt diye hızın artsın.veritabanın yapısına göre veritananını indexi kulanma tekniği ayrıdır diye düşünüyorum.

foringkeyi kullanım olarak bahsedeyim biraz.master-detail ilişkili tablolarda diyelimki detail tabloya 1 den fazla kayıt girmek istediğim zamanlarda detaile forinkey oluşturuyorum,ve istediğimi bu şekilde yapabiliyorum.bu anlamda alırsanız yardımcı anahtar olarak tanımlayabilirsiniz.SQL dilinde bu şekilde bir anahtarlara bir ad veriliyordu aklıma gelmiyor şu anda.ben o şkilde tanımlıyorum yanlışım varsa düzeltin.

Birde compositekey(karma anahtar)iki alanı birden kontrol eden anahtar.

GEreksiz idex tanımlamak ta hızımızı artırmak yerine düşürebilir.kolay gelsin.Firebird ün nasıl kullanıdığı açısından tam emin değilim ama kanaatimce indexli alan varsa onu kullanıyor yoksa normal yolları kullanıyor diyebilirim.yanlışım olabilir.sonuçta where ifadesine koşul koyduğunuz zaman o alan indexli değilse hızınız yavaş olcak diye bir şey olamaz,var olan indexi kullanacaktır diye düşünüyorum.

[sadettinpolat]

çok emin olmamakla birlikte select ifadesinde hangi indexi kullanmak istediğinizi belirtebiliyor olmanız gerekiyor. eğer belirtmezseniz firebird uygun bir index seçiyor.

Kod: Tümünü seç

select * from TabloAdi plan IndexAdi

[fduman]

Interbase PDF'lerinde yeterince detaylı açıklanmıştır. Ben biraz özetleyeyim.

Şimdi benim sorunum firebird'de indexleme mantığının nasıl çalıştığı ve mesala ibquery'lerde istediğimiz bir index-name'e göre sorgulama yapabiliyormuyuz şeklinde artı where şartında index'de olmayan bir field kullandığımızda firebird nasıl bir mantık kullanıyor.

Firebird sorgularda kullanılacak Index'leri belirlemek için içsel, zeki bir algoritmadan faydalanır, bu algoritma index kullanıldığında daha mı hızlı erişilir, index istatistikleri gibi verileri kombine ederek hangi indexi kullanacağına karar verir. Buna müdahale etmek mümkündür. Çünkü özellikle çok karmaşık sorgularda her zaman doğru karar veremeyebilir. Bunun için hangi indexi kullanacağını belirleyen PLAN'i biz gönderebiliriz. Eğer Where şartında index'te tanımlanmayan bir alan var ise Firebird bu alanı bütün veri tabanında sequential olarak tarar. Bu da fazla kayıt olduğunda performansı azaltır.

Firebird'de bir index içinde birden fazla alan tanımlanarak da kullanılabilir. Örneklemek gerekirse:

INDX_TEST indexinin içinde ADI, SOYADI alanları atanarak bu alanların beraber indexlenmesi sağlanabilir. Bu kullanımda dikkat edilmesi gereken Alanların indexte tanımlanma sırasına göre index kullanan işlemlerde kullanılmasıdır. Misal:

Kod: Tümünü seç

SELECT * FROM HEBE ORDER BY ADI, SOYADI

indexten faydalanarak sıralama yaparken,

Kod: Tümünü seç

SELECT * FROM HEBE ORDER BY SOYADI

indexten faydalanamaz, çünkü ADI alanı index içinde daha önce tanımlanmıştır.

Daha detaylı bilgiyi ve PLAN oluşturulmasını bu PDF leri indirip okuyarak öğrenebilirsin.

[fduman]

Bir ek daha yapayım. Index'ler defaul olarak ASC olarak sıralanır. Yani küçükten büyüğe doğru. Eğer sizin indexiniz de ASC olarak sıralı ise:

Kod: Tümünü seç

SELECT * FROM HEBE ORDER BY ADI DESC

türünde tersten sıralama yapan bir sorgu indexinizden faydalanamaz. DESC sıralama için ayrı bir index yaratmanız gerekir.

[Kuri_YJ]

Selamlar,

viewtopic.php?t=581&highlight=

Burada indeks nasıl kurulmalı Table'lar nasıl yapılandırılmalı üzerine örnekler veren ve (daha profesyonel) indeks kullanımları hakkında bir takım bilgiler vermiştim.

Sanırım işinize yarayacaktır. Ayrıca B-Tree (Binary Tree) indekslerin çalışmasındaki yük dengelenmesi hakkında fikir edinirsiniz.

Kolay Gelsin

[tsamim]

Arkadaşlar ilginiz için çok teşekkürler ;

Cevaplarınızdan anladığım kadarıyla use-index diye bir kullanım yok herhal peki tanımladığım index sirket-kodu;mali-yil,musteri-kodu şeklinde

sql cümlelerinde where şartında bu fieldları kullanım sırasının önemi varmı ,

örneğin where sirket-kodu = :esirket and mali-yil = :eyil and
musteri-kodu = :emus ile

where musteri-kodu = :emus and sirket-kodu = :esirket and mali-yil = :eyil

indeximde primary-key olarak mesala sirket-kodu+mali-yil+musteri-kodu olarak tanımlı

bu iki kullanım arasında bir hız farkı varmı ?


Yinede benim daha önceki veritabanlarından tecrübem istediğimiz indexe göre sorgulama yapmamızı sağlıyacak bir komut olması gerkmiyormu diyor.

iyi çalışmalar ;

[Kuri_YJ]

Selamlar,

Aşağı yukarı aynı sırada yazmanız tavsiye edilir, zira indexin otomatik seçilmesinde bazen yanlış index seçebiliyor, bunun için plan analysis'ler yapılması ve Index Tuning olayları filan gerekli olur.

Karmaşık query'lerde zaman zaman doğru indexi seçmediği olur bu gibi durumlarda Forced Index (Zorlamalı Index Kullanımı) yapmanız lazım bu da kullanılan veritabanının SQL syntax'ına göre değişir ama (Standard SQL'de var mıdır bilmiyorum ama muhtemelen vardır) bunu inceleyin.

Ama basit Query'lerde şaşırmaz !... Yani verdiğiniz örneği rahatlıkla algılayıp doğru indexi seçip kullanır.

Bu arada ek bir bilgi daha, Eğer MAX gibi bir Aggragate kullanıyorsanız MAX yaptığınız alan için DESC bir index tanımlamalısınız. Bu da MAX sorgusunda bu indexi kullanmasını sağlar ve hız inanılmaz artar. Aksi halde indexi kullanamayacağı için Table scan yapar. Takdirinizdir ki, Index ile Table scan arasında büyük farklar vardır (Hız açısından).

Kolay Gelsin

[tsamim]

Arkadaşlar çok teşekkürler ;

Benim için cevaplarınız ve verdiğiniz linkteki açıklamalar gerçekten yeterli oldu
index kullanımı için tekrar teşekkürler çalışmalarınızda başarılar dilerim.

Her şeyden önemlisi harcadığınız vaktin karşılığını almanız dileğiyle.

[mkysoft]

yazdıklarınız çok yararlı geldi. benim aklıma indexlerin yönü (asc veya desc) takıldı. benim kullanığım yönetim araçlarında idex yönü seçimi ile ilgili bir seçenek yok. buda aklıma yönün fark etmediği ihitmalini getirdi. matıkende sıralanmış bir dizi veriyi tersten okursak yine sıralı elde ederiz. neden tekrar sıralamaya çalışsınki? garip geldi bana. mysql kullandığımdan onun user manuel'ine baktım böyle bir parametre ve bilgi yok. firebird'e özel bir durum olabilir. mantığa aykırı genede.

[vedatkaba]

Aslında index yönü diye bir olay bilmiyorum yok diye biliyorum.

mesela tarihsel bir alan vardır ama index değildir

Kod: Tümünü seç

order by tarih asc

diyerekte sıralama yapılabilir.

[fduman]

Index yönü vardır. Indexsiz alanların sıralanması sequential okuma ile daha yavaş olarak gerçekleştirilir.

Interbase manual'lerinde index yönü hangi yönde düzenlenmişse sadece aynı yönde yapılan sorguların indexten faydalanabildiği yazar. Tersi yöndeki sorgular için ters yönlü bir indexin olması gerektiği belirtilir. Mantıksal nedenini bilmiyorum. VT motorunun çalışma yapısından kaynaklanıyor olmalı.

[vedatkaba]

;Hocam teşekkür ederim , sağolun bunuda öğrenmiş olduk.Firebird ve interbasele ilgili o kadar yüksek bilgiye sahip değilim yavaş yavaş İnşallah öğrencez.
Kolay gelin.

[Kuri_YJ]

Selamlar,

Index yönü vardır ve olmalıdır (yani mantığa aykırı bir durum yok) B-Tree indexlemede aradığınız şeyin nerde olduğunu bulmak açısından eğer descend bir index'iniz var ise Kök sayfada (yani ilk okunacak index sayfasında en büyük değerler durur)

Bunu 1000 sayfalık bir kitaba baktığınızı düşünün, 994. sayfaya ulaşmak için ilk 994 sayfayı atalyıp 994. sayfaya gözünüzle bakarak arayarak yaparsını) Bunu 1000'den geriye doğru başlayıp giden bir dizilimde yaparsanız ilk bir iki sayfaya bakarak 994. sayfaya ulaşırsınız (kitabın sayfa sayılarını tersten tuttulduğunu düşünün).

ASC-DESC farkı burda, yani bir tabloda bazı bilgilere ihtiyacınız var ki bu bilgiler daima büyük değere sahip olanlarını seçmeniz gerekmekte. O zaman DESC index işinize yarayacaktır.

Diyelim ki elinizde toplam verinin %90'nında 10'dan küçük, Kalan %10'luk kısımda 10'dan büyük değerlerin olduğu bir Tablo olduğunu düşünün veya veri yükünüz bu şekilde olduğunu düşünün. Ve benim sorgularımın %80'i bu 10'dan büyük rakamlara yönelik. Ben bu durumda DESC index tanımlarım (çünkü sistem az adımda istediğim veriye ulaşsın) aksi takdirde sisteme daha fazla yük bindirmiş olurum.

Bu anlatmaya çalıştıklarım, DESC veya ASC index'in sisteme sağladığı yararlardı, bir de Madalyonun öbür yüzü var, bize sağladığı yararlar.

En başlıcası, Sıralamalı sonuçlar. Yani bir liste hazırlıyorsunuz , Ad ve Soyada göre sıralı olsun. Aynı listeyi Doğum tarihine göre ama En son doğan kişiden en önce doğan kişiye göre sıralı getirmek istediğinizde yada En son kesilen faturadan geriye doğru dizilimli bir liste yapacaksınız.

ASC veya DESC indexleme mantıkları olmasa nasıl yapacaksınız bunları? Oturup sizin yazmanız gerekecek

Ayrıca bu söylediklerim IB yada FB'ye özgü bir şey değil, RDBMS'lerin hepsinde olması zorunlu şeyler yani SQL'in kendinde var bu !...

Kolay Gelsin