Ingyenesen használható adatbáziskezelő
2016-05-06T08:08:01+02:00
2016-05-14T10:20:05+02:00
2022-07-21T22:08:50+02:00
  • egyik adatbázis sem tömöríti az adatokat!

    A Firebird most is tömörít RLE-vel (ami ugyan nem túl erős tömörítésű, de rendkívül egyszerű és gyors).
    Pont a rekordok legnagyobb gondján segít, pl. egy char(20) mezőbe tett 3 karakteren. Így a maradék 17 space karaktert 3 byte-re csökkenti.
    Ez mellesleg sebesség növekedést is eredményez, mert adott esetben pl. egy 4096 bytes lapon 4874 byte adat található, így nem két page, hanem csak egy page I/O illetve cache kell.
    Mutasd a teljes hozzászólást!
  • Hát ebből a threadből nem lesz sok DDE
    Szerintem próbáld meg a DDE-t kerülni mert ezer éves technika
    Valahogy soros/Ethernet/ valamilyen buszon kellene elérni az adatokat
    Mutasd a teljes hozzászólást!
  • Gondolatok az olvasottakhoz (Mindenkiéhez)

    - igen, több lehetséges megoldás is van, érdemes előre mérlegelni
    - Úgy tudom a MySQL már nem ingyenes, helyette MariaDB van.
    - az SQLite csak lokálisan működik, hálózatosan nem.
    - tudtommal egyik adatbázis sem tömöríti az adatokat! (Max a mentés fájlt)
     sőt, inkább rendkívül pazarlóan használják a merevlemezt, hogy minél biztonságosabb és gyorsabb legyen. (Indexelés, lazy-sweep, redundancia ...)
    - kérdéses lehet még az adatbázis REPLIKÁCIÓ !
     Ez már nem éppen a kezdő-kategória, de érdemes fontolóra venni, hogy a kiolvasott adatokat esetleg egyszerre több gépen/helyen is tárolni mindenképpen előnyös.

    - Akarod-e webes motorokkal összekapcsolni? Ha igen, az az engine támogatja-e azt az adatbázist?

    Személyes vélemény:
     Jómagam is FireBird párti vagyok, (Jelenleg a 2.5.5 motort használom Delphi7-tel és Lazarus-szal)
    Mert:
    - egyetlenegy fájlban tárolja az adatokat.
    - Nagyon egyszerű installálni és konfigurálni a motort.
    - Rendszergazdaként sokszor kellett sérült rendszerekről adatbázisokat lementenem, és egyedül a FB volt, ahol egyszerűen ki tudtam menteni a "lényeget".
    - Eléggé jól bírja a hirtelen áramszüneteket
    - A Delphibe és Lazarusba szinte alapból van integrálva a komponens-csomag, amivel működik.
    ...
    Ugyanakkor:
    Ha most kellene kezdenem valamivel, akkor lehet, hogy inkább a PostgreSQL-t választanám, mert
    - rendkívül gyors és stabil és a
    - webes integrálása is könnyebb (Több webszolgáltató is kínál hozzáférést olcsón.)
    Mutasd a teljes hozzászólást!
  • firebirdnél van-e incrementális/differenciális backup

    Vagy 3 éve lehet.

    nbackup utility néven keresd, része a mellékelt utility készletnek, de akár teljesen saját is írható, mert adatbázis tulajdonsággá tették, hogy "befagyasztható" az adatbázisfile tartalom (és külső filebe mennek az adatok addig) majd a mentés végeztével rádolgozza az epszilon állományt az adatbázisra.
    Ez a technika pl. lehetővé teszi filecopy-val adatmentést megnyitott éles adatbázison. Fényévekkel gyorsabb a gbak-nál (igaz az adatbázis sértetlenségét/konzisztenciáját nem elemzi... buta filecopy ill. az nbackup is egyszerű filetartalom másoló, csak inkrementálisan is tudja)
    Mutasd a teljes hozzászólást!
  • MSSQL Server Express is ingyenes de max 10 GB adatbázisonként
    Mutasd a teljes hozzászólást!
  • Ez lehet hogy segít a választásban:
    SQL Feature Comparison

    ezekből a PostgreSQL, MySQL, Firebird, SQLite tuti ingyenes.

    Én nagy PostgreSQL mániás vagyok, így nyílván azt ajánlom, de valszeg ennél a problémakörnél annyira nem fontosak a modern SQL funkciók.
    Bár hosszútávon nem lehet tudni mire lesz szükség.
    A tábla partícionálás pl. ebben az esetben jól jöhet, ha szükség lenne olyan lekérdezésre, amivel az összes eddigi adatra szükség van, de már túl sok lenne egy táblában tárolni.
    Mutasd a teljes hozzászólást!
  • Hali!

    Én is hasonló gondokkal kűzdök annyi különbséggel, hogy nekem excelbe jönnek az adatok DDe linken csak valamiért én még menteni sem tudom a változókat.... úgyhogy feszülten figyelem a hozzászólásokat :)
    Mutasd a teljes hozzászólást!
  • úh, heves szorzások közepette elég csúnyán benéztem
    Mutasd a teljes hozzászólást!
  • Azért ennél lényegesebben kevesebb adat halmozódna fel egy hónap alatt, mert szerencsére 1 hónap nem 31 hétből áll.
    Mutasd a teljes hozzászólást!
  • Szép feladat!
    Mutasd a teljes hozzászólást!
  • Tehát az adatbáziskezelők, amiket ajánlottatok, azok mind használhatóak ingyen, hivatalosan?
    Mutasd a teljes hozzászólást!
  • Köszi, már gyorsan rá is néztem, majd otthon kipróbálom. Te használod? Majd arra leszek kíváncsi, hogy milyen gyorsan dolgozik, illetve mennyire szereti ha másik gépen közben valaki valami tranzakció(ka)t futtat.
    Mutasd a teljes hozzászólást!
  • Firebird tud incremental backup-ot (nbackup)
    Mutasd a teljes hozzászólást!
  • Hát igen, az előbb nem írtam, hogy milyen adatokat gyűjtök. Szóval távfűtésről van szó, így ahogy írtad lassú folyamatról van szó, ezért megengedhettük, hogy ritkábban mentek adatot a hőközpontokból. Azért megnyugtatok mindenkit, nem a programom szabályoz hanem ő csak adatokat gyűjt, illetve bizonyos paramétereket tud állítani. A szabályzást egy cél hardver végzi, ő szolgáltatja az adatokat is.

    Hogy, hogyan tudja előre jelezni a hibát? Egy-két példa egyszerűen megfogalmazva (lehet olyan is van ami nem 100% úgy van ahogy leírtam):
    Pl. a melegvíz puffertároló alsó érzékelő szerint folyamatosan hűl a víz, akkor valószínű valamiért nem kezdi el vissza melegíteni. A lakók csak akkor érzékelnék a hibát ha már teljesen kiürül a tartály. Viszont mi már akkor látjuk, hogy valami van mikor még 2/3 -1 /2 -ig van, így van fél – egy nap előnyünk a javításra.
    Nem is olyan rég pont az tűnt fel, hogy napról-napra egyre több vizet kellett „utántölteni” a rendszerbe, így már akkor elkezdték megnézni az aknákat, hogy hol áll a víz, mert valahol szivárgás van.
    Vagy a legegyszerűbb eset, ha egy érzékelő rossz. Ami lehet csak pár órával vagy csak az esti időszakban lenne hatással a fűtésre. Vagy a relék – hőmérsékletek szinkrobna vannak-e (relé szerint menni kéne a szivattyú de a víz hőmérsékletből nem ez látszik )
    Ilyenkor a nyári időszak kezdetén adatok alapján látjuk, hogy a hőcserélők milyen „állapotúak / hatásfokúak” (primer-szekunder hőmérsékletek). Ha szükséges akkor most nyáron lesznek felújítva, cserélve.

    Ezt a részt pont 1-2 hónapja írtam meg, sok ellenőrzési algoritmusok jelenleg még kialakítás alatt van. Meg most kezdtem el foglalkozni a M-bus rendszerrel, amin keresztül még több és pontosabb adathoz jutnék (ha esetleg van valaki foglalkozott a témával az jelezhetne privátban :)

    Megnézem, hogy firebirdnél van-e incrementális/differenciális backup. Eddig nem hallottam róla, hogy ilyen is van. Köszi a tippet!
    Mutasd a teljes hozzászólást!
  • Mivel CSV-be kerül, ezért csak több lesz ugye. :D

    Jah, bocs

    (Tényleg: végeznek tömörítést az adatbáziskezelők? Automatikusan, vagy be kell neki állítani?)

    Van olyan is.
    Mutasd a teljes hozzászólást!
  • Első lépésben átgondoltuk a lekérdezési időt, amely után a kétszeresére emeltük a lekérdezési időt. Ezzel ugye felére is csökkent a méret.

    Ahogy írod is, feladat (és Shannon tétel ) függő a megoldás.
    Szerintem elsősorban a sűrűbb mintavétel átlagolásán kell elgondolkodni, ez pontosabb mintha ritkásabban csak bele szurkálunk az adatgörbébe.
    Persze ez tök értelmetlen ha egy lassú folyamatról van szó és 1 másodperc helyett 2 másodpercenként van mintavételezve

    megpróbálom előre jelezni.

    Erről mesélhetnél, milyen módszerrel?

    Így a mentés jelentősen felgyorsult, nem kell minden alkalommal 10 év adatait elmentem, hanem csak az aktuálisat.

    Igaz, viszont az adatbázis kezelőknél is létezik az incrementális/differenciális backup
    Mutasd a teljes hozzászólást!
  • Üdv!

    Látom lassan áttérünk az adatgyűjtés fogalmához.
    Jelenleg nekem is van egy olyan program ami több helyről több adatot gyűjt. Nálam is probléma volt a nagy adatbázis, így változtatni kellett a módszeren.
    Első lépésben átgondoltuk a lekérdezési időt, amely után a kétszeresére emeltük a lekérdezési időt. Ezzel ugye felére is csökkent a méret.
    Mivel így is elég nagy maradt még az adatbázis ezért dolgozni kellett még rajta. Nálam elég sok string adat van, amely sok esetben akár napokon keresztül is változatlan. Így ezeket csak akkor mentem el az adatbázisba, ha változás áll be. Vannak bizonyos számok ami csak tájékoztató jellegűek, azon kívül, hogy az ember szükség esetén megnézze oda is elég volt a változásokat menteni. Természetesen amivel számolni is kellett ott maradt az a változat, hogy minden alkalommal ment.
    Ez természetesen az én feladatomhoz jó, lehet neked/nektek teljesen más kell. Továbbá az adatgyűjtésen kívül nekem a másik fontos dolgom, hogy a hibát jelezzem, illetve megpróbálom előre jelezni.
    Szóval az eredeti témához szólva (ahogy korábban is írták) csak azt akartam kinyögni, hogy jól át kell gondolni az egész adatgyűjtést és jól meg kell tervezni. Utána mérlegelni kell az adatbázis kezelők képességeit.
    Hogy saját véleményemet is megírjam: én firebird adatbázis-kezelőt használok. Igaz, nekem semmi extra nem kell így szinte bármi jó lehetne. Több más programnál is ezt használtam, mostani igényeimnek is megfelel így ezért nem is gondolkodtam el máson.
    Ja és a másik ami hirtelen eszembe jutott, nekem nem volt fontos, hogy egy adatbázisba legyen minden, így én szétbontottam évente, azaz egy adatbázisba csak egy év van. Így a mentés jelentősen felgyorsult, nem kell minden alkalommal 10 év adatait elmentem, hanem csak az aktuálisat.
    Mutasd a teljes hozzászólást!
  • Oké, legyen adatgyűjtés! :D

    Amit kiszámoltál, az csak a nyers adatok mennyisége. Mivel CSV-be kerül, ezért csak több lesz ugye. :D Viszont naponta készül egy fájl, majd be lesz tömörítve. Illetve (ez kérdés is) az adatbáziskezelők tömörítést is végeznek az adatokon, nem? (Tényleg: végeznek tömörítést az adatbáziskezelők? Automatikusan, vagy be kell neki állítani?)
      Hogy a megrendelő mit kezd a rengeteg adattal, az már legyen az ő problémája! :D (Amíg át nem hárítja rám a dolog megoldását... :D )

      Egyébként csak nem egy kollégához van szerencsém? Mármint: Te is esetleg irányítástechnikai rendszerekkel foglalkozol?

     (Tegnap felmerült még néhány újabb kérdés/probléma, de azoknak inkább nyitok egy új témát.)
    Mutasd a teljes hozzászólást!
  • Érdekes módon XP alatt mindig jól ment ez a program, de amióta Windows 7 alatt használom, eddig minden munkámnál produkált valamilyen bosszantó hibát.

    Elég specifikus (DDE/OLE/ActiveX/OPC) az ilyen rendszerek  belő szerkezete és erősen kötődnek az adott operációs rendszer belső világához. Egyáltalán nem csodálkozom ha OS rendszer váltása után nem minden tökéletes.
    Sz.v.sz. agyrém (WinCC/Step7 <-> stuxnet) hogy a SCADA-k általában ennyire függenek az MS-től és a fent nevezett technológiákhoz, bár érthető hogy kialakulásukkor miért azok voltak a megfelelőek.

    Így aztán belefogtam a saját készítésű adatmentő programba

    Amit leírtál az adatgyűjtés nem adatmentés. Mert ugye attól, hogy CSV-be teszed az adatokat még nem oldottad meg az adatmentést mivel azok a fájlok is elveszhetnek.
    Ha adatmentés is cél, akkor ahhoz be kell állítani valamilyen backup megoldást.

    Nekem annyi dolgom lesz az adatbázissal illetve a rögzített adatokkal, hogy bizonyos adatokból napi/heti stb. ? átlagokat kell számolnom

    Akkor célszerű hogy adatbázisba irányítsd az adatokat. Vagy közvetlenül, vagy akkor csv-ből adott időnként (óránként?/naponként?)  bedolgozva (ez utóbbi megoldás arra is jó ha az adatbázis szerver elérhetetlen vagy lerohad ... ellenben extra munka)
    Adatbázis szerverben vagy külső időzített feladatként is beállítható a backup.

    Egyébként most épp úgy tartotta úri kedvem, hogy 3 másodpercenként kérdezem le a rendszerben lévő összes adatot. Ez kb. 10-12 kbyte/lekérdezés adatmennyiség. (Mármint ennyi adat van a PLC-kből kiolvasva.)

    Úri kedved "vonzata":

    időtartam   MiB
    3 sec     0,0    
    1 perc     0,2    
    1 óra     14,1    
    1 nap     337,5    
    1 hét     2 362,5    
    1 hónap     73 237,5

    szóval 73 GB havonként, valszeg el fogsz kezdeni valamilyen kivonatoláson gondolkodni
    Mutasd a teljes hozzászólást!
  • Nos, köszönöm a hozzászólásokat! Megpróbálok mindenkinek válaszolni...

      Az operációs rendszer Windows 7. Van már egy működő SCADA rendszer a PC-n, ami viszont sajnos nem mindig áll a helyzet magaslatán. Ez a PLC-k gyártójának saját SCADA rendszere, a maga hülyeségeivel és hibáival. Érdekes módon XP alatt mindig jól ment ez a program, de amióta Windows 7 alatt használom, eddig minden munkámnál produkált valamilyen bosszantó  hibát.

      Azért szerettem volna magam megírni egy adatgyűjtő programot, mert :

      1. Szerettem volna kicsit fejlődni szakmailag (nem PC programozó vagyok alapvetően, hanem PLC programozó)
      2. Nagyon kíváncsi voltam, hogy amikor a gyári alkalmazás megbolondul, akkor vajon a saját programom megfelelően működik-e? (Tehát hogy megbízhatóbb-e egy saját készítésű program, mint a megvásárolt SCADA.) 

      A kezem sokmindenben meg van kötve, illetve vannak olyan dolgok, amikbe nem szólnak bele. A jelenleg működő SCADA sajnos most is küszködik néha... ez azt jelenti, hogy megszakad a kommunikáció a PLC-kkel, illetve a mentett adatokat valamiért nem egy fájlba menti, hanem több fájlba szétszórja azokat. Így aztán belefogtam a saját készítésű adatmentő programba. Ez csak az adatok mentését végzi, a grafikus megjelenítés, felpattanó ablakok kezelése stb. továbbra is a SCADA programra van bízva.
      Azért döntöttem a CSV formátum mellett, mert az ugye univerzális. Bár nem néztem utána, de sejtésem szerint bármilyen adatbáziskezelőbe be lehet importálni. Tehát a megrendelő bármilyen adatbáziskezelőt szeretne használni, az importálás megoldható. (A másik dolog, hogy azért annyira még nem vagyok otthon a PC programozásban. Nagyon a felszínét karcolgatom csak, nem akartam még több időt azzal tölteni, hogy az adatbázisba mentést közvetlenül a programomból csináljam. Bár lehet, hogy az lesz a vége!)

      Nekem annyi dolgom lesz az adatbázissal illetve a rögzített adatokkal, hogy bizonyos adatokból napi/heti stb. ? átlagokat kell számolnom. Ezen felül viszont a megrendelő megkapja a hőn áhított adatbázisát és azt csinál az adatokkal, amit csak szeretne... :D 
      Egyébként most épp úgy tartotta úri kedvem, hogy 3 másodpercenként kérdezem le a rendszerben lévő összes adatot. Ez kb. 10-12 kbyte/lekérdezés adatmennyiség. (Mármint ennyi adat van a PLC-kből kiolvasva.)
    Mutasd a teljes hozzászólást!
  • Magam is írtam már így programot. A mai napig üzemel. Minden hajnalban több millió sort dolgoz fel. Sok mappából, több szervezetből egy szervezetbe egy adatbázisba.

    Mondjuk én dbf->csv->mssql (bulk) megoldással. A végén indexeket gyárt, másfél óra alatt fut le kompletten.
    Mutasd a teljes hozzászólást!
  • Bocs de mindenki felsorolta (tisztelet a kivételnek) a kedvenc DB-jét.
    Miközben ez tipikusan az az eset, ahol a feladathoz választunk DB-t (ha nagy az adatmennyiség), vagy használja ami az ismert fejlesztő eszközeihez a legjobban illik (kis adatmennyiség esetén).


    A mért adatok tipikusan read-only-k.
    De egy nagy adatbázisba összehordva nem csak adhoc adatlekérdezések vannak, hanem statisztikai összesítések is lehetnek.
    Ezeket meg (egy adatmennyiség felett) vagy a tételek beszúrásakor triggerel (nem igazán javallt) vagy ütemezett futtatással oldjuk meg.
    Van az az adatmennyiség, ahol a nyers adatok kitisztázása/részösszesenek képzése/összesítő adatok kigyüjtése+tárolása erős terhelést okoz. 

    Én pl. csináltam többször olyat, hogy régi DBF alapú rendszerből átemeltem az adatokat egy SQL adatbázisba.
    Mert az jó!  [A régi rendszer elmuzsikál, gyártja az adatokat ütemesen, de már bottal sem piszkálja (főként nem fejleszti) senki.]
    A DBF-ek betöltése raw formában ömlesztve történik, mert így gyors. Még az indexeket is lekapcsolom róla a betöltés idejére. Merthogy a DBF hemzseghet a legkülönfélébb hibáktól. Meghogy a normál formákat csak hírből ismerik ezek az adatok.
    Ez valóban gyors művelet.
    Aztán ezeket a nyers adatokat le kell tisztázni és új adatszerkezetbe áttolni (persze közben hibalistát/naplókat gyártani), hogy jól használható legyen.
    Na ez már képes keményen leterhelni a szervert! 
    Mutasd a teljes hozzászólást!
  • Ha már mindenkit lehordtál,

    felhasználás [keresések ill. módosítások])?

    szerinted a kinyert adatokat szokták módosítani ?
    Mutasd a teljes hozzászólást!
  • off
    Mutasd a teljes hozzászólást!
  • Látom hülyébbnél hülyébb válaszok érkeztek (tisztelet a kivételeknek  ). 

    Rengeteg ingyenes DB van, ami alapján dönthetsz az 

    1./ Milyen nyelven/eszközzel akarod kezelni, milyen környezetben (win/Linux/felhő/embed/stb)?
    2./ Milyen célra kell (tételszám, méret, felhasználás [keresések ill. módosítások])?
    Mutasd a teljes hozzászólást!
  • A problémának n+1 lehetséges megoldása van, szóval már csak egy dolog maradt: szavazzunk 

    Én MySQL-t használnék hozzá.
    Mutasd a teljes hozzászólást!
  • Egyetértek az előttem hozzászólókkal valamint amit még nem értek, hogy ha már magad csinálsz mindent, akkor minek ez a bonyolítás, hogy előbb egy csv-be aztán onnan adatbázisba. Miért nem egyből adatbázisba írod be az adatokat?
    Mutasd a teljes hozzászólást!
  • Sosem értettem miért kell a "tákolás" az ilyen jellegű feladatokat már n+1 alkalommal megvalósították, és kialakították a megfelelő eljárásokat

    Ha ezen a területen mozogsz, akkor érdemes lenne utánanézni a SCADA és OPC rendszereknek
    http://home.hit.no/~hansha/documents/lab/Lab%20Work/SCADA/SCADA,%20O..

    és keress ingyenes, opensource alternatívát ami a céljaidnak megfelel
    Mutasd a teljes hozzászólást!
  • Ha már megy a Lazarus akkor SQlite  és olyat készítesz amilyet akarsz.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd