Firebirde hız

[cabbar]

Yaklaşık 1 aydır firebir ile ilgili formdaki tüm yazıları ve internette bulduğum tüm kaynakları okuyarak programlarımda kullandığım paradox tan kurulmaya karar verdim. Az çok bazı şeyleri öğrendim. veritabanımı firebirde yaptıktan sonra elimde 12 fieldli ve içinde 700.000 kayıt olan paradoks tablomu firebirde birebir aynı şekilde aktardım. lakin bu işlem tam 4 saat 47 dakika sürdü oysa benim firebird hakkında okuduklarım firebirdin fazla kayıtlarda çok daha hızlı olduğudur. Denemediğm yöntem kalmadı. Tüm alanları indeksledim denedim, indeksleri kaldırdım denedim sonuç yine değişmedi. tablomda sadece 1 tane autoinc alan var bununiçin triger kullandım. birtek bunu sp ile denemedim ikisi arasında hız farkı olurmu bilmiyorum çünkü her denemeden sonra 4 saat 47 dakika beklemem canıma tak ettirdi. Bu arada bilgisyar kon. P4 3.0, 512 ram çalışan herhangi bir firewal yok. kullandıpım compenantlar IBO datalarım kullandığım bilgisyarda başka bir serverda değil yerel bir veritabanı kullanıyorum.
Aktarma Kodun örneği aşağıda

Kod: Tümünü seç

Tbl_Stok.Open;
 //IBOTbl_Stok.Open;
 Tbl_Stok.First;
  while not Tbl_Stok.Eof do
      begin
       IBOTbl_Stok.Open;
            begin
             IBOTbl_Stok.Append;
             IBOTbl_StokTUR.AsInteger:=Tbl_StokTUR.AsInteger;
             IBOTbl_StokTARIH.Text:=Tbl_StokTARIH.Text;
             IBOTbl_StokGRUP.AsString:=Tbl_StokGRUP.AsString;
             IBOTbl_StokFIRMA.AsString:=Tbl_StokFIRMA. AsString ;
             IBOTbl_StokSTOKADI. AsString :=Tbl_StokSTOKADI. AsString ;
             IBOTbl_StokSTOKTIP. AsString :=Tbl_StokSTOKTIP. AsString ;
             IBOTbl_StokSTOK_FIATI.AsCurrency:=Tbl_StokSTOK_FIATI.AsCurrency;
             IBOTbl_StokGTARIH.AsText:=Tbl_StokGTARIH.AsText;
             IBOTbl_StokCTARIH.AsText:=Tbl_StokCTARIH.AsText;
             IBOTbl_StokALAN.AsString:=Tbl_StokALAN.AsString;
             IBOTbl_StokMIKTAR.AsFloat:=Tbl_StokFloat.AsCurrency;
             Tbl_Stok.Next;
             end;
       IBOTbl_Stok.Post;
       end;
ShowMessage('İşlem Tamam');

end;

Dataları firebirde aktardıktan sonra ibexpertle açtığımda tabloyu aşağı ve yukarı dolaştığımdada çok yavaş. fakat yazdığım programda herhangi bir sorguyu çalıştırdığımda oldukça hızlı. Neden bukadar sürede bir tablodan diğerine aktardığını anlamış değilim oysa paradoks tablosundan başka bir paradoks tablosuna aktarmam 5-6 dakikamı alıyor. Doğrusu firebird hakkında okuduklarım beni şüpheyle bakmaya sevk etti benim gözden kaçırdığım birşeymi var bu konuda yardımcı olacak arkadaşlara şimdiden teşekkürler.

[husonet]

