firebird ve x64 sorunu ?

[dberdi]

herkese selamlar, iyi çalışmalar, geçen hafta bir projemizde firebird kullanma kararı aldık ama sadece ve sadece almakla kaldık

neden ? çünkü x 64 desteği yok malesef ?

diyeceksinizki olmasın ne olur!...

ama malesef öyle olmuyor işte, 32 bit işletim sistemlerinin göreceği maksimum ram 3.25 gb dir, inanmayan araştırsın taraştırsın, makina ve bit algoritmasını hesaplasın sonucu görecektir, halen inanmayanda alsın 4 gb yada daha fazla ramı taksın pc ye kursun windowsu yada linux u görsün, dolayısı ile 8 gb ram ile çalışacak olan bir bilgisayarda işletim sisteminin 64 bit olması gerekiyor,

ben bu foruma başlarken bir yazı görmüştüm mssql mi firebird mi diye? hatta oraya mssql diye ısrarla yazılar yazmıştım, ama firebird hakkındaki yorumları görünce firebird ile bir proje kullanma kararı aldık ama gördükki 64bit desteği bile yok, veritabanı küçük işler için iyi olabilir ama verigüvenliği için, hız için, kapasite için ben uygun olduğunu düşünmüyorum, şuana kadar en büyük veritabanı büyüklüğü 950 gb diye bir yazı görmüştüm, açıkcası o şahıslarında halen firebird kullandığınada inanmıyorum.

357 milyon kaydı firebird malesef deviremedi, 20 alan varchar(25) ve 357milyon kayıtta patladı, (dual core 3.4 ghz. 4 gb ram)...

şimdi ben firebirdci arkadaşlara sormak istiyorum benim sorunumu nasıl çözebilirsiniz ? ben projeyi yaptığımız firmaya ramlarınızı 4 de düşürün 3 e düşürün diyemem, adam 8 gb ram istiyor ? bizdende çok büyük bişeyde istemedi basit bir cari hesap takibi gibi bişey istedi ? şimdi ben bu sorunu nasıl çözebilirim? madem firebird diye ısrar eden arkadaşlar var, ozaman bu sorunun çözümünü söylesinler? firebird ile günümüz teknolojisi ile program yazmak için oturup x64 tabanlısının çıkmasınımı bekleyelim ? açıkcası hevesim kursağımda kaldı. şimdi alternatif diyeceklerki "madem firebird görmüyo oracle kullan!..." ben oracle kullanmakta istemiyorum, oracle veri hiyerarşisi olarak iyi olabilir ama mssql kadar dayanıklı değil malesef, sadece hızlı, ama şuan ondan daha hızlı çalışan java tabanlı db lerde var ? ben firebirdi nasıl kullanacam ? mssql den daha iyi diye idda ettiğiniz firebird in neden 64 biti yok? 64 bit tabanlı desteği olmayan bir veritabanı sistemini neye göre mssql den daha iyi diyosunuz ? kimse alınmasın gücenmesin, herşey para değil önemli olanmüşteri memnuniyeti...

daha geçen haftaya kadar firebird diye arkadaşlarla tartışıyoduk ama şimdi bütün herşey altüst oldu ? bu sorunun çözümü varsa söyleyin bilelim, yoksada kimse kalkıpta firebird mssql den çok iyi demesin...

kimsede alınmasın, burası forum ortamı görüşlerimizi fikirlerimizi söylemek hakkımız. en iyi olan tartışılarak bulunur.

[serkan]

vallaaa kardeş,aslında bu dertten muzdarip olmamak mümkün değil heralde volcan dedikleri meredi beklemek lazım...şöyle 10 işlemcili filan süper pc denilen donanımlardada sistem kaynaklarını kullanmıyo firebird yiğidimm,minimum donanımda çok iş mantığı var ama maximum donanımda maximum iş yok bu firebirdde nedense...
bende firebird kullanıyorum kullancam da,çünkü diğerlerininde başka dezavantajları var..burda fayda maliyet analizi yapmak lazım.

belki bi bilen çıkar..başarılar

[sadettinpolat]

*fb nin 64bit surumu 2.0 versiyonundan beri linux icin mevcut.
*windows icin ise su aralar rc2 surumu yayinlanmis olan fb 2.1 de win64 destegi mevcut. 1-2 haftaya kadar fb 2.1 in kararli surumu release edilecek.

367 milyon kayitta fb nin kaldiramadigi sey nedir acaba ?
biraz bilgi verir misiniz ?

kayit eklemek, sorgulamak , gruplamak vs.

50-100 milyon kayit barindiran veritabani kullandim lakin 367 milyon kayit barindiran veritabani su ana kadar fb de henuz kullanmadim. bilgi amacli soruyorum.

