PostgreSQL 9.5

Byl vydán PostgreSQL 9.5. Nejnovější verze tohoto relačního databázového systému s otevřeným zdrojovým kódem přináší celou řadu nových vlastností a vylepšení. Zdůraznit lze například nový příkaz UPSERT (INSERT ... ON CONFLICT DO NOTHING/UPDATE), možnost nastavení práv pro jednotlivé řádky (Row Level Security) nebo několik vylepšení pro Big Data. Podrobnosti v poznámkách k vydání.

8.1.2016 10:30 | Ladislav Hagara | Nová verze

Komentáře

[Max]

Zajímalo by mně, zda má někdo zkušenost s Enterprise verzí a třeba i s koexistencí s Oracle (db link apod.)
Zdar Max

[noo]

Srát na Orákl

[Max]

Tvé vyjadřování značí, že mluvím s trollem, nebo s někým, kdo postrádá vychování. Ale budiž, budu se ti snažit odpovědět k tématu. Jak asi přiměješ firmy k migraci z oracle na postgresql, když mají nad oraclem postavených hafo věcí. Přepisování je nejen finančně náročné, ale hlavně časově. Je tedy lepší provést migraci, nebo nasadit postgres k oracle jen pro nějaké služby a migrovat a případně přepisovat postupně, nebo vůbec.
Co vím, tak Enterprise verze postgresql se chlubí kompatibilitou s oracle. Tzn. funkce, packages, PL/SQL, triggery, sekvence, db link a spoustu dalších věcí.
Jen mně zajímá, jak moc je to kompatibilní / spolehlivé, zda s tím má někdo zkušenosti ...
Zdar Max

[okbob]

Určitou zkušenost s EDB mám - hodně záleží na tom, jak moc byli vývojáři kreativní. Aplikace pro starší verze Oracle rozumně psané lze převést jednoduše - a přepis (optimalizace) je nutná jen z výkonnostních důvodů, . Jinak spolehlivost a výkon - je to Postgres - vyjma vrchní vrstvy se to od normálního Postgresu liší minimálně.

[Chulda]

kolega oraclista byl na školení ohledně migrace z oracle na postgresql a byl dost rozladěný. Podle něj sice prezentovali, že postgres umí všechno co oracle a to prý svým způsobem je pravda, ale jen pokud se to srovnává se starší verzí oraclu. Konkrétní verze nevím a momentálně je out, takže se ani nezeptám.

Tedy záleží na tom, jak moc byli vývojáři kreativní. Ale obvykle o oracle moc nevědí, takže máš naději

[okbob]

Ono v reálu velká většina aplikací je psaná pro 10ku a to programátory, kteří jen málokdy jsou databázovými specialisty, já bych si tipoval 80%. Což je cílovka EDB. Ve firmách máte hromadu takových aplikací, přepisovat je nikdo nebude, a Oracle Vám slevu nedá. EDB nemá ambice být levnějším 100% kompatibilní verzí aktuálního Oracle. Díky packages je Oracle neskutečný moloch, přičemž rozumně použitelných je cca 20% packages.

[okbob]

Jen bych upřesnil, že se nejedná o enterprise verzi Postgresu, ale o samostatně vyvíjený fork Postgresu EnterpriseDB.

[Pev]

Na upsert jsem se těšil už nějakou dobu .

[Radek Miček]

Systémy jako PostgreSQL jsou úplný opak tzv. unixové filozofie (tj. dělat jednu věc a dělat ji pořádně).

[okbob]

No Postgres je relační SQL ACID OLTP databáze. Co to dělá navíc???

[Radek Miček]

relační SQL ACID OLTP databáze

To už je trochu dost věcí v jednom, ne (vždyť to zahrnuje indexování, zpracování přirozeného jazyka (pro fulltextové vyhledávání), zpracování (někdy i distribuovaných) transakcí, umělá inteligence a statistika (při plánování dotazů), replikace, zpracování časových řad a další věci)?

