Postgres Advanced Server Performans

EnterpriseDB size ve kurumunuza PostgreSQL veri tabanlarını kullanabilmeniz, verinizi PostgreSQL’e taşıyabilmeniz (göç) için; veri koruması, yedekleme, performans geliştirme ve felaket yönerimi gibi üst düzey özellikler için özel araçlar sağlamaktadır.

Burada sadece bir kısım öne çıkan PAS Performans geliştirmeleri ele alınmıştır.

InfiniteCache ile Sınırsız Bellek

Veritabanı başarımında en kilit noktalardan birisi paylaşılan tampon bellek miktarını sağlayan sistem belleği miktarıdır. İstenen tüm veri önce paylaşımlı tampon belleğe atılarak okunmalı ve sonra işlenmelidir. Zira paylaşımlı tampon bellek üzerindeki veriyi işlemek disk üzerindeki veriyi işlemeye göre kat kat hızlıdır.

EnterpriseDB tarafından geliştirilen InfiniteCache sayesinde Postgres Advanced Server’a sınırsız bellek sağlamak mümkün olmaktadır. InfiniteCache ile veritabanı sistemleri mevcut sunucu dışındaki sistemlere erişerek onların üzerindeki bellekleri tampon bellek olarak kullanabilir.

Veritabanı performansını nasıl arttırabileceğinizi keşfedin!

InfiniteCache ile sınırsız bellek mimarisine adım atın...

Sorgu Optimizasyon İpuçları

Query Optimizer Hints yazılım geliştiricilerinin, dahili SQL Optimizasyoncusuna optimizasyon yaparken nasıl davranacağına yönelik katkıda bulunmalarını sağlar. Zira bazı durumlarda verinin yapısını yazılım geliştirici bilir ama SQL Optimizasyoncusu bilmez. Örneğin yazılımcı bir index’in o sorgu için daha seçici olduğunu biliyor olabilir.

Hazır sorguların (prepared query), işlem süresinde meydana gelen tutarsızlık PostgreSQL dünyasında yaygın bir senaryodur. Daha önce planlanan hazır sorgu ilk çalıştırıldığından sonraki çalıştırılmalarında, sorgu için hazırlanmış olan plan artık optimal durumda olmayabilir. Örneğin, tablolar küçükken hazırlanmış olan sorgu planı, tablolar zaman içinde büyüyünce optimizasyonunu kaybetmiş olabilir. PostgreSQL küçük tablolarda sıralı tarama yaparken, büyük tablolarda dizin (index) taramaları tercih eder.

Ticari bir veritabanı uygulamasındaki günlük işlem tablosunu ele alalım. Her günün başlangıcında tabloda sadece birkaç yüz satır veri varken, günün sonuna doğru tablo milyonlarca satır veriye sahip oluyor olabilir. Dolayısı ile sabah yapılmış olan sorgu planı kısa zaman içinde optimal halinden çıkıp hatalı hale gelebilir.

PREPARE foo(int) AS
   SELECT */+ INDEX(emp emp_pk) */ empno, ename dname
   FROM emp.dept
   WHERE emp.deptno = dept.deptno
   AND empno = $1
EXECUTE foo(7369);

Bunu farkeden veya öngören yazılımcı, Postgres’in varsayılan sorgu planının üzerini çizip, sorgunun kendi sağladığı plan ile işletilmesini zorlayarak, planların her daim optimal çalışmasını sağlayabilir.

Böyle durumlarda optimizasyon ipucu sorgunun içine soldaki şekilde eklenebilir. Yukarıdaki sorgu sağ yukarıda gösterilen sorgu planı ile çalışacaktır ve normalde emp tablosunda sıralı bir tam tarama yapacak iken, emp_pk dizinini (index) kullanacaktır.

Sorguların yazılımın ihtiyaçlarına uygun plan ile çalıştırılması ve optimizasyonu için birçok ipucu mevcuttur. Sorgu bazı satırları hızlıca getirmek üzere belirli bir plan ile işletilmek üzere yönlendirilebilir veya belirli bir join kullanmak üzere optimize edilebilir.

Sorgu Optimizasyon İpuçları yazılım geliştiricilerine ek esneklikler ve sorgu işletim esnasında ek kontrol gücü sağlayarak, uygulamanın her daim belirli, kararlı bir performansı yakalamasını sağlar.

