Data z vlastního PostgreSQL systému v Microsoft Fabric, propojená s marketingem i účetnictvím

Na co si dát pozor

PostgreSQL není packaged platforma s daným schématem, je to obecná databáze, na které si každá firma postavila vlastní e-shop nebo systém po svém. To má přímý dopad na to, jak napojení vzniká, a proč u něj neexistuje jeden univerzální konektor jako u krabicových řešení.

• Čtení nesmí zatěžovat živý provoz

  Přímé těžké dotazy na produkční databázi mohou zpomalit checkout nebo příjem objednávek. Napojení proto typicky čte přes read repliku, nebo přes logickou replikaci, která čte změny přímo z WAL (write-ahead logu) pomocí replikačního slotu a umožňuje sledovat jen vybrané tabulky, ne celou databázi jako fyzická replika.

• Žádné standardní schéma

  Struktura vlastní databáze je unikátní pro každý projekt, není tam žádné dané schéma jako u packaged platformy. Napojení proto vždy začíná zmapováním konkrétních tabulek a vztahů mezi nimi, teprve podle toho se navrhne rozsah přenášených dat.

• Replikační slot musí být pod kontrolou

  Dokud replikační slot nepokročí, PostgreSQL nesmí smazat WAL segmenty, které si přes něj konzument teprve má vyzvednout. Zaseknutý nebo zapomenutý slot proto může nechat WAL růst a zaplnit disk na produkční databázi, počet současně otevřených slotů má navíc svůj limit (max_replication_slots), který je potřeba počítat spolu s ostatními napojeními na stejnou databázi.

• On-premises data gateway, pokud databáze neběží na veřejné síti

  PostgreSQL bývá provozovaný na vlastním serveru nebo cloudové VM bez veřejně dostupného přístupu, ne vždy jde o spravovanou cloudovou službu dosažitelnou přímo z internetu. Pokud je to i váš případ, potřebuje Fabric pro pravidelné načítání dat on-premises data gateway, lokální bránu, přes kterou se pipeline k databázi dostanou, aniž by musela být otevřená směrem ven.

• Přístup do databáze je citlivější než API

  Přímé připojení do produkční databáze zákazníka je z hlediska přístupových údajů a bezpečnosti citlivější než napojení přes veřejné API. Pracujeme proto jen s právy omezenými na čtení a jen na to, co je pro synchronizaci skutečně potřeba.

• Sdílená kapacita Fabricu

  Fabric účtuje přes sdílený fond kapacitních jednotek pro Lakehouse, Warehouse, Power BI i pipeline dohromady. Náročný report nebo velký běh synchronizace tak čerpá ze stejné kapacity jako zbytek workspace, což je dobré počítat při plánování, ne až při prvním zpomalení.

Jak to Datimo řeší

1. 1

   Konektor šitý na vaše schéma

   Konektor stavíme podle konkrétní struktury vaší databáze, ne jako univerzální řešení pro PostgreSQL obecně. Nejdřív zmapujeme tabulky a vztahy, které reálně používáte, teprve podle toho navrhneme rozsah přenášených dat. Datový model je stejný jako u napojení na BigQuery, mění se jen cílová platforma.

2. 2

   Synchronizace šetrná k provoznímu výkonu

   Data čteme přes read repliku nebo naplánovaný export, podle toho, co vaše infrastruktura umožňuje, případně přes on-premises data gateway, pokud databáze neběží na veřejně dostupné síti, aby dotazy nezatěžovaly databázi, na které běží živý provoz.

3. 3

   Data v Lakehouse nebo Warehouse podle potřeby

   Data ukládáme do formátu, který dává smysl vašemu použití, do Lakehouse pro práci přes Spark a analytický endpoint, nebo do Warehouse, pokud potřebujete plné T-SQL.

4. 4

   Správa napojení v ceně

   Technickou správu, úpravy při změnách schématu na vaší straně i aktivní monitoring hlídáme za vás, v rámci ceny.

5. 5

   Modulární rozsah dat

   Rozsah přenášených tabulek jde kdykoli rozšířit podle toho, co zrovna potřebujete reportovat, bez nutnosti stavět napojení znovu od nuly.