Firebird ve arkasından gelenler..

Firebird ve Interbase veritabanları ve SQL komutlarıyla ilgli sorularınızı sorabilirsiniz. Delphi tarafındaki sorularınızı lütfen Programlama forumunda sorunuz.
Kullanıcı avatarı
Terminator
Üye
Mesajlar: 313
Kayıt: 13 Ara 2005 01:45
Konum: İzmir, ama Aydın Efesi!

Mesaj gönderen Terminator » 14 Ara 2005 04:28

highmemo,
mevcut FB code yapısı kalacak olsa dediğinde haklısın.
yani mevcut, borlanda özgü bazı kodlama hataları yüzünden büyük ölçekli işlemlerde FB bazı darboğaz işlemlere takılıyor. ama bunlar giderildi.
kimseye kalkıp, FB küçük ve orta ölçeklidir, öyle kalacaktır denemez.
önemli olan gelecektir. geliştirecek olan kişinin iş yükünden daha hızlı büyüyecek ve hızlanacak FB. kimse yolda kalmaz. FB ilk geliştirildiğinde büyük işler içindi, 90 lardan sonra windowsa ve pclere taşındı o yüzden pek bilinmedi. çünkü sıradışı mimarisine sahip çıkıp geliştirecek zengin bir sahibi olmadı hiçbir zaman. sabahtan akşama büyük bir projeyi tamamlayamayacağına göre kimse ve birkaç ayda terabytelar düzeyine çıkmayacağına göre DB file, bence yanlış bir sistemle başlamak daha sakıncalı.

sen
Üye
Mesajlar: 34
Kayıt: 04 Tem 2003 12:33
Konum: Ankara

Mesaj gönderen sen » 14 Ara 2005 04:34

oracle onu bunu satın alıyor :lol: yarın birgün firebid de satın almasın sakın :D

Kullanıcı avatarı
naile
Admin
Mesajlar: 1873
Kayıt: 11 Haz 2003 09:11

Mesaj gönderen naile » 14 Ara 2005 04:40

Terminator yazdı: Ama görüyorum ki, ilgilenen yok bunlarla, komut ve fonksiyon
kaynakları sizin için daha önemli...
bana ne, nasıl yaparsa yapsın, benim istediğim yapsın da.. diyebilirsiniz.
bu çok profesyonelce yaklaşım ve tartışacak değilim, tercih meselesi.
Ama en başta da dediğim gibi FB çok farklıdır.
Tabii ki nasıl yaptığı da bizim için önemli çünkü ucu yine bize dokunuyor. Önceki mesajımda da söyledim ms sqldeki locklanmalardan şikayetçiyiz. Ama tabi sadece mimari yeterli kalmadığı için mssqlin fonksiyonlarının çokluığuna değinmek istedim. FB dü bende bir projemde kullandım (1.5),tamamen yabancı değilim ve foreign keylerdeki duplicate index sorununu ben de yaşadım, bu sorunun 2 ile giderilmiş olmasına sevindim :) Bakalım FB dediğiniz gibi sağlam bir mimari ile gümbür gümbür geliyor.

Adnan abi senin vesilenle hakkaten güzel canlanadı forum, herkese teşekkürler ;)

Kullanıcı avatarı
Terminator
Üye
Mesajlar: 313
Kayıt: 13 Ara 2005 01:45
Konum: İzmir, ama Aydın Efesi!

Mesaj gönderen Terminator » 14 Ara 2005 04:49

Firebird satılık değil! kodunu satınalabilirsin, kopyalayabilirsin ama ruhunu asla! nihahahaa..

Oracle çaresiz şu anda, eskiden burnundan kıl aldırmazdı.
hatta biz oracle lisansı bile alamadık 1992 civarı, satmadılar!
çünkü aynı konuda iş yapan başka birini çözüm ortağı yapmışlar ve rakiplere veremezlermiş... hadi şimdi de söylesin bunu..
şimdi bana bedavaya dergi gönderiyor her ay, sitesinden 10g download serbest. stınalcam desem ayakkabılarımı bile yalayacak neredeyse..
hatta çok sıkıştı 5GB tam beleş ürün çıkardı.
MS in kısıtlı beleş engine i gibi..

Ürünleri o kadar şişti ve karmaşıklaştı ki, 3-5 mühendisle asla yaşatamazlar geliştiremezler.. yani arge ve test maliyetleri dağıtım maliyetleri destek maliyetleri çok yüksek. ama open source mimariler
aradaki fonksiyonellik açığını çok hızlı kapatıyorlar üstelik çok daha az eleman ve kısa kod altyapısıyla. Oracle gibi pahalı ve hantal ürün kullanan büyük firmalar maliyet yükü yüzünden piyasa kaybediyor.

