Firebird Veritabanını Hızlandırmanın 45 Yolu

Burada Firebird veritabanı için farklı alanlardaki performans ipuçlarının listesini bulabilirsiniz - donanım/işletim sistemi ve Firebird yapılandırma ayarlarından SQL optimizasyon önerilerine kadar. Bu liste Firebird’ün nasıl optimize edileceğine dair eksiksiz bir başvuru kaynağı değildir ve yürütme planları, işlem yönetimi ve sorgu performans istatistikleri gibi Firebird’ün işleyişinin temellerini anladığınızı varsayar.

Lütfen bu ipuçlarını dikkatli bir şekilde uygulayın ve üretime almadan önce etkilerini doğrulayın.

Şirketimiz (IBSurgeon) kapsamlı veritabanı performans optimizasyonu hizmeti sunmaktadır.

1. Veritabanını SSD’ye koyun

Veritabanınızı SSD’ye koyun. SSD sürücü, geleneksel sürücülere göre çok daha iyi rastgele IO sağlar. Rastgele IO, büyük veritabanı dosyasına dağılmış verilerin okunması ve yazılması için kritik öneme sahiptir - veritabanı işlemlerinin çoğunluğu yoğun paralel rastgele IO gerektirir.

2. RAID 10 kullanın

RAID1 veya RAID5 kullanıyorsanız, RAID10’u düşünün - %15-25 daha hızlıdır.

3. BBU’yu kontrol edin

RAID denetleyicisi kullanıyorsanız, Yedekleme Batarya Ünitesi’nin (BBU) kurulu ve çalışır durumda olduğunu kontrol edin - bazı satıcılar varsayılan olarak BBU sağlamaz. BBU olmadan denetleyici önbelleği devre dışı bırakır ve RAID çok yavaş çalışır, hatta normal SATA sürücülerden bile daha yavaş. Genellikle BBU durumunu RAID yapılandırma aracında kontrol edebilirsiniz.

4. Yazma önbelleğini write-back olarak ayarlayın

BBU kurulu bir RAID denetleyicisi (ve UPS’li bir sunucu) kullanıyorsanız, önbelleğinin write-back (write-through değil) olarak ayarlandığını kontrol edin. «Write-back» denetleyicinin yazma önbelleğini etkinleştirir.

5. Okuma önbelleğini etkinleştirin

RAID denetleyicisi kullanıyorsanız, okuma önbelleğinin etkinleştirildiğini kontrol edin.

6. Disk alt sistemini kontrol edin

Sürücülerinizi bozuk bloklar ve diğer donanım sorunları (aşırı ısınma dahil) açısından kontrol edin. Donanım sorunları IO performansını önemli ölçüde düşürebilir ve veritabanı bozulmalarına yol açabilir.

7. Firebird 2.5’te SuperClassic veya Classic kullanın

Çok sayıda bağlantıyla Firebird 2.5 SuperServer kullanıyorsanız, SuperClassic veya Classic kullanmayı deneyin; CPU’nun tüm çekirdeklerini kullanarak daha iyi ölçeklenebilirler.

8. Firebird 3’te SuperServer 3.0 kullanın

2.5’te Classic veya SuperClassic kullanıyorsanız, Firebird 3.0 SuperServer’a geçişi düşünün; artık birden fazla çekirdek kullanabilir ve bunu paylaşılan önbelleğin avantajlarıyla birleştirebilir.

9. Sayfa arabelleği önbelleğini artırın

Sayfa arabelleği önbelleğinin boyutunu (DefaultDBCachePages parametresi) varsayılan değerlerden artırın. 2.5 SuperServer için 10000 sayfa, 3.0 SuperServer için 50000 sayfa, Classic ve SuperClassic için 256 ila 2048 sayfa öneriyoruz. Ancak, sayfa arabelleği önbellek değerini çok yüksek ayarlamayın - önbellek senkronizasyonunun bir maliyeti vardır ve bu değeri ayarlayarak tüm veritabanını RAM’e koyma fikri işe yaramayacaktır. Önceden optimize edilmiş Firebird yapılandırma dosyalarını burada kullanın: /tr/optimized-firebird-configuration/

10. Sıralama işlemleri için bellek boyutunu artırın

