ugrás a tartalomhoz

tail -f sql alapon?

mind1 valami név · 2019. Már. 24. (V), 10.42
Van arra bejáratott módszer mysql/mariadb/postgresql vonalon, hogy folyamatosan lekérjem az újonnan bekerült sorokat egy táblából és ne terheljem ezzel túlságosan a szervert?

Át akarom állítani a log szerveremet text fájlokról rdbms backendre, viszont ebben az esetben nem látok elég egyszerű lehetőséget arra, hogy kiváltsam a tail -f log parancsot, ha épp szükségem van rá. Mivel eseti dologról van szó, azt nem tartom jó ötletnek, hogy emiatt kétfelé küldjem a logok tartalmát, ami egyébként megoldás lehetne...
‹ postgres - insert into ... select - megadott sorrendben 5.5.65-MariaDB kérések várakoznak, nem teljesülnek ›
 ■
1

Én PostgreSQL-el csináltam

kuka · 2019. Már. 24. (V), 15.54
Én PostgreSQL-el csináltam egy azonnali értesítést:
Így egyik résztvevő program sem futott fölösleges köröket, a Qt program pedig azonnal értesült róla, hogy változás történt. A változás mibenlétének persze már maga kellett utánajárjon.

Elméletileg más adatbázis esetében is mű ködhet, amennyiben QSqlDriver::hasFeature(QSqlDriver::EventNotifications), de gyakorlatilag csak PostgreSQL-ről tudok. És ott is csak a Qt osztállyal sikerült összehozni, más nyelvek esetében az értesítés vagy teljesen hiányzik, vagy csak egy akármilyen adatbázis művelet után kapja meg a program.
2

Köszi, ez így felejtősnek

mind1 valami név · 2019. Már. 24. (V), 18.50
Köszi, ez így felejtősnek tűnik, esetemben ágyúval verébre kategória. Reméltem, hogy van a select-nek olyan opciója, ami képes ilyesmire, vagy tárolt eljárásnak van ehhez direkt megoldása.
Úgy fest valamit rosszul írtam a googliba, most találtam pár tippet, de mind a tiédhez hasonló szintű, úgyhogy ezt akkor félreteszem.
Még azt megnézem, hogy mi történik, ha egy fifo eszközre próbálok írni az adatbázis mellett... ha az annyi, mintha a /dev/null-ba küldené, csak ad esélyt a kiolvasásra, akkor ez is megoldja a gondomat.

Ui: az egész csak azért jött elő, mert ha textbe írja a syslogd a logot, akkor csak a küldő rendszer ideje kerül bele, az adatbázisba meg a log szerveré is. (A router restart után május 5-ére áll be, ami elront pár szkriptet)


Update: lehet, hogy mégsem olyan szörnyen bonyolult, mint ahogy elsőre gondoltam, csak az a Qt-s dolog tűnt ijesztőnek... megnézem, megoldható-e nálam is ez a verzió. (és hogy nem zavarja-e az rsyslogd-t a trigger)
3

Új sorok

Pepita · 2019. Már. 25. (H), 11.13
Szerintem nem ördögtől való ezeket query-zni, ha van egy jó (pl AUTOINCREMENT) meződ rá a táblában, és megfelelően partícionált, ha nagy a rekordszám.
SELECT * FROM Tábla
WHERE id > (
SELECT MAX(id) - 10 AS max_id FROM Tábla
)
;
Itt a belső select is csak egyszer fut le, mert nem függ az értéke a külsőtől.
Persze lehet ezt is pontosítani kívánság szerint.
4

Binlog streaming

vbence · 2019. Már. 27. (Sze), 00.40
Léteznek megoldások, amik az amúgy replikációra használt bináris logot fogyasztják és akár küldik message brokerre (amire ráakaszkodhatsz bármilyen fogyasztóval).

Itt van pl egy opensource projekt:
https://github.com/mardambey/guzzler

Kicsit részletesebb Kafkás megoldás:
https://engineeringblog.yelp.com/2016/08/streaming-mysql-tables-in-real-time-to-kafka.html

... that been said, én nem ajánlom RDBMS-be írni logot.Azok a storage enginek nem ilyen jellegű használatra lettek kitalálva. Text fájllal bármilyen linux eszköz tud dolgozni, ha rotálni szeretnéd, vagy zippelve feltölteni valami olcsó tárhelyre.
5

Köszi, abban azért nem értünk

mind1 valami név · 2019. Már. 27. (Sze), 16.32
Köszi, abban azért nem értünk egyet, hogy e célra ne lenne alkalmas egy rdbms (leszámítva azt, hogy a tail -f nem épp triviális)
Ami miatt én gondolkodom rajta: az adatbázisba írt sorokba több info kerül, mint textbe. Évszám, a küldő és fogadó rendszer ideje egyaránt, a textben nincs évszám, nincs benne a fogadó rendszer ideje (lehet, hogy ez is módosítható, egyelőre nem találom).
Amiért komolyabb helyeken megfontolandó az rdbms használat, az pl. adatvesztés megelőzése, ami sima text esetén nem biztosított igazán.

Azt nem igazán értem, mire gondolsz azzal, hogy nem erre valók ezek az engine-k. Max. hangolni kell a tároláson, hogy ne pazarolja a helyet (sajnos csak oracle tapasztalatom van, ott megoldható), esetleg particionálni. Rotate kicsit másképp megy persze, de évente egyszer elég általában.

Update: syslog-ng esetében megvan a potenciális megoldás a text formátumú log átalakítására, a template "személyében".
6

rdbms

vbence · 2019. Ápr. 2. (K), 19.55
Hasrautesre alapozva: egy random írasra/olvasara szant eszközzel kezelsz egy append-only adatstrukturat. Jo esetben is folosleges adminisztracioval lassitod a folyamatot, rossz esetben meg nagysagrendekkel is lassabba teheted (mondjuk par napi/heti torlesi cikus utan fregmentalt tablaba iras random ures lukakkal).

Lehet hogy csak előítélet, mert nem láttam még ezt a módszert használatban, de nem is olvastam sehol hogy ennek az előnyeit bizonygatták volna egy klasszik, file alapú megoldással szemben.

A backupot emlitetted előnyként, ami rotált fájloknál igazán triviálisan megoldható., viszont RDBMS esetén a tavaly márciusi log kikeresése egy olcsó tárhelyre lementett backupból elég körülményes).
7

Háááát... ebbe már nem mennék

mind1 valami név · 2019. Ápr. 2. (K), 20.10
Háááát... ebbe már nem mennék bele, mert 10+ éve volt és amúgy is amortizálódott a szürkeállományom, de azért egy rdbms nem olyan egyszerű, hogy random I/O-ra van kitalálva.
Backupot én egy szóval sem említettem.
Adatvesztés megelőzése alatt arra gondoltam, hogy ha pl. kirántod a gépet a kettőhúszból, akkor sem fog elveszni (annyi) adat, mint amikor sima textbe megy.
8

Pedig a DB írási és olvasási

BlaZe · 2019. Ápr. 2. (K), 21.12
Pedig a DB írási és olvasási feladatok random váltakozására van kitalálva. Kezelnie kell egy rekord update-jét, törlését (tombstone-ok), indexelését, kulcsok menedzselését stb. Továbbá a konzisztencia megőrzése miatt (egy normális) adatbázis a változások végrehajtása előtt egy változás logba (WAL) beírja a végrehajtandó módosításokat. Ebből tud visszaállni egy esetleges crash esetén. Ez így lényegesen több munka, és több helyet foglal, mint egy szekvenciális log file-ba írás. Emiatt (többek között) én se tennék logot adatbázisba.

