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

Burada Firebird veritabanı için farklı alanlarda performans ipuçlarının listesini bulabilirsiniz - donanım/İşletim Sistemi ve Firebird yapılandırma ayarlarından SQL optimizasyon önerilerine kadar. Bu liste, Firebird’ü optimize etmek için eksiksiz bir referans değildir ve yürütme planları, işlem yönetimi ve sorgu performans istatistikleri gibi Firebird’ün çalışma temellerini anladığınızı varsayar.

Lütfen bu ipuçlarını dikkatle 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ülerden çok daha iyi rastgele G/Ç sağlar. Rastgele G/Ç, büyük veritabanı dosyasına dağıtılmış verilerin okunması ve yazılması için kritiktir - veritabanı işlemlerinin çoğu yoğun paralel rastgele G/Ç 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, Yedek Pil Ünitesinin (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, 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

Kurulu BBU’ya sahip RAID denetleyicisi (ve UPS’li 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ülerinizde bozuk bloklar ve diğer donanım sorunları (aşırı ısınma dahil) olup olmadığını kontrol edin. Donanım sorunları G/Ç performansını önemli ölçüde düşürebilir ve veritabanı bozulmalarına yol açabilir.

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

Birçok 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 çalışmayacaktı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 dosyasındaki TempCacheLimit parametresinin değerini artırın - bu, sıralama için geçici alan önbelleğinin 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 ve SuperClassic için 1Gb kullanın. Yine, #9’dan optimize edilmiş yapılandırma dosyalarını kullanın.

11. Forced Writes’ı Kapatın (dikkatle!)

Yoğun ekleme veya güncelleme aktiviteniz varsa (bunu HQbird MonLogger ile kontrol edebilirsiniz, ayrıntılar için HQbird Kullanıcı Kılavuzu sayfa 60’a bakın) ve donanım arızalarına karşı korumak için UPS ve replikasyon kuruluysa, Forced Writes ayarlarını OFF olarak ayarlamayı 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 çekirdekleri kullanabilir.

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

firebird.conf dosyasındaki TempDirectory parametresinin ilk bölümünü hızlı diske - SSD veya RAM sürücüye 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 özel fiziksel sürücüde (RAID) saklayın. Bu, yedekleme sırasında okuma ve yazma G/Ç’sini ayıracak, yedekleme hızını artıracak ve ana sürücüdeki yükü azaltacaktır. Bu, özellikle kullanıcılar veritabanıyla çalışırken yedekler alındığında önemlidir. Firebird için donanım yapılandırması hakkında daha fazla ayrıntı " Firebird Donanım Kılavuzu" içinde bulunabilir.

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

Birçok kayıt ekliyor veya güncelliyorsanız (tablonun %25’inden fazlası), kayıtların eklendiği tablo için endeksleri devre dışı bırakın ve ekleme veya güncellemeden sonra yeniden etkinleştirin. Endeks yeniden oluşturma işlemi, endeksin birçok güncellemesinden daha hızlı olabilir.

17. Hızlı eklemeler için Global Geçici Tablolar kullanın

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

18. Gereksiz endekslerden kaçının

Yoğun ekleme ve güncelleme yapılan tablolar için daha az endeks kullanın. Her endeks, ekleme, güncelleme, silme ve çöp toplama işlemlerine önemli bir yük ekler - tek bir kayıt eklendiğinde/güncellendiğinde/silindiğinde/temizlendiğinde her endeks için 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 kitaplıklarında bulunan işlevselliği sunan birçok gömülü fonksiyon eklenmiştir. Mümkün olduğunda bu tür fonksiyonları 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

Kayıtları 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, çöp toplamadan kayıt sürümlerini 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, uzun süreli olanlardan orantılı olarak daha az sayıda kayıt sürümünü çöp toplamadan tutar. Ne yazık ki, tek bir uzun süreli işlem bile (örneğin geliştirme aracından açık bırakılan) diğer tüm kısa yazılabilir işlemlerin iyi etkisini bozabilir. Bu yüzden uzun süreli işlemleri izlemeniz ve kaynak koddaki 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şlangıç zaman damgası) ve uzun süreli aktif işlemlerin tam listesini ve G/Ç 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/kitaplıkları kullanıyorsanız, önbelleğe alınmış güncellemeleri kullanın.

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

Bir kaydın birçok kayıt sürümüne sahip olduğu durumlardan kaçının - Firebird uzun kayıt zincirleriyle çok daha yavaş çalışır. (hangi 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ı, Tablolar sekmesini kullanabilir, “Max Version” üzerinde sıralayabilirsiniz). Aynı kaydın birden çok güncellenmesi yerine, eklemelerin ve eski kayıtların zamanlanmış silinmesinin bir kombinasyonunu kullanın.

23. PREPARE’ı 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 fazlasında commit edin. Her işlem commit’i veritabanına karşı birkaç okuma/yazma G/Ç işlemi çalıştırır, bu yüzden sık commit’ler veritabanı performansını düşürür.

25. Birçok sabitle IN kullanıyorsanız endeksleri “kapatın”

WHERE fieldX IN (Constant1, Constant2,… ConstantN) yapısını kullanıyorsanız ve fieldX üzerinde bir endeks varsa, Firebird endeksi IN listesinde kaç sabit varsa o kadar kullanacaktır. fieldX’i +0 ifadesine çevirerek endeks 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 optimizer’ın kafasını karıştırabilir. İç içe IN’leri join’lere dönüştürün.

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

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

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

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

29. ORDER BY/GROUP BY içeren SELECT’te daha az sütun belirtin

ORDER BY/GROUP BY içeren sorgularda hem SELECT kısmında (yani gösterilecek alanlar) hem de ORDER BY yan tümcesinde sütun sayısını ve toplam genişliklerini 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). Yalnızca sıralanması gereken alanlar için alan sayısını 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 içeren SELECT’i optimize etmek için türetilmiş tablolar kullanın

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

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

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, büyükleri 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ıtta saklanırlar ve kaydın tamamı aynı G/Ç döngüsünde okunur ve kayıt boyutu veritabanı sayfa boyutunun 2/3’ünden azsa, kaydın tamamı aynı veritabanı sayfasında saklanır. BLOB’lar kaydın dışında saklanır ve okumak için ek bir G/Ç turu gerektirir; uzun dizeleri okuma ve yazmada avantaj gösterirler.

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

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

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

