Open source databáze pronikají stále více do komerčního prostředí

Diskuze čtenářů k článku

Tomáš  |  27. 08. 2005 19:33

Používám již 12 let *.dbf Approach není to dobré pro internet ani velké firmy ,ale pro osobní užití super chodí to od w95 až po w XP je to rychlé a kvalitní jen škoda že si toho lidé nevšimly prostě to Lotusy nezvládly s propagací a později ukončili vývoj .

Souhlasím  |  Nesouhlasím  |  Odpovědět
honza  |  11. 08. 2005 22:54

ja uz delam 25 let do ekonomickych aplikaci a pouzivam vetsinou isam-file-systemy. Jeste se mi nestalo, ze by se nejaka data ztratila, nebo bylo neco blbe. zato jsem uz mnohokrat zazil, ze ze sblaznil raid5-controller a zapsal i pod oracle na harddisk uplnej salat - bez zalohy by byla firma hotova. Nepocitam u tech 'super-databazi" kolikrat se vsechno zastavi, protoze pretecou logy, nebo je nestaci admin vubec odzalohovat. To tedy jako k te bezpecnosti dat, transakcim a recovery.

Trigerry jsou krasna vec, zejmena tehdy, kdyz se aplikace rozjizdi. Data nemohou byt v zacatku vubec konzistentni a mily admin ma plny brejle deaktivace trigerru pro ten ktery testovaci stav dat. Vysledkem je nadherny gulas za behu aplikace, protoze polovinu deaktivovanych trigerru nekdo zapomnel aktivovat.

Pohledy jsou potreba, zejmena tehdy, kdyz je jen trochu slozitejsi pozadavek. Napr. kdyz se ma zjistit pro nejakou zakazku, kdy je mozna dodavka na zaklade materialu a casu ve vyrobe. Takovy SQL-statement (super-slozeny dotaz) se vejde tak na 20 A4-stranek a samozrejme ho kazdy sql-parser odmitne s pozadavkem, aby to laskave programator zjednodusil. Takze se to rozseka budto do pohledu nebo se pouziji storage-procedury. Protoze je silne potreba rekurze, tak nakonec nezbyde nic jineho, nez data natahat do C-struktur a vyridit to v pameti (alespon to bezi rychle) - samozrejme ze se rekne zakaznikovi - zadny strach - transakce mame.

Storage-procedury maji take tu vyhodu, ze jsou vazany na konkretni databazi a proto kdyz se objevi zakaznik, ktery by si produkt koupil ale provozuje jiz jinou db, tak tomu je mozno hned sdelit at jde ke konkurenci a tim se setri naklady na vypracovani nabidky

Souhlasím  |  Nesouhlasím  |  Odpovědět
PaJaSoft  |  15. 08. 2005 15:19

No ja tedy do toho nedelam tak dlouho (alespon na SQL urovni), ale jednak myslim, ze kolegove mluvili o Stored-prodecures, jednak o jazyce PSQL - oboji dneska v normovanem tvaru... v cem je tedy problem?
Vzhledem k tomu, ze RDBMS ma v nazvu a popisu prace RELACNI, tak si myslim, ze cyklicka struktura pujde z toho brat vzdycky blbe... i kdyz jsou zpusoby, jak to obejit a pak se dotazovat pomoci jednoho selectu - prave zde by triggery mohly ukousnout vetsinu prace....
Komentovat zamenu archivace, zalohovani a implementace/systemove integrace radeji nebudu, stejne tak moznost referencni integritu NEVYPINAT (tfuj, od vas bych si system teda opravdu nekoupil, chudaci zakaznici), ale pozadat slusne v transakci, aby se referencni integrita zkoumala az na konci... a to by me teda opravdu jako zajimalo, v cem by pak mel byt s referencni integritou (na DDL urovni!) problem...
Samozrejme, ze vim o cem mluvite, neco jineho je par relacnich vazeb a neco jineho slozite vyrobni vazby na kusovniky, ciselniky, sklady, modely atd... - opravdu nejsem trotl a vim, o cem hovorim, stejne jako mam velmi dobrou predstavu o rozsahu problematiky, o ktere se tu bavime...

Souhlasím  |  Nesouhlasím  |  Odpovědět
alex  |  11. 08. 2005 16:59

Zapomeňte na MySQL I. http://hulan.cz/blog/item/zapomente-na-mysql-nic-horsiho-neni
 
Zapomeňte na MySQL II  http://hulan.cz/blog/item/zapomente-na-mysql-podruhe/category/apache-php

Souhlasím  |  Nesouhlasím  |  Odpovědět
TimeLord, TimeLord  |  11. 08. 2005 17:30

