Firebird ve arkasından gelenler..

[fduman]

MS SQL'de de bir kesinti olursa çok kişi etkilenecek. VT spesifik birşey değil bu söylediğin.

[highmemo]

Coder, evet ister MSSQL ister ORACLE olsun
kesintide herkes etkilenecek ama aslında demek
istediğim nokta bu değildi,

FB yada IB nin o yoğunlukta 1000 kişi yi nasıl kaldırdığını
gösteren örnekleri bulsun ve incelesin var ise, zaten var ise azdır diye düşünüyorum ki ben 300 kişi duymuştum dedim en fazla.

Dedim ya ii araştırması gerekir. Doğru seçimi yapması gerekir.

Ben şahsen 500-1000 kişi FB olsun IB olsun
şu an için tavsiye etmem.

Ayrıca 500-1000 kişi total user mı yoksa concurrent user mı ?

Sadece dikkat etmesini söylüyorum. Ayrıca UI tarafınında çok titizlikle planlaması lazım. DB ile herşey bitmiyor. Uygulama kısmında Data Access
Strategy ini yanlış yaparsan Oracle bile kaldırmaz 100-500 kişiyi.

[fduman]

Haklısın. Concurrent için 1000 kişiyi kaldıracak VT az bulunur. FB de deneme şansım malesef olmadı. Ama denemediğimiz birşey için de FB bunu yapamaz dememiz de pek doğru değil.

[sadettinpolat]

bence 500-1000 veya daha fazla kişide veritabanından önce mimari incelenmeli. aynı anda 1000 kişi db ye fiziksel connect olacaksa sistem performansı muhakkak düşecektir. 3 katmanlı bir mimari ise hizmet vereceğiniz kişi sayısını aynı sistemle çok daha yukarılara çekebilir. en azından 1000 kişiye hizmet verecek bir sistemde db ye olan fiziksel bağlantı sayısı çok daha aşağılarda olacaktır.

[Terminator]

1000 kişi FB için insert-veri girişi amaçlı bir projede bir yük oluşturmaz.
Yük nedir, sistemler neden tıkanır, neden kaldırmaz çok iyi bilmek gerekir.
Firebird Transaction log tutmaz, verileri takibetmek için ekstra işlemler dosyalar kullanmaz. daha önce anlattığım gibi, FB her seferinde asıl kaydı yapar, aktarıp çevirmez commit veya rollback edilince. sadece transaction envanterine durum kodunu yazar. yani 50,000 kayıt da yapmış olsanız, commit dediğiniz anda sadece versiyon numaraları resmi hale getirilir envanter yoluyla. eski bilgiler de gerektiği sürece tutulur, bu zaten bir şartdır. ne zaman temizlendi, o sayfalar tekrar yeni kayıtlar için değerlendirilir.
Yani FB db yi takip için ekstra bir dosya ya da işlem yapmadığı için, db çok şiştiğinde bilinçsiz kullanıcılar panikler. bu server, yağı, tuzu, suyu sabunu herşeyi içinde bir serverdır, geri dönüşüm ve diğer işlemler iç organlarla yapılır.
FB ün anatomisini bilmiyorsanız ve de öğrenmek istemiyorsanız kesinlikle 500 kullanıcılı bir projede kullanmayın. çünkü FB cüler, kötü tasarımları
kurtarcak eğreti yamalar ve çözümlerden nefret eder.

[fahrettin]

Ali Bey,
ben bu aşamada özellikle şunu merak ediyorum. Bilinen veya sizin bildiğiniz en büyük Firebird projesi nedir, nerededir? Ve burada bahsi geçtiği gibi 1000 kullanıcı çapında projeler var mı? Varsa kaç tane vs... Gibi şu anda yaşayan somut proje örneklerinin varlığını merak ediyorum...
iyi çalışmalar dilerim....

[recepgalip]