[dberdi]

ben rc sürümlerini kullanarak müşteriye ürün sunamam, rc zaten alfa/beta karışımı (release candidate) test amaçlı çıkan bi ürün..

357 milyon kayda gelincede, elimizdeki müşterilerimizden db si büyük boyutlarda olanlar var örneğin xxxxxxtaş a.ş. nin 19 yıllık müşteri kayıtları bilgi tabloları kayıt sayıları 360 milyon civarında , sadece 42739 cari kaydı var tabi bunlara bağlı alt tablolarda var, ödeme tabloları ise minimum 3 aydan başlıyor, 1 milyar civarında taksit kayıtları var, işte tam firebird i burda gösterilen şöyle böyle denilen özelliklere göre test etmek için mütiş bi fırsat geçti elimize, aldık db yi firebirde aktardık, baya bi zamanımızı aldı ama malesef sadece aktarmakla kaldık bu arada çok fazla kayıt sayısında hiçte öyle süper denilen bi performans vermiyor, join lerden vazgeçtik tekil almak istedik, ondada bi öğle yemeği yedik geldik yani sonuç olarak ben bunu x64 te sorunsuz çalıştırmak için anlaşılan yine paralı bişey alacam. durum onu gösteriyor.

bugün TÜRKİYE' de çok fazla program satmış bir A...INSOFT bütün programlarında firebird kullanıyor, adamları müşteriymiş gibi aradım, dedimki benim pc de 8 gb ram var ve x64 kullanıyorum, nasıl yapabilirim ? adamların bana dediği üzgünüz o sistemde programlarımız çalışmaz... buyrun burdan yakın...

ben daha öncede burda yazmıştım "firebird ile adres etiket programı yapılabilir ama iyi bir proje yapılamaz" aksini idda eden varsa göstersin görelim.

hepimizin amacı ülkemiz ve ekonomi için açık kaynağa destek vermek, ama bu tip şeyleri aşmadan bişeyler yapamayız, biz diğer yazılımcı arkadaşlarla beraber bir açık kaynak sistemi kurmayı planlıyoruz, ben herzaman tartışmacı ve münazaracı bir yapıya sahip biriyim. firebird kullanmak isterim ama, dediğim gibi tartışmayı seviyorum, tez çürütme fikir üstünlüğü yada ne bilim böyle tartışmak ve en iyisini bulmak gerektiğini düşünüyorum. ben firebirdi ilk defa kullanacağım için daha çok (-) yönlerini tartışıyorum, yanlız lütfen beni kimse yanlış anlamasın, bensadece tartışıyorum,

[sadettinpolat]

bence yanlis bir firmaya sormussunuz soruyu

firebirdun teknik destek icin kullanilan mail grubu var. sorunu o grupta dile getirmeden a.....softun "calismaz" demisiyle arastirmalariniza nokta koymayin.

rc surumle proje gelistirmek pek saglikli degil elbet.ben sadece rc2 nin ciktigini kararli surumunde eli kulaginda oldugunu belirtmek icin soyledim. ustelik su an test asamasindasiniz ve fb 2.1 rc2 test amacli kullanilabilir. hem kendi projenizi test etmis olur hem de fb yi test ederek acik kaynaga yardimci olmus olursunuz.

sorgu sonucunu yemekten sonra almak net bir performans kriteri olmanin cok uzaginda. karsilastirma yapabilmek icin diger sql sunucularininda ayni sorguyu ne kadar sure icerisinde dondurdugu onemli. mesela hali hazirda kullanilan sistem ayni sorguyu ne kadar bir surede isliyor ?

[serkan]

firebird indexleri diğer veritabanlarına göre daha iyi kullanıyor kanısındayım,yaklaşık 200.000 kayıtlık ana tablo ve 30 milyon kayıtlık detay tabloyu joinle seçerken gerçekten bir fincan kahve içiliyordu.ama tabloların özellikle bağlantı ve sıralama alanlarına indexleri ekleyince sorgu 2-3 sn de geldi.bunu söylememin sebebi acaba sanada öğle yemeği yediren sorguda indexleri filan tanımladınmı veya o sorguyu nerden çalıştırdın programının içindenmi yoksa IBExpert gibi bir tooldanmı?

[dberdi]

index tanımladım ve ibexpert kullandık ? ama küçük bir exe yapıp testte ettik, hem fill hem reader kullandık. neyse artık heralde x64 ün tam sürümüne bakcaz.

[serkan]

sadece sorgu hızına bakmak için 2.1 rc sürümünü x64 de test edebilirsin,tatmin ederse projeye başlayıp kararlı sürüm çıkınca veritababıbı aktarırsın..

[Vital]

