Všem čtenářkám a čtenářům AbcLinuxu krásné Vánoce.
Byla vydána nová verze 7.0 linuxové distribuce Parrot OS (Wikipedie). S kódovým názvem Echo. Jedná se o linuxovou distribuci založenou na Debianu a zaměřenou na penetrační testování, digitální forenzní analýzu, reverzní inženýrství, hacking, anonymitu nebo kryptografii. Přehled novinek v příspěvku na blogu.
Vývojáři postmarketOS vydali verzi 25.12 tohoto před osmi lety představeného operačního systému pro chytré telefony vycházejícího z optimalizovaného a nakonfigurovaného Alpine Linuxu s vlastními balíčky. Přehled novinek v příspěvku na blogu. Na výběr jsou 4 uživatelská rozhraní: GNOME Shell on Mobile, KDE Plasma Mobile, Phosh a Sxmo.
Byla vydána nová verze 0.41.0 multimediálního přehrávače mpv (Wikipedie) vycházejícího z přehrávačů MPlayer a mplayer2. Přehled novinek, změn a oprav na GitHubu. Požadován je FFmpeg 6.1 nebo novější a také libplacebo 6.338.2 nebo novější.
Byla vydána nová verze 5.5 (novinky) skriptovacího jazyka Lua (Wikipedie). Po pěti a půl letech od vydání verze 5.4.
Byla vydána nová verze 5.4.0 programu na úpravu digitálních fotografií darktable (Wikipedie). Z novinek lze vypíchnout vylepšenou podporu Waylandu. Nejnovější darktable by měl na Waylandu fungovat stejně dobře jako na X11.
Byla vydána beta verze Linux Mintu 22.3 s kódovým jménem Zena. Podrobnosti v přehledu novinek a poznámkách k vydání. Vypíchnout lze, že nástroj Systémová hlášení (System Reports) získal mnoho nových funkcí a byl přejmenován na Informace o systému (System Information). Linux Mint 22.3 bude podporován do roku 2029.
GNU Project Debugger aneb GDB byl vydán ve verzi 17.1. Podrobný přehled novinek v souboru NEWS.
Josef Průša oznámil zveřejnění kompletních CAD souborů rámů tiskáren Prusa CORE One a CORE One L. Nejsou vydány pod obecnou veřejnou licenci GNU ani Creative Commons ale pod novou licencí OCL neboli Open Community License. Ta nepovoluje prodávat kompletní tiskárny či remixy založené na těchto zdrojích.
Nový CEO Mozilla Corporation Anthony Enzor-DeMeo tento týden prohlásil, že by se Firefox měl vyvinout v moderní AI prohlížeč. Po bouřlivých diskusích na redditu ujistil, že v nastavení Firefoxu bude existovat volba pro zakázání všech AI funkcí.
Zdravim,
nie som prilis expert na veci okolo databaz, tak by som sa chcel spytat -- mam (server) aplikaciu, ktora komunikuje s databazou. V tejto DB musi byt o.i. ulozeny aj binarny obsah, zhruba 2-3 MB na kazdeho pouzivatela. Kedze ide o data, ktore si klient k sebe stiahne, nie je problem ich mat ulozene niekde externe a v DB mat len cestu, kde ich potom server aplikacia najde.
Chcel by som sa spytat, ma nejaky zmysel uvazovat nad BLOBom? Je mi jasne, ze cesta vnasa trochu redunancie (zmenim cestu, musim zmenit aj umiestnenie na disku), ale zase predpokladam, ze ziskanie informacie od DB o ceste a nasledne nahranie uz pomocou server aplikacie je neporovnatelne rychlejsie a menej stresujucejsie pre DB... v akych pripadoch by ste ten BLOB doporucili pouzit?
Ja som na to išiel tak, že som si povedal: chcem aby môj dump databázy mal 70 mega, alebo 70 giga? Zvíťazilo 70 mega. :) Navyše keď to je v súboroch, tak sa nad tým dajú jednoducho spúšťať ďalšie príkazy - clamscan, file, convert, a tak. Na druhej
strane vynútenie integrity dát je ta tam...
70 GB dump je neskladný. Neviem to rýchlo preniesť na devel server, lebo ten má "len" 2 MBit linku a trvá to 3 dni. Plus spravím na serveri 4 denné snapshoty a voľné miesto sa tým minulo.
Keď to je v súboroch ktoré sa príliš nemenia, tak viem preniesť zmeny cez rsync za pár minút, a pre denné zálohy mám miesto na celý rok.
Okrem toho viem fileserver oddeliť od DB serveru, až nastane ten čas, že to jeden server všetko neutiahne.
Tech 70 giga je presne ten duvod proc bys' to do DB dat mel. Pokud zalohuje data aplikace, tak bys mel zazalohovat opravdu vsechna data. Zalohy delas proto, abys' je moh pouzit pro obnovu. Kcemu ti bude dump DB s cestama k neexistujicim souborum?
Robiť zálohu 70 GB každý deň? Netúžim 2x denne bežať do serverovne (niekoľko km vzdialenej) a meniť pásku. Neviem dosť dobre urobiť rozdielový SQL dump - diff medzi dvoma súbormi väčšími už len ako 500 MB skončil zatiaľ vždy katastrofou. Preto zálohujem celý dump (70 M), a súbory potom už len inkrementálne. Pri obnove najprv obnovím DB a následne budem riešiť súbory. Radšej než oboje naraz - keď nie je DB tak sa nedá ani len prihlásiť, zatiaľčo keď nie sú súbory, tak sa dá so systémom pracovať celkom v pohode, len nie sú k dispozícii niektoré funkcie.
Aha, takze ty vlastne jenom obchazis to, ze tvoje DB neumi inkrementalni zalohy. Nebylo by jednodussi zamerit se rovnou na ty incrementalni zalohy?
Je dosť možné, že to tá DB podporuje (jedná sa o PostgreSQL), len som bol lenivý to naštudovať... V princípe môžeš mať pravdu, že mám len zlé postupy...
Prišlo mi to takto jednoduchšie...
Promysli si pri svem rozhodovani taky scenar, kdy budou data distribuovana pres vice serveru (pro failover).
Práce s blobem máš jednodušší. Nemusíš generovat název souboru. Pokud mažeš fotky z databáze, nemůsíš se zajímat o mazání souboru. Pokud bys mazal z databáze záznam fotografie přes nějaké vazby (ON DELETE CASCADE, ...), tak by se zároveň mazání souborů dělalo dost blbě. Můžeš na ně aplikovat databázové práva...
V súvislosti s predchádzajúcimi komentármi by stál za zváženie kompromis: ukladania do BLOB-u, ale v oddelenej databáze. Táto sa v prípade môže dedikovať na iné železo a integritu zabezpečovať aplikačne. Zálohovať sa tým pádom môže oddelene. Záleží na tom ako DB podporuje aliasy...
Tiskni
Sdílej: