Használom az InfluxDB-t és kíváncsian várom az alább írt 2.0 nyelvezetét.
https://www.influxdata.com/blog/why-were-building-flux-a-new-data-scripting-and-query-language/
https://www.influxdata.com/blog/why-were-building-flux-a-new-data-scripting-and-query-language/
Mesélsz róla kicsit?
VálaszTörlésPersze, szívesen. Van egy halom adatod, ami nagyon sűrű adatfolyamban jön létre. Ezt letárolod valami olyan adatbázisban, mely kifejezetten a gyors és nagy mennyiségű tárolásra alkalmas. Aztán fogod ezeket az adatokat és konszolidálod, pl. leindexeled órás vagy napi adatsorra. Ezt már egész jól lehet kezelni SQL alatt is. Aztán elérkezel egy pontra, mikor rohadt macerás lesz a különböző metrikák közötti értékváltozások viszonyainak valami egyéb viszonyát összevetni, mert lesz egy olyan rohadt bonyolult SQL lekérdezésed, hogy a legközelebbi módosításnál már nem hogy nem tekinted át könnyen, vagy más valaki, de sok lesz benne a hibalehetőség is. Erre találták ki az olyan adatbázisokat, mint az Influx, mely úgynevezett timeseries, azaz "az első oszlopban" mindig ott az idő. Az Influx kifejezetten arra alkalmas, hogy időben változó értékeket rögzíts és olvass ki belőle, legyen az hőmérséklet, kattintás, forint, stb... Aztán ezekhez nem túl nagy számban, de címkéket rendelhetsz. Túl sokat nem, mert nem erre való. Így mondjuk (példa) könyvenként minden könyv szavának olvasottságát nem jó Influxban tárolni, de mondjuk a lapok számának lapozásszámát könyvtípusonként még jól lehet kezelni. Az Influx abban is rugalmas, hogy mondjuk az órás adathalmazból könnyen elkészítve olyan automatikus lekérdezéseket indíts, mely a 10 perces adathalmazból óránként készít egy napi kumulált adatsort, és az 1 hónapnál régebbi részletes adatokat már kukázza. Ezeket brutálisan egyszerűen és kényelmesen meg lehet vele oldani. Ezt SQL-ben már macerás.
VálaszTörlésNa, és akkor jön az, hogy kéne egy olyan lekérdezés Influxban, hogy a 4 hetes mozgó átlag arányosítva a másik adatsor értékváltozásaival, meg valami hülye matek még. Ezt nem tudja. Erre jó az SQL. De az SQL rohadt bonyolult szintaxissal dolgozik.
A fulx 2.0 arra készül, hogy egy olyan adatleíró nyelvet adjon, mely a javascript egyszerűsített szintaxisával adja az Influx egyszerűségét, és az SQL nyelvek komplexitását.
Nagyon elnagyolva írtam le, mert inkább egy lelkes felhasználója vagyok az adatbázisoknak, egy olyan termékfelelős, aki képes egy SELECT FROM LEFT JOIN megírására, hogy az üzleti célokhoz vezető utat konszolidált grafikonokkal töltse meg. XD Így a fogalmakat lehet, hogy nem jól használom.
Egyébként döbbenetesen jól fordítja a Google Translate a cikket. Tök érthető azoknak is, akik adatgazdák, de nem angoloznak annyira jól.
VálaszTörlésKöszönöm! Lett valami fogalmam arról mi is ez, és mire jó. Érthető volt a magyarázat.
VálaszTörlésEgyébként olyan működés esetén érdekes ez, ahol napi rutin egy új lekérdezés megfogalmazása. Ott ahol semmi sem változik a riportokon, ott egyszer elkészítik, azt annyi, mindegy hogy nem szép, csak az elvárt sebességgel működjön. Nálunk napi több riport is készül, nagyon sok az adat, és mint mindenhol, kevés az ember. Így nem mindegy, hogy a riport milyen gyorsan készül el, mennyire biztos, hogy a riport jó, stb...
VálaszTörlés