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.

[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?

[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.

[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.

[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.