abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
včera 22:44 | Komunita

Joinup informuje, že Mnichov používá open source groupware Kolab. V srpnu byl dokončen dvouletý přechod na toto řešení. V provozu je asi 60 000 poštovních schránek. Nejenom Kolabu se věnoval Georg Greve ve své přednášce Open Source: the future for the European institutions (SlideShare) na konferenci DIGITEC 2016, jež proběhla v úterý 29. listopadu v Bruselu. Videozáznam přednášek z hlavního sálu je ke zhlédnutí na Livestreamu.

Ladislav Hagara | Komentářů: 1
včera 15:30 | Zajímavý projekt

Společnost Jolla oznámila v příspěvku Case study: Sailfish Watch na svém blogu, že naportovala Sailfish OS na chytré hodinky. Využila a inspirovala se otevřeným operačním systémem pro chytré hodinky AsteroidOS. Použita je knihovna libhybris. Ukázka ovládání hodinek na YouTube.

Ladislav Hagara | Komentářů: 5
včera 14:15 | Nová verze

Byla vydána verze 7.1.0 skriptovacího jazyka PHP používaného zejména k vývoji dynamických webových stránek. Jedná se o první stabilní verzi nejnovější větvě 7.1. Přehled novinek v dokumentaci. Podrobnosti v ChangeLogu. K dispozici je také příručka pro přechod z PHP 7.0.x na PHP 7.1.x.

Ladislav Hagara | Komentářů: 0
včera 12:55 | Nová verze

Google Chrome 55 byl prohlášen za stabilní. Nejnovější stabilní verze 55.0.2883.75 tohoto webového prohlížeče přináší řadu oprav a vylepšení (YouTube). Opraveno bylo také 36 bezpečnostních chyb. Mariusz Mlynski si například vydělal 22 500 dolarů za 3 nahlášené chyby (Universal XSS in Blink).

Ladislav Hagara | Komentářů: 4
včera 11:55 | Pozvánky

Máte rádi svobodný software a hardware nebo se o nich chcete něco dozvědět? Přijďte na 135. sraz spolku OpenAlt, který se bude konat ve čtvrtek 8. prosince od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Sraz bude tentokrát tématický. Bude retro! K vidění budou přístroje jako Psion 5mx nebo Palm Z22. Ze svobodného hardwaru pak Openmoko nebo čtečka WikiReader. Přijďte se i vy pochlubit svými legendami, nebo alespoň na pivo. Moderní hardware má vstup samozřejmě také povolen.

xkucf03 | Komentářů: 0
včera 00:10 | Nová verze

Byla vydána verze 3.2 svobodného systému pro detekci a prevenci průniků a monitorování bezpečnosti počítačových sítí Suricata. Z novinek lze zmínit například podporu protokolů DNP3 a CIP/ENIP, vylepšenou podporu TLS a samozřejmě také aktualizovanou dokumentaci.

Ladislav Hagara | Komentářů: 0
1.12. 21:00 | Nová verze

Byla vydána beta verze Linux Mintu 18.1 s kódovým jménem Serena. Na blogu Linux Mintu jsou hned dvě oznámení. První o vydání Linux Mintu s prostředím MATE a druhé o vydání Linux Mintu s prostředím Cinnamon. Stejným způsobem jsou rozděleny také poznámky k vydání (MATE, Cinnamon) a přehled novinek s náhledy (MATE, Cinnamon). Linux Mint 18.1 bude podporován až do roku 2021.

Ladislav Hagara | Komentářů: 0
1.12. 16:42 | Nová verze

Byl vydán Devuan Jessie 1.0 Beta 2. Jedná se o druhou beta verzi forku Debianu bez systemd představeného v listopadu 2014 (zprávička). První beta verze byla vydána v dubnu letošního roku (zprávička). Jedna z posledních přednášek věnovaných Devuanu proběhla v listopadu na konferenci FSCONS 2016 (YouTube, pdf).

Ladislav Hagara | Komentářů: 0
1.12. 15:16 | Komunita

Na GOG.com začal zimní výprodej. Řada zlevněných her běží oficiálně také na Linuxu. Hru Neverwinter Nights Diamond lze dva dny získat zdarma. Hra dle stránek GOG.com na Linuxu neběží. Pomocí návodu ji lze ale rozběhnout také na Linuxu [Gaming On Linux].

Ladislav Hagara | Komentářů: 1
1.12. 13:14 | Bezpečnostní upozornění