Navíc jednotlivé věci moc dobře nefungují. Například relační: na rozdíl od relační algebry chybí uzavřenost – když na indexovanou tabulku aplikuji selekci, nedostanu indexovanou tabulku, ale pouze "tabulku". Tj. indexy jsou pryč a už nejde dělat rychlé dotazy. Výsledkem je ztráta modularity dotazů (dotaz nemůžete rozdělit na části a ty vykonat postupně). Díky modularitě by odpadla potřeba plánovače dotazů.

Dále například abstrakce: SQL je vlastně programovací jazyk, ale na rozdíl od moderních jazyků má velmi malé prostředky pro abstrakci. Psaní parametrizovaných dotazů (kde parametry jsou tabulky, názvy sloupců, jiné dotazy) připomíná lepení stringů. Co třeba šablony tabulek (jako v C++) – můžete vytvořit šablonu, kde parametry budou například seznamy s názvy sloupců, jiné tabulky, typy sloupců apod.?

Jiným příkladem jsou transakce: Kvůli efektivitě (?) vznikl jakýsi koncept úroveň izolace transakcí. Pokud si nenastavíte serializable (v některých db to ani nejde), tak je uvažování o korektnosti aplikací prakticky nemožné.

[JoHnY3]

Super, takže víme, že všechny používané RDBMS jsou docela špatné. Existuje něco lepšího s stejným rozložením na CAP theoremu?

[Radek Miček]

Existuje něco lepšího s stejným rozložením na CAP theoremu?

Záleží, jaké rozložení myslíte. Například s asynchronní replikací, která je většinou standardní, bude mít většina RDBMS jen P. Předpokládám tedy, že hledáte systém, jenž má CP?

[okbob]

Trnem v oku Vám není Postgres, ale SQL. Co se týče komplexnosti, umělé inteligence - podívejte se na překladač C, C++, Javy. SQL podporuje určitou modularitu - pohledy. Aplikací selekce indexy neztratíte - právě díky planneru, který čeká až na finální dotaz. Pokud by se dotaz vykonával postupně, jak navrhujete, tak by to nedopadlo moc dobře - z určitého pohledu je to cesta lokálních optim - moderní planner hledá globální optimum.

Faktem je, že koncept SQL (relační algebry) je pro některé programátory obtížně uchopitelný - jelikož je to samostatný koncept, který není ani procedurální a zrovna tak má daleko k OOP.

[Radek Miček]

Trnem v oku Vám není Postgres, ale SQL.

Však jsem psal systémy jako PostgreSQL.

Co se týče komplexnosti, umělé inteligence - podívejte se na překladač C, C++, Javy.

Špatně navržený systém bych neobhajoval existencí jiných špatně navržených systémů. Podívejte se třeba na Clojure a Datomic.

SQL podporuje určitou modularitu - pohledy.

Ale to je velmi omezené vůči tomu, co jsem navrhoval já.

Aplikací selekce indexy neztratíte - právě díky planneru, který čeká až na finální dotaz.

Když výsledek nebo část výsledku pošlu na klienta, tak indexy ztratím. Moje idea je, že klient si může procházet index a třeba podle toho požadovat další části výsledku. Nebo si klient celý výsledek včetně indexu uloží a pak ho může opakovaně filtrovat.

Aplikací selekce indexy neztratíte - právě díky planneru, který čeká až na finální dotaz.

Jsou případy, kdy tohle může být méně efektivní. Konkrétně třeba, když je výsledek jednoho dotazu Q opakovaně dotazován různými dotazy (musíte se spolehnout na db, že brzy pochopí, o co jde, a nacachuje výsledek Q).

Pokud by se dotaz vykonával postupně, jak navrhujete, tak by to nedopadlo moc dobře - z určitého pohledu je to cesta lokálních optim - moderní planner hledá globální optimum.

Já ale nezakazuji plánovač, já pouze dávám uživatelům více možností. U vás musí být celý dotaz znám dopředu a potřebujete plánovač, jinak to nebude efektivní, u mě ani jedno není třeba.

[okbob]

Můžete mít vymyslet jakýkoliv systém - jen ho naprogramovat a ověřit praxí.

[Radek Miček]

