Veritaban\u0131 sistemleri modern yaz\u0131l\u0131mlar\u0131n belkemi\u011fini olu\u015ftururken, b\u00fcy\u00fck veri setleriyle \u00e7al\u0131\u015f\u0131rken performans sorunlar\u0131 ya\u015famak ka\u00e7\u0131n\u0131lmaz hale gelebilir. Peki, veritaban\u0131n\u0131z neden yava\u015f \u00e7al\u0131\u015f\u0131yor ve bu duruma nas\u0131l m\u00fcdahale edebilirsiniz? Bu rehber, indeksleme, hashing ve sorgu optimizasyonu gibi temel y\u00f6ntemleri ad\u0131m ad\u0131m inceleyerek, veritaban\u0131 performans\u0131n\u0131z\u0131 \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131rman\u0131n yollar\u0131n\u0131 pratik \u00f6rneklerle sunuyor. Hemen \u015fimdi, daha h\u0131zl\u0131 ve verimli veritaban\u0131 i\u015flemlerine y\u00f6nelik stratejileri ke\u015ffedin!<\/p>\n
G\u00fcn\u00fcm\u00fcz\u00fcn dijital d\u00fcnyas\u0131nda, her saniye milyonlarca veri i\u015fleniyor ve depolan\u0131yor. Bir e-ticaret sitesinin \u00fcr\u00fcn kataloglar\u0131n\u0131 listelemesinden, bir bankan\u0131n finansal i\u015flemlerini kaydetmesine kadar, her t\u00fcrl\u00fc uygulaman\u0131n arkas\u0131nda g\u00fc\u00e7l\u00fc bir veritaban\u0131 sistemi yatar. Ancak, veritaban\u0131n\u0131z b\u00fcy\u00fcd\u00fck\u00e7e, i\u015flem y\u00fck\u00fc artt\u0131k\u00e7a veya sorgular karma\u015f\u0131kla\u015ft\u0131k\u00e7a, sistemin yava\u015flamas\u0131 s\u0131k\u00e7a kar\u015f\u0131la\u015f\u0131lan bir problem haline gelir. Bu durum, kullan\u0131c\u0131 deneyimini olumsuz etkilemenin yan\u0131 s\u0131ra, i\u015f s\u00fcre\u00e7lerinde aksakl\u0131klara ve hatta maliyet art\u0131\u015flar\u0131na yol a\u00e7abilir. Veritaban\u0131 performans\u0131n\u0131 optimize etmek, bu nedenle sadece bir teknik gereklilik de\u011fil, ayn\u0131 zamanda i\u015f s\u00fcreklili\u011fi i\u00e7in hayati bir zorunluluktur.<\/p>\n
Peki, bir veritaban\u0131n\u0131n yava\u015f \u00e7al\u0131\u015fmas\u0131n\u0131n temel nedenleri nelerdir? Genellikle bu sorunlar, veriye eri\u015fim y\u00f6ntemlerinin yetersizli\u011fi, sorgular\u0131n verimsiz yaz\u0131lmas\u0131 veya donan\u0131m k\u0131s\u0131tlamalar\u0131 gibi fakt\u00f6rlerden kaynaklan\u0131r. Diske her eri\u015fim, CPU d\u00f6ng\u00fcleri ve a\u011f gecikmeleri, sorgular\u0131n tamamlanma s\u00fcresini do\u011frudan etkiler. Bu nedenle, veriye eri\u015fimi h\u0131zland\u0131rmak, gereksiz disk okumalar\u0131n\u0131 azaltmak ve CPU’nun daha verimli \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flamak, optimizasyon s\u00fcrecinin ana hedefleridir. Bu rehberde, bu hedeflere ula\u015fmak i\u00e7in en g\u00fc\u00e7l\u00fc ara\u00e7lardan baz\u0131lar\u0131n\u0131, yani indeksleme, hashing ve sorgu optimizasyonu tekniklerini detayl\u0131ca inceleyece\u011fiz. Her bir y\u00f6ntemin nas\u0131l \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131, ne zaman kullan\u0131lmas\u0131 gerekti\u011fini ve ger\u00e7ek d\u00fcnya senaryolar\u0131nda nas\u0131l uygulanabilece\u011fini ke\u015ffedeceksiniz. Sonu\u00e7 olarak, bu y\u00f6ntemleri do\u011fru bir \u015fekilde uygulayarak, veritaban\u0131n\u0131z\u0131n tepki s\u00fcresini \u00f6nemli \u00f6l\u00e7\u00fcde d\u00fc\u015f\u00fcrebilir ve genel sistem performans\u0131n\u0131z\u0131 art\u0131rabilirsiniz.<\/p>\n
Veritaban\u0131 performans\u0131n\u0131 anlamak ve iyile\u015ftirmek i\u00e7in \u00f6ncelikle temel kavramlar\u0131 iyi kavramam\u0131z gerekir. \u0130ndeksleme, hashing ve sorgu optimizasyonu, veritaban\u0131 y\u00f6netim sistemlerinin (DBMS) adeta DNA’s\u0131nda bulunan ve veri eri\u015fimini h\u0131zland\u0131rmak i\u00e7in kullan\u0131lan \u00fc\u00e7 kritik bile\u015fendir. Bunlar, veritaban\u0131 i\u00e7indeki verilere ula\u015fma ve onlar\u0131 i\u015fleme \u015feklimizi do\u011frudan etkiler.<\/p>\n
\u0130ndeksleme (Indexing)<\/strong>, temel olarak bir kitab\u0131n i\u00e7indekiler veya dizin k\u0131sm\u0131 gibi d\u00fc\u015f\u00fcn\u00fclebilir. B\u00fcy\u00fck bir kitapta belirli bir konuyu bulmak i\u00e7in sayfalar\u0131 tek tek kar\u0131\u015ft\u0131rmak yerine, dizine bak\u0131p ilgili sayfa numaras\u0131na do\u011frudan gitmeniz zamandan tasarruf etmenizi sa\u011flar. Veritaban\u0131 d\u00fcnyas\u0131nda da indeksler, tablolardaki belirli s\u00fctunlar \u00fczerinde olu\u015fturulur ve sorgular\u0131n ilgili verilere \u00e7ok daha h\u0131zl\u0131 ula\u015fmas\u0131n\u0131 sa\u011flar. Bir indeks, verilerin diskte fiziksel olarak nas\u0131l sakland\u0131\u011f\u0131ndan ba\u011f\u0131ms\u0131z olarak mant\u0131ksal bir s\u0131ralama veya eri\u015fim yolu sunar. Genellikle B-tree veya B+ tree gibi a\u011fa\u00e7 tabanl\u0131 yap\u0131lar kullan\u0131l\u0131r ve bu yap\u0131lar, veritaban\u0131 motorunun milyonlarca sat\u0131r aras\u0131ndan aranan kay\u0131tlara logaritmik zamanda eri\u015fmesine olanak tan\u0131r. \u00d6rne\u011fin, bir kullan\u0131c\u0131 ad\u0131 veya \u00fcr\u00fcn ID’si ile arama yapt\u0131\u011f\u0131n\u0131zda, indeks sayesinde veritaban\u0131 t\u00fcm tabloyu taramak yerine do\u011frudan aranan de\u011fere y\u00f6nlendirilir. Bu sayede disk I\/O i\u015flemleri azal\u0131r ve sorgu s\u00fcresi k\u0131sal\u0131r.<\/p>\n Hashing<\/strong> ise, veriyi belirli bir boyuttaki bir anahtara d\u00f6n\u00fc\u015ft\u00fcren ve bu anahtar\u0131 kullanarak verilere do\u011frudan eri\u015fim sa\u011flayan bir tekniktir. Hash fonksiyonlar\u0131, herhangi bir uzunluktaki girdiyi sabit uzunlukta bir \u00e7\u0131kt\u0131ya (hash de\u011feri veya hash kodu) d\u00f6n\u00fc\u015ft\u00fcr\u00fcr. Bu hash de\u011feri daha sonra verinin depoland\u0131\u011f\u0131 haf\u0131za veya disk adresini belirlemek i\u00e7in kullan\u0131l\u0131r. \u0130ndekslemeden farkl\u0131 olarak, hashing genellikle tam e\u015fle\u015fme sorgular\u0131 i\u00e7in inan\u0131lmaz h\u0131zl\u0131 eri\u015fim sa\u011flar. \u00d6rne\u011fin, bir kullan\u0131c\u0131n\u0131n e-posta adresinden profil bilgilerine an\u0131nda eri\u015fmek istedi\u011finizde hashing \u00e7ok etkili olabilir. Ancak, aral\u0131k sorgular\u0131 (\u00f6rne\u011fin, “fiyat\u0131 100 TL ile 200 TL aras\u0131nda olan \u00fcr\u00fcnleri getir”) hashing ile verimli bir \u015fekilde yap\u0131lamaz, \u00e7\u00fcnk\u00fc hash de\u011ferleri aras\u0131nda mant\u0131ksal bir s\u0131ra yoktur. \u00c7arp\u0131\u015fmalar (farkl\u0131 girdilerin ayn\u0131 hash de\u011ferini \u00fcretmesi) hash sistemlerinde y\u00f6netilmesi gereken \u00f6nemli bir konudur ve bu \u00e7arp\u0131\u015fmalar\u0131n \u00e7\u00f6z\u00fcm\u00fc i\u00e7in \u00e7e\u015fitli algoritmalar kullan\u0131l\u0131r.<\/p>\n Sorgu Optimizasyonu (Query Optimization)<\/strong>, bir SQL sorgusunun veritaban\u0131 motoru taraf\u0131ndan en verimli \u015fekilde nas\u0131l y\u00fcr\u00fct\u00fclece\u011fine karar verme s\u00fcrecidir. Bir SQL sorgusu yazd\u0131\u011f\u0131n\u0131zda, veritaban\u0131 motoru bu sorguyu do\u011frudan \u00e7al\u0131\u015ft\u0131rmaz. Bunun yerine, bir “sorgu planlay\u0131c\u0131” veya “optimiz\u00f6r”, sorgunun farkl\u0131 y\u00fcr\u00fctme planlar\u0131n\u0131 (\u00f6rne\u011fin, hangi indekslerin kullan\u0131laca\u011f\u0131, tablolar\u0131n hangi s\u0131rayla birle\u015ftirilece\u011fi, hangi algoritman\u0131n kullan\u0131laca\u011f\u0131) analiz eder. Ama\u00e7, en az maliyetli (en az disk I\/O, en az CPU kullan\u0131m\u0131) ve dolay\u0131s\u0131yla en h\u0131zl\u0131 plan\u0131 se\u00e7mektir. Bu s\u00fcre\u00e7te, veritaban\u0131 istatistikleri (tablolardaki sat\u0131r say\u0131s\u0131, indekslerin da\u011f\u0131l\u0131m\u0131 vb.) kritik rol oynar. Optimiz\u00f6r, maliyet tabanl\u0131 bir yakla\u015f\u0131mla, t\u00fcm olas\u0131 planlar\u0131 de\u011ferlendirir ve tahminler yaparak en uygun olan\u0131 se\u00e7er. Yanl\u0131\u015f optimize edilmi\u015f bir sorgu, do\u011fru indeksler olsa bile t\u00fcm sistemi yava\u015flatabilir. Bu \u00fc\u00e7 kavram, bir araya geldi\u011finde veritaban\u0131 performans\u0131n\u0131 maksimize etmede birbirini tamamlayan g\u00fc\u00e7l\u00fc ara\u00e7lard\u0131r.<\/p>\n \u0130ndeksleme, bir veritaban\u0131n\u0131n en g\u00fc\u00e7l\u00fc performans art\u0131r\u0131c\u0131 \u00f6zelliklerinden biridir. T\u0131pk\u0131 bir kitab\u0131n i\u00e7indekiler k\u0131sm\u0131 gibi, indeksler de veritaban\u0131 tablolar\u0131ndaki belirli s\u00fctunlar i\u00e7in h\u0131zl\u0131 arama ve s\u0131ralama imkan\u0131 sunar. B\u00fcy\u00fck veri k\u00fcmelerinde, indekssiz bir sorgu, t\u00fcm tabloyu sat\u0131r sat\u0131r taramak zorunda kal\u0131r (full table scan), ki bu da \u00e7ok zaman al\u0131c\u0131 ve kaynak yo\u011fun bir i\u015flemdir. \u0130ndeksler, bu tam tablo taramalar\u0131n\u0131 ortadan kald\u0131rarak, veritaban\u0131 motorunun do\u011frudan ilgili verilere ula\u015fmas\u0131n\u0131 sa\u011flar ve b\u00f6ylece sorgu s\u00fcrelerini saniyelerden milisaniyelere d\u00fc\u015f\u00fcrebilir.<\/p>\n Farkl\u0131 ihtiya\u00e7lara y\u00f6nelik \u00e7e\u015fitli indeks t\u00fcrleri bulunmaktad\u0131r:<\/p>\n Bir e-ticaret platformunda, milyonlarca \u00fcr\u00fcn\u00fcn oldu\u011fu bir \u0130ndeks olu\u015fturma \u00f6rne\u011fi:<\/p>\n <\/code><\/p>\n Bu indeks olu\u015ftuktan sonra, a\u015fa\u011f\u0131daki gibi bir sorgu:<\/p>\n <\/code><\/p>\n Art\u0131k \u00e7ok daha h\u0131zl\u0131 \u00e7al\u0131\u015facakt\u0131r. Veritaban\u0131, <\/code><\/p>\n \u0130ndeksleme, veritaban\u0131 performans\u0131n\u0131 art\u0131rmak i\u00e7in genellikle ilk ba\u015fvurulan y\u00f6ntemdir. Ancak, hangi s\u00fctunlara indeks uygulanaca\u011f\u0131 ve hangi indeks t\u00fcr\u00fcn\u00fcn kullan\u0131laca\u011f\u0131 karar\u0131, uygulaman\u0131z\u0131n sorgu desenlerine ve veri eri\u015fim ihtiya\u00e7lar\u0131na g\u00f6re dikkatlice de\u011ferlendirilmelidir.<\/p>\n Hashing, indekslemeye benzer bir amaca hizmet eder: veriye h\u0131zl\u0131 eri\u015fim sa\u011flamak. Ancak, \u00e7al\u0131\u015fma prensibi ve kullan\u0131m senaryolar\u0131 a\u00e7\u0131s\u0131ndan indekslemeden belirgin farkl\u0131l\u0131klar\u0131 vard\u0131r. Hashing, bir anahtar de\u011feri (\u00f6rne\u011fin, bir ID veya e-posta adresi) al\u0131p, \u00f6zel bir matematiksel fonksiyon (hash fonksiyonu) arac\u0131l\u0131\u011f\u0131yla sabit boyutlu bir \"hash de\u011feri\"ne d\u00f6n\u00fc\u015ft\u00fcrme i\u015flemidir. Bu hash de\u011feri, daha sonra verinin depoland\u0131\u011f\u0131 konumu (disk blo\u011fu veya bellek adresi) do\u011frudan i\u015faret eder. Bu sayede, aranan veriye tek bir ad\u0131mda veya \u00e7ok az ad\u0131mla eri\u015fim sa\u011flanabilir, bu da hashing'i \u00f6zellikle tam e\u015fle\u015fme sorgular\u0131 i\u00e7in inan\u0131lmaz h\u0131zl\u0131 hale getirir.<\/p>\n Bir hash tablosu (veya hash map), anahtarlar\u0131 hash de\u011ferlerine d\u00f6n\u00fc\u015ft\u00fcrerek verileri depolayan bir veri yap\u0131s\u0131d\u0131r. Bir veri eklendi\u011finde, anahtar\u0131 hash fonksiyonundan ge\u00e7irilir ve elde edilen hash de\u011feri, verinin depolanaca\u011f\u0131 yeri belirler. Veri arand\u0131\u011f\u0131nda da ayn\u0131 i\u015flem uygulan\u0131r; aranan anahtar\u0131n hash de\u011feri hesaplan\u0131r ve do\u011frudan ilgili depolama konumuna gidilir. Teorik olarak, bu O(1) zaman karma\u015f\u0131kl\u0131\u011f\u0131na sahip, yani verinin boyutu ne olursa olsun sabit zamanda eri\u015fim demektir.<\/p>\n Ancak, her zaman i\u015fler bu kadar kusursuz y\u00fcr\u00fcmez. Farkl\u0131 girdilerin ayn\u0131 hash de\u011ferini \u00fcretmesine \"\u00e7arp\u0131\u015fma\" (collision) denir. \u00c7arp\u0131\u015fmalar\u0131n \u00e7\u00f6z\u00fcm\u00fc i\u00e7in \u00e7e\u015fitli y\u00f6ntemler vard\u0131r:<\/p>\n Bu \u00e7arp\u0131\u015fma \u00e7\u00f6z\u00fcm mekanizmalar\u0131, hashing'in performans\u0131n\u0131 etkileyebilir. \u0130yi bir hash fonksiyonu, \u00e7arp\u0131\u015fmalar\u0131 minimize eder ve verileri m\u00fcmk\u00fcn oldu\u011funca e\u015fit bir \u015fekilde da\u011f\u0131t\u0131r.<\/p>\n Hashing, genellikle a\u015fa\u011f\u0131daki durumlarda tercih edilir:<\/p>\n \u0130ndeksleme ile hashing aras\u0131ndaki temel farklar \u015funlard\u0131r:<\/p>\n Veritaban\u0131 sistemlerinde, \"Hash Index\" kavram\u0131 bazen \u00f6zel durumlarda kullan\u0131l\u0131r, ancak genel ama\u00e7l\u0131 sorgular i\u00e7in B-tree indeksler daha yayg\u0131n ve esnektir. Baz\u0131 veritaban\u0131 sistemleri, belirli tablolar veya alanlar i\u00e7in hash indeksleri sunar ve bunlar, s\u0131ralama ihtiyac\u0131 olmayan, s\u0131k\u00e7a tam e\u015fle\u015fme ile aranan s\u00fctunlarda performans\u0131 art\u0131rabilir.<\/p>\n \u00d6rne\u011fin, bir PostgreSQL veritaban\u0131nda, bir s\u00fctun \u00fczerinde hash indeksi olu\u015fturmak i\u00e7in:<\/p>\n <\/code><\/p>\n Bu indeks, <\/code><\/p>\n bu hash indeksini kullanarak \u00e7ok h\u0131zl\u0131 bir \u015fekilde yan\u0131tlanabilir. Ancak, \u0130ndeksleme ve hashing, veriye h\u0131zl\u0131 eri\u015fim i\u00e7in yap\u0131sal \u00e7\u00f6z\u00fcmler sunarken, sorgu optimizasyonu, yazd\u0131\u011f\u0131n\u0131z SQL sorgular\u0131n\u0131n veritaban\u0131 taraf\u0131ndan en verimli \u015fekilde y\u00fcr\u00fct\u00fclmesini sa\u011flamakla ilgilidir. K\u00f6t\u00fc yaz\u0131lm\u0131\u015f bir sorgu, en iyi indekslere sahip olsa bile t\u00fcm sistemi yava\u015flatabilir. Veritaban\u0131 y\u00f6netim sistemleri (DBMS), her sorguyu \u00e7al\u0131\u015ft\u0131rmadan \u00f6nce, bir \"sorgu planlay\u0131c\u0131\" veya \"optimiz\u00f6r\" arac\u0131l\u0131\u011f\u0131yla sorgunun en uygun y\u00fcr\u00fctme plan\u0131n\u0131 belirler. Bu plan, hangi indekslerin kullan\u0131laca\u011f\u0131ndan, tablolar\u0131n hangi s\u0131rayla birle\u015ftirilece\u011fine ve hangi algoritmalar\u0131n uygulanaca\u011f\u0131na kadar bir\u00e7ok detay\u0131 i\u00e7erir. Amac\u0131m\u0131z, bu optimiz\u00f6re en iyi karar\u0131 vermesi i\u00e7in yard\u0131mc\u0131 olmakt\u0131r.<\/p>\n Bir sorgunun optimizasyonu, veritaban\u0131n\u0131n \u00fczerindeki y\u00fck\u00fc azalt\u0131r, disk G\/\u00c7 (I\/O) i\u015flemlerini minimize eder ve CPU kullan\u0131m\u0131n\u0131 d\u00fc\u015f\u00fcr\u00fcr. Bu da daha h\u0131zl\u0131 yan\u0131t s\u00fcreleri, daha fazla e\u015fzamanl\u0131 kullan\u0131c\u0131 deste\u011fi ve genel olarak daha istikrarl\u0131 bir sistem anlam\u0131na gelir. Optimizasyon yap\u0131lmayan bir sorgu, y\u00fczlerce mili saniyede tamamlanabilecekken saniyeler, hatta dakikalar s\u00fcrebilir; bu durum kullan\u0131c\u0131 deneyimini do\u011frudan bozar ve uygulaman\u0131n kullan\u0131labilirli\u011fini d\u00fc\u015f\u00fcr\u00fcr.<\/p>\n Sorgu optimizasyonunun ilk ad\u0131m\u0131, mevcut bir sorgunun performans sorununu anlamakt\u0131r. Bunun i\u00e7in \u00d6rne\u011fin, PostgreSQL'de bir sorgunun plan\u0131n\u0131 incelemek i\u00e7in:<\/p>\n <\/code><\/p>\n Bu komutun \u00e7\u0131kt\u0131s\u0131, JOIN tipi (Hash Join, Nested Loop Join vb.), indeks kullan\u0131mlar\u0131 (Index Scan, Bitmap Index Scan vb.), s\u0131ralama maliyetleri ve her ad\u0131m\u0131n ger\u00e7ek zamanlar\u0131n\u0131 g\u00f6sterir. \u00c7\u0131kt\u0131da \"Seq Scan\" (Sequential Scan - tam tablo taramas\u0131) g\u00f6r\u00fcyorsan\u0131z, bu genellikle bir indeksin eksik veya yanl\u0131\u015f kullan\u0131ld\u0131\u011f\u0131na i\u015faret eder.<\/p>\n Bir e-ticaret \u015firketinin y\u00f6neticileri, ayl\u0131k olarak en \u00e7ok satan \u00fcr\u00fcnleri ve en y\u00fcksek gelir getiren m\u00fc\u015fterileri g\u00f6steren raporlar istiyor. \u0130lk sorgu a\u015fa\u011f\u0131daki gibi yaz\u0131ld\u0131:<\/p>\n <\/code><\/p>\n Bu sorgu ilk ba\u015fta yava\u015f \u00e7al\u0131\u015ft\u0131. Optimizasyon ad\u0131mlar\u0131:<\/p>\n Bu ad\u0131mlar sonucunda sorgu s\u00fcresi dakikalardan saniyelere indi. Sorgu optimizasyonu, sadece indeks ve hashing kullanmakla kalmay\u0131p, ayn\u0131 zamanda veritaban\u0131n\u0131n \"d\u00fc\u015f\u00fcnce \u015feklini\" anlayarak sorgular\u0131 ona g\u00f6re yap\u0131land\u0131rmakla ilgilidir. S\u00fcrekli izleme ve test, ba\u015far\u0131l\u0131 optimizasyonun anahtar\u0131d\u0131r.<\/p>\n Veritaban\u0131 performans\u0131 optimizasyonu, sadece indeksleme ve sorgu iyile\u015ftirmeleriyle s\u0131n\u0131rl\u0131 de\u011fildir. Daha karma\u015f\u0131k senaryolarda ve \u00e7ok b\u00fcy\u00fck veri setleriyle \u00e7al\u0131\u015f\u0131rken, sistemin genel verimlili\u011fini art\u0131rmak i\u00e7in daha ileri stratejilere ihtiya\u00e7 duyulur. Bu stratejiler, \u00f6zellikle y\u00fcksek trafikli uygulamalar ve b\u00fcy\u00fck veri analiti\u011fi sistemleri i\u00e7in vazge\u00e7ilmezdir.<\/p>\n Normalde, k\u00fcmelenmemi\u015f bir indeks kullan\u0131ld\u0131\u011f\u0131nda, veritaban\u0131 \u00f6nce indeksten ilgili anahtar\u0131 bulur, ard\u0131ndan bu anahtar\u0131n i\u015faret etti\u011fi veri sat\u0131r\u0131na (genellikle birincil anahtar arac\u0131l\u0131\u011f\u0131yla) giderek istenen di\u011fer s\u00fctun de\u011ferlerini al\u0131r. Buna \"bookmark lookup\" denir. Ancak, bir sorgunun \u00d6rne\u011fin, <\/code><\/p>\n Bu, Karma\u015f\u0131k sorgular, \u00f6zellikle raporlama ve analiz senaryolar\u0131nda, birden fazla tabloyu birle\u015ftirip yo\u011fun hesaplamalar yapabilir. Bu t\u00fcr sorgular her \u00e7al\u0131\u015ft\u0131\u011f\u0131nda ayn\u0131 pahal\u0131 hesaplamalar\u0131 tekrarlamak yerine, bu sorgular\u0131n sonu\u00e7lar\u0131n\u0131 \u00f6nceden hesaplay\u0131p ayr\u0131 bir tabloda (materialized view) depolayabilirsiniz. Bu g\u00f6r\u00fcn\u00fcm, temel tablolar de\u011fi\u015fti\u011finde d\u00fczenli aral\u0131klarla (\u00f6rne\u011fin, her gece veya her saat) yenilenebilir.<\/p>\n \u00d6rnek:<\/p>\n <\/code><\/p>\n Art\u0131k rapor sorgular\u0131 do\u011frudan \u00c7ok b\u00fcy\u00fck tablolar (milyarlarca sat\u0131r), y\u00f6netim ve sorgu performans\u0131 a\u00e7\u0131s\u0131ndan zorluklar yaratabilir. B\u00f6l\u00fcmleme, bu b\u00fcy\u00fck tablolar\u0131 daha k\u00fc\u00e7\u00fck, daha y\u00f6netilebilir par\u00e7alara (b\u00f6l\u00fcmlere) ay\u0131rma tekni\u011fidir. Bu b\u00f6l\u00fcmler, ayn\u0131 mant\u0131ksal tablo gibi g\u00f6r\u00fcnse de fiziksel olarak ayr\u0131 depolan\u0131r. B\u00f6l\u00fcmleme, veri eri\u015fimini h\u0131zland\u0131rabilir, \u00e7\u00fcnk\u00fc sorgular yaln\u0131zca ilgili b\u00f6l\u00fcmleri tarar, t\u00fcm tabloyu de\u011fil.<\/p>\n \u00d6rne\u011fin, bir B\u00f6l\u00fcmleme, ayr\u0131ca bak\u0131m i\u015flemlerini (yedekleme, indeks olu\u015fturma) kolayla\u015ft\u0131r\u0131r ve eski verilerin ar\u015fivlenmesini veya silinmesini h\u0131zland\u0131r\u0131r.<\/p>\n Veritaban\u0131 optimiz\u00f6r\u00fcn\u00fcn ak\u0131ll\u0131 kararlar verebilmesi i\u00e7in tablolardaki ve indekslerdeki veri da\u011f\u0131l\u0131m\u0131 hakk\u0131nda g\u00fcncel ve do\u011fru istatistiklere ihtiyac\u0131 vard\u0131r. E\u011fer istatistikler g\u00fcncel de\u011filse, optimiz\u00f6r yanl\u0131\u015f tahminlerde bulunabilir ve optimal olmayan bir sorgu plan\u0131 se\u00e7ebilir. Bu da performans d\u00fc\u015f\u00fc\u015flerine yol a\u00e7ar. \u00c7o\u011fu DBMS, istatistikleri otomatik olarak g\u00fcnceller, ancak b\u00fcy\u00fck veri de\u011fi\u015fikliklerinden sonra veya periyodik olarak manuel olarak g\u00fcncellemek faydal\u0131 olabilir.<\/p>\n <\/code><\/p>\n Uygulama katman\u0131nda, veritaban\u0131 ba\u011flant\u0131lar\u0131n\u0131 s\u00fcrekli a\u00e7\u0131p kapatmak yerine ba\u011flant\u0131 havuzlama (connection pooling) kullanmak, ba\u011flant\u0131 kurma maliyetini ortadan kald\u0131r\u0131r ve performans\u0131 art\u0131r\u0131r. Ayr\u0131ca, s\u0131k\u00e7a eri\u015filen ve nadiren de\u011fi\u015fen verileri uygulama taraf\u0131nda veya ayr\u0131 bir \u00f6nbellek katman\u0131nda (\u00f6rne\u011fin, Redis veya Memcached) \u00f6nbelle\u011fe almak, veritaban\u0131na olan y\u00fck\u00fc \u00f6nemli \u00f6l\u00e7\u00fcde azaltabilir.<\/p>\n Mobil uygulamalar, g\u00fcn\u00fcm\u00fczde kullan\u0131c\u0131lar\u0131n b\u00fcy\u00fck bir k\u0131sm\u0131n\u0131n etkile\u015fimde bulundu\u011fu ana platformlard\u0131r. Mobil cihazlar\u0131n s\u0131n\u0131rl\u0131 i\u015flem g\u00fcc\u00fc, de\u011fi\u015fken a\u011f ko\u015fullar\u0131 ve pil \u00f6mr\u00fc k\u0131s\u0131tlamalar\u0131, veritaban\u0131 eri\u015fiminde ve veri sunumunda \u00f6zel bir dikkat gerektirir. Veritaban\u0131 optimizasyonu, mobil uygulamalar\u0131n h\u0131zl\u0131, ak\u0131c\u0131 ve kaynak dostu \u00e7al\u0131\u015fmas\u0131 i\u00e7in hayati \u00f6nem ta\u015f\u0131r. Mobil uyumluluk, sadece ekran boyutlar\u0131na adapte olmakla kalmaz, ayn\u0131 zamanda verinin h\u0131zl\u0131 ve verimli bir \u015fekilde sunulmas\u0131n\u0131 da kapsar.<\/p>\n Bu zorluklar g\u00f6z \u00f6n\u00fcne al\u0131nd\u0131\u011f\u0131nda, mobil uygulamalar i\u00e7in veritaban\u0131 optimizasyonunda temel stratejiler \u015funlard\u0131r:<\/p>\n Veritaban\u0131ndan gelen veriler genellikle HTML aray\u00fczlerinde sunulur. Mobil uyumlu bir deneyim i\u00e7in sadece veritaban\u0131 sorgular\u0131n\u0131n h\u0131zl\u0131 olmas\u0131 yeterli de\u011fildir, ayn\u0131 zamanda bu verinin cihaz boyutuna uygun \u015fekilde g\u00f6r\u00fcnt\u00fclenmesi de \u00f6nemlidir. \u0130\u015fte burada CSS medya sorgular\u0131 (media queries) devreye girer. Medya sorgular\u0131, farkl\u0131 ekran boyutlar\u0131na ve \u00e7\u00f6z\u00fcn\u00fcrl\u00fcklere g\u00f6re farkl\u0131 stil kurallar\u0131n\u0131 uygulaman\u0131za olanak tan\u0131r. \u00d6rne\u011fin, bir veri tablosunu mobil ekranda daha okunakl\u0131 hale getirmek i\u00e7in s\u00fctunlar\u0131 alt alta s\u0131ralayabilirsiniz.<\/p>\n A\u015fa\u011f\u0131da, bir veri tablosunun mobil cihazlarda nas\u0131l daha okunabilir hale getirilece\u011fine dair bir CSS medya sorgusu \u00f6rne\u011fi verilmi\u015ftir:<\/p>\n\u0130ndeksleme Nedir ve Veritaban\u0131 Performans\u0131n\u0131 Nas\u0131l Art\u0131r\u0131r?<\/h2>\n
Hangi \u0130ndeks T\u00fcrleri Mevcuttur ve Ne Zaman Kullan\u0131lmal\u0131d\u0131r?<\/h3>\n
\n
(Soyad, Ad)<\/code> s\u00fctunlar\u0131 \u00fczerinde bir indeks olu\u015fturmak, hem soyada g\u00f6re hem de soyad i\u00e7inde ada g\u00f6re arama yapan sorgular\u0131 h\u0131zland\u0131rabilir. S\u00fctunlar\u0131n s\u0131ras\u0131 \u00f6nemlidir.<\/li>\nLIKE '%kelime%'<\/code> sorgular\u0131nda tam tablo taramas\u0131na neden olurken, tam metin indeksleri bu t\u00fcr sorgular\u0131 \u00e7ok daha verimli hale getirir.<\/li>\n<\/ul>\nGer\u00e7ek D\u00fcnya Senaryosu: E-ticaret \u00dcr\u00fcn Aramas\u0131<\/h3>\n
Urunler<\/code> tablosu d\u00fc\u015f\u00fcnelim. Kullan\u0131c\u0131lar genellikle \u00fcr\u00fcn ad\u0131na, kategoriye veya fiyat aral\u0131\u011f\u0131na g\u00f6re arama yapar. E\u011fer bu tablonun UrunAdi<\/code> s\u00fctununda bir indeks yoksa, her arama sorgusu t\u00fcm Urunler<\/code> tablosunu taramak zorunda kal\u0131r, bu da saniyeler s\u00fcren yava\u015f yan\u0131tlara yol a\u00e7ar. Ancak, UrunAdi<\/code> \u00fczerinde bir k\u00fcmelenmemi\u015f indeks olu\u015fturdu\u011fumuzda durum de\u011fi\u015fir.<\/p>\n\nCREATE INDEX IX_Urunler_UrunAdi\nON Urunler (UrunAdi);\n <\/pre>\n\nSELECT UrunID, UrunAdi, Fiyat\nFROM Urunler\nWHERE UrunAdi LIKE 'Ak\u0131ll\u0131 Telefon%';\n <\/pre>\nUrunAdi<\/code> indeksi \u00fczerinde \"Ak\u0131ll\u0131 Telefon\" ile ba\u015flayan \u00fcr\u00fcnleri h\u0131zl\u0131ca bulacak ve sadece ilgili veri sat\u0131rlar\u0131na eri\u015fecektir. E\u011fer kullan\u0131c\u0131lar s\u0131k s\u0131k hem \u00fcr\u00fcn ad\u0131na hem de kategoriye g\u00f6re arama yap\u0131yorsa, (UrunAdi, KategoriID)<\/code> gibi bir birle\u015fik indeks de d\u00fc\u015f\u00fcn\u00fclebilir:<\/p>\n\nCREATE INDEX IX_Urunler_UrunAdi_Kategori\nON Urunler (UrunAdi, KategoriID);\n <\/pre>\nHashing Y\u00f6ntemleri ve Veriye H\u0131zl\u0131 Eri\u015fim Sa\u011flama Yollar\u0131<\/h2>\n
Hashing Nas\u0131l \u00c7al\u0131\u015f\u0131r?<\/h3>\n
\n
Hashing Ne Zaman Kullan\u0131l\u0131r? \u0130ndekslemeden Farklar\u0131 Nelerdir?<\/h3>\n
\n
CustomerID<\/code> ile m\u00fc\u015fteri bilgilerini \u00e7ekmek).<\/li>\n\n
WHERE fiyat BETWEEN 100 AND 200<\/code>) ve s\u0131ral\u0131 okumalar (ORDER BY UrunAdi<\/code>) i\u00e7in \u00e7ok etkilidir. Hashing ise veri s\u0131ras\u0131n\u0131 korumaz ve bu t\u00fcr sorgular i\u00e7in uygun de\u011fildir.<\/li>\n\nCREATE INDEX IX_Kullanicilar_Email_Hash ON Kullanicilar USING HASH (Email);\n <\/pre>\nKullanicilar<\/code> tablosundaki Email<\/code> s\u00fctunu \u00fczerinde bir hash indeksi olu\u015fturur. Art\u0131k a\u015fa\u011f\u0131daki gibi bir sorgu:<\/p>\n\nSELECT * FROM Kullanicilar WHERE Email = 'ornek@mail.com';\n <\/pre>\nEmail LIKE '%mail.com'<\/code> veya ORDER BY Email<\/code> gibi sorgular bu indeksi kullanamaz.<\/p>\nSorgu Optimizasyonu: SQL Sorgular\u0131n\u0131z\u0131 Neden ve Nas\u0131l \u0130yile\u015ftirmelisiniz?<\/h2>\n
Sorgu Optimizasyonunun \u00d6nemi<\/h3>\n
Sorgu Plan\u0131n\u0131 Anlamak: EXPLAIN Komutu<\/h3>\n
EXPLAIN<\/code> (veya baz\u0131 veritabanlar\u0131nda EXPLAIN ANALYZE<\/code>) komutu kullan\u0131l\u0131r. Bu komut, veritaban\u0131 optimiz\u00f6r\u00fcn\u00fcn belirli bir sorgu i\u00e7in hangi y\u00fcr\u00fctme plan\u0131n\u0131 se\u00e7ti\u011fini, hangi indeksleri kulland\u0131\u011f\u0131n\u0131, ka\u00e7 sat\u0131r\u0131 tarad\u0131\u011f\u0131n\u0131 ve tahmini maliyetini g\u00f6sterir. Bu bilgiyi analiz ederek darbo\u011fazlar\u0131 tespit edebilirsiniz.<\/p>\n\nEXPLAIN ANALYZE\nSELECT U.KullaniciAdi, S.SiparisTarihi, S.ToplamTutar\nFROM Kullanicilar U\nJOIN Siparisler S ON U.KullaniciID = S.KullaniciID\nWHERE S.SiparisTarihi >= '2023-01-01' AND S.ToplamTutar > 1000\nORDER BY S.SiparisTarihi DESC;\n <\/pre>\nSorgu Optimizasyonu Teknikleri ve \u0130pu\u00e7lar\u0131<\/h3>\n
\n
SELECT *<\/code> yerine sadece ihtiyac\u0131n\u0131z olan s\u00fctunlar\u0131 belirtin. Bu, a\u011f trafi\u011fini ve bellek kullan\u0131m\u0131n\u0131 azalt\u0131r.<\/li>\nWHERE<\/code> ko\u015fulunun sol taraf\u0131nda kullanmaktan ka\u00e7\u0131n\u0131n. \u00d6rne\u011fin, WHERE DATE(SiparisTarihi) = '2023-01-01'<\/code> yerine WHERE SiparisTarihi >= '2023-01-01' AND SiparisTarihi < '2023-01-02'<\/code> kullan\u0131n, \u00e7\u00fcnk\u00fc ilk \u00f6rnekte indeks kullan\u0131lmayabilir.<\/li>\nJOIN<\/code> stratejisini (Nested Loop, Hash Join, Merge Join) se\u00e7mesine izin verin. Genellikle, \u00f6ncelikle daha k\u00fc\u00e7\u00fck tabloyu filtreleyip sonra birle\u015ftirme yapmak daha etkilidir.<\/li>\nIN<\/code> veya EXISTS<\/code> ile kullan\u0131lan alt sorgular yerine INNER JOIN<\/code> kullanmak daha performansl\u0131 olabilir, \u00e7\u00fcnk\u00fc JOIN optimizasyonu genellikle daha geli\u015fmi\u015ftir.<\/li>\nOFFSET<\/code> de\u011feri \u00e7ok b\u00fcy\u00fcd\u00fc\u011f\u00fcnde performans sorunlar\u0131 ya\u015fanabilir, \u00e7\u00fcnk\u00fc veritaban\u0131 yine de OFFSET<\/code> kadarki t\u00fcm sat\u0131rlar\u0131 i\u015flemek zorunda kal\u0131r. M\u00fcmk\u00fcnse WHERE<\/code> ko\u015fullar\u0131na dayal\u0131 daha ak\u0131ll\u0131 sayfalama y\u00f6ntemleri (\u00f6rne\u011fin, \"cursor-based pagination\") kullan\u0131n.<\/li>\nANALYZE<\/code> komutuyla) kritiktir.<\/li>\n<\/ol>\nVaka Analizi: E-ticaret Raporlama Sistemi<\/h3>\n
\nSELECT P.UrunAdi, SUM(OD.Adet * OD.BirimFiyat) AS ToplamGelir\nFROM Urunler P\nJOIN SiparisDetaylari OD ON P.UrunID = OD.UrunID\nJOIN Siparisler S ON OD.SiparisID = S.SiparisID\nWHERE S.SiparisTarihi BETWEEN '2023-01-01' AND '2023-01-31'\nGROUP BY P.UrunAdi\nORDER BY ToplamGelir DESC\nLIMIT 10;\n <\/pre>\nEXPLAIN ANALYZE<\/code> \u00e7\u0131kt\u0131s\u0131, SiparisTarihi<\/code> \u00fczerinde indeks olmas\u0131na ra\u011fmen Siparisler<\/code> tablosunda tam tarama yap\u0131ld\u0131\u011f\u0131n\u0131 g\u00f6sterdi. Ayr\u0131ca, UrunAdi<\/code> \u00fczerinde GROUP BY<\/code> i\u015fleminin \u00e7ok maliyetli oldu\u011funu ortaya \u00e7\u0131kard\u0131.<\/p>\n\n
SiparisTarihi<\/code> \u00fczerindeki indeksin do\u011fru kullan\u0131ld\u0131\u011f\u0131ndan emin olundu. (Bazen veri tipi uyumsuzluklar\u0131 veya fonksiyon kullan\u0131mlar\u0131 indeksi devre d\u0131\u015f\u0131 b\u0131rakabilir.)<\/li>\nSiparisDetaylari<\/code> tablosundaki UrunID<\/code> ve SiparisID<\/code> s\u00fctunlar\u0131na indeks eklendi.<\/li>\nGeli\u015fmi\u015f Optimizasyon Stratejileri ve \u0130pu\u00e7lar\u0131 Nelerdir?<\/h2>\n
Kapsayan \u0130ndeksler (Covering Indexes)<\/h3>\n
SELECT<\/code> listesindeki t\u00fcm s\u00fctunlar ve WHERE<\/code> ko\u015fulundaki t\u00fcm s\u00fctunlar, bir indekste mevcutsa, veritaban\u0131 do\u011frudan indeksten t\u00fcm gerekli bilgiyi alabilir ve ana veri tablosuna eri\u015fmeye gerek duymaz. Bu t\u00fcr indekslere \"kapsayan indeks\" denir ve disk I\/O'yu \u00f6nemli \u00f6l\u00e7\u00fcde azaltarak sorgu performans\u0131n\u0131 art\u0131r\u0131r.<\/p>\nMusteriler<\/code> tablosunda Email<\/code> ve Adres<\/code> s\u00fctunlar\u0131n\u0131 s\u0131kl\u0131kla birlikte ar\u0131yorsan\u0131z:<\/p>\n\nCREATE INDEX IX_Musteriler_Email_Adres ON Musteriler (Email) INCLUDE (Adres);\n <\/pre>\nEmail<\/code> \u00fczerinde bir indeks olu\u015fturur ve Adres<\/code> s\u00fctununu indeksin bir par\u00e7as\u0131 olarak dahil eder. B\u00f6ylece, SELECT Email, Adres FROM Musteriler WHERE Email = 'abc@xyz.com'<\/code> gibi bir sorgu do\u011frudan bu indeksten yan\u0131tlanabilir.<\/p>\nMaterialized View'ler (Somutla\u015ft\u0131r\u0131lm\u0131\u015f G\u00f6r\u00fcn\u00fcmler)<\/h3>\n
\nCREATE MATERIALIZED VIEW AylikSatisRaporu AS\nSELECT\n DATE_TRUNC('month', S.SiparisTarihi) AS Ay,\n P.Kategori,\n SUM(OD.Adet * OD.BirimFiyat) AS ToplamGelir\nFROM Siparisler S\nJOIN SiparisDetaylari OD ON S.SiparisID = OD.SiparisID\nJOIN Urunler P ON OD.UrunID = P.UrunID\nGROUP BY 1, 2\nWITH DATA;\n\n-- G\u00f6r\u00fcn\u00fcm\u00fc yenilemek i\u00e7in:\nREFRESH MATERIALIZED VIEW AylikSatisRaporu;\n <\/pre>\nAylikSatisRaporu<\/code> g\u00f6r\u00fcn\u00fcm\u00fcnden okunur ve \u00e7ok daha h\u0131zl\u0131 yan\u0131t verir.<\/p>\nB\u00f6l\u00fcmleme (Partitioning)<\/h3>\n
Loglar<\/code> tablosunu Tarih<\/code> s\u00fctununa g\u00f6re ayl\u0131k b\u00f6l\u00fcmlere ay\u0131rabilirsiniz. 2023 Ocak ay\u0131 loglar\u0131n\u0131 sorgulad\u0131\u011f\u0131n\u0131zda, veritaban\u0131 yaln\u0131zca ilgili Ocak b\u00f6l\u00fcm\u00fcn\u00fc inceler.<\/p>\nVeritaban\u0131 \u0130statistiklerinin \u00d6nemi<\/h3>\n
\nANALYZE TABLE BenimTablom; -- MySQL\/MariaDB\nVACUUM ANALYZE BenimTablom; -- PostgreSQL\nUPDATE STATISTICS BenimTablom; -- SQL Server\n <\/pre>\nBa\u011flant\u0131 Havuzlama ve \u00d6nbellekleme<\/h3>\n
Mobil Uyumlu Veritaban\u0131 Y\u00f6netimi: Performans\u0131 Mobil Ortamda Nas\u0131l Korursunuz?<\/h2>\n
Mobil Ortam\u0131n Zorluklar\u0131 ve Veritaban\u0131 \u0130li\u015fkisi<\/h3>\n
\n
\n
SELECT *<\/code> kullanmaktan ka\u00e7\u0131narak sadece ihtiyac\u0131n\u0131z olan s\u00fctunlar\u0131 \u00e7ekin. Ayr\u0131ca, sayfalama (pagination) kullanarak b\u00fcy\u00fck veri setlerini k\u00fc\u00e7\u00fck par\u00e7alar halinde y\u00fckleyin. Bu, a\u011f trafi\u011fini ve dolay\u0131s\u0131yla gecikmeyi azalt\u0131r.<\/li>\nMobil Uyumlu HTML ve Veri Sunumu<\/h3>\n
\n