Byla vydána verze 2.7.1 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Řešeno je několik bezpečnostních problémů. Aktualizován byl především Tor Browser na verzi 6.0.7. Tor Browser je postaven na Firefoxu ESR (Extended Support Release) a právě ve Firefoxu byla nalezena a opravena vážná bezpečnostní chyba MFSA 2016-92 (CVE-2016-9079, Firefox SVG Animation

… více »
Ladislav Hagara | Komentářů: 0
Kolik máte dat ve svém domovském adresáři na svém primárním osobním počítači?
 (32%)
 (24%)
 (29%)
 (7%)
 (5%)
 (3%)
Celkem 759 hlasů
 Komentářů: 50, poslední 29.11. 15:50
Rozcestník
Reklama

Dotaz: Jak v postgresql "zamknout pohled na resultset"

10.5.2015 07:26 pocestny05
Jak v postgresql "zamknout pohled na resultset"
Přečteno: 721×
Ahoj. V php načítám data z tabulky v postgresu stylem:
select id, s1, s2 from ...
Výsledek dotazu předám do třídy php iterátoru, kterou jsem si napsal a pak postupně čtu podle potřeby řádek po řádku. Je to rychlé, šetří to paměť a mám jistotu, že mám konzistentní pohled na data. Jenže já bych si chtěl vybudovat cache a nenačítat znovu data, které jsem si už načetl. Tzn. chtěl bych jenom číst id řádků a podle toho bych se rozhodl zda to číst dál:
select id from ...
Jenže ve chvíli, kdy se rozhodnu provést "select s1, s2 from ... where id = ...", tak už ten daný řádek nemusí v tabulce existovat. Transakce na to použít nemohu, čtení všech výsledků dotazu není ihned po jeho provedení. Explicitní zamykání řádků zase znemožní, aby někdo jiný dané řádky smazal.

Potřebuji vlastně označit řádky a vytvořit tak konstantní pohled, ale umožnit někomu jinému, aby ty řádky reálně mohl mazat (ale já měl pořád ten svůj pohled). Jak to udělat?

Odpovědi

10.5.2015 08:39 Filip Jirsák
Rozbalit Rozbalit vše Re: Jak v postgresql "zamknout pohled na resultset"
Máte nějaký důvod, proč to takhle komplikovat a zpomalovat? Nerozumím větě "transakce na to použít nemohu", protože přesně k zobrazení konzistentního stavu dat transakce slouží.
10.5.2015 15:47 pocestny05
Rozbalit Rozbalit vše Re: Jak v postgresql "zamknout pohled na resultset"
Mám objektový návrh aplikace. Pro zjednodušení: třída DatabazovaVrstva vrací objekty Radek, kde Radek odpovídá jednomu řádku tabulky. S objekty Radek poté někde v aplikaci pracuji. Pokud by těch objektů Radek bylo hodně a DatabazovaVrstva všechny naráz načítala do paměti, pak by php skript mohl zabrat relativně dost paměti. Proto nevrací pole objektů Radek, ale RadekIterator, který se chová jako pole a například po každé foreach iteraci provede jeden DB fetch.

Většinu objektu to vrací během spuštění php skriptu 1x, ale s některými se pracuje v různých částech aplikace několikrát. Proto chci vytvořit cache, která si bude pamatovat N nejpoužívanějších (nejčtenějších) objektů.
okbob avatar 10.5.2015 21:11 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
Rozbalit Rozbalit vše Re: Jak v postgresql "zamknout pohled na resultset"
To je špatně - když pracujete s relační databází, a provádíte hromadné operace, tak nejlepší, co můžete udělat, je zapomenout na OOP (a začít myslet v relacích a procedurálně). Navíc, čím víc udělá práce databáze, a čím méně klient, tím to bude rychlejší. PostgreSQL je databáze, která dobře zvládá komplexní SQL a pro složitější věci je možné jednoduše používat uložené procedury. Je tedy hloupé ji degradovat na storage nějaké cache.
10.5.2015 23:28 pocestny05
Rozbalit Rozbalit vše Re: Jak v postgresql "zamknout pohled na resultset"

To si nerozumíme. Databáze neslouží jako cache, spoustu věcí dělá za aplikaci právě postgresql. Jde mi o jinou věc: když převádím "řádek" či spíše relaci na objekt, tak provedu select z databáze. Když budu chtít s tím samým objektem pracovat znovu, tak bych chtěl použít cache, která by vlastně byla pole načtených objektů. Cílem je, abych místo 100 dotazů na ta samá data provedl jen jeden dotaz a vrácená data si cachoval na úrovni php.

Celkově aplikace hodně moc pracuje s databází a mezi aplikací a db se přenáší dost dat. Proto je DB a aplikace na stejném systému. Je otázka, zda cache vůbec něco řeší (i když asi jo, třeba PropelORM ji používá). Minimálně si ušetřím čas znovusestavováním objektů.

Dejme tomu, že v každém fetch vrátí databáze 20 sloupců, kdy "velikost dat řádku" je od 5 do 5000 KB. Co z následujícího je rychlejší? (tabulka je ve skutečnosti join několika tabulek)
  • Vybrat všechno (SELECT s1 ... s20 FROM tabulka WHERE xy LIMIT 500) a pak postupně řádek po řádku s daty pracovat (převádět na objekty případně nedělat nic a použít cache)
  • Vybrat primární klíče (SELECT s1 FROM tabulka WHERE xy LIMIT 500) a pak postupně řádek po řádku s daty pracovat (převádět na objekty). Pokud objekt není nacachován, pak SELECT s2 ... s20 FROM tabulka WHERE s1=PKHODNOTA
Jde o to, jak rychlé je postgresql ve vracení většího množství dat a zda se vůbec vyplatí drobit to na selecty primárních klíčů a podle potřeby načítat ostatní sloupce. Rovněž je otázka, zda vůbec cachovat kvůli rychlosti komunikace php-postgresql - jak rychlé je N krát opakovat stejný dotaz? Při dotazování používám prepared statements, takže by to mělo být rychlejší a bezpečnější.

Děkuji za jakékoliv postřehy k mým mnohým otázkám. Nedokážu to moc reálně posoudit, protože jak na straně php, tak postgresql se dá celkem čarovat s nastavením různých cachí a přidělené paměti.
okbob avatar 11.5.2015 06:13 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
Rozbalit Rozbalit vše Re: Jak v postgresql "zamknout pohled na resultset"
Nakešovaná id Vám ale téměř vůbec nepomohou - pokud chcete použít cache, tak už byste vůbec neměl přistupovat do databáze.

Základním pravidlem je nedělat hromadné operace přes objekty - to je neskutečná brzda. Data posílám na klienta pouze tehdy, když je chci zobrazit nebo někam odeslat.
okbob avatar 11.5.2015 06:15 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
Rozbalit Rozbalit vše Re: Jak v postgresql "zamknout pohled na resultset"
Cache id se používaly před 15 roky ve VB - výsledkem byly docela rychlé aplikace, které ale byly docela brutálně komplikované - na to co uměly.
11.5.2015 08:08 Filip Jirsák
Rozbalit Rozbalit vše Re: Jak v postgresql "zamknout pohled na resultset"
Co z následujícího je rychlejší?
Ty vaše pokusy s cache jsou evidentně předčasná optimalizace, když se na tohle ptáte. Normálně se preferuje první varianta, ke druhé se přistoupí až tehdy, pokud je jasně změřené, že v daném konkrétním případě je ta druhá varianta efektivnější.

Jinak to ale z vašeho popisu vypadá, že by té vaší aplikaci mnohem víc, než cache, prospělo, kdybyste databázi používal správně. Podle vašeho dotazu to totiž vypadá, že máte na jedné webové stránce sto různých výpisů, které vypisují stejná data, každý řádek může mít až 5 MB. Když bude jeden dotaz vracet jen 10 záznamů, vychází to na 5 GB na jednu webovou stránku. Opravdu? To vám nějaký webový prohlížeč zobrazí? A ještě navíc tam chcete mít různé transakce, proč? I kdybyste něco takového doopravdy potřeboval dělat, o čemž pochybuju, pořád pravděpodobně bude mnohem efektivnější z těch „100 dotazů na ta samá data“ udělat dotaz jeden.
11.5.2015 21:55 pocestny05
Rozbalit Rozbalit vše Re: Jak v postgresql "zamknout pohled na resultset"
Klientovi nikdy neposílám velké množství dat. Kdybych měl stručně shrnout co ta aplikace dělá tak:
  1. Uživatel nahraje textový soubor
  2. Aplikace soubor postupně parsuje a na základě jeho obsahu načítá nějaká transformační pravidla
  3. Aplikace transformuje soubor a uloží ho lokálně
  4. Aplikace odešle uživateli výsledek operace
Transformační pravidlo T je vlastně objekt. Načítá se z databáze. Každé pravidlo může mít libovolný počet vnořených pravidel. Jednoduše řečeno pravidlo obsahuje pokyny, případně nějaká data, která lze použít při transformaci vstupního souboru. Díky vnořování může být strom pravidel třeba:
T1
├── T8
└── T9
T2
└── T8
T3
└── T8
T4
Když načítám T1, pak aplikace musí načíst i T8 a T9. Když načítám T2, musí načíst T8 atp. Zde je výhodné držet si T8 v cache. Nemůžu si dopředu rozparsovat celý soubor a pak s tím pracovat. Potřebuji šetřit paměť a navíc aplikace nemá jen webové rozhraní a nemusí dopředu znát obsah souboru. Cache už nějak implementovanou mám, zajímalo by mě, zda by to šlo lépe. Takto to funguje:
  1. Parser potřebuje T1, pak ho načtu z databáze
  2. Parser potřebuje T1, pak ho načtu z databáze
  3. Parser potřebuje T1, jenže už ho potřeboval 2x, proto si ho načtu z DB a nacachuji
  4. Parser potřebuje T1, jenže už ho potřeboval 2x, provedu dotaz do DB a použiji nacachovaný
  5. ...
  6. Parser potřebuje Tn, pak ho načtu z databáze
  7. Parser potřebuje Tn, pak ho načtu z databáze
  8. Parser potřebuje Tn, jenže už ho potřeboval 2x, proto si ho načtu z DB a nacachuji. Pokud už je načtených objektů moc, vyhodím ten nejméně používaný.
  9. ...
Neřeším úpravy hodnot databáze další osobou. Data si cachuji jen N sekund. Strom načítám v transakci. Co hlavně řeším je to, že i u bodu 4 provádím dotaz do databáze typu "SELECT t_name, s1, s2, ... FROM t WHERE x = y AND i LIKE ..." a pokud t_name znám, pak si ušetřím konstrukci stromu T1->T8,T9. V tom případě mi ale databáze vrací i nepotřebné sloupce s1, s2, ..., které teď nepotřebuji (strom už mám). Tak je otázkou, zda nenačítat jen t_name a podle potřeby další dotaz na zbylé sloupce a jestli potenciálně vrácená nepotřebná data mají jen zanedbatelný vliv na výkon (výhodu mají určitě v možnosti transakčního zpracování).
11.5.2015 21:59 pocestny05
Rozbalit Rozbalit vše Re: Jak v postgresql "zamknout pohled na resultset"
Jo a parsování, načítání pravidel a transformace probíhá postupně, ne parsování, pak načtení pravidel a pak transformace.
11.5.2015 23:00 Ivan
Rozbalit Rozbalit vše Re: Jak v postgresql "zamknout pohled na resultset"
Ony ty databaze zase nejsou tak blby. Ony taky umi cachovat. Opravdu to cachovani tolik pomaha? Na dotaz pres primarni klic by mela DB odpovedet v radech milisekund. Spis bych se zameril na to jak snizit pocet round-tripu do te databaze.

Co je lepsi cache v PHP anebo cache Postgresu? Jak dlouho trva ta transformace v porovnani s nactenim dat z DB?
12.5.2015 01:10 pocestny05
Rozbalit Rozbalit vše Re: Jak v postgresql "zamknout pohled na resultset"
Nedokážu určit, co je rychlejší. V PHP záleží na nastavení přidělené paměti, na rozšíření PHP, OS apod., u postgresql na nastavení shared buffers apod. Určitě vím, že současná cache, kdy vlastně eliminuji pouze vytváření objektů (a taky dotazování, pokud provádím Transformace::findById, tzn. hledám jen jeden záznam podle ID a nemusím se dotazovat postgresql - 1 nevýhoda: findById může najít to, co findAllNěco ne) dost urychlila aplikaci.
12.5.2015 07:21 Filip Jirsák
Rozbalit Rozbalit vše Re: Jak v postgresql "zamknout pohled na resultset"
Ty nepotřebné sloupce by měly vliv na výkon jedině tehdy, pokud by kvůli nim databáze musela přečíst nový blok z disku - tj. pokud by bez nich dokázala odpovědět jen z indexu a nemusela stejně načítat příslušný blok třeba kvůli sousednímu řádku. Když už byste chtěl implementovat to vaše řešení, pořád nevidím jediný důvod proč nepoužít transakce, které jsou právě na tohle určené.

Jinak mi pořád připadá, že jste si vybral velmi nevhodné nástroje, a pak řešíte nějakou velmi pochybnou optimalizaci. Potřebujete šetřit paměť, a přitom chcete kešovat velký objem dat. Optimalizujete zpracování transformačních pravidel, místo abyste je měl uložená ve tvaru, v jakém je můžete rovnou použít.
12.5.2015 18:34 pocestny05
Rozbalit Rozbalit vše Re: Jak v postgresql "zamknout pohled na resultset"
Jinak mi pořád připadá, že jste si vybral velmi nevhodné nástroje, a pak řešíte nějakou velmi pochybnou optimalizaci. Potřebujete šetřit paměť, a přitom chcete kešovat velký objem dat. Optimalizujete zpracování transformačních pravidel, místo abyste je měl uložená ve tvaru, v jakém je můžete rovnou použít.
Je to o kompromisu. Data (i pravidla) se ukládají v takovém tvaru, aby se dala zajistit konzistence na úrovni DB a aby DB mohla provádět potřebné operace.
12.5.2015 22:38 Delaunay | skóre: 17 | blog:
Rozbalit Rozbalit vše Re: Jak v postgresql "zamknout pohled na resultset"
Pokud neřešíte případné úpravy hodnot v databázi další osobou, tak bych postupoval následujícím způsobem.

Načetl bych si jediným rekurzivním SQL dotazem celý strom pravidel.

Následně bych jako cache pro objekty vytvořil haldu s omezeným počtem prvků řazených primárně podle počtu přístupů k danému objektu z aplikace a sekundárně podle času vložení do haldy.

Pokud by během plnění cache nastal případ, že by již nebyla data v databázi k dispozici, zahodil bych všechny dosavadní výsledky transformace, poté z databáze znovunačetl strom pravidel, vyresetoval počítadla přístupů u všech již nacachovaných objektů na haldě a začal s transformací od začátku.
11.5.2015 22:16 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Jak v postgresql "zamknout pohled na resultset"
Transakce na to použít nemohu, čtení všech výsledků dotazu není ihned po jeho provedení.

Proč byste nemohl? Pokud je mi známo, PostgreSQL používá MGA (MVCC), takže read-only snapshot transakce by neměla nijak zvlášť překážet. Aspoň u Firebirdu to tak je.

15.5.2015 03:56 pedro
Rozbalit Rozbalit vše Re: Jak v postgresql "zamknout pohled na resultset"
create temp table mojetabule as select id, s1, s2 from ...

a ta temp tabulka se už nezmění a zcela jistě nebude nikomu překážet, jedině bude zabírat místo.
21.5.2015 08:12 aubi
Rozbalit Rozbalit vše Re: Jak v postgresql "zamknout pohled na resultset"
Bude zabirat misto a cas na vytvoreni. Taky musite resit nazev tabulky, protoze uvedeny zpusob ma problem s dvojity pristupem na tuhle stranku.

Proc nestaci jedna transakce? Hledejte transaction isolation - dostanete presne totez chovani bez pomocne tabulky.

aubi
21.5.2015 08:31 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Jak v postgresql "zamknout pohled na resultset"
To jsem navrhoval už minulé pondělí, ale holt to asi vyžaduje překonat nějaký myšlenkový blok a dočasná tabulka připadá lidem z nějakého důvodu jednodušší.
25.5.2015 18:07 OldFrog {Ondra Nemecek} | skóre: 25 | blog: Žabákův notes | Praha
Rozbalit Rozbalit vše Re: Jak v postgresql "zamknout pohled na resultset"
Tím blokem je nutnost pochopit koncept transakcí včetně isolation levels. Což přiznejme si, je v reálu o dost těžší než vzít data, která tudle vidím a strčit je do nějaký dočasný tabulky.

BTW ono je toho víc, co vypadá jednoduše, ale dá to zabrat. Před rokem mě dostal například upsert v Postgres (v poslední Postgres to je snad implementováno už nativně).
-- OldFrog
xkucf03 avatar 30.5.2015 00:07 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Re: Jak v postgresql "zamknout pohled na resultset"

Nechci říct, že mezipaměť je zbytečná1, ale pro začátek bych se snažil využít možností relační databáze. Přiděl jí víc paměti a uvidíš, jak se ti odvděčí. Ono je totiž celkem jedno, jestli si data v RAM drží tenhle proces nebo tamten. A databáze (nebo třeba OS, souborové systémy atd.) bývají typicky lépe napsané než běžné zakázkové aplikace. Mezipaměť v aplikaci bych použil spíš pro data po nějakém náročnějším zpracování (třeba vygenerované PDF, XHTML stránka, obrázek, archiv atd.), ne je tam udržovat v surové formě, v jaké jsou i v databázi.

[1] zvlášť když je to po síti – na jiném stroji – nebo těch aplikačních serverů máš víc a databázi jen jednu

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
30.5.2015 12:30 Delaunay | skóre: 17 | blog:
Rozbalit Rozbalit vše Re: Jak v postgresql "zamknout pohled na resultset"
Za omezujících podmínek, např. schopnostech programátora, nevhodně zvolených technologiích, termínu dokončení... je opravdu často výhodnější nehledat hned na začátku technicky optimální řešení, ale vydat se zprvu cestou využití brutální síly.

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.