Tbl_Stok.Open;
//IBOTbl_Stok.Open;
Tbl_Stok.First;
while not Tbl_Stok.Eof do
begin
IBOTbl_Stok.Open;
begin
IBOTbl_Stok.Append;
IBOTbl_StokTUR.AsInteger:=Tbl_StokTUR.AsInteger;
IBOTbl_StokTARIH.Text:=Tbl_StokTARIH.Text;
IBOTbl_StokGRUP.AsString:=Tbl_StokGRUP.AsString;
IBOTbl_StokFIRMA.AsString:=Tbl_StokFIRMA. AsString ;
IBOTbl_StokSTOKADI. AsString :=Tbl_StokSTOKADI. AsString ;
IBOTbl_StokSTOKTIP. AsString :=Tbl_StokSTOKTIP. AsString ;
IBOTbl_StokSTOK_FIATI.AsCurrency:=Tbl_StokSTOK_FIATI.AsCurrency;
IBOTbl_StokGTARIH.AsText:=Tbl_StokGTARIH.AsText;
IBOTbl_StokCTARIH.AsText:=Tbl_StokCTARIH.AsText;
IBOTbl_StokALAN.AsString:=Tbl_StokALAN.AsString;
IBOTbl_StokMIKTAR.AsFloat:=Tbl_StokFloat.AsCurrency;
Tbl_Stok.Next;
end;
IBOTbl_Stok.Post;
end;
ShowMessage('İşlem Tamam');

end;

Gördüğüm Kadarıyla
aktarımı döngü kuararak yapıyorsun ve ayrı ayrı ayrı 2 database in açılıyor. Atamalarında her döngü döndüğünde Database yazılmıyor ve cache de tutulduğunu görüyorum CommitRetaining i kullanarak Cache yi biraz rahatlatabilirsin. Convert işlemlerinde Zaman kaybını gözden çıkartmak gerekecektir.

Kolay Gelsin...

[cabbar]

Hocam o dediklerinizi zaten yaptım post işlemini döngünün içine alarakta denedim. Zaten şuanda tablolarımda cacheupdates=false seklinde direk kayıt yapıyor ben sadece her ihtimale karşı döngü dışınada pos u larak son deneme kodumu gönderdim şuanda halen transfer devam ediyor. kodlarımda herhangi bir hata olmadığının farkındayım fakat firebirde daha yeni olduğum için şüphelerim arttı. bu kod sadece bana birdefa lazım. fakat günde yaklaşık 1000 kayıt girildiği için bu yavaşlık beni oldukça ürküttü. firebirde benim gözümden kaçırdığım ve acemiliğimden kaynaklanan herhangi bir başka incelikvamı diye düşünüyorum. Eğer bu yavaşlık günlük kayıtlarımdada devam ederse firebird sevdasından vazgeçme durumunda kalacağım. Oysa okuduklarım ve incelerken gördüklerim bana paradokstan çok üstün yanlarını gösterdi. çünkü böyle bir veritabanında anladığım kadarıyla yazdığımız kodlarda %50 civarında azalma olacağının farkına vardım ve bende bundan dolayı geçmeye heveslendim. ilgilendiğin için teşekkür ederim.

[husonet]

Hocam o dediklerinizi zaten yaptım post işlemini döngünün içine alarakta denedim. Zaten şuanda tablolarımda cacheupdates=false seklinde direk kayıt yapıyor ben sadece her ihtimale karşı döngü dışınada pos u larak son deneme kodumu gönderdim şuanda halen transfer devam ediyor. kodlarımda herhangi bir hata olmadığının farkındayım fakat firebirde daha yeni olduğum için şüphelerim arttı. bu kod sadece bana birdefa lazım. fakat günde yaklaşık 1000 kayıt girildiği için bu yavaşlık beni oldukça ürküttü. firebirde benim gözümden kaçırdığım ve acemiliğimden kaynaklanan herhangi bir başka incelikvamı diye düşünüyorum. Eğer bu yavaşlık günlük kayıtlarımdada devam ederse firebird sevdasından vazgeçme durumunda kalacağım. Oysa okuduklarım ve incelerken gördüklerim bana paradokstan çok üstün yanlarını gösterdi. çünkü böyle bir veritabanında anladığım kadarıyla yazdığımız kodlarda %50 civarında azalma olacağının farkına vardım ve bende bundan dolayı geçmeye heveslendim. ilgilendiğin için teşekkür ederim.

