Megnézzük, hogyan működik a Zabbix a TimescaleDB adatbázissal mint háttérrendszerrel. Megmutatjuk, hogyan kezdje el a nulláról, és hogyan térjen át a PostgreSQL-ről. Összehasonlító teljesítményteszteket is biztosítunk a két konfigurációhoz.
HighLoad++ Szibéria 2019. Tomszk Hall. június 24., 16:00. Tézisek és . A következő HighLoad++ konferenciát 6. április 7-án és 2020-én tartják Szentpéterváron. Részletek és jegyek .
Andrey Gushchin (a továbbiakban – AG): – A ZABBIX műszaki támogatási mérnöke (a továbbiakban: „Zabbix”), oktató vagyok. Több mint 6 éve dolgozom műszaki támogatásban, és közvetlen tapasztalatom van a teljesítményről. Ma arról fogok beszélni, hogy a TimescaleDB milyen teljesítményt tud nyújtani a szokásos PostgreSQL 10-hez képest. Valamint néhány bevezető rész arról, hogyan működik általában.
A legnagyobb termelékenységi kihívások: az adatgyűjtéstől az adattisztításig
Először is, vannak bizonyos teljesítménybeli kihívások, amelyekkel minden megfigyelő rendszer szembesül. Az első termelékenységi kihívás az adatok gyors összegyűjtése és feldolgozása.
Egy jó felügyeleti rendszernek gyorsan, időben kell fogadnia minden adatot, trigger kifejezések szerint feldolgozni, azaz bizonyos kritériumok szerint feldolgozni (ez a különböző rendszerekben eltérő), és adatbázisba kell mentenie, hogy ezeket az adatokat felhasználhassa a jövő.
A második teljesítmény kihívás az előzmények tárolása. Gyakran tároljon adatbázisban, és gyorsan és kényelmesen hozzáférjen ezekhez a mérőszámokhoz, amelyeket egy bizonyos időszak alatt gyűjtöttek össze. A legfontosabb, hogy ezeket az adatokat kényelmesen lehessen megszerezni, felhasználni jelentésekben, grafikonokban, triggerekben, bizonyos küszöbértékekben, riasztásokhoz stb.
A harmadik teljesítménybeli kihívás az előzmények törlése, vagyis amikor eljutunk odáig, hogy nem kell 5 év (akár hónap vagy két hónap) alatt gyűjtött részletes mérőszámokat tárolni. Egyes hálózati csomópontok vagy gazdagépek törölve lettek, a metrikákra már nincs szükség, mert már elavultak, és már nem gyűjtik őket. Mindezt ki kell tisztítani, hogy az adatbázisunk ne nőjön túl nagyra. Általánosságban elmondható, hogy az előzmények törlése leggyakrabban komoly próbát jelent a tároló számára - gyakran nagyon erős hatással van a teljesítményre.
Hogyan lehet megoldani a gyorsítótárazási problémákat?
Most konkrétan a Zabbixról fogok beszélni. A Zabbixban az első és a második hívást gyorsítótárazással oldják meg.
Adatgyűjtés és -feldolgozás – RAM-ot használunk az adatok tárolására. Ezeket az adatokat most részletesebben tárgyaljuk.
Az adatbázis oldalán is található néhány gyorsítótár a főbb kijelölésekhez - grafikonokhoz és egyéb dolgokhoz.
Gyorsítótár a Zabbix szerver oldalán: van ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Ami?
A ConfigurationCache a fő gyorsítótár, amelyben mérőszámokat, gazdagépeket, adatelemeket, triggereket tárolunk; mindent, ami az előfeldolgozás feldolgozásához, adatgyűjtéshez kell, mely gépekről, milyen gyakorisággal kell gyűjteni. Mindezt a ConfigurationCache tárolja, hogy ne menjen az adatbázisba és ne hozzon létre szükségtelen lekérdezéseket. A szerver indulása után frissítjük ezt a gyorsítótárat (létrehozzuk), és rendszeresen frissítjük (a konfigurációs beállításoktól függően).
Gyorsítótár a Zabbixban. Adatgyűjtés
Itt a diagram elég nagy:
A rendszerben a főbbek ezek a gyűjtők:
Ezek maguk az összeszerelési folyamatok, különféle „pollerek”, amelyek a különböző típusú összeszerelésekért felelősek. Adatokat gyűjtenek icmp-n, ipmi-n és különféle protokollokon keresztül, és mindezt az előfeldolgozásba továbbítják.
Előfeldolgozás HistoryCache
Továbbá, ha vannak számított adatelemeink (a Zabbix-ot ismerők tudják), azaz számított, összesített adatelemeink, akkor közvetlenül a ValueCache-ből vesszük azokat. Később elmondom, hogyan kell kitölteni. Mindezek a gyűjtők a ConfigurationCache segítségével fogadják a munkáikat, majd továbbítják azokat az előfeldolgozáshoz.
Az előfeldolgozás a ConfigurationCache-t is használja az előfeldolgozási lépések lekérésére, és különféle módokon dolgozza fel ezeket az adatokat. A 4.2-es verziótól kezdve proxyra helyeztük át. Ez nagyon kényelmes, mert maga az előfeldolgozás meglehetősen nehéz művelet. És ha nagyon nagy Zabbixed van, nagy számú adatelemmel és magas gyűjtési gyakorisággal, akkor ez nagyban leegyszerűsíti a munkát.
Ennek megfelelően, miután ezeket az adatokat valamilyen módon előfeldolgozással feldolgoztuk, a HistoryCache-be mentjük a további feldolgozás érdekében. Ezzel az adatgyűjtés véget ért. Továbblépünk a fő folyamatra.
A történelem szinkronizáló munkája
A Zabbix fő folyamata (mivel ez egy monolitikus architektúra) a History syncer. Ez a fő folyamat, amely kifejezetten az egyes adatelemek, azaz minden egyes érték atomi feldolgozásával foglalkozik:
- jön az érték (a HistoryCache-ből veszi);
- ellenőrzi a Konfigurációs szinkronizálóban: vannak-e triggerek a számításhoz - kiszámítja azokat;
ha van - eseményeket hoz létre, eszkalációt hoz létre riasztás létrehozása érdekében, ha szükséges a konfigurációnak megfelelően; - rögzíti a triggereket a későbbi feldolgozáshoz, összesítéshez; ha az elmúlt órában összesít, és így tovább, a ValueCache megjegyzi ezt az értéket, hogy ne kerüljön az előzmények táblájába; Így a ValueCache feltöltődik a szükséges adatokkal, amelyek a triggerek, számított elemek stb. kiszámításához szükségesek;
- majd a History syncer minden adatot az adatbázisba ír;
- az adatbázis lemezre írja őket – itt ér véget a feldolgozási folyamat.
Adatbázis. Gyorsítótárazás
Az adatbázis oldalon különféle gyorsítótárak találhatók, amikor grafikonokat vagy jelentéseket szeretne megtekinteni az eseményekről. De ebben a jelentésben nem beszélek róluk.
A MySQL-hez van Innodb_buffer_pool, és egy csomó különböző gyorsítótár, amelyek szintén konfigurálhatók.
De ezek a főbbek:
- megosztott_pufferek;
- hatékony_gyorsítótár mérete;
- megosztott_pool.
Minden adatbázis esetében elmondtam, hogy vannak bizonyos gyorsítótárak, amelyek lehetővé teszik a lekérdezéshez gyakran szükséges adatok RAM-ban történő tárolását. Ehhez saját technológiájuk van.
Az adatbázis teljesítményéről
Ennek megfelelően versenykörnyezet van, vagyis a Zabbix szerver adatokat gyűjt és rögzít. Újraindításkor az előzményekből is beolvas, hogy kitöltse a ValueCache-t és így tovább. Itt lehetnek olyan szkriptek és jelentések, amelyek a webes felületre épülő Zabbix API-t használják. A Zabbix API belép az adatbázisba, és megkapja a szükséges adatokat grafikonok, jelentések, vagy valamilyen eseménylista, közelmúltbeli problémák lekéréséhez.
Szintén nagyon népszerű vizualizációs megoldás a Grafana, amelyet felhasználóink használnak. Képes közvetlenül bejelentkezni a Zabbix API-n és az adatbázison keresztül egyaránt. Ez bizonyos versenyt is teremt az adatok megszerzésében: az adatbázis finomabb, jobb hangolása szükséges ahhoz, hogy megfeleljen az eredmények gyors eljuttatásának és a tesztelésnek.
Előzmények törlése. Zabbixnek házvezetőnője van
A harmadik hívás, amelyet a Zabbix használ, az előzmények törlése a Housekeeper segítségével. A Housekeeper minden beállítást követ, vagyis az adatelemeink jelzik, hogy mennyi ideig tároljuk (napokban), meddig tároljuk a trendeket, illetve a változások dinamikáját.
Nem beszéltem a TrendCache-ről, amit menet közben számolunk: megérkeznek az adatok, egy órára összesítjük (ezek többnyire az utolsó órára vonatkozó számok), a mennyiség átlagos/minimális és óránként egyszer rögzítjük a táblázat a változások dinamikájáról („Trendek”) . A „Housekeeper” rendszeres kiválasztással elindítja és törli az adatokat az adatbázisból, ami nem mindig hatékony.
Hogyan lehet megérteni, hogy hatástalan? A belső folyamatok teljesítménygrafikonjain az alábbi kép látható:
Az előzmények szinkronizálója folyamatosan foglalt (piros grafikon). És a „piros” grafikon, ami a tetején megy. Ez egy „házvezető”, amely elindul, és várja, hogy az adatbázis törölje az összes megadott sort.
Vegyünk valami tételazonosítót: törölni kell az utolsó 5 ezret; természetesen indexek szerint. De általában az adatkészlet meglehetősen nagy - az adatbázis továbbra is beolvassa a lemezről, és a gyorsítótárba helyezi, és ez nagyon költséges művelet az adatbázis számára. Méretétől függően ez bizonyos teljesítményproblémákhoz vezethet.
A Housekeepert egyszerűen letilthatja – ismerős webes felületünk van. Az Adminisztráció általános beállításai (beállítások a „Housekeeper”-hez) letiltjuk a belső házvezetést a belső előzmények és trendek miatt. Ennek megfelelően a Housekeeper már nem ellenőrzi ezt:
Mit tehetsz ezután? Kikapcsoltad, a grafikonjaid kiegyenlítettek... Milyen további problémák merülhetnek fel ebben az esetben? Mi segíthet?
Partícionálás (szakaszolás)
Ez általában minden felsorolt relációs adatbázisban eltérő módon van beállítva. A MySQL-nek saját technológiája van. De összességében nagyon hasonlítanak a PostgreSQL 10-re és a MySQL-re. Természetesen sok belső különbség van a megvalósításban, és mindez hogyan befolyásolja a teljesítményt. Általában azonban egy új partíció létrehozása gyakran bizonyos problémákhoz is vezet.
A beállítástól függően (mennyi adatot hoz létre egy nap alatt) általában beállítják a minimumot - ez 1 nap / köteg, és a „trendek”, a változások dinamikája esetén - 1 hónap / új köteg. Ez változhat, ha nagyon nagy a beállítás.
Mondjuk rögtön a beállítás méretéről: akár 5 ezer új érték másodpercenként (úgynevezett nvps) - ez egy kis „beállításnak” tekinthető. Átlagos - 5-25 ezer érték másodpercenként. A fentiek már csak nagy és nagyon nagy telepítések, amelyek az adatbázis nagyon gondos beállítását igénylik.
Nagyon nagy telepítéseknél előfordulhat, hogy 1 nap nem optimális. Én személy szerint napi 40 gigabájt partíciókat láttam a MySQL-en (és lehet, hogy több is van). Ez nagyon nagy mennyiségű adat, ami problémákhoz vezethet. Csökkenteni kell.
Miért van szükség particionálásra?
Amit a Partitioning nyújt, azt hiszem, mindenki tudja, az az asztali particionálás. Ezek gyakran külön fájlok a lemezen és a span kérések. Egy partíciót választ ki optimálisabban, ha az a normál particionálás része.
Konkrétan a Zabbix esetében tartományonként, tartományonként használják, vagyis időbélyeget használunk (szabályos szám, a korszak kezdete óta eltelt idő). Megadja a nap kezdetét/végét, és ez a partíció. Ennek megfelelően, ha két napos adatokat kérünk, akkor minden gyorsabban lekerül az adatbázisból, mert csak egy fájlt kell betölteni a gyorsítótárba és visszaküldeni (nem egy nagy táblát).
Sok adatbázis felgyorsítja a beszúrást (egy gyermektáblába való beillesztést). Egyelőre elvontan beszélek, de ez is lehetséges. A partitonálás gyakran segít.
Elasticsearch a NoSQL-hez
Nemrég, a 3.4-ben implementáltunk egy NoSQL megoldást. Hozzáadtuk az Elasticsearch-ben való írás képességét. Írhat bizonyos típusokat: Ön választja - vagy írjon számokat vagy néhány jelet; sztring szövegünk van, az Elasticsearch-ba naplókat írhat... Ennek megfelelően a webes felület is eléri az Elasticsearch-et. Ez bizonyos esetekben kiválóan működik, de jelenleg használható.
TimescaleDB. Hypertables
A 4.4.2 esetében egy dologra figyeltünk, például a TimescaleDB-re. Ami? Ez a PostgreSQL kiterjesztése, vagyis natív PostgreSQL felülettel rendelkezik. Ráadásul ez a kiterjesztés lehetővé teszi, hogy sokkal hatékonyabban dolgozzon az idősorok adataival, és automatikus particionálást is biztosítson. Hogy néz ki:
Ez hipertable – van ilyen fogalom az Időskálában. Ez egy hipertábla, amelyet Ön hoz létre, és darabokat tartalmaz. A darabok partíciók, ezek gyerektáblák, ha nem tévedek. Tényleg hatásos.
TimescaleDB és PostgreSQL
Ahogy a TimescaleDB gyártói biztosítják, korrektebb algoritmust használnak a lekérdezések, különösen a beillesztések feldolgozására, ami lehetővé teszi számukra, hogy hozzávetőlegesen állandó teljesítményt nyújtsanak az adatkészlet beillesztésének növekvő méretével. Vagyis 200 millió Postgres-sor után a szokásos nagyon megereszkedik, és szó szerint nullára veszíti a teljesítményét, míg a Timescale lehetővé teszi, hogy bármilyen adatmennyiséggel a lehető leghatékonyabban illessze be a beszúrásokat.
Hogyan kell telepíteni a TimescaleDB-t? Ez egyszerű!
Benne van a dokumentációban, le van írva - bármilyen csomagból telepítheti... Ez a hivatalos Postgres csomagoktól függ. Manuálisan összeállítható. Így esett, hogy az adatbázishoz kellett fordítanom.
A Zabbix-on egyszerűen aktiváljuk a kiterjesztést. Szerintem azok, akik a Postgres-ben az Extention-t használták... Egyszerűen aktiválja az Extention-t, létrehozza a használt Zabbix adatbázishoz.
És az utolsó lépés...
TimescaleDB. Történeti táblák vándorlása
Létre kell hoznia egy hipertáblát. Ehhez van egy speciális funkció – Hypertable létrehozása. Ebben az első paraméter az ebben az adatbázisban szükséges tábla (amelyhez hipertáblát kell létrehozni).
A mező, amellyel létre kell hozni, és a chunk_time_interval (ez a darabok (használandó partíciók) intervalluma). 86 400 egy nap.
Migrate_data paraméter: Ha beszúrja a true értéket, akkor ez az összes aktuális adatot előre létrehozott darabokba migrálja.
Magam is használtam a migrate_data-t – elég sok időt vesz igénybe, attól függően, hogy mekkora az adatbázis. Több mint egy terabájtom volt – több mint egy órát vett igénybe a létrehozás. Egyes esetekben a tesztelés során töröltem a szöveg (history_text) és a karakterlánc (history_str) előzményadatait, hogy ne vigyem át őket - nem igazán voltak érdekesek számomra.
Az utolsó frissítést a db_extention-ben végezzük: telepítjük a timescaledb-t, hogy az adatbázis és különösen a Zabbix megértse, hogy létezik db_extention. Aktiválja, és a megfelelő szintaxist és lekérdezéseket használja az adatbázishoz, a TimescaleDB számára szükséges „szolgáltatások” használatával.
Szerver konfigurációja
Két szervert használtam. Az első szerver egy meglehetősen kicsi virtuális gép, 20 processzorral, 16 gigabájt RAM-mal. A Postgres 10.8-at konfiguráltam rajta:
Az operációs rendszer Debian, a fájlrendszer xfs volt. Minimális beállításokat végeztem az adott adatbázis használatához, leszámítva azt, amit maga a Zabbix fog használni. Ugyanazon a gépen volt egy Zabbix szerver, PostgreSQL és betöltési ügynökök.
50 olyan aktív ügynököt használtam, amelyek a LoadableModule segítségével gyorsan különböző eredményeket generálnak. Ők azok, akik létrehozták a karakterláncokat, számokat és így tovább. Nagyon sok adattal töltöttem fel az adatbázist. Kezdetben a konfiguráció állomásonként 5 ezer adatelemet tartalmazott, és hozzávetőlegesen minden adatelem tartalmazott egy triggert - annak érdekében, hogy ez valódi beállítás legyen. Néha több trigger is kell a használatához.
A frissítési intervallumot és magát a betöltést nem csak 50 ügynök felhasználásával (több hozzáadásával), hanem dinamikus adatelemekkel is szabályoztam, és a frissítési intervallumot 4 másodpercre csökkentettem.
Teljesítményteszt. PostgreSQL: 36 ezer NVP
Az első indítás, az első beállítás tiszta PostreSQL 10-en volt ezen a hardveren (35 ezer érték másodpercenként). Általában, amint a képernyőn látható, az adatok beillesztése a másodperc töredékeibe telik - minden jó és gyors, SSD meghajtók (200 gigabájt). Az egyetlen dolog, hogy a 20 GB elég gyorsan megtelik.
A jövőben elég sok ilyen grafikon lesz. Ez egy szabványos Zabbix szerver teljesítmény-műszerfal.
Az első grafikon a másodpercenkénti értékek száma (kék, bal felső), ebben az esetben 35 ezer érték. Ez (fent középen) a build folyamatok betöltése, ez pedig (jobbra fent) a belső folyamatok betöltése: a történelem szinkronizálók és a housekeeper, ami itt (alul középen) már jó ideje fut.
Ez a grafikon (alul, középen) mutatja a ValueCache használatát – hány ValueCache-találat az aktiválókhoz (több ezer érték másodpercenként). Egy másik fontos grafikon a negyedik (balra lent), amely a HistoryCache használatát mutatja, amiről beszéltem, ami egy puffer az adatbázisba való beillesztés előtt.
Teljesítményteszt. PostgreSQL: 50 ezer NVP
Ezután a terhelést másodpercenként 50 ezer értékre növeltem ugyanazon a hardveren. A Housekeeper betöltésekor 10-2 másodperc alatt 3 ezer értéket rögzítettek számítással. Ami valójában látható a következő képernyőképen:
A „házvezetőnő” már kezdi zavarni a munkát, de általában véve a történelem-süllyesztő csapdák terhelése még mindig 60% (harmadik grafikon, jobbra fent). A HistoryCache már aktívan töltődik, miközben a Housekeeper fut (balra lent). Körülbelül fél gigabájt volt, 20%-a megtelt.
Teljesítményteszt. PostgreSQL: 80 ezer NVP
Aztán megnöveltem másodpercenként 80 ezer értékre:
Körülbelül 400 ezer adatelemről, 280 ezer triggerről volt szó. A betét, mint látható, a történelemsüllyesztők (30 db volt) terhelését tekintve már elég magas volt. Aztán megnöveltem a különféle paramétereket: előzménysüllyesztők, gyorsítótár... Ezen a hardveren az előzménysüllyesztők terhelése a maximumra kezdett nőni, szinte „a polcon” - ennek megfelelően a HistoryCache nagyon nagy terhelésbe került:
Ezalatt az összes rendszerparamétert figyeltem (a processzor használatának módja, RAM), és azt tapasztaltam, hogy a lemezkihasználás maximális volt - ezen a hardveren, ezen a virtuális gépen elértem a lemez maximális kapacitását. A "Postgres" ilyen intenzitással elkezdett elég aktívan kiíratni az adatokat, és a lemeznek már nem volt ideje írni, olvasni...
Vettem egy másik szervert, amelyen már 48 processzor és 128 gigabájt RAM volt:
Én is "hangoltam" - telepítettem a History syncert (60 db) és elfogadható teljesítményt értem el. Valójában nem vagyunk „a polcon”, de valószínűleg ez a termelékenység határa, ahol már tenni kell valamit.
Teljesítményteszt. TimescaleDB: 80 ezer NVP
A fő feladatom a TimescaleDB használata volt. Minden grafikon egy zuhanást mutat:
Ezek a hibák pontosan az adatmigrációt jelentik. Ezt követően a Zabbix szerveren az előzménysüllyesztők betöltési profilja, mint látható, sokat változott. Lehetővé teszi az adatok közel 3-szor gyorsabb beszúrását és kevesebb HistoryCache használatát – ennek megfelelően az adatok időben kézbesítve lesznek. A másodpercenkénti 80 ezer érték ismét meglehetősen magas arány (természetesen nem a Yandex esetében). Összességében ez egy meglehetősen nagy beállítás, egyetlen szerverrel.
PostgreSQL teljesítményteszt: 120 ezer NVP
Ezután az adatelemek számának értékét félmillióra növeltem, és 125 ezer másodpercenkénti számított értéket kaptam:
És ezeket a grafikonokat kaptam:
Elvileg ez egy működő beállítás, elég sokáig működhet. De mivel csak 1,5 terabájtos lemezem volt, pár nap alatt elhasználtam. A legfontosabb dolog az, hogy ezzel egy időben új partíciók jöttek létre a TimescaleDB-n, és ez teljesen észrevétlen volt a teljesítmény szempontjából, ami a MySQL-ről nem mondható el.
A partíciók általában éjszaka jönnek létre, mert ez általában blokkolja a beillesztést és a táblákkal való munkát, és a szolgáltatás leromlásához vezethet. Ebben az esetben ez nem így van! A fő feladat a TimescaleDB képességeinek tesztelése volt. Az eredmény a következő: 120 ezer érték másodpercenként.
A közösségben is vannak példák:
A személy bekapcsolta a TimescaleDB-t is, és az io.weight használatával járó terhelés csökkent a processzoron; és a belső folyamatelemek használata is csökkent a TimescaleDB bevonása miatt. Ráadásul ezek közönséges palacsintalemezek, vagyis egy közönséges virtuális gép közönséges lemezeken (nem SSD-ken)!
Néhány kisebb beállításnál, amelyeket a lemez teljesítménye korlátoz, a TimescaleDB véleményem szerint nagyon jó megoldás. Lehetővé teszi a munka folytatását, mielőtt az adatbázis gyorsabb hardverére költözne.
Mindenkit meghívok rendezvényeinkre: konferencia Moszkvában, csúcstalálkozó Rigában. Használja csatornáinkat - Telegram, fórum, IRC. Ha kérdése van, jöjjön el asztalunkhoz, mindent megbeszélünk.
Közönségkérdések
Kérdés a közönségtől (továbbiakban - A): - Ha a TimescaleDB ilyen könnyen konfigurálható, és ilyen teljesítménynövekedést ad, akkor talán ezt kellene bevált módszerként használni a Zabbix és a Postgres konfigurálásához? És vannak-e buktatói és hátrányai ennek a megoldásnak, vagy végül is, ha úgy döntöttem, hogy Zabbix-ot készítek magamnak, könnyen elvihetem a Postgrest, azonnal telepíthetem a Timescale-t, használhatom, és nem gondolok semmiféle problémára?
AG: – Igen, azt mondanám, hogy ez egy jó javaslat: azonnal használja a Postgres-t a TimescaleDB kiterjesztéssel. Mint már mondtam, sok jó vélemény, annak ellenére, hogy ez a „funkció” kísérleti jellegű. De valójában a tesztek azt mutatják, hogy ez egy nagyszerű megoldás (a TimescaleDB-vel), és azt hiszem, hogy fejlődni fog! Figyeljük a bővítmény fejlődését, és szükség szerint módosítjuk.
Már a fejlesztés során is az egyik jól ismert „tulajdonságukra” hagyatkoztunk: a darabokkal kicsit másképp lehetett dolgozni. De aztán a következő kiadásban kivágták, és fel kellett hagynunk ezzel a kóddal. Javaslom ennek a megoldásnak a használatát számos beállításnál. Ha MySQL-t használsz... Átlagos beállításoknál minden megoldás jól működik.
és: – A közösség utolsó grafikonjain volt egy grafikon a „házvezetőnő” felirattal:
Folytatta a munkát. Mit csinál a házvezetőnő a TimescaleDB-vel?
AG: – Most nem tudok biztosat mondani – megnézem a kódot, és elmondom részletesebben. A TimescaleDB lekérdezéseket nem a darabok törlésére használja, hanem valamilyen módon összesíti azokat. Még nem állok készen erre a technikai kérdésre. Ma vagy holnap többet megtudunk a standon.
és: – Hasonló kérdésem lenne – a törlési művelet végrehajtásával kapcsolatban az Időskálában.
A (válasz a közönségtől): – Amikor adatokat töröl egy táblázatból, ha törléssel teszi, akkor végig kell mennie a táblázaton - törölni, tisztítani, mindent megjelölni a jövőbeni vákuum érdekében. Az Időskálában, mivel vannak darabjai, eldobhatja. Durván szólva, egyszerűen azt mondod a nagy adatban lévő fájlnak: „Törlés!”
Az időskála egyszerűen megérti, hogy ilyen darab már nem létezik. És mivel be van építve a lekérdezéstervezőbe, horgokat használ, hogy elkapja a feltételeket a kiválasztott vagy más műveletekben, és azonnal megérti, hogy ez a darab már nem létezik – „Oda többé nem megyek!” (az adatok nem állnak rendelkezésre). Ez minden! Vagyis a táblázatvizsgálatot felváltja a bináris fájl törlése, tehát gyors.
és: – A nem SQL témáját már érintettük. Amennyire én értem, a Zabbixnak nem igazán kell módosítania az adatokat, és mindez olyan, mint egy napló. Lehetséges olyan speciális adatbázisokat használni, amelyek nem tudják megváltoztatni az adataikat, ugyanakkor sokkal gyorsabban mentik, felhalmozzák, terjesztik - Clickhouse például valami Kafka-szerű?.. A Kafka is napló! Lehetséges valahogyan integrálni őket?
AG: - A kirakodás megoldható. Van egy bizonyos „funkciónk” a 3.4-es verzió óta: minden történelmi fájlt, eseményt, minden mást fájlba írhat; majd elküldi bármely más adatbázisba valamilyen kezelő segítségével. Valójában sokan átdolgozzák és közvetlenül az adatbázisba írnak. Menet közben a történelemsüllyesztők mindezt fájlokba írják, elforgatják ezeket a fájlokat és így tovább, és átviheted a Clickhouse-ba. A tervekről nem tudok nyilatkozni, de talán folytatódik a NoSQL-megoldások (például a Clickhouse) további támogatása.
és: – Általánosságban kiderül, hogy teljesen megszabadulhatsz a postgres-től?
AG: – Természetesen a Zabbixban a legnehezebb része a történelmi táblák, amelyek a legtöbb problémát és eseményeket okozzák. Ebben az esetben, ha az eseményeket nem tárolja sokáig, és az előzményeket a trendekkel együtt valamilyen más gyorstárhelyen tárolja, akkor általában úgy gondolom, hogy nem lesz probléma.
és: – Meg tudja becsülni, mennyivel fog gyorsabban minden működni, ha például a Clickhouse-ra vált?
AG: - Nem teszteltem. Azt gondolom, hogy legalább ugyanezeket a számokat egészen egyszerűen el lehet érni, tekintve, hogy a Clickhouse saját felülettel rendelkezik, de biztosat nem tudok mondani. Jobb tesztelni. Minden a konfigurációtól függ: hány gazdagéped van, és így tovább. A beszúrás egy dolog, de ezeket az adatokat is le kell kérni - Grafana vagy valami más.
és: – Tehát egyenlő küzdelemről beszélünk, és nem ezeknek a gyors adatbázisoknak a nagy előnyéről?
AG: – Szerintem, ha integráljuk, pontosabb tesztek lesznek.
és: – Hová tűnt a jó öreg RRD? Mi késztetett arra, hogy SQL adatbázisokra válts? Kezdetben az összes mérőszámot az RRD-n gyűjtötték össze.
AG: – Zabbixnak volt RRD-je, talán egy nagyon ősi változatban. Mindig is voltak SQL adatbázisok – klasszikus megközelítés. A klasszikus megközelítés a MySQL, PostgreSQL (ezek nagyon régóta léteznek). Szinte soha nem használtunk közös felületet az SQL és RRD adatbázisokhoz.
Néhány hirdetés 🙂
Köszönjük, hogy velünk tartott. Tetszenek cikkeink? További érdekes tartalmakat szeretne látni? Támogass minket rendeléssel vagy ajánlj ismerőseidnek, , a belépő szintű szerverek egyedülálló analógja, amelyet mi találtunk ki Önnek: (RAID1 és RAID10, akár 24 maggal és akár 40 GB DDR4-gyel is elérhető).
A Dell R730xd kétszer olcsóbb az amszterdami Equinix Tier IV adatközpontban? Csak itt Hollandiában! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 dollártól! Olvasni valamiről
Forrás: will.com