Názory k článku PostgreSQL 9.6: odteď paralelně na více CPU
-
Dont panic! Diky za nazor, php jsem na chut neprisel, takze duvod asi nemam. Jina otazka - kdyz ted jsou vsechny filesystemy journalovaci, ma acid vyznam? A co to InnoDB v mysql, neni to acid? A proc phpckari nesli do postgresu?
Nicmene, jestli Ti otazky prijdou trollovite, tak se na ne vykasli, me staci tech 42. -
Ondra Satai NekolaZlatý podporovatelJournalovaci system zas tak moc neresi. Predstav si, ze ta databaze nad nim jednu transakci pise v nekolika operacich nad FS a nekde v puli se stane chyba. Pritom z hlediska FS ta chyba neprijde uvnitr jedne operace ale mezi operacemi... (ve skutecnosti to muze jit do kopru i daleko zbesilejsimi zpusoby, tohle je spis pro jednoduchou predstavu, kdyz to databaze neresi sama nebo v uzsi spolupraci s FS)
Nemluve o tom, ze FS velmi casto journaluje jen metadata. A nemluve o tom, ze journaling je prima idea, ale dneska je priklon spis k CoW, kde ale narazis na neco podobneho, pokud DB nebude minimalne pomahat reseni... -
Postgres je databáze - phpčkáři dost často potřebují jenom cache. Dneska se lze asi bez ACIDu obejít, ale potřebujete mnohem komplexnější infrastrukturu - data ukládáte redundantně, v případě výpadku musíte být schopný chybějící data zrekonstruovat, místo update operací děláte pouze append atd.
Navíc se víc kombinují ACID a ne ACID databáze - účetnictví a evidence se dělají v SQL databázích, monitoring, data mining v ne ACID databázích. Hodně záleží s jakými objemy dat se pracuje, jestli jsou k dispozici lidé, kteří datům, databázím rozumí, jaké jsou penalizace v případě nedostupnosti nebo ztráty dat.
InnoDB v mysql je ACID. Journálovací filesystém Vám asi moc nepomůže - typicky se, kvůli výkonu, žurnálem chrání pouze metadata. Vlastní data většinou nejsou jištěná, případně pokud jsou, tak je výkon horší než u databází - které i když jsou méně generické než obecný fs.
-
Palo (neregistrovaný)
Prepac nemal som v umysle ta urazat len mi to fakt prislo trochu scestne sa pytat na zakladne veci. ACID ma velky vyznam pokial jedinou ulohou tvojho kodu nie je niekam vlozit jeden riadok udajov. Journalovaci FS neriesi v tomto smere vobec nic. Jednak Journal funguje iba na metadata (vacsinou) a medzi transakciou a journalovanim je RADIKALNY rozdiel.
No a PHPckari su patlaci tak ako MySQLkari a tak nasli spolocnu jednoduchu rec. Potrebovali nieco ako 'o trosku lepsi filesystem' a MySQL im to poskytovalo. Naviac SQL je v MySQL trochu zjednodusene.
My si zivot bez PostgreSQL uz nevieme predstavit. MySQL odmietam zaradit do kategorie databaza resp OLTP. -
>zakladne veci
Jo, sorry, ze tu harasim o vecech, co jsou vsem ostatnim jasne. Premyslim ted o psql, kdybych chtel prejit, radsi ted, nez potom. Pak bych ale chtel jeste zkusit vasi trpelivost :
- bude mi jeste fungovat v bash ... echo "INSERT INTO peaks (pkid,run,time) VALUES ('$pkid','$run',NOW());" | mysql -u$USER -p$PASS $DBASE
Hlavne ten NOW() je fajn.- je to stejny system v commandline?: use database test; show tables; select * from tab;
- je kopirovani/presouvani databazi stejna pakarna jako v mysql?
- a taky- je tam stejne dobry prohlizec jako mysql-workbench?
Je otazka, jestli ma zmena smysl, ale ted si chci udelat relaci mezi tabulkami, delat vypocty a generovat grafy v xmgrace pomoci xmg.pl, tak nevim...mozna 'procedural languages' by bodly... Diky za snahu, jestli nekdo odpovi...
-
z commandline lze pracovat s pg velice dobře - parametry jsou ale jiné - viz psql --help. Místo now() je current_timestamp. Metapříkazy jsou úplně jiné - viz http://postgres.cz/wiki/P%C5%99echod_z_MySQL
Kopírování a přesouvání databází bude asi nemlich stejné jako v MySQL - dump/load - není to embedded databáze.
K dispozici je free pgAdmin 3, který pro základní práci postačí, mysql-workbench má širší záběr. Lze si koupit komerční admin nástroje - např. ems admin atd.
Procedury má pg lepší - lze použít Perl, Python, R
-
dustin (neregistrovaný)
Tak nějak. InnoDB/XtraDB je dnes přece standard a rozumné tooly s tím počítají (replikace přes id transakcí, hot-copy přes innobackupex atd.).
Samozřejmě jako všechno je spoustu příležitostí ke zlepšení (např. by se mi moc líbilo zprovoznění dalšího replikačního uzlu jednoduše jako např. v mongodb, i když by to šlo to automatické nalití naskriptovat...). Spíše mi přijde, že lidé apriori ohrnující nad mysql/mariadb nos ji moc neznají a nepoužívají...
-
MySQL i MariaDB se také posouvají dopředu - v něčem tyto databáze konvergují, v něčem nikoliv. MySQL, MariaDB jsou spíš zaměřené na velice intenzivní jednořádkové jednoduché operace nad základními datovými typy, Postgres teď už inklinuje k OLAPu - složitější dotazy, složitější schémata, případně nabízí větší komfort v SQL - neatomické typy, podpora CTE, analytických funkcí, XML, JSON, vlastních typů, ...
U MariaDB mám problém sledovat vývoj - některé funkce přebírají z MySQL, něco si píší samy a aby v tom byl větší zmatek, tak mají jiný release cyklus než Oracle MySQL, které konkurují/nekonkurují. Co se týče SQL, tak si myslím, že Oracle MySQL je nyní podobně jako Postgres před 6-8 roky. Zase, co se týče replikace, tak má MySQL náskok (i když něco, co se relativně běžně používá, tak je pro vývojáře pg nepřijatelné z důvodu hodně velkých rizik poškození dat). Ale ve firmách se to používá, bo je to zadarmo, a data se poškodí jednou za pár let (je dost pravděpodobné, že to padne na někoho jiného, než kdo ten systém psal nebo konfiguroval).
-
anonym069 (neregistrovaný)
"Proc lidi pouzivaj mysql, kdyz postgres je pry compliant?"
Protože buď nic jiného neznají, anebo protože všichni ostatní již zkušení programátoři (rozuměj "PHPkáři" samouci) používají také MySQL, respektive protežovaný LAMP/WAMP, takže se bojí jít proti davu.
Všimněte si, že když je tu na fóru položen dotaz na něco ohledně SQL a není uveden typ DBMS, na 95 % se bude jednat o MySQL (nebo dnes už i o MariaDB).
Zkuste si také vygúglit "php tutoriál", proklikejte všechny nekomerční odkazy na první stránce a v každém najděte kapitolu o databázi. Ve všech je MySQL! Pouze jeden na linuxsoft.cz (je třeba se proklikat až do 34. části) zmiňuje v poznámce pod článkem jako alternativní možnost PostgreSQL a Firebird, ale celkově to tam vyznívá jako nějaká pochybná undergroundová záležitost. A dokonce i ten, jehož jméno se nevyslovuje, ale jehož odkaz na mě vyskočil, má tutoriál o MySQL. A to vzpomínám na jeho "odborné" články o MS SQL Serveru proti MySQL. Škoda, že už nepíše, to bylo lepší čtivo než diskuze na root.cz ;-).
Prostě dokud si lidé budou myslet, že IT = Google a Facebook, a že programování = vývoj webů v PHP, tak také bude platit, že databáze = MySQL.
PS: Rozhodně se nechci navážet do seriozních aplikací používajících zrovna MySQL. Pokud se dá na stůl seznam všech existujícíh DBMS, z nichž se postupně podle jasně daných požadavků a jejich priorit jednotlivé databáze vyškrtávají, až zbyde zrovna MySQL, tak je to samozřejmě v pořádku.
-
Za sebe. Mysql je populární, protože kdysi byla postgres "neohrabaná na použivání", a tak se vžilo používání Mysql. Ta doba je dávno pryč.
V současné době, pokud člověk nepotřebuje replikace (tam je mysql lepší), tak je postgre jinde. Zaprve se její vývojáři striktně drží standardu SQL, takže odpadaj špeky typu - no projdi si sám:
http://sql-info.de/mysql/gotchas.html#1_1
umí toho spoustu navíc (např. pomocí CTE se napíše spousta dotazů daleko snadněji, než bez nich) a nemá různá zajímavá omezení na to, co se dá a nedá udělat - default current_timestamp donedávna mohl mít jen jeden sloupec, fulltext dlouhou dobu nešel na innodb tabulkama, nad isam zas nejsou trasakce atd.... hodně z toho už opravili, ale furt když se k mysql má člověk vrátit od postgre, tak skřípe zubama... -
V MySQL se replikace používat dříve - jednak z důvodu masivního nasazení v globálních web aplikací, druhak jako workaround - zálohování, výkonnostní problémy, problémy se stabilitou. Což byl pro vývojáře Pg nebyla cesta. Investovalo se stability místo do clusteringu. Primární nasazení bylo v single serverech. O dost později se začaly podporovat fyzická replikace Master/slave, Master/multislave která se nasazuje v korporátu. Jinde je to ale spíš výjimka.
-
dustin (neregistrovaný)
IMO se replikace/klastry u mysql nepoužívá kvůli problémům s výkonností nebo stabilitou (obojí je IMO OK a replikace to samozřejmě akorát komplikuje), ale hlavně kvůli zvýšení dostupnosti při poruše HW. Jak mám klientům zaručit chod jejich služeb, když je budu provozovat jen na jednom stroji? V tom mi nepomůže sebevychytanější DB, potřebuji více stále aktuálních instancí, na které mohu kdykoliv snadno přejít.
A ano, replikace pro účely zálohování je velice užitečná, protože není důvod zálohováním zatěžovat hlavní stroj/stroje pro klienty. Ale dovedu si představit zálohovat z něj napřímo, proč ne. Nicméně HA je pro dlouhodobé komerční používání zcela zásadní.
-
dustin (neregistrovaný)
Holt každý má nastavenou kvalitu služeb jinak... Když mi v serverovně na páteři umře server (a že se to opravdu stává, jednou to přijde na každý stroj, opakovaně bohužel vyzkoušené) a nemám jej zreplikovaný na jiný, na který dokážu službu vzdáleně v rámci minut/nejhůře málo hodin přehodit), pošlou mě korporátní klienti k šípku. A ano, opravdu k potřebě takového přehození bohužel dochází.
Provoz na alespoň dvou strojích (nebo jinak zduplikované řešení) považuju u komerčního projektu s platícími klienty za samozřejmost. Mysql to dává úplně v pohodě a není potřeba nad ní ohrnovat nos. Pro mě je daleko důležitější její schopnost replikace, než např. možnost spouštět procedury v různých jazycích (db používáme jako perzistentní storage pro objektovou in-memory databázi (defakto ORM), stavět dlouhodobě rozšiřovatelnou aplikaci nad přímými dotazy do relační db a při každém přidání nového údaje k objektu měnit strukturu tabulek bych vážně nechtěl).
-
Filip JirsákStříbrný podporovatelO MySQL tedy po internetu koluje spousta historek o tom, jak to poškodí data, aniž by vůbec došlo k nějakému hardwarovému problému. Takže z mého pohledu je to výběr, zda mít data spolehlivě uložená a v případě výpadku hardware počkat, než se data obnoví ze zálohy, nebo mít data sice replikovaná, ale možná špatně.
Navíc proti „úmrtí“ serveru se lze pojistit i jinak, než replikací – server může být virtuální, data mohou být na nějakém SAN, takže v případě výpadku hardwarového serveru jen přemigrujete virtuální server na jiný uzel – což splní ty požadavky „vzdáleně a během pár minut“.
-
dustin (neregistrovaný)
Jistě, pokud mám spolehlivý SAN, nemusím replikovat. Stejně tak mohu říct - pokud mám spolehlivý server, nemusím řešit problémy HW. SAN je taky jenom HW, se zdroji (třeba redundantními), základními deskami atd. Nákladově mi vyjde výhodnější několik replikovaných strojů, než distribuovaný SAN přes více uzlů. Navíc mám replikaci produkční DB přímo do firmy na další servery, kde se jednak zálohuje, jednak po "obfuskaci" používá pro vývojáře, kdykoliv si mohou spustit nalití ostrých aktuálních dat do svého prostředí.
Na mysql jsme nikdy neměli problém s výpadkem dat. Tabulky i desítky GB, stovky miliónů řádků, celkem cca 100GB/DB. Nasbíráno během cca 15 let. Samozřejmě se musí používat innodb/XtraDB s žurnálem a transakcemi, ale to je samozřejmost - stejně jako u jiných db.
Nemám vůbec nic proti PostgreSQL, naopak. Stejně tak nikomu mysql netlačím, jen nesouhlasím s hláškami lidí, kteří mysql osobně vůbec nepoužívají, prakticky neznají a argumentují "na netu koluje spoustu historek"...
-
Filip JirsákStříbrný podporovatel
Některé z těch historek jsou od lidí, kterým je věřím a nemyslím si, že by ten problém byl rukama. Např. zde. To, že nemám osobní zkušenost se ztrátou dat v MySQL, neznamená, že ji vůbec nepoužívám – ostatně, to už by bylo hodně zlé, nemyslíte? Z mého pohledu daleko dřív, než by došlo na potřebu replikace, skončí MySQL kvůli tomu, že nepodporuje spoustu databázových možností, které slouží pro zajištění logické konzistence dat. Jako jednoduché úložiště (v podstatě pro serializaci objektů) je podle mne MySQL výborná. Ale těžko si představuju projekt používající SQL databázi, kde logická konzistence dat bude záviset prakticky výhradně na aplikaci, konzistenci databáze také nemůžu úplně věřit, ale zato bych potřeboval on-line replikaci.
-
dustin (neregistrovaný)
Viz příběh - první používal myisam, tedy zamykaní tabulek při mysqldump (na innodb se používá pro dump přímo transakce). Druhý příběh nenastartoval innodb (nikdy jsem se s tím nesetkal) - pak by neměl vůbec žádná data - to fakt nevidím jako problém s konzistencí dat. Fakt ty dva příběhy neříkají nic o riziku ztráty dat v mysql.
Konzistenci dat nám drží referenční integrita a funguje, mnohokrát otestováno. Nepotřebujeme složitější podmínky konzistence, než vazby dle cizích klíčů . Ano, logickou konzistenci udržuje aplikace, protože nebudeme psát aplikaci v javě a stored procedures/triggery v mysql. Nebudeme kódovat byznys logiku do databáze. Ladění a každodenní vývoj/změny by pak přerostly v neudržitelný opruz.
Ano, je to pro nás jen objektový storage, ale poměrně velký, relativně rychlý, konzistentní a spolehlivý. Takovou máme zkušenost 15 let.
-
Filip JirsákStříbrný podporovatel
Kde je v dokumentaci MySQL napsáno, že MYISAM vede ke ztrátě dat? Proč vůbec něco takového je součástí projektu? Opravdu funkčnost replikace závisí na tom, jaký se použije storage engine? Kde je to zdokumentováno? A když uživatel řekne, že chce použít InnoDB, ale databáze použije MYISAM, je to také rukama?
-
-
Filip JirsákStříbrný podporovatel
Úplně stejně se dá argumentovati i o celé MySQL. Takže mi to jako moc dobrý argument nepřipadá. Mimochodem, v odkazovaném zápisku byly popsané dva případy, přičemž v tom druhém uživatel chtěl použít InnoDB, ale MySQL to sama změnila na MyISAM. Takže to možná ví každý až na vývojáře MySQL.
-
JuraF (neregistrovaný)
Ahoj, přepínač max_parallel_degree pro nastavení počtu pomocných paralelních procesů se zřejmě na 9.6 verzi (kterou mám na Debianu) jmenuje max_parallel_workers_per_gather (https://www.postgresql.org/docs/9.6/static/runtime-config-resource.html#GUC-MAX-PARALLEL-WORKERS-PER-GATHER). J.
