Dotaz: SQLite jako sdílená databáze?

[Burák]

Přemýšlím o jednoduché aplikaci pro sběr a zobrazování dat. Prvni část v C čte každou minuto data z ModBus RTU a jednou za 10 minut je zapíše do databaze. Druhá část je už klasicka web záležitost,které je zobrazuje ve formě grafů a "gadget". Jde o technologickou záležitost, čili sůedovat to budou max tři lidé , jde o to, aby to bylo co nejednoduší, nejblbuvdornější a schopné provozu desetileti. Nechci data ukladat jako textový log, ale také nechci "velký" SQL server . Logicky mě napadla SQLite, ale nevím jak relné a rozumné je nasadit jí jako databazi ke ketré májí přístup dva "programy"

Poradíte?

Odpovědi

[X]

Kdyz se nad tim zamyslis, tak program v C "zapisuje" a program pro web "cte". To se vzajemne nevylucuje, takze SQLite je uplne v pohode.

[Jendа]

To se vzajemne nevylucuje

Vylučuje v tom smyslu, že když čtecí program bude přistupovat zrovna v okamžiku, kdy se mu data mění pod rukama, tak načte něco nevalidního. Ano, nedojde ke ztrátě dat, a když se to zkusí za chvilku znovu, tak už to třeba dopadne dobře.

Nicméně sqlite má tohle ošetřené zámky.

[Kit]

Hlavně tu databázi nedávej na sdílené úložiště.

[RealJ]

myslis, ze takova samba nezvladne nazev čurák\šulin\Zvěrokleštička.sqlite?

[Kit]

Problém u Samby je se zamykáním záznamů při modifikaci. Podle setupu je to buď pomalé, anebo nespolehlivé. Můžeš si vybrat.

[Want]

Jo. Jde to, ale znamená to, že musíš na aplikační úrovni ošetřit věci, které mají jiné databáze vyřešené "in vitro". A tím pádem získáš, jako bonus, mraky potenciálně rizikových míst.

[Want]

Ale zdá se, že turso by mohlo být pro tebe vhodným řešením. Má být kompatibilní s SQLite, ale řeší právě ty konkurenční zápisy.

[sdfdsf]

rust slop. no, thanks.

[OldFrog {Ondra Nemecek}]

A jak se ti tři lidé k té sqlite databázi dostanou? Budou sedět u jednoho počítače?

Spočítal bych, kolik dat tam bude za 5 let. Nevím jaká motivace je nemít velký sql server, ale pokud je to jen "aby s tím nebyla práce", tak to není dobrá volba a dal bych na to Postgres, se kterým bude ve výsledku práce méně a zadarmo získáte vzdálený konkurentní přístup. Případně - pokud bude dat opravdu hodně a budou založená na časových razítkách - bych volil timetable databázi.

[Kit]

Uvádí, že ostatní uživatelé se připojují přes web. Dělal jsem podobnou aplikaci s MySQL a vlastně by podobně fungoval i SQLite. Vlastně ne tak docela, protože pro statistiku jsem potřeboval vložené procedury, bez kterých to původně jelo 100× pomaleji. V SQLite by se to řešilo v aplikaci.

[RealJ]

ten web ty pozadavky do db muze delat fifo... nic ve zlym, tohle je reseni ktere si rika dlouhodobe o pruser... nevim co je ve dnesnim svete velkeho na treba mariadb ktere ti pobezi i na raspberry... vygenerovat relevantni kod v cecku ti zvladne i zak pomocne skoly nebo libovolna "AI"...

[Kit]

FIFO si SQLite obslouží samo. V jeden okamžik může být jeden zápis a vícero čtení. Více procesu současně nevadí. Vadí jen více vláken jednoho procesu.

Zrovna u sledování výrobního procesu je MySQL v nevýhodě, kterou by aplikace musela řešit vloženou procedurou. V SQLite se to dá umístit přímo do aplikace bez ztráty výkonu.

[OldFrog {Ondra Nemecek}]

Popiš přesněji problémy s výrobním procesem, procedurou a výkonem. Zní to hodně divně.

[Kit]

Pokud proces hlásí každých 10 sekund stav zapnuto/vypnuto a tento stav je uložen do databáze. Za den získáš kolem 10k záznamů od každého stroje. Typickým požadavkem vedení je graf využití toho stroje za den, týden či měsíc. Bez vhodné agregace to jsou obrovské přesuny dat mezi databází a aplikací. V mém případě to byly 3 minuty na každý graf a bylo jich deset. V této podobě jsem to zdědil. Agregací vloženou procedurou jsem to zkrátil na 1-2 sekundy na graf.

V SQLite tento problém odpadá, protože SQLite je v selectech řádově rychlejší než MySQL a proto je možné tu agregací řešit až v aplikaci.

