Osvědčené postupy pro vytvoření aplikace s jednoúčelovým serverem Azure Database for PostgreSQL

  • Článek

PLATÍ PRO: Azure Database for PostgreSQL – Jednoúčelový server

Důležité

Jednoúčelový server Azure Database for PostgreSQL je na cestě vyřazení. Důrazně doporučujeme upgradovat na flexibilní server Azure Database for PostgreSQL. Další informace o migraci na flexibilní server Azure Database for PostgreSQL najdete v tématu Co se děje s jednoúčelovým serverem Azure Database for PostgreSQL?

Tady je několik osvědčených postupů, které vám pomůžou vytvořit aplikaci připravenou pro cloud pomocí Azure Database for PostgreSQL. Tyto osvědčené postupy můžou zkrátit dobu vývoje vaší aplikace.

Konfigurace aplikačních a databázových prostředků

Zachování aplikace a databáze ve stejné oblasti

Při nasazování aplikace v Azure se ujistěte, že jsou všechny vaše závislosti ve stejné oblasti. Šíření instancí napříč oblastmi nebo zónami dostupnosti vytváří latenci sítě, což může ovlivnit celkový výkon vaší aplikace.

Zajištění zabezpečení serveru PostgreSQL

Nakonfigurujte server PostgreSQL tak, aby byl zabezpečený a veřejně nepřístupný. K zabezpečení serveru použijte jednu z těchto možností:

Kvůli zabezpečení se musíte vždy připojit k serveru PostgreSQL přes PROTOKOL SSL a nakonfigurovat server PostgreSQL a aplikaci tak, aby používaly protokol TLS 1.2. Přečtěte si , jak nakonfigurovat protokol SSL/TLS.

Použití proměnných prostředí pro informace o připojení

Neukládejte přihlašovací údaje databáze do kódu aplikace. V závislosti na front-endové aplikaci nastavte proměnné prostředí podle pokynů. Informace o použití služby App Service najdete v tématu konfigurace nastavení aplikace a služby Azure Kubernetes, kde se dozvíte, jak používat tajné kódy Kubernetes.

Výkon a odolnost

Tady je několik nástrojů a postupů, které můžete použít k ladění problémů s výkonem aplikace.

Použití sdružování Připojení

Při sdružování připojení se v době spuštění naváže pevná sada připojení a udržuje se. Také to pomáhá snížit fragmentaci paměti na serveru, která je způsobena dynamickými novými připojeními zřízenými na databázovém serveru. Sdružování připojení je možné nakonfigurovat na straně aplikace, pokud ji podporuje architektura aplikace nebo ovladač databáze. Pokud to není podporované, druhou doporučenou možností je využít službu sdružování připojení proxy serveru, jako je PgBouncer nebo Pgpool spuštěná mimo aplikaci a připojení k databázovému serveru. PgBouncer i Pgpool jsou komunitní nástroje, které pracují se službou Azure Database for PostgreSQL.

Logika opakování pro ošetření přechodných chyb

U vaší aplikace může docházet k přechodným chybám, kdy se přerušovaně zahodí nebo ztratí připojení k databázi. V takových situacích je server spuštěný po jednom až dvou opakováních za 5 až 10 sekund. Osvědčeným postupem je počkat před prvním opakováním 5 sekund. Potom postupujte podle jednotlivých opakování postupným zvýšením čekání až o 60 sekund. Omezte maximální počet opakování v okamžiku, kdy vaše aplikace považuje operaci za neúspěšnou, abyste ji mohli dále prozkoumat. Další informace najdete v tématu Řešení chyb připojení.

Povolení replikace pro čtení pro zmírnění převzetí služeb při selhání

Replikace příchozích dat můžete použít pro scénáře převzetí služeb při selhání. Pokud používáte repliky pro čtení, nedojde mezi zdrojovými servery a servery replik k automatickému převzetí služeb při selhání. Mezi zdrojem a replikou si všimnete prodlevy, protože replikace je asynchronní. Prodleva sítě může být ovlivněna mnoha faktory, jako je velikost úlohy spuštěné na zdrojovém serveru a latence mezi datovými centry. Ve většině případů prodleva repliky trvá několik sekund až několik minut.

Nasazení databáze

Konfigurace kanálu nasazení CI/CD

