Veritaban\u0131 performans\u0131n\u0131 k\u00f6kten de\u011fi\u015ftirmek ister misiniz? Bu makalede, veri eri\u015fimini h\u0131zland\u0131ran indeksleme ve hashing tekniklerini \u00f6\u011frenirken, sorgu optimizasyonu ile uygulamalar\u0131n\u0131z\u0131 nas\u0131l u\u00e7uraca\u011f\u0131n\u0131z\u0131 ad\u0131m ad\u0131m ke\u015ffedin. Haz\u0131rlan\u0131n, \u00e7\u00fcnk\u00fc yava\u015f sorgular kabusunuz olmaktan \u00e7\u0131kacak!<\/p>\n
G\u00fcn\u00fcm\u00fcz\u00fcn dijital d\u00fcnyas\u0131nda, kullan\u0131c\u0131 deneyimi h\u0131zla e\u015fanlaml\u0131 hale geldi. Bir web sitesine girdi\u011finizde veya bir mobil uygulamay\u0131 kulland\u0131\u011f\u0131n\u0131zda, verilerin an\u0131nda y\u00fcklenmesini, i\u015flemlerin gecikmesiz tamamlanmas\u0131n\u0131 bekleriz. Ancak arkada yatan veritaban\u0131, milyonlarca hatta milyarlarca sat\u0131r veriyi y\u00f6netmekle y\u00fck\u00fcml\u00fcd\u00fcr. Bu devasa veri y\u0131\u011f\u0131nlar\u0131 aras\u0131nda do\u011fru bilgiyi bulmak ve size sunmak, iyi optimize edilmemi\u015f bir veritaban\u0131 i\u00e7in ger\u00e7ek bir m\u00fccadeleye d\u00f6n\u00fc\u015febilir. Yava\u015f yan\u0131t s\u00fcreleri, uygulamalar\u0131n \u00e7\u00f6kmesi, m\u00fc\u015fteri kayb\u0131 ve hatta i\u015f s\u00fcre\u00e7lerinde aksakl\u0131klar gibi ciddi sorunlara yol a\u00e7abilir. Veritaban\u0131, bir uygulaman\u0131n kalbidir ve bu kalp yeterince h\u0131zl\u0131 atmad\u0131\u011f\u0131nda, t\u00fcm sistem etkilenir.<\/p>\n
Peki, bu veritaban\u0131 performans sorunlar\u0131n\u0131n k\u00f6k nedenleri nelerdir? Genellikle, veriye eri\u015fim y\u00f6ntemlerinin verimsiz olmas\u0131, sorgular\u0131n k\u00f6t\u00fc yaz\u0131lmas\u0131 veya veritaban\u0131n\u0131n fiziksel yap\u0131s\u0131n\u0131n yanl\u0131\u015f tasarlanmas\u0131 gibi fakt\u00f6rlerden kaynaklan\u0131r. \u0130\u015fte tam da bu noktada, indeksleme, hashing ve sorgu optimizasyonu gibi teknikler devreye girer. Bu kavramlar, sadece veritaban\u0131 y\u00f6neticileri veya geli\u015ftiriciler i\u00e7in de\u011fil, ayn\u0131 zamanda veriye dayal\u0131 herhangi bir uygulamay\u0131 geli\u015ftiren veya kullanan herkes i\u00e7in kritik \u00f6neme sahiptir.<\/p>\n
Bu kapsaml\u0131 makalede, veritaban\u0131 performans\u0131n\u0131 en \u00fcst d\u00fczeye \u00e7\u0131karmak i\u00e7in kullanabilece\u011finiz bu g\u00fc\u00e7l\u00fc ara\u00e7lar\u0131 derinlemesine inceleyece\u011fiz. \u0130lk olarak, indekslemenin ne oldu\u011funu, farkl\u0131 t\u00fcrlerini ve veriye eri\u015fimi nas\u0131l h\u0131zland\u0131rd\u0131\u011f\u0131n\u0131 anlayaca\u011f\u0131z. Ard\u0131ndan, veriye daha da h\u0131zl\u0131 ve do\u011frudan eri\u015fim sa\u011flayan hashing mekanizmalar\u0131na g\u00f6z ataca\u011f\u0131z. Son olarak, sorgu optimizasyonunun neden bu kadar \u00f6nemli oldu\u011funu ve veritaban\u0131 sorgular\u0131n\u0131z\u0131 nas\u0131l daha verimli hale getirebilece\u011finizi ad\u0131m ad\u0131m \u00f6rneklerle g\u00f6sterece\u011fiz. Her bir b\u00f6l\u00fcm, konuya s\u0131f\u0131rdan ba\u015flayan birinin bile kolayca anlayabilece\u011fi, ancak deneyimli kullan\u0131c\u0131lar i\u00e7in de de\u011ferli ipu\u00e7lar\u0131 sunacak \u015fekilde tasarlanm\u0131\u015ft\u0131r. Ger\u00e7ek d\u00fcnya senaryolar\u0131yla desteklenen vaka analizleri ve pratik kod \u00f6rnekleri sayesinde, bu bilgileri kendi projelerinizde hemen uygulamaya ba\u015flayabileceksiniz. Amac\u0131m\u0131z, sadece teorik bilgi vermek de\u011fil, ayn\u0131 zamanda size veritaban\u0131 performans sorunlar\u0131n\u0131 \u00e7\u00f6zme ve \u00f6nleme konusunda pratik bir yol haritas\u0131 sunmakt\u0131r. Veritabanlar\u0131n\u0131z\u0131n potansiyelini tam olarak ortaya \u00e7\u0131karmaya haz\u0131r olun!<\/p>\n
\u0130ndeksleme, bir veritaban\u0131n\u0131n performans\u0131n\u0131 art\u0131rman\u0131n en temel ve etkili yollar\u0131ndan biridir. En basit ifadeyle, bir indeks, veritaban\u0131 tablolar\u0131ndaki verilerin daha h\u0131zl\u0131 bulunmas\u0131n\u0131 sa\u011flayan \u00f6zel bir arama tablosudur. T\u0131pk\u0131 bir kitab\u0131n arkas\u0131ndaki dizin gibi d\u00fc\u015f\u00fcnebilirsiniz; belirli bir konuyu bulmak i\u00e7in kitab\u0131n t\u00fcm sayfalar\u0131n\u0131 tek tek \u00e7evirmek yerine, dizine bakarak do\u011frudan ilgili sayfaya y\u00f6nlendirilirsiniz. Veritaban\u0131 d\u00fcnyas\u0131nda da indeksler, tam olarak bu g\u00f6revi \u00fcstlenirler: veritaban\u0131n\u0131n disk \u00fczerindeki t\u00fcm sat\u0131rlar\u0131 taramak yerine, do\u011frudan aranan verinin bulundu\u011fu konuma i\u015faret ederler. Bu sayede, \u00f6zellikle b\u00fcy\u00fck veri k\u00fcmelerinde, sorgu s\u00fcreleri dramatik bir \u015fekilde k\u0131sal\u0131r.<\/p>\n
Peki, indeksler tam olarak nas\u0131l \u00e7al\u0131\u015f\u0131r? Bir indeks olu\u015fturdu\u011funuzda, veritaban\u0131 y\u00f6netim sistemi (DBMS), belirtti\u011finiz s\u00fctun veya s\u00fctunlar \u00fczerindeki de\u011ferleri belirli bir yap\u0131da (genellikle B-Tree veya B+Tree) depolar. Bu yap\u0131, verilerin s\u0131ral\u0131 bir \u015fekilde tutulmas\u0131n\u0131 sa\u011flar ve arama i\u015flemlerini logaritmik zamanda ger\u00e7ekle\u015ftirmeye olanak tan\u0131r. Yani, 1 milyon sat\u0131rl\u0131k bir tabloda bir de\u011feri aramak, 100 sat\u0131rl\u0131k bir tabloda aramak kadar h\u0131zl\u0131 olmasa da, indeks olmadan t\u00fcm tabloyu taramaktan \u00e7ok daha h\u0131zl\u0131d\u0131r. \u0130ndeksler genellikle veri ile birlikte veya veriden ayr\u0131 olarak saklanabilir; bu da “k\u00fcmelenmi\u015f” (clustered) ve “k\u00fcmelenmemi\u015f” (non-clustered) indeks kavramlar\u0131n\u0131 ortaya \u00e7\u0131kar\u0131r.<\/p>\n
MusteriID<\/code> \u00fczerine k\u00fcmelenmi\u015f bir indeks olu\u015fturursan\u0131z, m\u00fc\u015fterilerin diskte MusteriID<\/code>‘ye g\u00f6re s\u0131ral\u0131 oldu\u011funu varsayabiliriz. Bu, genellikle anahtar (primary key) s\u00fctunlar \u00fczerinde olu\u015fturulur ve RANGE<\/code> sorgular\u0131 i\u00e7in inan\u0131lmaz derecede etkilidir.<\/li>\n- K\u00fcmelenmemi\u015f \u0130ndeks (Non-Clustered Index):<\/strong> Bir tabloda birden fazla k\u00fcmelenmemi\u015f indeks olabilir. Bu indeksler, verilerin fiziksel s\u0131ralamas\u0131n\u0131 de\u011fi\u015ftirmezler. Bunun yerine, orijinal veriye i\u015faret eden ayr\u0131 bir yap\u0131 olu\u015ftururlar. T\u0131pk\u0131 bir kitab\u0131n sonundaki birden fazla dizin gibi (yazar dizini, konu dizini). K\u00fcmelenmemi\u015f indeksler, belirli s\u00fctunlar \u00fczerinde
WHERE<\/code> ko\u015fullar\u0131nda s\u0131k\u00e7a kullan\u0131lan veya ORDER BY<\/code> clause’lar\u0131nda yer alan s\u00fctunlar i\u00e7in idealdir.<\/li>\n- Bitmap \u0130ndeksler:<\/strong> \u00d6zellikle d\u00fc\u015f\u00fck kardinaliteli (yani az say\u0131da benzersiz de\u011fere sahip) s\u00fctunlar i\u00e7in uygundur, \u00f6rne\u011fin “Cinsiyet” (Kad\u0131n\/Erkek) veya “Medeni Durum”. B-Tree indekslerden farkl\u0131 olarak, her bir de\u011fer i\u00e7in bit dizileri kullan\u0131rlar ve bu da belirli t\u00fcrdeki sorgular i\u00e7in alan verimlili\u011fi ve h\u0131z sa\u011flayabilir.<\/li>\n<\/ul>\n
\u0130ndeks olu\u015fturman\u0131n bir maliyeti de vard\u0131r. \u0130ndeksler ek depolama alan\u0131 kaplar ve tablodaki veri ekleme (INSERT), g\u00fcncelleme (UPDATE) veya silme (DELETE) i\u015flemleri s\u0131ras\u0131nda indekslerin de g\u00fcncellenmesi gerekti\u011fi i\u00e7in bu i\u015flemlerin performans\u0131n\u0131 bir miktar d\u00fc\u015f\u00fcrebilir. Bu nedenle, hangi s\u00fctunlara indeks uygulanaca\u011f\u0131n\u0131 dikkatlice se\u00e7mek \u00e7ok \u00f6nemlidir. Genellikle, s\u0131k\u00e7a sorgulanan, birle\u015ftirme (JOIN) ko\u015fullar\u0131nda kullan\u0131lan veya s\u0131ralama (ORDER BY) i\u00e7in kullan\u0131lan s\u00fctunlar indeksleme i\u00e7in iyi adaylard\u0131r.<\/p>\n
\n Uzman \u0130pucu: \u00c7ok fazla indeks, sorgu performans\u0131n\u0131 art\u0131rmak yerine tam tersi etki yaratabilir. \u00d6zellikle yazma yo\u011fun sistemlerde, yaln\u0131zca en kritik sorgu senaryolar\u0131n\u0131 destekleyecek indeksleri se\u00e7mek, dengeli bir performans sa\u011flaman\u0131n anahtar\u0131d\u0131r. \u0130ndekslemeyi “olmazsa olmaz” de\u011fil, “gerekti\u011finde kullan\u0131lan g\u00fc\u00e7l\u00fc bir ara\u00e7” olarak g\u00f6rmelisiniz.\n <\/div>\n\u015eimdi bir \u00f6rnekle indekslemenin g\u00fcc\u00fcn\u00fc g\u00f6relim. Diyelim ki b\u00fcy\u00fck bir Kullanicilar<\/code> tablonuz var ve s\u00fcrekli olarak kullan\u0131c\u0131 ad\u0131na g\u00f6re arama yap\u0131yorsunuz:<\/p>\n\n-- \u0130ndekssiz bir tablo \u00fczerinde yava\u015f bir sorgu \u00f6rne\u011fi\nSELECT * FROM Kullanicilar WHERE Ad = 'Mehmet';\n <\/pre>\n<\/code><\/p>\n
Bu sorgu, Kullanicilar<\/code> tablosundaki her sat\u0131r\u0131 tek tek taramak zorunda kalacakt\u0131r ki bu da \u00e7ok yava\u015ft\u0131r. \u015eimdi, Ad<\/code> s\u00fctunu \u00fczerinde bir indeks olu\u015ftural\u0131m:<\/p>\n\n-- Ad s\u00fctunu \u00fczerinde k\u00fcmelenmemi\u015f bir indeks olu\u015fturma\nCREATE INDEX idx_kullanici_ad ON Kullanicilar (Ad);\n <\/pre>\n<\/code><\/p>\n
Bu indeks olu\u015fturulduktan sonra, ayn\u0131 sorguyu tekrar \u00e7al\u0131\u015ft\u0131rd\u0131\u011f\u0131n\u0131zda, veritaban\u0131 art\u0131k t\u00fcm tabloyu taramak yerine, do\u011frudan idx_kullanici_ad<\/code> indeksini kullanarak 'Mehmet' adl\u0131 kullan\u0131c\u0131lar\u0131 \u00e7ok daha h\u0131zl\u0131 bulacakt\u0131r. \u0130\u015fte indekslemenin temel g\u00fcc\u00fc budur; arama i\u015flemini bir veri y\u0131\u011f\u0131n\u0131 i\u00e7inde i\u011fne aramak yerine, organize bir katalogda ilgili maddeyi bulmaya benzetir.<\/p>\nHashing: Veri Eri\u015fimini \u015eim\u015fek H\u0131z\u0131na \u00c7\u0131karan Mekanizma Nedir?<\/h2>\n
\u0130ndeksleme, veriye h\u0131zl\u0131 eri\u015fim i\u00e7in harika bir y\u00f6ntem olsa da, belirli senaryolarda daha da h\u0131zl\u0131 bir alternatife ihtiya\u00e7 duyabiliriz: Hashing. Hashing, \u00f6zellikle belirli bir de\u011feri \"do\u011frudan\" araman\u0131z gerekti\u011finde devreye girer. Bu mekanizma, bir anahtar de\u011feri al\u0131p, onu verinin depoland\u0131\u011f\u0131 haf\u0131zadaki veya diskteki belirli bir adrese e\u015fleyen bir \"hash fonksiyonu\" kullanarak \u00e7al\u0131\u015f\u0131r. Sonu\u00e7 olarak, veriye eri\u015fim genellikle sabit zaman karma\u015f\u0131kl\u0131\u011f\u0131na (O(1)) yakla\u015f\u0131r, yani veritaban\u0131 boyutu ne olursa olsun arama s\u00fcresi neredeyse sabittir.<\/p>\n
Hashing'in temel \u00e7al\u0131\u015fma prensibi olduk\u00e7a basittir ancak g\u00fc\u00e7l\u00fcd\u00fcr. Bir hash tablosu (veya hash map), anahtar-de\u011fer \u00e7iftlerini saklayan bir veri yap\u0131s\u0131d\u0131r. Bir anahtar verildi\u011finde, hash fonksiyonu bu anahtar\u0131 alarak bir \"hash de\u011feri\" veya \"hash kodu\" \u00fcretir. Bu hash de\u011feri daha sonra verinin depoland\u0131\u011f\u0131 bir \"kova\" (bucket) veya \"yuva\" (slot) adresine d\u00f6n\u00fc\u015ft\u00fcr\u00fcl\u00fcr. E\u011fer bu adreste veri varsa, do\u011frudan eri\u015fim sa\u011flan\u0131r. Bu, \u00f6zellikle tam e\u015fle\u015fme (equality lookup) sorgular\u0131 i\u00e7in indekslerden bile daha h\u0131zl\u0131 olabilir.<\/p>\n
Peki, hashing tam olarak ne zaman kullan\u0131l\u0131r? Genellikle, veritaban\u0131 y\u00f6netim sistemleri (DBMS) dahili olarak hashing'i farkl\u0131 ama\u00e7lar i\u00e7in kullan\u0131r. \u00d6rne\u011fin:<\/p>\n
\n- Anahtar Aramalar\u0131:<\/strong> Benzersiz anahtarlar (unique keys) veya birincil anahtarlar (primary keys) \u00fczerinde h\u0131zl\u0131 tam e\u015fle\u015fme aramalar\u0131 gerekti\u011finde hashing m\u00fckemmeldir. Bir \u00fcr\u00fcn koduyla \u00fcr\u00fcn bilgisini veya bir \u00f6\u011frenci numaras\u0131yla \u00f6\u011frenci kayd\u0131n\u0131 aramak gibi.<\/li>\n
- Bellek \u0130\u00e7i \u00d6nbellekler (In-Memory Caches):<\/strong> S\u0131k eri\u015filen verileri h\u0131zl\u0131ca getirmek i\u00e7in bellek i\u00e7i hash tablolar\u0131 kullan\u0131l\u0131r.<\/li>\n
- Birle\u015fim (JOIN) \u0130\u015flemleri:<\/strong> Baz\u0131 veritabanlar\u0131, b\u00fcy\u00fck tablolar aras\u0131nda h\u0131zl\u0131 birle\u015fim i\u015flemleri yapmak i\u00e7in \"hash join\" algoritmalar\u0131n\u0131 kullan\u0131r.<\/li>\n
- Benzersiz K\u0131s\u0131tlamalar (Unique Constraints):<\/strong> Bir s\u00fctundaki de\u011ferlerin benzersizli\u011fini sa\u011flamak i\u00e7in dahili olarak hash yap\u0131lar\u0131 kullan\u0131labilir.<\/li>\n<\/ul>\n
Hashing'in de kendine \u00f6zg\u00fc zorluklar\u0131 vard\u0131r. En \u00f6nemlisi \"\u00e7arp\u0131\u015fma\" (collision) durumudur. Farkl\u0131 anahtarlar\u0131n ayn\u0131 hash de\u011ferini \u00fcretmesi durumunda \u00e7arp\u0131\u015fma meydana gelir. DBMS'ler bu \u00e7arp\u0131\u015fmalar\u0131 \u00e7e\u015fitli tekniklerle (\u00f6rne\u011fin, zincirleme veya a\u00e7\u0131k adresleme) ele al\u0131r. \u0130yi tasarlanm\u0131\u015f bir hash fonksiyonu, \u00e7arp\u0131\u015fmalar\u0131 minimize eder ve verilerin kovalara dengeli bir \u015fekilde da\u011f\u0131lmas\u0131n\u0131 sa\u011flar. Ayr\u0131ca, hashing'in bir dezavantaj\u0131, verilerin s\u0131ral\u0131 olarak depolanmamas\u0131d\u0131r. Bu nedenle, RANGE<\/code> sorgular\u0131 (\u00f6rne\u011fin, \"2023-01-01 ile 2023-03-31 aras\u0131ndaki sipari\u015fleri bul\") veya s\u0131ralama (ORDER BY<\/code>) i\u015flemleri i\u00e7in hashing uygun de\u011fildir; bu t\u00fcr durumlarda B-Tree indeksler daha etkilidir.<\/p>\n\n Uzman \u0130pucu: Hashing, veriyi disk \u00fczerinde organize etmekten \u00e7ok, genellikle veritaban\u0131 sistemlerinin dahili olarak sorgular\u0131 h\u0131zland\u0131rmak veya ge\u00e7ici tablolar olu\u015fturmak i\u00e7in kulland\u0131\u011f\u0131 bir y\u00f6ntemdir. D\u0131\u015far\u0131dan do\u011frudan \"hash indeksi\" olu\u015fturma yetene\u011fi her DBMS'de bulunmayabilir veya belirli k\u0131s\u0131tlamalara sahip olabilir. Ancak, \u00f6zellikle bellekte h\u0131zl\u0131 aramalar ve birle\u015fimler i\u00e7in hashing'in temel prensibini anlamak, veritaban\u0131 performans\u0131n\u0131 d\u00fc\u015f\u00fcn\u00fcrken \u00f6nemlidir.\n <\/div>\n\u00d6rne\u011fin, bir veritaban\u0131 y\u00f6netim sistemi, birincil anahtarlar \u00fczerinde h\u0131zl\u0131 birle\u015fimler yaparken a\u015fa\u011f\u0131daki gibi bir i\u00e7 mekanizma kullanabilir:<\/p>\n
\n-- Kaba bir \u00f6rnek: Birincil anahtardan hash de\u011feri t\u00fcretme\n-- Ger\u00e7ek DBMS'ler \u00e7ok daha karma\u015f\u0131k algoritmalar kullan\u0131r.\nFUNCTION CalculateHash(PrimaryKey) RETURNS INTEGER:\n RETURN PrimaryKey MOD NumberOfBuckets;\n\n-- Veri Ekleme Mant\u0131\u011f\u0131 (Kavramsal)\nFUNCTION InsertData(PrimaryKey, Value):\n bucket_index = CalculateHash(PrimaryKey);\n Store Value at bucket_index with PrimaryKey;\n\n-- Veri Arama Mant\u0131\u011f\u0131 (Kavramsal)\nFUNCTION RetrieveData(PrimaryKey):\n bucket_index = CalculateHash(PrimaryKey);\n Search for PrimaryKey in bucket_index;\n RETURN Value if found;\n <\/pre>\n<\/code><\/p>\n
Bu konsept, MusteriID<\/code> gibi bir birincil anahtar \u00fczerinde, m\u00fc\u015fteri bilgilerine \u015fim\u015fek h\u0131z\u0131nda eri\u015fim sa\u011flaman\u0131n temelini olu\u015fturur. E\u011fer verileriniz \u00e7o\u011funlukla tam e\u015fle\u015fme aramalar\u0131 gerektiriyorsa ve aral\u0131k sorgular\u0131na ihtiyac\u0131n\u0131z yoksa, hashing'in sundu\u011fu performans avantajlar\u0131 g\u00f6z ard\u0131 edilemez. \u0130ndeksleme ile birlikte hashing'i do\u011fru yerlerde kullanmak, veritaban\u0131 performans\u0131n\u0131z\u0131 bir sonraki seviyeye ta\u015f\u0131yabilir.<\/p>\nSorgu Optimizasyonu Neden Hayati \u00d6nem Ta\u015f\u0131r ve Nas\u0131l Yap\u0131l\u0131r?<\/h2>\n
\u0130ndeksleme ve hashing teknikleri, veritaban\u0131n\u0131n fiziksel yap\u0131s\u0131n\u0131 iyile\u015ftirerek veri eri\u015fimini h\u0131zland\u0131rsa da, bu avantajlardan tam olarak yararlanabilmek i\u00e7in sorgular\u0131m\u0131z\u0131n da \"ak\u0131ll\u0131ca\" yaz\u0131lmas\u0131 gerekir. \u0130\u015fte tam da burada sorgu optimizasyonu devreye girer. Sorgu optimizasyonu, bir veritaban\u0131 y\u00f6netim sisteminin (DBMS) belirli bir SQL sorgusunu m\u00fcmk\u00fcn olan en verimli \u015fekilde y\u00fcr\u00fctmek i\u00e7in kulland\u0131\u011f\u0131 veya bir geli\u015ftiricinin sorgular\u0131 daha performansl\u0131 hale getirmek i\u00e7in uygulad\u0131\u011f\u0131 bir dizi teknik ve stratejiyi ifade eder. K\u0131sacas\u0131, ayn\u0131 sonucu veren ancak farkl\u0131 y\u00fcr\u00fctme maliyetlerine sahip olabilecek alternatif sorgular aras\u0131ndan en h\u0131zl\u0131 ve en az kaynak t\u00fcketen yolu bulma sanat\u0131d\u0131r.<\/p>\n
Bir sorgu veritaban\u0131na g\u00f6nderildi\u011finde, DBMS i\u00e7inde bulunan \"sorgu iyile\u015ftirici\" (query optimizer) ad\u0131 verilen bir bile\u015fen devreye girer. Bu iyile\u015ftirici, sorguyu analiz eder, veritaban\u0131 \u015femas\u0131 ve mevcut indeksler hakk\u0131nda bilgi toplar, istatistikleri kullanarak olas\u0131 y\u00fcr\u00fctme planlar\u0131n\u0131 (execution plans) de\u011ferlendirir ve sonunda en maliyet-etkin plan\u0131 se\u00e7er. Bu s\u00fcre\u00e7 genellikle \u015fu ad\u0131mlar\u0131 i\u00e7erir:<\/p>\n
\n- Sorgu Ayr\u0131\u015ft\u0131rma (Parsing):<\/strong> SQL sorgusu, s\u00f6zdizimi ve semantik olarak kontrol edilir.<\/li>\n
- Sorgu Optimizasyonu (Optimization):<\/strong> \u00c7e\u015fitli algoritmalar ve istatistikler kullan\u0131larak en iyi y\u00fcr\u00fctme plan\u0131 belirlenir. Bu, indeks kullan\u0131m\u0131, birle\u015fim s\u0131ralamas\u0131, filtre uygulama s\u0131ras\u0131 gibi kararlar\u0131 i\u00e7erir.<\/li>\n
- Sorgu Y\u00fcr\u00fctme (Execution):<\/strong> Se\u00e7ilen plana g\u00f6re sorgu \u00e7al\u0131\u015ft\u0131r\u0131l\u0131r ve sonu\u00e7lar d\u00f6nd\u00fcr\u00fcl\u00fcr.<\/li>\n<\/ol>\n
Sorgu optimizasyonu sadece DBMS'nin g\u00f6revi de\u011fildir; geli\u015ftiricilerin ve veritaban\u0131 y\u00f6neticilerinin de bu s\u00fcre\u00e7te aktif rol almas\u0131 gerekir. \u0130\u015fte sorgular\u0131n\u0131z\u0131 optimize etmek i\u00e7in uygulayabilece\u011finiz baz\u0131 pratik ipu\u00e7lar\u0131 ve teknikler:<\/p>\n
\nEXPLAIN<\/code> veya EXPLAIN ANALYZE<\/code> Kullan\u0131n:<\/strong> Bu komutlar, bir sorgunun nas\u0131l y\u00fcr\u00fct\u00fclece\u011fini g\u00f6steren y\u00fcr\u00fctme plan\u0131n\u0131 (execution plan) g\u00f6rmenizi sa\u011flar. Hangi indekslerin kullan\u0131ld\u0131\u011f\u0131n\u0131, hangi tablolar\u0131n tam tarama (full table scan) yap\u0131ld\u0131\u011f\u0131n\u0131, birle\u015fimlerin nas\u0131l ger\u00e7ekle\u015ftirildi\u011fini \u00f6\u011frenerek darbo\u011fazlar\u0131 tespit edebilirsiniz.<\/li>\n- Do\u011fru \u0130ndeksleri Se\u00e7in:<\/strong> \u00d6nceki b\u00f6l\u00fcmde bahsetti\u011fimiz gibi,
WHERE<\/code> ko\u015fullar\u0131nda, JOIN<\/code> ko\u015fullar\u0131nda ve ORDER BY<\/code> veya GROUP BY<\/code> clause'lar\u0131nda s\u0131k\u00e7a kullan\u0131lan s\u00fctunlara indeks eklemek sorgu performans\u0131n\u0131 b\u00fcy\u00fck \u00f6l\u00e7\u00fcde art\u0131r\u0131r. Ancak, gereksiz indekslerden ka\u00e7\u0131n\u0131n.<\/li>\n- Sorgular\u0131 Daha Spesifik Hale Getirin:<\/strong> M\u00fcmk\u00fcn oldu\u011funca
SELECT *<\/code> yerine sadece ihtiyac\u0131n\u0131z olan s\u00fctunlar\u0131 se\u00e7in. WHERE<\/code> ko\u015fullar\u0131n\u0131z\u0131 daraltarak veritaban\u0131n\u0131n daha az sat\u0131r\u0131 i\u015flemesini sa\u011flay\u0131n.<\/li>\nJOIN<\/code> T\u00fcrlerini Do\u011fru Kullan\u0131n:<\/strong> INNER JOIN<\/code>, LEFT JOIN<\/code> gibi birle\u015fim t\u00fcrlerini ve bunlar\u0131n performans \u00fczerindeki etkilerini anlay\u0131n. B\u00fcy\u00fck tablolar\u0131 birle\u015ftirirken, veritaban\u0131n\u0131n istatistiklerinin g\u00fcncel oldu\u011fundan emin olun.<\/li>\n- Alt Sorgular\u0131 (Subqueries) G\u00f6zden Ge\u00e7irin:<\/strong> Baz\u0131 durumlarda alt sorgular, daha verimli bir
JOIN<\/code> veya ge\u00e7ici tablo (CTE - Common Table Expression) ile yeniden yaz\u0131labilir.<\/li>\nLIKE<\/code> Operat\u00f6r\u00fcn\u00fc Ak\u0131ll\u0131ca Kullan\u0131n:<\/strong> LIKE '%de\u011fer%'<\/code> gibi ifadeler genellikle indeks kullanamaz (\u00e7\u00fcnk\u00fc arama kal\u0131b\u0131 bir joker karakterle ba\u015fl\u0131yor). M\u00fcmk\u00fcnse LIKE 'de\u011fer%'<\/code> veya tam e\u015fle\u015fme kullanmaya \u00e7al\u0131\u015f\u0131n. Tam metin arama (full-text search) \u00e7\u00f6z\u00fcmlerini de de\u011ferlendirebilirsiniz.<\/li>\n- Veri \u0130statistiklerini G\u00fcncel Tutun:<\/strong> DBMS'nin sorgu planlay\u0131c\u0131s\u0131, tablolardaki veri da\u011f\u0131l\u0131m\u0131 hakk\u0131ndaki istatistikleri kullanarak en iyi plan\u0131 belirler. Bu istatistikler zamanla g\u00fcncel kalmazsa, yanl\u0131\u015f y\u00fcr\u00fctme planlar\u0131 se\u00e7ilebilir. Periyodik olarak
ANALYZE TABLE<\/code> (veya e\u015fde\u011fer) komutlar\u0131n\u0131 \u00e7al\u0131\u015ft\u0131rmak \u00f6nemlidir.<\/li>\nNOT IN<\/code> yerine NOT EXISTS<\/code> veya LEFT JOIN ... WHERE ... IS NULL<\/code> kullan\u0131n:<\/strong> Baz\u0131 durumlarda NOT IN<\/code> performans\u0131 d\u00fc\u015f\u00fcrebilir, bu alternatifler daha verimli olabilir.<\/li>\n<\/ul>\n\n Uzman \u0130pucu: Sorgu optimizasyonunda alt\u0131n kural, problemin nerede oldu\u011funu anlamakt\u0131r. Bunun i\u00e7in en g\u00fc\u00e7l\u00fc ara\u00e7 EXPLAIN ANALYZE<\/code> (PostgreSQL) veya EXPLAIN<\/code> (MySQL\/SQL Server) \u00e7\u0131kt\u0131s\u0131d\u0131r. Bu \u00e7\u0131kt\u0131y\u0131 okumay\u0131 \u00f6\u011frenmek, veritaban\u0131 performans\u0131n\u0131z\u0131 iyile\u015ftirme yolculu\u011funuzda size rehberlik edecektir. Hangi ad\u0131mlar\u0131n en \u00e7ok zaman ald\u0131\u011f\u0131n\u0131, hangi filtrelerin indeks kulland\u0131\u011f\u0131n\u0131 veya kullanmad\u0131\u011f\u0131n\u0131 bu \u00e7\u0131kt\u0131dan net bir \u015fekilde g\u00f6rebilirsiniz.\n <\/div>\n\u015eimdi bir \u00f6rnekle sorgu optimizasyonunun etkisini g\u00f6relim. Diyelim ki iki b\u00fcy\u00fck tablonuz var: Musteriler<\/code> ve Siparisler<\/code>. S\u0131k s\u0131k belirli bir tarih aral\u0131\u011f\u0131ndaki sipari\u015flerle birlikte m\u00fc\u015fteri bilgilerini \u00e7ekmeniz gerekiyor.<\/p>\n\n-- Potansiyel olarak yava\u015f bir sorgu \u00f6rne\u011fi (Implicit JOIN ve indeks eksikli\u011fi)\nSELECT M.Ad, M.Soyad, S.SiparisTarihi, S.ToplamTutar\nFROM Musteriler M, Siparisler S\nWHERE M.MusteriID = S.MusteriID\nAND S.SiparisTarihi BETWEEN '2023-01-01' AND '2023-03-31';\n\n-- Bu sorguyu EXPLAIN ile analiz edelim\nEXPLAIN SELECT M.Ad, M.Soyad, S.SiparisTarihi, S.ToplamTutar\nFROM Musteriler M, Siparisler S\nWHERE M.MusteriID = S.MusteriID\nAND S.SiparisTarihi BETWEEN '2023-01-01' AND '2023-03-31';\n <\/pre>\n<\/code><\/p>\n
E\u011fer Siparisler<\/code> tablosunda SiparisTarihi<\/code> \u00fczerinde bir indeks yoksa veya MusteriID<\/code> \u00fczerinde indeksler verimsizse, yukar\u0131daki sorgu yava\u015f \u00e7al\u0131\u015fabilir. Optimizasyon i\u00e7in \u015funlar\u0131 yapabiliriz:<\/p>\n\nSiparisler.SiparisTarihi<\/code> s\u00fctununa indeks ekleyin.<\/li>\nMusteriler.MusteriID<\/code> ve Siparisler.MusteriID<\/code> s\u00fctunlar\u0131na indeks ekleyin (e\u011fer yoksa veya yetersizse).<\/li>\n- A\u00e7\u0131k
INNER JOIN<\/code> s\u00f6zdizimini kullan\u0131n (DBMS genellikle ayn\u0131 plan\u0131 \u00fcretse de, okunabilirli\u011fi art\u0131r\u0131r).<\/li>\n<\/ul>\n\n-- Gerekli indeksleri olu\u015fturma (varsayal\u0131m hen\u00fcz yoklar)\nCREATE INDEX idx_siparis_tarihi ON Siparisler (SiparisTarihi);\nCREATE INDEX idx_musteri_id ON Musteriler (MusteriID); -- Genellikle Primary Key oldu\u011fu i\u00e7in otomatik olu\u015fur\nCREATE INDEX idx_siparis_musteri_id ON Siparisler (MusteriID);\n\n-- Optimize edilmi\u015f sorgu \u00f6rne\u011fi\nSELECT M.Ad, M.Soyad, S.SiparisTarihi, S.ToplamTutar\nFROM Musteriler M\nINNER JOIN Siparisler S ON M.MusteriID = S.MusteriID\nWHERE S.SiparisTarihi BETWEEN '2023-01-01' AND '2023-03-31';\n <\/pre>\n<\/code><\/p>\n
Bu optimize edilmi\u015f yakla\u015f\u0131m, veritaban\u0131n\u0131n SiparisTarihi<\/code> indeksi sayesinde sadece ilgili tarih aral\u0131\u011f\u0131ndaki sipari\u015fleri h\u0131zl\u0131ca bulmas\u0131n\u0131 ve ard\u0131ndan MusteriID<\/code> indekslerini kullanarak ilgili m\u00fc\u015fteri bilgilerini verimli bir \u015fekilde birle\u015ftirmesini sa\u011flar. Sorgu optimizasyonu, veritaban\u0131 performans\u0131n\u0131n s\u00fcrekli bir yolculu\u011fudur ve her bir sorguyu en iyi hale getirme \u00e7abas\u0131, genel sistem performans\u0131na \u00f6nemli katk\u0131lar sa\u011flar.<\/p>\nGeli\u015fmi\u015f Optimizasyon Teknikleri: Daha Derinlere \u0130nmek \u0130ster Misiniz?<\/h2>\n
Temel indeksleme, hashing prensipleri ve sorgu optimizasyon stratejileri, veritaban\u0131 performans\u0131n\u0131 \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131rman\u0131n ilk ad\u0131mlar\u0131d\u0131r. Ancak, \u00e7ok b\u00fcy\u00fck veri k\u00fcmeleriyle \u00e7al\u0131\u015f\u0131rken, karma\u015f\u0131k sistemlerde veya belirli performans darbo\u011fazlar\u0131n\u0131 a\u015fmak i\u00e7in daha ileri d\u00fczey tekniklere ihtiya\u00e7 duyulabilir. Bu b\u00f6l\u00fcm, deneyimli kullan\u0131c\u0131lar ve daha derinlemesine optimizasyon arayanlar i\u00e7in tasarlanm\u0131\u015ft\u0131r.<\/p>\n
Materialized View'lar: Karma\u015f\u0131k Sorgular\u0131 \u00d6nceden Haz\u0131rlama<\/h3>\n
Baz\u0131 raporlama veya analitik sorgular o kadar karma\u015f\u0131kt\u0131r ki, her \u00e7al\u0131\u015ft\u0131r\u0131ld\u0131\u011f\u0131nda milyonlarca sat\u0131r\u0131 i\u015flemek zorunda kalabilir. Bu t\u00fcr sorgular, kullan\u0131c\u0131lar\u0131n bekleyemeyece\u011fi kadar uzun s\u00fcrebilir. Materialized View'lar (MV), bu sorunu \u00e7\u00f6zmek i\u00e7in harika bir yakla\u015f\u0131md\u0131r. Geleneksel view'lardan farkl\u0131 olarak, MV'ler sorgunun sonucunu \u00f6nceden hesaplar ve fiziksel olarak diskte bir tablo gibi saklar. B\u00f6ylece, kullan\u0131c\u0131 MV'yi sorgulad\u0131\u011f\u0131nda, veritaban\u0131 karma\u015f\u0131k sorguyu yeniden \u00e7al\u0131\u015ft\u0131rmak yerine \u00f6nceden hesaplanm\u0131\u015f sonu\u00e7lar\u0131 hemen d\u00f6nd\u00fcr\u00fcr. MV'ler, belirli aral\u0131klarla (\u00f6rne\u011fin gece yar\u0131s\u0131 veya her saat ba\u015f\u0131) yenilenmelidir ki veriler g\u00fcncel kals\u0131n. Bu, okuma yo\u011funlu\u011fu y\u00fcksek, ancak veri g\u00fcncelli\u011finin anl\u0131k olmad\u0131\u011f\u0131 senaryolar i\u00e7in idealdir.<\/p>\n
\n-- \u00d6rnek Materialized View olu\u015fturma\nCREATE MATERIALIZED VIEW AylikSatisRaporu AS\nSELECT\n DATE_TRUNC('month', S.SiparisTarihi) AS Ay,\n SUM(S.ToplamTutar) AS ToplamSatis,\n COUNT(DISTINCT S.MusteriID) AS BenzersizMusteriSayisi\nFROM Siparisler S\nGROUP BY Ay\nORDER BY Ay;\n\n-- Materialized View'i yenileme\nREFRESH MATERIALIZED VIEW AylikSatisRaporu;\n <\/pre>\n<\/code><\/p>\n
Veritaban\u0131 B\u00f6l\u00fcmleme (Partitioning): B\u00fcy\u00fck Tablolar\u0131 Y\u00f6netilebilir Par\u00e7alara Ay\u0131rma<\/h3>\n
\u00c7ok b\u00fcy\u00fck tablolar (terabaytlarca veri i\u00e7erenler), performans sorunlar\u0131na yol a\u00e7abilir. Bu tablolar \u00fczerinde indeksleme bile zamanla yava\u015flayabilir. B\u00f6l\u00fcmleme, mant\u0131ksal olarak tek bir tablo gibi g\u00f6r\u00fcnen veriyi, fiziksel olarak daha k\u00fc\u00e7\u00fck ve daha y\u00f6netilebilir par\u00e7alara (b\u00f6l\u00fcmlere) ay\u0131rma tekni\u011fidir. Bu, sorgular\u0131n sadece ilgili b\u00f6l\u00fcmleri taramas\u0131n\u0131 sa\u011flayarak performans\u0131 art\u0131r\u0131r. Ayr\u0131ca, eski verileri ar\u015fivlemek veya silmek gibi bak\u0131m i\u015flemlerini de kolayla\u015ft\u0131r\u0131r.<\/p>\n
\n- Range Partitioning (Aral\u0131k B\u00f6l\u00fcmleme):<\/strong> Belirli bir s\u00fctundaki de\u011fer aral\u0131\u011f\u0131na g\u00f6re b\u00f6l\u00fcmleme (\u00f6rne\u011fin, tarihe g\u00f6re y\u0131ll\u0131k b\u00f6l\u00fcmler).<\/li>\n
- List Partitioning (Liste B\u00f6l\u00fcmleme):<\/strong> Belirli bir s\u00fctundaki de\u011fer listesine g\u00f6re b\u00f6l\u00fcmleme (\u00f6rne\u011fin, \u00fclkeye g\u00f6re b\u00f6l\u00fcmler).<\/li>\n
- Hash Partitioning (Hash B\u00f6l\u00fcmleme):<\/strong> Belirli bir s\u00fctundaki de\u011ferin hash'ine g\u00f6re b\u00f6l\u00fcmleme, veriyi e\u015fit olarak da\u011f\u0131tmak i\u00e7in kullan\u0131l\u0131r.<\/li>\n<\/ul>\n\n Uzman \u0130pucu: B\u00f6l\u00fcmleme, genellikle b\u00fcy\u00fck veri k\u00fcmeleri ve y\u00fcksek trafikli sistemler i\u00e7in uygun bir stratejidir. K\u00fc\u00e7\u00fck tablolar i\u00e7in b\u00f6l\u00fcmleme yapmak, y\u00f6netim y\u00fck\u00fcn\u00fc art\u0131rabilir ve performansa belirgin bir fayda sa\u011flamayabilir. B\u00f6l\u00fcmleme stratejinizi, veri eri\u015fim desenlerinize g\u00f6re dikkatlice planlamal\u0131s\u0131n\u0131z.\n <\/div>\n
Denormalizasyon: Normalizasyonun Tersine \u0130\u015flemi<\/h3>\n
Veritaban\u0131 tasar\u0131m\u0131nda genellikle normalizasyon kurallar\u0131na uyar\u0131z. Bu, veri tekrar\u0131n\u0131 azalt\u0131r ve veri b\u00fct\u00fcnl\u00fc\u011f\u00fcn\u00fc sa\u011flar. Ancak, baz\u0131 durumlarda, a\u015f\u0131r\u0131 normalizasyon (\u00e7ok fazla tablo birle\u015ftirme gerektiren) sorgu performans\u0131n\u0131 olumsuz etkileyebilir. Denormalizasyon, bilerek veri tekrar\u0131na izin vererek veya ili\u015fkili verileri tek bir tabloda birle\u015ftirerek sorgu karma\u015f\u0131kl\u0131\u011f\u0131n\u0131 ve dolay\u0131s\u0131yla y\u00fcr\u00fctme s\u00fcresini azaltma tekni\u011fidir. \u00d6rne\u011fin, bir Siparisler<\/code> tablosuna MusteriAd<\/code> s\u00fctununu ekleyerek, her sipari\u015f detay\u0131n\u0131 sorgularken Musteriler<\/code> tablosuyla JOIN<\/code> yapmaktan kurtulabilirsiniz. Elbette, bu veri tekrar\u0131n\u0131 ve g\u00fcncelleme anormalliklerini y\u00f6netme y\u00fck\u00fcn\u00fc beraberinde getirir.<\/p>\nSorgu \u0130pu\u00e7lar\u0131 (Query Hints): Optimizasyon Kontrol\u00fcn\u00fc Ele Alma<\/h3>\n
Baz\u0131 veritaban\u0131 sistemleri (\u00f6rne\u011fin SQL Server, Oracle), geli\u015ftiricilere sorgu i\u00e7inde \"ipu\u00e7lar\u0131\" (hints) kullanarak sorgu planlay\u0131c\u0131s\u0131na nas\u0131l davranmas\u0131 gerekti\u011fini s\u00f6yleme yetene\u011fi sunar. \u00d6rne\u011fin, belirli bir indeksi kullanmas\u0131n\u0131 veya belirli bir birle\u015fim t\u00fcr\u00fcn\u00fc uygulamas\u0131n\u0131 zorlayabilirsiniz. Ancak, bu ipu\u00e7lar\u0131n\u0131 dikkatli kullanmal\u0131s\u0131n\u0131z. \u0130yile\u015ftiricinin genellikle sizden daha iyi planlar \u00fcretti\u011fi unutulmamal\u0131d\u0131r. Yanl\u0131\u015f kullan\u0131lan bir ipucu, performans\u0131 iyile\u015ftirmek yerine daha da k\u00f6t\u00fcle\u015ftirebilir. Genellikle, sadece iyile\u015ftiricinin s\u00fcrekli olarak suboptimal bir plan se\u00e7ti\u011fi durumlarda ba\u015fvurulur.<\/p>\n
Veritaban\u0131 Ba\u011flant\u0131 Havuzlama (Connection Pooling) ve \u00d6nbellekleme (Caching)<\/h3>\n
Uygulama taraf\u0131nda, veritaban\u0131 ba\u011flant\u0131lar\u0131n\u0131n s\u00fcrekli a\u00e7\u0131l\u0131p kapat\u0131lmas\u0131 kaynak yo\u011fun bir i\u015flemdir. Ba\u011flant\u0131 havuzlama, \u00f6nceden a\u00e7\u0131lm\u0131\u015f ve kullan\u0131ma haz\u0131r veritaban\u0131 ba\u011flant\u0131lar\u0131ndan olu\u015fan bir havuz tutarak bu maliyeti ortadan kald\u0131r\u0131r. Uygulama bir ba\u011flant\u0131ya ihtiya\u00e7 duydu\u011funda, havuzdan bir tane al\u0131r ve i\u015fi bitti\u011finde havuza geri verir. Bu, ba\u011flant\u0131 a\u00e7ma\/kapama overhead'ini ortadan kald\u0131r\u0131r ve performans\u0131 art\u0131r\u0131r. Ayr\u0131ca, s\u0131k eri\u015filen verileri uygulama katman\u0131nda veya \u00f6zel bir \u00f6nbellek katman\u0131nda (\u00f6rne\u011fin Redis, Memcached) \u00f6nbelle\u011fe almak, veritaban\u0131na yap\u0131lan y\u00fck\u00fc \u00f6nemli \u00f6l\u00e7\u00fcde azaltabilir.<\/p>\n
Mobil uyumlu bir web sitesi veya uygulaman\u0131n veritaban\u0131 etkile\u015fimleri i\u00e7in de performans kritik \u00f6neme sahiptir. Kullan\u0131c\u0131lar, mobil cihazlar\u0131nda da h\u0131zl\u0131 yan\u0131t s\u00fcreleri bekler. A\u015fa\u011f\u0131da, mobil uyumlu HTML i\u00e7in basit bir stil \u00f6rne\u011fi yer almaktad\u0131r:<\/p>\n
\n