Enterprise környezetben se tárolnak RDBMS-ben logot. Log aggregátorokat és processorokat használnak, ami értelmezni, indexelni, keresni, feldolgozni tudja a logokat, riasztásokat tudsz beállítani rá stb. Viszont erre se az RDBMS a legjobb megoldás. Ezek mellett text formátumban is megtartják viszont a logokat, mert sokminden úgy a leghatékonyabb (pl a tail).
9

Egyetlen okból nem akarok

mind1 valami név · 2019. Ápr. 2. (K), 21.24
Egyetlen okból nem akarok vitatkozni: kurrrva rég volt. Oracle 9i-vel volt mélyebb kapcsolatom, ott elég alaposan lehetett paraméterezni táblákat, táblatereket stb., ha épp szekvenciális adatbetöltésre/írásra volt szükség.
Rdbms-ben tárolt loggal kapcsolatban talán a Balabit embereit kellene kérdezni, nem feltételezem róluky hogy felesleges dolgokba ölnék a munkaidejük egy részét, ilyesmit én nem csináltam. De pl. Websphere MQ is használ(t) DB2 backendet a rajta átmenő üzenetek tárolására, ami kb. ugyanaz volt, mint a logok tárolása, csak gyakrabban törlődtek talán a benne tárolt adatok.

Mondjuk humoros, hogy itt: https://www.rsyslog.com/doc/v8-stable/tutorials/database.html többek közt a realtime hozzáférést emelik ki rdbms-ben tárolt logok egyik előnyeként. :)
10

Nem a megvalósíthatóság a

BlaZe · 2019. Ápr. 2. (K), 23.59
Nem a megvalósíthatóság a kérdés, hanem hogy milyen előnyöket ad. Amit akarsz:
- timestampekkel
- megtagelt
- tartalmat
- nagy mennyiségben
- leírni

Erre egy valamilyen NoSQL megoldás sokkal kellemesebb tud lenni. Szemben egy RDBMS-sel, sok esetben natívan tudnak elosztva adatokat tárolni, akár in-memory, elosztott backupokkal, sokkal alacsonyabb latency mellett, és még kismillió előnyük bír lenni. Ahogy Bence is írta, ez egy append-only feladat. Nyilván tudsz táblaterekkel játszani, olyan tábla definíciót létrehozni, ami akkor optimális, ha csak insertelni fogsz.

Én is dolgoztam olyan projecten, ahol RDBMS-be írtunk (nem syslog jellegű, nem szöveges) logot. Ott még volt valamennyi reláció is, de szerintem az RDBMS nem erre való.

Sok cucc képes RDBMS-eket használni backendnek, mert
- kiforrottak
- stabilak
- egyszerűen illeszthetőek
- mindenki ismeri
- van csomó open-source
- apt-get install és megy :)

De mindenre RDBMS-t használni perzistence layerként kalapács és szög esete. Gondolj bele, hogy egy MQ-nál mekkora overhead egy RDBMS persistence layer egy erre szabott formátum helyett. Hogy mást ne mondjak mi az említett projecten pont egy (durable) MQ-t tettünk az Oracle-be írás elé. Az egyéb architekturális megfontolások mellett ez sokkal stabilabb latency-t hozott, és jobban viselte a burst jellegű workloadot. Az alkalmazáslogokat ugyanezen a projecten Splunkba irányítottuk. Ami sokkal többet tud, mint amit képes voltam felfogni és használni belőle :)

Ha már úgyis tanulási céllal csinálod az egészet magadnak, lehet annak lenne inkább értelme, hogy írj egy logger szervert, ami pl syslog (vagy egyéb) bemenetet dolgoz fel/dekorál és ír ki textbe. Akkor megjelenhetnek benne olyan mezők, amiket hiányolsz a syslogból, de az oprendszer tooljait se bukod. Cserébe lehet OOP-t, file kezelést, akár hálózatot is gyakorolni.
11

No várj, itt már nem az volt