Firebirdün müşterileri eskiden büyük uzay ve havacılık firmalarıymış,
ama borlanda geçtikten sonra kötü geliştirme yüzünden müşteriler diğer sistemlere geçmek zorunda kalmış.

Kullanıcı avatarı
Terminator
Üye
Mesajlar: 313
Kayıt: 13 Ara 2005 01:45
Konum: İzmir, ama Aydın Efesi!

Mesaj gönderen Terminator » 14 Ara 2005 05:11

Tabii ki nasıl yaptığı da bizim için önemli çünkü ucu yine bize dokunuyor. Önceki mesajımda da söyledim ms sqldeki locklanmalardan şikayetçiyiz. Ama tabi sadece mimari yeterli kalmadığı için mssqlin fonksiyonlarının çokluığuna değinmek istedim. FB dü bende bir projemde kullandım (1.5),tamamen yabancı değilim ve foreign keylerdeki duplicate index sorununu ben de yaşadım, bu sorunun 2 ile giderilmiş olmasına sevindim Bakalım FB dediğiniz gibi sağlam bir mimari ile gümbür gümbür geliyor.
Evet Naile,
FB ün en büyük üç sorunundan biri, FK gibi duplicate indexlerde kendini kaybetmesi(ilgili kaydı bulmak için o değerdeki indexi sequential taramak zorunda kalıyordu), SMP ve bellekten yararlanamaması idi. her üçü de çok hızlı çözüldü aslında geçen senelerde(index nodelara sadece küçük bir kayıt bilgisi eklendi)
ama codeun yeniden yapılandırılması ve testler uzun sürdü.
32 bit olan transaction numarasını da 64 bit olacak yakın gelecekteki versiyonlarda, bazılarının ihtiyaç duyduğu temp table özelliği de yazıldı, test ediliyor.
diğer sistemlerdeki kemikleşmiş açmazları kısıtlamaları dezavantajları gördükçe bu 3 günlük fani eksiklikler hiç önemsenmiyorum. birkaç sorundan geçici bir süre kaçınmak zor değil.
doğum bile sancılı ve riskli bi süreçtir ama sonuçları için değiyor olmalı ki 6 milyar insan var ve, her ay 2 izmir nüfusu artmaya devam ediyor. :)

Kullanıcı avatarı
sadettinpolat
Moderator
Mesajlar: 2126
Kayıt: 07 Ara 2003 02:51
Konum: Ankara
İletişim:

Mesaj gönderen sadettinpolat » 15 Ara 2005 09:53

hep fb nin mimarisinin ii oldugu oracle ve mssql in mimarisinin kotu oldugu vurgulanıyor.

hem oracle hem de ms dunyanin en cok kazanan yazilim firmalari hatta firmalari. diyelim ki oracle ve mssql in mimarisi kotu ve bu mimari uzerine daha fazla saglikli bir gelistirme yapmak mumkun degil. fb gibi open source bir proje bile kodlarını c den c++ 'a kisa bir surede tasiyabiliyorsa oracle ve ms gibi firmalar uygun mimariyle veritabanlarini 10 kere yeniden yazabilecek guce sahipler. zira ms windowsu 3 kere sifirdan yeniden yazdi bi veritabanini neden yazmasin ? ustelik mimarisi begenilen fb ve pgsql gibi sistemlerin kodu acikken ;)
"Sevmek, ne zaman vazgececegini bilmektir." dedi, bana.

---
http://sadettinpolat.blogspot.com/

Kullanıcı avatarı
musti
Üye
Mesajlar: 527
Kayıt: 11 Tem 2005 08:44

Mesaj gönderen musti » 15 Ara 2005 11:37

s.a.
firebird 2.0 ne zaman net kullanacaz. Bilgi verebilirmisiniz lütfen.

Kullanıcı avatarı
Terminator
Üye
Mesajlar: 313
Kayıt: 13 Ara 2005 01:45
Konum: İzmir, ama Aydın Efesi!

Mesaj gönderen Terminator » 15 Ara 2005 03:13

sadettinpolat yazdı:hep fb nin mimarisinin ii oldugu oracle ve mssql in mimarisinin kotu oldugu vurgulanıyor.

hem oracle hem de ms dunyanin en cok kazanan yazilim firmalari hatta firmalari. diyelim ki oracle ve mssql in mimarisi kotu ve bu mimari uzerine daha fazla saglikli bir gelistirme yapmak mumkun degil. fb gibi open source bir proje bile kodlarını c den c++ 'a kisa bir surede tasiyabiliyorsa oracle ve ms gibi firmalar uygun mimariyle veritabanlarini 10 kere yeniden yazabilecek guce sahipler. zira ms windowsu 3 kere sifirdan yeniden yazdi bi veritabanini neden yazmasin ? ustelik mimarisi begenilen fb ve pgsql gibi sistemlerin kodu acikken ;)

Kullanıcı avatarı
Terminator
Üye
Mesajlar: 313
Kayıt: 13 Ara 2005 01:45
Konum: İzmir, ama Aydın Efesi!

Mesaj gönderen Terminator » 15 Ara 2005 03:20

sadettinpolat yazdı:hep fb nin mimarisinin ii oldugu oracle ve mssql in mimarisinin kotu oldugu vurgulanıyor.

hem oracle hem de ms dunyanin en cok kazanan yazilim firmalari hatta firmalari. diyelim ki oracle ve mssql in mimarisi kotu ve bu mimari uzerine daha fazla saglikli bir gelistirme yapmak mumkun degil. fb gibi open source bir proje bile kodlarını c den c++ 'a kisa bir surede tasiyabiliyorsa oracle ve ms gibi firmalar uygun mimariyle veritabanlarini 10 kere yeniden yazabilecek guce sahipler. zira ms windowsu 3 kere sifirdan yeniden yazdi bi veritabanini neden yazmasin ? ustelik mimarisi begenilen fb ve pgsql gibi sistemlerin kodu acikken ;)
http://www.firebirdsql.org/devel/engine ... p2006.html

yok mimarileri kötü değil, mazoşistliğine sürekli mıncıklayıp duruyorlar ve değiştiriyorlar. Ben sadece FB mimarisi ilk günkü gibi diyorum ve tartışılmıyor diyorum. diğerlerinin nasıl olduğu pek de umrumda değil.
bir SQL engine nasıl çalışır, paylaşmak, saklamak, bulmak nasıl olur bunlar ilgilendiriyor beni. Hangisini beğendiysem ve kendi aklıma uygun bulduysam onu takdir ederim. diğer sistemleri seven ve sahip çıkanlara da saygı duyuyorum ama hayranlık babında değil, varlığa saygı...

Kullanıcı avatarı
recepgalip
Üye
Mesajlar: 60
Kayıt: 12 Haz 2003 03:50
Konum: Mersin/Rize
İletişim:

bu söylenenler guzelde.....

Mesaj gönderen recepgalip » 15 Ara 2005 05:38

merhabalar arkdaşlar. valla çok guzel bi moral oldu benim için diyebilriim . diyenizki niye bende firebird kullanıyorum. 08:00-16:00 arası oldukça yogun kayıtlı bi istemim var. şuan da 30-120 teminal arası çalışıyor. guzelde çalışıyor. ama sankim bazı sorunlarım oluoyr gibi orn.
yogunlugun en fazla oldugu zamanlarda firebird 300-350 mb arası bi ram yiyor makinada bazende tıkanıp kalıyor. serveri tekrar kapatıp açmam gerekiyor. server ole kucumsenecek bi serverda değil. ama bi turlu sebebini bulamadım.veri tabanı mimamrimin oldukça iyi oldugunu duşunuyorum. hatta yeni başlayacagım bi proje var bu projede her servera yaklaşı olarak 500-1000 kullanıcı arası kullanıcı bağlanacak ve mesai içinde surekli kayıt giirşleri olacak her ucun servera uzaklıgı 1km-150km arası değişecek. dedim borlanda yazı yazayım bu sistemi kaldırırmı çunku herkes oracle onerip duruyordu borlantçılar 50-100 arası olsa neyse(interbase7.1 için) bu yazıları okuyunca acaba dedim kayıt yogunlu max nekadarlık bi sistemde çalışlmışmışkine acaba. geçekten benimde oracle ile çalışmam işime gelmez ama mecbur kalınca insan. ne yapmalı kine. yoksam tum uygulamalarımı firebird den oracleye geçirmek zorunda kalacam.
ALLAH NAMINA VER.. ALLAH NAMINA AL.. ALLAH NAMINA BAŞLA.. ALLAH NAMINA İŞLE VESSELAM
SAYGILARIMLA BEN...

Kullanıcı avatarı
sadettinpolat
Moderator
Mesajlar: 2126
Kayıt: 07 Ara 2003 02:51
Konum: Ankara
İletişim:

Mesaj gönderen sadettinpolat » 15 Ara 2005 06:38

Terminator yazdı: FB ün en büyük üç sorunundan biri, FK gibi duplicate indexlerde kendini kaybetmesi(ilgili kaydı bulmak için o değerdeki indexi sequential taramak zorunda kalıyordu),
bu sorunu ben tam olarak anlayamadım ve senelerdir fb/ib kullanmama ağmen farketmedim. bu sorunun tam olarak ne olduğunu ve neden kaynaklandığını belirtebilir misiniz?
"Sevmek, ne zaman vazgececegini bilmektir." dedi, bana.