[OldFrog {Ondra Nemecek}]

Ok. Koukal jsem na to a ta sqlite je opravdu rychlá, proti Postgres na vzorových datech daného typu několikanásobně rychlejší.

Otázka však zní, zda je pro měsíční graf potřeba do aplikace přenášet 10k hodnot * 30 dnů = 300k hodnot. Pokud by se to řešilo ve standardní SQL tak by se pomocí MATERIALIZED VIEW agregoval stav jako hodinový průměr (procentuelní zastoupení stavu true za danou hodinu) a select pro graf by měl minimální režii (v Postgresql by to bylo v řádu ms oproti řádu sekund v Sqlite).

[Kit]

Tenkrát mi bylo dáno MySQL s daty a byl jsem rád, že jsem mohl přidat dvě tabulky, když jsem nesměl do stávajících přidat sloupce a že jsem mohl přidat tu vloženou proceduru.

[OldFrog {Ondra Nemecek}]

To si dokážu představit... Akorát bych z toho nedělal závěry pro serióznější nasazení SQL databáze. Dobře navržená SQL databáze bude mít v řadě situaci lepší celkový performace než Sqlite. To není nic proti Sqlite, naopak o ní uvažuju pro jeden soukromý projekt.

[RealJ]

A to zapnuto/vypnuto tam zapisujes o velikosti 10mb na zaznam? Ty vole db s 10k radkami pro treba 1000 stroju ve ktere je v podstate 0/1 ti pobrzi i na mikrovlnce. Ja netusim co tazatel resi, ale reporting nejakych stavu je zalezitost kde fakt negenerujes terabajty dat… ja videl db ktera dela monitoring/reporting dat ze senzoru v nuklearnim provozu, tech senzoru bylo asi 300 a kazdych 5 sekund to zapsalo namerenou hodnotu ze senzoru, jednou denne to vygenerovalo nejaky report, jednou tydne to vygenerovalo dalsi report, jednou mesicne mesicni report a to cele bezelo na starickem pentiu se 2gb ram…muj prispevek byl o tom, ze tazatel vymysli reseni ala kapica ktere bude stat dlouhodobe za hovno a jednoho dne mu nekdo za nej podekuje…

[Want]

muj prispevek byl o tom, ze tazatel vymysli reseni ala kapica ktere bude stat dlouhodobe za hovno a jednoho dne mu nekdo za nej podekuje…

Moje řešení jede non-stop od roku 2011 ty blbe. A za tu dobu se v něm protočily nejmíň čtyři major verze Debianu.

[sid]

Preco nie firebase? Pokrocile, bezpecne, jednoduchsie ako postgresql.

[sid]

Firebird myslene.

[OldFrog {Ondra Nemecek}]

Desetileti bez údržby nepoběží nic. Jaká má být retence dat? Jak dlouhou historii potřebuješ mít uloženou a co se stane, když o nic přijdeš? Jak velká ta data jsou, jaké operace se nad nimi mají dělat? Od toho bych se odpíchnul a pak teprve vybíral vhodnou technologii. V extrému například, pokud bys nepotřeboval retenci a o data mohl kdykoli přijít, tak stačí systém spouštět z read-only úložiště a data ukládat jen do paměti (struktura nebo in-memory databáze), bude to rychlé, nebude potřeba údržba úložiště a při restartu vše naběhne s prázdnými daty. Opačný protipól je situace, kdy o data nesmíš v žádném případě přijít protože hrozí velké pokuty, pak bude řešení postavené úplně jinak a budeš řešit pravidelné odlévání dat do nějaké repliky, provádění snapshotů a záloh. Atd. atd.

[Jendа]

Ano, já bych to udělal přesně takhle, SQL server se mi adminovat nechce. Jen si dej pozor, že u sqlite budou fungovat její přirozené zámky - což je naprosto v pohodě na jakémkoli normálním FS, ale raději bych si to ověřil, pokud by to bylo na něčem divnějším síťovém (sshfs, NFS s vypnutými zámky kvůli rychlosti…).

a schopné provozu desetileti

V tomto nebude podle mě problém se sqlite, ale s technologií, která bude dělat to webové rozhraní. Například dvě populární webové technologie (PHP a Python s Bottle/Flaskem) se rozbíjejí s poločasem 5-10 let a jsou potřeba většinou drobné, někdy ale i větší (přechod z PHP 5, přechod z Pythonu 2) úpravy. Obdobně ty "grafy a gadgety", pokud to bude nějaké hodně javascriptové s příliš mnoha knihovnami, tak bych se trochu bál o kompatibilitu jak knihoven, tak prohlížečů za 10 let.

[noone]

Oracel BerkleyDB