Možná se dočkáme i reálné implementace – viz How laziness brings good query performance without an insane black box optimizer.

[okbob]

Podle toho článku je to k produkčně použitelné implementaci ještě daleko (cca 5-10let). Autor má vymyšlené jen joinování a to ještě uvažuje jen indexscan. Adaptivní exekuce není nic nového - výzkum tu je od 90 let, ale zatím bez prakticky použitelných výsledků. Místo toho se v OLAPu prosazují sloupcové databáze, které jsou z hlediska architektury klasikou, ale dokáží lépe využít výpočetní sílu. Přiznám se, že nejsem optimistou ani ohledně designu přístupu k datům. Jiných jazyků tu bylo nespočet, a fakticky se neujal žádný, jelikož mu kromě tvůrce rozumělo pouze pár geeků.

Nemyslím si, že se nějaký ne SQL jazyk může prosadit. Na druhou stranu je docela pravděpodobné, že stávající architektura dožije během 20 let - je navržená a optimalizovaná pro hw a úlohy 70 - 80 let. Jakmile data budou pouze v RAM, dají se použít chytřejší datové struktury než heap a možná se i dočkáme adaptivního executoru.

[Radek Miček]

Adaptivní exekuce není nic nového - výzkum tu je od 90 let, ale zatím bez prakticky použitelných výsledků.

Nevím, zda se přesně jedná o adaptivní exekuci? Zde to nebude řídit plánovač, ale přímo uživatelský program.

Nemyslím si, že se nějaký ne SQL jazyk může prosadit.

Myslím, že JavaScript se může více prosadit, bohužel. V rámci rozšířených jazyků pak vzniknou EDSL, která se budou do SQL robustně (například dle pravidel z A Practical Theory of Language-Integrated Query) překládat – o to se snaží například knihovna Quill ve Scale (výhodou je lepší abstrakce, než poskytuje SQL a typová bezpečnost).

[okbob]

Nevím, zda se přesně jedná o adaptivní exekuci? Zde to nebude řídit plánovač, ale přímo uživatelský program.

Možná tam každý vidíme gro někde jinde. Já v tom, že tam autor slibuje databázi, databázové operace bez optimalizátoru. U JVM technologií není tak jednoznačně vymezená hranice mezi serverem a zákaznickým kódem. Zákaznickým kódem můžete injektovat/substitovat planner, executor - což ale neznamená, že tam executor nebo planner není. Je otázkou ale kam to spěje, jelikož třeba Hadoop systémy oklikou dospěli k existenci optimalizátorů, SQL, executorů.

[little.owl]

Podívejte se třeba na Clojure a Datomic.

+1

[okbob]

Já ale nezakazuji plánovač, já pouze dávám uživatelům více možností. U vás musí být celý dotaz znám dopředu a potřebujete plánovač, jinak to nebude efektivní, u mě ani jedno není třeba.

Může být. Je to jiná filozofie. Ono ale SQL iteraci po datech umožňuje také - díky kurzorům. Jde to sice proti mainstreamu, který cobolovský způsob zpracování zatracuje - ale někdy se to možná může hodit. Zkušenosti lidí z první a druhé dekády SQL, kdy se migrovalo z cobolu , jsou s tímto stylem negativní, na druhou stranu díky ORMkům se ISAM styl stále používá, jen tak není vidět - a občas jsou výsledkem aplikace, které jsou pomalé. Pokud by tu byla technologie, která zbaví svět ORM - "i za cenu ztráty SQL", tak jsem pro. Ale nemyslím si, že se tak stane. Je potřeba interoperabilita - a tam je SQL nezastupitelné.

[jkb]

Ono ale SQL iteraci po datech umožňuje také - díky kurzorům

u SQL databazi se ale daji kurzory pouzit (a nebo nejaka jina iterace po radkach) pouze na vysledkovou mnozinu. V situacich, kdy neni mozno nejak rozumne tu vysledkovou mnozinu omezit je ta iterace tezko pouzitelna.

Jo, existuje nekolik exotickych vyjimek (SQLite, ADABAS-D).

[okbob]

Jak omezit?