Sorgu ipucu Açıklama
ALL_ROWS Sonuç kümesinden tüm satırları getirmek üzere optimize
CHOOSE Varsayılan durum. Sonuç kümesinden belirli miktarda satırı getirmek üzere herhangi bir optimizasyon içermez
FIRST_ROWS Sonuç kümesinden ilk satırı getirmek üzere optimize
FIRST_ROWS_10 Sonuç kümesinden ilk 10 satırı getirmek üzere optimize
FIRST_ROWS_100 Sonuç kümesinden ilk 100 satırı getirmek üzere optimize
FIRST_ROWS_1000 Sonuç kümesinden ilk 1000 satırı getirmek üzere optimize
FIRST_ROWS(n) Sonuç kümesinden ilk [n] satırı getirmek üzere optimize
FULL(table) Tabloda sıralı bir tam tarama gerçekleştirir
INDEX(table[ index] [...]) İlişkiye erişim için tablodaki [index]’i kullanır
NO_INDEX(table [ index] [...]) İlişkiye erişim için tablodaki [index]’i kullanmaz
USE_HASH(table [...]) Tablosunun join niteliklerini kullanarak oluşturulan bir hash’i kullanır
NO_USE_HASH(table [...]) Tablosunun join niteliklerini kullanarak oluşturulan bir hash’i kullanmaz
USE_MERGE(table [...]) Join tablosu için birleştirilmiş sıralama kullanır
NO_USE_MERGE(table [...]) Join tablosu için birleştirilmiş sıralama kullanmaz.
USE_NL(table [...]) Tablo için içiçe geçmiş (nested loop) döngü kullanır
NO_USE_NL(table [...]) Tablo için içiçe geçmiş (nested loop) döngü kullanmaz

EDB*Loader ile Hızlı Veri Aktarımı

EDB*Loader’ın text dosyaları Postgres veritabanına alırken performansı artırıcı özellikleri mevcuttur.

PostgreSQL’in standardı COPY komutudur, ancak yükleme zamanını artıran önemli limitleri vardır. Bunlardan ilki, sabit genişlikli dosyaları alırken bunların önce ayrılmış (örneğin virgül ile) dosya haline getirilmesi gerekliliğidir.

“COPY” komutunun diğer önemli limitasyonu ise hata kontrolünün olmamasıdır. “COPY” komutu kullanıldığında, dosyadaki tek bir satır hatalı ise geri kalanların aktarımının da yapılamaması, dosyanın incelenerek yeniden düzeltimesinin gerekliliğidir.

EDB*Loader ise bu satırları gözardı edilenler olarak farklı bir dosyaya atar ve sadece bu satırların düzeltilerek yeniden yüklenmesini sağlar. Diğer satırlar ise sisteme alınır.

Direct Path, Paralel Çalışma ve Append

Diğer taraftan EDB*Loader’ın sağladığı en önemli avantaj yükleme performansını çok fazla artıran “Direct Path” yüklemesidir. Direct Path yüklemesi, toplu dosya işleme aktarma performansını önemli ölçüde etkileyen, yavaşlatan bazı işlemlerin bypass edilmesini sağlarken, kullanıcıya hepsini işlet veya hata varsa hiçbiri alma seçeneğini de sunar.

Direct Path yüklemesi işlenen satırları ele alarak, bir kontrol dosyasında sunulan sütun özelliklerine göre ayrıştırır. Ayrıştırdığı veriyi daha sonra sütün veri tipine çevirerek dahili bir veri yapısı oluşturup bunu doğrudan Postgres veri bloğu formatına çevirerek içeri alır.Doğrudan veri dizinine yazılan bu işlenmiş veri bloğu sayesinde yüksek içeri alma performansı sağlanır.

PAS 9.0 sürümünden itibaren EDB*Loader’a aynı tabloya birden fazla dosyadan aynı anda içeri aktarım yeteneği kazandırılmış ve böylece içeri aktarım performansında çok daha ileri kazanımlar sağlanmıştır. Paralel yükleme özelliği artık EDB Migration Araçları içerisine de alınmıştır ve bu sayede veri göçü işlemlerinin daha hızlı yapılması sağlanmıştır.

EDB*Loader ile içeri aktarımlar sırasında kullanabileceğiniz APPEND seçeneği sayesinde hedef tablonun boş olmasını da gerektirmez.


Toplu SQL İşlemleri

Yüksek sayıda satır içeren devasa sonuç kümelerini getiren SQL komutları mümkün olan en performanslı şekilde çalışamayabilirler. Bunun sebebi, veritabanı motoru ile prosedürel dil kodu arasında bu sonuç kümelerinin transferi sırasında sürekli oluşan bağlam (context) değişimleridir.