Hocam hiç alakası yok nedeni ise kodlama yerinde yapıldığın da Sp ve Trigerlardan tam anlamıyla yararlanıldığını hesaba katarsak ta 700.000 kayıt FireBird de vızırtı gelecektir. Ben İbtable kullanmadım ibDataset ve ibQuery kullanıyorum bütün ağırlığı Database kısmına (En Ufak Raporumu bile) Sp ve Triger larime yıkıyorum ve Aldığım sonuçlardan da gayet memnunum SQL e ağırlık vererek kodlamanızı yaparsanız beklediğinizin üstünde bile performans alabilirsiniz....

Mesala 700.000 kaydınızı Aynı database için de farkı bir tabloya SQL ile insert into kayıt yapın bakalım sonuçlar ne olacak!

insert into EKLENEN_TABLO (select alan1,alan2,alan3 from EKLENECEK_TABLO)


Kolay Gelsin...

[cabbar]

hocam kullandığım ibtable değil IBO table bu kompenantı hem normal tablo gibi kullanabildiğimiz gibi hemde Sql desteği var ben demosunu sitesinden indirdim şuan için deneme amaçlı kulanıyorum. aktarmam bittikten sonra zaten dediğnizi deneyeceğim. yukardıda söylediğinizgibi convertten kaynaklanan bir yavaşlama olabilir. ayrıcıca bu IBO compenantlarını inclemeni tavsiye ederim. fiyatı biraz yüksek ama anladığım kadarıyla hertürlü işlemi her şekilde yapma şansınız var hiç bir table nesnesinde ben daha önceden sql desteği görmedm ama bunda var. adresi http://www.ibobjects.com

[mkysoft]

bu şekilde üst üstte 700.000 kayıt girecekseniz append ve post işlemleri çok yavaş oluyor bunu bende fakketim. bunu kullanmak yerine updatequery nesnesini yada husonet'in bahsettiği gibi sql komutlarını kullanabilirsin. sql konutlarını sqlstiring'e attıktan sonra execsql fonksiyonunu çağır.

[gkimirti]

eger index sayısı fazla ise bunun kayıt aramalara cok buyuk etkisi olurken insert islemlerini yavaslatdıgı bilinen bir gercek
ama sandıgınız kadar da yavas degil
eger hız konusunda bir test yapmak isterseniz ibexpert yada dbworkbench gibi toollarda mevcut olan TestData Generatorleri kullanabilirsiniz.
saniyede yaklasık (tabi burda alan sayısı ve uzunlukları da cok onemli) 1000 yada biraz altı kayıt insert edebilmekte.
buda fena bir rakam degil.
Firebirde aktardıgınız tabloların aynı database icinde bir klonunu olusturarak
insert into klon_tablom select * from tablom seklinde bir test yapın
ne kadar zaman alacak?
Ben su an 100 tabloya yakın karısık bir projeyi Firebird ile gelistiriyorum ve tam anlamıyla Free bir canavardır Firebird

[freeman35]

Kesinlikle FireBird yavaş değildir. 700 milyonda olsa diğer databaselerle karşılaştırırsan bence firebird başa güreşir. IBO bana sorarsan FIBPlus öneririm. Bende her ikisini denedim benim kararım FIBPlus dan yana. demoları içinde "data_copy" projesi var. burda direk SQL oluşturuyor ve yeni database e aktarılıyor.

yavaşlığa sebep eğer bağlı grid vs gibi componentlar varsa bunlarda işlemi yavaşlatır. Bir diğer önderimde diğer arkadaşların söylediği gibi SQL cümlesi oluşturup insert işlemini öyle yap

kolay gele

[Ali Erdoğan]

Paradoxdaki değerleri parametre olarak alıp insert işlemini gerçekleştiren bir stored procedure ile bu işi denemelisin.Elde ettiğin sonucu yazarsan memnun oluruz

[Hakan Can]

