Vlákno názorů k článku Úvaha ohledně zneužívání LIKE v databázích od NOT LIKE(AUTOR) - Nebudu se vyjadřovat k obsahu, ale způsob napsání...
-
NOT LIKE(AUTOR) (neregistrovaný)Nebudu se vyjadřovat k obsahu, ale způsob napsání je dost arogantní a vyznívá že "já jsem správný programátor, podívejte se ostatní co jste za voly, uživatelé jsou taky pitomci, jen já vím, co je pro ně správné".
No, autore bez profilu; neoslnil jsi mne, zatím nedostatečná. Naučte se to ještě jednou a přijďte znovu ... -
The other non-transactional storage engines in MySQL Server (such as MyISAM) follow a different paradigm for data integrity called “atomic operations.” In transactional terms, MyISAM tables effectively always operate in autocommit = 1 mode. Atomic operations often offer comparable integrity with higher performance.
(z dokumentace MySQL)…tak nevím. :-)
-
backup (neregistrovaný)me se na techto prikladech nelibi, ze nejsou realne. Me se to jeste nikdy nestalo, aby se server restartoval prave v tu chvili, kdy se provadi nejaky velky update. To ja pak mohu jit, zabudovat do masiny vadny hw-raid controler, nechat oracle-db bezet a pote, kdy uzivatel zjisti, ze ma misto dat salat rici, ze Oracle je na prd.
Nahoda je blbec ale statistika je ocelova, transakce jsou monstrance dnesni IT doby a plni zejmena tu ulohu, aby mohl management klidne spat. -
Karel (neregistrovaný)Pokud se něco podobného stane u velkého updatu, pak je to pořád ještě ten lepší případ. A ne, nestalo se mi. Horší je to u malého updatu, kde je poškozeno jen pár záznamů a kolikrát na to nepřijdete. A to se mi už stalo. Troufám si říci, že pokud máte rozumně vytíženou databázi, tak při každém násilném restartu (já onehdá zakopl o napájecí kabel) se vám poškodí nějaká data. A teď jak z toho ven? Jedna cesta je používat stabilní OS, stabilní verzi databázového SW, pravidelně aktualizovat, UPS atd. Druhá cesta je použít transakční databázi. V každém případě je to však "vlastnost", o které by měl správce vědět a nějak ji řešit. Strčit hlavu do písku a tvářit se, že problém neexistuje... no to není dobré :-)
-
Lael Ophir (neregistrovaný)Firmy naštěstí nepoužívají MySQL. Mají serverový HW (ne shit postavený v garáži), UPS, používají transakční DB engine a transakce na úrovni aplikačních serverů, zálohují DB i transakční logy, a drží vždy více záloh. "Webové aplikace" běžící na garážovém HW, LAMP a bez zálohování jsou z trochu jiné kategorie.
-
Lael Ophir (neregistrovaný)To se ovšem typicky týká služeb typu Google. Když taková služba ztratí kus indexu, nic se neděje, za nějaký čas ho získá zpátky. Když ale firma ztratí faktury, tak se už samy neobjeví.
Pokud jste ale byl v serverově nějakého hostingu, tak tam v klecích ležely počítače různých garážových firem, co mají své projekty na inetu. A to je přesně ta kategorie "splácám to v garáži, ono to něco udělá, a jestli se ta data ztratí, je mi to jedno". -
Ony to nemusí být vyloženě zbastlené servery pro garážové firmy - nemá cenu zastírat že i servery v racku sem tam odejdou do věčných lovišť. Ne každý server má redundantní napájení zdroje, větráček na CPU taky občas doslouží, kondenzátory na MB taky nevydrží všechno, ne každé datacentrum má dobře dimenzovanou (nebo chlazenou) UPS apod. A taková nevhodně umístěná klimatizace která začne téct, to taky umí svoje ... -
Tak chtěl bych vás vidět jak "rollbackujete z pravidelné zálohy" například v případě většího e-shopu, kde:
(a) může být velmi mnoho dat (řádově GB)
(b) záleží zejména na naposledy vytvořených datech (čert vem rok staré již vyřízené objednávky - výdělek závisí na těch právě odeslaných)
(c) záleží na dostupnosti - uživatelé nepočkají a přímé ztráty za hodinu výpadku v nevhodnou dobu mohou jít klidně do desetitisíců Kč obratu (o nepřímých ztrátách na image apod. ani nemluvě)
To že se šetří na HW ještě neznamená že se na něm nedá provozovat pořádná databáze. -
Lael Ophir (neregistrovaný)Řeč byla o MySQL, a tam myslím není co řešit. Firebird neznám, nebudu tedy vynášet soudy.
SQL Server nebo Oracle vám dají minimálně to, že můžete začíst s verzí zdarma (SQL Server Express Edition), a poté jen za cenu licence přejít na větší DB server (SQL Server Standard Edition). Nemusíte u toho přepisovat aplikaci. Naopak když začnete na MySQL a budete chtít víc, budete aplikaci přepisovat, což je velký problém. -
LENIN POWER! (neregistrovaný)no treba kdyz mate oracle data guard nebo db2 hadr tak pri havarii neztratite ani jednu transakci a failover na backup server je za nekolik sekund. To je dost dobra vec pro online e=shop, nemyslite?
Dalsi vec je mit db ktera je odzkousena a ne kterou dela par zoufalcu po vecerech.
Dalsi hezka vec je ze profi databaze umi workload manager - nektere dotazy umi vyrizovat prednostne. Takze pak reporty nebrzdi OLTP a nemusite delat reporty nad historickymi daty, ale nad aktualnimy. Aktualni informace maji cenu zlata. Kdyz treba zakaznik zavola nasi reklamce a chce prave aktualni stav protoze pred nekolika hodinama spustil dulezitou a drahou kampan tak muze operatorka vyrobit a poslat sestavy, ktery se nevytvari zrovna rychle tak je dulezity aby to tu databazi nebrzdilo pro normalni provoz.
Krom toho dneska se databaze daji zalohovat velmi rychle ty 2 TB co tu mame se zalohuji na pasky bez disk spoolingu neco malo pres hodinu.
Takze jak tu mistni expert tvrdil 'databaze co muze mit i nekolik GB a to je pak problem' asi nikdy nevidel poradny HW. -
anonymní
"no treba kdyz mate oracle data guard nebo db2 hadr tak pri havarii neztratite ani jednu transakci a failover na backup server je za nekolik sekund. To je dost dobra vec pro online e=shop, nemyslite?"
Myslím, že s výjimkou (ne)ztráty transakcí lze totéž realizovat s Firebirdem celkem jednoduše. Ztratím pouze nepotvrzené transakce, ovšem počítám-li s tím, že s touhle jedinou výjimkou si DB stroj může třeba totálně vyhořet, tak to snad není tak strašné. Jak ODG zachovává všechno? Spolupracuje s klientskou knihovnou na straně aplikace, aby kontext připojení přesměrovala na nový server? A kolik to vlastně stojí? :-)Dalsi vec je mit db ktera je odzkousena a ne kterou dela par zoufalcu po vecerech.
Ale já nepsal o MySQL. Já psal o databázi, kterou dvacet let vyvíjel člověk, od kterého Oracle kopíroval fíčury. :-)Krom toho dneska se databaze daji zalohovat velmi rychle ty 2 TB co tu mame se zalohuji na pasky bez disk spoolingu neco malo pres hodinu. Takze jak tu mistni expert tvrdil 'databaze co muze mit i nekolik GB a to je pak problem' asi nikdy nevidel poradny HW.
Brazilci cpou do Firebirdu deset tera (BTW, asi světový rekord v poměru velikost databáze/velikost serverového softwaru :-)) a prý si nestěžují. :] Českému e-shopu jistě pár tera pro data postačí s ohromnou rezervou. -
LENIN POWER! (neregistrovaný)ODG stalo $30k na procesor, ale nekdo mi tu psal ze ho uz v 11 EE davaji zadara.
To neni zadny hrdinstvi nacpat hodne dat do db, zalezi na tom jak to je pak rychly. mysql pri 10GB db uz zacne prohravat s cloudscape.
PGSQL ne pri vice datech taky strasnej opruz protoze vacuum. I na 30 GB trva vacuum full hodne dlouho (po 8 hodinach jsem to killnul) pokud je ta db rozfragmentovana treba 3 rocnim provozem. -
Vacuum je téma samo pro sebe, ale pokud se věnuje dostatečná pozornost konfiguraci autovacuum démona tak s ním nebývají výrazné problémy. Bohužel na (auto)vacuum nadávají hlavně vývojáři a admini kteří se na konfiguraci vyprdnou a pak se diví.
Pokud jste 3 roky provozovali databázi do které se i zapisovalo, a pak jste spustil VACUUM FULL aniž byste předtím rozumně nastavil vacuum_cost_ proměnné, tak se nedivte že to běželo hodiny (předpokládám že se CPU flákalo, že?).
Je to prostě vlastnost MVCC architektury, která se ale kontinuálně řeší a teď v 8.4 by se to mělo zase zlepšit. Stěžovatelé se většinou ohání tím že "Oracle to nedělá" - no, nedělá to proto že má jinou MVCC architekturu, která zase přináší jiné problémy (starý známý "ORA-01555: Snapshot Too Old", apod.). -
vacuum full zamyka tablice, takze je zadouci aby to dobehlo co nejrychleji. Krom toho to byla miniaturni db 20-30GB. Od te ocekavam, ze se zreogranizuje na x86 komodity hw s levnym ide diskem za maximalne 30 minut.
db2 9.7 ma taky mvcc a nemusi delat ani stupidni vacuum (pg, firebird) ani pouzivat rollback segmenty (oracle). Nacita starsi verze radek z transakcniho logu. Oracle kopiruje kazdou zmenenou stranku do rollback segmentu, to generuje znacne mnozstvi IO operaci i kdyz ji nikdo nebude cist. DB2 se s tim zacne zabyvat az v pripade ze nekdo chce stary snapshot dat cist.
Taky je zajimave jak i5/os db2 dela recovery z journalu. to je velmi creativni zpusob recovery aniz by se muselo cekat na dokonceni operace. Najdete si k tomu nejake prezentace na webu. z/OS verze DB2 se to naucila casem taky (defered restart), ale i5/os verze to umi porad jeste lepe. unix verze db2 to pravdepodobne nebude umet nikdy pokud nebudou zakaznici dupat at to tam preportuji.
Mne se libi pristup ibm - poslou vam papiry kam si muzete napsat co byste v db2 radi videli a kolik si koupite novych licenci, kdyz to tam dodelaji. tomu rikam spravna orientace na zakaznika. Obvolaval jsem lidi at jim napisou ze chceme preportovat schema evolution z Z/OS do unix verze. i5/OS verze db2 ma zase naprosto suprovej fulltext se semantickou analyzou textu (kterej se normalne prodava zvlast za $30k na procesor) a vybornou podporu pro narodni jazyky. Holt si to i5/os zakaznici umeli vydupat. Ja uz jsem si taky uspesne vydupal u IBM radu featur v jejich softu - u jinych ISV prakticky nemam moc sanci aby mi do krabicove verze dodelali to co chci. -
Ano, vacuum full zamyká tabulky a když už ho pustíte tak je žádoucí aby to doběhlo rychle. Jenomže k tomu aby to doběhlo rychle je potřeba vhodně nastavit právě ty vacuum_cost_* proměnné, protože defaultní nastavení je takové aby to nevytěžovalo CPU.
Navíc všechny rady ohledně vacuum full jsou ve smyslu "nastavte to tak aby vacuum full vůbec nebylo potřeba". Pokud totiž dostatečně vhodně nastavíte autovacuum, max_fsm_pages atd. tak by vacuum full vůbec nemělo být potřeba. -
Ksl (neregistrovaný)
db2 9.7 ma taky mvcc a nemusi delat ani stupidni vacuum (pg, firebird) ani pouzivat rollback segmenty (oracle). Nacita starsi verze radek z transakcniho logu. Oracle kopiruje kazdou zmenenou stranku do rollback segmentu, to generuje znacne mnozstvi IO operaci i kdyz ji nikdo nebude cist. DB2 se s tim zacne zabyvat az v pripade ze nekdo chce stary snapshot dat cist.
No něco na upřesnění: Firebird většinu starých řádků odstraňuje průběžně na pozadí společně s běžným přístupem ke stránkám. Jakmile je zapotřebí provést "sweep", je to příznak, že se něco "podělalo". Pro starší verze řádku nemusí sahat do protokolu - nejenže transakční protokol nemá, ale proč sahat pro nejnovější verzi řádku do jedné (datové) stránky a pro dvě starší verze do dvou různých dalších stránek (protokolu), když je jednodušší a rychlejší všechno shrábnout z jediné diskové stránky? Opravdu "stupidní" řešení. :-)Obvolaval jsem lidi at jim napisou ze chceme preportovat schema evolution z Z/OS do unix verze.
Schema evolution? To jako tohle?DB2 UDB for z/OS now provides the ability to change the definitions of tables and indexes without dropping and re-creating the object. This capability significantly enhances both the availability of your database and the performance of data access.
Přidat sloupec do existující tabulky je "pokročílá fíčura"? Nejen že tohle Firebird umí, ale umí to už dvacet let, za plného chodu, je to transakčně opouzdřené a provádí se to lazy updatem dat (verzovaná metadata), takže se databáze nezasekne na půl hodiny, když přidám sloupec do desetigigabajtové tabulky. -
LENIN POWER! (neregistrovaný)precetl jsem si dokumentaci a firebird uklada vice verzi radek do stejneho bloku. kdyz zjisti ze je tam nejaka stara co se uz nepotrebuje (nevim zda i pri cteni bloku nebo jen pri zapisu) tak ji vygumuje. Nektere stare radky to ale nemusi timpadem vygumovat kdyz pak delsi cas k nim nikdo nepristupuje. pokud je takhle cisti i pri cteni bloku tak generuje zbytecne zapisove operace, ktere jsou pomale.
bez transakcniho logu nemuzete delat rollforward recovery, umi tohle firebird?
Pokud mate v logu starou i novou verzi radku jako mela db2 vzdycky tak se za delat i rollbackward recovery coz je velmi zajimava vec. Do logu se musi stara verze zapsat u db2 vzdy takze mvcc neni zadne io navic jako u oraclu a vetsinou se stara verze potrebovat nacist nebude, v pripade ze ano je tu jeste pravdepodobnost ze bude v log bufferu. Mne to nepripada jako nestastne reseni, je to asi to nejlepsi co se da zaridit. Vacuum i rollback segment free a navic setri misto na disku i v bufferpoolu.
no schema evolution umi i zajimavejsi veci: zmenit index podle ktereho se tablice clusteruje, pridat sloupecek do indexu. zbytek uz je docela nuda: pridavani sloupecku, prejmenovani sloupecku, zruseni sloupecku, zmena poradi sloupcu a zmena data typu. Nejzajimavejsi je ze je to provedeno okamzite bez cekani, fyzicky se ta tabulka presoupe casem. Pro data warehousing k nezaplaceni. podporovano je soucasne max. 255 verzi tabulky a 16 versi indexu.
adminovat db2 na zOS je narocnejsi nez Oracle, ma to hodne ruznych prepinacu. naopak db2 na unixu je velmi jednoducha a kazda dalsi verze je snadnejsi. Na zOS panuje opacny trend. -
Předpokládám že tou poslední poznámkou se navážíte do mne, že? V tom případě si prosím znovu přečtěte v jaké souvislosti jsem se o těch GB zmiňoval, a třeba si všimnete že jsem to uváděl jako protiargument na návrh řešit problémy s transakcemi po pádu MySQL serveru obnovováním databáze ze zálohy a přehráním transakčního logu. Doufám že se shodneme že tady už i těch pár GB problémy s dostupností působit bude.
A věřte že "pořádného hardwaru" už jsem viděl celkem dost ... -
LENIN POWER! (neregistrovaný)no kolik mela nejrychlejsi masina co jste kdy videl? Mame tu treba db server co dela 1.1M TPC-C. Konzolidujeme na nem databaze a stal necely $3 mega.
mysql nema rollforward recovery, umi jen prehravat SQL prikazy (to je znacne pomale) a jeste v tom ma zname races, takze je mozne dostat po prehrani SQL logu jina data.
S bastlem mysql se vubec nema cenu zabyvat. -
Ano, máte pravdu - s takhle výkonnými a drahými stroji nepracuji. Běžně se setkávám jen se servery na úrovni PowerEdge 2950 a 2900 od Dellu (což jsou ve srovnání s tím vaším monstrem samozřejmě ořezávátka s 10x nižším TPC-C score za 50x nižší cenu), a databáze na nich provozované nemají TB ale pouze (desítky) GB. Uznávám že to ze mne nepochybně dělá absolutní lamu bez ponětí o technologiích ...
No a teď když jsme si tak pěkně pomocí TPC-C přeměřili virtuální penisy (váš je větší), tak byste mi mohl vysvětlit jak to souvisí s mým postem o nesmyslnosti řešit problémy s integritou při pádu MySQL obnovením ze zálohy. -
Pokud jste nekdy varil v restauraci tak budete prekvapen ze i kdyz doma varit umite, tak se v restouraci vari uplne jinym zpusobem. Protoze postupy ktere pouzivame pri vareni doma nejsou moc skalovatelne.
V databazich je to stejne. OSS db funguji prijatelne maximalne v rozmezich desitky GB dat.
2950 Dell - 2 sockety. 8x15K disky bratru za $9.6k. Ten hw je dnes prakticky zdarma. licence pro db by staly tak $120k. Proto se prave konzoliduji databaze na jednu velkou masinu - znacne setrite na SW licencich, uspora muze byt i 10:1 pri vhodne pouzite virtualizaci. -
no vidite a ja bych jim doporucil at si misto pgsql daji ms sql express kdyz uz nechteji utracet za licenci.
Pro zacatecniky je to nejlepsi. Jsou k tomu skoleni a literatura na kazdym rohu, vyvojovych nastroju dostatek. Kdyz nebudou neco vedet, tak jim poradi vsude.
Pokud chteji mermomoci provozovat db na linux, tak tam maji db2 express-C. Ale radsi bych jim doporucil ten ms sql. Pro zacatecniky je to lepsi.
Kdyz express verze prestane stacit, tak za velmi levny peniz poridi plnohodnotnou db a nebudou muset menit aplikaci. -
No, a já tahle absolutní tvrzení že produkt "X" je nejlepší považuji za nesmysl. Jistě, express edice (ať už Oracle nebo MS SQL) jsou sice hezká věc, ale zase že bych to snad chtěl používat na netriviální produkční aplikace?
To že jsou k něčemu školení a dokumentace dle mých zkušeností ještě nic neznamená, ve výsledku vždycky jde o to jestli vývojáři mají mozek. Kdybyste viděl s jakými hrůzami jsem se v poslední době setkal v dodávkách Oracle aplikací od "velkých" firem (Accenture, Cleverlance, Ness, ...) které svoje lidi údajně "školí", tak by vám hrůzou vstávaly vlasy, chlupy a kdoví co ještě.
Oproti tomu znám firmy které už několik let používají PostgreSQL, mají vývojáře a adminy kteří s ním umí pracovat, a nemají s tím sebemenší problém. Přechod na Oracle nebo jinou komerční databázi (třeba vaší oblíbenou DB2) by jim nepřinesl žádné výhody, jenom poplatky za licence. Čímž netvrdím že PostgreSQL je nejlepší databáze na světě ... -
LENIN POWER! (neregistrovaný)express edice se daji pouzit na netrivialni produkcni aplikace bez problemu. Jsou to totiz plnohodnotne databaze, ktera maji nejaka technicka nebo jen licencni omezeni. Je to stejne vyspely kod, ktery pohani velke databaze. Neni to nejaky zmetek zbastleny v garazi. Navic mate k dispozici vsechny vyvojove nastroje a knowhow z velkych systemu.
Pokud trvate na tom ze chcete databazi s nulovymi pocatecnimy naklady tak jsou to prave. Zejmena mssql express je velmi dobra vec pro zacatecniky. Mrknete co vsechno ta databaze umi http://www.microsoft.com/express/sql/default.aspx a jake hezke tooly k tomu muzete mit. Vy to nevidite ze se vam v tom bude delat snadneji a rychleji? Lidska prace totiz stoji nemale prostredky.
My treba mame pgsql nasazeny v jedne aplikaci kterou jsme koupili i ze serverem. Ma to pro nas nevyhody:
* opruz s vacuum
* nutnosti porad nastavovat free space map velikost protoze db porad roste. uz se to asi zvetsovalo 3x. Vrchol demence nastavovat cosi podle velikosti db, jak to mame vedet jak rychle poroste?
* replikace slony1 se opravdu velmi spatne adminuje a je nespolehliva, krome toho ze je jeste dost pomala a ma overhead i na strane master db.
* aplikace v 8.3+ nechodi. Zpetna kompatibilita pgsql zjevne neni nic moc. Jak dlouho bude jeste podporovana 8.2, kdo vi.
* pri upgradu na vyssi verzi se musi udelat import/export dat coz je dost opruz pac se jedna o 24/7 aplikaci. Pgsql navic importuje data pomalu jako lemra.
* knowhow o administraci pgsql se spatne shani.
* administrativni nastroje nejsou - vse se dela z command lajny
* monitorovaci nastroje taky nejsou
a to jeste nemluvime o takovych vlastnostech jako HA a recovery
Takze databaze sice stala toho kdo tu aplikaci psal $0, ale TCO co nas to stoji je mnohem vyssi nez kdyby to bezelo na komercni databazi. Kdyby ji napsal pro express edici velke db, tak si normalne misto srani s pgsql koupime standardni edici a mame klid. Ted budete muset jeste nechat nekoho to aplikaci prepsat do jine db, coz jsou zase nemale naklady.
Kde jsme podle vas usetrili pouzitim pgsql? Ja tu inzerovanou usporu nikde nevidim. -
Poradím:
Divím se, že takový borci neumí používat google.
free_space_map stačí nastavit jednou a pořádně - případně nasadit autovacuum. Čím déle neprovedete vacuum, tím větší musíte mít free_space_map.
migrace do 8.3, buďto opravit chyby nebo použít http://www.postgres.cz/index.php/Migrace_dat
něco o administraci http://www.postgres.cz/index.php/Desatero , http://www.postgres.cz/skoleni/skoleni_administrace_web.pdf
Administrace http://sqlmanager.net/products/postgresql/manager
Monitoring: http://pgfoundry.org/projects/nagiosplugins http://pgfouine.projects.postgresql.org/ -
LENIN POWER! (neregistrovaný)INFO: vacuuming "alexa.resultcache"
INFO: scanned index "resultcache1" to remove 91 row versions
DETAIL: CPU 3.66s/6.46u sec elapsed 131.09 sec.
INFO: "resultcache": removed 91 row versions in 7 pages
DETAIL: CPU 0.00s/0.00u sec elapsed 0.12 sec.
INFO: index "resultcache1" now contains 143751986 row versions in 497612 pages
DETAIL: 91 index row versions were removed.
74 index pages have been deleted, 74 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.01 sec.
INFO: "resultcache": found 91 removable, 143751986 nonremovable row versions in 1647055 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 7503 unused item pointers.
73 pages contain useful free space.
0 pages are entirely empty.
CPU 14.72s/11.47u sec elapsed 361.19 sec.
autovacuum | on
autovacuum_analyze_scale_factor | 0.1
autovacuum_analyze_threshold | 250
autovacuum_freeze_max_age | 200000000
autovacuum_naptime | 60
autovacuum_vacuum_cost_delay | -1
autovacuum_vacuum_cost_limit | -1
autovacuum_vacuum_scale_factor | 0.2
autovacuum_vacuum_threshold | 500
na 8.3 migrovat nebudeme, k nicemu by nam to nebylo. db roste asi o 1 GB denne. Mame autovacuum + 1x denne vacuum. REINDEX ani VACUUM FULL delat nemuzeme, to by trvalo desitky hodin.
Ten /postmaster.pid to je taky opruz, mame tu napsano v poznamkach ze kdyz server spadne tak pgsql kvuli nemu nenastartuje. musi se rucne smazat. Boze to je spolehlivost. Ta pitoma databaze neumi ani spolehlive zjistit zda bezi?
pokud hroz´ı pˇreteˇcen´ı ˇc´ıtaˇce transakc´ı (varov´an´ı v logu) VACUUM FREEZE (1x za nˇekolik let). Neda se to zjistit nejakym selectem? ja nemam zajem se hrabat ve /var/log/messages - zaukoloval jsem admina.
Kdyby ta aplikace nebyla zbastlena v pythonu, nemela 6mb zdrojaku a nepouzivala modul import pg ktery je db neprenositelny tak uz by davno sel pg i se svym vacuum do haje. delat mvcc pres disk je pitomost.
Ne ze by se ten pgsql nejak vyrazne predrel pokud jde o odmazavani dat z velkych tablic. Pravda je tam DELETE CASCADE v relaci tak 1:80 ale stejne je to pomaly jak prase.
crawler=# DELETE FROM alexa.querycache where cached < '2009-03-17';
DELETE 67155
Time: 228892.404 ms
ted mne bezi DELETE + aktivni autovacuum cisti tabulky a dulezita query od klientu co bezi normalne tak 0.3sec normalne ted jede tak 7 sekund. To je radosti na starym belidle s db co nemaj workload manager a neumi poustet dulezite dotazy prioritne. Doufam ze neprijdou stiznosti.
Kdyz bezi autovacuum tak je to tedy znatelne pomalejsi:
crawler=# DELETE FROM alexa.querycache where cached < '2009-03-19';
DELETE 147471
Time: 1331750.621 ms
To vacuum je fakt za trest. Nerikal jsem vam ze je dulezite umet garantovat worst case? Takhle to moc nejde, napere se tam jedno automaticke vacuum a vykon jde do kytek.
taky by mne zajimalo proc se to vacuum chova takto, delam to na jedne tabulce a porad to cisteni restartuje. Proc tu tabulku a index musel cistit 3x? To to nezvladl v jednom pruchodu? To ale generuje strasnyho i/o.
crawler=# VACUUM verbose alexa.resultcache ;
INFO: vacuuming "alexa.resultcache"
INFO: scanned index "resultcache1" to remove 5592194 row versions
DETAIL: CPU 4.69s/18.03u sec elapsed 227.78 sec.
INFO: "resultcache": removed 5592194 row versions in 67423 pages
DETAIL: CPU 2.13s/0.45u sec elapsed 141.74 sec.
INFO: scanned index "resultcache1" to remove 5592205 row versions
DETAIL: CPU 4.69s/17.31u sec elapsed 170.26 sec.
INFO: "resultcache": removed 5592205 row versions in 63695 pages
DETAIL: CPU 1.85s/0.50u sec elapsed 80.27 sec.
INFO: scanned index "resultcache1" to remove 5005436 row versions
DETAIL: CPU 4.39s/32.36u sec elapsed 225.78 sec.
INFO: "resultcache": removed 5005436 row versions in 57313 pages
DETAIL: CPU 1.70s/0.46u sec elapsed 91.58 sec.
INFO: index "resultcache1" now contains 118633367 row versions in 498388 pages
DETAIL: 16189835 index row versions were removed.
87911 index pages have been deleted, 31703 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: "resultcache": found 16189835 removable, 118633367 nonremovable row versions in 1649104 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 9117033 unused item pointers.
289416 pages contain useful free space.
0 pages are entirely empty.
CPU 31.78s/74.51u sec elapsed 1226.20 sec.
Teda zajimalo by mne ciste teoreticky zda firebird s tim vacuum taky takhle blbne. jo recovery.conf to je od autoru pgsql opravdu kanadsky zertik. Pripadam si jak roce 1987.
A to se tu bavime o pididatabazi 30GB. Co budeme delat az db naroste na 200GB? To uz abychom to zacali prepisovat pro ten Oraakl. Tady vidite ze pgsql ma pri nasazeni v realne netrivialni aplikaci dost vazne problemy. A to nechavam stranou jeho narocnou administraci na lidskou praci.
Vy si porad myslite ze se nam to vyplati? Kdyby jsme tam meli neco z trojky db2, mssql, oracle tak tyhle db zadne z vyse uvedenych problemu (vacuum normal/full/freeze migrace verzi) nemaji. Administrace pomoci klikacich nastroju, zalohovani do TSM bez problemu, rollforward recovery se dela 1 - slovy jednim prikazem. Ten pgsql ma strasne velky TCO. -
V něčem by ti možná pomohla 8.4. VACUUM projíždí pouze změněné datové stránky - neprovádí FULL SCAN tabulky. Jinak:
INFO: vacuuming "alexa.resultcache"
INFO: scanned index "resultcache1" to remove 91 row versions
DETAIL: CPU 3.66s/6.46u sec elapsed 131.09 sec.
V contribu je modul pg_stattuple, skrz který je možné se dostat k údajům jako fragmentace datových stránek, hloubka indexů a podobně. Pokud je nad tabulkou zavěšené hodně indexů, je důležité zvětšit maintanaince_work_mem - např. 3-4 GB.
Nevidím do aplikace, ale předpokládám ať už z názvu nebo z výsledků VACCUA, že tabulka result cache je použitá jako cache. Na to je lepší použít MyISAM nebo memcache - případně vysadit tuto tabulku z autovacuua, a na konec dávek - např. toho masivního deletu přidat VACUUM tabulky. Další možností je použít partitioning a dropovat celé partišny - v pg je partitioning v základu, nikoliv v enterprise edicích, takže není důvod proč se mu vyhýbat.
Proč VACUUM prochází opakovaně, fakt netuším. Musel bych se podívat do zdrojáků nebo se zeptat v konferenci. U mne to nedělá, ale používám 8.4
Vytvořil jsem tabulku s 1mil řádků a zrušil každý třetí.
INFO: vacuuming "public.e"
INFO: scanned index "e_pkey" to remove 333333 row versions
DETAIL: CPU 0.03s/0.44u sec elapsed 0.66 sec.
INFO: "e": removed 333333 row versions in 3922 pages
DETAIL: CPU 0.02s/0.09u sec elapsed 0.14 sec.
INFO: index "e_pkey" now contains 666667 row versions in 2192 pages
DETAIL: 333333 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: "e": found 333333 removable, 666667 nonremovable row versions in 3922 out of 3922 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 0 unused item pointers.
0 pages are entirely empty.
CPU 0.10s/0.75u sec elapsed 1.36 sec.
hlavně pak další průchod, pokud se nic nedělá je "rychlý". Samozřejmě, protože to už nic nedělá:
NFO: vacuuming "public.e"
INFO: index "e_pkey" now contains 666667 row versions in 2192 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: "e": found 0 removable, 666667 nonremovable row versions in 3922 out of 3922 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 333333 unused item pointers.
0 pages are entirely empty.
CPU 0.01s/0.06u sec elapsed 0.08 sec.
O postmaster.pid se většinou nemusíte starat (v nových verzích). Editace recovery.conf je asi jeden z mála úkonů administrace, kdy si připadám, že sedím u Oracle. Srovnávat administraci Oraclu a pg je vtip ne? To může zafungovat na tvoje ťuňtoidní zákazníky, kterým nacpeš předražený Indy. DB2, mssql, oracle sice nemají VACUUM, zase mají svoje jiné šperky dané buďto technologií nebo administrací - patchování Oraclu je taky dobrodružná záležitost, u db2 jsme před týdnem přišli o data a museli číst zálohu. Ukaž mi databázi, která je bez chyb. U pg by VACUUM už neměl být problém - v 8.3 je HOT update, v 8.4 se vacuují už jen modifikované stránky.
Fakt je, že migrace na vyšší verzi by mohla být pořešená líp - na online migraci dělal Zdeněk Kotala - je otázkou, na čem bude dělat pod Oraclem. Zatím můžeš použít pg_migrátor nebo si vyzkoušet pg_restore, který v 8.4 už dokáže běžet paralelně.
Pokud chceš klikat - pořiď si ems admina. Všechno je tam zabalené do klikátek. -
LENIN POWER! (neregistrovaný)ad 8.4 migrace:
* aplikace nefunguje ani s 8.3 - musela by se upravit, asi nejak moc vyrazne ale:
* dump z 8.2 se do 8.3 nenacte kvuli fulltext indexum
ad myisam/memcache:
potrebuju persistentni data, vyroba tech sestav trva znacne dlouho. Tak si nemuzu dovolit po pripadnem restartu stroje dropnout cache. To je pak ta aplikace nepouzitelne pomala.
table partitioning nemam moc rad, driv se to muselo pouzivat ponevadz db2 umela na unixu/windows max. velikost tablespace 64GB coz byl ale desnej opruz. Osobne ho pouzivam jako nutne zlo jen kdyz se tablice nevejdou do tablespace. Nastesti s db2 9 uz tento opruz konci pac minimalni maximalni velikost tablespace je 2TB.
Ale uznavam ze to bude asi nejlepsi navrzene reseni. Musim rict ze je to tedy znacny administrativni opruz v pgsql:
http://www.postgresql.org/docs/8.2/static/ddl-partitioning.html
to se mi delat nechce, na to si nekoho najmeme, napsal jsem tehletem http://www.varlena.com/contactus.php
srovnejte to s db2
http://www.ibm.com/developerworks/data/library/techarticle/dm-0605ahuja2/index.html
jak vam crashla ta db2 a ktera verze to byla?
Obvykle neni duvod delat restore cele databaze, staci udelat restore jen toho tablespace ktere zarvalo. Vy nezalohujete po tablespaces? Pokud mate soft `db2 recovery expert` tak dokonce staci jen dropnout tu poskozenou tablici a udelat na ni rollforward.
Uznavam ze oracle je v tomto lepsi nez db2, ten umi delat restore na urovni db bloku (obnovi jen ty pozkozene bloky ze zalohy); je to jen ponekud administrativne narocnejsi na muj vkus. ja recovery databazi nedelam, mozna ze na to budou mit nejaky tooly.
Na ten EMS manager jsem se dival, vyzkousel jsem db2 verzi, ta mela vazny bugy (neukladala konfiguraci pripojeni k db, a taky pouzivala V8 syntax oproti V9 db) tak jsem ji smazal. Kdyz se holt setri na QA testingu tak pak nejsou sales. Na tu pgsql verzi EMS se podivam casem.
Takhle to dopadne kdyz se clovek necha premluvit na OSS databazovy soft. Je s tim jeden problem za druhym:
NOTICE: number of page slots needed (1950384) exceeds max_fsm_pages (1000000)
asi mi tim chce naznacit ze 30GB databaze potrebuje 2 mega? no dobre nastavil jsem mu je na 5 mega. -
db2 určitě nebyla poslední verze - možná 7. Netuším, db2 v práci neřeším.
Doporučuji Release Notes pro 8.3 - je tam sekce věnovaná i TSearch2 aplikacím a importu z 8.2 do 8.3. Ostatně Release Notes je v každém případě, to co potřebuješ.
Partitioning v pg je lepší než žádný. A v 8.5 by se měl upravit, tj. přidat pár příkazů. Aby se člověk neupsal, tak stačí použí skript v shellu nebo uloženou proceduru.
NOTICE: number of page slots needed (1950384) exceeds max_fsm_pages (1000000). Tím to chce naznačit, aby ses podíval do dokumentace a přečetl si co max_fsm_pages znamená, a co se stane nebo nestane, když jej přešvihneš. V 8.4 už si fsm pg "jakoby" udržuje dynamicky.
Patrně uživatelé db2 nebudou tím typickým klientem EMS manageru. Verze v pg fungovala v pohodě, a už v roce 2004 měla integrovaný debugger plpgsql. -
Ne, já skutečně nevidím že se v tom bude pracovat lépe a rychleji. Ale možná je to tím že jsem v příkazové řádce jako ryba ve vodě, a když už potřebuji nějaké GUI tak si pustím Aqua Data Studio. Ale uznávám že OSS databáze nemají klikátka na takové úrovni jako například MS SQL (i když teda když jsem nedávno musel pracovat s tím administračním nástrojem od MS SQL tak jsem skoro umíral ... zlatá command lajna).
Každopádně pokud nejste spokojeni s danou aplikací postavenou nad pgsql, nemusí to nutně být chyba pgsql, ne? Zejména pokud to dělali vývojáři bez znalosti použité databáze - a to platí i pro ostatní produkty, včetně komerčních databází (Oracle, SQL Serveru a DB2).
Jak jsem řekl - pokud musíte pravidelně zvyšovat max_fsm_pages, tipuji na nevhodně nastavený autovacuum (pokud vůbec běží). Nehledě na to že max_fsm_pages souvisí ani ne tak s rychlostí růstu aplikace, ale s množstvím mazaných a měněných dat ... Zkuste autovacuum nastavit o něco agresivněji, tj. ať vacuumuje častěji a agresivněji. Máte-li zájem mohu vám s tím poradit.
Mimochodem zvyšování max_fsm_pages a nedostatečné vakuování má pochopitelně negativní vliv na rychlost. A jedna dobrá zpráva - v 8.4 už max_fsm_pages není potřeba.
Ano, replikace je jedna ze slabých míst PostgreSQL, to uznávám. Stejně tak nutnost exportu/importu při upgrade na další verzi je nepříjemné, zejména u 24/7 aplikací. 8.4 verze pg_restore už umí používat víc CPU, takže je to znatelně rychlejší.
Ano, máte pravdu že monitorovací nástroje nejsou, a je to velká chyba. Cosi primitivního jsem nedávno stvořil (http://pgmonitor.sf.net), ale s nástroji distribuovanými například s Oracle to pochopitelně soupeřit nemůže.
Na druhou stranu nevím co přesně myslíte tím "knowhow o administraci pgsql se spatne shani" - osobně pokládám dokumentaci k PostgreSQL za velice přehlednou a kvalitní, ale holt to chce zkušenosti. Znám dost lidí kteří si říkají "oracle administrátor" - dobří jsou tak 3 nebo 4, zbytku bych nesvěřil ani MySQL na domácím serveru. -
Nerad bych se tady zaplétal do flame na téma "která databáze je nejlepší" případně "proč by všichni měli používat databázi X a ne Y" takže pouze pár důvodů proč si firmy často volí některou z mainstreamových komerčních databází typu Oracle a MS SQL Server a ne open source databázi.
- v podstatě jsou to kvalitní a spolehlivé produkty (i když ne že by se mi na nich líbilo úplně všechno), mají poměrně dost zajímavých funkcí (replikace, apod.)
- když za něco platím (licence), mám většinou nárok na přesně specifikovanou podporu od konkrétního subjektu (lokální zastoupení apod.) - skutečnost že když se něco pokazí tak mám někoho po kom se vozit je pro manažery dost důležitá ;-)
- existuje k nim poměrně rozsáhlá dokumentace / nabídka školení apod. (což například pro Firebird neplatí, resp. neplatilo před cca rokem kdy jsem kloudnou dokumentaci hledal dost marně) -
- existuje k nim poměrně rozsáhlá dokumentace / nabídka školení apod. (což například pro Firebird neplatí, resp. neplatilo před cca rokem kdy jsem kloudnou dokumentaci hledal dost marně)
Dokumentace k Firebirdu spatna neni a behem par dni od objednani jsem ji mel doma na stoje, ale je placena.
-
Nezlobte se, ale postupovat dle logiky "nikdy se mi to nestalo takže nebudu přemýšlet jaké by to mělo následky" je poněkud naivní. Věřte že náhlý pád serveru není nic až tak výjimečného - může vypadnout elektrika a selhat UPS, může vyhořet zdroj, může přijít blbec a vytáhnout napájecí kabel ze serveru ... fantazii se meze nekladou. A pokud databáze neustojí ani takhle základní typ výpadku, tak se nedá mluvit o spolehlivosti.
Jistě, může se pokazit i řadič (i to už jsem viděl), ale to už je zase o kus dál. On totiž úplně stačí pokažený driver pro chipset, a je to. Ne že by nestálo za úvahu jak to sledovat a jak na to reagovat (v rámci standardního recovery plánu), ale asi se shodneme že je to řádově méně pravděpodobné než prostý pád serveru. -
Jencek (neregistrovaný)Stalo. Poprvé to byl idiot, který vytáhl kabel. Podruhé to byl ten samý idiot kdy pro změnu vypl natvrdo diskové pole u špatného serveru. Ale uznávám, že to není obvyklé a že to byla naše chyba, protože jsme ho neměli do servrovny pouštět. Bohužel to byl správce druhého serveru a tak jsme ho tam pustit asi museli. Pazoury bych mu tehdy nejraději urazil.
-
Lael Ophir (neregistrovaný)Já jednou viděl server v kanclu, kde uklízečka brzo ráno přišla, vrazila vysavač do UPS, a začala kancelář luxovat. Po půl minutě overloadu UPSky provedl server automaticky shutdown. Dali červenou nálepku s upozorněním na zásuvku co byla na UPSce, a situace se opakovala. Dali dětské zámky na zásuvky, ale uklízečka je vyndala ze zásuvky. Takové osobě urazit obě ruce.
-
Lael Ophir (neregistrovaný)Jistě takové firmy jsou. Také je ale hromada firem, které nemají ani tu UPS, natož server v racku. Pokladna je ve formě kasičky zamknuté v šuplíku stolu, a HR materiály zamknuté ve skříni. Prostě jim to tak stačí, protože jsou malí. Doma svůj počítač asi nezamykáte do racku, i když jsou na něm citlivá data, a své papírové dokumenty nemáte v trezoru. Občas se podobně chovají i firmy o desítkách lidí, protože rády šetří a nemají ještě špatnou zkušenost.
Nemusíte psát, jak je fyzická bezpečnost důležitá. Dobře to vím. -
> Ale uprimne, stalo sa nikomu v realnom nasadeni, ze by sa server restartoval(spadol) pocas vykonavania updatu?
Veril by jste tomu ze nekdy nejake SQL prikazy bezi treba i tydny? Nebo sypete 15k updatu do serveru za sekundu. Pravda kdyz davate databazi jeden jednoradkovy update za 5 minut tak pravdepodobnost ze se havarie trefi zrovna do nej je mala. Krom toho transakce chrani take pred havarii/kilnutim aplikace.
Na linuxu s jeho demetni spravou pameti tam kdyz dojde pamet tak kernel odstreli ten oracle, pac ji ma nejvic. Ja si myslim, ze pri spravnemu navrhu memory managementu to skoro ani nieje mozne. -
Sten (neregistrovaný)
Na linuxu s jeho demetni spravou pameti tam kdyz dojde pamet tak kernel odstreli ten oracle, pac ji ma nejvic
Tak hloupý zase OOM killer není. Nejdřív střílí procesy, které už dlouho nepožadovaly CPU čas. Krom toho mu lze celkem snadno říct (přes /proc/$PID/oom_adj), aby Oracle nechával až na později anebo vůbec nestřílel.
-
Lael Ophir (neregistrovaný)Zkuste na rootu vyhledat OOM Killer v diskuzích ke článkům a zprávičkám. V krátkosti:
- nepoužívat fork/exec, ale nějakou obdobu CreateProces
- používat thready místo worker procesů
- při alokaci paměti jí opravdu vyhradit (tedy nelhat o paměti)
- když paměť není, tak se chovat dle normy jazyka C (alokace vrátí null),
- aplikace by měly být schopné správně reagovat na nedostatek paměti
Zkuste si to s Oraclem nebo MS SQL Serverem. Když selže alokace, tak zmenší nějaké buffery, nebo selže pouze provádění statementu, který paměť potřeboval. Slíbit procesům paměť, a pak je různě losovat a střílet, to je linuxové zvěrstvo. -
Lael Ophir (neregistrovaný)Memory overcommit jde vypnout, ale pak brzo dojde paměť. Důvodem je nadužívání konstrukcí, které mohou spotřebovat spoustu paměti, ale většinou jí nepoužijí. Příkladem je fork a fork/exec.
Reakce na nedostatek paměti NENÍ v rukou programátora. Na Linuxi díky overcommittingu projde prakticky jakákoliv alokace, i když paměť není (malloc vrátí pointer). Když potom aplikace zkusí paměť použít, kernel zjistí, že aplikaci slíbil paměť, a teď jí nemá. Pak je čas na OOM Killer. Autor aplikace s tím moc nenadělá. Minimálně na Windows a Solarisu je situace řešená daleko lépe. O paměti se nelže, threading je dlouhá léta funkční, a příšernost fork/exec není třeba používat. -
LENIN POWER! (neregistrovaný)http://www.root.cz/zpravicky/steve-ballmer-linux-je-vetsi-hrozba-nez-apple/257669/
misto aby vylepsovali oom killer by mohli prestat lhat o pameti. Navic ta sama aplikace na windows kdyz se srovna s linux verzi tak linux verze zerou mnohem vic pameti.
Solaris taky neni zadny zazrak, 32 bit verze ma swap max. 2GB. 32bit solac je kupodivu vyrazne rychlejsi. -
Pokud by CreateProces melo mit stejne moznosti (predevsim co se tyce pipe a ostatni meziprocesove komunikace) jako fork/exec taky by muselo mit zhora neomezeny pocet parametru. Problem, o kterem mluvite, je vyresen uz 30 let: vfork je funkce kterou mate zavolat pokud vite, ze budete skoro hned delat exec. Tim jadru umoznite predpokladat, ze se nebude ve skutecnosti spotrebovavat zadna pamet.
-
Lael Ophir (neregistrovaný)POSIX.2 z roku 1996 nezná vfork. Možná právě proto už 30 let aplikace vesele používají fork/exec. Navíc vfork má své vlastní problémy:
http://linux.die.net/man/2/vfork
Které konkrétní možnosti máte na mysli u CreateProcess? -
Tak s MyISAMem je problém i obyčejná úloha typu převod peněz z účtu na účet.
BEGIN; UPDATE accounts SET balance = balance - 100 WHERE id = 1; UPDATE accounts SET balance = balance + 100 WHERE id = 2; COMMIT;Obecně pokud je pro zachování integrity dat nutné provést atomicky více než jeden příkaz, tak je to jen velice obtížně řešitelné.
-
mate ale nekolik problemu:
1.
V prvni rade musite umet detekovat ze vam mysql samo od sebe zbuchlo nebo ze vam spadnul OS. Havarie OS ty dejme tomu budeme umet spolehlive detekovat, ale mysql je udelane tak ze kdyz crashne tak se samo restartne - jak vlastne zjistit ze padlo?.
2.
Budete muset detekovat v aplikaci chybove stavy jako treba UPDATE vice nez 1 radky zarvalo protoze doslo misto na disku.
3.
Takze detekce zda se vam vubec podelali nejaka data neni zrovna trivialni. Vetsina mysql aplikaci ignoruje nejake navratove kody, proste tam jen vali sql statementy.
4. Fajn takze i kdyz sance ze zjistime potencionalni poskozeni dat je velmi mala rekneme ze to na 100% zvladame. Kdyz se to zjisti tak se musi zashutdownovat databaze co mozna nejdrive abychom zabranili dalsi ztrate dat - uzivatele vkladaji data do poskozene databaze. Ma na to vubec nami pripojena aplikace prava?
5. Pak je potreba udelat restore ze zalohy, vybrat spravne binarni logy od posledni zalohy a prehrat je. Zrejmne dost rucni prace admina.
6. neuvazujeme pro jednoduchost zname pripady races, kdy mysql zapisuje prikazy do binarniho logu v nespravnem poradi a tedy jejich prehranim dostaneme odlisna data od puvodnich. Tyto bugy jsou dlouhou dobu neresene.
Jak vidite atomicita sql statementu je pro mysql/isam prakticky nedosazitelny highend.
Nejake dalsi otazky? -
1.
V prvni rade musite umet detekovat ze vam mysql samo od sebe zbuchlo nebo ze vam spadnul OS. Havarie OS ty dejme tomu budeme umet spolehlive detekovat, ale mysql je udelane tak ze kdyz crashne tak se samo restartne - jak vlastne zjistit ze padlo?.Automatický restart zařizuje nějaký pomocný skript, který vůbec není nutné používat.
2.
Budete muset detekovat v aplikaci chybove stavy jako treba UPDATE vice nez 1 radky zarvalo protoze doslo misto na disku.Aktuální verze se při zaplnění disku chová tak, že se daná operace zablokuje a čeká se, až se nějaké místo uvolní. Pokud vím, tak mimo uvolnění místa se z tohoto stavu lze dostat pouze násilným ukončením serverového vlákna, které tu operaci provádí, sama aplikace s tím nemůže už nic udělat.
3.
Takze detekce zda se vam vubec podelali nejaka data neni zrovna trivialni. Vetsina mysql aplikaci ignoruje nejake navratove kody, proste tam jen vali sql statementy.4.
Fajn takze i kdyz sance ze zjistime potencionalni poskozeni dat je velmi mala rekneme ze to na 100% zvladame. Kdyz se to zjisti tak se musi zashutdownovat databaze co mozna nejdrive abychom zabranili dalsi ztrate dat - uzivatele vkladaji data do poskozene databaze. Ma na to vubec nami pripojena aplikace prava?Tyhle dva body nechápu. K poškození dat může dojít pokud server spadne nebo ho násilně ukončíme, v obou případech už ale server neběží a aplikace se k poškozeným datům nedostanou.
5.
Pak je potreba udelat restore ze zalohy, vybrat spravne binarni logy od posledni zalohy a prehrat je. Zrejmne dost rucni prace admina.Tak najít log s nejvyšším číslem a pustit ty tři nebo kolik příkazů zas tolik práce není. :-)
-
Já samozřejmě chápu myšlenku toho článku (zhruba "Nezneužívejte LIKE operátor k dotazům nad nedostatečně normalizovaným schématem!") ale trochu mi tam chybí nějaké jasné shrnutí kdy je použití LIKE operátoru v pořádku a kdy to zavání čuňárnou.
Totiž vyjdeme-li z toho že článek je určen hlavně těm kdo si popisované problémy neuvědomují, hrozí že to buď vůbec nepochopí a nebo přejdou k opačnému extrému (LIKE je absolutně fuj a kdo ho použije není skutečný programátor!) zhruba ve stylu příkazu GOTO. Na školách se učí že je to fuj, tak si spousta programátorů myslí že je to fuj ... a přitom v některých případech je jeho použití zcela korektní (viz. například http://kerneltrap.org/node/553)
No ale hlavně se bojím že obávám že ti kteří by si tento článek měli přečíst především (tj. ti kdo zvěrstva s LIKE páchají) si ho nepřečtou protože si myslí kdoví jak to není fikané - vím o čem mluvím, několik takových individuí která sebe sama nazývají programátory znám. -
Raulik (neregistrovaný)Napadat zde timto zpusobem cloveka, ktery denne prispiva vyvoji pgSQL, zhruba co mesic vydava clanky zde na rootu, obstarava pgsql.cz, je vzdy ochotny poradit a na rozdil od ostatnich v hlave ma hodne, mi prijde ubohe, zvlast od neregistrovaneho NOT LIKE(AUTORa). Jsi ubohy chlapce.
-
N/A (neregistrovaný)mozna ubohy, ale ma pravdu. na zacatku autor nadava na LIKE, pak predvede priklad, na kterem se snazi chybne pouziti LIKE predvest, ale predvadi pouze app. s chybnym navrhem... atd.
velmi slaby clanek.
a je mi uplne jedno, kolik domen autor provozuje, co na ne pise a kam prispiva. hodnotim clanek, nikoli barvu autorovych oci. -
pepak (neregistrovaný)Je to tak. V principu by šlo se článkem souhlasit, kdyby ovšem byl formulovaný ve stylu "LIKE je často použit chybně, lepší je nahradit ho tak a tak". Ale tady je stavěný do pozice "existuje špatné použití operátoru LIKE, tudíž je operátor LIKE špatný a kdo ho používá je blbec", a to je prostě jednoznačně špatně.
-
Xerces (neregistrovaný)Je to možná malinko přesazené, ale všichni se tady prsíte jako že tenhle problém neexistuje a on existuje a je to skutečně problém který není jen technický jak je z článku, kterému je vytýkána omáčka, patrné. Samozřejmě root čtou samý technicky uvažující lidé, kterým je hned všechno jasné :-D ale mě příjde forma i rozsah článku absolutně ok a dobře se mi to četlo. Asi proto, že s tím občas v práci taky bojuju ;-)
-
martin (neregistrovaný)Ale přece o tom ten článek je -- o tom, že je potřeba se 2x zamyslet, než použijete LIKE.
A na reálném příkladu ukazuje, že to co se na první pohled může zdát jednodušší (tj. držet si data pohromadě a použít LIKE) v důsledcích vede jen k problémům. Bohužel spousta lidí nemá dostatečné znalosti o fungování relačních databází a vůbec tak nedokáže posoudit, co je správné řešení (chybná úvaha "musel bych k tomu připojovat další tabulku -- bylo by to pomalé") -- tady si tito lidé můžou přečíst a na příkladech vyzkoušet co opravdu funguje lépe. -
Ne že bych k článku neměl výhrady, ale o demonstraci nevhodného použití operátoru LIKE snad šlo, ne? A to že někdo použije operátor LIKE namísto toho aby data správně normalizoval a použil standardní porovnání je celkem častým problémem (věřte nebo ne).
Samozřejmě, LIKE operátor má spoustu dalších problémů (například výkonnostních - osobně jsem řešil výkonnostní problémy u jednoho e-shopu který LIKE používal pro fulltextové vyhledávání v popisech výrobků a i při minimální zátěži 100% vytěžoval SCSI disky protože generoval soustaný datový tok přes 80 MB/s), ale to nebylo tématem tohoto článku, ne? -
ldx (neregistrovaný)Souhlasim s tim, ze takovy clanek nepatri na root, ale na zive nebo lupu, kde se takovi koderi, co jsou schopni spachat vyse popisovane spis vyskytnou. Predpokladam, ze na root lamy moc nechodi. Clanek by taky klidne moh zabrat tak tretinu objemu, ja jsem se po precteni par odstavcu priserne nudil... napriklad rozdil mezi normalizovanou a nenormalizovanou databazi by pokryl jeden odstavec, neni nutne omilat deset prikladu. A podle meho nazoru operator LIKE muze byt za urcitych podminek celkem uzitecny, stejne jako treba regularni vyrazy.