Bu verimsizlik sonuç kümelerinin belleğe aktarımı ve istemcinin sonrasında erişimi sağlanarak hafifletilebilir. Postgres Advanced Server’ın SPL olarak adlandırdığımız saklı yordam dili (stored procedure language), BULK COLLECT özelliği sayesinde büyük sonuç kümelerinin bellek içi bir kolleksiyonda toplanmasını sağlar.

Bu tür büyük imleçleri işleyen PL/pgSQL fonksiyonlarının BULK COLLECT kullanan SPL fonksiyonlarına çevrilmesiyle performans 100% ve üzerinde arttırılabilir.

Dizin Danışmanı

Postgres Advanced Server içerisinde gelen bir başka performans analiz aracı Index Advisor (Dizin Danışmanı)’dır.

Index Advisor, veritabanı uzmanlarına ve yazılım geliştiricilerine, bir veya birden fazla SQL ifadesini analiz ederek daha performanslı veri tarama için oluşturulması gereken yeni dizinler (index) ile ilgili tavsiyelerde bulunur. Bunu birden fazla sütunu içeren bileşik dizinler için de yapabilmektedir.

Index Advisor tüm veri değiştirme (INSERT, UPDATE, DELETE) ve SELECT ifadelerinde devreye girer.


Index Advisor tanı raporunda şu bilgilere de yer verir:

  • Yeni oluşturulacak dizinler sayesinde performans artışları
  • Yeni dizinlerin boyutu
  • Yeni dizinlerin oluşturulmasında kullanılacak tanımlama bilgisi (DDL)

SQL Profilcisi

Postgres Advanced Server, Postgres Enterprise Manager içerisinde gelen bir SQL Profiler içermektedir.

SQL Profiler seçilen veritabanını inceleyerek buraya gelen SQL komutlarının raporunu çıkartır. Bir sorgu profili raporu veritabanı uzmanlarına sistemlerinin veya yazılımlarının performansını artırmada en büyük yardımcılardan birisidir.

Sorgu profil raporları iki temel amaç için kullanılabilir:

  • İşletimi uzun süren sorguların tespit edilerek yeniden optimize edilmesi ile performans artışı
  • Sürekli tekrarlanan SQL komutları veya zaman alıcı işlemler içeren fonksiyonların tespiti ve optimizasyonu ile performans artışı

Sonuç raporundaki SQL sorguları, Toplam işletim süresi, Ortalama İşletim Süresi, SQL komutunun işletim tekrarı gibi özelliklere göre artan/azalan şekilde sıralanabilmektedir. SQL komutları ayrıca, sorgu tiplerine (INSERT, UPDATE, SELECT vb.) göre de filtrelenebilmektedir.

Bu verimsizlik sonuç kümelerinin belleğe aktarımı ve istemcinin sonrasında erişimi sağlanarak hafifletilebilir. Postgres Advanced Server’ın SPL olarak adlandırdığımız Saklı Yordam Dili (stored procedure language), BULK COLLECT özelliği sayesinde büyük sonuç kümelerinin bellek içi bir kolleksiyonda toplanmasını sağlar.

Bu tür büyük imleçleri işleyen PL/pgSQL fonksiyonlarının BULK COLLECT kullanan SPL fonksiyonlarına çevrilmesiyle performans 100% ve üzerinde arttırılabilir!

Kod Profilcisi

Kod profili çıkartma işlemi bir veya daha fazla prosedürel veritabanı kod parçasının çalıştırılarak performans kıyaslamasının yapılması ve işletim esnasında nerede, ne kadar zaman harcandığının çözümlenmesidir.

Profilleme ile genellikle şu soruların cevapları aranır:

  • İşletim süresinin büyük kısmı hangi kod parçası tarafından işgal ediliyor?
  • Bir döngü kaç kere işletilmekte?
  • Hangi kodlama yaklaşımı istenen sonucu vermekte daha performanslı?

Profilleme yapmadan, yukarıdaki gibi soruların cevapları sadece tahmine dayalı olur. Veritabanı ve yazılım uzmanları ellerinde güçlü araçlar yoksa, genellikle kod parçalarının aralarına bazı ifadeler yerleştirmek, cevap süresini yazdırmak gibi ilkel profilleme teknikleri kullanırlar. Bunlara ilkel dememizin sebebi bu şekilde bir çalışma zahmetli ve zaman alıcı olduğu kadar, hataya da açıktır. Çoğunlukla bir ava benzer, oltayı atar ve beklersiniz, balık yoksa başka bir yere olta atmanız gerekir. Code Profiler ile bu sıkıntıları yaşamazsınız.

Özellikle Oracle DBMS_PROFILER kullanıcıları Code Profiler kullanırken kendilerini çok rahat hissedecekler.