Aşağıdaki procedure 34 alanlı 300 bin kayıtlı bir paradox tablosunu 103 saniyede aktardı.
(Her iki tablonun alan yapısı aynı olduğu varsayılarak. Eğer aynı değilse yazılımı ona göre değiştirmeniz gerekiyor.)

Kod: Tümünü seç

Procedure'un kullanım şekli:

MyBDETableToInterBaseTable('C:\DETAY.DB', 'C:\MyData.GDB', 'DETAY', 'TEST0001');


procedure MyBDETableToInterBaseTable(const aBDETableFileName, aInterBaseDatabaseFileName, aInterBaseTableName, aDummyAliasName: string);
var
  MyList: TStringList;
  aAliasName: string;
  aBDETableName: string;
  L: Integer;
begin
  aBDETableName := ExtractFileName(aBDETableFileName);
  L := Length(ExtractFileExt(aBDETableName));
  if L > 0 then aBDETableName := System.Copy(aBDETableName, 1, Length(aBDETableName) - L);
  MyList := TStringList.Create;
  try
    MyList.Add('SERVER NAME=' + aInterBaseDatabaseFileName);
    MyList.Add('USER NAME=SYSDBA');
    MyList.Add('PASSWORD=masterkey');
    Session.DeleteAlias(aDummyAliasName);
    Session.AddAlias(aDummyAliasName, 'INTRBASE', MyList);
    with TQuery.Create(nil) do
    try
      DatabaseName := ExtractFilePath(aBDETableFileName);
      SessionName := 'Default';
      SQL.Text := 'INSERT INTO ":' + aDummyAliasName + ':' + aInterBaseTableName + '" SELECT * FROM ' + aBDETableName;
      ExecSQL;
    finally
      Free;
    end;
  finally
    MyList.Free;
    Session.DeleteAlias(aDummyAliasName);
  end;
end;

İyi çalışmalar.

Kod larınızı Code tag içine alınız HUSONET

[mege]

evet bende teknik nedenlerden dolayı FIBPlus çılardanım

firebirde 1 milyon kayıt atım denediğim ufak bi test vardı sonuçları için bakınız

viewtopic.php?p=39207#39207

test sonuçları :

Advanced Data Generator i kurdım ve tabloma bağladım ve teste aldım.
( trial versiyonda bir seferda max 10000 kayıt üretebiliyor)

ilk önce bi ayarını gözden kaçırmışım. 1000 kayıtta bi transaction çekecek şekilde ilk denememi yaptım gözüm yaşardı

20:44:30: Started.

20:44:30: Preparing for relation "ARSIV".
20:44:30: Starting 10000 rows for relation "ARSIV".
20:44:34: Inserted 10000 of 10000 rows for relation "ARSIV".

20:44:34: Finished.

sonra baktımki bu benim yapıya uymaz. sonuçta ben her kayıttan sonra kesin kaydedicem.
ayarlardan her kayda özel transaction yaptım yani 10000 transaction

20:45:09: Started.

20:45:09: Preparing for relation "ARSIV".
20:45:09: Starting 10000 rows for relation "ARSIV".
20:45:27: Inserted 10000 of 10000 rows for relation "ARSIV".

20:45:28: Finished.

eh buda süper sayılır 19 saniyede 10000 kayıt.

yani sizde 100 kayıtta bir commit edin 500 snde bitmesi lazım milyon kayıtın,

[fahrettin]

Arkadaşlar veritaabanına insert performansı genel ihtiyaçlar açısından hiç önemli değildir....
Ve de kesinlikle kabul edilir ki sql temelli veritabanlarına insert hızı paradox, access, dbase vs.. gibi file based sistemlere insert hızından yavaştır.. Hatta çok yavaştır.....

Hiç index olmasa bile aynı miktardaki kaydı aynı kodla paradoxa insert, firebird veya sybase veya oracle'a insertten hızlıdır... En azından ben bunu beklerim.... Ancak kaynak veri aynı veritabanında ise ve toplu olarak tek bir insert kodu ile inserti yapıyorsanız o başka....