arkadaslar yaziyi okudum biraz sasirdim desem yeridir

yani bir den fazla islemcili server lardami ayni kaderi paylasiyor 4 islemcili bir bilgisayarin isletim sistemi 32 bit ise ram i 3.25 mi
kafam karisti dogrusu.
ve fb nin 64 bit destegi hangi surumden itibaren basliyor.

tskler

[dberdi]

bence yanlis bir firmaya sormussunuz soruyu

firebirdun teknik destek icin kullanilan mail grubu var. sorunu o grupta dile getirmeden a.....softun "calismaz" demisiyle arastirmalariniza nokta koymayin.

rc surumle proje gelistirmek pek saglikli degil elbet.ben sadece rc2 nin ciktigini kararli surumunde eli kulaginda oldugunu belirtmek icin soyledim. ustelik su an test asamasindasiniz ve fb 2.1 rc2 test amacli kullanilabilir. hem kendi projenizi test etmis olur hem de fb yi test ederek acik kaynaga yardimci olmus olursunuz.

sorgu sonucunu yemekten sonra almak net bir performans kriteri olmanin cok uzaginda. karsilastirma yapabilmek icin diger sql sunucularininda ayni sorguyu ne kadar sure icerisinde dondurdugu onemli. mesela hali hazirda kullanilan sistem ayni sorguyu ne kadar bir surede isliyor ?

mssql = 94 saniye
oracle = 61 saniye
jdatastore = 53 saniye

diğer serverlerin verdiği cevap bu

biz ekip olarak açık kaynağa tam destek vercez 2008 de, yeni projelerimizin birde açık kaynak versiyonunu yapacağız, hatta mevcut sürümlerin pardus versiyonlarını ücretsiz dağıtmayı bile düşünüyoruz. açık kaynağa tam destek bizden ama firebird düşündürüyo java tabanlılar sanki daha iyi gibimi ne

arkadaslar yaziyi okudum biraz sasirdim desem yeridir

yani bir den fazla islemcili server lardami ayni kaderi paylasiyor 4 islemcili bir bilgisayarin isletim sistemi 32 bit ise ram i 3.25 mi
kafam karisti dogrusu.
ve fb nin 64 bit destegi hangi surumden itibaren basliyor.

tskler

4 çekirdekli ve ram 4 gb ve üstü olan bi işletim sistemi zaten 32 bit çalışmaz çünkü matematiksel algoritması 4 gb ramı görmez, firebird inde malesef x64 tabanlı desteği henüz beta aşamasındaymış.

[mussimsek]

Merhaba,

Firebird 2.1 sürümünden itibaren Windows, Linux, MacOs vb. işletim sistemlerinde 64 bit desteği vermektedir.

Firebird 64 bit desteği Beta aşamasında değil. Final sürüm çıkmak üzere. Teknik problemler RC1 ve RC2 sürümleriyle tamamen giderildi. Installer (kurulum kısmı) ile alakalı bir sıkıntı vardı, onu düzeltince 2.1 sürümü çıkacak. 3-4 güne çıkar diye tahmin ediyorum.

Ama daha önce @sadettinpolat'ında dediği gibi 3-4 gün beklemem diyorsanız RC2 sürümü ile denemelerinizi yapabilirsiniz.

Kolay gelsin.

[Hakan Can]

Yanlış anlaşılmaması noktasında öncelikle şu hususları baştan belirtmekte fayda var.

64 Bit işletim sisteminde (misal Vista Bussiness 64) 32 Bit FireBird çalışıyor. Yani FireBird'ün de 64 Bit olması gerekmiyor.

8 GB RAM'i 32 Bit işletim sistemleri desteklemiyor derken Windows Server bunun dışındadır. XP ve Vista 32 en fazla 4 GB RAM'i destekliyor (Bu da 3.25 olarak falan gözüküyor).

4 GB RAM ile 8 GB RAM'in FireBird açısından belki de hiçbir farkı yoktur.

Kayıt konusunda; 360 milyon kayıtlık bir tablo hangi veritabanı olursa olsun beklediğiniz performansı göstermeyecektir. Birinde sorgu başlatıp, bitene kadar, gidip öğlen yemeği yiyebiliyorsanız diğerinde en azından çay demleyip çay içersiniz. Yani kaba tabiriyle al birini vur ötekisinedir.

Bu malesef veritabanı sorunu değil veritabanı tasarımcısı sorunudur. Eğer biz günde gerekirse böyle tablolardan bin tane rapor almak zorundayız falan diyorsanız malesef sadece hava alırsınız.