Otomatik artan 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ıdır ve BIGINT neredeyse tüm veri aralıklarını saklamak için yeterli kapasiteye sahiptir.

34. Anahtar olarak VARCHAR kullanmayın

Gerçekten gerekmedikçe tanımlayıcılar için VARCHAR kullanmayın - bunlarla yapılan işlemler, tamsayı sütunlarına göre çok daha az verimlidir. Özellikle GUID’lerden tanımlayıcı olarak kaçının - GUID değerlerinin rastgele dağılımı nedeniyle, Primary/Unique Keys GUID’leri ile yapılan INSERT/UPDATE işlemleri tamsayılara göre 20 kata kadar daha yavaş olabilir.

35. İndeks istatistiklerini yeniden hesaplayın

İndeks istatistiklerini düzenli olarak yeniden hesaplayın. Sık veya büyük ölçekli değişiklikler olan 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 indeks istatistiklerinin yeniden hesaplanmasını istenen programa göre (genellikle haftada bir) otomatik olarak gerçekleştirebilir.

36. Bağlantı havuzu kullanın

Firebird veritabanına veritabanı 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 aktif tutmak için LINGER seçeneğini kullanın; bu, 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 bitiminden sonra önbelleği 60 saniye tutar.

38. HASH JOIN kullanın

Firebird 3.0’da, büyük ve küçük tabloların birleştirilmesi durumunda, HASH JOIN, indeks kullanan «nested loop» ile 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 production’a koymadan ö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+) 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 (window) fonksiyonları kullanın

Bir sütunu ve onun için toplama fonksiyonunu aynı anda çıktılayan SELECT çalıştırıyorsanız, window (analitik) fonksiyonları kullanın - bu, alt sorgu veya 2 sorgudan daha hızlıdır. Örneğin:

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

bununla 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. Bu, ‘where rb$db_key = :v_db_key’ ifadesinden daha hızlı ve birincil veya benzersiz anahtarla aramadan çok daha hızlıdır.

43. İzleme tablolarına sık sorgu yapmaktan 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 daha 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üncelleme işlemleri için NO_AUTO_UNDO seçeneğini kullanın

Aynı işlem çerçevesinde birçok 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’unu işlemin undo-log’u ile birleştirmemek için işlemi «NO AUTO UNDO» seçeneğiyle başlatın.

45. Gerekmiyorsa 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 birçok faktörün dikkate alınmasını gerektirir ve gerçekten zorlu 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 bizimle iletişime geçmekten çekinmeyin!