merhabalar. Terminator abicim. sen firebird.conf düzenlemelr yap dedin de biraz daha açabilirmisin. aslında hakılısın çunku interbase bole bi sıkışma olmuş şair abinin dediğine göre daha sonra borlançılar gelmiş uygulama yerine conf dosyası uzerinde oynama yaparaktan gözlee görünür bir performans sağlamış.

mümkünse bu performans arttırımlarını yazabilirsen memlun olurum. hem denerim ve sonucu buraya aktarırım. acaba gerçekten gozle gorunur bi şeyler varmı diye. şimdiden tşk. ederim. iyi çalşmalar.

şu an bendeki kullnaıcı sayısı 120 bunların 50-60 yogun çalışıyor geri kalan ise ihtiyaç oldukça sisteme bağlanıyor. şunuda söyleyim ben tum uygulamalarımı bir veri tabanında toplamadım. çok yogun kullanılanları ayrı bir veritabanında topladım. ve her yıl datamı sıfırlarım yani 2000.gdb,2001.gdb,2002.gdb gibi.

[Terminator]

http://www.ibphoenix.com/main.nfs?a=ibp ... d_firebird

http://www.ibphoenix.com/main.nfs?a=ibp ... s_firebird


Fahrettin,
bunlar sadece kullanıcıların bazıları, çok daha büyük ve ciddi işlerde kullanan kullanıcılar var burada görünmeyen, özel bir konu geçtiğinde
projesini açıklayanlar var. Mesela burada doğru dürüst Rus kullanıcısı bile göremezsin ama, en çok FB toolu yazan ve FB geliştirici katkısı olanlar ruslar.
FB kodunda bilinçli olarak kullanıcı sayısı 1024 olarak kısıtlandırılmıştır.
ama önümüzdeki versiyonlarda bu kısıtlama tamamen kaldırılacaktır kod
sistemindeki tıkanıklıklar düzeltildiği için. lisans ve kullanıcı kısıtlaması olmadığı için, bağlantı sayısı da kullanılan platformun limitlerine bırakılacaktır.
bizim kullandığımız mesela, fiziksel olarak 100 terminal civarında, çok aktif
işlemler, üstelik bizde, her terminal aynı anda 2-3 den fazla bağlantı yapıyor. yani bağımsız connection sayısı 200 ü rahat geçiyor.
serverlar allahlık. oracle sistem almak istediğinde para hesabı yapmayan müşteriler, FB söz konusu oldugunda, sıradan bir ev kullanıcısının bile burun kıvıracağı pc leri server yaptırıyor.
makinalar, işletim sistemi kurulumu kötü, programlarımızı ben yazmadım,
bir sürü gereksiz, acele yazılmış queryler, procedurler var,
FB default parametrelerle çalışıyor yıllardır, buna rağmen bir hız sorunu yok. Hız ve tıkanma sorunu yaşadığımız kuruluşlarda task manageri açmam sorunu görmeme yetiyor.
birkaç FB virtual ram açmış antivirusler, spamlar, spywareler, hannibal ekran koruyucuları, vs vs.. FB garibim bi kenarda yine de çalışıyor normal priorityde üstelik.
yani diyeceğim o ki, herşey benim kontrolümde olsa, 1000 değil onbin kişiyi bile idare ederim. ama demokrasilerde paranın sözü geçiyor bilirsin.

[Terminator]

Recep,
projenin konusunu bilmediğim için ön yargılı olmak istemem ama,
parçalanmış db ler performans sağlamaz tam tersi yük olur.
her db için pc nin kapasitesini bölmüş olursun.

FB parametrelerine gelince, bunları bi ara detaylı açıklarım burda zaman bulabilirsem. etkisi olacağından hiç şüphen olmasın, ama asıl görevin kendi tasarımını optimize etmek olmalı. çünkü bilirsin hazıra dağ dayanmaz, sistem kaynaklarını, imkanlarını tüketmek çok kolaydır, zor olanı, ekonomik olmaktır. Yavuz Yodamız anlatsın size 8KB bellekle uzaya gidip gelen roketi...