Sonuçta yapacağınız sorgu eğer baştan sona bu tabloyu taramayı gerektiriyorsa bu bütün veritabanlarında hemen hemen aynı yöntemle olacaktır. Harddiskin okuyucu kafası haldır huldur harddiskte bir oraya bir buraya gidecek-gelecek ve al sana sonuç diyecektir.

Kısaca tasarım hatanızı FireBird'e fatura etmeyiniz. Gerçekten ne demek istediğimi anlamak isterseniz testi MS SQL ve/veya Oracle'da yapınız. Örneğin MS SQL ilk sorgulamada üç aşağı beş yukarı aynı çıkacaktır. Sonraki sorgulamalar korkunç hızlı olacaktır belki. Ama bu statik yapıdaki tablolarda yani verigirişi durmuş tablolarda ve hafıza yettiği taktirde falan olacaktır. Yani bu da işinizi görmeyecektir sonuçta ki tabloyu yüzlerce milyon kayıtlarla ifade etmek demek saniyede yüzlerce-binlerce kayıt girmek demektir.

Aslında en önemli sorun olan veritabanı tasarımının masaya yatırılması gerekiyor.

Tabi belki de buna yakın önemde olan programlama tarafındaki çözüm yaklaşımlarının, kullanılan bileşenlerin vs. neler oldukları da beraber yatırılmalı.

Misal 360 milyon kayıtlı tabloyu TTable ile açıp Last işlemi yaptığınızda galiba ertesi günü beklemeniz gerekecektir.

Özetle FireBird olsun MS SQL olsun Oracle olsun. 360 milyon kayıtlı tabloyu baştan sona sorgulamaya gerek bırakmayacak, basit yapılar kurmak gerekir. En basiti hareketlerin toplamlarının cari kartlara triggerlar ile işlenmesi. Hareketlerin tutulduğu tabloların yıllara göre farklı tablolarda tutulması ve yıl başında devri (Tek Düzen Muhasabe) vs. gibi.

Yani sorun FireBird'de değil malesef.

Her zaman olduğu gibi biz yazılımcılarda.

Ama işin güzel tarafı, çözüm de yazılımcılarda. Tabi çözebilirsen.

İyi çalışmalar.

[sadettinpolat]

firebird 2.1 cikti
denemelerinizi birde bu surum ile yapip bilgi verirseniz sevinirim...

http://firebirdsql.org/index.php?op=dev ... 10_release

[csunguray]

32 bir işlemcili bir bilgisayar Physical AddressExtension yöntemi ile 4 GB'tan daha çok belleği desteklemektedir.

http://en.wikipedia.org/wiki/Physical_Address_Extension
http://technet2.microsoft.com/windowsse ... x?mfr=true (Türkçe)
http://www.microsoft.com/whdc/system/pl ... AEdrv.mspx

Birinci elden cevap almak için Firebird sorunlarınızı [url]news://news.atkin.com[/url] haber grubu sunucusundaki gruplara sorabilirsiniz.

[Ali Erdoğan]

Bunun gibi milyar kayıtlı tablolar yerine tabloları parçalamayı öneren bir makale okumuştum. Yani 1 milyar cari hareketi bir tabloda saklamak yerine

carihareket2006
carihareket2007
carihareket2008

gibi ayrı ayrı tablolarda saklamak, cari döküm istendiğinde en son yılı göstermek, eğer tüm cari döküm isteniyorsa da union kullanarak tablolardan çekilen verileri birleştirme yoluna gidilebilir. 10 Yıllık cari döküm isteyen biri de zaten sonuçlarına katlanır.

Taksitli işlemler kısmında da ödenip biten taksitleri çok fazla merak eden olmayacaktır. Bu yüzden ödemesi biten taksitleri taksitler tablosunun bir kopyası durumunda olan taksitarsiv tablosuna kaldırmak akıllıca olabilir. Ödenmiş ve ödemesi bitmemiş taksitler bir arada görülmek istendiğinde yine union kullanılabilir.

1 Milyon nüfuslu bir ilin sorunlarını tek bir merkezden çözmek kolay değildir. Bu yüzden böl parçala yönet politikası uygulanır. Bir büyükşehir belediyesi ve bazen onlarca ilçe belediyeleri vardır.

Join pratik bir yöntem ancak bu kadar performans gerektiren bir durumda her kayıt için join ile yaptığınız işlemleri trigger gerçek alanlara işlemeniz durumunda ne indeks ne de çok akıllı bir veri tabanına ihtiyaç kalmadan olay çözülecektir. Yani her bir cari hesabın bakiyesini her seferinde join kullanarak hesaplatıyorsanız zaten boşu boşuna gblarca ramleri, mhzlerce işlemcileri harcıyorsunuz demektir.

Bu iş biryerden sonra harddisk'in okuma/yazma hızı olayında zaten tıkanıyor.