[jkb]

kdyz mam napr. v databazi tabulku zakazek a chci si zjistit neco o tech z roku 2010, tak se udela select na vsechny zakazky s datumem fakturace v roce 2010 a pak je mozno si za pomocu nejakeho 'fetche' jednu takovou zakazku za druhou podrobneji nahlednout . To je ten bezny a normalni postup, kdy vysledkova mnozina je omezena na ty radky, ktere jsou zajimave a pro tu ulohu take vsechny potrebne.

Ten hloupy postup by byl, nechat si vytvorit vysledkovou mnozinu pro vsechny zakazky a pak kurzorem prochazet toto obrovske mnozstvi a vzdy se ptat, jestli je ta doba fakturace ten zadany rok a jen odpovidajici radky zpracovavat. Takhle to samozrejme nikdo nedela, uz i proto, ze je 'vubec' mozne tu vysledkovou mnozinu vtipne omezit.

Podle mych zkusenosti existuje v oblasti informacnich systemu jak pro podniky tak pro statni spravu zhruba 5-10% uloh, kde to omezeni neni 'prakticky' mozne - jsou to ulohy pri rizeni vyroby a obecnejei vse, kde je ve hre nejaka simulace.

[okbob]

Takové omezení snad umí vyjma MySQL všechny SQL db, které znám.

[Ivan]

Dále například abstrakce: SQL je vlastně programovací jazyk, ale na rozdíl od moderních jazyků má velmi malé prostředky pro abstrakci. Psaní parametrizovaných dotazů (kde parametry jsou tabulky, názvy sloupců, jiné dotazy) připomíná lepení stringů.

SQL je taky deklarativni programovací jazyk. A zatímco imperativni a funkcionalni jazyky vznikají "každý" den. Do deklarativnich jazyků se nikdo moc nežene. Deklarativni jazyky jsou úzce specializovane(DSL). A pokud něco náhodou vznikne tak je to něco co jako SQL vypadá. Viz Jpa(jql). SQL pořád poplatné době kdy vzniklo (a cílům, které si jeho autoři kladli). Žádný jeho nástupce není na obzoru. Teď mě napadá jen XQUERY(XPATH), ten je ale svázány s xml.

[Radek Miček]

SQL je taky deklarativni programovací jazyk.

Tohle vám přijde jako deklarativní:

CREATE OR REPLACE FUNCTION fibonacci (n INTEGER) 
 RETURNS INTEGER AS $$ 
DECLARE
   counter INTEGER := 0 ; 
   i INTEGER := 0 ; 
   j INTEGER := 1 ;
BEGIN
 
 IF (n < 1) THEN
 RETURN 0 ;
 END IF; 
 
 LOOP 
 EXIT WHEN counter = n ; 
 counter := counter + 1 ; 
 SELECT j, i + j INTO i, j ;
 END LOOP ; 
 
 RETURN i ;
END ; 

Do deklarativnich jazyků se nikdo moc nežene.

Záleží, co deklarativním jazykem myslíte. Často jsou funkcionální i logické jazyky označovány jako deklarativní, společným rysem je, že nemají klasické proměnné, tedy deklarativní může znamenat, že nemá klasické proměnné. Takových jazyků vzniká celkem dost.

Wikipedia naopak nabízí celou řadu definic, některé jsou však tak vágní, že můžete tvrdit, že každý programovací jazyk je deklarativní.

[Radek Miček]

tedy deklarativní může znamenat, že nemá klasické proměnné.

s klasickým přiřazovacím příkazem

[okbob]

Tohle už není SQL. Je to PL/pgSQL - což je ADA rozšířená o vložené SQL. Tohle je hodně slabý argument.

[little.owl]

Tak on je IMHO i proceduralni, s tim ze tam podle noveho standardu Oracle proloboval Javu (ISO/IEC 9075:2011).

[Sid]

Ono asi uroven izolacie transakci ma aj urcity pragmaticky dovod. Nie vzdy potrebujete predsa uplnu ochranu. To mozete brblat ze realne cisla su dajme tomu prezentovane povacsine 64b. Rozumny dovod je ze pre 99.9% aplikaci to dostacuje.

