Názory k článku Používání indexů v PostgreSQL: krátce a pro začátečníky
-
Pro každý sloupec se udržují základní statistiky, které se spočítají na vzorku dat - viz pohled pg_stats a případně dokumentace k příkazu ANALYZE - zjednodušeně si lze představit, že se ke každému histogramu udržuje seznam nejčastějších hodnot a jejich četnost, průměrná šířka, počet unikátních hodnot, a hranice histogramu - viz http://linuxfinances.info/info/sqlqueries.html a na základě těchto hodnot se odhadne efekt predikátu http://www.postgresql.org/docs/devel/static/row-estimation-examples.html
-
jkb (neregistrovaný)
ze indexy vzdy neco stoji je sice pravda, ale ja mam posledni dobou zkusenosti, ze nejvice se to projevi, kdyz se index (zaznam) maze. Insert a update zaznamu neni zdaleka tak narocny. Docela to chapu, vselijakymi optimalizacemi je to mozno takhle nastavit a predstava vyrobcu databazi ( a asi i zkusenosti) jsou takove, ze delete je operace, ktera se pouzije mnohem mene, nez insert a update.
Ja jsem se podle toho zaridil a snazim se nic nemazat, ale jen oznacuji zaznamy jako smazane a v dobe 'nocniho klidu' je pak opravdu fyzikalne z databaze odstranim.
-
UPDATE může mít dopad na několik vybraných indexů, kdežto DELETE a INSERT má dopad na všechny indexy nad tabulkou - a vůči DELETE může být volání INSERTu lépe rozprostřeno v čase - jinak je tam celá řada vlivů - třeba i to, jak široký máte záznam, a jak často musí docházet k dělení nebo slučování stránek. Navíc, pokud byste neměl index nad sloupcem "smazano", tak může být UPDATE velice laciný i vůči implementaci MGA (díky HOT-UPDATE).
-
To IMHO není až tak úplně pravda - DELETE na indexy vliv nemá, resp. při DELETE se indexy vůbec nemodifikují, pouze se u záznamu nastaví ID transakce která to smazala (ale to je v tabulce, ne v indexu). Dokonce i množství dat zapisované do transakčního logu bude daleko menší. To co DELETE naopak udělat musí je např. kontrola záznamů v child tabulkách apod.
Takže DELETE nemusí být nutně pomalejší než INSERT/UPDATE, nicméně takové situace nastat mohou. Troufám si ale tvrdit že to není ani tak vlivem indexů ale má to jiné příčiny. Ale chtělo by to vidět strukturu / SQL a trochu to zprofilovat.
-
Ano, to je pravda. Vyjadřoval jsem se k tomu jak se to chová v Postgresu (kterému se článek věnuje především), a tam je MVCC architektura implementovaná jinak takže DELETE tímto výkonnostním problémem netrpí.
A předpokládal jsem že jkb který se o problémech s DELETE zmínil také mluví o PostgreSQL, ale možná ne.
-
jkb (neregistrovaný)
no, ja jsem mluvil obecne o vetsine databazi. Napr. v cervnu psal kolega nasledujici:
tabulka ma 12 milionu radku , mssql 2008, server 12 GB memory:
CREATE TABLE eav_einnahmen2(
id uniqueidentifier NOT NULL,
jahr int NULL,
monat int NULL,
vu tinyint NULL,
version tinyint NULL,
tz_ein smallint NULL,
gem_ein smallint NULL,
hs_ein int NULL,
tz_aus smallint NULL,
gem_aus smallint NULL,
hs_aus int NULL,
weg smallint NULL,
fs smallint NULL,
ps smallint NULL,
preis decimal(18, 2) NULL,
anzahl smallint NULL,
datum_kauf date NULL,
uhrzeit_kauf time(7) NULL,
datum_fahrt date NULL,
vw smallint NULL,
geraete_nr nvarchar(50) NULL,
ticket_nr nvarchar(50) NULL,
zahlung smallint NULL,
kunden_id nvarchar(50) NULL,
status int NULL,
original varchar(255) NOT NULL,
id_datei int NOT NULL,
PRIMARY KEY CLUSTERED
(
id ASC
)
);CREATE NONCLUSTERED INDEX einnahmen_datei ON eav_einnahmen2
(
id_datei ASC
);Zadne dalsi foreign keys, trigger. Pres prikaz:
delete from eav_einnahmen where id_datei=xxx;
se smaze 317271 radek cas: 6:32 min
select COUNT(*) from eav_einnahmen where id_datei=xxx ... cas nekolik milisekund
select * from eav_einnahmen where id_datei=xxx ... cas: 43 sekund
Jak je videt, problemy ma nejen Oracle.
Ted tedy k tomu b-tree. Podle me vyrobci databazi nijak zvlast neoptimalizuji ten DELETE ve spojitosti s tim b-tree, dival jsem se u tech jednodussich (sqlite, myisam) a tam se proste ten strom preorganizuje jak je to napsane v kazde ucebnici. Nevim nakolik pouzivaji ty vetsi db bulk-loading, coz je v takovych pripadech potreba, ale ono to asi neni tak jednoduche, protoze ta manipulace s tim stromem se neda oddelit od toho transakcniho zpracovani a to byla vlastne moje myslenka, ze v pripade DELETE je v tom asi nejaky zasadni problem.
Nakonec ono staci si zadat v google 'delet sql slow' a clovek vidi, kolik lidi se s tim pere.
-
Ivan (neregistrovaný)
Ta pomalost neni "problem", rozhodne to neni neco co by se dalo resit. Je to dan ze to, ze vase data jsou chranena databazi. Tzn. diky MVCC muze ke smazanym datum pristupovat jina konexe (protoze jeste nejsou commitnuta) a jeste navic muzete provest rollback a vsechna data do db "vratit".
Databaze, ktere nechrani vase data mazou velice efektivne.Pokud jde o operace nad stromem indexu, tak to se oddelit da. Resp. da se na to pouzit "lina" metoda.
-
Jenom drobné upřesnění - MVCC jako takové nemusí nutně znamenat pomalost DELETE operací, záleží na implementaci. Oracle má MVCC implementované pomocí UNDO, a tam to prostě pomalé je. PostgreSQL má MVCC implementované jinak (u každého řádku je informace o viditelnosti a v případě UPDATE se řádek duplikuje), a díky čemuž je DELETE rychlé (i když samozřejmě ne zcela zadarmo).
-
Koukam ze na partitioning taky nikdo nesah:
http://www.postgresql.org/docs/devel/static/ddl-partitioning.htmlmisto toho deti resi kraviny jako JSON a range data typ:
http://www.postgresql.org/docs/devel/static/release-9-2.htmlJediny zajimavy na co se vzmohli je index only scan. Ale podle manualu
http://www.postgresql.org/docs/devel/static/sql-createindex.html neumi do indexu zahrnout extra sloupec aby se vyuzil index only pristup.Priklad: mam index pro primarni klic A, ale zahrnu do nej taky sloupecek B. aby se dotazy typu select b where a=2 vzali z indexu.
Takhle to vypada kdyz o vyvoji rozhoduje komunita. Projekt potrebuje silnou osobnost ve vedeni ktera do toho HODNE VIDI. Kdyby meli u mne co do vyvoje kecat koderi tak by to vypadalo stejne.
-
Diskobolos (neregistrovaný)
To je zase výblitek z kontextu, co lenine? Hlavně že tebou zmiňovaný oracle v majoritně zastoupených verzích dodnes nemá ani OFFSET/LIMIT. O pomalém indexu při delete jsi se zmínil sám. Divím se ti, že vůbec svět opensource řešíš. Žij si v tom "dokonalém" komerčním světě plných silných osobností (však svět podle toho taky vypadá), plať licence za každý pšouk a diskutovat můžeš na webu MS.
-
Olineq (neregistrovaný)
Ono to vůbec vytržené z kontextu právě není. Oracle je na cpaní tun dat ve vícero threadech pořád mnohem rychlejší než postgres, a navíc se tam relativně slušně dá rozjet automatický partitioning na rozložení zátěže a rychlé dropování starých dat.
Novinky v postgresu mi přijdou naprosto nezajímavé vůči tomu, co by RDBMS určený pro enterprise nasazení měl primárně umět.
Jak řekl Lenin - hlavně že si děti hrají...
-
Diskobolos (neregistrovaný)
Cpát tuny... to jsi mě vážně pobavil. To je asi jediná činnost, kterou znáš/zvládáš, co? Především je třeba s těmi daty pak pracovat, víme Oline? Máme tady pár verzí velebeného oraclu a pracovat s těmi tunami dat je vážně balada (chápej ironicky). HW za staticíce, 2 fulltime lidi (z toho jeden certifikovný) jen pro hraní si konfigurací oraclu (indexy atd...) a neustále výkonostní problémy na řádově 10-tky miliónů vět (v pár desítkách tabulek). Mě je to jedno, já jsem vývojář. Jen mě sere, že mě to omezuje v práci a není NIKDO, kdo by to vyřešil. A to já sám za sebe nemluvím o komfortu, který mi postgre oproti oracle nabízí...
-
Ivan (neregistrovaný)
V tomhle se musim Oracle zastat. OFFSET/LIMIT nema jednoduse proto, ze tyhle veci implementoval davno pred tim, ze se to stalo soucasti ISO standaru.
Jejich politika je "bohuzel" takova, ze pokud pro nejaky problem existuje reseni, tak uz se zadne druhe nedela. Navic v Oracle mate skrolovatelne kurzory, takze muzete prochazet resultset dopredu a dozadu kolikrat se vam zlibi.Pokud jde o mazani tak Oracle taky nemaze z indexu, k jejich "cisteni" dochazi az v okamziku kdy se prijde na to, ze index obsahuje invalidni ROWID - rika se tomu index "browning" (na podzim listy stromu hnednou a opadavaji). "Perfomace problem" s mazanim je zpusoben tim, ze se pouziva UNDO tablespace. Smazani radky vyzaduje 1 OI operaci nad datovym tablespace, 1 OI nad UNDO tablespace, plus dalsi 2 IO operace nad redo-logy nad kazdym tablespace, takze to muze nakonec byt az 6 IOs pro jednu radku. Navic se do UNDO uklada pri delete cely obsah radky, zatimco pri insertu je to jen ROWID. Pokud vas zajimava jak to udelat lepe, tak se podivejte na Terradatu a na jijich dopredne a zpetne redo-logy.
Pokud jde o vytahovani hodnot z indexu, tak musim souhlasit s Leninem. Je opravdu paradni vec, se kterou se da dokazat spousta triku na zvyseni vykonu.
-
Tak Oracle má rownum, ale přiznejme si že spousta vývojářů to vlastně ani neumí správně použít protože je to komplexnější než OFFSET/LIMIT. Ono totiž prosté
SELECT * FROM tabulka WHERE rownum BETWEEN 1000 AND 2000
nefunguje úplně tak jak by člověk čekal. Takže aniž bych to Oracle chtěl nějak zazlívat, tak OFFSET/LIMIT mu prostě chybí.
Ano, covering indexy jsou samozřejmě moc fajn věc. Bohužel způsob jak je v PostgreSQL vymyšlený MVCC (zejména skutečnost že v indexech není informace o viditelnosti) implementaci komplikují. Ale index-only scany jsou nepochybně velmi výrazný krok k této vlastnosti.
-
1. offset/limit je prasarna ktera se predevsim nemela do standardu vubec dostat.
2. kazdy vyvojar to umi spravne pouzit protoze kdyz mu between v ORA nezafunguje tak SE ZEPTA.
3. existuje nekolik moznosti jak to udelat. Treba:
row_number() over (order by)
narozdil od offset/limit je to stabilni protoze O/L nevyzaduje order by
-
1. Proč? Nějaké konkrétní důvody? A proč by ROWNUM měl být lepší?
2. Neumí. 99% programátorů si prostě neuvědomuje že rownum se přiřazuje až úplně na konec, a jsou situace (např. v kombinaci s ORDER BY) kdy to jakoby funguje ale vlastně ne tak docela. Jasně, z manuálu se asi dá vyčíst všechno ale zrovna LIMIT/OFFSET je natolik primitivní konstrukt že pokud vás někdo nutí koukat do dokumentace a používat subselecty, tak je něco špatně.
3. Já netvrdím že to nejde napsat správně / obejít jinak. To ale nic nemění na tom že Oracle nemá LIMIT/OFFSET.
-
Pořád jsem se ale nedozvěděl proč že je LIMIT/OFFSET prasárna a vůbec se neměl dostat do standardu. Prosím o jasné věcné argumenty.
Řeč nebyla o window funkcích ale o použití ROWNUM k simulaci LIMIT/OFFSET, a o skrytých úskalích která jsou s tím spojena a o kterých většina programátorů vůbec neví. Samozřejmě, pokud si důkladně přečtou manuál od A do Z tak to asi napíšou správně, i když výsledné SQL bude podstatně komplikovanější / hůře čitelné kvůli subselectům, ale v zásadě to bude fungovat. Můj názor je že takhle primitivní funkcionalita jako je LIMIT/OFFSET by se měla dát používat přirozeně, bez podobných problémů.
Window funkce jsou samozřejmě moc fajn věc, jde jimi napsat spoustu věcí které by jinak napsat vůbec nešly nebo jen velmi komplikovaně. Problém je pro simulaci LIMIT/OFFSET se téměř výhradně používá ROWNUM, mimo jiné i proto že je to tak uvedeno ve všech materiálech Oracle.
A co se týká silných osobností / kvalitního vedení - netvrdil jsem a netvrdím že projekt nepotřebuje kvalitní vedení, ostatně lidé jako Tom Lane, Simon Riggs, Greg Stark, Bruce Monjian a další commiteři nepochybně silnými osobnostmi jsou a navíc mají přímou vazbu na praxi. Nemají sice možnost nějak ultimativně rozhodnout na čem mají ostatní pracovat, protože to prostě vesměs nejsou jejich podřízení, ale nepochybně mají velký vliv na to kam se projekt ubírá. Děje se tak ale primárně na základě požadavků od uživatelů, což je IMHO nejlepší zdroj informací pro takováto rozhodnutí.
To je důvod proč jsou naimplementovány věci jako range typy nebo JSON - prostě to implementoval člověk pro kterého je to užitečná vlastnost. Je samozřejmě pravda že některé hodně "internal" věci musí dirigovat přímo lidi z core - týkalo se to replikace, týká se to partitioningu a podobně.
-
OFFSET je prasarna protoze nevyzaduje ORDER BY. Puvodne to tam vubec nemelo byt, ani oracle ani ibm to nechteli.
ROWNUM je v oracle implementovano tak jak to bylo nejjednodusi. V DB2 je naimplementovano podle ocekavani.
Window fce se nepouzivaji protoze je oracle ani db2 neumi pro tento pripad dostatecne dobre optimalizovat. Nedival jsem se ale co umeji nejnovejsi verze techto db - db2 10 a oracle 12, zda se tam na tom nemaklo.
pouzivani limit/offset pro listovani ve vysledcich je nevhodne protoze to nedava konzistentni vysledky, data se muzou mezitim zmenit. scrollable cursor nebo nacachovani je mnohem lepsi.
Vedeni ktere nemuze ridit lidi nema "nepochybne velky vliv". Vedeni ma udavat smer, ne byt jen policajt aby deti nedelali obzvlast velke kraviny.
-
100% Lenin (neregistrovaný)
Musim souhlasit hlavne s temi detmi.
Oni, myslim ta decka, kdyz si hraji a mrsknou do produkce cross join nekolika giga tabuli a k tomu vicero left joinu pres jine gigatabule a vypadne diky tomu produkce. Tak je to na vrazdu nekoho z IT.
Pokud si to deti neuvedomuji, tak mnohda je jedna hodina rovna 1 000 000 USD ciste ztraty.Procez ... + 1000
A remcalum poradim. Nemusite souhlasit, nemusite verit. Ale v mnohem ma nas sourecnik pravdu a dnesa vice jak stoprocentni.
Experimenty patri do vyvoje. Ale tvrdy a stabilni kod do produkce.
Bez pevneho vedeni ji nezajistite.Tedy< Experimentujte si deticky za svoje. Jak tak na to koukam / tak se nam mnozi jak trpaslici. A nezalezi uz ani nahodou na windows a nebo na Linuxu coby vzdelavaci platforme.
Nejak to jde z kopce. No neni to prauda? Dajano?
-
Stejně jako Pavel Stěhule naprosto nechápu co jste tím vlastně chtěl říct, resp. jakou to má relevanci k předchozí diskusi.
To že vám někdo nasadí crossjoin produkující bambilión řádek skutečně není chyba PostgreSQL, to musíte fackovat aplikační vývojáře kteří ten SQL dotaz stvořili.
Při vývoji PostgreSQL se neexperimentuje - rozhodně ne v tom smyslu že by se do ostré větve commitovaly nějaké experimentální věci. Každý patch prochází poměrně drtivým veřejným review během kterého se mimo jiné zkoumá jestli to je vůbec dobrý nápad, jestli to nemá nějaký dopad na existující aplikace, včetně dopadů na výkon apod.
Neznám jiný projekt (komerční nebo open-source) kde by kontrola byla tak důkladná a pečlivá.
-
Ivan (neregistrovaný)
JJ. OFFSET se poziva jen na prochazeni velkych record setu na webu. Tim se vlastne jen obchazi problemy webovych aplikaci a prenasi se nekam jinam.
Oracle na tom maknul ve verzi 11g, ale uplne jinym zpusobem. Oni implementovali neco jako je MaxConnect na Informixu. Tzn. na aplikacnim serveru si nainstalujete OCI proxy server. Ten drzi skutecne DB konexe, vcetne otevrenych skrolovatelnych kurzoru.
S timhle proxy serverem se bavi klient (treba PHP) a posila mu requesty. Tim se da docilit toho, ze ruzne Unixove procesy "sdili" jedno TCP spojeni do databaze.
Anebo muzete prochazet nejaky obrovsky result set vramci nekolika HTTP requestu, a nemusite drzet vsechna data v pameti. -
No, to že LIMIT/OFFSET správně funguje jenom ve spojení s ORDER BY je pravda, ale rozhodně si nemyslím že by to z LIMIT/OFFSET dělalo prasárnu. A už vůbec si nemyslím že by snaha nezahrnout to do standardu byla ze strany IBM a Oracle byla motivována snahou o čistotu. Oni prostě v dané chvíli měli nějaké svoje specifické implementace a zahrnutím do standardu se z nich stává nestandardní chování (tj. specifická implementace se standardizovanou alternativou). Nějakou snahu o vyšší blaho bych v tom nehledal.
Ano, používá se to často pro stránkování - neříkám že je to vždy ideální řešení, ale ony kurzory také nejsou dokonalé. Navíc u bezstavových aplikací (resp. tam kde se stav předává např. v URL) to moc dobře použít nejde. Navíc nepochybně existují i use-case kde kurzory nejsou dobré/efektivní řešení.
Co se týká vedení - zjistěte si prosím jak funguje vývojový model PostgreSQL a jak jsou do toho zapojené firmy jako EDB, 2ndQ a spoustu dalších. Těžko polemizovat s člověkem který tu před pár týdny tvrdil že na vývoji PostgreSQL pracuje 20 lidí, protože mu Ohloh ukázal jenom commitery ...
Mě se ten model líbí, ale netvrdím že je dokonalý a že by vývoji některých featur neprospělo těsnější řízení shora.
-
Tys nepochopil ze rychlost vyvoje pgsql je tragicka i kdyby ho vyvijelo jen 20 lidi. Podivej se co se za rok udelalo. Tomu rikas odpovidajici vysledek prace 20ti lidi?
Az krcmar konecne opravi forum tak tam placnu statistiky z clear case nasich lidi. Uvidis ze nekteri borci delaji i 12 tisic radku tydne. Prumer je 6k radku za tyden na kodera. Mame vyssi zisk na zamestnance nez EMC, proto nam tu stoji uz 3 tryskace pred barakem.
Podivej se na zmeny v Oracle nebo DB2 a porovnej to se zmenama v pgsql. Kazdym dnem ztracite vic a vic. Ted jsem sjel JDBC driver a neprojde ani TCK JDBC API version 2. To je za 10+ let vyvoje dost slaby. Pro podnikove nasazeni je pgsql naprosto nevhodny, nema ani potrebnou zakladni funkcionalitu a ani ekosystem jako ma mysql.
V PGSQL nejsou v CR vubec zadny prachy, ani Stehule se tim neuzivi je normalni zamestnanec. lidi to pouzivaji PROTOZE JE ZDARMA a tudiz jaksi z principu NECHTEJI PLATIT, takze vlastne musis PRACOVAT ZADARMO. PGSQL proste neprorazi nikdy, neni o nej prakticky zadnej zajem v podnikove sfere a to i presto ZE JE ZDARMA. Naucte se videt svet takovy jaky je a ne takovy jaky by jste ho chteli mit.
-
Diskobolos (neregistrovaný)
Lenine, za hlášku "Prumer je 6k radku za tyden na kodera" ti tleskám - stále umíš pobavit. :-D Zajímala by mě ale ta kvalita. No určitě bude ale bombastická, stejně jako ty tvoje nabubřelé kecy a tryskáčích apod. Koukni na http://www.postgresql.org/about/users/ - já myslím, že PgSQL bez problému funguje i na podnikové úrovni. Je to cílovka pro jiné typy lidí, než jsi ty. Shazovat a dehonestovat přínosný a fungujícíc projekt může jen egoistický hlupák nebo zamindrákovaný jedinec. Postgres má svou kvalitu a tvoje hloupé kecy na tom nic nezmění. Drž se skvělého Oracle a IBM, btw - narazil jsem na tvojeho zaměstnance, viz. http://www.hovnokod.cz/763
-
Přemýšlím na co mám odpovědět - JDBC se tu už probíralo 100x - nemá cenu komentovat dále. Posuzovat ziskovost PostgreSQL podle mně asi nedá ten pravý obraz - stejně jako kdybyste posuzovali střídavý proud podle Tesly. V Anglii, v Americe, v Německu, ve Francii je několik úspěšných firem - tady v ČR má docela dost firem postavené své produkty na PostgreSQL - a konečně mně můj zaměstnavatel platí primárně za mé znalosti pg, které bych jinak než hackingem nezískal - takže se z Postgresu dá uživit - je otázkou, jak by vypadal byznys s obchodníky, marketingem - reklamou. Vyjma rootu nikde nic nemám - v novinách se o mně nedočtete.
Nedávno jsem školil v jedné japonské firmě, kde nasazují PostgreSQL na důležité řídící systémy - což by Japonci, pokud by nebyli přesvědčeni, že to je dobrý sw nikdy neudělali. Shodou okolností odcházeli z Oraclu. Takže asi tak - zatím rok od roku roste zájem o školení, konzultace. Roste zájem i o P2D2.
Jinak ohledně rychlosti vývoje jste v první lize s Hulánem - gratuluji.
-
Ten JDBC driver je pro vas lekce aby jste se uz ve svych letech naucil divat se ocima managera jinak se dal v zivote nedostanete.
Vas zamestnaval vam tezko plati za tak PG specificke znalosti co mate. Plati vam za administraci ci programovani, ale to muze delat misto vas kdokoliv jinej a vyjde to nastejno. Pod pojmem uzivit se si predstavuju unik z "rat race".
Vedeni fabriky ktere se rozhodne vymenit profi soft za neco co si zpatlaji doma je zidovska produkce. Kdyz se to povede tak tim neziskaji prakticky nic vzhledem ke cash flow jaky ma tovarna, kdyz to neudelaji dokonale tak hodne ztrati. Vzhledem k tomu ze nemaji kvalifikovany IT lidi - jsou fabrika a ne firma delajici SW, tak budou mit horsi vysledek nez ten co meli predtim. Navic se jim odrizne pristup k know-how, ekosystemu a nastrojum pro Oracle, ktery jsou hodne dobre. pgadmin3 je hnuj, mrknete se jak vypadaji performance nastroje pro oracle, ty umi velmi detailne zjistovat co se v serveru deje; pgsql tak podrobne statistiky ani nezbira. Ukol managementu tovarny je zajistit aby SE PRODALO. Firma ma delat jen to co umi dobre a efektivne, ostatni veci je levnejsi si koupit. Semtam se nejaky trouba najde, co premigruje na pgsql a mysli si ze usetril, stejne tak nejaky trouba skoci na nigeria scam.
Proc se ale cilene zamerovat na zakazniky co nechteji platit? Vzdyt vidite ze to neuzivi na fulltime ani vas. Muzete si litat po svete a davat konzultace fulltime?
Ja nechapu proc se vsichni z roota cpete s takovou vervou do lowendu. To nechapate ze budete celej zivot zivorit? Kdyz mluvim s klukama a holkama tady tak maji hezke plany do budoucna a pracuji na tom aby je zrealizovali. Vy se tady nechcete ucit nic, vase idealni mistecko je - naucit se to nezbytne minimum a pak flakat se nekde za co nejvic penez. Nedavno jsem vyrazil jednoho cecha, chtel abych pro nej nasel misto za 90 tisic rocne kde by nemusel nic delat. At si ho jde laskave hledat sam a ne v pracovni dobe.
-
Je úsměvné že přes dvěma měsíci jsi mne tu Pavla Stěhule a mne lákal jak ti máme za milióny pomáhat přepisovat PostgreSQL na mainframe, že to bude super business se strašným ziskem, a dneska se tady opět dočítám jak je PostgreSQL strašně na pikaču. Proč jen mi to přijde zvláštní?
Celkem by mne zajímalo odkud berete polopravdy o tom kdo se čím uživí - nenapadá mne nic jiného než křišťálová koule. Žádná konzultační / support firma okolo PostgreSQL tu není jednoduše proto že ji nikdo nezaložil, takže spekulovat jestli by se uživila nebo je je skutečně jenom spekulování. Firem která PostgreSQL používají a měly by zájem o podporu tu málo není.
A k tomu měření produktivity přes počet řádek kódu - gratuluji, super nápad, ale děkuji nechci, nejsem blázen.
-
zOS je jedina platforma kde by se MOZNA dalo na pgsql vydelat a zuzitkovat tak Stehuleho vedomosti, protoze zakaznici maji prachy ale obcas prskaji nad licencnima castkama za DB2 for zOS. Kdyby se jim nabidla alternativa, rekneme $40k/procesor jako to ma oracle na unixu tak by to vzali pokud by vykon nebyl uplne mimo.
Vondra, tobe bych ale zadny procenta uz nedal. Pises sem strasny kraviny, ses ale uplne mimo. Stehule ma alespon vzdalenou predstavu o tom jak funguje byznis, toho kdyz se vzda svych ruzovych bryly, tak ten by pak moh na vedeni vlastni firmy casem mit, potreboval by jeste alespon pulrok delat nejaky management nekde kde by byl trenovan pod dohledem.
Programovani je TO KDE SE VYTVARI HODNOTA. Projekty se posouvaji dopredu tim ZE SE NA NICH DELA. Kdyz nenaskakuji radky tak se jen mlati hubou a to nestaci.
Kdyz programujes malo, tak to je jasny ze te to nebavi. Bavit te to zacne az kdyz to poradne rozjedes a das 10k za tyden. Pak si budes sam sebe vazit, protoze ses PAN PROGRAMATOR. Da si 3 tydny za deset tisic a pak oznamis leninovi - Lenine, potrebuju jeste maknout na tom golfu, pujc mi tvoje hole, trenera a vstupenku do golfovyho klubu pro snoby. A celej tejden si pak mlatis klackem do micku a pochopis ze sis prave uniknul z toho krysiho kolecka.
Vondra, zivot funguje - nejdriv davej a potom dostanes. Ty ho ale zijes - nejdriv at dostanu a potom *mozna* dam.
-
Lenine, snažně prosím, nevyjadřuj se k životu lidí o kterých vůbec nic nevíš. Zejména pokud jsou to taková "moudra" jako v tvém předchozím postu.
Jasně, PostgreSQL má šanci jenom na zOS. Proto EnterpriseDB v minulém roce vyrostla o 80% ... Ale když máš tak supa-dupa programátory, tak oni ti to přece přeportují. A nebo jinak - když máte produktivitu 5k/týden na člověka, PostgreSQL má dneska cca 650k řádek, tak oni ti to ve třech lidech napíšou úplně znova (a určitě líp) cca za rok, ne? Leda že by počet řádek / hlavu poněkud zavádějící metrika.
Víc asi radši no comment.
-
Ja jsem nespokojeny kdyz se nejede na MAX. Teprve pak ten zivot dostane poradny grady a zacne to lidi bavit. Kdyz treba jdete na koncert, chcete tam videt jak to ta kapela poradne rozbali nebo se tam divate na chciply princezny co se boji ze by se jim rozbil makeup.
Tryskac je zaokrouhlovaci chyba v rozpoctu, ten nereste. Kdyby jsme nemeli letiste pred barakem tak ho taky nemame vlastni a pronajmeme si ho. Pro zajimavost se podivejte na cenu nemovitosti a pozemku.
Kdyz chcete byt uspesni v cemkoliv, musite to umet rozjet. Slusni, hodni chlapci to nikdy nedaji protoze povazuji konflikty za neco cemu by se meli vyhnout. Boji se cokoliv risknout. Uvedomte si ze se musite narvat do trzniho prostredi, kde je potreba narusit zabehane toky penez a presmerovat je k sobe.
-
Už jsem o tom několikrát psal - v Postgresu o vývoji nerozhoduje komunita - ale každý konkrétní vývojář, který napíše patch - potažmo firma, která si zaplatí vývojáře, který napíše patch. Tuhle databázi používají tisíce firem a každá má jiné priority - a každá trochu jinak a v jiné míře přispívá do vývoje. Aktivní firmy své fíčury mají v pg během roku.
Jinak k index only scanu - nic Vám nebrání si udělat coverage index - prostě místo n sloupcového indexu uděláte n+m sloupcový. Výkonnostně by to mělo vyjít nastejno.
-
Vývojáři řeší problémy které je a jejich zaměstnavatele tíží - proto tam jsou zahrnuté JSON nebo range typy (mimochodem velmi užitečná věc), protože dotyčný člověk resp. jeho zaměstnavatel to považovali za přínosné pro svoje účely a investovali do toho svůj čas a případně peníze.
Samozřejmě často se naráží na komplexní problémy které asi není schopen vyřešit člověk mimo omezenou skupinu lidí kteří vidí do internals. To je případ partitioningu který skutečně nemá odpovídající funkčnost - o tom se ví a všichni to uvádí jako jednu z priorit pro nejbližší dobu, společně např. s paralelizací vybraných míst apod.
Nevěřím v silné osobnosti které ze svého kapitánského můstku vedou vývoj produktu - to je utopie. Úspěšné vývojové modely vesměs fungují tak že od uživatelů sbírají požadavky na funkčnost, nějak se řadí podle přínosnosti a pak se implementují. A takhle nějak ve svém důsledku funguje i vývoj PostgreSQL, ačkoliv tam není žádná centrální entita která by ty požadavky sbírala a třídila.
-
Trm (neregistrovaný)
No, neni to zly. Ale kdyz jsem cetl o ,,dvou typech databazovych relaci, tak jsem si rikal, ze si asi budu muset zopaknout diskretni matematiku, protoze se asi ,,objevilo neco noveho. Ale nakonec vsechno dobre dopadlo, relace je furt ,,jen jedna'', Maier, Date, ani Hopcroft nemuseji ty svoje bible prepisovat.
-
Lyco (neregistrovaný)
V článku mi chybí zmínka o proměnné effective_cache_size http://www.postgresql.org/docs/current/static/runtime-config-query.html#GUC-EFFECTIVE-CACHE-SIZE. Je to jedna z věcí, které silně ovlivňují jestli Postgres použije nebo nepoužije index, a začátečník si na tom může snadno vylámat zuby (mluvím z vlastní zkušenosti). Stačí aby databáze byla dost velká, v konfiguraci nebylo nastavené dost paměti, a člověk se může jít hlásit na hlemýždí závody.
-
juju - díky za připomenutí - tahle proměnná se vztahuje spíš k optimalizaci, ale určitě by neškodilo, kdyby byla zmíněna - stále platí desatero http://postgres.cz/wiki/Desatero
-
Skalimil Vuk (neregistrovaný)
Zdravím, zkoumám v článku zmíněnou databázi Monetdb a SciteDb. SciteDb zřejmě nevyužiju, i když kdo ví, každopádně to je trochu odlišná filosofie.
Ale co Monetdb? Když čtu dokumentaci, vypadá to jako běžná SQL databáze. Pracuje se pomocí SQL, v podstatě to lze asi používat bez učení, kdož zná třeba PostgreSQL.
Chápu to dobře, že základní rozdíl třeba oproti PostgreSQl je ukryt pod kapotou? A velice zjednodušeně řečeno, pokud používám převážně SELECT a případně INSERT, bude na velké databáze vhodnější Monetdb, zatímco pokud používám často UPDATE, pak je asi lepší zůstat u PostgreSQL ?
-
V podstatě asi ano, ale je to složitější - záleží na tom jaké dotazy nad tím spouštíte.
PostgreSQL je výborná na OLTP zátěž, tj. spousta malý transakcí - operace nad jednotlivými řádky (nebo malým počtem řádků), ke kterým se typicky přístupuje přes PK.
Lze ho samozřejmě použít i na DWH/DSS zátěž, tj. dotazy pracující s velkým počtem řádků najednou - typicky třeba měsíční uzávěrka, joiny velkých tabulek, agregace apod. Má to ale tu nevýhodu že PostgreSQL je "row store" tj. řádky jsou uloženy pohromadě a i když čtete jenom jeden sloupec tak se musí načíst celý řádek.
MonetDB je "column store" což je výhodné právě pro DWH/DSS zátěž, ale při OLTP s tím budete mít výkonnostní problém (hlavně při modifikacích).
-
Skalimil Vuk (neregistrovaný)
Díky. Už chápu, klíčová slova jsou OLAP versus OLTP :-)
Překvapilo mne, že se vývojář nemusí nic učit, aby přešel třeba z PostgreSQl na Monetdb. Inu, je to stále SQL databáze.
Takže kdybych uvažoval o nějaké NoSQL databázi kvůli rychlosti nad obrovským množstvím dat (což se uvádí jako důvod užití těchto databází), pak je na zváženou použít nějakou SQL databázi s OLAP ukládáním dat.
-
SQL je stejné, ale zbytek je dost odlišný - i když třeba na úrovni ETL nástrojů se rozdíly stírají - extrémně záleží na velikosti analyzovaných dat - MonetDB je částečně paměťová databáze - je velice rychlý v případě, že se Vám data vejdou do RAM - pak může být stejně rychlý jako Cčkový program - tedy, klidně o dva řády rychlejší než PostgreSQL na stejném hw.
Pokud se nevejdete do RAM, tak zrychlení klesá zhruba o řád - nicméně stále budete mít jednodušší hromadné nalévání. Sloupcových, případně paměťových SQL databází je víc - a mezi nimi jsou podstatně větší rozdíly než např. mezi MySQL a PostgreSQL.
NoSQL databáze se mohou hodit v případě ultra velkých dat (TB) - kdy můžete díky map/reduce redistribuovat zpracování dat mezi větší množství serverů.
-
Paja (neregistrovaný)
I kdyz sem se snazil projit vsechny vygooglene helpy k nastaveni pameti, porad mi chybi nejake spolehlive doporuceni k nastaveni postgresu.
Konkretne: server ma 24GB RAM, je dedikovany jen pro databaze (cca 8GB zapakovany postgres, + test server tohotez + cca 6GB zabaleny firebird). Dale ma radic s 1GB NV RAM a disky jsou 15k rmp SAS v raid 5. Pro produkcni postgres muzu uvazovat s cca cistych 12GB RAM. Zapisuje se 5-10k transakci denne. Pri zapisu se trigery overuje konzizstence a omezeni (napr. zaverka skladu). Aktualne nema server vykonnovy problem.To ze ma server relativne dost RAM vzhledem k velikosti DB a ze ma radic s 1GB NVRAM mi trochu boura predstavu o kvalite vygooglenych dporuceni.
A ani netusim, z ceho vychazet pri konfiguraci.Pak mam jednu poznamku k ruseni a obnovovani indexu pri vytvareni reportu. Osvedcilo se mi v nekterych pripadech vytvoreni temp tabulky. Oproti vypoctu napr. procentualni dostupnosti top 100 produktu na prodejnach s indexy a temp tabulkou se to zrychlilo 20x.
-
Sice RAID5 je asi to nejhorší, co můžete udělat, ale vzhledem k dostatku RAM a minimu transakci to musí zvládat v pohodě - konfigurace pg - např. zde http://postgres.cz/wiki/Desatero#P.C5.99id.C4.9Blte_PostgreSQL_dostatek_pam.C4.9Bti
Optimalizace dotazů je občas alchymie - a to včetně dočasných tabulek - na jednu stranu jsou docela drahé - na druhou stranu pokud vám ustřelují statistiky, tak dočasná tabulka může "přerušit chybu" v aplikaci statistik a šíření chyby a tudíž planer může vygenerovat skutečně optimální plán - případně i nad dočasnou tabulkou je možné vytvořit indexy a zase o něco zrychlit provedení dotazu.
-
V situaci kdy databáze sdílí železo s dalšími neznámými aplikacemi, těžko nějak radit. Ne úplně jsem pochopil co se myslí tím "zapakovaným postgresem" a "zabaleným firebirdem"?
Každopádně standardní doporučení zní shared_buffers = 1/4 dostupné paměti, takže pokud 12 GB zabírají jiné aplikace tak nastavte plus minus 2 až 3GB shared. Také mi není jasné jak z toho plyne velikost databáze, nicméně ona je spíš důležitá velikost aktivní části té DB (s kolika MB/GB se skutečně aktivně pracuje).
Co znamená 10k transakcí za den? Jak ty transakce vypadají? Pokud jsou to malé transakce (insert pár záznamů, pár updatů a deletů) tak 10k / den je pod hranicí šumu, zejména když tam máte řadič s 1GB write cache. Ale pokud to jsou nějaké velké bulk operace tak vám ani ten 1GB nemusí stačit - RAID5 je obecně asi nejhorší RAID varianta pro zápis.
-
Paja (neregistrovaný)
Premyslel jsem nad tim. Je pravda, ze od doby porizeni serveru pred dvema lety mame asi pul roku novy aplikacni server, kde jsem zvirtualizoval vsechny ostatni servery krome tohodle databazoveho. Testovaci databazi i ucetni firebird presunu na ten aplikacni. Z RAID 5 udelam RAID 10 (jsou tam 4ks 15krpm 2,5" 146GB, coz bude kapacitne stacit s velkou rezervou). Drive tam behal napr. i virtualni 2008 server. Takze budu mit celych 24GB pro primarni databazi a zadne jine aplikace tam nebudou.
Tim zabalenym jsem myslel cista komprimovana data. S indexy ma ta primarni databaze 22GB. Nejvic zabiraj soubory (7G) ale s temi se nepracuje. Dalsi jsou skladove pohyby (3,5GB) - tam se saha furt. Treti je materializovane view - datova kostka pro obchodniky (3GB) s tou se taky pracuje intenzivne.
Temi transakcemi myslim zapis obchodni transakce. Typicky hlavicka dokladu, radek dokladu, rozpad na skladove pohyby, zmena skladove karty vcetne kontroly konzistence, podnet k prepocitani datove kostky a prenosu zmen na web. Takovato transakce trva cca 100ms. Jenze kdyz jich prijde 10 najednou, uz to ty ostatni brzdi. Ne ze by si toho bezny uzivatel vsimnul. Jen si myslim, ze nerozumim uplne nastaveni pameti a nastavit to jen od oka je ma neschopnost. Treba by se trivialnim nastavenim pameti dala zvysit propustnost. Nechci to resit az to bude potreba resit. Je pravda, ze z hlediska prumerneho zatizeni je to pod hranici sumu.
Nektere view pracuji se znacnym objemem dat. Sice je pouziva velmi mala cast firmy a je to porad rychlejsi, nez jine systemy se kterymi sem mel moznost pracovat, nicmene pokud by nastaveni pameti urychlilo slozitejsi view, tak to tak rad nastavim. Jenze netusim jak.
Slozitejsi transakce (prevod mezi centralnim skladem a pobockami o nekolika tisicich radcich) dela jen par lidi. Takze jestli to zapisuje 30 sec, nebo 2 sec je skoro jedno - kdyz to delaj jednou denne.Zkusim prostudovat ty doporuceni. Jenze zatim jsem vzdy jen nasel doporuceni ale nevim proc to nekdo takto doporucuje.
PS: dik za komentar (i komentar autora clanku), bez nej bych se asi k predelani serveru nedokopal
-
Tomas (neregistrovaný)
Prosim, rad by som sa opytal na vas nazor na riesenie nasledovneho problemu:
Tabulka, cca 2 mil zaznamov, jeden z nich textovy, dlzka cca 30 az 40 znakov obsahujuca slova napr. ferko mrkvicka v katedrale.
Problem: v tomto stlpci potrebujem efektivne vyhladavat zaznamy obsahujuce zadane slova. Priklad:
Vyhladavam ferko mrkvicka kat - zaujimaju ma zaznamy obsahujuce ferko, mrkvicka a zaroven vsetky slova ktore zacinaju na kat tj. A napriklad yssie uvedena katedrala ale a katedra atd.
V klasicke databaze sa to da riesit via lika. Mna napadlo pouzit klasicku databazu, stlpec tokenizovat tj. Vytvorit slovnik vsetkych moznych slov a nasledne v relacii 1 ku N priradit pre jednotlive zaznamy idcka do slovnika tj. Pre priklad vyssie idcka vsetkych styroch slov. Nasledne vyhladavat v slovniku tj. Zistit idcka, cezmidcka zistit idcka zaznamov a tak sa dopracovatk vysledku. Avsak mozno existuje specializvana databaza o ktorej neviem ;)
Za kazdy napad budem vdacny ;)
-
Nejsem autor ale i tak se pokusím odpovědět ...
V podstatě asi nejlepší způsob jak to vyřešit je přes fulltext přímo v databázi - implementace závisí na konkrétní databázi, v PostgreSQL tu funguje zhruba tak že si vytvoříte konfiguraci která říká podle jakého slovníku a pravidel se má skloňovat (např. slovensky nebo vůbec), následně nad daným sloupcem vytvoříte fulltext index a pak hledáte - efektivně (přes index), můžete si nechat spočítat score apod. Popsané je to tady: http://www.postgresql.org/docs/9.1/interactive/textsearch.html
Druhou možností (pokud se mermomocí chcete držet LIKE) jsou trigramy - jednoduše každé slovo se rozloží na trojice znaků, ty se oindexují a pak se v tom dá hledat (opět celkem efektivně) - podrobnosti viz. zde: http://www.postgresql.org/docs/9.1/interactive/pgtrgm.html
Toto jsou možnosti v rámci PostgreSQL, v jiných DB to může být trochu jinak.
-
Vítejte do světa MySQL, kde každý storage engine implementuje jinou nekompletní sadu vlastností :-( Jedna možnost je udělat si tam duplicitní MyISAM tabulku do které se data nějak kopírují a tam už to fulltext umí. Ale je to takové "drbání pravou nohou za levým uchem".
Ale když už jsme v diskusi pod článkem o indexech v PostgreSQL, tak jsem si vzpomněl že ono LIKE jde optimalizovat i přes obyčejné b-tree indexy, je akorát potřeba správně nastavit operator class.
Každopádně jsme už hodně hodně offtopic, takže pokud nehcete migrovat na PostgreSQL tak bych tu diskusi asi přesunul jinam.
ČLÁNKY DO MAILU