OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Po roce vývoje od vydání verze 1.24.0 byla vydána nová stabilní verze 1.26.0 webového serveru a reverzní proxy nginx (Wikipedie). Nová verze přináší řadu novinek. Podrobný přehled v souboru CHANGES-1.26.
Byla vydána nová verze 6.2 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.14.
Byla vydána nová verze 30.0.0 frameworku pro vývoj multiplatformních desktopových aplikací pomocí JavaScriptu, HTML a CSS Electron (Wikipedie, GitHub). Chromium bylo aktualizováno na verzi 124.0.6367.49, V8 na verzi 12.4 a Node.js na verzi 20.11.1. Electron byl původně vyvíjen pro editor Atom pod názvem Atom Shell. Dnes je na Electronu postavena celá řada dalších aplikací.
Byla vydána nová verze 9.0.0 otevřeného emulátoru procesorů a virtualizačního nástroje QEMU (Wikipedie). Přispělo 220 vývojářů. Provedeno bylo více než 2 700 commitů. Přehled úprav a nových vlastností v seznamu změn.
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.
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)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.
T1 ├── T8 └── T9 T2 └── T8 T3 └── T8 T4Když 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:
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.
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.
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.
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
Tiskni Sdílej: