Vlákno názorů k článku
MySQL má nástupce InnoDB od xm - Skutečným killer storage enginem pro MySQL je Falcon....

  • Článek je starý, nové názory již nelze přidávat.
  • 30. 1. 2008 14:14

    xm (neregistrovaný)
    Skutečným killer storage enginem pro MySQL je Falcon. Má velmi moderní architekturu a vyvíjí ho samotný Jim Starkey (otec InterBase a databáze Firebird). MySQL 6 bude opravdu skvělá databáze, myslím že Oraclu začne dosti šlapat na paty.
  • 30. 1. 2008 14:30

    Lenin (neregistrovaný)
    Nojo kazdy rok slysime o tom jak bude ta nova verze MySQL skvela a jak natre ten Oracle.
  • 30. 1. 2008 15:06

    xm (neregistrovaný)
    A není to snad pravda? Srovnejte si co uměla MySQL 4 a co umí MySQL 5 - je to jak nebe a dudy, obrovitánský rozdíl. A nebo se podívejte na to, jak se Oracle neustále snažil MySQL škodit a dokonce jí i koupit - MySQL mu totiž skutečně uždibuje čím dál tím větší kousky z jeho koláče (i když je pozice Orucla stále neohrozitelná, všechno se může časem změnit).
  • 30. 1. 2008 19:58

    jb (neregistrovaný)
    Nojo, ale když MySQL 3 uměla SELECT, MySQL 4 uměla už i WHERE a MySQL 5 k tomu málu přidává transakce, tak je samozřejmě vidět pokrok.
  • 30. 1. 2008 14:31

    Pepa (neregistrovaný)
    "... myslím že Oraclu začne dosti šlapat na paty."

    Evidentně pán neví, co to je Oracle.
  • 30. 1. 2008 15:03

    xm (neregistrovaný)
    Ale vím, MySQL už dnes v některých segmentech databázového trhu na paty Oraclu šlape. A třeba i to že Google běží na MySQL o něčem vypovídá. Samozřejmě jsou části trhu kde Oracle má absolutní a zatím neohrozitelnou nadvládu, ale časem se všechno může změnit (neříkám však že už s další verzí MySQL, tak rychle to vážně nepůjde ;-)).

    Proč si myslíte, že se Oracle snažil MySQL nejdříve uškodit tím, že odkoupil firmy vyvíjející transakční databáze pro MySQL (nejdříve Sleepycat a jejich BerkeleyDB a pak Innobase a jejich InnoDB) a pak se snažil MySQL dokonce koupit celou (čemuž však lidi z MySQL naštěstí zabránili - radši prodali MySQL Sunu než Oraclu)? MySQL pro Oracle skutečně _je_ konkurence - byť jen v některých segmentech trhu. A uždibuje Oraclu stále větší a větší kousky z jeho koláče.
  • 30. 1. 2008 19:09

    anonymní
    Sorry, ale nedá mi to - v těch segmentech trhu na kterých vydělává Oracle je MySQL dost pozadu. Ono totiž velkým firmám často nejde o špičkový výkon, ale špičkovou spolehlivost a kontinuitu. O spolehlivosti MySQL vím bohužel svoje, a jako zrovna příklad kontinuity to také nevypadá. Ono je to sice hezky modulárně napsané takže věřím že přidávat další storage engine není až takový problém, ale nebylo by lepší mít jeden skutečně pořádný?

    Ne že by MySQL nebyla pro některé segmenty trhu zajímavá, ale co se skutečně velkých řešení týká tak mne namátkou napadá

    - má MySQL PITR?
    - má nějaké standardní clusterovací řešení?
    - má nějaké standardní replikační řešení?
    - umí dobře optimalizovat execution plany? (neptám se na query cache)

    A takových otázek je samozřejmě spousta ...

    Přiznávám že negativní vztah k MySQL jsem získal v době verze 3.23, ale ani verze 4 a 5 mne prostě nepřesvědčily. Mimo jiné benchmarky které jsem viděl většinou ukazovaly při vyšší zátěži problémy se zamykáním, takže s tou škálovatelností bych to v reálu neviděl tak růžově ...
  • 30. 1. 2008 20:29

    roman (neregistrovaný)
    Neviem, co je to PITR, mozem si to v pripade potreby vyhladat.
    Neviem, ci standartne, ale MySQL ma clusterovací řešení aj replikační řešení. "optimalizovat execution plany" - tazko povedat, co je dobre a co zle, ale ak sa ti nepaci, ako sa DB rozhodne mozes jej vnutit svoj plan. vela veci sa da vyriesit/zrychlit nastavenim servru. Ak sa robili tesy na MyISAM a konkurencne inserty, selecty, tak je jasne, ze svetlo nebolo ruzove. Od toho je v sucasnosti InnoDB. Co viem samotna MySQL DB zaberie v RAMke omoc menej, ako Oracle, takze mi ostane viac na cache, indexy. Chybaju mi zas bitmapove indexy, to vsak vyriesi Partitioning, ten je vsak sucastou 5.1, ktora este nie je stable a kto vie, kedy vyjde.
  • 31. 1. 2008 0:00

    anonymní
    PITR znamená "Point In Time Recovery" - zjednodušeně řečeno na začátku udělám celkovou zálohu a pak už zálohuji / replikuji transakční logy (nebo řešení zhruba v tomto smyslu). Čili když mi ve 13:44 lehne server, vezmu základní zálohu, doplním informace ze zálohovaných / replikovaných transakčních logů, a mám stav databáze ve 13:44. Případně se rozhodnu že chci DB ve stavu z 13:01, a dokážu se tam dostat. Celkem šikovná věcička, rozhodně asi o 1000000% lepší než když mi ve 13:44 lehne server a já mám zálohu z minulýho úterka ;-(

    Co se clusteru týká, tak o MySQL řešení mi ani nemluvte - to co vydali jako první ostrou verzi bylo kvalitativně tak možná na úrovni alfaverze. Ale ono je clusterování a clusterování.

    Co se týká zamykání, přiznávám že nevím jestli ten benchmark byl na MyISAM nebo InnoDB, nebo jak, a po těch několika 12˚ pivech holt nejsem schopen si vzpomenout kde jsem ho viděl ;-) Byl to jakýsi benchmark který porovnával tuším nová CPU AMD vs. Intel a současně MySQL vs. PostgreSQL, ale kde to bylo ... zkusím to zítra dohledat.

    Argument "MySQL zabere v paměti o moc menej ako Oracle" je myslím nesmysl - já jako uživatel chci aby databáze maximálně využívala zdroje počítače maximálně efektivně, takže pokud Oracle zabere víc pro sebe (a interní cachování) tak mi to vlastně nevadí. Oproti tomu třeba PostgreSQL jde opačnou cestou - cachování apod. ponechává v co největší míře na OS (Linuxu).

    Možná se pletu, ale bitmapové indexy a partitioning toho zase až tak společného nemají, ne? Nebo když budu mít 5 sloupců, v každém budu mít 10 hodnot, tak vznikne 100000 partitions? To asi nebude zrovna efektivní, ne? Rozhodně to nebude efektivní jako klasické bitmapové indexy ... Čili troufám si tvrdit že věta "chybaju mi bitmapove indexy, to vsak vyresi partitioning" je logicky nesmysl.
  • 31. 1. 2008 8:16

    Rejpal (neregistrovaný)
    "Čili když mi ve 13:44 lehne server, vezmu základní zálohu, doplním informace ze zálohovaných / replikovaných transakčních logů, a mám stav databáze ve 13:44. Případně se rozhodnu že chci DB ve stavu z 13:01, a dokážu se tam dostat. Celkem šikovná věcička, rozhodně asi o 1000000% lepší než když mi ve 13:44 lehne server a já mám zálohu z minulýho úterka ;-("
    Tak obnovení databáze ze zálohy a dopnění transakčních protokolů se dneska říká "point-in-time recovery"? No to nám teda přibylo honorifik. Kdysi se tomu říkalo prostě "obnovení ze zálohy". ;-) Myslel jsem, že to point-in-time se týká jen toho "vynech poslední hodinu", pokud tedy je někdo, kdo takovéhle věci potřebuje (a nevymýšlí si).
  • 31. 1. 2008 9:25

    Rado1 (neregistrovaný)
    "point-in-time" recovery je presne to, co pisal o par riadkov neskor. Chcem restore databazy do stavu v case 13:01, aj ked padla az o 13:44, pretoze viem, ze od 13:01 sa data sprasili.
    Pripadne "vcera sa admin ozral a v HR databaze vsetkym kolegyniam nastavil ako poznamku velkost prs - potrebujeme obnovu zo 17:00, to bol este triezvy"...
  • 31. 1. 2008 9:55

    roman (neregistrovaný)
    :-) pravda, ale ak nepotrebujem vsetkych 100k kombinacii, bude mi to stacit.
    ad "MySQL zabere v paměti o moc menej ako Oracle" myslel som cisto DB.
  • 30. 1. 2008 15:08

    Rejpal (neregistrovaný)
    A pán nade mnou zase neví, kdo je Jim Starkey, že? Od něj Oracle kdysi ve verzi tři (nebo tak něco?) obšlehnul několik fíčur, aby se měl od čeho odpíchnout, než šel do databázové základní školy druhého stupně. Na hardwaru, kterým disponují menší firmy, budou Firebird 3/Vulcan a MySQL/Falcon běhat kolem Oraclu v kruzích. Na větším železe nevím, ale Vulcan na 4-way stroji scaloval před dvěma lety na 350 % výkonu a nemyslím, že se to zhoršilo. (Jen není dost lidí na rychlejší integraci do větve Firebird 3. :-/)
  • 30. 1. 2008 19:51

    Miloslav Ponkrác
    Tak jo, až to uvidíme, pobavíme se. Do té doby si necháme pohádky na jindy.

    Ale bylo by taky záhodno, aby MySQL někdy dosáhla spolehlivosti Oracle, protože zatím to s ní jde pomalu, ale jistě z kopce. Aby to nedopadlo tak, že Falcon bude 4x rychlejší a data bude rovnou komprimovat při ukládání na nulovou velikost.

    Jsem zvědav, kdy konečně někdo pochopí, že db není jen o rychlosti, ale také o spolehlivosti, škálovatelnosti a velkých zátěžích. Takový Firebird při velké zátěži 100 uživatelů naráz je naprosto nepoužitelný - nic jiného, než nasadit lepší db nemůžete.
  • 30. 1. 2008 23:20

    Rejpal (neregistrovaný)
    Jestli máte Firebird nepoužitelný při sto uživatelích, tak asi něco děláte špatně (leda že by všichni dělali full table scany či co). Několik set uživatelů je v pohodě, problémy začínají u devíti set, kdy je třeba je začít multiplexování v middlewaru (ale totéž řešení používá třeba Informix). Možná jste měl na poslední konferenci přijet. ;-) Pokud jde o spolehlivost, opravdu Vám nestačí sever, který obsluhuje důležitá data v tanku a je zvyklý padat při výstřelu z kanónu, který palubní elektronika příliš dobře neustojí, a za pár desítek milisekund naběhnout bez poškození dat? (Teď samozřejmě nemluvím o MySQL).
  • 30. 1. 2008 23:39

    Miloslav Ponkrác
    Není nad to, co si člověk vyzkouší sám - zvláště v oblasti open software se schopnosti sw dost fanaticky nadsazují. Ničemu jinému se příliš nedá věřit.

    Jinak máte opravdu pocit, že neustálé resetování systému je klasický stav databází v bankách? Zkuste naběhnout do bankovního domu, nebo do nějaké nadnárodní firmy a nabídněte jim, že jim jejich důležitá data bude spravovat nad Firefoxem, neřku-li MySQL. Možná jim to bude připadat jako dobrý vtip, budou-li v dobrém rozmaru. Ono totiž u db je důležité více věcí, než pár papírových parametrů, nebo rychlost.

    Celé je to o tom, že je sice hezké, že nějaký Falcon a další mají skvělé vlastnosti (i když vlastně ani ještě pořádně neexistují, ale to tu nikomu nebrání kecat a prášit se mu od úst, jak jsou skvělé, proč taky taková drobnost). Právě na razanci a intenzitě obhajoby ještě neexistujících věcí a jejich vyzdvihováním jak jsou dobré je krásně vidět nesoudnost jejich zastánců. Až budou, pak si povíme - a jak to v praxi bývá, parametry Falconu budou na 99,999% mnohem výrazně slabší oproti nadšení jejich propagátorů - pokud vůbec nějaký Falcon se kdy dočká release verze, protože ani to není jisté.
  • 31. 1. 2008 0:12

    Rejpal (neregistrovaný)
    Jinak máte opravdu pocit, že neustálé resetování systému je klasický stav databází v bankách?
    I něco takového se ke mně doneslo. :-) O bankách bych pomlčel, jeden známý se zařekl, že bance, pro kterou programuje, už v životě peníze nesvěří. V tomhle případě ale armáda prostě zadala výběrové řízení a jediný SW, který vyhověl, byla Starkeyho Interbase. :-) Firefox bankám vnucovat nebudu, jeho databáze je poněkud slabá :-) (naposledy měl rozhraní pro sqlite).
    Právě na razanci a intenzitě obhajoby ještě neexistujících věcí a jejich vyzdvihováním jak jsou dobré je krásně vidět nesoudnost jejich zastánců.
    Jo, s Falconem Vám neporadím, nevím, co tam vařej, a jak dlouho jim to může trvat. Ale Vulcan si zkuste, až vyjde beta, třeba se Vám bude líbit. Kód je v podstatě hotový, problém je integrace do Firebirdu, protože Borland zku*il, zprasil atd. co mohl, a vývojáři přiznávají, že místo, do kterého se musí ten engine ve Firebirdu naroubovat, je hrozná změť. Takže to může chvilku trvat, prý mohou být tři integrační vlny, s meziverzí 2.5. Do té doby to budeme muset vydržet, Vy samozřejmě můžete dál křepčit nad Oraclem, který já si ho jako člověk s potřebou malých a nepřekážejících embedded vecí instalovat nebudu. ;-)
  • 31. 1. 2008 9:39

    Miloslav Ponkrác

    I něco takového se ke mně doneslo. :-) O bankách bych pomlčel, jeden známý se zařekl, že bance, pro kterou programuje, už v životě peníze nesvěří. V tomhle případě ale armáda prostě zadala výběrové řízení a jediný SW, který vyhověl, byla Starkeyho Interbase. :-) Firefox bankám vnucovat nebudu, jeho databáze je poněkud slabá :-) (naposledy měl rozhraní pro sqlite).

    Já si o pozadí bank také myslím leccos, ale zkrátka db, kterou vážně nasadíte musí být db, za kterou někdo stojí, někdo jí servisuje, a někdo na ní dává nějaké záruky, tj. že bude podporována ještě za x let a spoustu jiných záruk a to řadu let dopředu. Kromě toho to musí být prověřená db a musí mít i seriózní, vybudovanou značku. Nic z toho u Interbase/Firefoxu nemáte. Já osobně, kdybych se rozhodoval, tak se rozhoduji podobně. Db bez záruk o budoucnosti a o servise - ta prostě do ostrého nasazení na místa, kde na načem skutečně záleží zkrátka nepatří, i kdyby byla pozlacená, nejlepší a nejskvělejší.

    Ohledně resetování - běžná db snese tvrdý reset a je dělaná na to, že občasné sletění systému na ústa zvládne. Nicméně počítá se s tím, že to nebude obvyklý stav věci.

  • 31. 1. 2008 10:55

    Pavel Císař
    Komolení jména Firebirdu je opravdu dětinské. Profesionál který si je jist svými argumenty se k takovým věcem uchylovat nepotřebuje. Že by jste síle svých argumentů zase tak moc nevěřil?
  • 31. 1. 2008 11:17

    Miloslav Ponkrác
    Jestli je to jediný argument, který jste schopen vznést, pak je mi Vás líto. Chápu, že pro Vás, jakožto pro člověka je název db, který Vás živí něco co nespletete ani když Vás vzbudí o půlnoci. Vzhledem k tomu, že člověk běžně pracuje se stovkami názvů produktů je občasné zmýlení se v názvu celkem pochopitelné. Jinak snadno dohledáte, že zesměšňování názvů produktů není mým stylem.
  • 2. 2. 2008 20:31

    ldx (neregistrovaný)
    to myslite vazne?? takze kdyz budu komolit treba vase jmeno nebo jmeno firmy, ktera vas zamestnava, protoze si za zivot musim pamatovat stovky jmen, tak se nemusim omlouvat, vam to zajiste nebude vadit :-)
  • 2. 2. 2008 21:14

    Miloslav Ponkrác
    Mé jméno i příjmení je komoleno prakticky několikrát denně (neboť jméno je nezvyklé a příjmení se velmi podobá jedné pražské čtvrti) a problém z toho nedělám. Je totiž velký rozdíl mezi komolit a zesměšňovat. Komolení jméno mého zaměstnavatele, nebo produktu ve kterém dělám mi nevadí už vůbec - dokážu pochopit, že není v lidských silách si zapamatovat vše, co je na reklamních plakátech. Nehledě na to, že 99% jmen produktů má jepičí život. Takže pokud budete komolit mé jméno v dobré víře, že ho říkáte správně, není proč vyvolávat války, hádky atd.. Dokážu vycítit proč člověk komolí mé jméno a pokud to není úmyslné, opravdu mi to ani v nejmenším vadit nebude.

    Pokud zkomolím jméno člověka, okamžitě se omlouvám. Je to ryze osobní záležitost.

    Co se týká jmen produktu, opravdu není v lidských silách vše pobrat. A to nemluvím o fanaticích, kteří Linux fanaticky opravují na GNU/Linux, OpenOffice na OpenOffice.org atd.. To opravdu podporovat nechci a nehodlám.
  • 3. 2. 2008 11:20

    ldx (neregistrovaný)
    a vy jste komolil firebird v dobre vire? vzhledem k tomu, jak se vyjadrujete o linuxu a jakychsi fanaticich o tom dost pochybuju. vase deformace osobnosti kvuli vasemu jmenu nikoho nezajima, nechte se treba prejmenovat (zakon v oduvodnenych pripadech jiz umoznuje) anebo si zvolte nejakou prezdivku, pod kterou vas lidi budou znat, ale uz boha jeho nekomolte pojmy!
  • 3. 2. 2008 12:39

    Miloslav Ponkrác
    Stačí si přečíst Váš příspěvek a je naprostojasné, že jste ztratil soudnost. Že z Vás čiší snaha mě poškodit, a že Firebird je pro Vás jenom záminka, která Vám má pomoci, ale ve skutečnosti tu o to nejde. Na jedné straně se ptáte, jestli by mi vadilo, kdyby mě někdo komolil jméno, teď píšete že moje jméno nikoho nezajímá. Prostě kdo chce psa bít, hůl si vždycky najde - Vám nejde vůbec o zkomolení jména Firebirdu, Vám jde jen o to, že nezvládáte svojí nenávist.

    Já jen doufám, že až Vy jednou zkomolíte nějaký pojem v dobré víře, že budete k sobě stejně přísný jako teď prezentujete a necháte se pro výstrahu zastřelit, protože žádný menší trest za komolení jména samozřejmě nemůžete přijmout.
  • 3. 2. 2008 12:59

    ldx (neregistrovaný)
    kdyby jste cetl co jsem napsal, tak tam stalo, ze vase osobni deformace, ktera vyplyva z vaseho jmena nikoho nezajima. namisto toho reagujete jako typicky paranoidni psychopat, ktery si mysli, ze ho kazdy ohrozuje, takze REaguje slovy, kde se to hemzi zastrelenim a podobnymi, agresivnimi, vylevy. je mi vas lito.
  • 3. 2. 2008 16:31

    Miloslav Ponkrác
    Hm, začínáte být čím dál více nesoudný, a Vaši agresivitu, nenávist a další už ani neskrýváte. Podle sebe soudím Tebe - vše co mi přisuzujete jsou Vaše vlasnosti. Prostě mě chcete setřít, tak do toho. Toto je totiž moje poslední reakce na Vás - plně se rozepište o mých nejhorších vlastnotech, pořádně mi to nandejte, a využijte toho. Já totiž Vaše reakce nechám zcela bez odezvy, takže se snažte.
  • 3. 2. 2008 16:36

    Miloslav Ponkrác
    Vidím, že moje osoba Vás zaujala. Samozřejmě mým fanouškům nehodlám nijak bránit a naopak jim pomáhám co můžu. Stačí napsat mail a klidně se Vám i podepíšu do deníčku. :-) Jinak tady jsme na internetu pane, nehodlám nic potvrzovat, ani vyvracet.
  • 31. 1. 2008 9:44

    Miloslav Ponkrác

    Jo, s Falconem Vám neporadím, nevím, co tam vařej, a jak dlouho jim to může trvat. Ale Vulcan si zkuste, až vyjde beta, třeba se Vám bude líbit. Kód je v podstatě hotový, problém je integrace do Firebirdu, protože Borland zku*il, zprasil atd. co mohl, a vývojáři přiznávají, že místo, do kterého se musí ten engine ve Firebirdu naroubovat, je hrozná změť. Takže to může chvilku trvat, prý mohou být tři integrační vlny, s meziverzí 2.5. Do té doby to budeme muset vydržet, Vy samozřejmě můžete dál křepčit nad Oraclem, který já si ho jako člověk s potřebou malých a nepřekážejících embedded vecí instalovat nebudu. ;-)

    Já nepotřebuji radit s Falconem - ale všimněte si, jak tu spousta lidí uvádí jeho vlastnosti, včetně toho, že Oracle se potom půjde zahrabat. Buď jsoum totálně zhulení, nebo opilí až namol, nebo dokonale nesoudní. Stačí se podívat do historie na bombastické uvádění různých vaporware, či na to, jak přehnané příznivé vlastnosti jsou dávány všemu co se plánuje a jak se schlípýma ušima se pak dívají manažeři, či technici na tu hrůzu, až to naplánované vznikne. Takže oslavování Falcona je hovadina - až tu bude povíme si (pokud vůbec někdy bude), dokud ne - byl bych při zemi.

  • 31. 1. 2008 9:50

    Miloslav Ponkrác

    Kód je v podstatě hotový, problém je integrace do Firebirdu, protože Borland zku*il, zprasil atd. co mohl, a vývojáři přiznávají, že místo, do kterého se musí ten engine ve Firebirdu naroubovat, je hrozná změť.

    Ideální případ - vývojáři to prostě mají na koho svést, jsou z obliga. A Borlandu se nic nestane, když se na něj snese nějaká ta špína a vývojářům to pomůže, tak co.

    Každý program má takovou architekturu, se kterou počítá při návrhu - pokud si vymyslím něco neobvyklého (platí pro jakýkoli sw i ten nejčistější a nejlépe navržený), na který původní architektura programu nebyla připravena, pak samozřejmě dojde k podstatnému přepisu. Házet ovšem ještě navíc špínu na hlavu Borlandu, tím se u mě vývojáři Firefoxu hodně shodili. Protože to je stejné, jako skočit z okna a nadávat, že jsem si zlomil nohu.

  • 31. 1. 2008 10:49

    Pavel Císař
    Vážený pane, mohu vás ujistit že řada bank a nadnárodních firem svá důležitá data ve Firebirdu spravuje. Bohužel nemohu příliš hýřit jmény, protože bez jejich souhlasu o interních operacích našich zákazníků mluvit nelze. Nicméně o takovém MICEX (Moscow Currency Exchange) se to obecně ví (Firebird na HP-UX je už mnoho let v centru veškeré výměny peněz mezi Ruskými bankami). Řada Fortune 500 firem využívajících služeb SAS Institute vlastně také používá Firebird (jádrem nové platformy je Vulcan, v budoucnu pak Firebird 3). A to nemluvím o bezpočtu nasazení Firebird embedded v klientských a mobilních aplikacích (ten používají nejen banky, ale i např. takový německý T-Mobil). A to jsou jen klíčové aplikace u velkých firem, nasazení v podpůrných projektech a department-level aplikacích je nepočítaně. Nicméně finanční ústavy a nadnárodní firmy nejsou nijak zvláštní zákazníci, protože i pro menší firmy a instituce jsou jejich data významná. Co třeba takové nemocnice, že? Firebird jich používá docela dost.
  • 31. 1. 2008 11:10

    Miloslav Ponkrác
    Ano, řada důležitých dat se spravuje ve Firebirdu, akorát se nesmí říkat kdo. Skvělé a naprosto přesvědčující.

    Velmi pochybuji, že hlavní databáze a hlavní data budou u banky, nebo nadnárodním koncernu ve Firebirdu. Že se pár nezodpovědných ústavů najde, o tom vůbec nepochybuji , ostatně stejně tak jako jsou zodpovědné firmy vážících si svých dat a nezodpovědné, které na to kašlou je zcela normální.

    V mobilních aplikacích je samozřejmě Firebird zcela na místě, protože tam jen málokdy jde o klíčová data, jejichž ztráta by byla nenahraditelná. Zajisté se shodneme, že mluvit o Oracle, nebo DB2 v mobilech jaksi nesvědčí o zdravém rozumu. V podpůrných projektech a podobně není až tak kritické, co se tam nasadí.

    Ohledně nemocnic vím dost a řeknu to tak, že bych brečel. Nejenom ohledně sw zázemí a dalšího, ale i ohledně dalších procesů, různých vyvedených penězotoků...
  • 31. 1. 2008 12:12

    Pavel Císař

    Ano, řada důležitých dat se spravuje ve Firebirdu, akorát se nesmí říkat kdo. Skvělé a naprosto přesvědčující.

    V obchodní praxi je zcela běžné, že neveřejné informace o svých zákaznících nesdělujete bez jejich souhlasu. Nedělá to ani Oracle, IBM nebo Microsoft. Bohužel jste se ptal po existenci uživatelů Firebirdu, kteří zrovna spadají do kategorie obzvláště paranoidních pokud se zveřejňování informací týče, takže je mi opravdu líto, ale bez jejich souhlasu si je nedovolím ani jmenovat. Že vám mé slovo nestačí, je politováníhodné. Nicméně známých významných uživatelů Firebirdu je hodně, a některé z nich jsem vám vypsal již při jiné příležitosti (snadno si je v případě zájmu dohledáte).

    Velmi pochybuji, že hlavní databáze a hlavní data budou u banky, nebo nadnárodním koncernu ve Firebirdu.

    Skutečně velké společnosti nemají "hlavní data" (u společností tohoto typu je těžké vůbec určit, která data *nejsou* hlavní) v jediné databázi, ale jedná se o poměrně komplexní provázaný systém HW, databází a aplikací, a málokterá společnost má "hlavní" data spravovaná v jediném typu databázovém systému (např. Oracle nebo Firebird). Firebird se v takovýchto institucích používá, ale typicky to není jediný databázový systém, který používají, stejně jako nepoužívají jen Oracle nebo něco jiného.

    Že se pár nezodpovědných ústavů najde, o tom vůbec nepochybuji , ostatně stejně tak jako jsou zodpovědné firmy vážících si svých dat a nezodpovědné, které na to kašlou je zcela normální.

    Je opravdu ostudné, jak jsou tyto firmy nezodpovědné. Svěřit svá data Vulcanu je přeci nesmysl!

  • 31. 1. 2008 12:35

    Miloslav Ponkrác
    Pane Císaři, nechme toho. Vraťme to na začátek - já jsem tu psal svoje názory na db, o Firebirdu jsem se zmínil jen okrajově. Je mi jasné, když to řeknu natvrdo a upřímně - Vy jste z Firebirdu živ - a je celkem očekávatelné, že chválou Firebirdu zaplníte každý patník, neboť jsou to penízky pro Vás.

    Všimněte si, že násilně protlačujete Firebird, kde se dá. Mě jste dokonce napadl za to, že jsem zkomolil jméno Firebirdu, což je sice pravda, nicméně pokud z kontextu bylo jasně vidět, že to nebyl záměr, nýbrž překlep.

    Vaše slovo mi nestačí, protože - nezlobte se, myslím to v dobrém - nejste v otázkách Firebirdu nestranná osoba. Jste s ním finančně i jinak svázán, a je ve Vašem vlastním zájmu, aby Firebird byl protlačován všude, i když by se tam třeba hodila lépe jiná db. Stejně tak, jako Billu Gatesovi a Steve Ballmerovi nebudu věřit vše co říká o Windows - protože má ohledně Windows své finanční zájmy, stejně tak nemohu od Vás bezduše a bez důkazů přebírat Vámi řečené o Firebirdu. Vaše slovo mi bude stačit v jakémkoli jiném případě.

    Kdybych navázal na zbytek - vzhledem k tomu jak sám tvrdíte, že velké společnosti tají podrobnosti o svých databázích a Vy víte o té Firebird části (a pravděpodobně ani Vám nesdělili podrobnosti o své datové strategii), pravdu se stejně nedozvíme a tím bych zbytek textu považoval za irelevantní.

    Aby bylo jasné, nepovažuji FB za špatnou databázi a myslím, že moje výhrady znáte a koneckonců jsem je sem také napsal. A teď o čem tu píšu - jen o tom, jaké věci považuji u db za důležité, přičemž o Firebirdu tu dokonce ani není hlavní řeč, ta je o MySQL. Protože právě teď celý svět sleduje co se bude dít s MySQL, neboť v poslední době se kolem MySQL událo dost zajímavých událostí : koupě InnoDb Oraclem, koupě firmy Sunem, vývoj Marii a Falconu a je zajímavé si zavěštit a zahrát na proroka.
  • 31. 1. 2008 13:46

    Pavel Císař

    Vraťme to na začátek - já jsem tu psal svoje názory na db, o Firebirdu jsem se zmínil jen okrajově. Je mi jasné, když to řeknu natvrdo a upřímně - Vy jste z Firebirdu živ - a je celkem očekávatelné, že chválou Firebirdu zaplníte každý patník, neboť jsou to penízky pro Vás.

    Poněkud si pletete dojmy s pojmy. Vy jste se ptal na uživatele, a já odpovídal, což je na hony vzdáleno jakémukoliv vychvalování (a navíc o vlastnostech Firebirdu nepadla ani zmínka).

    Vaše slovo mi nestačí, protože - nezlobte se, myslím to v dobrém - nejste v otázkách Firebirdu nestranná osoba. Jste s ním finančně i jinak svázán, a je ve Vašem vlastním zájmu, aby Firebird byl protlačován všude, i když by se tam třeba hodila lépe jiná db.

    To bych chápal v případě, že by byla řeč o vlastnostech nebo schopnostech Firebirdu. Tady byla ovšem řeč o zákaznících naší společnosti, a vy zpochybňujete mé slovo, že mezi našimi klienty jsou i známé finanční ústavy a státní instituce.

    Očividně si pletete Firebird a IBPhoenix. I kdyby všichni nakrásno používali Firebird, tak to vůbec neznamená, že z toho budu mít byť jen pětník. Firebird je zdarma pro každého, a opravdu z něho nemám ani korunu (naopak mě stojí čas a peníze). Obživu mám teprve ze společností, které se rozhodnou využít našich služeb. V podstatě si na chleba vydělávám jen díky některým (protože zdaleka ne všem) velkým a bohatým uživatelům Firebirdu, o jejichž existenci pochybujete. Navíc již řadu let je uživatelů Firebirdu několikařádově více než by byla naše společnost v současnosti schopna obsloužit kdyby se byť jen setina z nich dožadovala našich služeb, takže z čistě obchodního hlediska mi vskutku nesejde na tom, zda bude Firebird používat někdo další či nikoliv.

    A teď o čem tu píšu - jen o tom, jaké věci považuji u db za důležité, přičemž o Firebirdu tu dokonce ani není hlavní řeč, ta je o MySQL. Protože právě teď celý svět sleduje co se bude dít s MySQL, neboť v poslední době se kolem MySQL událo dost zajímavých událostí : koupě InnoDb Oraclem, koupě firmy Sunem, vývoj Marii a Falconu a je zajímavé si zavěštit a zahrát na proroka.

    Bohužel jste příliš nevěštil, pouze projevoval pochybnosti. Pokud chcete nějakou věštbu, pak tady jednu máte: Díky koupi Sunem jsou teď kluci z MySQL AB za vodou, a mají z krku trable s IPO a netrpělivými VC investory. Nemusí teď moc spěchat a mohou si vymýšlet blbosti typu Maria. Každý případný neúspěch se teď dá svalit na špatné zacházení a nepochopení ze strany Sunu. Sun využije MySQL aby prodal více železa jistým společnostem, a hlavně ji využije jako argument při manévrování s komunitou a některými partnery i protivníky. Ale jinak se nic zásadního dít nebude. Maria bude v konečném důsledku jen plácnutí do vody bez zásadního úspěchu, protože Monty je prostě Monty, a nic lepšího od něj čekat nelze. Falcon se bude ladit tak dlouho, dokud to bude Jima bavit. Pak Jim uteče za zajímavějším projektem (v rámci Sunu nebo úplně jinam), nejspíš ještě před naprostým dokončením. Existence MySQL v rámci Sunu bude plná pouze velkých PR kroků bez zásadního posunu kamkoliv (jinak řečeno bude mnoho povyku pro nic), vše se bude pouze více a více komplikovat. Díky technické roztříštěnosti a licenčním komplikacím budou Open Source projekty méně a méně využívat primárně MySQL, a zaměří se na podporu jiných databází, a v rámci LAMP stacku bude MySQL v průběhu následujících tří let postupně nahrazována jinými databázemi. Do pěti let bude MySQL de facto jen další databází, o které se nebude nebo možná bude mluvit tolik jako dnes (ale v jiných souvislostech).

  • 31. 1. 2008 16:38

    Lenin (neregistrovaný)
    Zverejnovani informaci na cem se jede nema nic do cineni s tim zda je organizace paranoidni nebo ne. Je to otazka navratnosti investic. Ve sve organizaci to taky nezverejnujeme.

    Jednak, co je komu do toho na cem jedeme pokud se to nepotrebuje pro audit a za druhe tim zverejnenim neziskame zadnou podstatnou vyhodu a tak neni duvod delat nejake PR okolo toho, ze jsme si koupili nove zelezo a novy soft.
  • 31. 1. 2008 16:32

    Lenin (neregistrovaný)
    Nojo, ale rusaci to jsou socky, to nemaj par podelanejch mega na Oracle. Kdyby firebird nebyl zadarmo, nestekl by po nem ani pes.
  • 31. 1. 2008 17:13

    Pavel Císař
    1. Představa že Rusové jsou socky je opravdu úsměvná. Lidé jsou možná vesměs chudí, ale mnoho organizací je bohatších než průměrný stát třetího světa (obzvláště mají-li co do činění s peněžnictvím nebo nerostným bohatstvím). Pro MICEX nebyl a není problém zaplatit za cokoliv.

    2. MICEX původně používal InterBase 3 pro HP-UX, která samozřejmě nebyla zadarmo. Bohužel Borland přestal InterBase pro HP-UX podporovat, takže pokud chtěli novější a udržovanou databázi, museli přejít na Firebird. Pokud vím, jsou velmi spokojení.
  • 31. 1. 2008 23:20

    Lenin (neregistrovaný)
    Vdyz to rikam. Proc jel na Interbazi a ne na Oraclu, ktery toho umel i v te dobe vic? Proste na nej nemeli a tak si koupili levnejsi soft.

    Taky jsme onehda jeli na Informixu pac se sefum zdal ten Oracle moc drahej, nakonec jsme ale po velkych problemech s informixem nakonec ten Oracle koupili a mame klid.

    Cena je validnim parametrem rozhodovaciho procesu, ale uz nema co do cineni s tim zda je produkt X lepsi nez produkt Y.
  • 1. 2. 2008 11:01

    Pavel Císař
    Že toho nějaký produkt umí víc ještě neznamená, že je pro danou úlohu lepší. Rovněž mě fascinuje vaše schopnost šmahem rozpoznat motivace a ohodnotit rozhodovací schopnosti jiných bez nejmenší znalosti situace. Chápu, že asi máte špatnou zkušenost, ale automaticky přisuzovat vlastní omyly jiným je krátkozraké.
  • 1. 2. 2008 14:10

    Ondřej Tůma (neregistrovaný)
    Tohle mi neda:

    Budete se divit ale v takove ceske sporitelne to funguje tak, ze se proste v konkretni casy pravidelne restartuji vsechny servery, bez ohledu na to, na jake platforme bezi. Tedy vim ze to tak jeste loni bylo.

    Zaroven vim, ze ebanka (jeste pred spojenim s RB) uvazovala ve smyslu - udelame SW prasarnu - to neva, to se dozene hardwarem. A Dosti vazne se uvazovalo ze databazova logika, tenkrat postavena na Oraclu se proste kompletne prehodi do Javy a db bude jen uloziste. Uz nevim jak to dopadlo, ale toto byl opravdovy plan.

    Takze prosim nevykladejte jak to v tech bankovnich domech funguje uzasne. Prasata jsou totiz vsude, a rozdil mezi Oraclem a MySQL je primarne v nasazeni, sekundarne v pouzivani !! Proste se ta db musi pouzivat a konfigurovat jinak.
  • 30. 1. 2008 15:39

    Miloš (neregistrovaný)
    Jistě. to bylo přehnané. Ale určitě má MySQL potenciál účině bránit Oraclu v pronikání na nová teritoria. Výhledově si dokážu více představit užívání MySQL v menších firemních aplikacích než užívání Oraclu na Webu. Jistě nemůže konkurovat Oraclu obecně. Ale existují styčné body, kde se obě databáze potkat mohou a tam už neustále zlepšovaná MySQL představuje potenciální hrozbu. Ví to Oracle a ví to i Sun.
    Jinak vývoj nových enginů je pozitivní zpráva i pro toho, kdo MySQL zrovna nefandí. Vývoj v této oblasti je přeci pro databáze klíčový. Tak ať se ledy hejbaj.
  • 30. 1. 2008 20:00

    Miloslav Ponkrác
    Myslím si, že na vody MySQL si to šine většina db strojů v podobné kategorii db. Například MySQL na Windows byla prakticky vytlačena pomocí MS SQL a pro embedded věci pomocí sqlite a Access. Proč? Protože licence (zmíněné náhrady MySQL jsou zcela zdarma) a protože MySQL je na to co umí příliš drahá. Z druhé strany i pro jiné platformy konkuruje Firebird, když bych měl definovat to nejrozšířenější.

    U Oracle je to tak, že kdyby měli vůli, tak tento segment převálcují podle mě rovněž, nicméně oni jdou po větších segmentech.

    Vývoj nových db enginů je jistě pozitivní zpráva, ale zatím firma MySQL AB ještě nikdy nic pořádného nevyvinula. Jen wrapper, do kterého šoupali cizí enginy vyvinuté někdým jiným (nepočítám MyISAM, který toho mnoho neumí). Proto taky je tak ohrožují koupě těchto enginů jinými firmami. Na db standardy MySQL taky zvysoka kašle.
  • 31. 1. 2008 1:42

    Miloš (neregistrovaný)
    Už mě to trochu unavuje. Tvrdím, že žádná z přetřásaných databází není špatná. Zato je plno naprosto tragicky napsaných aplikací. Viděl jsem pro Oracle napsaný takový sračky, až se mi chtělo brečet. Databáze za to pochopitelně nemůže. Kdekdo vybírá nejrychlejší a nejdokonalejší databázi a pak napíše aplikaci, která jí stonásobně zpomalí. Zděsilo mě, když např. zarytý oraclista v jedné diskuzi tvrdil, že nějaké snahy o kánonický tvar jsou k ničemu a že je lepší nacpat všechno do jediný tabulky, protože prej dnešní disky jsou rychlý. On si zřejmě myslí, že když pracuje s Oraclem, je prostě machr, extra třída a profík, i když píše sračky. A z toho také pramení pohrdání těmi, kteří užívají databáze méně luxusní.
    Prostě si myslím, že na dobře napsané aplikaci záleží víc než na typu databáze. A prosadí se prostě ta, pro kterou se bude psát víc aplikací. Protože databáze samotná je k ničemu.
  • 31. 1. 2008 9:28

    Miloslav Ponkrác
    Souhlasím s Vámi, že spousta aplikací je špatně napsaných. Je to prostě pokrokem, před určitým časem programátor, nebo databázista musel být člověk s hlubokými znalostmi, dneska je programátor kdekdo, kdo zvládne naklikat pár formulářů a když do toho zvládne udělat i menu, pak je senior programátor. Prosím, teď ani trochu nenadsazuji, ale popisuji reálný stav. U databázistů profesionálů už se také nedivím naprosto ničemu. Zkrátka neviditelná ruka trhu má více ekonomické působení, než aby to bylo o kvalitě.

    Jinak žádná z přetřásaných db opravdu žádná sračka není, i když o MySQL už si to začínám pomalu myslet. Počet chyb, které u MySQL nalézám roste a zatímco dříve se dalo na MySQL spolehnout, dnes už běžně dost chybuje. A nespolehlivá db je o ničem.

    To machrování je všude - takové rozšířené typy machrování skupin lidí, kterým narůstá nosánek hodně nahoru je - "já jsem Javista, ostatní jsou podlidi", pak dlouho dlouho nic, pak mnohem slabší machrování typu "cokoli kromě Oracle je sračka", nebo "cokoli co není GPL je špatné a je třeba to násilím převést na GPL".

    Jinak abych řekl pravdu, mě chybí spíše malá až střední db, kterou bych mohl používat bundlovanou s aplikací. Nejnadějnější kandidát pro mě je sqlite. Firefox používat pro tyto účely nechci díky tragickému stavu dokumentace - takže černou skříňku používat nechci. MySQL nechci kvůli licenci, vychází dosti draho a také proto, že jsou její vlastnosti nejisté.
  • 31. 1. 2008 10:17

    Analytik (neregistrovaný)
    Víte přátelé, sedím v bance už nějaký čas a můžu vám říci, že to co se prezentuje od mnohých subdodavatelů je tragedie. Tak například - cca. dvouletý vývoj pod RUPem a nevím čím aplikace pro web na (Autocenzored) - například objednávkový systém. Mne šokoval tím, že skvělý engine postavený na řízení procesů, javě, web sphere a orákulu měl takový výkon, že zvládal realizovat 5 objednávek via https za hodinu. Pak to lehlo.
    A víte kde byla a doposud je tragdie? Právě ve špatném návrhu DB tabulek arákula.
    Při cca. 130 záznamech mi totiž komplexní výpis všech informací ze všech tabulek trval (při použití PL/SQL na 100-kové síti hned vedle serveru) btto 1800 vteřin.

    Pánové - je mi jedno na čem to běží. Mne nezajímá je-li to MYSQL a nebo Orákulum.
    Ale tohle - to byl šok.
    A co na to dodavatel - inu. On je přeci ve fázi optimalizace struktury a výkonu (blekotal jen o výkonu).

    Takže lidově řečeno - ona i blbá foxka může být rychlejší.
    Jinými slovy - výsledek záleží na všech komponentách systému a ne jen na DB Enginu.

    Dále k vašim předchozím cancům o restartech DB v bankách.
    No nevím jak by jste svoje (pro mne přiblblá tvrzení) vysvětlovali akcionářům.
    Restart serveru s DB Enginem a jinými službami trvá asi 1 hodinu, někdy i více času žere to.
    A víte kolik je u nás v bance cena 1 - slovy jedné - hodiny výpočetního času tohoto serveru ?
    Tak seďte. 1 000 000 USD. Slovy jeden milion amerických dolarů.

    A tak bych rád slyšel vaše rady typu - no, někde nám to zatuhlo. Asi to budete muset restartovat.

    :)))))))))))))))))))))))))))))))))))))))))))))))))))

    Takže opět - ne-li něco začneme tvrdit, tak si uvědomme, o čem to vlastně je.
    O stabilitě, výkonu a odpovědnosti.
    Vše ostatní jsou jen akademické řeči a to jsou přesně ty řeči, které zde prezentujete.

    Czus
  • 31. 1. 2008 10:56

    Miloslav Ponkrác

    Víte přátelé, sedím v bance už nějaký čas a můžu vám říci, že to co se prezentuje od mnohých subdodavatelů je tragedie.

    Nesedím v bance, ale naprosto souhlasím.

    dvouletý vývoj pod RUPem

    Mnoho lidí si myslí, že použijí RUP a bude všechno skvělé. Ale to je běžný stav - mnoho firem po nasazení ISO 9001 šlo do háje s kvalitou, protože kvalitu jim přeci hlídá to ISO.

    Takže lidově řečeno - ona i blbá foxka může být rychlejší.

    Přesně tak. Ono totiž záleží na celém vyvážení všech součástí řetězce. Jenže v poslední době se tu pořád melou jména technologií, a houby z toho.

    Takže opět - ne-li něco začneme tvrdit, tak si uvědomme, o čem to vlastně je. O stabilitě, výkonu a odpovědnosti.

    Naprosto to tak je.

    Ale jinak mám raději sw, který je třeba horší, pomalejší - ale je na něho spolehnutí, má dobrou dokumentaci a to co deklaruje, taky bez problémů a bez řečí provádí. Bombastické řeči a efekty už ve mě vyvolávají varovné světélko. Nedělám sice momentálně pro banky, ale on spolehlivý sw je taky o tom, že něco udělám a můžu jít s někým na večeři, nebo někam. A nemusím trávit čas tím, že hledám, kde se zase sw podělal a dělat betatestera, nebo trávit čas tím, že se snažím zjistit informace, které by normálně byly v základní dokumentaci.

    Každý sw, který rutinně a dlouhodobě chci používat si sám testnu (případně si předávám zkušenosti s pragmatickými lidmi podobného ražení) - a mám dost dlouhou praxi abych věděl, kam šťournout. Pak se taky dívám na to, jak dobrá je dokumentace (bez dobré dokumentace do toho vůbec nejdu - viz Firefox), jak je sw spolehlivý, jaká je šance, že tu ještě bude za pár let, jaká je architektura programu (hodně napoví o spolehlivosti i o mnoha dalších věcech). Hodně důležitá věc, skoro klíčová je licence sw - k čemu je učit se třeba GPL knihovnu, když vím, že ze mě GPL kód nepadá a padat nebude (padá ze mě public domain, BSD, nebo komerční)?

    Pokud pak takový sw používám, pak klidně k němu přispěju, buď si ho zaplatím, nebo klidně napíšu, nebo opravím část kódu.

  • 31. 1. 2008 12:22

    Pavel Císař
    K Firebirdu je dokumentace špičková, jen není zadarmo. Bezplatně dostupná dokumentace sice není učesaná a sjednocená do jedné-dvou knih, ale *je* kompletní.