---
http://sadettinpolat.blogspot.com/

Kullanıcı avatarı
Terminator
Üye
Mesajlar: 313
Kayıt: 13 Ara 2005 01:45
Konum: İzmir, ama Aydın Efesi!

Mesaj gönderen Terminator » 15 Ara 2005 08:39

recep'e:
Korkmadan kullan recep, FB 1.5.x için 500 civarı fazla gelebilir uygulamalar çok yoğunsa. yani çok iyi bir organizasyonla ancak kaldırır.
Ama önümüzdeki aylarda FB 2.0 çıkıyor, testte olmasına rağmen birçok kişi kullanıyor bile. 2.0 senin kullanıcılarını kaldırır. aslında sorun FB ün
DB mimarisi değil, o mimariyi bazı açılardan kötü kullanan kodu.
sinek küçüktür ama mide bulandırır, FB de de interbase den gelen kodlama hataları var jim amcayı ve FB cüleri kızdıran, bunlar sistemi bazı
kullanım tarzlarında darboğaza sokuyor. yani sistem deli gibi gereksiz işlemler yapıyor. ayrıca yine yakında FB2.0 la hemen hemen aynı özelliklerde ama daha gelişmiş vulcan çıkacak SMP özellikli.
yani makina 1000 kişiye yetişemedi mi? koy 4-8 işlemci SMP çalışsın.
bu arada FB kurduğunuz makinalarda gereksiz proseslere izin vermeyin,
antivirus, cafcaflı ekran koruyucular, bir başka VT sistemi gibi..
ayrıca firebird.conf dosyasında projenin büyüklüğüne uygun ufak 2-3 satır düzeltmesiyle FB ü tıkanmadan uçurabilirsin.
çünkü FB sortlama için tanımlı büyüklükte ram kullanır. querylerin
index dışında sorta ihtiyaç duyduğunda kullanılır bu. ve hemen herkese lazım.
düşün 100 kullanıcın var ve her biri ortalama 3 dataset/query kullanıyor diyelim. bunlardan 2 tanesi bile sorta ihtiyaç duysa ortalama 2-3 MB lık bir alanda, sistemin 300 MB verebilmelidir. oysa veremez çünkü
firebird.conf da sort için 67 MB tanımlanmıştır. bu yetmediği için
FB başlar temp filelar üzerinden sort yapmaya..
ya kardeşim zaten disk IO bir bottleneck, bi de sort için IO yaparsan
FB db yi okuyup yazmak için iyice bi beklemek zorunda kalıyor.
DISKler rame ve CPU ya benzemez, asenkron çalışır ve mekaniktir.
her nasılsa, oracle kurarken 1 GB rame acımayan ahali, FB kurunca 256 MB ı bile çok görür. bu bir terbiyesizlik. FB o yüzden profesyonellerin tercihidir diyorum her yerde, kullanmasını bilmiyorsan bir boing 747 senin için dünyanın en yavaş ve ağır cihazıdır.

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.

Kullanıcı avatarı
sadettinpolat
Moderator
Mesajlar: 2126
Kayıt: 07 Ara 2003 02:51
Konum: Ankara
İletişim:

Mesaj gönderen sadettinpolat » 15 Ara 2005 08:48

@terminatör: yazdığın açıklayıcı bilgiler için teşekkür ederim. demekki bu sorunu gözle farkedebileceğim kadar çok duplicate indexim olmamış. artık olsa bile çözümü de öğrenmiş oldum :D
"Sevmek, ne zaman vazgececegini bilmektir." dedi, bana.

---
http://sadettinpolat.blogspot.com/

Kullanıcı avatarı
Terminator
Üye
Mesajlar: 313
Kayıt: 13 Ara 2005 01:45
Konum: İzmir, ama Aydın Efesi!

Mesaj gönderen Terminator » 15 Ara 2005 09:08

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..

highmemo

Mesaj gönderen highmemo » 16 Ara 2005 12:53

Recep bey ben 300 kullanıcı ya kada duymuştum yoğun bir veri girişi olan IB sistemini. Ama yineden çok iyi teknik bilgi ve donanım gerektirdiği kesin.

Ama sen 500-1000 kullanıcı diyorsan bilemem
Yarı yolda kalma..

Canlı örneklerini bulursan sistemlerin ve işleyişin özetini alırsan ii olur.
Buna göre davranman akıllıca olur.

FB 2.0 test ediliyor muş. Kullananlarda varmış sanırım. Ama unutmayalım
MS dünya çapında kullanılan uygulamarında bile. Sürekli buglar vs. çıkıyor.

Herhangi bir kesinti de , çıkmazda 1000 kişi etkilenecek
büyük sorumluluk.

sana tavsiyem ii düşün.

Cevapla