[Radek Miček]

Nie vzdy potrebujete predsa uplnu ochranu.

Těžké je ale určit, kdy ji ještě nepotřebujeme a kdy už ji potřebujeme. Například při změně v programu se musíte dívat na celý kód – i části, které jste neměnil. Výsledkem je tedy kód, který je velmi těžké udržovat, neboť je vše provázané se vším a chyby navíc nastávají nedeterministicky (podle toho, jak se transakce vykonávají).

Rozumny dovod je ze pre 99.9% aplikaci to dostacuje.

Ano, když programy špatně fungují, tak to většinou nevadí.

[kralyk z abclinuxu]

No Postgres je relační SQL ACID OLTP databáze. Co to dělá navíc???

Postgre má i NoSQL fíčury.

[Heron]

Naopak, PG je ukázkou unixového přístupu. Neřeší nic co nemusí. Takže na rozdíl od jiných db systému neběží přímo nad blokovým zařízením, ale vyžaduje fs, který splňuje obecné unixové nároky (i když toto není nikde v posixu definováno). Spoléhá se na OS io cache (některé db systémy se snaží si řešit cache sami). Pro každého klienta vytváří vlastní proces a s masterem se komunikuje pomocí unix ipc (shared memory apod.). Některé jiné db systémy se snaží o vlastní řízení a prioritizaci procesů, tady se to nechává na os.

Takže je to přesně naopak. PG dělá jen to, co musí. Tedy spolehlivé ukládání dat a dotazy nad nimi.

[Valenta]

no,ja si myslim, ze predrecnik chtel jenom provokovat, ale kvuli pozitku z diskuze se na chvili ztotoznim s jeho myslenkou a pokusim se ji uchopit.

Jako zkousejici na nejake univerzite v predmetu 'databazove systemy' bych totiz takove otazky pokladal a vyuzil je k tomu zjistit, jak adept splnuje kriteria k zapsani alespon 3- do indexu. Ta otazka by znela, proc jsou systemy jako postgresql tak 'obsahle' a jak by se to dalo udelat, aby tomu tak nebylo.

A student nejake takove 'skutecne' univerzity (Stanford, MIT ..) by pak nacrtl to vnitrni schema tech 'beznych' databazi a ukazal by, ze to tesne propojeni b-tree, transakcni spravy, lock manageru, paging a jejich navaznost na sql-parser a optimizer odpovida soucasnemu mainstreamu v oblasti databazi a je na to nahlizeno jako na dnes jedinou moznou a kvasi-optimalni metodu, jak zejmena 'velke' (mnozstvi dat, dotazu) systemy vubec provozovat.

A protoze by se jednalo o tu 'skutecnou' univerzitu, tak pak by ten student rozebral ty jednotlive hlavni komponenty takovych obsahlych systemu a prezentoval by zkousejicimu vysledky sveho samostudia napr. optimalizaci b-tree spravy ve spojeni s in-memory-transactional systemem. To vse s cilem ukazat, zda je to tesne propojeni uvedenych komponent skutecne nutne a nebo jestli existuje nejaka realna moznost ty jednotlive komponenty oddelit.

Ten student by pak samozrejme kriticky zhodnotil stavajici snahy v tomto smeru (mysql - storage engines)) a ukazal jake nevyhody a vyhody ma takove funkcni rozdeleni.

[Field]

Jo, takoví studenti by se mi taky líbili. Jenom jestli vy si ten Stanford nebo MIT moc nemalujete

[trekker.dk]

Doporučuji návrat do reality, ve které má EU stanovenou kvótu na podíl vysokoškolsky vzdělaných lidí.

[Acci]

Zdroj?

[EtDirloth]

trochu menej idealizmu:

• PG pouziva nielen OS cache ale aj shared_buffers - takze si riesi aj vlastnu cache
• prioritu procesov PG riesi napr. pre autovacuum vo forme naptime a max_workers
• PG je multiplatformny a je treba riesit specifika podporovanych platforiem - to k unix IPC a obecnym narokom na FS