firebird.conf içindeki TempCacheLimit parametresinin değerini artırın - sıralama için geçici alanın önbellek boyutunu belirtir. Varsayılan değerler çok düşüktür (Classic için 8Mb ve SuperServer için 64Mb), Classic için en az 64Mb ve SuperServer ile SuperClassic için 1Gb kullanın. Yine, #9’daki optimize edilmiş yapılandırma dosyalarını kullanın.

11. Forced Writes’ı Off yapın (dikkatli bir şekilde!)

Yoğun ekleme veya güncelleme etkinliğiniz varsa (HQbird MonLogger ile kontrol edebilirsiniz, ayrıntılar için HQbird User Guide sayfa 60’a bakın) ve donanım arızalarına karşı korunmak için UPS ve replikasyon kuruluysa, Forced Writes ayarını OFF yapmayı düşünün; yazma işlemlerinin hızını 3 kata kadar artırabilir.

12. Classic/SuperClassic için karma yuva sayısını artırın

Classic ve SuperClassic için LockHashSlots parametresinin değerini varsayılan 1009’dan büyük bir asal sayıya (örneğin 30011) artırın; bu, dahili kilitleme mekanizmasındaki kuyrukları azaltacaktır.

13. Super Server 2.5 için CPU Affinity kullanın

SuperServer 2.5 kullanıyorsanız, CPUAffinity parametresini kullanımdaki veritabanı sayısına eşit bir değere ayarlayın: 2.5’teki SuperServer, belirli veritabanları için istekleri işlemek üzere farklı CPU çekirdeklerini kullanabilir.

14. Geçici alan için hızlı sürücü kullanın

firebird.conf içindeki TempDirectory parametresinin ilk bölümünü hızlı diske - SSD veya RAM sürücüsüne - ayarlayın. Bu, büyük sıralamaların süresini azaltacaktır - örneğin veritabanı geri yüklenirken.

15. Veritabanı yedeklerini başka bir sürücüde saklayın

Veritabanı yedeklerini ayrılmış fiziksel sürücüde (RAID) saklayın. Bu, yedekleme sırasında okuma ve yazma IO’sunu ayıracak, yedekleme hızını artıracak ve ana sürücü üzerindeki yükü azaltacaktır. Bu, özellikle kullanıcılar veritabanıyla çalışırken yedek alındığında önemlidir. Firebird için donanım yapılandırması hakkında daha fazla ayrıntıyı " Firebird Hardware Guide" içinde bulabilirsiniz.

16. Toplu eklemeler için dizinleri devre dışı bırakın

Çok sayıda kayıt eklerseniz veya güncellerseniz (tablonun %25’inden fazlası), kayıtların eklendiği tablo için dizinleri devre dışı bırakın ve ekleme veya güncellemeden sonra yeniden etkinleştirin. Dizin yeniden oluşturma işlemi, dizinin birçok güncellemesinden daha hızlı olabilir.

17. Hızlı eklemeler için Global Temporary Tables kullanın

Ekleme ve güncellemeleri hızlandırmak için, büyük kayıt kümelerinin toplu eklenmesi için Global Temporary Tables kullanın ve ardından kayıtları kalıcı tabloya aktarın. Kayıtları GTT’ye eklemek, önceden işlemek ve ardından kalıcı tabloya taşımak çok etkili olabilir.

18. Gereksiz dizinlerden kaçının

Yoğun ekleme ve güncelleme yapılan tablolar için daha az dizin kullanın. Her dizin, ekleme, güncelleme, silme ve çöp toplama işlemleri için önemli ölçüde ek yük getirir - her dizin için tek bir kayıt eklenirken/güncellenirken/silinirken/temizlenirken 3-4 ek sayfa okuma ve yazma olabilir.

19. UDF’leri gömülü fonksiyon çağrılarıyla değiştirin

UDF çağrılarını gömülü fonksiyon çağrılarıyla değiştirin. Firebird’ün son sürümlerinde, daha önce yalnızca UDF kütüphanelerinde bulunan işlevselliği sunan birçok gömülü fonksiyon eklenmiştir. Bu tür fonksiyonları mümkün olduğunca değiştirin, çünkü gömülü fonksiyonlar UDF’lerden 3 kata kadar daha hızlı çalışır.

20. Okuma işlemleri için salt okunur işlemler kullanın

Kaydı değiştirmeyen işlemler (yani SELECT’ler) için izolasyon modu = read committed olan salt okunur işlemler kullanın. Bu tür işlemler, kayıt sürümlerini çöp toplamadan tutmaz ve süresiz olarak çalışabilir: veritabanı performansını etkilemezler.

21. Kısa yazma işlemleri kullanın ve TÜM uzun süreli işlemlerden kurtulun

Kısa yazılabilir işlemler kullanın (INSERT/UPDATE/DELETE işlemleri için).

Yazılabilir işlem ne kadar kısa olursa o kadar iyidir. Kısa işlemler, çöp toplamadan orantılı olarak uzun süreli işlemlerden daha az sayıda kayıt sürümü tutar. Ne yazık ki, tek bir uzun süreli işlem bile (örneğin, açık bırakılan geliştirme aracından) diğer tüm kısa yazılabilir işlemlerin iyi etkisini bozabilir. Bu nedenle, uzun süreli işlemleri izlemeniz ve kaynak kodundaki uygun yerleri düzeltmeniz gerekir. Firebird veritabanındaki en eski aktif işlem hakkında uyarılar almak için HQbird DataGuard aracını (hangi uygulamaların başlattığı, hangi IP adresi, başlama zaman damgası) ve uzun süreli aktif işlemlerin tam listesini ve IO istatistiklerini görmek için HQbird MonLogger aracını kullanın. Ayrıca, kayıt kümelerini önbelleğe alabilen veritabanı erişim bileşenleri/kütüphaneleri kullanıyorsanız, önbelleğe alınmış güncellemeleri kullanın.

22. Uzun kayıt zincirlerinden kaçının

Bir kaydın çok sayıda kayıt sürümüne sahip olduğu durumlardan kaçının - Firebird uzun kayıt zincirleriyle çok daha yavaş çalışır. (bazı tabloların kaç kayıt sürümüne sahip olduğunu ve en uzun kayıt zincirinin ne olduğunu görmek için HQbird IBAnalyst aracını, Tables sekmesini, “Max Version” üzerinde sıralayın). Aynı kaydın birden fazla güncellenmesi yerine eklemeler ve eski kayıtların zamanlanmış silinmesi kombinasyonunu kullanın.

23. PREPARE’i doğru kullanın

Yalnızca parametrelerin değiştiği SQL sorgularını çalıştırmak için hazırlanmış ifadeler kullanın - örneğin, bu tür sorguların döngüsünden önce prepare yapın. Prepare önemli zaman alabilir (özellikle büyük tablolar için) ve sorguyu yalnızca bir kez hazırlamak genel performansı büyük ölçüde artıracaktır.

24. Toplu ekleme/güncelleme işlemi sırasında çok sık COMMIT yapmayın

Toplu INSERT/UPDATE/DELETE işlemi durumunda, her değişiklikten sonra işlemi commit etmeyin (veritabanı sürücünüzde otomatik commit seçeneğini kullanıyorsanız bu olabilir) - işlemleri en az 1000 işlemden sonra veya daha fazla commit edin. Her işlem commit’i veritabanına karşı birkaç okuma/yazma IO işlemi çalıştırır, bu nedenle sık commit’ler veritabanı performansını düşürür.

25. Çok sayıda sabit ile IN kullanıyorsanız dizinleri “kapatın”

WHERE fieldX IN (Constant1, Constant2,… ConstantN) yapısını kullanıyorsanız ve fieldX üzerinde bir dizin varsa, Firebird dizini IN listesindeki sabit sayısı kadar kullanacaktır. fieldX’i ifade +0’a dönüştürerek dizin aramasını devre dışı bırakın: WHERE fieldX+0 IN (Constant1, Constant2,… ConstantN) veya dizeler için fieldX||’’ kullanın

26. IN’i JOIN ile değiştirin

İç içe WHERE IN(SELECT… WHERE IN (SELECT.. WHERE IN() )) içeren sorguları kullanmaktan kaçının, bu Firebird optimize edicisini şaşırtabilir. İç içe IN’leri join’lere dönüştürün.

27. LEFT JOIN’i doğru şekilde kullanın

LEFT OUTER join kullanıyorsanız, tabloları join’de açıkça en küçükten en büyüğe doğru yerleştirin.

28. SELECT sorgularının getirisini sınırlayın

SELECT sorguları için büyük çıktıyı her zaman FIRST… SKIP veya ROWS yan tümceleriyle sınırlamaya çalışın. Sorgu özellikle bir rapor olarak tasarlanmamışsa (tüm kayıtların yazdırılması/dışa aktarılması gereken), genellikle ilk 10-100 kaydı göstermek yeterlidir. Yalnızca gerekli kayıtları getirin.