Keby som nepoznal Hulana a jeho nazory, tak tomu aj uverim.

Mozno by bolo vhodne pozriet si, aky je tam uvedeny datum pri jeho reciach a aj pri clankoch, na ktore odkazuje.

Nie zeby som sa MySQL zastaval, len mnoho veci, co tam pisal, uz neplati.

Souhlasím  |  Nesouhlasím  |  Odpovědět
hyperion  |  11. 08. 2005 21:07

taky tam toho magora v diskuzi pekne setreli..ono neco jineho je si stahnout Oracle z OTNka a pak machrovat se SELECTama (navic napsanyma pekne prasacky) a neco jinyho je pak platit licenci na nekolikaprocesorovou masinu, pri pohledu na ty cifry je cloveku do breku. Typickej FUD.
kazda db je pouzitelna na neco..a MySQL je pouzitelna na hodne veci.
a asi byste se divili, kdybyste vedeli kde v CR vsude MySQL (dobre) funguje.
v computerpressu uz to snad taky pochopili, kdyz maji na novy forum Debian+PHPBB(to bude casty patchovani...:))+MySQL

Souhlasím  |  Nesouhlasím  |  Odpovědět
brouk pytlik  |  11. 08. 2005 21:32

http://web.archive.org/web/20041106014247/hulan.info/cv/

Souhlasím  |  Nesouhlasím  |  Odpovědět
TimeLord, TimeLord  |  12. 08. 2005 00:27

LOL

"2003/10 - současnost
Open Source developer - BLOG:CMS and PunBB Forum,
Od 10/2003 pracuji jako Hlavní Vývojář na Open Source systému BLOG:CMS, poskytovaným v GNU licenci. BLOG:CMS je komplexní online redakční systém pro správu obsahu, založený na MySQL 4, PHP 4, XHTML, XML, XSLT, JS a CSS. Vlastní systém je používán na tisících webech po celém světě a konkuruje systémům jako je Movable Type, či WordPress."

Souhlasím  |  Nesouhlasím  |  Odpovědět
lubos, lubos  |  11. 08. 2005 15:56

"Apache jako zajímavý webserver" ROFL
"nebáli byste se je nasadit na kritické aplikace" - jako MySQL ?

"však stále vedou firmy Oracle, IBM a Microsoft", patrilo by se rict, ze skutecne velke databazy jsou Oracle a DB/2. MSSQL je jaksi neco , no ... :)

Souhlasím  |  Nesouhlasím  |  Odpovědět
zz  |  11. 08. 2005 12:57

autor bi si mal nieco zistit o apache. ten bol majoritnym webserverom este v case ked microsoft ani nevedel co je to HTTP. vedsia komercne dodavanych serverou je apache alebo aspon upravena verzia apache (napr ibm http server).

Souhlasím  |  Nesouhlasím  |  Odpovědět
Luke  |  11. 08. 2005 11:55

Poté, co byl postupně vzat v úvahu ... Apache jako zajímavý webserver
Apache vzat v úvahu. Vždyť je to nejpoužívanější HTTP server. A byl tady dlouho před IIS. Hmm, to mě zajímalo, CTCHBŘ (co tím chtěl básník říct).

Souhlasím  |  Nesouhlasím  |  Odpovědět
ACCEPTus Metalist  |  11. 08. 2005 13:03

Pravdepodobne mysleli Apache na Windows, meli tu vetu formulovat lepe...

Souhlasím  |  Nesouhlasím  |  Odpovědět
zz  |  11. 08. 2005 13:17

nic len to ze scasti tvoril z vlastnej neznalosti.

Souhlasím  |  Nesouhlasím  |  Odpovědět
kasparek  |  11. 08. 2005 13:33

"...Apache jako zajímavý webserver..." tuhle cast taky miluju ;)

Souhlasím  |  Nesouhlasím  |  Odpovědět
tommic  |  11. 08. 2005 09:38

Ahoj,

od tohoto kvetna uz tam jede SAP, ale predtim pouzivala firma ProCA po dobu dvou let vlastni ERP system bezici nad Firebirdem na Linuxu. Centralizovany DB server na prazske centrale a k nemu pripojenych bezne vice nez 200 klientu po cele republice ve dvouvrstve architekture. Fungovalo to dobre. Na SAP se prechazelo z jinych duvodu nez technickych ...

Souhlasím  |  Nesouhlasím  |  Odpovědět
Arima-kun  |  11. 08. 2005 09:02

