Firebird ve arkasından gelenler..

[integra_sir]

Evet,

Terminatörün de dediği gibi; Diğer Vt lerde yanlış ya da eksik olanlar düzeltilip tamamlanıp yeni özellik gibi sokuşturuldu piyasaya. Kolay gele.

[Kuri_YJ]

Selamlar,

Öncelikle, FB geliştirmenleri bu işi, işi olduğu için yapmıyorlar. Bu işten para da kazanmıyorlar. Ötelenmeler ertelenmeler doğal olarak normaldir. Aynı şeyi, para ödediğiniz bir sunucu için söyleyemezsiniz.

En basitinden, M$-SQL Server (Adı bile yok malesef) kendi hatalarını ve açıklarını gidermeye çalışarak mantığını record versioninge kaydırmaya çalışıyor. Ta en başından beri değişmez, değiştirilemez, değiştirilmesi teklif dahi edilemez Record size limit 8060 Byte sınırını aşamadılar (Merak edenler için adresi veriyorum http://msdn.microsoft.com/en-us/library ... .105).aspx). Page size'ı şekillendiremiyorsun, hele ki indexleme mantıklarında yeni bir şey yumurtladılar evlere şenlik. Bu kadar külfete eziyete girebilmek için bir de üzerine para ödüyorsunuz

Bilmiyorum tercih meselesi elbet ama yükünü aldıkça çıkan ve hayır kurumundan sunulan bir hizmete laf edilmesi haksızlık olur kanaatindeyim. Ayrıca iyi optimize edilmiş bir FB server işinizi hayli hayli görür (Tabi concurrent user sayınz 100,000'leri bulmuyorsa. Bilmem denemedim belki de kotarıyordur, deneyen var mı?)

[Lost Soul]

Vakti zamanında bu konuyu takibe almışım cevap yazılınca bana da mesaj geldi. Üşenmedim sayfaların tümünü gözden geçirdim. Araya faydalı bilgiler sıkışmış özetle bi öne çıkarayım dedim.

mesela postgresql de şöyle bişe yazılabiliyor.
bence çok güzel bi özellik

Kod: Tümünü seç

  CREATE TABLE cities (
    name            text,
    population      float,
    altitude        int     -- (in ft)
  );

  CREATE TABLE capitals (
    state           char(2)
  ) INHERITS (cities);

Inherit edebilme özelliği iyiy miş. Başka hangi vtlerde vardır acaba???

sadettin, 100-200 kullanıcın insert ederken bile kasılıyorsa orda bir sorun vardır. benim 5 yıl önceki AMD-K2-350 fosil makinam bile 3 GB lık quantum fireball diske saniyede 3000 (yazıyla üçbin!) kayıt yapıyordu en eski FB ile üstelik, ya da IB 5.6/6.0 dı tam hatırlamıyorum.
nasıl yapabiliyordu?
duplicate indexim/referans indexim yoktu, ya unique ya da primary key.
FB çok hızlı insert yapan bir sistemdir çünkü indexleri unidirectionaldır.
FB ü insert yaparken durduracak hiçbirşey yoktur, insert lock nedir bilmez.
select ler de lock bilmez FB de.
sadece eş zamanlı düzeltme/silme lock verir, o da Allah'ın emri.

sistemin tıkanıyorsa 100-200 kullanıcıda:
1- sweep/GC devreye giriyodur, bu da bütün tabloların taranması demektir, DISK çok meşgul olacağı için takılma hissedilir, yani response hızı düşer. bunu önlemenin çareleri var.
2- kullanıcıların çok fazla full table scan, fetch veya sort yaratıryodur, bunun da çaresi var.
3- Sisteminde çalışan başka bir proses vardır, network trafigi ve disk trafiği artınca, cpu kullanımı artınca kasılmaya etkisi hissedilir hale geliyodur. bunun da çaresi var.
4- eksik ya da ayakbağı olan indexlerin olabilir.
5- transaction süreçlerin çok uzun ve/veya modu yanlış olabilir.
vs vs vs..

sadettine:
şöyle oluyor sadettin, indexlerde tekrar eden kayıtlardan birini bulup
kullanmak zorlaşıyor, ister okumak isterse o index kaydını silmek için olsun(GC)
diyelim ki senin çok büyük bir hareket dosyan var milyonlarca kayıt..
stok çıkış diyelim,
mal_id integer referenced mal(id), olsun.
345 numaralı maldan 45000 defa çıkış yapıldı diyelim.
ve sen kalktın, bu çıkışlardan biri hatalı yapıldığı için sildin.
silinen kayıt 345 ok, ama referans index tablosunda 45000 tane var aynı
değeri gösteren. yani 45000 tane fiziksel kayıt numarası.
şimdi GC devreye girdi ve temizlik yapıyor diyelim.
silinen kaydı buldu, kullanan ilgili bir transaction yok, yeni versiyonları var.
bu kaydı siler. ama sadece kaydı değil o tablonun bütün indexlerini tarayıp o kayda ait girişleri de silmesi lazım.(remember kurinin çöpleri)
ee lök diye 5-6 hamlede 345 merkezini buldu.
ya sonra?
hani 3423423550 fiziksel adresli olanı? ara da bulasın..
index sadece mal_id için var, fiziksel adres pasif bir bilgi.
başlıyorsun 345 e ait bütün kayıt numaralarını karşılaştırmaya bulana kadar, ilk seferde de karşılaşabilirsin, 45 binincisinde de.. sırayla tek tek..
buldun, sil.
böyle tekrar kaç indexin var? 4-5 referanslı ve çok tekrarlı indexin varsa vay haline.. gereksiz yere onlarca sayfa okunup incelenecek, düzeltilip tekrar yazılacak.
naaptılar, çok basit, indexe bir de kayıt bilgisini eklediler kullanıcıyı ilgilendirmeyecek bi şekilde, böylece çöt diye inary tree de hemen buluyor. olay biraz daha komlike ve daha geniş kapsamlı bir sorun, ben basitleştirmeye çalıştım.
ben sırf bu yüzden referans indexlerin belalılarını silmek zorunda kaldım.
hangilerini silmedim?
mesla bir fatura master detaili silmeye gerek yok, bir faturanın kalemleri
sınırlıdır 1-100 civarıdır. bu sorun değil. ama 30000 ve üstü olunca kasılıyor FB salakça bi işe dalıyor engine düzeyinde. diğer kullanıcılara da hizmeti aksıyor.
çok tekrar eden ama kullanman gereken bir refrans tablon varsa,
(silinmeyi önlemek için) başka küçük bir pasif tablo yaratıp referans verebilirsiniz silemezler. insert ederken varlıgını test etmek içinse,
before insert ve update triggerlarına field değiştiğinde referans kontrolü koyabilirsiniz, yoksa user exception yaratırsınız.
biz bilgisayarcıların birinci görevi, çok kullanıcı bir sistemi daima boşta tutmaya çalışmaktır.

Eğer firebirdde halen sistem böyle işliyorsa veritabanı oluştururken bu konuya da dikkat etmekte fayda var.

VEEEEE ARADAN YILLAAAR YILLAR GEÇTİ....
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.

İnternet veya Uzak bağlantı denilince firebird biraz sönük kalıyor malesef. Kulanılmıyor değil kullanılabiliyor ancak mysql le kesinlikle boy ölçüşemiyor.

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

Karar verme aşamasında sizi caydıran ne oldu acaba. Size özel bir işi kaşılamayan birşey miydi yoksa genel itibariyle korkutucu birşey miydi.

Bu kadar külfete eziyete girebilmek için bir de üzerine para ödüyorsunuz

Ora Kıl 'ı bilmem ama microsoft için Kesinlikle katılıyorum

[Kuri_YJ]

Selamlar,

Lostsoul

İnternet veya Uzak bağlantı denilince firebird biraz sönük kalıyor malesef. Kulanılmıyor değil kullanılabiliyor ancak mysql le kesinlikle boy ölçüşemiyor.

demiş.

Kullanmadığım için soruyorum, örnekleyebilir misin? Nerelerde nasıl bir kayıp var. Belki de kullanımdan kaynaklı olabilir. Bilmiyorum, kullanmadım, öğrenmek istiyorum.

Kolay Gelsin
Adnan

[Lost Soul]

Selamlar,
...
Kullanmadığım için soruyorum, örnekleyebilir misin? Nerelerde nasıl bir kayıp var. Belki de kullanımdan kaynaklı olabilir.
...

Sayısal istatistik veremem ancak hem firebird hem de mysql veri tabanına client erişimleri sağlayan programlarım oldu.
Ve internet üzerinden erişimde gözle rahatlıkla fark edilecek düzeyde hız farkı var.

Ben mi kuruntu ediyorum diye düşünüyordum fakat her iki veri tabanını bilen çevremdeki insanların da görüşü bu yöndeydi.

Acaba onlar da mı kuruntulu diye düşünüyor tabi insan.

Fakat tarzanca ingilizcemden yanlış anlamadıysam kendi sitesinde de internet üzerinden kullanım için pek iddialı değiliz diyor Bu linkte

[Kuri_YJ]

Selamlar,

Verdiğin linki okuduğumuzda senin kadar karamsar yaklaşmıyorum. Çünkü iş temelinde mimari olarak ele alınmalı. Çünkü, Firebird aslında 3050 Portunu kullanan bir TCP/IP server'dır. Bu nedenle IP protokolü oldukça ağırdır diyorlar. Tabi bu da küçük veri alış verişlerinde, gecikmelerin ana sorunu teşkil ettiğinden bahsediyorlar. Bu tür uygulamalarınızda, en az Firebird 2.1 (çünkü IP protokolünde çok önemli geliştirmeler yapıldığından bahsedilmiş.) veya SOAP veya Middle Tier applikasyonlar tasarlamanızı tavsiye ediyorlar. Ayrıca veri güvenliği ve bu tür ufak tefek verilerin transferleri için (özellikle internet üzerinde) ZeBeDee, SSH ya da SSL kullanılmasını tavsiye ediyorlar.

Sonuçta Firebird bir Database server ve onu sadece bu amaçla kullanmanız daha doğru bir yaklaşım olur.

Kolay Gelsin
Adnan

[csunguray]

Firebird'te çok büyüyen veritabanlarında vertabanını durdurmadan shrink işlemi yapılamıyormuş.

[Kuri_YJ]

Selamlar,

Shrink????? Ben anlamadım, açıklar mısın?

Firebird'te çok büyüyen veritabanlarında vertabanını durdurmadan shrink işlemi yapılamıyormuş.

[csunguray]

Diyelim 10 GB veritabanınız var. 8 GB bilgi (Kayıt) sildiniz. Veritabanı boyutu hala 10 GB kalır. Boşluğu kazanmak için diğer veritabanlarında bazı komutlar var. Ama Firebird kullanıyorsanız Backup/Restore yapmanız lazım. Bunun için de veritabanını durdurmanız gerekir. Arada sırada diğer veritabanlarının özelliklerini da incelemenizi tavsiye ederim.

Öncelikle, FB geliştirmenleri bu işi, işi olduğu için yapmıyorlar. Bu işten para da kazanmıyorlar.

Firebird projesinde maaşları FireBird Vakfı tarafından ödenen benim bildiğim en az 1 tane tam zamanlı çalışan programcı vardır.

Ötelenmeler ertelenmeler doğal olarak normaldir. Aynı şeyi, para ödediğiniz bir sunucu için söyleyemezsiniz.

İşler yolunda gitmediği zaman bahane bu olacaksa ben ciddi projeler için Firebird kullanmam. Başkasının da kullanacağını sanmıyorum.

[Kuri_YJ]

Selamlar,

Öncelikle, Shrink'in ne olduğunu gayet iyi bildiğimi belirteyim. M$-SQL Server'ın yamalarından biridir. FB'de shrink olmadığından neyi kast ettiğini anlayamadım.

Diyelim 10 GB veritabanınız var. 8 GB bilgi (Kayıt) sildiniz. Veritabanı boyutu hala 10 GB kalır. Boşluğu kazanmak için diğer veritabanlarında bazı komutlar var. Ama Firebird kullanıyorsanız Backup/Restore yapmanız lazım. Bunun için de veritabanını durdurmanız gerekir. Arada sırada diğer veritabanlarının özelliklerini da incelemenizi tavsiye ederim..

Demişsin, ben sana benim bildiğim Database'leri bir söyleyeyim. Senin yaşını bilmiyorum ama ben bu işe daha 1985'lerde, sıralı (Sequential) ve rastgele erişimli (Random Access) kütük yapılarıyla, C64'lerde Teyp üzerinde, sonrasında Amstrad 6128'lerde disk üzerinde başladım. Ardından, Btrieve, Fabs, DBase, Clipper, FoxPro, Access, Interbase, Firebird, M$-SQL Server, Oracle, AS400 DB2, Informix, Sybase. Ayrıca Main Frame Makinelerde PL/1 ve VSAM/VTAM gibi veri yapıları kullandım, CICS ve oradaki SQL'i malesef kullanamadım. Bunlardan bir kısmını halen kullanıyorum ve yaptıklarını da takip ediyorum Dünyayı geriden takip eden M$'ın Database'i sanan arkadaşlar da kafasını kaldırıp ne olup ne bittiğiyle ilgilenmeleri daha iyi olur kanaatindeyim.

Ayrıca 10 Gig'lik veri tabanından 8 Gig'ini her gün silmezsin. Kaldı ki, silsen ve yer kazansan neyine yarar? Disk sıkıntın mı var? Ayrıca 10 Gig'lik veritabanından kayıtların 8 Gig'ini siliyorsan bu işte bir sıkıntı var, mimarinde bozukluk var demektir. Bu kadar kaydı yazıp silmenin costlarını hiç hesaba katmamışsın, sistem mimarisini iyi kurmamışsın demektir. Boşa harcanan alanları doldur boşalt yaparak hem enerji hem de vakit kaybettirirsin.

Kaldı ki, senin verdiğin örneğe istinaden, 10 Gig'lik bir DB'den 8 Gig silinmesi gerekiyorsa, ben 8 Gig sileceğime, 2 Gig'lik bilgiyi bir Datapump ile başka bir DB'ye alırdım. 8'i silmektense, 2'yi taşımak daha az maliyetli olur.

Öncelikle, FB geliştirmenleri bu işi, işi olduğu için yapmıyorlar. Bu işten para da kazanmıyorlar.

Firebird projesinde maaşları FireBird Vakfı tarafından ödenen benim bildiğim en az 1 tane tam zamanlı çalışan programcı vardır.

Doğrudur takımda işleri sürekli takip etmesi için bir yada birden fazla Firebird Foundation'da fiilen çalışan kişiler var. Ben isimleriyle vereyim sana, Dmitry Yemanov (Software Developer, R&D Coordinator 2001 yılından beri), Alex Peshkoff (Core Developer 2004'den beri), Vladyslav Khorsun (2003'den beri) gibi. Bunlar zaten hem Vakfın hem de takımın çekirdek isimlerinden, Helen Borrie, Claudio Valderrama, Adriano Dos Santos Fernandes gibi bu projeye katkıda bulunan memberlar var, bkz. http://www.firebirdsql.org/en/members/ öyle bir yada ikiyle ifade edilmiyor gönüllüleri. Deniz feneri veya kimse yok mu gibi derneklerde de maaşlı çalışanlar vardır. İlla ki bir dernek binası veya ofisi vardır. Bunların olmadığını mı düşünüyordun? Yüzlerin içinde sayabileceğin 2-3 kişi.

Ötelenmeler ertelenmeler doğal olarak normaldir. Aynı şeyi, para ödediğiniz bir sunucu için söyleyemezsiniz.

İşler yolunda gitmediği zaman bahane bu olacaksa ben ciddi projeler için Firebird kullanmam. Başkasının da kullanacağını sanmıyorum.

Sanılarla değil kanıtlarla gitmek gerek. Sonuçta, cumaya giden kişi herkesi müslüman, gitmeyen de kafir sanırmış. O duruma benziyor biraz seninkisi.

İşlerin yolunda gidip gitmemesini, senin Database dizaynın ve yazılım mühendisliğindeki becerilerin ortaya koyar. Örnek vermek gerekirse, benim yazdığım bir sistemde günlük transaction sayısı 250,000-300,000 civarında, zaman zaman 400,000'e yaklaştığı da oluyor. Transactiondan kastım her türlü Insert/Update/Delete işlemi. Ayrıca 3 DB bu server üzerinde duruyor. DB'lerin birinde 10,000,000'dan fazla kayıt historical olarak tutuluyor. Bir tane LIVE DB bir tane de OLAP işlemleri için CUBE DB'si var ve bu CUBE DB'sinde de yaklaşık 4,500,000 kayıt var. Kullanılan database server Firebird, işletim sistemi windows 2003 server 32 bit. Üstüne üstlük her 8 Core olan CPU'dan sadece 3 core kullanıyor ve Max Bellek kullanımı DB başına 400-500 MB civarında. Gelelim CPU usage değerlerine En zorlandığı anda %25 CPU tüketiyor. Concurrent kullanıcı sayısı da ortalamada 60 ama zaman zaman 100'e kadar çıkıyor. Bu kullanıcılardan bir kısmı doğrudan veri tabanıyla iş yaparken, aynı server üzerinde BI Reporting yapan Raporlama uzmanları var. Bunların da üzerine ek olarak, Sistem servisleri de saniyede 10'larca otomatize edilmiş processleri DB üzerinde gerçekleştiriyor.

Bunu diğer databaseerde yaptığında oluşacak LOG şişmelerini bir düşünürsen, Memory kullanımı, CPU kullanımı, durmadan shrink etme ihtiyacı duyarsın. Ama Firebird'ün, silinen kayıtların sweep edilerek ilgili sayfaları tekrardan kullanildiğinden, bahsedilen GAP'ler düşündüğün gibi oluşmaz.

Olay tasarımda yatıyor yatıyor, ki 2005 yılından bu yana M$ yırtınıyor, Record Versioning uygulamak için. Ama FB bunu daha ilk çıktığı günden bu yana uygulayan DB'lerden biri.

İş tasarımda biter Yukarıda bahsettiğim işi ben M$ üzerine de yaparım ve yine makineyi de zorlamam insanları da. At sahibine göre kişner.

Mesela sana bir örnek daha vereyim. 8064 bytelık Record sınırlamasının M$'da haa çözülemediğini, 8 K'lık page yapılanmasının hiç değiştirilemediğini, buna karşın NTFS'in defaultta 4K'lık page'lerde olduğunu, senin her bir Page Read veya page Write'ta, OS'e hep 2 Page iş yaptırdığını, bu yüzden disk işletim maliyetinin de FB'ye göre neredeyse 2 kat olduğunu biliyor musun?

Kolay Gelsin
Adnan

[Kuri_YJ]

Ha aklıma gelmişken. Bir de M$-SQL serverda dbccreindex vardır, bozulan indexleri onarmak için kullanırsın. Tıpkı Shrink gibi FB de bu da yoktur, çünkü index bozulmaz

[PhoenixJedi]

Abi Sen bu işe başladığında İstanbul Osmanlı toprağıydı değil mi?

[csunguray]

Sayın Kuri_YJ. Ben Firebird düşmanı değilim. Zaten burada 1-2 cümle yazıyorsam bu Firebird ile ilgilendiğim anlamına gelir. Ama sizin Firebird harici veritabanlarının (özellikle ticari olanlarının) düşmanı olduğunuz çok açık. Hatta o kadar taraf tututorsunuz ki Firebird harici veritabanlarını seçen ve kullanan programcıları bile pek akıllı görmüyorsunuz. O yüzden bu tartışmayı sürdürmek anlamsız.

[anemos]

FB veritabanı varsayılan 20.000 transaction ardından otomatik olarak sweep(shrink) yapıyor. Yanlış mı biliyorum?

Sayın Kuri_YJ, mesajlarından çok faydalandım. Sevgiler, selamlar...

[Kuri_YJ]

Selamlar,

Rica ederim, ama yazdıklarımın düşman algılanması şaşırtıcı. Çünkü ben bu forumda, ne Oracle'a ne MySQL'e ne PstgreSQL'e ne Informix, Sybase ve diğer paralı database'lere ne de onları kullananlara laf söylemedim. Söylemem de, herkes bildiğini sevdiğini kullansın ama bilmediğine de laf söylemesin, haksızlık karşısında kendimi tutamam. Sadece M$'a yalan söyledikleri ve ondan daha kralcı olanlara laf söylerim.

Sweep olayını da bir başka konu başlığında anlatmıştım (açıklayıcı olarak nasıl olması gerektiği ve neler döndüğü sorusunu da, Link vererek göstermiştim.)

Kolay Gelsin
Adnan