Velhasıl kelam hiç test etmeye gerek yok.... firebird daha hızlı insert etse de sonucta bu bir anlama gelmez....

Cunku sql temelli veritabanlarının (Sybase, Firebird, Oracle, vs...) hızlı olomalarından bahsedilerkenki hız insert hızı degil select hızıdır....

Siz selecte bakın.... Zira çok istisnai durumlar hariç kimse hergun 1 milyon kayıt insert etmez.... Ya da bunu toplu olarak hızlı bir sekilde isnert etme ihtiyacı duymaz....
Genel olarak komplike sistemlerde yuzlerce kullanıcı ayrı ayrı kollardan data giriyor olurlar ki bu da her kullanıcıc dakikada ya da 10-15 saniye 1 kayıt insert ediyor olabilir... Bu da tek bir kayıt isnert işlemidir ve paradox misal 10 milisaniyede yapsın. firebird de 100 milisaniyede yapsın... 10 kat yavaşlık bile kullanıcılar tarafından hissedilmez...

ama iş selecte gelince sybase veya firebird in 1 saniyede aldigi bir kompleks sorgu sonucunu paradox 10 saniyede aldımı bunu herkes hisseder....

Bu nedenle insert hızına hiç takmaya gerek yok yavaş oldugunu kabul ediyoruz zaten...

[name]

Merhaba.
fahrettin bey, @cabbar arkadaşın problemi anormal bir durum bence. Sizin bahsettiniz durum @cabbar arkadaşın bahsettiği duruma (700bin kayıt'ın 4 saat'te aktarılması) yol açmamalı bence.

bu şekilde üst üstte 700.000 kayıt girecekseniz append ve post işlemleri çok yavaş oluyor bunu bende fakketim. bunu kullanmak yerine updatequery nesnesini yada husonet'in bahsettiği gibi sql komutlarını kullanabilirsin. sql konutlarını sqlstiring'e attıktan sonra execsql fonksiyonunu çağır.

Verileri IBDataset ile append yaparak yada IBSql ile "insert" sql ifadesini kullanarak aktarım arasında bir fark olmayacaktır.

@cabbar, yaşadığın problemin bir kaç tane sebebi olabilir.

1. Kullandığın Triger'ın kodundan olabilir. Trigger'ında nasıl bir kod kullandın. Triger'ın DLL kodlarını yazabilirmisin? Bende Triger kodlamam yüzünden benzer bir problem yaşamıştım.

2. @freeman35'in dediği gibi aktarım sırasında DataControl bileşenlerinden biri yada bir kaçı ilgili tablolara bağlı ve açık ise yine aktarım yavaş olacaktır.

3. Bundan emin değilim ama oluşturmuş olduğun FB database'in PageSize'ından olabilir. Oluşturduğum bütün database'lerde PageSize'ı 4096 yapıyorum. Sende bu değeri deneyebilirsin. PageSize'ın tam olarak ne olduğunu bilmiyorum . Ancak bu sayının düşük olmasından dolayı çok fazla performans kaybettiğimi hatırlıyorum.

Ayrıca PageSize hakkında bilgisi olan arkadaşlar paylaşırsa sevinirim.

[fahrettin]

O kadar sure olmasi biraz anorlam hakikaten... ama ozetel demek istedigim insert performansında paradox mu firebird mu karsilastirmasi gereksiz....

[Ali Erdoğan]

This is the specification of the database page size in bytes.

Firebird/InterBase databases are saved in blocks. Each of these blocks is called a page. Database administration occurs basically by accessing the hard drive block by block. The more data per access fetched by a single database page, the less often it is necessary to load a new page, at least theoretically. Practically, depending upon the operating system and server hardware, access to larger database pages can even influence the performance negatively, as 1024 bytes can be loaded quicker than 8192 bytes.

IBExpert

Page size can be 1024, 2048, 4096, or 8192. The default page size is 1024. For Windows 9x databases, the optimal page size is 4096. On Windows NT and Unix databases, the optimal page size is 8192.

http://www.prestwood.com/community/data ... e_spec.asp