Fórum Root.cz
Hlavní témata => Server => Téma založeno: Standa Blábol 14. 05. 2024, 10:19:28
-
Dotaz do think tanku.
Mam Postgres DB, v ni tabulku se seznamem devices.
K te tabulce pres LEFT JOIN pripojuju KPI indikatory ze vzdalene MySQL DB, pripojene pres FDW.
Funguje to pekne, kdyz vsak vzdalena MySQL lehne (neni to muj stroj), padne na hubu s exception i ten select s leftjoinovanyma KPIckama.
Existuje nejaka moznost, aby z pripade nedostupnosti MySQL se ona foreign table chovala jako prazdna, a proste to pres LEFT JOIN nevratilo nic a pouze data z moji postgres tabulky?
Dik za jakykoliv hint.
-
Tohle mi navrhla ChatGPT, napada nekoho neco lepsiho?
CREATE OR REPLACE FUNCTION get_devices_with_kpi()
RETURNS TABLE (
device_id INTEGER,
device_name VARCHAR(64),
kpi_id INTEGER,
kpi_name VARCHAR(64)
) AS
$$
BEGIN
BEGIN
RETURN QUERY
SELECT d.id AS device_id, d.name AS device_name,
k.id AS kpi_id, k.name AS kpi_name
FROM device d
LEFT JOIN kpi k ON d.id = k.id; -- Adjust the join condition as needed
EXCEPTION
WHEN SQLSTATE '08006' THEN -- Exception for network errors
-- Return left joined nulls as if "kpi" is empty
RETURN QUERY
SELECT d.id AS device_id, d.name AS device_name,
NULL AS kpi_id, NULL AS kpi_name
FROM device d;
END;
END;
$$ LANGUAGE plpgsql;
-
No a neměl bys lepší si podklady pro ten SELECT kopírovat k sobě?
Třeba jednou za minutu si data očmuchat a pokud se to nepovede, tak si to hodit do logu?
Já bych to tak asi udělal.
Sice se ti zvedne latence, ale nebude ti to padat.
-
Ta tabulka je velka a nechci to tahat k sobe.
Asi pouziju tu ChatGPT doporucenou variantu, v KPI chlivkach se ukaze N/A a spravte si to kkti.
-
Jako jo, protože tím kešováním si vytvoříš další problémy.
Na druhou stranu znám lidi a ti jsou schopný dokola divoce klikat, dokud tam nebudou hodnoty.
A další věc, možná by ses divil, co všechno se při joinech stejně přenáší.
Někdy může být řešení si udělat View, které počet položek omezí a nebo použít nějakou metodu replikace, což má zase jiné dopady.
-
Ta tabulka je velka a nechci to tahat k sobe.
Asi pouziju tu ChatGPT doporucenou variantu, v KPI chlivkach se ukaze N/A a spravte si to kkti.
Bacha, RETURN QUERY v plpgsql materializuje result - do work mem se kopiruje do paměti, nad se ukládá do dočasného souboru a pak z něj se zase vyčítá - má to výrazně vyšší režii než FDW - pro menší tabulky (do 10K řádků to bude v pohodě), ale pro větší nebo opravdu velké ta režie bude znát.
-
Ta tabulka je velka a nechci to tahat k sobe.
Asi pouziju tu ChatGPT doporucenou variantu, v KPI chlivkach se ukaze N/A a spravte si to kkti.
Bacha, RETURN QUERY v plpgsql materializuje result - do work mem se kopiruje do paměti, nad se ukládá do dočasného souboru a pak z něj se zase vyčítá - má to výrazně vyšší režii než FDW - pro menší tabulky (do 10K řádků to bude v pohodě), ale pro větší nebo opravdu velké ta režie bude znát.
Pokud spravne chapu dokumentaci, RETURN QUERY pripadne RETURN NEXT nejprve nasysli vsechna vystupni data a pakt teprve pusti uvolni funkci.
Tedy kdyz z obri tabulky moje funkce vytaha subset cca 1000 radku, onen temporary store bude odpovidat onem 1000 radkum a JDBC loop bude streamovat az nad tim predzvykanym defacto "materialized view"
Kdezto cisty FDW bude zasilat do JDBC stream, ktery si to bude postupne odebirat.
Chapu spravne?
-
Ta tabulka je velka a nechci to tahat k sobe.
Asi pouziju tu ChatGPT doporucenou variantu, v KPI chlivkach se ukaze N/A a spravte si to kkti.
Bacha, RETURN QUERY v plpgsql materializuje result - do work mem se kopiruje do paměti, nad se ukládá do dočasného souboru a pak z něj se zase vyčítá - má to výrazně vyšší režii než FDW - pro menší tabulky (do 10K řádků to bude v pohodě), ale pro větší nebo opravdu velké ta režie bude znát.
Pokud spravne chapu dokumentaci, RETURN QUERY pripadne RETURN NEXT nejprve nasysli vsechna vystupni data a pakt teprve pusti uvolni funkci.
Tedy kdyz z obri tabulky moje funkce vytaha subset cca 1000 radku, onen temporary store bude odpovidat onem 1000 radkum a JDBC loop bude streamovat az nad tim predzvykanym defacto "materialized view"
Kdezto cisty FDW bude zasilat do JDBC stream, ktery si to bude postupne odebirat.
Chapu spravne?
ano - FDW je průtokáč, řádek dostane, řádek pošle. Podobná věc by se dala napsat i v Céčkové extenzi, ne ale v PL/pgSQL
-
A jak byste to resil vy?
Resi se to ruzne, treba synchronizaci do jine "pidi" databaze a replikaci cele takove male databaze. Cachovanim view? Jen FDW a nechat to failovat -> N/A?
Mam par projektu a zadne genialni reseni jsem nevidel.
-
A jak byste to resil vy?
Resi se to ruzne, treba synchronizaci do jine "pidi" databaze a replikaci cele takove male databaze. Cachovanim view? Jen FDW a nechat to failovat -> N/A?
Mam par projektu a zadne genialni reseni jsem nevidel.
Tam geniální řešení nevidím - spíš vidím chybu v zadání. Buďto mám data stažená lokálně - třeba nějakou agregaci nebo vyhodím fail. Případně, pokud mi failuje FDW, tak udělat retry a provést dotaz bez failujícího fdw, a neobalovat to uloženou procedurou - to mi přijde jako prasárna. Uložené procedury jsou super, ale neměly by se zneužívat k maskování chyb.
Neznám prostředí ve kterém se pohybujete, takže nemám anunk jestli je rozumné ignorovat chyby nebo ne - to neumím posoudit. Moje zkušenost je taková, že buďto chybu dokážu obsloužit bez ztráty dat - nějakou fault tolerant technikou nebo vyhodím chybu. Tiché maskování chyb je většinou zlo, minimálně prasečina, která se vrátí. Pak něco vyhnije a vy (nebo někdo jiný) si toho vůbec nevšimne, a je z toho větší průser.
-
Integracie cez databazu byvaju casto nestastne riesenia (ak nie vzdy).
Ak je moznost zadat do vlastneho riesenia poziadavku (requirement) na dodavanie danych informacii v nejakej forme, tak by som to skusil a druhej strane poslal ako jednu z moznosti projekt https://debezium.io/ . Dokaze sa pripojit na db a "streamovat" vsetky zmeny z nejakej tabulky smerom k vasemu systemu. Osobne mam skusenost len v kombinacii s Postgresql a kafka. Tam sa to tvarilo akokeby dalsi postgresql replikacny klient.
Pripadne si popytat nejake rozumne API pre Vase pouzitie, ktore by vedelo vratit potrebne info na poziadanie.
PS: Synchronizacia cudzej tabulky do lokalnej DB bola spomenuta ako nevhodne riesenie kvoli velkosti. Nebolo by mozne obmedzit velkost a synchronizovat dopredu tabulku s vylucenim riadkov, ktore nebudu urcite potrebne?
PS2: Nedosupnost cudzej DB nemusi byt vzdy len chyba prevadzkovatela danej DB... Stale tu su veci "po ceste" a aj vas lokalny OS sa moze pricinit o nedostupnost cudzieho systemu.