[Kuri_YJ]

Selamlar,

2005 Global Kullanım Araştırmasında çıkan sonuçlarda aradığınız soruların yanıtları var aslında.

http://www.firebase.com.br/fb/imgdocs/F ... y_2005.pdf

Bu linki inceleyin, max. connection 1250 olarak kayıtlanmış. 1 TB datası olan yerler var. Yani

Kolay Gelsin

[Terminator]

Kuri,
veritabanı dosyasının boyu FB için bir karşılaştırma ögesi olmamalı.
neden?
FB dataları asgari maliyetle saklar, RLE komprasyon uygular,
veritipleri çok optimistiktir, 1 byte dan 2GB a kadar olabilir.
ve FB dosyası yanıltıcı boyda olabilir bilmeyen için.
yani boyu, güncel data demek değildir. içinde yeniden kullanıma
hazır sayfalar geridönüşüme kazandırılır. yan bir FB dosyasının içinde
hem gerçek güncel datalar, hem açık olan bütün snapshotlara uygun datalar hem de önemi kalmayan datalar vardır. sistem bunları çok güvenli ve otomatik bir şekilde sürekli organize eder.
bir FB dosyasının gerçek kayıtlardan büyük olması doğaldır.
diğer sistemlerdeki dbdosyası ve transactionlog vb ilgili dosyaların toplamından yine de daha fazla değildir. çünkü FB indexleri tek yönlüdür bitmaptir comprasyonludur ve minimum yer kaplar.

adamın biri geçen sene bir tecrübesini yazmıştı forumda.
aynı verileri hem firebirde hem de MSSQL e aynı yapıda aktarmış.
sonuç: FB 3.5GB MSSQL 8GB.
oracle dosyalarının hacmi ise zaten malum.
bu sistemlerin çoğu, dosyalardaki alanların büyük kısmını mimailerindeki sorunları aşmak için kullandıkları ilişkilendirme, konumlanma vs bilgilerine harcıyor. Jim amca çok pintidir, her bitin hesabını yapar DECte de asm programcısıymış zaten, C ye FB ile başlamış. 1980 başlarında
bir PC için 128 KB belleğin bile waay bee! olduğunu, ciddi projelerde PClerin kullanılmadığını düşünürsek.
zamanında ekonomik olmak için sistem kodunda neden 2 bytelık sahaların bugün sorun olduğunu, büyütüldüğünü daha doğru anlarız.
neyse ki Ann teyze yasaklamış smallint kullanmasını artık kullanamıyor.

[recepgalip]

ya terminator abicim. sıkbogaz etmek istemem ama conf. dosyasını incelemey çalıştım ama orda neyi değiştirmem gerekiyor yeterli bilgi bulamadım. hatta interbasede v4_lock_mem_size =98304 tu bunu 198304 yapınca baya hızlanıd diyolardı acaba firebirde denemek babında diyorum neleri değiştirmelikine. bunu deneyebileğim yerler var yardımcı olursan sevinirim.

[Kuri_YJ]

Terminator,

Kesinlikle, yani silinmiş kayıtlar ile vs. bir sürü bilgiler DB'de tutuluyor. Ama sanırım orada verilen bilgi SAF DATA olarak verilmiş olabilir. Zira Breziya'da Devlet Dairelerinde de kullanıldığını varsayarsak olabilir.

Yani en azından ben öyle yorumlamıştım.

Kolay Gelsin

[integra_sir]

VEEEEE ARADAN YILLAAAR YILLAR GEÇTİ....

O günlerde (Terminatör Abimizin Yazısından sonra) bi bakalım nedir bu Fayırbörd dedim, oturdum kurcuklamaya başladım. SQL bilgim SIFIR. BDE ile bişiler yapıp çok kullanıcılı olarak çalıştırmaya uğraşıyorum falan. Fb Sürümü 1.0

