Dotaz: Multi-threading v embedded databazovej aplikacii

[kovariadam]

Dobrý deň vospolok, nemám skúsenosti s následujúcim problémom, preto Vás chcem poprosiť o rady/skúsenosti:

Jedná sa o lokálny server/daemon, ktorý bude mať 3 úlohy:

1) čakať na povely/žiadosti o dáta od klientskej aplikácie,
2) získavať dáta z hardware a ukladať ich a
3) poslúchať na TCP sockete a odosielať dáta podľa požiadania servera.

Rozmýšlam o POSIXových threadoch, ale nie som si istý či sa jedná o najlepšie riešenie. Pôvodne som si myslel, že SQLite bude dobré jednoduché úložisko, ale zistil som, že nepodporuje paralelný zápis aj čítanie(jedine zamykanie). Tak teraz uvažujem o textových súboroch. Lenže je možne dosiahnuť paralelné čítanie aj zápis? Pravdepodobne len so zámkami, ale obávam sa o výkon. Jedná sa totiž o embedded zariadenie a zápisy budú časté, niekoľko za sekundu, čítania zas až tak časté nebudú(raz za hodinu približne).

Myslíte, že je to dobrý nápad? Alebo uvažovať o nejakom embedded MySQL/Firebird? Ale, čo ten overhead?

Ešte jedna možnosť by bola sa na celé multi-threading veci vykašlať a riešiť to v rámci jednej event loop.

Ďakujem za odpovede.

Odpovědi

[Fuky]

Chtělo by to více podrobností:

1. Jaké množství dat budeš ukládat?
2. Jakou strukturu budou mít data?
3. Jak budeš data číst, všechna, výběr dle nějakého klíče?
4. Kolik máš k dispozici paměti?
5. Je potřeba data zachovat i při vypnutí HW?

[kovariadam]

1. Množstvo dát bude závisiet od množstva prídavných kariet(tak do 10), z nich sa budú zbierať namerané hodnoty každú sekundu, teda je to štruktura typu {čas, hodnota}.

2. vid bod 1.

3. Z dát sa bude robiť štatistika každú hodinu, ale tak isto budú sa čítať podľa kľúča občasne a inak len externý server ich bude zbierať, teda opäť celý "súbor dát"

4. 64-128MB RAM, ešte presný model HW neviem. Na ukladanie asi 2GB SD karta alebo niečo podobné, to by ale malo stačiť na požadovanú dobu ukladania, tj. 1 mesiac.

5. Áno, integrita dát je zásadná.

[podlesh]

Existuje "multiprocess verze" klasické Berkley db: TDB (součást projektu Samba). Není to SQL, ale pořád lepší než textové soubory.

[kovariadam]

Ďakujem, môžem sa spýtať prečo sú textové súbory zlé, resp. prečo toto je lepšie?

[pavlix]

Z hlediska efektivity na tom bude nějaká lehká databázová knihovna líp než ukládání do jednotlivých souborů. Na souborech se taky hůř dělají transakce.

Ale mezi náma... git taky používá souborovou databázi a běhá jako hodinky. Dost záleží na účelu a taky návrhu aplikace.

[podlesh]

No v podstatě je to totéž, ale už to udělal někdo jiný, dal si s tím dost práce a opravil spousty bugů. Obzvláště u poměrně používaného projektu.

[AraxoN]

Sqlite pokiaľ viem podporuje paralelný zápis a čítanie, akurát zápis v jednej chvíli môže robiť najviac jedna transakcia. Ak zápis bude robiť len jeden proces naraz, tak by som v tom nevidel problém.

[kovariadam]

Several computer processes or threads may access the same database without problems. Several read accesses can be satisfied in parallel. A write access can only be satisfied if no other accesses are currently being serviced, otherwise the write access fails with an error code (or can automatically be retried until a configurable timeout expires). This concurrent access situation would change when dealing with temporary tables.

Ak tomu rozumiem správne, tak zápis môže sa diať len pokiaľ sa nedeje čítanie. K tomu mi napadli dve veci: ako zabezpečiť aby sa nezapisovalo keď chcem čítat, resp. čo s tými dátami, budem ich zatiaľ nejako bufferovať a potom zapisovať? To je ale dosť hnusný hack.

Druhá vec je, že taký istý problém budem mať asi aj so súbormi.

[AraxoN]

Áno, to sa píše na wikipedii. Na stránke Sqlite sa ale píše toto:

SQLite connections can open two kinds of transactions, read and write transactions. This is not done explicitly, a transaction is implicitly a read-transaction until it first writes to a database table, at which point it becomes a write-transaction.

At most one connection to a single shared cache may open a write transaction at any one time. This may co-exist with any number of read transactions.

Mám za to, že ak explicitne nezačneš v Sqlite transakciu, tak on do transakcie zabalí každý jeden SQL príkaz osobitne (t.j. každý príkaz sa vykoná ako BEGIN-príkaz-COMMIT). Takže zápisy sa vykonajú postupne v nejakom poradí, zatiaľčo čítanie to nijak neovplyvní. Ako sám píšeš, zamykanie budeš musieť riešiť aj pri iných uložiskách, a toto je podľa mňa vyriešené celkom dobre samo od seba.

Ale ber ma s rezervou, neskúšal som to, len tak mudrujem. Radšej to prever na nejakom testovacom príklade.

[kovariadam]

Ďakujem, vyzerá to sľubne.

Takže úložisko je už vyriešené. Čo sa vlákien týka, tak ich najlepšie použitie sa mi zdá ich nepoužiť:).

Ak existuje nejaký pádny dôvod ich použiť, tak prosím oň.

[AraxoN]

K threadom sa Ti neviem vyjadriť - niekde sa hodia, niekde nie. Čo by som ale chcel ešte okomentovať je "niekoľko zápisov za sekundu". Podľa typu flashky je počet zápisov na to isté miesto obmedzený na rádovo 10-tisíc až milión, takže niekoľko zápisov za sekundu Ti tú flashku môže zabiť v horšom prípade za pár hodín, v lepšom za pár dní.

[kovariadam]

Ďakujem, neviem ako som mohol na také niečo nemyslieť. Našťastie tam nebude flashka, ale normalný HDD. Tam tento problém síce možno nenastáva, ale aj tak uvažujem o cachovani dát napríklad po minútach. V kombinácií s baterkou by to malo byť už OK.