Nestabilní vzdálená DB připojená přes FDW

Nestabilní vzdálená DB připojená přes FDW
« kdy: 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.


Re:Nestabilní vzdálená DB připojená přes FDW
« Odpověď #1 kdy: 14. 05. 2024, 11:18:25 »
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;

CPU

  • *****
  • 659
    • Zobrazit profil
    • E-mail
Re:Nestabilní vzdálená DB připojená přes FDW
« Odpověď #2 kdy: 14. 05. 2024, 12:15:24 »
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.

Re:Nestabilní vzdálená DB připojená přes FDW
« Odpověď #3 kdy: 14. 05. 2024, 14:06:09 »
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.

CPU

  • *****
  • 659
    • Zobrazit profil
    • E-mail
Re:Nestabilní vzdálená DB připojená přes FDW
« Odpověď #4 kdy: 14. 05. 2024, 20:40:57 »
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.


Re:Nestabilní vzdálená DB připojená přes FDW
« Odpověď #5 kdy: 15. 05. 2024, 22:32:02 »
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.

Re:Nestabilní vzdálená DB připojená přes FDW
« Odpověď #6 kdy: 16. 05. 2024, 12:24:09 »
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?

Re:Nestabilní vzdálená DB připojená přes FDW
« Odpověď #7 kdy: 16. 05. 2024, 14:27:29 »
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

CPU

  • *****
  • 659
    • Zobrazit profil
    • E-mail
Re:Nestabilní vzdálená DB připojená přes FDW
« Odpověď #8 kdy: 16. 05. 2024, 15:25:21 »

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.

Re:Nestabilní vzdálená DB připojená přes FDW
« Odpověď #9 kdy: 16. 05. 2024, 17:29:06 »

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.

luvar

  • ***
  • 232
    • Zobrazit profil
    • E-mail
Re:Nestabilní vzdálená DB připojená přes FDW
« Odpověď #10 kdy: 17. 05. 2024, 06:48:38 »
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.