Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Joskoo 29. 01. 2018, 11:05:08
-
Ahojte,
Pracujem na projekte pre embedded zariadenia v C, single/multi-thread model, POSIX standard. Prisla potreba ukladania nameranych dat na fyzicke medium.
Data su vo formate bud JSON alebo XML, key/value. Jedna "polozka" dat ma velkost od ~500b do ~3kb, encoding je utf-8. Data su asynchronne prijimane a spracovane, potom by mali byt logovane na fyzicke medium. Takze sa jedna o W operacie, ale kvoli "buducim" zmenam, by bolo vhodne implementovat RW operacie nad DB.
Poloziek je vsehovsudy asi 500/h, zariadenie je aktivne 6h/24h.
Chcem sa vyhnut znovuobjaveniu kolesa, existuje nejaka pekna implementacia v C ktora by mi zabezpecila potrebnu funkcionalitu, ale aby overhead nebol zas prilis velky?
1) SQLite - na takuto potrebu sa mi zdal overhead prilis velky, plny potencial by som nevyuzil...
2) NoSQL, skusil som asi dve implementacie, ale vsehovsudy, 500b zaznam + skoro 4kb junk-u okolo...
3) Napisat si svoju implementaciu v XML/JSON, (asi nebude tak efektivna co do I/O ale nebude az taky moloch...)
Otazka do plena, pozna niekto peknu vhodnu implementaciu na embedded zariadenia?
ktoru z bodov by ste na dany problem pouzili?
diky S.
-
Ukladej to do souboru jehoz cesta/nazev bude odvozena od primarniho klice. Nevim proc si komplikovat zivot :)
-
https://en.wikipedia.org/wiki/Sleepycat_Software
-
sqlite je na tohle přímo ideální, nemusíš použít démonizovanou verzi, ale použít její C knihovny, běžně na tom běžíme. Pokud chceš být hodně minimalista, redis či whitedb, ale ty jsou primáně in-memory.
Sqlite má doboru synergii s ext4 a přes její journaling si umí řešit paralelní zápisy, takže ti může běžet na každém jádru jedna aplikace a ta zapisovat do binárního souboru na disku, co chceš víc? Nosql je proti sqlite velký overhead.
-
Jestli je to jen jednoduche key-value na disku, tak treba https://en.wikipedia.org/wiki/Berkeley_DB (libdb v debianu)
-
Jestli je to jen jednoduche key-value na disku, tak treba https://en.wikipedia.org/wiki/Berkeley_DB (libdb v debianu)
Nevíš jak to je teď s její licencí? Co jsem viděl, Oracle to chce zavřít.
-
Normalne bych pouzil filesystem na sd disku, flash pameti, nebo naprudko ukladat data linearne jako bajty za sebou jako v tar. Mohly sis pridat index na offsety zacinajicich polozek.
-
Xml/json jsou stromy, co treba compact tree storage, v pameti, ve flash.
-
dělat to ručně jako doporučuje 8xd je asi ta nejhorší varianta, pokud se něco nepovede, může to vést k poškození dat, chybné konzistenci, má to problém s paralelismem, musíš si ručně udržovat fsync, pokud nechceš nic ztratit, tohle vše již řeší hotové knihovny a je jich celá řada, od zmíněné berkeley db, což je hoodně lehká nadstavba, po těžší ale pořád lehký sqllite, můj oblíbené whitedb, které to ukládá do sdílené paměti či poměrně rád používám na mini projekty tuhle opičárnu https://github.com/simongog/sdsl-lite
-
Jestli je to jen jednoduche key-value na disku, tak treba https://en.wikipedia.org/wiki/Berkeley_DB (libdb v debianu)
Nevíš jak to je teď s její licencí? Co jsem viděl, Oracle to chce zavřít.
Já nevím, wikipedie tvrdí:
dual licensed (GNU Affero General Public License and commercial permissive license) (version 6.x and upwards)
Sleepycat license (versions 2.0-5.x)
4-clause BSD license (versions 1.x) / JE is licensed under Apache License, Version 2.0.
-
Ukladej to do souboru jehoz cesta/nazev bude odvozena od primarniho klice. Nevim proc si komplikovat zivot :)
Taky doporučuji tohle. Souborový systém je také key-value databáze, a pro tak velká data bude ta nejrychlejší.
-
soubory ve FS nejsou špatné, pokud mi stačí pouze jeden index (název souboru; v tomhle případě asi datum) a pokud souborů nejsou stovky tisíc, miliony, řada nástrojů ze coreutils může mít s tímhle pak problémy (ls je jednovláknové např. a klidně si počkáš 20 min na list na pomalejším zařízení). Na druhou stranu nástroje z coreutils se dají používat pohodlně jako knihovna v C.
Jakmile je ale potřeba soubory prohledávat, upravovat jednotlivé řádky či řešit multivláknový přístup, FS může být zlý pán.
Bez upřesnění zadání lze těžko doporučit správné řešení.
-
soubory ve FS nejsou špatné, pokud mi stačí pouze jeden index (název souboru; v tomhle případě asi datum) a pokud souborů nejsou stovky tisíc, miliony, řada nástrojů ze coreutils může mít s tímhle pak problémy (ls je jednovláknové např. a klidně si počkáš 20 min na list na pomalejším zařízení). Na druhou stranu nástroje z coreutils se dají používat pohodlně jako knihovna v C.
Jakmile je ale potřeba soubory prohledávat, upravovat jednotlivé řádky či řešit multivláknový přístup, FS může být zlý pán.
Bez upřesnění zadání lze těžko doporučit správné řešení.
Jen dodam, ze (pokud se nic nezmenilo), tak linux kernel neumi drzet v buffer cache cast inode adresare. Takze je v pameti bud vse anebo nic. Takze se muze obcas stat, ze bude potreba nahrat z disku cely "index".