29. ORDER BY/GROUP BY ile SELECT’te daha az sütun belirtin

ORDER BY/GROUP BY içeren sorgularda hem SELECT bölümünde (yani gösterilecek alanlar) hem de ORDER BY yan tümcesinde sütun sayısını ve bunların toplam genişliğini azaltın. Firebird, SELECT ve ORDER BY/GROUP BY yan tümcelerindeki sütunları birleştirir ve bunları bellekte (veya bellek yeterli değilse diskte) sıralar. Bu nedenle, SELECT’te uzun bir VARCHAR varsa, sıralama dosyalarının boyutu gerçekten büyük olabilir (birçok gigabayt). Alan sayısını yalnızca sıralanması gerekenler için azaltmak ve gösterilecek büyük alanlarla geç join yapmak, ORDER BY/GROUP BY içeren bir sorgunun hızını büyük ölçüde (x3-x10) artırabilir.

30. ORDER BY/GROUP BY ile SELECT’i optimize etmek için türetilmiş tablolar kullanın

Sıralama içeren SQL sorgusunu optimize etmenin bir başka yolu da gereksiz sıralama işlemlerinden kaçınmak için türetilmiş tablolar kullanmaktır.

SELECT FIELD_KEY, FIELD1, FIELD2, ... FIELD_NFROM TORDER BY FIELD2

yerine aşağıdaki değişikliği kullanın:

SELECT T.FIELD_KEY, T.FIELD1, T.FIELD2, ... T.FIELD_NFROM (SELECT FIELD_KEY FROM T ORDER BY FIELD2) T2JOIN T ON T.FIELD_KEY = T2.FIELD_KEY

31. Kısa dizeleri VARCHAR’da, uzun olanları BLOB’larda saklayın

Kısa karakter verilerini saklamak için VARCHAR’ları, uzun metinleri saklamak için BLOB’ları kullanın. Varchar’lar küçük veri parçaları için daha hızlıdır çünkü kayıt içinde saklanırlar ve tüm kayıt aynı IO döngüsünde okunur; kayıt boyutu veritabanı sayfa boyutunun 2/3’ünden küçükse, tüm kayıt aynı veritabanı sayfasında saklanır. BLOB’lar kaydın dışında saklanır ve okumak için ek IO turu gerektirir; uzun dizelerin okunması ve yazılmasında avantaj gösterirler.

32. BLOB sütunlarını büyük SELECT’lerden hariç tutun

BLOB sütunlarını büyük SELECT’lerden hariç tutun. BLOB’lardan seçici olarak bilgi göstermek için (örneğin, belgenin içeriğini göstermek) alt seçimlerle bir tür geç bağlama kullanın.

33. Birincil ve benzersiz anahtarlar için BIGINT kullanın

Otomatik artırılan birincil ve benzersiz anahtarlar ve her türden tanımlayıcılar için BIGINT türünü kullanın. BIGINT ile işlemler en hızlısıdır ve BIGINT neredeyse tüm veri aralıklarını saklamak için yeterli kapasiteye sahiptir.

34. Anahtarlar için VARCHAR kullanmayın

Tanımlayıcılar için gerçekten gerekli olmadıkça VARCHAR kullanmayın - bunlarla yapılan işlemler tamsayı sütunlarına göre çok daha az etkilidir. Özellikle GUID’lerden tanımlayıcı olarak kaçının - GUID değerlerinin rastgele dağılımı nedeniyle Birincil/Benzersiz Anahtar GUID’leri ile INSERT/UPDATE işlemleri tamsayılara göre 20 kat daha yavaş olabilir.

35. İndeks istatistiklerini yeniden hesaplayın

İndeks istatistiklerini düzenli olarak yeniden hesaplayın. Sık veya büyük değişikliklerin olduğu tablolar için indeks istatistiklerini SET STATISTICS komutuyla güncelleyin, bu Firebird optimizer’ın daha iyi SQL planları seçmesini sağlar. HQbird Firebird DataGuard bu tür indeks istatistiklerinin yeniden hesaplanmasını istenen programa göre otomatik olarak gerçekleştirebilir (genellikle haftada bir).

36. Bağlantı havuzu kullanın

Firebird veritabanına bağlantılar kısa süreliyse (web siteleri için tipiktir), bağlantı havuzu kullanın - örneğin PHP’de ibase_connect yerine ibase_pconnect fonksiyonunu kullanın

