Hirdetés
- Beköltözött a ChatGPT az Ulefone filléres órájába
- Kisebb kivágás, középen kamera: így nézhet ki az iPhone 18 Pro előlapja
- 100 wattos töltést és 27 wattos fordított töltést kap a Redmi Turbo 5 Max
- Másfél millió forintért már haza is vihető a Huawei aranyozott csúcsórája
- Gyártási gondok a BOE-nél: Samsung kaphatja az iPhone 17e kijelzőit is
- Samsung Galaxy A54 - türelemjáték
- iPhone topik
- Honor Magic6 Pro - kör közepén számok
- Milyen okostelefont vegyek?
- Poco F8 Ultra – forrónaci
- Megtalálták az akkumulátortechnológiai Szent Grált? - CES
- Szívós, szép és kitartó az új OnePlus óra
- Samsung Galaxy Z Fold4 - egyre megy, honnan nézed
- Xiaomi 15T Pro - a téma nincs lezárva
- Samsung Galaxy S23 Ultra - non plus ultra
Új hozzászólás Aktív témák
-
Keem1
veterán
Mekkora az MD5 hash mérete?
Ezt nem értem
Simán a normál MD5 16 bájtos mérete, hexában.Miért nem másolod el egy másik fájlba azokat amit nem akartsz törölni [...]?
Alapvetően az lett volna, hogy nap végén: logs.txt -> logs001.txt, de külső elérés kell a loghoz, ezért (+ a kereshetőség miatt) a DB.Most van egy AI PK, de az a fájlbéli logbejegyzéstől független. Arra is gondoltam, hogy hátha lenne egy int alapú hash algoritmus, de itt is fontos a gyorsaság (az MD5 előállítása minimális erőforrást igényel), a hash-re csak az adatbázisba írás miatt van szükség, a feladat többi szemszögéből irreleváns.
Így néz ki a tábla schema:
CREATE TABLE "logs" (
"id" INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT,
"level" INTEGER,
"tstamp" TEXT,
"message" TEXT,
"location" TEXT,
"userid" TEXT,
"hash" TEXT
);A logfájl mindegyik sora egy határoló string alapján kerül feltördelésre, a log level pedig a megfelelő string indexe lesz (NONE->0, ERROR->1, DEBUG->2, ...).
Egy log sor így néz ki:
DEBUG - 2020-04-05 16:00:04 - No IP change detected, no need to update - [itt az adott namespace.class.method van] - [devicename/userid]Tranzakcióra nincs esetleg valami (sematikusan) ilyesmi?
IF SELECT ...
INSERT INTO ...
ENDIF -
Keem1
veterán
Helló emberek, iránymutatást szeretnék kérni. Mivel IoT rendszerről (Raspberry Pi) van szó, minden megspórolt millisec számít.
Adott egy már jól működő service, de ami még debug módban megy, ezért rengeteget loggol file-ba (egyelőre kell is, az alapján csiszolom), viszont minden nap végén a log file-t kiürítené, tartalmát SQLite adattáblába zsuppolná (keresés, kiértékelések miatt). Sajnos egyelőre vannak logbejegyzések, amiket bent hagynánk a fileban, és nem lenne jó naponta újra és újra beírni az adatbázisba, ezért egyszerűen tárolunk ott egy MD5 hasht is (vizsgálva, hogy a hash bent van-e már az adatbázisban). A helyzetet "bonyolítja", hogy tranzakcióval megy a beírás (napi 200-1000 log tranzakció nélküli beírása [csak az adatbázisművelet] 1-2 sec, tranzakcióval 40-80 ms).
Hogy lehet a legjobban, legelegánsabban megoldani?
- letárolás előtt a hash értékek kiolvasása egy tömmbe/listába programozottan (C#)?
- INSERT helyett SELECT(?) + INSERT annak csekkolására, hogy már bent van-e a hash, a db-re bízva? Ha igen, itt kérnék iránymutatást, fogalmam sincs, ez miképp kivitelezhető egy tranzakció belsejében, a COMMIT parancsot megelőzően.Az első pont fizikailag készen van, működik is, csak nem tudom, ez így mennyire vehető jó megoldásnak egy IoT rendszernél.
Javaslatot szeretnék kérni!
Új hozzászólás Aktív témák
- Amazon Kindle 10th Generation ébresztős tok
- Azonnali készpénzes INTEL CPU NVIDIA VGA számítógép felvásárlás személyesen / postával korrekt áron
- BESZÁMÍTÁS! GIGABYTE A520M R5 1400 8GB DDR4 256GB SSD 500GB HDD GTX 1050 Ti 4GB ZALMAN S3 400W
- Apple iPhone 12 Pro Max 128GB, Kártyafüggetlen, 1 Év Garanciával
- Xiaomi 11 Lite 5G NE 256GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Central PC számítógép és laptop szerviz - Pécs
Város: Pécs
Simán a normál MD5 16 bájtos mérete, hexában.


