Viszont mielott belefeccolnek nemi emberorat a dologba, tudni kene, hogy eleg stabil es robosztus lesz-e? Arra gondolok, hogy egy esetleges filerendszer gubanc (pl. serult/orhpan/... inode-ok, stb.) mennyire vagna haza ezt a koncepciot, hogy ez a nagy binaris file hasznalhatatlan lesz? Ehhez kapcsolodik, mi van, ha megserul az elejen levo tartalomjegyzek? Erre megoldas lehet, ha kulon file-ba teszem a tartalomjegyzeket, akar 2-3 peldanyban (=2-3 file-ban) is.
A masik aggodalmam az, hogy nem lesz eleg gyors a kontener file-bol valo adatkiszedes. Jelenleg egy bizonyos adat eloallitasahoz be kell olvasni kb. 1..5 db file-t, majd ezekbol osszerakni az adatot (deduplikalas rulez), azaz be kell olvasni pl. az aa/bb/cc/1234, aa/07/87/8338 es a6/45/2f/3798389 file-okat. A kontener file + toc file eseten eloszor mindig be kell olvasni a toc file-t, abban lookup-ot vegezni, ami alapjan lehet a kontener file-bol kiolvasni a fenti pelda 3 db file-jaban levo adatot. De az is lehet, hogy 5 reszadat van, 2 az egyik kontener file-ban, 3 meg egy masikban.
Meg annyi info, hogy a kontener file-okat opcionalisan a letrehozas utan mar csak olvasni kell, nem modosulnak tobbe.
Szoval hagyjam a csillio file-t a hash-elt konyvtarszerkezetben, es torodjek bele, hogy sokaig tart atmasolni egy masik gepre; vagy erdemes a fenti kiserletbe (vagy valami egeszen mas iranyba menni) belevagni? A fo szempont az, hogy adat ne vesszen el. Van arra is lehetoseg, hogy egy bizonyos filerendszer hasznalatahoz kossuk a dolgot, ha az tamogatott mondjuk egy friss ubuntu, debian, ill. centos-en.
- sj blogja
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Ha BtrFS-t használnál, ott van FS szintű subvolume sync ami diff-et is tud (send / receive):
- A hozzászóláshoz be kell jelentkezni
jol hangzik, de akkor kilottem a centos/redhat usereket. Legalabbis a redhat kivezet(n)i( keszul) a btrfs tamogatast...
--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...
- A hozzászóláshoz be kell jelentkezni
Legalabbis a redhat kivezet(n)i( keszul) a btrfs tamogatast...
Nem gondoltam volna, de igazad van, tényleg deprecated-re rakta és a 7-es verzió után kivezetik. Ez elég furcsa hozzáállás egy a kernelben levő fs-sel szemben!
Mondjuk az is kérdés, hogy mit jelent az, hogy kiveszik. Kiveszik a kernelből is vagy csak a userspace programokat veszik ki, vagy ...?
- A hozzászóláshoz be kell jelentkezni
Szerintem benne marad, csak támogatást nem adnak rá.
- A hozzászóláshoz be kell jelentkezni
Miért nem tar?
- A hozzászóláshoz be kell jelentkezni
+netpipe segítségével a tar streamet TCP-n átlőni.
- A hozzászóláshoz be kell jelentkezni
igen, lenyegeben valami hasonlot koncepciot vazoltam.
--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...
- A hozzászóláshoz be kell jelentkezni
Ha emailek és mentéshez kell, akkor részemről nem szórakoznék mással, csakis file szintű másolással. Egyszerű és megbízható.
Egyszer bedobott valaki egy olyan ötletet ide, hogy a random fej ugrálásokat elkerülendő, inode alapján rendezve kell felolvasni a fájlokat. Emlékeim szerint nagy sebesség növekedés keletkezett.
ls -i
- A hozzászóláshoz be kell jelentkezni
a mongodb gridfs rendszerét tudom ajánlani, nálam bevált hasonló problémára, előnyök:
- 2 binary fájl: meta adat + chunks (fájl adat)
- alapből van konzisztencia check stb
- wiredtiger-ben állítható zlib tömörítés, szóval kb. azonos méretű lesz mintha az egészet zip-ben tárolnád
- auth: minden programnyelvből szabványosan tudsz hozzáférést állítani
- meta adatok: mellé tudsz rakni bármi egyéb infót, index, query stb
- dump és snapshot backupok, amelyik szimpatikusabb
- nem utolsó sorban replikáció beépítve
- A hozzászóláshoz be kell jelentkezni
hacsak lehetseges, nem bonyolitanam (jobban) az egesz komplexitasat sem mongoval, sem rdbms-sel.
--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...
- A hozzászóláshoz be kell jelentkezni
Egyben kell az egész fájl vagy kell részolvasás ia? Mik ezek, emailek? Ha nem kell, akkor minek feltalálni a spanyol viaszt és miért nem használsz rá adatbázist? Akár egy pgsql, akár valami specifikusan kulcs-érték alapú db. Ha sok az adat, még mindig lehet particionálni.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Tehát legyen egy nagy fájl és ne csilliárd kicsi. Ami véletlenül egy pg data file, de az lényegtelen ha a feltett kérdésre koncentrálunk. :)
--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead
- A hozzászóláshoz be kell jelentkezni
Ja, csak cserébe ad neked mindent készen, megbízhatóan. Fiatal koromban én is játszadoztam még ilyen konténer-formátumokkal, arra jutottam, hogy ameddig RO és csak egyszer le kell generálni, addig nem probléma a feladat, ha már módosítás is van és az se árt, ha megbízható, akkor már problémásabb. Ha párhuzamos írás is van, akkor meg jobb nem feltalálni a spanyol viaszt.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
A kérdést én úgy értelmeztem hogy van A hoszt, rajta egy raklap bittel, meg van B hoszt, amin nincs semmi. Hogyan vigyük át A-ból B-be a cuccot (egyszer).
Tehát nem kell a szinkront fenttartani a két hoszt között, meg semmi hasonló. Mivel a kolléga nem említett ilyesmit, csak egy copy -t.
Az igaz, hogy a második fele egy tök más kérdés, ott már bőszen lehet RDBMS -ekről beszélgetni.
--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead
- A hozzászóláshoz be kell jelentkezni
igy van, nem szinkornizalni kell 2 gep kozott, hanem migralni. Az a use case, hogy gyulik a sok raklap bit egy gepen, aztan egyszer csak a jomunkasember megvilagosodik, hogy mindezt at kene tenni egy masik gepre, mert kinotte a regit, whatever, vagy a topik apropoja kapcsan gondolom, nem akar tovabb fizetni a szolgaltatojanak.
--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...
- A hozzászóláshoz be kell jelentkezni
Én sem beszéltem szinkronizációról, hanem arról, hogy a saját konténer-formátum fasság.
(Bár egyébként migrációra most pont adtál most egy tök jó ötletet, hogy migráció esetén bőven elég felhúzni egy replikációt két DB között, aztán mikor átment, akkor szimplán csak módosítani a connection stringben a DB-t az újra.)
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Egyébként, ha szigorúan nézzük, a Pgsql is szegmentál 1G-s egységekre ;)
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
igen, emailekrol van szo. Ha a csillio 'kis' file-okrol van szo, akkor nem kell reszolvasas, viszont amint a mongodb ellen is irtam, mindenkeppen elkerulnem a komlexitas noveleset egy extra rdbms-sel. Mysql amugy van metaadatok szamara, de eleve ebbe sem akartam TB-nyi, valtozo meretu blob-ot tarolni, ill. mysql melle meg foleg nem tennek fel pgsql-t, hogy a file-ok (tartalma) azokban legyen.
--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...
- A hozzászóláshoz be kell jelentkezni
Édes midnegy, hogy pgsql, mysql vagy akármi. Megoldott problémára akarod feltalálni a spanyol viaszt szvsz.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Ahogy a bölcs dakota mondás tartja:
Do not reinvent the wheel, except when learning about wheels.
- A hozzászóláshoz be kell jelentkezni
Emlekszem, h egyszer mar volt es az volt, hogy db kezelot akarsz lenyegeben fejleszteni, akkor miert nem hasznalsz egy mar meglevot (vagy rakod abba a dolgaid).
- A hozzászóláshoz be kell jelentkezni
lehet, hogy volt, de kifejezetten nem db kezelot szeretnek.
--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...
- A hozzászóláshoz be kell jelentkezni
Nem kell bonyolitanni.
Attol fuggoen rsync mennyi ideig tart, migralas elott 1-2-3 nappal lsyncd-t allitsd neki hogy nyomja at masik gepre + hagyd futni. Csinal egy rsync-et, majd a valtozo file-okat is.
Migralas idopontjaban minden (file) ott az uj gepen, leallitod a regin az lsyncd-t es orulsz.
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
Ez az lsyncd nagyon jó cucc, köszönöm!
- A hozzászóláshoz be kell jelentkezni
Mennyi a sok? Mennyi a kevesebb? Mik a követelmények a másolásra/backupra?
- A hozzászóláshoz be kell jelentkezni
tobb millio file-rol, tobb TB adatrol van szo. A masolasra valojaban nincs kovetelmeny, hanem az lenne kivanatos, ha konnyebb (es gyorsabb) lenne, mint a sok file-t egyesevel atvinni.
--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...
- A hozzászóláshoz be kell jelentkezni
Nagy hülyeség lenne;
1. sftp helyett tar|untar ahogy már javasolták
2. man 8 dump
3. man 8 nilfs
4. ha semmi nem tántorít el, akkor már legalább a libtar-t használd
A nilfs-hez hashelés helyett az kell, hogy mondjuk 10000 fájl/mappa és utána nyitod a következőt. A rendezetlen fájl szintű mentéshez így szinte csak szekveniális IO kell. A deduplikáció miatti begyűjtés ígyis-úgyis random IO, bár ebben valszeg lassabb lesz a nilfs mint egy általános fs, ki kell mérni.
- A hozzászóláshoz be kell jelentkezni
miert lenne hulyeseg? A libtar otlete viszont tetszik. Megneztem egy konkurens megoldast, az ugy csinalja, hogy nyit kb. 1024 db zip file-t, es azokba teszi a 'sok kis file-t'. Valamelyik forumukon viszont valaki beleszaladt valamilyen zip gubancba, de (gondolom en, hogy) eleg stabil lehet, kulonben tele lenne a forumuk a 'tele vagyunk korrupt zip file-okkal' panaszokkal.
--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...
- A hozzászóláshoz be kell jelentkezni
Mert a sok fájl hozzáértéssel kezelhető, vannak rá jó módszerek. Ugyanakkor "dobozos" terméknél erős érv, hogy az 1 bites rendszergazda is elboldoguljon vele. Visszavonom: nem hülyeség.
- A hozzászóláshoz be kell jelentkezni
itt szerintem az sftp a fő problema
akkor már inkabb rsync
--
Live free, or I f'ing kill you.
- A hozzászóláshoz be kell jelentkezni
Hát, nem biztos. Feltételezve hogy a távoli host szűz, akkor az rsync-el nem nyersz, mert egy sima másolás lesz a vége.
Magyarul az sftp és az rsync bitre ugyanazt fogja csinálni (nyit egy ssh data sessiont és becopyzza a fájlt csilliárdszor).
Amennyiben maradunk csillárd fájlnál, és használjuk az rsync compressiont, még lassabbak is leszünk, mivel a csilliárd cp parancs előtt és után is tömörítünk egyet be meg ki.
Szerintem valami ügyes eljárással össze kéne concatolni a fájlokat, átvinni egyben rsync compress-el (mivel az on the fly tömörít, és nem kell kézzel be meg ki tarolni), és visszavagdosni.
A művelet előtt meg után meg rázavarni valami md5sum szerű ellenőrzést.
--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead
- A hozzászóláshoz be kell jelentkezni
"valami ügyes eljárással össze kéne concatolni a fájlokat, átvinni egyben rsync compress-el (mivel az on the fly tömörít, ..."
tar cz MAPPANÉV | nc HOST PORTSZÁM
On the fly tömörít és kiadja a másik HOST általad meghatározott TCP PORTjára. Ott pedig hasonlóképpen egy nc fogadja és a tar on the fly kicsomagolja.
- A hozzászóláshoz be kell jelentkezni
De a tar ugyanúgy sok random fejmozgást okoz a sok kis fájlnál nem? Tehát így nem spórolsz I/O-t. A háló meg nem derült ki hogy szűk lenne.
- A hozzászóláshoz be kell jelentkezni
Mindegyik fájlrendszerbeli olvasásnál ugyanez a problémád lesz forgótányéron, hiszen a 10 ms körüli fejléptetési ideje fog valójában vissza.
Erre viszont megoldás lehet, ha a partíciót átklónozod dd-vel egy kölcsön SSD-re és arról tar-olod a fájlokat.
De az is érdekes, hogy igény szerint "dd if=/dev/zero of=uresfile" módon kinullázhatod a diszk maradék részét és a partíciót dd if=/dev/... | gzip | nc átmásolod a másik gépre ahol szintén egy nagy partícióra dd-zed bele, majd a fájlrendszert igény szerint kiterjeszted a partíció valós méretére. Ext4 exetén resize2fs paranccsal.
- A hozzászóláshoz be kell jelentkezni
Feljebb írtam BtrFS send / receive -et, akkor már az jobb szerintem. Ott blokkonként tudod tolni az FS diff-et, nem számít hogy sok kicsi fájlból áll-e, ha jól gondolom.
- A hozzászóláshoz be kell jelentkezni
Ha BtrFS-en van a cucc. Ha nem, akkor az egészet át kell migrálni - csillió darab fájl esetén nem kevés idő.
- A hozzászóláshoz be kell jelentkezni
https://en.wikipedia.org/wiki/Btrfs#Send.2Freceive
"Binary diff"-et csinál. Ha jól értelmezem, akkor ez nem fájlonként való átmásolást jelent. Ha így van, akkor sokkal gyorsabb lehet.
- A hozzászóláshoz be kell jelentkezni
a forras gep egy centos 6 volt, nem is emberunk kezeben volt, hanem a szolgaltatojaeban. Nem tudjuk, milyen fs volt rajta, szerintem default, amit a centos 6 telepitoje felajanlott.
csillió darab fájl esetén nem kevés idő.
igy van, meg az rsync is elgondolkodik, mire elkezdi masolni a file-okat. Ezert toprengek egy olyan strukturan, ami robosztus, nem serulekeny, es egyszerubb az atvitele 2 gep kozott.
--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...
- A hozzászóláshoz be kell jelentkezni
Az rsync már jobb egy fokkal, mert felszedi a fájlok adatait, de annak is az a rákfenéje, hogy nem egyszer, hanem menet közben minden fájlra a másolás/szinkronizálás előtt nyom stat() hívásokat - ami ilyen számosság esetén rohadt drága.
Ha backup-jelleggel kell másolni, akkor lvm snapshot, és a snapshot-ról tar | ssh -c arcfour ... | tar megoldásban gondolkodnék. Szabványos eszközökkel megoldható, egyszerű - igaz, kell hozzá amásolás idején változó blokkok össz méretét meghaladó szabad hely, meg rendszergazda jog.
Ha csak az kell, hogy az 1. gép elborulása esetén is meglegyenek a fájlok a 2. gépen, akkor akár egy drbd-s kötet is jó lehet - ott viszont a sávszélesség, illetve opcionálisan a titkosított csőbe húzása a forgalomnak is kérdés. Volt szerencsém relative magas i/o igényű motyót drbd-n szinkronizálni két gépterem (Petőfi S. u. - Dataplex) között (szintén több millió fájl, hash-elt könyvtárstruktúrában), és egészen megbízhatóan működött. Volt, hogy onnan vettem észre az elsődleges odlalon lévő diszk kihullását, hogy a képek egy része a szokottnál lassabban töltődött le...
- A hozzászóláshoz be kell jelentkezni
A dump(8) elvileg nem a fa-strukturát járja be hanem szekvenciálisan megy a diszken és úgy szívja fel a használt blokkokat. Mondjuk nagyon-nagyon rég használtam, lehet rosszul emlékszem.
- A hozzászóláshoz be kell jelentkezni
"A háló meg nem derült ki hogy szűk lenne."
Az már réges rég kiderült, de nem a sávszélesség a szűk, hanem az sftp protokollban a file-onként szükséges roundtrip üzenetváltások késleltetése adódik össze.
- A hozzászóláshoz be kell jelentkezni
+1, az sftp erősen szuboptimális nagy mennyiségű fájl átlapátolására.
- A hozzászóláshoz be kell jelentkezni
.
- A hozzászóláshoz be kell jelentkezni
Vagy "csak" a default cypher, ami nem arcfour, bár jóval nagyobb az esélye annak, hogy rettenet sok I/O-val jár a standard eszközök használatakor a másolás.
Nekem törölni kellett rengeteg fájlból keletkezési idő meg fájlnévre illesztett minta alapján - ugye mindenki rávágja, hogy find minta meg -mtime, oszt' jónapot... Ja. csak stat() hívásból ha jól rémlik négy volt per fájl... Saját eszköz készült: egyszer felolvasta a könyvtárat, minden fájlra, aminek a neve illeszkedett a mintára egy stat(), az mtime alapján meg unlink(), ha törlendő volt. Nem picit lett gyorsabb.
A sokfájlt átmásolni dologra nem tudok ilyen ötletet, a saját konténer (fs over fs) érdekes ötlet, ha csak kreálni meg törölni kell tudni belőle, akkor akár egyszerű is lehet, de azért célszerű ellesni a megbízhatósággalkapcsolatos ötleteket máshonnan (metaadatok többszörözése minimum).
- A hozzászóláshoz be kell jelentkezni
Csak minek saját konténer, mikor ugyanazt készen,valószínűleg megbízhatóak nyújtják az adatbáziskezelők?
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
mert erosen megnoveli a rendszer komplexitasat.
--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
Nézőpont kérdése. Nekem pont, hogy egyszerűbbnek tűnik így megoldani, mert áttolsz egy látszólag egyszerű, valójában meglehetősen komplex problémát - konzisztencia fenntartása, párhuzamos elérés és módosítás kérdése, műveletek atomi szinten kezelése, optmalizáció stb. - egy másik önálló egységbe, ráadásul valószínűleg jobban tesztelt, mintha te próbálnád feltalálni a spanyol viaszt.
Láttam már néhány rendszert, ahol megpróbálták feltalálni a spanyol viaszt, valahol mindig fájdalom volt a vége. Kedvencem, amikor valaki egy kulcs-érték alapú, journalingolt, .txt-s "adatbázist" fejlesztett le Java-ban a saját dolgához, aztán mikor jöttek a a kicsit komplexebb adatszerkezetek (pl. egy üzenet), akkor 3-4-5-6-7+ kulcson voltak tárolva, mert nem volt megoldva, hogy komplex osztályt beleserializálj, XML-t, Json-t meg nem akart belerakni, mert az is plusz függőség, blablabla. Fogott volna egy SQLite-t, hamarabb meglett volna és ezerszer egyszerűbb és hibabiztosabb lett volna minden.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
parhuzamos eleres max. olvasasra kell, azt meg tudom oldani, hogy csak 1 processz irjon. Viszont az SQLite-tal adtal egy jo otletet :-)
update: az sqlite db-nek van egy olyan korlatja, hogy vagy olvasod, vagy irod. Ha ketto sajnos nem megy egyszerre. Viszont ha tobb processz is tudja olvasni, akkor talan meg igy is jo lehet.
--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...
- A hozzászóláshoz be kell jelentkezni
Jó, csak ha úgy is van egy MySQL mögötte, akkor meg már nem mindegy? Meg ok persze, meg lehet olvasni, hogy 1 process írjon. De akkor meg kell oldani a queue-t, stb, stb. stb. Szóval végeredményben minek, ezzel is növeled a _saját_ komplexitásod. És igen, persze, egy adatbázistól is visszajöhet exception, kell retry policy, de ugyanígy visszajöhet egy IOException is, amit nem tudsz megoldani.
Igazából szimplán nem látom értelmét, minek megoldani megoldott problémákat, ha érdemben nem teszek hozzá többet.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
mar az elejen afele mentem, hogy sql-ben csak metaadatok legyenek, a tenyleges adatok meg a filerendszerben, es ezen egyelore nem is szivesen valtoztatnek.
Tovabbgondolva a feladatot, lehet egyszerusiteni is. Nem kell queue, (real time) exception kezeles, stb. hanem a demon processzei ugyanugy file-okba irnak mint eddig, es irok egy programot, ami bizonyos kesleltetes utan vegigmegy a top level konyvtarakon, es az azokban levo file-okat betolja egy sqlite db-be, majd torli az erintett file-okat.
Azt nem mondtam, hogy a top level konyvtarakbol ~12 naponta nyilik uj (pl. c7), es attol fogva a korabban nyitottakban (c6, c5, ...) mar nem modosulnak az adatok. Igy az sqlite file irasanal nincs konkurencia, olvasni meg akarhany processz megnyithatja oket. Igy ha pl. 4 ev mulva Huang-nak eszebe jut, hogy migralni kellene, akkor van neki 4 * 365/12 ~ 120 db nagy file-ja, meg 1 top level directory sok (de kozel sem annyira sok mar) file-lal, amit at kell vinni a masik gepre.
1 aprosag lesz igy: az olvaso programnak eloszor meg kell nezni, letezik-e a konszolidalt sqlite file (es mivel rengeteg legacy rendszer van, ahol nem feltetlen akarjak a regebbi konyvtarakat ilyen modon konszolidalni), amire a valasz sokszor az lesz, hogy nincs, es akkor csak ezutan fogja megnyitni a tenyleges adatfile-t.
--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...
- A hozzászóláshoz be kell jelentkezni
Én se raknák terabájtnyi blob-ot db-be, mert akkor nem kis gond, hogy legyen sűrűn konzisztens dump-od, ami meg egyetlen fájl és rohadt nagy. A db meg baromi érzékeny arra ha korrupt lesz a fájl, míg FS-nél pár fájlod kiesik a sok millióból.
- A hozzászóláshoz be kell jelentkezni
Szerencsére feltalálták már a dump mellett a replikációt is, ráadásul lehet a tranzakciós logokat is backupolni, ami máris nem lesz rohadt nagy.
Harmadrészt meg ha csak inkrementális backupot csinálsz, akkor ugyanúgy beszívhatod, hogy valamelyik inkrementum rossz, elveszett, stb.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
E-mail. Személyes adat. Felejtési jog. Törölni kell a blob-okból. Van shrink, vagy ha egyszer nagyra nőtt, akkor úgy is marad?
- A hozzászóláshoz be kell jelentkezni
PostgreSQL:
https://www.postgresql.org/docs/current/static/routine-vacuuming.html
https://www.postgresql.org/docs/current/static/sql-vacuum.html
MSSQL:
https://docs.microsoft.com/en-us/sql/relational-databases/databases/shr…
MySQL:
https://dev.mysql.com/doc/refman/5.7/en/optimize-table.html
SQLite:
https://sqlite.org/lang_vacuum.html
És így tovább...
De egyébként az ilyen réseket simán újrahasznosít egy normális RDBMS.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Ez jó, anno volt, aminél dump/restore volt az optimális megoldás...
- A hozzászóláshoz be kell jelentkezni
Szépen lassan feltalálod az adatbáziskezelőt és a particionálást.
Meg amit írtál, az számomra nagyságrenddel komplexebb, mintha csak annyit írnék meg, hogy van egy fekete dobozom, amibe az X id-jű bináris blob-ot betúrom, meg az X id-jű bináris blobot visszaadja és az egész baszakodás egy másik szinten van kezelve. Nem látom be, hogy ez az SQLite-s baszakodás miben jobb, mintha simán a MySQL-ben lenne tárolva az adat. Főleg, hogy egy tisztességes RDBMS a particionálást normálisan használva teljesen láthatatlan módon képes számodra az ezer éves adatot is előkotorni (akár még úgy is, hogy a régi fájlok particióit egy időzített jobbal folyamatosan mozgatod át mondjuk SSD-ről HDD-re vagy akár egy archiválásra használt cloudba a világ végére) függetlenül attól, hogy melyik chunkban van.
Sőt, egyébként, ha kultúrált interface-n keresztül éred el az egészet (ami most mindegy, hogy egy osztály, lib, vagy egy microservice), akkor az egészet úgy tudod cserélni a háttérben, ahogy akarod.
De a te dolgod, hogy hogyan szopatod magad és a szoftvered felhasználóit.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
BLOB, illetve BLOB-jellegű rekordokat tartalmazó táblánál melyik RDBMS tud jól shrinkelni...?
- A hozzászóláshoz be kell jelentkezni
az sftp a kozelebbrol nem megnevezett jomunkasember valasztasa volt. Nekem ugy adta elo, hogy ajanljak neki valami grafikus sftp kepes klienst. Elotte hiaba kertem, hogy egy basic centos-t huzzon csak fel. Erre felhuzott egy komplett grafikus kornyezetet is a gepre. Sigh... juzerek.
--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...
- A hozzászóláshoz be kell jelentkezni
dump + restore az adott block device-ra.
ZFS stream :)
--
„Spiró ótvar, Konrád átok, Nádastól meg mindjárt hányok!”
- A hozzászóláshoz be kell jelentkezni
Ilyesmit ganyoltam nem is olyan regen, sebesseg/megbizhatosag/kornyezet fuggvenyeben a kovetkezok voltak a modszerek, kezdve a leghatekonyabbal:
1. btrfs send/recv ssh-n keresztul
2. zfs send/recv ssh-n keresztul
3. tar|ssh|untar
4. rsync ssh-n keresztul
Amennyiben a forras fs sem btrfs, sem zfs, a 3. opciot erdemes megprobalnod
--
"It all keeps adding up / I think I'm cracking up / Am I just paranoid? / I'm just stoned"
/Green Day - Basket Case/
- A hozzászóláshoz be kell jelentkezni
leveldb (es hasonlo klonjaiben) nem lehet tarolni azokat az adatokat?
utana van nehany nagy fajlod amit konnyen lehet masolni
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni