PostgreSQL ile \u00e7al\u0131\u015f\u0131rken performans sorunlar\u0131, kilitlenmeler veya beklenmedik davran\u0131\u015flarla m\u0131 kar\u015f\u0131la\u015f\u0131yorsunuz? Pek \u00e7ok geli\u015ftirici gibi, ben de SQL sorgular\u0131n\u0131 yazmakta ustala\u015fsam bile, veritaban\u0131n\u0131n “neden” b\u00f6yle davrand\u0131\u011f\u0131n\u0131 anlamakta zorland\u0131\u011f\u0131m zamanlar oldu. Ancak, PostgreSQL’in alt\u0131nda yatan zihin modelini kavrad\u0131\u011f\u0131mda, her \u015fey yerine oturdu ve veritaban\u0131 y\u00f6netimi \u00e7ok daha sezgisel hale geldi. Bu makalede, benim i\u00e7in d\u00f6n\u00fcm noktas\u0131 olan bu temel kavramlar\u0131, ger\u00e7ek d\u00fcnya senaryolar\u0131 ve pratik \u00f6rneklerle ele alaca\u011f\u0131z, b\u00f6ylece siz de PostgreSQL’in derinliklerine inerek daha verimli ve g\u00fcvenli uygulamalar geli\u015ftirebileceksiniz.<\/p>\n
Herhangi bir karma\u015f\u0131k sistemde oldu\u011fu gibi, PostgreSQL’in de temel mimarisini anlamak, sorunlar\u0131 te\u015fhis etmek, performans\u0131 optimize etmek ve genel olarak sistemi daha iyi y\u00f6netmek i\u00e7in kritik \u00f6neme sahiptir. Veritaban\u0131n\u0131n nas\u0131l \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 bilmek, sadece bir SQL sorgusu yazmaktan \u00f6teye ge\u00e7erek, sorgunun arkas\u0131nda yatan s\u00fcre\u00e7leri ve kaynak t\u00fcketimini \u00f6ng\u00f6rmenizi sa\u011flar. PostgreSQL’in mimarisi, bir dizi birbirine ba\u011fl\u0131 s\u00fcre\u00e7ten, payla\u015f\u0131ml\u0131 bellek alanlar\u0131ndan ve disk \u00fczerindeki veri yap\u0131lar\u0131ndan olu\u015fur.<\/p>\n
En temel bile\u015fenlerden biri Postmaster<\/strong> s\u00fcrecidir. Bu, PostgreSQL sunucusunun ana s\u00fcrecidir ve t\u00fcm di\u011fer s\u00fcre\u00e7leri ba\u015flatmaktan ve y\u00f6netmekten sorumludur. \u0130stemcilerden gelen ba\u011flant\u0131 isteklerini dinler ve her yeni ba\u011flant\u0131 i\u00e7in bir Backend (arka u\u00e7) s\u00fcreci<\/strong> olu\u015fturur. Bu backend s\u00fcre\u00e7leri, asl\u0131nda bizim SQL sorgular\u0131m\u0131z\u0131 i\u015fleyen, veritaban\u0131 ile etkile\u015fime giren ve sonu\u00e7lar\u0131 istemciye d\u00f6nd\u00fcren ba\u011f\u0131ms\u0131z s\u00fcre\u00e7lerdir. Her bir ba\u011flant\u0131n\u0131n kendi backend s\u00fcreci olmas\u0131, bir ba\u011flant\u0131daki hatan\u0131n di\u011ferlerini etkilemesini \u00f6nler ve sistemin genel kararl\u0131l\u0131\u011f\u0131n\u0131 art\u0131r\u0131r. Ancak, ayn\u0131 zamanda \u00e7ok say\u0131da e\u015fzamanl\u0131 ba\u011flant\u0131n\u0131n y\u00fcksek bellek ve CPU t\u00fcketimine yol a\u00e7abilece\u011fi anlam\u0131na da gelir.<\/p>\n PostgreSQL, performans i\u00e7in Payla\u015f\u0131ml\u0131 Bellek (Shared Memory)<\/strong> alanlar\u0131n\u0131 yo\u011fun bir \u015fekilde kullan\u0131r. Bu alanlar, birden fazla backend s\u00fcreci taraf\u0131ndan eri\u015filebilen ve payla\u015f\u0131lan veri yap\u0131lar\u0131n\u0131 i\u00e7erir. En \u00f6nemlilerinden biri Payla\u015f\u0131ml\u0131 Tamponlar (Shared Buffers)<\/strong>‘d\u0131r. Diskten okunan veri sayfalar\u0131 (data pages) ve indeks sayfalar\u0131 burada \u00f6nbelle\u011fe al\u0131n\u0131r. Bir sorgu diskten veri istedi\u011finde, \u00f6nce bu tamponlara bak\u0131l\u0131r; e\u011fer veri oradaysa, disk I\/O’sundan ka\u00e7\u0131n\u0131larak \u00e7ok daha h\u0131zl\u0131 eri\u015fim sa\u011flan\u0131r. Bir di\u011fer kritik payla\u015f\u0131ml\u0131 bellek alan\u0131 ise WAL (Write-Ahead Log) Tamponlar\u0131<\/strong>‘d\u0131r. WAL, veritaban\u0131 de\u011fi\u015fikliklerinin kal\u0131c\u0131 depolamaya yaz\u0131lmadan \u00f6nce kaydedildi\u011fi bir g\u00fcnl\u00fck (log) sistemidir. Bu tamponlar, de\u011fi\u015fikliklerin diskteki WAL dosyalar\u0131na yaz\u0131lmadan \u00f6nce ge\u00e7ici olarak tutuldu\u011fu yerdir. WAL’\u0131n varl\u0131\u011f\u0131, PostgreSQL’in ACID \u00f6zelliklerinden biri olan Atomicity (B\u00fct\u00fcnl\u00fck) ve Durability (Kal\u0131c\u0131l\u0131k) garantisini sa\u011flar. Yani, bir i\u015flem tamamlanmadan \u00f6nce sistem \u00e7\u00f6kerse bile, WAL sayesinde veritaban\u0131 tutarl\u0131 bir duruma geri d\u00f6nd\u00fcr\u00fclebilir.<\/p>\n Arka plan s\u00fcre\u00e7leri de mimarinin \u00f6nemli bir par\u00e7as\u0131d\u0131r. \u00d6rne\u011fin, WAL Writer<\/strong> s\u00fcreci, WAL tamponlar\u0131ndaki verileri d\u00fczenli aral\u0131klarla diskteki WAL dosyalar\u0131na yazar. Checkpointer<\/strong> s\u00fcreci, payla\u015f\u0131ml\u0131 tamponlardaki kirli (de\u011fi\u015ftirilmi\u015f ama hen\u00fcz diske yaz\u0131lmam\u0131\u015f) veri sayfalar\u0131n\u0131 diske yazar ve kurtarma noktalar\u0131 (checkpoints) olu\u015fturur. Bu, sistem \u00e7\u00f6kmesi durumunda kurtarma s\u00fcresini k\u0131salt\u0131r. Autovacuum<\/strong> s\u00fcreci ise, veritaban\u0131nda biriken “\u00f6l\u00fc kay\u0131tlar\u0131” temizleyerek performans\u0131 ve disk alan\u0131 kullan\u0131m\u0131n\u0131 optimize eder. Bu s\u00fcre\u00e7lerin her biri, PostgreSQL’in sa\u011fl\u0131kl\u0131 ve performansl\u0131 \u00e7al\u0131\u015fmas\u0131 i\u00e7in vazge\u00e7ilmezdir. T\u00fcm bu bile\u015fenler, PostgreSQL’in y\u00fcksek performansl\u0131, g\u00fcvenilir ve esnek bir veritaban\u0131 olmas\u0131n\u0131 sa\u011flar. Bu mimariyi anlamak, bir sorunun bellek, disk I\/O, CPU veya a\u011f ile ilgili olup olmad\u0131\u011f\u0131n\u0131 belirlemenize yard\u0131mc\u0131 olur ve do\u011fru optimizasyon stratejilerini uygulaman\u0131z i\u00e7in size yol g\u00f6sterir.<\/p>\n Ger\u00e7ek d\u00fcnya senaryosu:<\/strong> Bir e-ticaret platformu d\u00fc\u015f\u00fcnelim. Black Friday gibi yo\u011fun bir al\u0131\u015fveri\u015f d\u00f6neminde, sunucuya binlerce e\u015fzamanl\u0131 ba\u011flant\u0131 gelir. Her ba\u011flant\u0131 kendi backend s\u00fcrecini tetikler. E\u011fer payla\u015f\u0131ml\u0131 tamponlar yeterince b\u00fcy\u00fck de\u011filse veya WAL yazma h\u0131z\u0131 disk kapasitesini a\u015farsa, sistem yava\u015flar, sorgular gecikir ve hatta veritaban\u0131 kilitlenebilir. Bu durumda, Postmaster’\u0131n ba\u011flant\u0131 y\u00f6netimini, shared buffers’\u0131n \u00f6nbellekleme yetene\u011fini ve WAL’\u0131n veri b\u00fct\u00fcnl\u00fc\u011f\u00fcn\u00fc nas\u0131l sa\u011flad\u0131\u011f\u0131n\u0131 anlamak, performans darbo\u011fazlar\u0131n\u0131 tespit edip PostgreSQL’in beni en \u00e7ok etkileyen ve zihin modelimi tamamen de\u011fi\u015ftiren \u00f6zelli\u011fi, \u015f\u00fcphesiz Multi-Version Concurrency Control (\u00c7ok S\u00fcr\u00fcml\u00fc E\u015fzamanl\u0131l\u0131k Kontrol\u00fc – MVCC)<\/strong> mekanizmas\u0131d\u0131r. Geleneksel veritaban\u0131 sistemlerinde, bir i\u015flem bir kayd\u0131 okurken ba\u015fka bir i\u015flemin ayn\u0131 kayd\u0131 g\u00fcncellemesi, kilitlenmelere veya tutars\u0131z verilere yol a\u00e7abilirdi. Bu durum, \u00f6zellikle y\u00fcksek e\u015fzamanl\u0131l\u0131\u011fa sahip uygulamalarda ciddi performans sorunlar\u0131na neden olurdu. PostgreSQL ise bu sorunu MVCC ile zarif bir \u015fekilde \u00e7\u00f6zer.<\/p>\n MVCC’nin temel prensibi, bir verinin birden fazla “s\u00fcr\u00fcm\u00fcn\u00fc” ayn\u0131 anda saklamakt\u0131r. Bir kay\u0131t g\u00fcncellendi\u011finde veya silindi\u011finde, asl\u0131nda eski kay\u0131t fiziksel olarak hemen silinmez. Bunun yerine, yeni bir s\u00fcr\u00fcm olu\u015fturulur veya eski s\u00fcr\u00fcm “ge\u00e7ersiz” olarak i\u015faretlenir. Her i\u015flem (transaction), ba\u015flad\u0131\u011f\u0131 anda veritaban\u0131n\u0131n belirli bir “anl\u0131k g\u00f6r\u00fcnt\u00fcs\u00fcn\u00fc” (snapshot) g\u00f6r\u00fcr. Bu anl\u0131k g\u00f6r\u00fcnt\u00fc, i\u015flemin ba\u015flad\u0131\u011f\u0131 zamana kadar commit edilmi\u015f t\u00fcm verileri i\u00e7erir. Dolay\u0131s\u0131yla, bir i\u015flem okuma yaparken, ba\u015fka bir i\u015flem ayn\u0131 kayd\u0131 g\u00fcncellese bile, okuyan i\u015flem kendi anl\u0131k g\u00f6r\u00fcnt\u00fcs\u00fcndeki eski s\u00fcr\u00fcm\u00fc g\u00f6rmeye devam eder. Bu sayede, okuma i\u015flemleri yazma i\u015flemlerini, yazma i\u015flemleri de okuma i\u015flemlerini engellemez. \u0130\u015fte bu, okuyucular\u0131n yaz\u0131c\u0131lar\u0131 asla engellemedi\u011fi ve yaz\u0131c\u0131lar\u0131n okuyucular\u0131 nadiren engelledi\u011fi<\/strong> anlam\u0131na gelir.<\/p>\n Bu mekanizma, \u00f6zellikle tuple g\u00f6r\u00fcn\u00fcrl\u00fc\u011f\u00fc (tuple visibility)<\/strong> kavram\u0131yla yak\u0131ndan ili\u015fkilidir. Her bir veri kayd\u0131 (tuple), iki gizli s\u00fctuna sahiptir: MVCC’nin sa\u011flad\u0131\u011f\u0131 en b\u00fcy\u00fck avantaj, veritaban\u0131 kilitlenmelerini (locking) \u00f6nemli \u00f6l\u00e7\u00fcde azaltmas\u0131d\u0131r. Okuma i\u015flemleri i\u00e7in genellikle herhangi bir kilit gerekmez, bu da veritaban\u0131n\u0131n y\u00fcksek e\u015fzamanl\u0131 okuma y\u00fcklerini kolayca kald\u0131rabilece\u011fi anlam\u0131na gelir. Yazma i\u015flemleri i\u00e7in de sadece ilgili kay\u0131t \u00fczerinde k\u0131sa s\u00fcreli ve hafif kilitler kullan\u0131l\u0131r. Bu sayede, sistemin genel yan\u0131t s\u00fcresi iyile\u015fir ve kullan\u0131c\u0131 deneyimi artar. Ancak, MVCC’nin bir bedeli de vard\u0131r: “\u00f6l\u00fc kay\u0131tlar” (dead tuples). Bir kay\u0131t g\u00fcncellendi\u011finde veya silindi\u011finde, eski s\u00fcr\u00fcm\u00fc diskte kalmaya devam eder. Bu \u00f6l\u00fc kay\u0131tlar, disk alan\u0131 kaplar ve indekslerin \u015fi\u015fmesine (bloat) neden olabilir. \u0130\u015fte bu noktada Vaka analizi:<\/strong> Bir bankac\u0131l\u0131k uygulamas\u0131 d\u00fc\u015f\u00fcn\u00fcn. Ayn\u0131 anda y\u00fczlerce m\u00fc\u015fteri hesap bakiyelerini sorgularken, di\u011fer m\u00fc\u015fteriler para transferi gibi i\u015flemlerle hesaplar\u0131n\u0131 g\u00fcncelliyor olabilir. Geleneksel bir kilitlenme mekanizmas\u0131yla, bir m\u00fc\u015fteri bakiyesini sorgularken, o hesab\u0131n kilitlenmesi di\u011fer i\u015flemlerin beklemesine neden olabilir. Ancak MVCC sayesinde, bir m\u00fc\u015fteri bakiyesini sorgulad\u0131\u011f\u0131nda, o anki veritaban\u0131 anl\u0131k g\u00f6r\u00fcnt\u00fcs\u00fcn\u00fc al\u0131r. Ba\u015fka bir m\u00fc\u015fteri ayn\u0131 anda para transferi yaparak hesab\u0131n\u0131 g\u00fcncellese bile, sorgu yapan m\u00fc\u015fteri i\u015flemi ba\u015flamadan \u00f6nceki bakiyeyi g\u00f6r\u00fcr. Transfer i\u015flemi tamamland\u0131\u011f\u0131nda, sorgu yapan m\u00fc\u015fteri bir sonraki sorgusunda g\u00fcncel bakiyeyi g\u00f6recektir. Bu, veritaban\u0131n\u0131n tutarl\u0131l\u0131\u011f\u0131n\u0131 korurken, y\u00fcksek e\u015fzamanl\u0131l\u0131\u011f\u0131 ve kesintisiz hizmeti m\u00fcmk\u00fcn k\u0131lar. MVCC, PostgreSQL’in modern, y\u00fcksek performansl\u0131 ve g\u00fcvenilir bir veritaban\u0131 olmas\u0131n\u0131n temel ta\u015flar\u0131ndan biridir.<\/p>\n Veritaban\u0131 sistemlerinin temel amac\u0131, verileri g\u00fcvenli, tutarl\u0131 ve b\u00fct\u00fcnl\u00fckl\u00fc bir \u015fekilde depolamak ve y\u00f6netmektir. Bu g\u00fcvenli\u011fi sa\u011flayan en \u00f6nemli kavramlardan biri, ACID \u00f6zellikleri<\/strong> olarak bilinen bir dizi prensiptir. ACID, Atomicity (Atomiklik), Consistency (Tutarl\u0131l\u0131k), Isolation (\u0130zolasyon) ve Durability (Kal\u0131c\u0131l\u0131k) kelimelerinin ba\u015f harflerinden olu\u015fur. PostgreSQL, bu \u00f6zellikleri titizlikle uygulayarak verilerinizin her zaman g\u00fcvende ve do\u011fru olmas\u0131n\u0131 garanti eder.<\/p>\n Atomicity (Atomiklik):<\/strong> Bir i\u015flem (transaction) ya tamamen tamamlan\u0131r (commit) ya da hi\u00e7 tamamlanmaz (rollback). Yani, bir i\u015flemin i\u00e7indeki t\u00fcm ad\u0131mlar ya ba\u015far\u0131yla uygulan\u0131r ya da herhangi bir ad\u0131mda hata olu\u015fursa, i\u015flem ba\u015flang\u0131\u00e7taki durumuna geri d\u00f6nd\u00fcr\u00fcl\u00fcr. Yar\u0131m kalm\u0131\u015f bir i\u015flem durumu s\u00f6z konusu olamaz. \u00d6rne\u011fin, bir banka hesab\u0131ndan di\u011ferine para transferi i\u015flemi, iki ayr\u0131 ad\u0131m\u0131 i\u00e7erir: bir hesaptan para \u00e7ekmek ve di\u011ferine para yat\u0131rmak. E\u011fer ilk ad\u0131m ba\u015far\u0131l\u0131 olup ikinci ad\u0131m ba\u015far\u0131s\u0131z olursa, atomiklik prensibi sayesinde t\u00fcm i\u015flem geri al\u0131n\u0131r ve ilk hesap bakiyesi de ba\u015flang\u0131\u00e7 durumuna d\u00f6ner. Bu, veritaban\u0131n\u0131n tutars\u0131z bir duruma d\u00fc\u015fmesini engeller.<\/p>\n Consistency (Tutarl\u0131l\u0131k):<\/strong> Bir i\u015flem ba\u015flad\u0131\u011f\u0131nda ve bitti\u011finde, veritaban\u0131 her zaman tutarl\u0131 bir durumda olmal\u0131d\u0131r. Bu, t\u00fcm tan\u0131mlanm\u0131\u015f k\u0131s\u0131tlamalar\u0131n (primary key, foreign key, unique, check k\u0131s\u0131tlamalar\u0131) ve tetikleyicilerin (triggers) her zaman ge\u00e7erli oldu\u011fu anlam\u0131na gelir. Bir i\u015flem, veritaban\u0131n\u0131 tutars\u0131z bir duruma sokacaksa, otomatik olarak geri al\u0131n\u0131r. \u00d6rne\u011fin, negatif bakiye kabul etmeyen bir k\u0131s\u0131tlama varsa, bir i\u015flem hesaptan para \u00e7ekerek bakiyeyi negatife d\u00fc\u015f\u00fcrecekse, bu i\u015flem tutarl\u0131l\u0131k ihlali nedeniyle geri al\u0131n\u0131r.<\/p>\n Isolation (\u0130zolasyon):<\/strong> E\u015fzamanl\u0131 \u00e7al\u0131\u015fan i\u015flemler, birbirlerinden ba\u011f\u0131ms\u0131z ve izole bir \u015fekilde \u00e7al\u0131\u015f\u0131r. Bir i\u015flem, di\u011fer e\u015fzamanl\u0131 i\u015flemlerin yapt\u0131\u011f\u0131 de\u011fi\u015fiklikleri, o i\u015flemler commit edilene kadar g\u00f6rmez. Bu, her i\u015flemin veritaban\u0131n\u0131 tek ba\u015f\u0131na \u00e7al\u0131\u015f\u0131yormu\u015f gibi g\u00f6rmesini sa\u011flar ve veri b\u00fct\u00fcnl\u00fc\u011f\u00fcn\u00fc korur. PostgreSQL’in MVCC mekanizmas\u0131, izolasyonu sa\u011flaman\u0131n temel yoludur. MVCC sayesinde, farkl\u0131 i\u015flemler ayn\u0131 verinin farkl\u0131 s\u00fcr\u00fcmlerini g\u00f6rebilir, bu da kilitlenmeleri minimuma indirir ve e\u015fzamanl\u0131l\u0131\u011f\u0131 art\u0131r\u0131r. PostgreSQL, farkl\u0131 izolasyon seviyeleri sunar (Read Committed, Repeatable Read, Serializable) ve her birinin kendine \u00f6zg\u00fc avantajlar\u0131 ve performans etkileri vard\u0131r.<\/p>\n Durability (Kal\u0131c\u0131l\u0131k):<\/strong> Bir i\u015flem ba\u015far\u0131yla tamamland\u0131\u011f\u0131nda (commit edildi\u011finde), yapt\u0131\u011f\u0131 de\u011fi\u015fiklikler kal\u0131c\u0131 olarak depolan\u0131r ve sistem \u00e7\u00f6kse bile kaybolmaz. PostgreSQL bu kal\u0131c\u0131l\u0131\u011f\u0131 WAL (Write-Ahead Log)<\/strong> sayesinde garanti eder. Herhangi bir veri de\u011fi\u015fikli\u011fi, diske yaz\u0131lmadan \u00f6nce mutlaka WAL dosyas\u0131na kaydedilir. \u0130\u015flem commit edildi\u011finde, ilgili WAL kay\u0131tlar\u0131 diske yaz\u0131l\u0131r ve ancak bundan sonra de\u011fi\u015fikliklerin veri dosyalar\u0131na yaz\u0131lmas\u0131 garanti edilir. Bu sayede, bir sistem \u00e7\u00f6kmesi durumunda, WAL dosyalar\u0131 kullan\u0131larak veritaban\u0131 en son commit edilen duruma geri y\u00fcklenebilir.<\/p>\n \u00d6rnek: Para Transferi \u0130\u015flemi<\/strong><\/p>\n \u015eimdi bu kavramlar\u0131 bir para transferi senaryosu \u00fczerinden inceleyelim:<\/p>\n Bu \u00f6rnekte, PostgreSQL'in MVCC (Multi-Version Concurrency Control) mekanizmas\u0131, e\u015fzamanl\u0131l\u0131\u011f\u0131 art\u0131r\u0131rken, beraberinde bir \"yan etki\" getirir: \u00f6l\u00fc kay\u0131tlar (dead tuples)<\/strong>. Bu \u00f6l\u00fc kay\u0131tlar, veritaban\u0131 performans\u0131n\u0131 ve disk alan\u0131 kullan\u0131m\u0131n\u0131 do\u011frudan etkileyen \u00f6nemli bir fakt\u00f6rd\u00fcr. Bu nedenle, PostgreSQL'de vakumlama (VACUUM) i\u015flemi, sadece bir bak\u0131m g\u00f6revi olmaktan \u00f6te, sistemin sa\u011fl\u0131kl\u0131 \u00e7al\u0131\u015fmas\u0131 i\u00e7in kritik bir zorunluluktur.<\/p>\n MVCC'yi hat\u0131rlayal\u0131m: Bir kay\u0131t g\u00fcncellendi\u011finde veya silindi\u011finde, PostgreSQL eski kayd\u0131 hemen silmez. Bunun yerine, eski s\u00fcr\u00fcm\u00fc \"\u00f6l\u00fc\" olarak i\u015faretler ve yeni bir s\u00fcr\u00fcm olu\u015fturur veya kayd\u0131 sadece g\u00f6r\u00fcnmez hale getirir. Bu, ayn\u0131 veriye eri\u015fen farkl\u0131 i\u015flemlerin kendi anl\u0131k g\u00f6r\u00fcnt\u00fclerine g\u00f6re verinin farkl\u0131 s\u00fcr\u00fcmlerini g\u00f6rmesini sa\u011flar. Ancak, bu \u00f6l\u00fc kay\u0131tlar disk \u00fczerinde yer kaplamaya devam eder ve zamanla birikerek tablolar\u0131n ve indekslerin fiziksel boyutunu art\u0131r\u0131r. Bu duruma tablo \u015fi\u015fmesi (table bloat)<\/strong> veya indeks \u015fi\u015fmesi (index bloat)<\/strong> denir.<\/p>\n \u015ei\u015fme (bloat) bir\u00e7ok soruna yol a\u00e7ar:<\/p>\n \u0130\u015fte tam da bu nedenlerle VACUUM<\/strong> i\u015flemi hayati \u00f6nem ta\u015f\u0131r. VACUUM, veritaban\u0131ndaki \u00f6l\u00fc kay\u0131tlar\u0131 tarar ve bunlar\u0131n kaplad\u0131\u011f\u0131 alan\u0131 serbest b\u0131rak\u0131r. Ancak, Neyse ki, PostgreSQL'in Autovacuum<\/strong> s\u00fcreci, bu bak\u0131m i\u015flemini b\u00fcy\u00fck \u00f6l\u00e7\u00fcde otomatikle\u015ftirir. Autovacuum, arka planda s\u00fcrekli \u00e7al\u0131\u015fan bir s\u00fcre\u00e7tir. Belirli bir tablo \u00fczerinde belirli bir e\u015fi\u011fi a\u015fan say\u0131da g\u00fcncelleme veya silme i\u015flemi ger\u00e7ekle\u015fti\u011finde, Autovacuum otomatik olarak o tablo \u00fczerinde bir VACUUM i\u015flemi ba\u015flat\u0131r. Bu sayede, veritaban\u0131 y\u00f6neticilerinin manuel olarak VACUUM \u00e7al\u0131\u015ft\u0131rma ihtiyac\u0131 azal\u0131r ve \u015fi\u015fme sorunu kontrol alt\u0131nda tutulur. Autovacuum ayarlar\u0131 (\u00f6rne\u011fin Vaka analizi:<\/strong> Bir IoT (Nesnelerin \u0130nterneti) platformu d\u00fc\u015f\u00fcnelim. Binlerce sens\u00f6rden saniyede y\u00fczlerce veri kayd\u0131 geliyor ve bu veriler s\u00fcrekli g\u00fcncelleniyor (\u00f6rne\u011fin, sens\u00f6r\u00fcn son durumu). Bu senaryoda, Veritaban\u0131 performans\u0131n\u0131n kalbi, sorgular\u0131n ne kadar verimli \u00e7al\u0131\u015ft\u0131\u011f\u0131nda yatar. Yava\u015f bir sorgu, t\u00fcm uygulaman\u0131n yava\u015flamas\u0131na, kullan\u0131c\u0131 deneyiminin d\u00fc\u015fmesine ve gereksiz kaynak t\u00fcketimine yol a\u00e7abilir. PostgreSQL'de bir sorgunun neden yava\u015f \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 anlamak ve onu optimize etmek i\u00e7in en g\u00fc\u00e7l\u00fc ara\u00e7lardan biri PostgreSQL'in sorgu planlay\u0131c\u0131s\u0131 (query planner)<\/strong> veya optimize edicisi (optimizer)<\/strong>, bir SQL sorgusu ald\u0131\u011f\u0131nda, bu sorguyu en verimli \u015fekilde y\u00fcr\u00fctmek i\u00e7in olas\u0131 bir\u00e7ok farkl\u0131 stratejiyi de\u011ferlendirir. Hangi tablolar\u0131n hangi s\u0131rayla birle\u015ftirilece\u011fi, hangi indekslerin kullan\u0131laca\u011f\u0131, verilerin nas\u0131l filtrelenece\u011fi gibi kararlar\u0131 verir. Bu kararlar\u0131 verirken, tablo istatistikleri (kay\u0131t say\u0131s\u0131, s\u00fctunlardaki veri da\u011f\u0131l\u0131m\u0131 vb.), mevcut indeksler, bellek limitleri ve diskin I\/O maliyeti gibi fakt\u00f6rleri g\u00f6z \u00f6n\u00fcnde bulundurur. Bir \u0130ndekslerin Rol\u00fc:<\/strong> Sorgu optimizasyonunda indeksler hayati bir rol oynar. Do\u011fru indeksler, \u00d6rnek: Yava\u015f \u00c7al\u0131\u015fan Bir Sorguyu Optimize Etme<\/strong><\/p>\n Diyelim ki bir e-ticaret siteniz var ve a\u015fa\u011f\u0131daki sorgu \u00e7ok yava\u015f \u00e7al\u0131\u015f\u0131yor:<\/p>\n Bu indeksleri olu\u015fturduktan sonra PostgreSQL'in temel mimarisini, MVCC'yi, i\u015flem y\u00f6netimini ve sorgu optimizasyonunu anlad\u0131ktan sonra, performans\u0131 daha da art\u0131rmak ve sisteminizi daha dayan\u0131kl\u0131 hale getirmek i\u00e7in ileri d\u00fczey tekniklere ge\u00e7ebiliriz. Bu ipu\u00e7lar\u0131, \u00f6zellikle b\u00fcy\u00fck \u00f6l\u00e7ekli ve y\u00fcksek trafikli uygulamalar i\u00e7in kritik \u00f6neme sahiptir.<\/p>\n Her istemci ba\u011flant\u0131s\u0131 i\u00e7in PostgreSQL'in bir backend s\u00fcreci olu\u015fturdu\u011funu ve bunun belirli bir bellek ve CPU y\u00fck\u00fc getirdi\u011fini hat\u0131rlayal\u0131m. Y\u00fcksek e\u015fzamanl\u0131l\u0131\u011fa sahip uygulamalarda, her gelen istekle yeni bir veritaban\u0131 ba\u011flant\u0131s\u0131 a\u00e7\u0131p kapatmak, ciddi performans darbo\u011fazlar\u0131na yol a\u00e7ar. \u0130\u015fte burada Ba\u011flant\u0131 Havuzlama (Connection Pooling)<\/strong> devreye girer. Ba\u011flant\u0131 havuzlay\u0131c\u0131, \u00f6nceden belirli say\u0131da veritaban\u0131 ba\u011flant\u0131s\u0131n\u0131 a\u00e7\u0131k tutar ve gelen istekleri bu havuzdaki mevcut ba\u011flant\u0131lara y\u00f6nlendirir. Bir istek tamamland\u0131\u011f\u0131nda, ba\u011flant\u0131 kapat\u0131lmak yerine havuza geri d\u00f6ner ve ba\u015fka bir istek i\u00e7in yeniden kullan\u0131labilir hale gelir. Bu, ba\u011flant\u0131 a\u00e7ma\/kapama maliyetini ortadan kald\u0131r\u0131r, backend s\u00fcreci olu\u015fturma y\u00fck\u00fcn\u00fc azalt\u0131r ve genel sistem performans\u0131n\u0131 art\u0131r\u0131r. PgBouncer veya Odyssey gibi harici ba\u011flant\u0131 havuzlay\u0131c\u0131lar, bu i\u015flevi etkin bir \u015fekilde yerine getirir.<\/p>\n PostgreSQL'in varsay\u0131lan ayarlar\u0131 genellikle genel kullan\u0131m i\u00e7in iyi olsa da, belirli bir i\u015f y\u00fck\u00fc ve donan\u0131m konfig\u00fcrasyonu i\u00e7in optimize edilmeleri gerekir. Bu ayarlar\u0131n her biri, sisteminizin performans\u0131n\u0131 ve kararl\u0131l\u0131\u011f\u0131n\u0131 do\u011frudan etkiler. Do\u011fru ayarlar\u0131 bulmak, genellikle i\u015f y\u00fck\u00fcn\u00fcz\u00fc dikkatlice izlemeyi ve test etmeyi gerektirir.<\/p>\n Y\u00fcksek eri\u015filebilirlik (High Availability) ve felaket kurtarma (Disaster Recovery) i\u00e7in replikasyon (\u00e7o\u011faltma) vazge\u00e7ilmezdir. PostgreSQL iki ana replikasyon t\u00fcr\u00fc sunar:<\/p>\n Hangi replikasyon y\u00f6nteminin se\u00e7ilece\u011fi, ihtiya\u00e7lar\u0131n\u0131za (performans, esneklik, veri tutarl\u0131l\u0131\u011f\u0131 gereksinimleri) ba\u011fl\u0131d\u0131r.<\/p>\n \u00c7ok b\u00fcy\u00fck tablolarda (milyarlarca sat\u0131r), sorgu performans\u0131 d\u00fc\u015febilir ve bak\u0131m i\u015flemleri (VACUUM, INDEX olu\u015fturma) zorla\u015fabilir. Partisyonlama (Partitioning)<\/strong>, bu b\u00fcy\u00fck tablolar\u0131 daha k\u00fc\u00e7\u00fck, daha y\u00f6netilebilir par\u00e7alara (partisyonlara) b\u00f6lme tekni\u011fidir. Bu par\u00e7alar, kendi ba\u015flar\u0131na ayr\u0131 birer tablo gibi davran\u0131r ancak mant\u0131ksal olarak ana tablonun bir par\u00e7as\u0131d\u0131r. Partisyonlama, genellikle tarih aral\u0131\u011f\u0131na, ID aral\u0131\u011f\u0131na veya belirli bir s\u00fctun de\u011ferine g\u00f6re yap\u0131l\u0131r.<\/p>\n Partisyonlaman\u0131n faydalar\u0131:<\/p>\n PostgreSQL 10 ve sonras\u0131 s\u00fcr\u00fcmlerde yerel (native) partisyonlama deste\u011fi bulunmaktad\u0131r ve bu, b\u00fcy\u00fck tablolarla \u00e7al\u0131\u015f\u0131rken performans ve y\u00f6netim kolayl\u0131\u011f\u0131 a\u00e7\u0131s\u0131ndan devrim niteli\u011findedir. Bu ileri d\u00fczey teknikler, PostgreSQL kurulumunuzdan maksimum verim alman\u0131z\u0131 ve zorlu i\u015f y\u00fcklerinin \u00fcstesinden gelmenizi sa\u011flar. Ancak her birinin kendine \u00f6zg\u00fc karma\u015f\u0131kl\u0131klar\u0131 ve trade-off'lar\u0131 oldu\u011funu unutmamak, bilin\u00e7li kararlar vermek i\u00e7in \u00f6nemlidir.<\/p>\n PostgreSQL ile \u00e7al\u0131\u015f\u0131rken, sadece SQL sorgular\u0131n\u0131 bilmek yeterli de\u011fildir. Veritaban\u0131n\u0131n \"neden\" b\u00f6yle davrand\u0131\u011f\u0131n\u0131, alt\u0131nda yatan mimariyi, MVCC gibi e\u015fzamanl\u0131l\u0131k kontrol mekanizmalar\u0131n\u0131, ACID prensiplerini ve vakumlaman\u0131n \u00f6nemini anlamak, ger\u00e7ekten ustala\u015fman\u0131n anahtar\u0131d\u0131r. Bu makalede ele ald\u0131\u011f\u0131m\u0131z konular, benim i\u00e7in PostgreSQL'in zihin modelinin nihayet yerine oturmas\u0131n\u0131 sa\u011flayan temel ta\u015flar\u0131 olu\u015fturdu. Postmaster ve backend s\u00fcre\u00e7lerinin nas\u0131l \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131, WAL'\u0131n veri b\u00fct\u00fcnl\u00fc\u011f\u00fcndeki rol\u00fcn\u00fc, MVCC'nin e\u015fzamanl\u0131 okuma ve yazma i\u015flemlerini nas\u0131l sorunsuz hale getirdi\u011fini, \u00f6l\u00fc kay\u0131tlar\u0131n neden temizlenmesi gerekti\u011fini ve Bu bilgilerle donanm\u0131\u015f olarak, bir performans darbo\u011faz\u0131yla kar\u015f\u0131la\u015ft\u0131\u011f\u0131n\u0131zda, sorunun bir indeks eksikli\u011finden mi, yetersiz payla\u015f\u0131ml\u0131 bellekten mi, yoksa autovacuum'un do\u011fru \u00e7al\u0131\u015fmamas\u0131ndan m\u0131 kaynakland\u0131\u011f\u0131n\u0131 daha kolay te\u015fhis edebilirsiniz. Ba\u011flant\u0131 havuzlama, ince ayarl\u0131 1. PostgreSQL'in MVCC'si neden \u00f6nemlidir?<\/strong><\/p>\n MVCC (Multi-Version Concurrency Control), PostgreSQL'in ayn\u0131 anda birden fazla i\u015flemin veritaban\u0131na eri\u015fmesini sa\u011flayan temel mekanizmas\u0131d\u0131r. En \u00f6nemli \u00f6zelli\u011fi, okuma i\u015flemlerinin yazma i\u015flemlerini, yazma i\u015flemlerinin de okuma i\u015flemlerini genellikle engellememesidir. Bu, kilitlenmeleri azalt\u0131r, e\u015fzamanl\u0131l\u0131\u011f\u0131 art\u0131r\u0131r ve y\u00fcksek trafikli sistemlerde daha iyi performans ve yan\u0131t s\u00fcresi sa\u011flar. Her i\u015flem, verinin kendi anl\u0131k g\u00f6r\u00fcnt\u00fcs\u00fcn\u00fc g\u00f6rd\u00fc\u011f\u00fc i\u00e7in veri tutarl\u0131l\u0131\u011f\u0131 da korunur.<\/p>\n 2. E\u011fer 3. 4. PostgreSQL'de performans sorunlar\u0131n\u0131 nas\u0131l te\u015fhis ederim?<\/strong><\/p>\n Performans sorunlar\u0131n\u0131 te\u015fhis etmek i\u00e7in birka\u00e7 ad\u0131m izlenebilir:<\/p>\n 5. WAL dosyalar\u0131 ne i\u015fe yarar ve boyutunu nas\u0131l y\u00f6netirim?<\/strong><\/p>\n WAL (Write-Ahead Log) dosyalar\u0131, veritaban\u0131ndaki t\u00fcm de\u011fi\u015fikliklerin kal\u0131c\u0131 depolamaya yaz\u0131lmadan \u00f6nce kaydedildi\u011fi bir g\u00fcnl\u00fck sistemidir. PostgreSQL'in ACID \u00f6zelliklerinden Atomicity ve Durability'yi garanti eder. Bir sistem \u00e7\u00f6kmesi durumunda, WAL dosyalar\u0131 kullan\u0131larak veritaban\u0131 en son commit edilen duruma geri y\u00fcklenebilir. WAL dosyalar\u0131n\u0131n boyutunu ve say\u0131s\u0131n\u0131 postgresql.conf<\/code> ayarlar\u0131nda (\u00f6rne\u011fin shared_buffers<\/code>, wal_buffers<\/code>, max_connections<\/code>) do\u011fru de\u011fi\u015fiklikleri yapman\u0131z\u0131 sa\u011flar. Bu, sadece bir ayar\u0131 de\u011fi\u015ftirmek de\u011fil, sistemin i\u00e7 i\u015fleyi\u015fini anlayarak bilin\u00e7li bir karar vermek demektir.<\/p>\nMVCC: PostgreSQL’in Sihirli Dokunu\u015fu ve E\u015fzamanl\u0131l\u0131k Y\u00f6netimi<\/h2>\n
xmin<\/code> ve xmax<\/code>. xmin<\/code>, kayd\u0131n olu\u015fturuldu\u011fu i\u015flemin ID’sini, xmax<\/code> ise kayd\u0131n silindi\u011fi veya g\u00fcncellendi\u011fi i\u015flemin ID’sini (e\u011fer varsa) belirtir. Bir i\u015flem, bir kayd\u0131n kendisi i\u00e7in g\u00f6r\u00fcn\u00fcr olup olmad\u0131\u011f\u0131n\u0131 bu ID’lere bakarak belirler. E\u011fer kayd\u0131n xmin<\/code>‘i, i\u015flemin ba\u015flad\u0131\u011f\u0131 anl\u0131k g\u00f6r\u00fcnt\u00fcs\u00fcnden \u00f6nce commit edilmi\u015fse ve xmax<\/code>‘i hen\u00fcz commit edilmemi\u015fse veya hi\u00e7 yoksa, o kay\u0131t i\u015flem i\u00e7in g\u00f6r\u00fcn\u00fcrd\u00fcr. Aksi takdirde, ya hen\u00fcz olu\u015fturulmam\u0131\u015ft\u0131r ya da ba\u015fka bir i\u015flem taraf\u0131ndan silinmi\u015ftir.<\/p>\nVACUUM<\/code> ve AUTOVACUUM<\/code> s\u00fcre\u00e7leri devreye girer; bu \u00f6l\u00fc kay\u0131tlar\u0131 temizleyerek disk alan\u0131n\u0131 geri kazan\u0131r ve performans\u0131 korur.<\/p>\n\u0130\u015flem Y\u00f6netimi ve ACID Garantisi: Verileriniz G\u00fcvende mi?<\/h2>\n
BEGIN;\n\n-- Hesaptan para \u00e7ekme\nUPDATE hesaplar SET bakiye = bakiye - 100 WHERE id = 1;\n\n-- E\u011fer bakiye negatif olursa (tutarl\u0131l\u0131k ihlali), i\u015flemi geri al\n-- Bu genellikle bir CHECK k\u0131s\u0131tlamas\u0131 ile otomatik yap\u0131l\u0131r veya uygulama katman\u0131nda kontrol edilir.\n-- SELECT bakiye FROM hesaplar WHERE id = 1; -- Kontrol ama\u00e7l\u0131\n-- IF (bakiye < 0) THEN ROLLBACK; END IF;\n\n-- Di\u011fer hesaba para yat\u0131rma\nUPDATE hesaplar SET bakiye = bakiye + 100 WHERE id = 2;\n\n-- \u0130\u015flem ba\u015far\u0131l\u0131ysa kal\u0131c\u0131 hale getir\nCOMMIT;\n\n-- Herhangi bir ad\u0131mda hata olursa veya uygulama karar verirse\n-- ROLLBACK;<\/code><\/pre>\n<\/div>\nBEGIN<\/code> ile bir i\u015flem ba\u015flat\u0131l\u0131r. \u0130ki UPDATE<\/code> ifadesi, bu i\u015flemin atomik ad\u0131mlar\u0131d\u0131r. E\u011fer ikinci UPDATE<\/code> ba\u015far\u0131s\u0131z olursa (\u00f6rne\u011fin, id=2<\/code> bulunamazsa veya ba\u015fka bir k\u0131s\u0131tlama ihlal edilirse), ROLLBACK<\/code> komutu otomatik olarak \u00e7al\u0131\u015f\u0131r veya biz manuel olarak \u00e7al\u0131\u015ft\u0131rabiliriz. Bu durumda, id=1<\/code> hesab\u0131ndan \u00e7ekilen para da geri y\u00fcklenir. E\u011fer her iki UPDATE<\/code> de ba\u015far\u0131l\u0131 olursa, COMMIT<\/code> komutuyla t\u00fcm de\u011fi\u015fiklikler kal\u0131c\u0131 hale getirilir. Bu s\u00fcre\u00e7te, WAL, de\u011fi\u015fikliklerin kal\u0131c\u0131l\u0131\u011f\u0131n\u0131 garanti ederken, MVCC (Isolation) sayesinde ba\u015fka bir i\u015flem ayn\u0131 hesap bakiyesini sorgulad\u0131\u011f\u0131nda, bu transfer i\u015flemi commit edilene kadar eski bakiyeyi g\u00f6rmeye devam eder. Bu sayede, finansal i\u015flemler gibi kritik operasyonlarda veri b\u00fct\u00fcnl\u00fc\u011f\u00fc ve g\u00fcvenli\u011fi en \u00fcst d\u00fczeyde sa\u011flanm\u0131\u015f olur.<\/p>\nNeden Vakumlama Yapmal\u0131y\u0131z? \u00d6l\u00fc Kay\u0131tlar ve Performans \u0130li\u015fkisi<\/h2>\n
\n
VACUUM<\/code> komutu genellikle disk alan\u0131n\u0131 i\u015fletim sistemine hemen geri vermez; sadece bu alan\u0131 gelecekteki yeni kay\u0131tlar i\u00e7in yeniden kullan\u0131labilir hale getirir. E\u011fer disk alan\u0131n\u0131 i\u015fletim sistemine geri vermek ve tabloyu fiziksel olarak k\u00fc\u00e7\u00fcltmek isterseniz, VACUUM FULL<\/code> komutunu kullanman\u0131z gerekir. Ancak VACUUM FULL<\/code>, tabloyu kilitler ve t\u00fcm tabloyu yeniden yazar, bu da y\u00fcksek trafikli sistemlerde uzun s\u00fcreli kesintilere neden olabilir. Bu nedenle, genellikle VACUUM FULL<\/code> yerine daha hafif olan VACUUM<\/code> ve pg_repack<\/code> gibi ara\u00e7lar tercih edilir.<\/p>\nautovacuum_vacuum_scale_factor<\/code>, autovacuum_vacuum_threshold<\/code>) postgresql.conf<\/code> dosyas\u0131nda yap\u0131land\u0131r\u0131labilir ve i\u015f y\u00fck\u00fcn\u00fcze g\u00f6re ince ayar yap\u0131labilir.<\/p>\nUPDATE<\/code> i\u015flemleri \u00e7ok s\u0131k ger\u00e7ekle\u015fti\u011fi i\u00e7in \u00f6l\u00fc kay\u0131tlar h\u0131zla birikecektir. E\u011fer Autovacuum do\u011fru yap\u0131land\u0131r\u0131lmam\u0131\u015fsa veya devre d\u0131\u015f\u0131 b\u0131rak\u0131lm\u0131\u015fsa, sens\u00f6r verilerinin tutuldu\u011fu tablolar k\u0131sa s\u00fcrede \u015fi\u015fer, disk alan\u0131 dolar ve sorgu performanslar\u0131 dramatik \u015fekilde d\u00fc\u015fer. Yeni sens\u00f6r verileri eklemek veya mevcut verileri sorgulamak bile yava\u015flar. Bu durumda, Autovacuum'un aktif ve do\u011fru ayarlanm\u0131\u015f olmas\u0131, veritaban\u0131n\u0131n s\u00fcrekli olarak sa\u011fl\u0131kl\u0131 kalmas\u0131n\u0131 ve y\u00fcksek performansla \u00e7al\u0131\u015fmas\u0131n\u0131 garanti eder. Aksi takdirde, sistemin tamamen durma noktas\u0131na gelmesi ka\u00e7\u0131n\u0131lmaz olacakt\u0131r. Bu y\u00fczden, PostgreSQL'de vakumlama, sadece bir se\u00e7enek de\u011fil, veritaban\u0131 sa\u011fl\u0131\u011f\u0131 i\u00e7in temel bir gerekliliktir.<\/p>\nSorgu Optimizasyonu: EXPLAIN ile Veritaban\u0131n\u0131n \u0130\u00e7ine Bakmak<\/h2>\n
EXPLAIN<\/code><\/strong> komutudur. EXPLAIN<\/code>, veritaban\u0131 sisteminin bir sorguyu nas\u0131l \u00e7al\u0131\u015ft\u0131rmay\u0131 planlad\u0131\u011f\u0131n\u0131 g\u00f6steren bir \"sorgu plan\u0131\" \u00fcretir. Bu plan\u0131 yorumlayabilmek, PostgreSQL'in zihin modelinin \u00f6nemli bir par\u00e7as\u0131d\u0131r.<\/p>\nEXPLAIN<\/code> komutu, bu planlay\u0131c\u0131n\u0131n \"ne d\u00fc\u015f\u00fcnd\u00fc\u011f\u00fcn\u00fc\" bize g\u00f6sterir.<\/p>\nEXPLAIN<\/code> komutunu tek ba\u015f\u0131na kulland\u0131\u011f\u0131n\u0131zda, sorgunun tahmini maliyetini ve y\u00fcr\u00fctme plan\u0131n\u0131 g\u00f6r\u00fcrs\u00fcn\u00fcz. Ancak, sorgunun ger\u00e7ekte ne kadar s\u00fcrd\u00fc\u011f\u00fcn\u00fc ve hangi ad\u0131mlar\u0131n ne kadar kaynak t\u00fcketti\u011fini g\u00f6rmek i\u00e7in EXPLAIN ANALYZE<\/code><\/strong> kullanmak \u00e7ok daha faydal\u0131d\u0131r. EXPLAIN ANALYZE<\/code>, sorguyu ger\u00e7ekten \u00e7al\u0131\u015ft\u0131r\u0131r ve her bir ad\u0131m i\u00e7in ger\u00e7ek y\u00fcr\u00fctme s\u00fcresini, d\u00f6nd\u00fcr\u00fclen sat\u0131r say\u0131s\u0131n\u0131 ve di\u011fer istatistikleri g\u00f6sterir.<\/p>\nEXPLAIN ANALYZE<\/code> \u00e7\u0131kt\u0131s\u0131n\u0131 yorumlarken dikkat etmeniz gereken baz\u0131 anahtar terimler ve desenler \u015funlard\u0131r:<\/p>\n\n
\n
Seq Scan (Sequential Scan)<\/code>: Tablonun ba\u015ftan sona taranmas\u0131. Genellikle b\u00fcy\u00fck tablolarda yava\u015ft\u0131r ve indeks eksikli\u011fini veya yanl\u0131\u015f kullan\u0131m\u0131 i\u015faret edebilir.<\/li>\nIndex Scan<\/code>: Bir indeks kullanarak belirli kay\u0131tlara do\u011frudan eri\u015fim. \u00c7ok daha h\u0131zl\u0131d\u0131r.<\/li>\nIndex Only Scan<\/code>: \u0130ndeks, sorgunun istedi\u011fi t\u00fcm verileri i\u00e7eriyorsa, tabloya hi\u00e7 eri\u015filmeden sadece indeksten okuma yap\u0131l\u0131r. En h\u0131zl\u0131 y\u00f6ntemlerden biridir.<\/li>\nBitmap Heap Scan \/ Bitmap Index Scan<\/code>: Birden fazla indeksin kullan\u0131ld\u0131\u011f\u0131 veya bir indeksin \u00e7ok say\u0131da sat\u0131r d\u00f6nd\u00fcrd\u00fc\u011f\u00fc durumlarda kullan\u0131l\u0131r. \u0130ndekslerden bit e\u015flem olu\u015fturulur, sonra heap (tablo) taran\u0131r.<\/li>\nHash Join<\/code>, Merge Join<\/code>, Nested Loop Join<\/code>: Tablolar\u0131n birle\u015ftirilme stratejileri. Hangi birle\u015ftirme y\u00f6nteminin kullan\u0131ld\u0131\u011f\u0131, sorgunun performans\u0131n\u0131 b\u00fcy\u00fck \u00f6l\u00e7\u00fcde etkileyebilir.<\/li>\nSort<\/code>: Verilerin s\u0131ralanmas\u0131. B\u00fcy\u00fck veri k\u00fcmelerinde maliyetli olabilir.<\/li>\n<\/ul>\n<\/li>\n{start_cost}..{total_cost}<\/code>. start_cost<\/code> ilk sat\u0131r\u0131n d\u00f6nd\u00fcr\u00fclmesi i\u00e7in ge\u00e7en tahmini s\u00fcreyi, total_cost<\/code> ise t\u00fcm sat\u0131rlar\u0131n d\u00f6nd\u00fcr\u00fclmesi i\u00e7in ge\u00e7en tahmini s\u00fcreyi ifade eder. Daha d\u00fc\u015f\u00fck maliyet, genellikle daha iyi bir pland\u0131r.<\/li>\nEXPLAIN ANALYZE<\/code>'de (actual rows={count})<\/code> ger\u00e7ek sat\u0131r say\u0131s\u0131n\u0131 g\u00f6sterir. Tahmini sat\u0131r say\u0131s\u0131 ile ger\u00e7ek sat\u0131r say\u0131s\u0131 aras\u0131ndaki b\u00fcy\u00fck farklar, g\u00fcncel olmayan istatistikleri veya planlay\u0131c\u0131n\u0131n yanl\u0131\u015f tahminlerini i\u015faret edebilir.<\/li>\nEXPLAIN ANALYZE<\/code> ile her bir ad\u0131m\u0131n ger\u00e7ek y\u00fcr\u00fctme s\u00fcresi. Buradaki en y\u00fcksek de\u011ferler, performans darbo\u011fazlar\u0131n\u0131 g\u00f6sterir.<\/li>\nSeq Scan<\/code>'leri Index Scan<\/code>'lere d\u00f6n\u00fc\u015ft\u00fcrerek sorgu h\u0131z\u0131n\u0131 katlayabilir. Ancak her indeksin bir maliyeti vard\u0131r (disk alan\u0131, yazma i\u015flemleri s\u0131ras\u0131nda ek y\u00fck). Bu nedenle, indeksleri stratejik olarak kullanmak \u00f6nemlidir. PostgreSQL, B-tree, Hash, GiST, GIN gibi farkl\u0131 indeks tipleri sunar. En yayg\u0131n olan\u0131 B-tree'dir ve e\u015fitlik, aral\u0131k ve s\u0131ralama sorgular\u0131 i\u00e7in idealdir. GiST ve GIN ise daha karma\u015f\u0131k veri tipleri (geometrik veriler, tam metin arama) i\u00e7in kullan\u0131l\u0131r.<\/p>\nEXPLAIN ANALYZE SELECT * FROM urunler WHERE fiyat > 100 AND kategori = 'Elektronik' ORDER BY stok_adedi DESC;<\/code><\/pre>\n<\/div>\nEXPLAIN ANALYZE<\/code> \u00e7\u0131kt\u0131s\u0131, muhtemelen bir Seq Scan<\/code> ve ard\u0131ndan b\u00fcy\u00fck bir Sort<\/code> i\u015flemi g\u00f6steriyorsa, bu, fiyat<\/code> ve kategori<\/code> s\u00fctunlar\u0131nda indeks eksikli\u011fi oldu\u011funu veya stok_adedi<\/code> s\u00fctununda s\u0131ralama i\u00e7in uygun bir indeks olmad\u0131\u011f\u0131n\u0131 g\u00f6sterir. Optimizasyon i\u00e7in \u015funlar\u0131 yapabiliriz:<\/p>\n\n
kategori<\/code> s\u00fctununda bir indeks olu\u015fturmak: CREATE INDEX idx_urunler_kategori ON urunler (kategori);<\/code><\/li>\nfiyat<\/code> s\u00fctununda bir indeks olu\u015fturmak: CREATE INDEX idx_urunler_fiyat ON urunler (fiyat);<\/code><\/li>\nCREATE INDEX idx_urunler_kategori_fiyat ON urunler (kategori, fiyat);<\/code> (Sorgunun s\u0131ras\u0131na dikkat!)<\/li>\nORDER BY<\/code> i\u00e7in de bir indeks d\u00fc\u015f\u00fcnmek: CREATE INDEX idx_urunler_stok_adedi_desc ON urunler (stok_adedi DESC);<\/code><\/li>\n<\/ol>\nEXPLAIN ANALYZE<\/code> komutunu tekrar \u00e7al\u0131\u015ft\u0131rd\u0131\u011f\u0131m\u0131zda, muhtemelen Seq Scan<\/code> yerine Index Scan<\/code> veya Bitmap Index Scan<\/code> g\u00f6rece\u011fiz ve Actual Time<\/code> de\u011ferleri \u00f6nemli \u00f6l\u00e7\u00fcde d\u00fc\u015fecektir. Sorgu plan\u0131n\u0131 okumay\u0131 ve yorumlamay\u0131 \u00f6\u011frenmek, veritaban\u0131 performans\u0131n\u0131 art\u0131rmak i\u00e7in en de\u011ferli becerilerden biridir. Bu, sadece sorunlar\u0131 \u00e7\u00f6zmekle kalmaz, ayn\u0131 zamanda gelecekteki sorgular\u0131 daha verimli yazman\u0131za da yard\u0131mc\u0131 olur.<\/p>\n\u0130leri D\u00fczey \u0130pu\u00e7lar\u0131: PostgreSQL'den Maksimum Verim Almak<\/h3>\n
Ba\u011flant\u0131 Havuzlama (Connection Pooling) Neden Gereklidir?<\/h4>\n
postgresql.conf Ayarlar\u0131n\u0131n \u0130nce Ayar\u0131<\/h4>\n
postgresql.conf<\/code> dosyas\u0131, veritaban\u0131n\u0131n davran\u0131\u015f\u0131n\u0131 kontrol eden y\u00fczlerce parametre i\u00e7erir. En kritik olanlardan baz\u0131lar\u0131 \u015funlard\u0131r:<\/p>\n\n
shared_buffers<\/code>: Payla\u015f\u0131ml\u0131 bellek tamponlar\u0131n\u0131n boyutu. Genellikle RAM'in %25'i kadar ayarlanmas\u0131 \u00f6nerilir. \u00c7ok d\u00fc\u015f\u00fck olmas\u0131 disk I\/O'yu art\u0131r\u0131r, \u00e7ok y\u00fcksek olmas\u0131 i\u015fletim sistemi \u00f6nbelleklemesiyle \u00e7ak\u0131\u015fabilir.<\/li>\nwal_buffers<\/code>: WAL tamponlar\u0131n\u0131n boyutu. K\u00fc\u00e7\u00fck de\u011ferler WAL yazma performans\u0131n\u0131 d\u00fc\u015f\u00fcrebilir.<\/li>\nwork_mem<\/code>: Her bir sorgu ad\u0131m\u0131n\u0131n (\u00f6rne\u011fin s\u0131ralama, hash tablolar\u0131) disk yerine bellekte ne kadar alan kullanabilece\u011fini belirler. \u00c7ok d\u00fc\u015f\u00fck olmas\u0131, disk yazma\/okuma i\u015flemlerine neden olarak sorgular\u0131 yava\u015flat\u0131r.<\/li>\nmaintenance_work_mem<\/code>: VACUUM, CREATE INDEX gibi bak\u0131m i\u015flemleri i\u00e7in kullan\u0131lan bellek. Autovacuum'un verimlili\u011fi i\u00e7in \u00f6nemlidir.<\/li>\nmax_connections<\/code>: Maksimum e\u015fzamanl\u0131 ba\u011flant\u0131 say\u0131s\u0131. Uygulaman\u0131z\u0131n ve ba\u011flant\u0131 havuzlay\u0131c\u0131n\u0131z\u0131n ihtiya\u00e7lar\u0131na g\u00f6re ayarlanmal\u0131d\u0131r.<\/li>\nautovacuum<\/code> ilgili ayarlar: Autovacuum'un ne s\u0131kl\u0131kta ve hangi e\u015fiklerde \u00e7al\u0131\u015faca\u011f\u0131n\u0131 kontrol eder.<\/li>\n<\/ul>\nReplikasyon: Fiziksel (Streaming) ve Mant\u0131ksal Replikasyon Farklar\u0131<\/h4>\n
\n
Partisyonlama (Partitioning) B\u00fcy\u00fck Tablolar \u0130\u00e7in<\/h4>\n
\n
Sonu\u00e7<\/h2>\n
EXPLAIN ANALYZE<\/code> ile sorgu planlar\u0131n\u0131 yorumlaman\u0131n g\u00fcc\u00fcn\u00fc kavramak, sadece sorunlar\u0131 gidermeme de\u011fil, ayn\u0131 zamanda daha sa\u011flam, performansl\u0131 ve \u00f6l\u00e7eklenebilir uygulamalar geli\u015ftirmeme de yard\u0131mc\u0131 oldu.<\/p>\npostgresql.conf<\/code> parametreleri, uygun replikasyon stratejileri ve partisyonlama gibi ileri d\u00fczey teknikler, sisteminizin potansiyelini tam anlam\u0131yla ortaya \u00e7\u0131karman\u0131za olanak tan\u0131r. PostgreSQL, g\u00fc\u00e7l\u00fc ve esnek bir veritaban\u0131d\u0131r; onun i\u00e7 i\u015fleyi\u015fini anlamak, bu g\u00fcc\u00fc ve esnekli\u011fi en \u00fcst d\u00fczeyde kullanman\u0131z\u0131 sa\u011flar. Unutmay\u0131n, veritaban\u0131 y\u00f6netimi s\u00fcrekli bir \u00f6\u011frenme s\u00fcrecidir ve bu temel zihin modelini edinmek, bu yolculukta size sa\u011flam bir temel sunacakt\u0131r.<\/p>\nS\u0131k\u00e7a Sorulan Sorular (SSS)<\/h2>\n
VACUUM<\/code> \u00e7al\u0131\u015ft\u0131rmazsam ne olur?<\/strong><\/p>\nVACUUM<\/code> (veya otomatik olarak \u00e7al\u0131\u015fan Autovacuum) d\u00fczenli olarak \u00e7al\u0131\u015fmazsa, PostgreSQL'in MVCC mekanizmas\u0131 nedeniyle olu\u015fan \"\u00f6l\u00fc kay\u0131tlar\" (dead tuples) diskte birikir. Bu durum, tablolar\u0131n ve indekslerin gereksiz yere \u015fi\u015fmesine (bloat) neden olur. Sonu\u00e7 olarak, disk alan\u0131 israf edilir, sorgular daha fazla veri okumak zorunda kald\u0131\u011f\u0131 i\u00e7in yava\u015flar ve veritaban\u0131n\u0131n genel performans\u0131 d\u00fc\u015fer. En kritik risk ise Transaction ID Wraparound'dur, bu durum veritaban\u0131n\u0131 fel\u00e7 edebilir.<\/p>\nEXPLAIN<\/code> \u00e7\u0131kt\u0131s\u0131n\u0131 nas\u0131l yorumlamal\u0131y\u0131m?<\/strong><\/p>\nEXPLAIN<\/code> veya EXPLAIN ANALYZE<\/code> \u00e7\u0131kt\u0131s\u0131, PostgreSQL'in bir sorguyu nas\u0131l y\u00fcr\u00fctmeyi planlad\u0131\u011f\u0131n\u0131 (veya ger\u00e7ekte nas\u0131l y\u00fcr\u00fctt\u00fc\u011f\u00fcn\u00fc) g\u00f6steren bir sorgu plan\u0131d\u0131r. \u00c7\u0131kt\u0131da Seq Scan<\/code> (s\u0131ral\u0131 tarama) yerine Index Scan<\/code> (indeks tarama) g\u00f6rmek genellikle daha iyidir. Her d\u00fc\u011f\u00fcmdeki Cost<\/code> (maliyet) ve Actual Time<\/code> (ger\u00e7ek s\u00fcre) de\u011ferleri, sorgunun hangi ad\u0131mlar\u0131nda performans darbo\u011faz\u0131 ya\u015fand\u0131\u011f\u0131n\u0131 g\u00f6sterir. Y\u00fcksek maliyetli veya uzun s\u00fcren ad\u0131mlar, optimizasyon gerektiren yerlerdir. Ayr\u0131ca, tahmin edilen sat\u0131r say\u0131s\u0131 (rows<\/code>) ile ger\u00e7ek sat\u0131r say\u0131s\u0131 (actual rows<\/code>) aras\u0131ndaki farklar, g\u00fcncel olmayan istatistiklere i\u015faret edebilir.<\/p>\n\n
EXPLAIN ANALYZE<\/code> kullan\u0131n:<\/strong> Yava\u015f sorgular\u0131 tespit edin ve sorgu planlar\u0131n\u0131 analiz edin.<\/li>\npg_stat_statements<\/code> mod\u00fcl\u00fcn\u00fc kullan\u0131n:<\/strong> En \u00e7ok zaman harcayan sorgular\u0131 ve \u00e7a\u011fr\u0131 say\u0131lar\u0131n\u0131 belirleyin.<\/li>\npostgresql.conf<\/code> ayarlar\u0131n\u0131 kontrol edin:<\/strong> shared_buffers<\/code>, work_mem<\/code>, max_connections<\/code> gibi parametrelerin do\u011fru yap\u0131land\u0131r\u0131ld\u0131\u011f\u0131ndan emin olun.<\/li>\npg_stat_all_tables<\/code> gibi g\u00f6r\u00fcn\u00fcmlerle tablolar\u0131n ne s\u0131kl\u0131kta vakumland\u0131\u011f\u0131n\u0131 kontrol edin.<\/li>\npg_locks<\/code> g\u00f6r\u00fcn\u00fcm\u00fc ile aktif kilitleri ve bekleyen i\u015flemleri tespit edin.<\/li>\n<\/ul>\npostgresql.conf<\/code> dosyas\u0131ndaki wal_segment_size<\/code>,