İlk projeyi 1 sene gibi bir zamanda deneme yanılma yoluyla üretmişim... Az buçuk birşeyler öğrenmişim. Sonra başkalarından ne eksiğim var ben de yaparım deyip oturmuşum adam akıllı program yazmaya başladım. Sürüm 1.5 . Bu uygulama anlık 120 civarı kullanıcıya internet bağlantısı ile tek serverdan hizmet veren ve aynı zamanda php ile yapılmış bir siteye de bilgi aktarımı yapan uygulama. Türkiyede ilk ve hala tek. Arada mikser ustam (Metin) bana zaman buldukça dili döndüğünce yardım etti sağolsun. işi öğretti de denebilir.

Şimdi geldik 2012 ye. Ben halen FB ile uygulama yazmaktayım. Dibine kadar herşeyini kullanmaktayım. Anlık binlerce kullanıcı internet ile aynı serverdan bilgi alıp yazabiliyor. Kasılma yok, yavaşlama net hızına bağlı, bozulma ile henüz tanışmadık. Versiyon 2.1

Tablo sayım 100 lerle ifade ediliyor şimdi. Viewlar, sprocedurelar ve view + table birleştiren sp lardan sorgulama ve raporlar oluşturup keyfime bakıyorum. Program tarafına kod bile yazmıyorum çoğunlukla. Dahası, fb çalışırken usb diske veritabanını alıp başka yerde işime devam edebiliyorum. Bunu diğer vt larında yapmak ciddi maça ister ki zaten imkansız. Hele ki DevExpress, FibPlus ve FastReport üçlüsü ile kullanyorsan tadından yenmiyor.

Sabırla Vulcan ı bekliyorum. Siz hala annenizin veritabanını mı kullanıyorsunuz gelin dönün o yollardan artık. Ne varsa FB de var, paranızı sokağa atmayın. Paralı da olsa vazgeçmem asla Fb Den.

Söylemeyi unutmuşum; firebird veritabanı 30 Terabayte kadar sorunsuz çalışıyor.

[csunguray]

Evet yıl 2012. Bu tartışmanın başladığı 2005 yılında Vulcan deniliyordu. Hala Vulcan ortalıkta yok. Başka söz söylemeye de gerek yok. Çünkü FB projesi her sene roadmap a uymama rekoru kırar. IB/FB ün bir takım benzersiz özelliklere sahip olduğu şüphesizdir ama aynı şeyi MS veya Oracle yapmış olsa... (Devamını yamaya gerek yok). Daha 2005 yılında SMP sorunundan bahsediliyordu. Yıl 2012 oldu, aradan 6 sene geçti, En basit serverların bile (hatta PC ve laptopların bile) CPU sayıları havalarda uçuşuyor. Ama Vulcan hala ortalıkta yok. Bir de FB'de table ların adını sonradan değiştiremiyorsunuz. Bunu basit bir sorun olarak görebilirsiniz veya şöyle böyle yöntemlerle yapabilirsiniz diye izah etmeye kalkabilirsiniz. Ama bu sorun program geliştirme esnasında programcıyı çok zorluyor. Ha bir de temporary table meselesi var. Daha yeni eklendi FB'e. En basit DB'lerde bile olan bir özellik. Eskiden FB çüler bunun gereksiz olduğunu savunuyorlardı. Sonradan özellik olarak eklendi. Büyük kurumlar ve büyük veritabaları için kritik olan incremental backup bile sanırım 2.0 sürümünden sonra eklendi.

Bu arada diğer veritabanı sunucularına da bir çok özellik eklendi. Bunları saymaya gerek yok.

Ben FB kullanmak için çok düşündüm. Ama her karar verme aşamasında beni korkutan bir şey çıktı karşıma.

Sağlıcakla kalın.