37. Firebird 3.0’da LINGER seçeneğini kullanın

Veritabanı bağlantıları kısa süreliyse ve Firebird 3+ kullanıyorsanız, önbelleği belirtilen süre boyunca etkin tutmak için LINGER seçeneğini kullanın, başka bağlantı olmasa bile sık kullanılan sayfaları önbellekte tutar. Örneğin, ALTER DATABASE SET LINGER TO 60 son bağlantının sona ermesinden sonra önbelleği 60 saniye boyunca tutar.

38. HASH JOIN kullanın

Firebird 3.0’da, büyük ve küçük tabloların birleştirilmesi durumunda, HASH JOIN indeksli «nested loop» kullanan normal birleştirmeden çok daha hızlı olabilir. Firebird optimizer’ın HASH join kullanmasını sağlamak için birleştirme koşulunda +0 kullanın: T1 JOIN T2 ON T1.FIELD1+0 = T2.FIELD2+0. Optimizasyonun sonucunu üretime almadan önce kontrol edin!

39. Uygun PSQL fonksiyonlarını DETERMINISTIC olarak işaretleyin

Parametresi olmayan ve sabit değerler döndüren PSQL fonksiyonlarınızı (Firebird 3+ içinde) DETERMINISTIC anahtar kelimesiyle işaretleyin. Deterministik fonksiyonlar geçerli sorgu kapsamında hesaplanır ve önbelleğe alınır.

40. Firebird 3.0’da analitik (pencere) fonksiyonları kullanın

Bazı sütunların ve bunun için toplu fonksiyonun aynı anda çıktısıyla SELECT çalıştırıyorsanız, pencere (analitik) fonksiyonları kullanın - alt sorgu veya 2 sorgudan daha hızlıdır. Örneğin:

Select id, department, salary, salary / (select sum(salary) from employee) percentagefrom employee

şununla değiştirin

Select id, department, salary, salary / sum(salary) OVER () percentage from employee

41. gbak için -se anahtarını kullanın

gbak yedekleme ve/veya geri yükleme hızını %20’ye kadar artırmak için -se anahtarını kullanın, örneğin

gbak -b -g -se service_mgr c:\db\data.fdb e:\backup\data.fbk

42. WHERE CURRENT OF

PSQL’de imleç tarafından getirilen kayıtları işlemenin en hızlı yolu ‘where current of <>’ yan tümcesidir. ‘where rb$db_key = :v_db_key’ ifadesinden daha hızlıdır ve birincil veya benzersiz anahtarla aramadan çok daha hızlıdır.

43. İzleme tablolarına sık sorgulardan kaçının

Firebird izleme tablolarına (MON$) çok sık sorgu çalıştırmayın - bu tür sorgular önemli kaynaklar tüketir ve ana iş mantığının performansını büyük ölçüde düşürebilir. MON$ sorgularını dakikada birden sık çalıştırmamanızı öneririz. Firebird sorgularının/işlemlerinin/bağlantılarının sürekli izlenmesi için Trace API’yi destekleyen HQbird PerfMon aracını kullanın (ayrıntılar için HQbird User Guide sayfa 66’ya bakın).

44. Toplu ekleme/güncellemeler için NO_AUTO_UNDO seçeneğini kullanın

Aynı işlem çerçevesinde çok sayıda DML (Update/Insert/Delete) komutu çalıştırıyorsanız, Firebird her komutun undo-log’unu işlemin undo-log’u ile birleştirir. Toplu DML işlemlerini hızlandırmak için, her komutun undo-log’larının işlemin undo-log’u ile birleştirilmemesi için işlemi «NO AUTO UNDO» seçeneğiyle başlatın.

45. İhtiyacınız yoksa Firebird 3’te SRP kimlik doğrulaması kullanmayın

Gerçekten ihtiyacınız yoksa SRP kullanıcı kimlik doğrulaması (Firebird 3.0+) kullanmayın - SRP kimlik doğrulamasıyla bağlantı normal bağlantıdan daha yavaş kurulur.

Özet yerine

Performans optimizasyonu birden fazla faktörün dikkate alınmasını gerektirir ve gerçekten zor olabilir. Yukarıdaki her şeyi denediyseniz, profesyonel veritabanı performans optimizasyonu hizmeti almayı düşünün.

Bize ulaşın

Sorularınız mı var? E-posta ile bize ulaşmaktan çekinmeyin!