A obligátní otázky do diskuse. Na jaké databázové platformě funguje Živě? Myslíte si, že současná open source řešení jsou už dostatečně vyzrálá, aby neházela při každém druhém pokusu o vložení příspěvku do diskuze nějaký error, jako se tomu děje u MSSHITQL 2011?

Souhlasím  |  Nesouhlasím  |  Odpovědět
t  |  11. 08. 2005 13:44

" MSSHITQL 2011"
Kdyz mam chyby v kodu, ktery vyuziva databazi , pak mi ta databaze rekne , ze mam proste chybu ve svem kodu !! A tedy ne zadan chyba v serveru, ale chyba v tom, co ho zasobuje daty - stejne se zachava jakykoliv jiny databazovy server.

Souhlasím  |  Nesouhlasím  |  Odpovědět
t  |  11. 08. 2005 13:45

" MSSHITQL 2011"
Kdyz mam chyby v kodu, ktery vyuziva databazi , pak mi ta databaze rekne , ze mam proste chybu ve svem kodu !! A tedy ne zadan chyba v serveru, ale chyba v tom, co ho zasobuje daty - stejne se zachava jakykoliv jiny databazovy server.

Souhlasím  |  Nesouhlasím  |  Odpovědět
J  |  12. 08. 2005 00:06

Problem zive je ovsem v tom, ze pouziva spatnou databazi a chybny kod zaroven. Casto to jejich M$ sql haze hlasky o timeout SQL dotazu a pod. Zajimave, ze mnohem vetsim webum bezicim na apache + zatracovane MySQL se to nestava.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Honza  |  11. 08. 2005 08:44

Ve firmě používáme jako hlavní databázi MS SQL server, protože na něm běhají prakticky všechny aplikace, které používáme. Náš ERP systém může používat MS SQL, Oracle nebo Pervasive SQL, z těchto tří je nejzajímavější MS SQL - Oracle je několikanásobně dražší a Pervasive jsme měli dříve a zkušenosti nebyly dobré. Ostatní aplikace dávají pak většinou vybrat mezi MS SQL a MDB, takže je to jasné.
Na testování pak používáme převážně MSDE, (pro ty, co neví, je to free verze MS SQL s určitými omezeními). Tip pro všechny, kteří by chtěli MSDE používat: Standardní MSDE má limit 2GB na jednu databázi, když si ale stáhnete z Microsoftího webu instalaci SharePoint Portal Services, je u toho přibalená verze MSDE, která má limit 4GB (a licenční podmínky jsou u ní stejné, není vázána na SharePoint). Tento limit ja samozřejmě na databázi, v serveru lze mít databází kolik chcete, omezení pouze znamená, že žádná z těchto databází nemůže mít více.
Free verze MS SQL 2005 bude mít limit také 4GB, to už Microsoft oznámil.
Kromě toho je tam limit na počet připojení (naštěstí připojení nad limit se neblokují, ale jejich požadavky řadí se do fronty a zpracovávají postupně, a ne najednou, takže je to trochu pomalejší, ale při běžném provozu běžného ERP systému s uživateli v počtu několika desítek to v praxi ani nepoznáte).
Pozn: pro většinu malých firem bude ten limit 4GB zajisté plně dostačující - my se považujeme za střední firmu (obrat cca. 700 mil Kč ročně) a naše ERP má v MS SQL velikost 9GB - veškerá data od zavedení MS SQL v roce 2001. Takže podle mého názoru malá firma může spokojeně žít s "malou", ale plně funkční verzí MS SQL (MSDE), a až se rozroste, nebude pro ni problém přejít na velký SQL server se všemi vymoženostmi, které má (OLAP analýzy apod.) - a které free databáze nemají, přinejmenším ne automaticky a jednoduše.
Aby bylo jasné, že vím o čem mluvím, mám na svém pracovním i domácím počítači nainstalován i MySQL 4.1.13a a aktivně jej používám, jelikož mám spoustu projektů z minula v něm a jsem na něj docela zvyklý. Ale rychlostně je na tom MS SQL podstatně lépe, a to obzvláště při práci přes síť, tam je rozdíl výkonu skutečně dramatický (pochopitelně porovnávám InnoDB tabulky, které podporují transakce, tabulky bez transakcí jako MyISAM jsou dobré tak akorát na logy; a AutoCommit na InnoDB mám zrušený). MySQL je hezký produkt, s novými nástroji (Administrator a Query Browser i docela uživatelsky přívětivý, ikdyž ten Query Browser má docela dost problémy s češtinou - myslím data v db uložená v češtině), ale na reálné nasazení bude zapotřebí ještě hodně práce - a to jak ve výkonu, tak ve vlastnostech databáze (speciálně MySQL dosavad bez uložených procedur atd.) a hlavně také v integraci s dalšími IT záležitostmi - používanost klientskými SW jako např. ERP, CRM atd., ale také monitorovací nástroje a nástroje pro zajištění 24/7 běhu (MOM Server, Veritas), zálohovací nástroje (žádný současný velký zálohovací nástroj nemá agenty pro MySQL nebo Postgre) atd.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Rudidlo, Rudidlo  |  11. 08. 2005 09:12