Bir veya daha fazla saklı yordamı veya fonksiyonu profillemek için veritabanı veya yazılım uzmanının yapması gerekenler kısaca:

  • Profiler’ı çalıştırıp bir oturum adı vermek:
    (EXEC dbms_profiler.start_profiler(<procedure name’);)
  • Profillenecek kodu çalıştırmak
  • Profillemeyi durdurup istatistiksel veriyi analiz etmek:
    (EXEC dbms_profiler.stop_profiler;)

Code Profiler tarafından üretilen tanılama raporu işletme süreleri, I/O bilgileri, bekleyen olaylar, işletme sayıları ve daha birçok yardımcı bilgiyi içermektedir.


DynaTune Dinamik Optimizasyon

DynaTune™ sunucu donanımına bağlı olarak veritabanı iş yükünün doğru optimizasyonun sağlanması için kullanılır. DBA’lerin en çok sıkıntı yaşadıkları konu olan performans optimizasyonunu en basite indirgeyerek size yardımcı olur.

Popüler veritabanı uygulamaları performans optimizasyonu yarışında “ne kadar çok ince ayarın varsa o kadar iyisin” anlayışı ile hareket etmekte ve her sistem değişkenini bir ayar dügmesi haline getirmektedirler. Buna karşın bir DBA olarak bunca ince ayarın tamamını bilmek, hangi durumlarda kullanılacağını öğrenmek ve en önemlisi, her ince ayarın etkisini ölçmek saç baş yoldurabilecek bir hal alabilmektedir. Bu sebeple bir çok veritabanı iş yükü doğru optimize edilmemiş şekilde çalışmaya devam etmektedir. Veritabanı uzmanları, DBA eğitimi veren üstadlar bilirler ki, en iyi yaklaşım önce en çok performans getirisi sağlayacak temel bir ayar seti ile başlamak ve sonra gerekirse ince ayarlara geçmektir.

DynaTune, Postgres veritabanı optimizasyonundaki belirsizlikleri ortadan kaldırır.

Geniş bir donanım yelpazesi ve veri setleri üzerinde yapılmış bir çok test sonucuna göre oluşturulmuş sofistike, akıllı bir algoritma sayesinde birçok veritabanı optimizasyon ayarını kullanıcıdan alınacak cevaba bağlı olarak iki temel set üzerinde sadeleştirmektedir.

Kurulum esnasında sorulan birkaç soru ile beraber daha başlangıçta, ortalamadan daha iyi bir performans optimizasyonuna sahip olursunuz. Daha sonra kullanım esnası verilerine bağlı olarak daha ince optimizasyon ayarları yapabilirsiniz. Böylece küçük performans getirisi sağlayacak ince ayarlarla uğraşarak ayarların içinde boğulmayı önleyerek, bu önemli olduğu kadar karmaşık işi basite indirger.

DynaTune, donanım arttırdığınızda veya değiştirdiğinizde, örneğin bellek artırımı yaptığınızda, otomatik olarak mevcut ayarları yeniden kalibre eder ve veritabanı iş yükünün önceki ile uyumlu şekilde donanımı kullanmasını sağlar.


Asenkron Sonuç Getirme

Asenkron Sonuç Getirme (Asynchronous Pre-Fetch), Postgres Advanced Server’ın Linux sürümlerinde olan ve ucuz disk dizilerini (RAID) performanslı kullanma yöntemidir.

RAID donanım kullanıldığında, veritabanı verisi birçok disk üzerinde farklı tekniklerle dağıtık olarak bulundurulabilir; striping, mirroring veya ikisinin kombinasyonları.

Asenkron Sonuç Getirme özelliği olmadığında, disk I/O sıra düzenli olarak kullanılır. Yani bir veri parçası bir disk üzerinden alınırken diğer disklere erişim sağlanmaz, sıra ile ilgili disklerden veri parçalarına erişim sağlanır. Oysa Asenkron Sonuç Getirme devreye alındığında aynı anda birçok disk üzerinden veri alımı sağlanarak sonuç çok daha hızlı biçimde oluşturulabilmektedir.

Asenkron Sonuç Getirme birden fazla diskin kullanıldığı ortamlarda performansı bir anda zıplatır.

EnterpriseDB Postgres Advanced Server Asenkron Sonuç Getirme özelliği ile sıradan indexleri kullanırken dahi performans artışı sağlamaktadır, özellikle:

  • eğer index çok fazla kümelendirilmiş (clustered) ise - yani satırlar indexle aynı şekilde sıralanmamış ise,
  • eğer index dar (bir veya bir iki sütundan oluşturulmuş) ise,
  • Sonuç kümesinden yüksek miktarda satır dönecekse