Občas je potřeba nasadit změny do databáze. V takových případech můžete k aktualizaci databáze použít kontinuální integraci (CI) prostřednictvím GitHub Actions pro server PostgreSQL spuštěním vlastního skriptu.

Definování procesu ručního nasazení databáze

Během ručního nasazení databáze minimalizujte výpadky nebo snižte riziko neúspěšného nasazení:

  • Vytvořte kopii produkční databáze v nové databázi pomocí pg_dump.
  • Aktualizujte novou databázi o nové změny schématu nebo aktualizace potřebné pro vaši databázi.
  • Umístěte produkční databázi do stavu jen pro čtení. Operace zápisu do produkční databáze byste neměli mít, dokud se nasazení nedokončí.
  • Otestujte aplikaci pomocí nově aktualizované databáze z kroku 1.
  • Nasaďte změny aplikace a ujistěte se, že aplikace teď používá novou databázi s nejnovějšími aktualizacemi.
  • Ponechte starou produkční databázi, abyste mohli vrátit změny zpět. Potom můžete vyhodnotit, jestli chcete odstranit starou produkční databázi, nebo ji v případě potřeby exportovat do služby Azure Storage.

Poznámka:

Pokud se aplikace podobá aplikaci elektronického obchodování a nemůžete ji umístit do stavu jen pro čtení, nasaďte změny přímo do produkční databáze po provedení zálohy. Tyto změny by se měly vyskytnout v době mimo špičku s nízkým provozem do aplikace, aby se minimalizoval dopad, protože někteří uživatelé můžou zaznamenat neúspěšné požadavky. Ujistěte se, že kód aplikace zpracovává také všechny neúspěšné požadavky.

Schéma databáze a dotazy

Tady je několik tipů, které byste měli mít na paměti při sestavování schématu databáze a dotazů.

Použití BIGINT nebo UUID pro primární klíče

Při vytváření vlastních aplikací nebo některých architektur možná místo pro primární klíče používají INTBIGINT . Při použití INTriskujete, že hodnota v databázi může překročit kapacitu úložiště datového INT typu. Provedení této změny stávající produkční aplikace může být časově náročné s nákladnějším časem vývoje. Další možností je použít UUID pro primární klíče. Tento identifikátor používá automaticky vygenerovaný 128bitový řetězec, například a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11. Přečtěte si další informace o datových typech PostgreSQL.

Použití indexů

Postgres obsahuje mnoho typů indexů , které se dají použít různými způsoby. Použití indexu pomáhá serveru najít a načíst určité řádky mnohem rychleji, než by bez indexu mohlo udělat. Indexy ale také přidávají režijní náklady na databázový server, a proto se vyhněte příliš velkému počtu indexů.

Použití automatického úklidu

Server můžete optimalizovat pomocí automatického úklidu na serveru Azure Database for PostgreSQL. PostgreSQL umožňuje větší souběžnost databáze, ale s každým výsledkem aktualizace je vložení a odstranění. Pro odstranění se záznamy označí jako obnovitelné, které se později vyprázdní. K provedení těchto úloh spustí PostgreSQL úlohu vakua. Pokud čas od času nevysadíte, můžou mrtvé řazené kolekce členů, které se hromadí, způsobit následující:

  • Data bloudí, například větší databáze a tabulky.
  • Větší neoptimální indexy.
  • Zvýšení vstupně-výstupních operací.

Přečtěte si další informace o tom, jak optimalizovat pomocí automatického úklidu.

Použití pg_stats_statements

Pg_stat_statements je rozšíření PostgreSQL, které je ve výchozím nastavení povolené ve službě Azure Database for PostgreSQL. Rozšíření poskytuje způsob sledování statistik provádění pro všechny příkazy SQL spuštěné serverem. Podívejte se, jak používat pg_statement.

Použití úložiště dotazů

Funkce Úložiště dotazů ve službě Azure Database for PostgreSQL poskytuje metodu pro sledování statistik dotazů. Tuto funkci doporučujeme jako alternativu k používání pg_stats_statements.

Optimalizace hromadných vkládání a používání přechodných dat

Pokud máte operace úloh, které zahrnují přechodná data nebo které vkládají velké datové sady hromadně, zvažte použití nezalogovaných tabulek. Ve výchozím nastavení poskytuje atomicitu a odolnost. Atomicita, konzistence, izolace a stálost tvoří vlastnosti ACID. Podívejte se, jak optimalizovat hromadné vkládání.