Díky za info pro nás, kteří jsme se s MySQL zatím nesetkali. Mě docela zaráží ta věc, že může existovat v db tabulka, která nepodporuje transakce. Jak ji změnit na transakční, když má definované kaskádové relace (Teda nevím, jestli tam jsou)? To musí být hromada práce navíc.

Souhlasím  |  Nesouhlasím  |  Odpovědět
MarSik  |  11. 08. 2005 09:28

No na MyISAM tabulkach ty kaskadove relace nadefinovat ani nejdou pokud vim. Jinak zmenit typ se da (myslim, ze dokonce pomoci alter table) a potom pri pridavani cizich klicu a vazeb na jine tabulky uz bude kontrolovat integritu (resp jeste je potreba povytvaret na klicove sloupce indexy).

Souhlasím  |  Nesouhlasím  |  Odpovědět
Rudidlo, Rudidlo  |  11. 08. 2005 09:37

Takze pouze pomoci alter table zmenim tabulku z netransakcni na transakcni?

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jarek Šeděnka  |  11. 08. 2005 10:20

presne tak, pokud mate verzi MySQL aspon 4 tak staci "ALTER TABLE tabulka TYPE=InnoDB;", a z netransakcni tabulky se okamzite stane transakcni (a o dost pomalejsi

bohuzel, na ulozene proceduryj e porad potreba si pockat..

Souhlasím  |  Nesouhlasím  |  Odpovědět
Ducháček  |  11. 08. 2005 07:53

Stejně většina firem využívá SQL především jako datový sklad, navíc MySQL již vyrostlaa tak vystačí většině malých českých firem, které se rozhodnout "přeportovat" staré aplikace na třívrstvou architekturu. Sám využívám MySQL jako datový sklad v mnoha aplikacích a necítím potřebu to měnit. Obzvlášť, když mi server běží na Linuxu a klienti buď na MS Windows, nebo jako webová (PHP) aplikace.
Takže ... k čemu drahý MSSQL server?
Mj. třeba Oracle má jistě svůj význam a jsou místam, kde je to vynikající volba a MySQL nestačí, ale jak jsem psal ... většině malých firem ...
A co se týká FireBird, pro nenáročné aplikace jistě vhodný SQL, především jako náhrada za často zneužívaný MDB soubor místo MS SQL....

Souhlasím  |  Nesouhlasím  |  Odpovědět
MaReK  |  11. 08. 2005 08:16

Spíše PostgreSQL, protože má, na rozdíl od MySQL, nástroje pro udržení a vynucení integrity dat, ať už se jedná o triggery, transakce, či cizí klíče. Netvrdím, že tyto vymoženosti MySQL vůbec nemá, ale ne ve svých tabulkách, a InnoDB tabulky jsou řádově pomalejší, než ty nativní, nebo jsou zatím ve víceméně testovací řadě 5. Od PgSQL existuje i "derivát", který se jmenuje EnterpriseDB a který má poskytnout kvalitní základ, jímž PostgreSQL je a maximální možnou kompatibilitu s Oracle.
Firebird není nejhorší, ale je pomalejší, než PostgreSQL. Má ovšem výhodu pro vývojáře v produktech firmy Borland, protože jsou pro něj kvalitní komponenty a další výhoda je v existenci embedded verze, která funguje jen jako dll/so knihovna a nevyžaduje instalaci celého serveru.

Souhlasím  |  Nesouhlasím  |  Odpovědět
PPPetr  |  11. 08. 2005 08:17

No zrovna kvalifikovaný názor to bohužel není. Nevím, proč je běžná databáze nazývána datovým skladem - nebo to lze na MySQL skutečně provozovat ETL procesy, OLAP kostky a data mining?
Autor "nechce" MS SQL - to je jeho právo. Je však třeba dodat, že použitý argument o ceně je zcela irelevantní. MSDE (MS SQL 2000 bez klientských nástrojů a určitým omezením výkonu) je zdarma, pro menší a střední databáze (malých firem) bezpochyby také postačí. Pochopitelně jej není možné provozovat na Linuxu, ale od Windows 98 výše - tedy není nutný server.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Petrik  |  11. 08. 2005 08:42

"Autor "nechce" MS SQL - to je jeho právo. Je však třeba dodat, že použitý argument o ceně je zcela irelevantní. MSDE (MS SQL 2000 bez klientských nástrojů a určitým omezením výkonu) je zdarma, pro menší a střední databáze (malých firem) bezpochyby také postačí. Pochopitelně jej není možné provozovat na Linuxu, ale od Windows 98 výše - tedy není nutný server."
No nevim dat si nejakou databazi se kterou to myslim vazne na Win98 to je for dne ale i tak pokud bych chtel fakticky usetrit tak reseni PgSQL + linux je podstatne levnejsi nez WinXXXX protoze si stejne musim koupit licenci Windowsu (home edice XP stoji cca 3000,-) kdezto Linux mne bude stat koupeni jednoho casopisu a nebo vyuziti pripojeni k internetu v dobe ADSL nebo spise pseudo ADSL ceskeho telekomu mne instalacni CD nevijde zase tak draho....

Souhlasím  |  Nesouhlasím  |  Odpovědět
BoodOk  |  11. 08. 2005 09:20

Datovy sklad. Proc se nekdo snazi jasnemu ceskemu slovnimu spojeni podsunout jiny vyznam. Datovy sklad muze byt cokoliv, kde se skladuji data. Zalezi na uzivateli, zalezi na jeho programatorech, kolik z nej uzitecneho vytahnout. Nekdo si poridi MySQL a necha si doprogramovat co potrebuje, nekdo si zaplati MS SQL (a stejne se bez programatora neobejde). OLAP je krasny termin, ale je to termin z jinych ekonomik. To co je u nas stredni firma je za oceanem mala firma atd. Mala firma se obejde bez OLAPu, ETL a data miningu. Myslim tim jen a pouze tyto terminy, nikoliv uz to co se pod nimi skryva. Holt nekdo pouziva termin CRM, nekdo ti po selsku rekne, ze si proste eviduje zakazniky a kontakty s nimi. Cim vetsi firma, tim vice MBA, kteri maji tyto akronymy nabusene z teorie, mala firma je povetsinou rizena jednim clovekem a par pomocniky, kteri se kazdy den potkavaji v kancelari a resi konkretni problemy, ne problemy typu - potrebujeme OLAP kostku (kterou potom stejne nikdo neumi pouzit, takze se stejne oslovi programator a rekne se mu: "Vytahni mi tu a tu statistiku.").

Souhlasím  |  Nesouhlasím  |  Odpovědět
Ditys, Ditys  |  11. 08. 2005 10:00

Datový sklad (ten termín je docela mladý) není cokoliv, kde se skladují data. Většinou jde o dlouhodobou historii - např. prodeje za 10 let zpátky, navíc jsou data upravena do podoby pro snadné vyhodnocení (databáze již obsahuje souhrny, mezisoučty atd.). Předpokládaný je přístup pouze pro čtení, nikoliv pro změny dat. Zdrojová (syrová) data tvoří ve skladu 30-40%, zbytek jsou různé indexy, tabulky součtů apod.
Cíl je jednoduchý - získat souhrnná data pro strategické plánování v rozumném čase, což ze stávajících informačních systémů většinou není možné (přílišná zátěž apod).

Souhlasím  |  Nesouhlasím  |  Odpovědět
Vít Špinka  |  11. 08. 2005 10:35

Neplést datový sklad (data warehouse) a data mart.

Ale jinak ano, na naší 300GB databázi a 5TB warehouse opravdu MySQL nemáme

Souhlasím  |  Nesouhlasím  |  Odpovědět
ROman  |  11. 08. 2005 10:36

MSDE - hm, podival ses na omezeni, 2GB na databazi cini ne zrovna pouzitelnou. Radeji nemluvim o dalsich omezenich. Ale ani MS SQL STANDARD neni zadna vyhra, staci par soucasne pripojenych uzivatelu a vykon je fuc.

Souhlasím  |  Nesouhlasím  |  Odpovědět
MAno_F., MAno_F.  |  11. 08. 2005 11:13

No nevim, ale na strankach mysql.com je neco o tom, ze na MaxDB bezi uz i SAP.

Souhlasím  |  Nesouhlasím  |  Odpovědět
MaReK  |  11. 08. 2005 11:56

Jestli to nebude tim, ze MySQL a.g. (ci jak se jmenuji) tu databázovou cast od SAPu koupili (mimochodem, SAP umi bezet na vicero SQL serverech, treba Oracle) a MySQL != MaxDB (jsou to jine produkty)

---- pod tlustou carou ----
(Sakra, jaktoze jeste nezacal flamovat AstolRights? On tak rad keca o tom, o cem moc nevi....

Souhlasím  |  Nesouhlasím  |  Odpovědět
Izak  |  11. 08. 2005 12:12

SAP je zastarala spatlanina, ta si dela z databaze disk, ale i tak na upravach MySQL deleli nekolik let.
Jinak SAP si prave transakce ridi sam, online backup DB dela taktez pres svoje API a MySQL je na cteni velice rychla takze ve specialnich pripadech je vhodna, ale pokud se bude masivne zapisovat je k nicemu.

No a SAP nezvolil PostgreSQL nejspise kvuli Oracle (nechce mu delat konkurenci v DB)

Souhlasím  |  Nesouhlasím  |  Odpovědět
Richard  |  11. 08. 2005 08:22

Pracujem intezivne s databazami od roku 1992 a to dost s velkymi, a este som v praxi nevidel firmu alebo aplikaciu, pre ktoru by bol MySQL nepouzitelny. Pokial viem, tak jediny vaznejsi problem s MySQL je robenie zalohy databazy pocas prevadzky. Neviem ako je na tom MySQL 5 - ale snad ten problem odstranili.

Souhlasím  |  Nesouhlasím  |  Odpovědět
MaReK  |  11. 08. 2005 08:52

Myslíte? Dobře zeptám se jinak:
1. Co třeba transakce (pokud nepoužijete InnoDB ), bez nich je docela těžké udržet integritu dat (v polovině přenosu se stane chyba a bude provedena půlka update... Co třeba pak v momntě, kdy jste zvyšoval plat o 10% a nemáte příznak, aby bylo vidět, u kterých lidí už zvýšení proběhlo?).
2. Triggery, je lepší a nepoměrně rychlejší tyto věci mít na straně db serverů, než na straně aplikací
3. Stored procedury
4. Nejen b-tree indexy, ale třeba GiST, HASH

Uznávám, že vůči u mě preferované PostgreSQL je MySQL nepoměrně rychlejší, jedná se prostě o kompromis mezi funkčností a rychlostí.
BTW: Nejsem žádný databázový superguru, ale ani neznalá lama.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Howard, Howard  |  11. 08. 2005 09:04

PostgreSQL je skvela volba

Souhlasím  |  Nesouhlasím  |  Odpovědět
MaReK  |  11. 08. 2005 09:31

Ja vim. Mimochodem, moje postupne narustajici dilko je zde: http://www.linuxsoft.cz/article_list.php?id_kategory=222

Souhlasím  |  Nesouhlasím  |  Odpovědět
MAno_F., MAno_F.  |  11. 08. 2005 11:33

jak na co. Pri zatezi kolem 50 paralelnich uzivatelu to uz prestava byt pouzitelne (a to tam mame jen radove desitky tisic zaznamu - nechci videt, co by to delalo s miliony zaznamu).

To, ze to neumi DIRTY (UNCOMMITTED) READ, je taky na houby. Tak treba Informix tohle zvlada uz nejmin 10 let.

JDBC driver na PostgreSQL je taky piece of shit - kdyz dam vyselectovat zaznamy z tabulky s milionem radku, tak to vsechno nejdriv nataha do pameti v Jave (kvuli cemuz muze snadno nastat OutOfMemoryError) a az pak to nejaka data naserviruje.

Cache na SELECTy nehrozi. Kdyz dam napr. nejdriv COUNT(*) a pak ten samy SELECT, jen misto COUNT(*) dam vyselectovat data, tak oba SELECTy trvaji zhruba stejne dlouho, ackoliv jsou nad stejnou mnozinou dat. To samy kdyz 10 uzivatelu paralelne zada vysledek stejneho SELECTu.

A takhle by slo pokracovat.

Jo, PostgreSQL je funkcne hodne zajimava databaze, ale ma svoje limity. Na rozdil od MySQL, enterprise nasazeni PostreSQL moc nema. Cim to asi tak bude? Slaby vykon pri vyssi zatezi? Nedostatecna podpora clusteru?

Mame ve firme DB/2 a PostgreSQL. DB/2 ma na slusnem HW slusny vykon, ale funkcne je to uboha databaze. PostgreSQL je funkcne velice slusna databaze, ale vykon stoji za houby. Tak jsme premysleli o zmene na MySQL, reseni integrity dat neni uplne nej. Zvazovali jsme i Interbase/Firebird, ale taky nic moc. Nakonec asi skoncime u Ingresu, jenz firma Computer Associates nedavno uvolnila jako open source.

Souhlasím  |  Nesouhlasím  |  Odpovědět
zz  |  11. 08. 2005 13:13

no ono zalezi jak mate ten postgresql nastaveny tie nastavenia co su defaultne su vhodne tak na vyvoj ci malinkaty webserver

Souhlasím  |  Nesouhlasím  |  Odpovědět
MAno F.  |  16. 08. 2005 03:31

A co je potrebne nastavit na hojne navstevovany internetovy portal + J2EE aplikaciu beziacu na jeho pozadi?

Vopred dakujem za odpoved.

Souhlasím  |  Nesouhlasím  |  Odpovědět
PaJaSoft  |  15. 08. 2005 15:08

Oooo pan se neucil ISOLATION LEVEL...:-r

Souhlasím  |  Nesouhlasím  |  Odpovědět
MAno F.  |  16. 08. 2005 03:29

Proc se Ti nejvetsi kreteni tvari jako ze snedli vsechnu moudrost sveta???

Tak po prve: ve v. 7.4.x PostgreSQL syntaxi "SET TRANSACTION ISOLATION LEVEL TO UNCOMMITTED READ" vubec neumel (viz prislusna dokumentace na http://www.postgresql.org/docs/7.4/static/sql-set-transaction.html )

A po druhe: ve v. 8.0.x je sice tato syntaxe podporovana, nicmene vysledek je stejny jako u "SET TRANSACTION ISOLATION LEVEL TO COMMITTED READ". Viz prislusna dokumentace na http://www.postgresql.org/docs/8.0/static/transaction-iso.html :

In PostgreSQL, you can request any of the four standard transaction isolation levels. But internally, there are only two distinct isolation levels, which correspond to the levels Read Committed and Serializable. When you select the level Read Uncommitted you really get Read Committed.

Takze jestli se nekdo chce jeste hadat, tak at se hada s autory dokumentace k PostgreSQL a ne se mnou (nemluve o tom, ze jsem to osobne zkousel a realita odpovida dokumentaci).

Souhlasím  |  Nesouhlasím  |  Odpovědět
MarSik  |  11. 08. 2005 09:24

No to "pokud nepouzijete InnoDB" je celkem omezujici ;)
V minulem prispevku jste se navic spletl ve verzi. InnoDB tabulky jsou v MySQL uz od verze 4.
Chtelo by to ovsem najit nejake porovnani rychlosti InnoDB a PostgreSQL, rekl bych totiz, ze pokud nepotrebujete stored procedury, tak je na tom MySQL s rychlosti naprosto srovnatelne nebo lepe.
Jinak je jasne, ze pokud musite hlidat integritu, tak budete pomalejsi nez bez ni (MyISAM vs. InnoDB).

Souhlasím  |  Nesouhlasím  |  Odpovědět
MaReK Olsavsky aka Penguin_007  |  11. 08. 2005 14:17

To omezeni na neInnoDB bylo zamerne, bermetez vychozi zakladni typy tabulek. Ve verzi jsem se nespletl, ano InnoDB je od rady 4, ale teprve od rady 5 jsou pridany cizi klice, ke kterymzto se mela verze 5 vztahovat...

Souhlasím  |  Nesouhlasím  |  Odpovědět
Vebloud, Vebloud  |  11. 08. 2005 15:29

To se mi nezdá, vvzhledem k tomu, že ve verzi 4.1 používám v InnoDB cizí klíče a constrainty. Jinak mi začínají v MySQL chybět triggery, uvidíme co verze 5.

Souhlasím  |  Nesouhlasím  |  Odpovědět
zvejkal  |  11. 08. 2005 15:47

InnoDb som testoval uz v 3.23 verzii. Takze uz boli aj v tejto verzii.

Souhlasím  |  Nesouhlasím  |  Odpovědět
BoodOk  |  11. 08. 2005 09:25

Transakce - timestamp u zaznamu, cislo verze zaznamu, mechanismy se daji nalezt.
Triggery - mate pravdu, ale data se sama od sebe v DB nezmeni, vzdy je meni nejaka aplikace - takze obejit se to da, otazka zni, jak moc triggery potrebujete.
Stored proceduryy - lze i bez nich

Napsal jste spravne, je to o kompromisu.

Souhlasím  |  Nesouhlasím  |  Odpovědět
MaReK  |  11. 08. 2005 09:41

Transakce - Timestamp je jasny, jina moznost je konkretne v MySQL pouzit InnoDB tabulky, ale ty jsou pomalejsi a to radove...
Triggery - lze obejit, ano ale z aplikace je to pomalejsi (odeslani dotazu, jeho analyza na serveru, provedeni)
Stored procedury - mohou usetrit hodne casu...

Co mi treba v MySQL take chybi jsou pohledy (preci jen rada 5 jeste neni dost stabilni na nasazeni), zase zvysuji rapidne ryhlost.

Souhlasím  |  Nesouhlasím  |  Odpovědět
MAno_F., MAno_F.  |  11. 08. 2005 11:36

No, to zvyseni rychlosti u views bych taky ocekaval, ale na PostgreSQL, svete div se, se s pouzitim view rychlost nijak nezvedla (spis klesla).

Souhlasím  |  Nesouhlasím  |  Odpovědět
MaReK  |  11. 08. 2005 12:03

Sakra a v jaky rade?? Me to jede na 8.0.2, hlavni tabulka ma sice teprve 5.7 mil. zaznamu a pribyva jich cca 300.000 mesicne, ale zrovna Views se projevili pozitivne, samozrejme, ze s inteligentni indexaci a nekterymi ukroky stranou, ksyz se importuji baliky dat. Ano, uznavam, ze PgSQL neni nejrychlejsi reseni, ale zkuste se podivat, co za zlepseni najdete v jejim contribu, co treba umi EnterpriseDB... Je toho hodne a znam i relativne vetsi projekty, pro ktere MySQL bylo nedostatecnym resenim a PostgreSQL optimalnim.

Souhlasím  |  Nesouhlasím  |  Odpovědět
MAno F.  |  16. 08. 2005 03:36

Bylo to ve verzi 7.4.x
Na 8.0.x zatim z jistych duvodu nemuzeme prejit. Je tedy mozne, ze 8.0.x uz dela views inteligentneji, ale overeno to nemam.

Souhlasím  |  Nesouhlasím  |  Odpovědět
JiVi  |  11. 08. 2005 09:53

sorry , ale transakce je na tolik dulezita vec u opravdu profi nasazeni, ze obchazni nejakym timestampem a podobne je proste hovadina ... proc osetrovat neco klientem, kdyz si to ma v pohode osetrit SQL server.
triggery  smarja .. zase .. proc to ma osetrovat klientska aplikace.. co kdyz k datum pristupuje nekolik aplikaci. kazdej by si to mel osetrit sam? ja trebas trigferama a ulozenejma procedurama generuju ID, ktere nejde poridit pomoci  AUTOINC ...  proc to delat slozite v aplikaci, kdyz si toto obslouzi SQL Server sam? a to jakymkoliv zasahem do DB, trebas pres conzolove query.
 
radsi sahnu po Firebirdu misto po MySQL.

Souhlasím  |  Nesouhlasím  |  Odpovědět
bullhead  |  11. 08. 2005 16:37

...presne ...to jsem fakt hledel ...ten clovek co napsal ze triggery a transakce nejsou dulezite je jen nejaky studentik co nikdy nerucil za data

Souhlasím  |  Nesouhlasím  |  Odpovědět
J  |  12. 08. 2005 00:01

Je to o kompromisu bezi bezpecnosti a rychlosti. Sam sem musel tyhle vymozenosti na M$ SQL vyradit (bohuzel nemam na vyber jinou DB), jelikoz to pri vzrustajicim poctu zaznamu bylo neustale pomalejsi a s DB se nedalo temer pracovat, jelikoz server neustale "neco" delal. Po odstreleni techto mechanismu se vykon zvetsil minimalne 10x. Trebas transakcni log mi pravidelne rostl behem par dnu do tak obskurnich rozmeru, ze bych se velmi brzo nevesel na disk.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jara  |  12. 08. 2005 10:19

Taky zalezi, nekdo pise triggery neefektivne, nevi co je inserted, deleted a dela neco porad se vsemi zaznamy.
Transakci log muze byt simple - pokud nechcete bod obnovy do jakehokoli casoveho bodu a pod.

Vetsinou je ztrata vykonu na triggerech ci SP jen veci nehorazne spatne napsaneho kodu.

Souhlasím  |  Nesouhlasím  |  Odpovědět
hidden  |  11. 08. 2005 07:34

Používáme Sybase. Dovedu si představit též využití databází Postgres či Firebird. Myslím, že i živě by o nějaké pořádné databázi mělo uvažovat.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Joker, Joker  |  11. 08. 2005 10:14

ad ŽIVĚ: jojo, chtělo by to

ad databáze: To samozřejmě záleží na konkrétním nasazení, ale řekl bych že pro převážnou většinu webových projektů je Apache+PHP+MySQL ideální kombinace

Souhlasím  |  Nesouhlasím  |  Odpovědět
Zasílat názory e-mailem: Zasílat názory Můj názor