mind1 valami név · 2019. Ápr. 3. (Sze), 05.47
No várj, itt már nem az volt a kérdés, hogy nekem megéri-e (kettővel feljebb beleírtam a kommentbe, hogy végül megtaláltam a text formátumú logok formázási lehetőségeit, szóval nekem már nincs szükségem rdbms-re)
Nálam csak azért jött elő, mert kb egy sor konfig módosítás és megkapok minden infót, amit úgy tűnt, textben nem tudok megszerezni.

MQ - nálunk DB2 volt alá tolva, de akkoriban nosql nem létezett, ellenben az adatbázis miatt nem volt performancia gondunk soha.

De pont amiket te is felsoroltál: szinte mindenhez illeszthető, fejlesztők is jobban ismerik, nem kell sokféle szoftvert üzemeltetni stb. azért még ma is hordoz épp elég előnyt.
12

Ma se keltem fel hiába. Úgy

mind1 valami név · 2020. Nov. 3. (K), 11.46
Ma se keltem fel hiába. Úgy két hónapja kerestem ezt a témát. Következetesen a prohardveren. :D

Így több, mint egy év távlatából elég ciki amiket ide írtam.
Logszervereken be lehet állítani, hogy miket akarok látni a logokban, szóval az hülyeség, hogy adatbázisba több info kerül.
És itt még rsyslogd-t emlegettem, azóta meg a nagyja syslog-ng alatt megy, amit doksi alapján tényleg úgy konfigurál az ember, ahogy szükséges (pythonban írt parsert is bele lehet tenni)
13

Nem ciki

Pepita · 2020. Nov. 4. (Sze), 09.50
Ugyan miért lenne ciki? Szerintem egyáltalán nem ciki, ha foglalkoztat egy probléma megoldása és a megoldáshoz vezető úton sokmindent megismersz - olyan dolgokat / technológiákat is, amik nem feltétlenül a legjobb eszközök az adott probléma megoldására.
Szerintem többen is tanultunk belőle és érdekes volt. Emiatt ez a téma nem lehet "ciki", szerintem inkább az a ciki, amikor valaki nem akar / tud tanulni, illetve ha másoktól várja a megoldást.
14

Ciki, hogy még mindig előbb

mind1 valami név · 2020. Nov. 4. (Sze), 10.09
Ciki, hogy még mindig előbb pofázok, utána olvasok, ha egyáltalán... :)
Kicsit beletúrtam volna a doksikba, akkor eleve másképp estem volna az egész témának.
Tíz év elteltével a napokban jöttem rá, hogy tképp a log szerverrel egy gépi feldolgozásra alkalmas formátumba kellene alakítani, ha mar úgyis a feldolgozhatóság a cél es akkor egy csomó dolgot nem kell szövegből kibányászni (program neve, időpontok stb)
15

notify - listen PostgreSQL-ben, nem jelent kockázatot?

mind1 valami név · 2020. Nov. 8. (V), 19.52
Valamit biztosan kihagyok a doksi nézegetése közben, de nem veszélyes játék ez a listen-notify páros?
Mintha bárki küldhetne értesítést az adatbázishoz kapcsolódó felhasználók közül, tetszőleges üzenettel (payload).
Nincs olyan, hogy létrehozok csatornát és jogot adok rá azoknak, akiknek engedni akarom, hogy elkapják az értesítéseket vagy küldjenek rá valamit.
Ezzel akár meg is lehet bolondítani a hallgatózó programokat.
16

Én ezt még a 7.3-al

kuka · 2020. Nov. 9. (H), 03.08
Én ezt még a 7.3-al használtam, ott a szintaxisa egyszerűbb volt, ami feltételezte, hogy a program úgyis utána kell nézzen a részleteknek, már ha van hozzá jogosultsága. Szerintem a cél csak a polling elkerülése volt, ezért nem bonyolították tovább. Bár így, hogy alapból 8000 byte adat is csapható az értesítésekhez, valóban lehet létjogosultsága valamilyen szabályozó mechanizmusnak.