Tipy a triky pro navigaci v komunitě PostgreSQL

Tento blog je o komunitě PostgreSQL, o tom, jak funguje a jak se v ní nejlépe orientovat. Všimněte si, že toto je pouze přehled ... existuje mnoho existující dokumentace.

Přehled komunity, jak rozvoj funguje

PostgreSQL je vyvíjen a udržován globálně rozptýlenou sítí vysoce kvalifikovaných dobrovolníků zapálených do relačních databází, označovaných jako PostgreSQL Global Development Group. Hrstka členů základního týmu společně řeší speciální povinnosti, jako je koordinace činností souvisejících s vydáním, speciální interní komunikace, oznámení o zásadách, dohled nad oprávněními k odevzdání a hostitelské infrastruktuře, disciplinární a další otázky vedení a také individuální odpovědnost za speciální kódování, vývoj a oblasti příspěvků na údržbu. . Asi čtyřicet dalších osob je považováno za hlavní přispěvatele, kteří, jak název napovídá, provedli komplexní vývoj nebo údržbu významných funkcí kódové základny nebo úzce souvisejících projektů. A několik desítek dalších jednotlivců aktivně přispívá různými dalšími příspěvky. Kromě aktivních přispěvatelů je za práci na projektu oceněn dlouhý seznam minulých přispěvatelů. Právě dovednosti a vysoké standardy tohoto týmu vyústily v bohatou a robustní sadu funkcí PostgreSQL.

Mnoho z přispěvatelů má zaměstnání na plný úvazek, které přímo souvisí s PostgreSQL nebo jiným Open Source softwarem, a nadšená podpora jejich zaměstnavatelů umožňuje jejich trvalé zapojení do komunity PostgreSQL.

Přispívající jednotlivci se koordinují pomocí nástrojů pro spolupráci, jako je Internet Relay Chat (irc://irc.freenode.net/PostgreSQL) a konference komunity PostgreSQL (https://www.PostgreSQL.org/community/lists). Pokud jste v IRC nebo mailing listech noví, pak se snažte konkrétně prostudovat etiketu a protokoly (jeden dobrý článek najdete na https://fedoramagazine.org/beginners-guide-irc/) a poté, co se připojíte, utrácejte nějaký čas jen poslouchejte probíhající konverzace a hledejte v archivech předchozí podobné otázky, než se pustíte do svých vlastních problémů.

Všimněte si, že tým není statický:Přispěvatelem se může stát kdokoli tím, že přispěje... ale od vašeho příspěvku se bude očekávat, že bude splňovat stejně vysoké standardy!

Tým spravuje stránku Wiki (https://wiki.postgresql.org/), která kromě spousty velmi podrobných a užitečných informací, jako jsou články, návody, úryvky kódu a další, představuje seznam TODO chyb PostgreSQL a požadavků na funkce a další oblasti, kde může být zapotřebí úsilí. Pokud chcete být součástí týmu, toto je dobré místo k procházení. Položky jsou přidávány až po důkladné diskusi na vývojářském mailing listu.

Komunita se řídí procesem znázorněným jako kroky na obrázku 1.

To znamená, že se očekává, že hodnota jakékoli netriviální implementace nového kódu bude nejprve diskutována a považována (na základě konsensu) za žádoucí. Poté se investuje do designu:návrh rozhraní, syntaxe, sémantiky a chování a zvážení problémů se zpětnou kompatibilitou. Chcete od vývojářské komunity získat názor na to, jaký problém je třeba vyřešit a čeho tato implementace dosáhne. Rozhodně NECHCETE odcházet a vyvíjet něco ve vzduchoprázdnu sami. V týmu jsou ztělesněny doslova desítky let vysoce kvalitních kolektivních zkušeností a vy chcete, a oni očekávají, že nápady budou brzy prověřeny.

Zdrojový kód PostgreSQL je uložen a spravován pomocí systému pro správu verzí Git, takže pro zahájení implementace je možné rezervovat místní kopii z https://git.postgresql.org/. Všimněte si, že pro trvalou udržovatelnost musí záplaty splynout s okolním kódem a dodržovat zavedené konvence kódování (http://developer.postgresql.org/pgdocs/postgres/source.html), takže je dobré si prostudovat jakýkoli podobný kód sekce, abyste se naučili a napodobovali konvence. Obecně se používá standardní formát BSD styl. Nezapomeňte také aktualizovat dokumentaci podle potřeby.

Testování zahrnuje nejprve zajištění úspěšnosti stávajících regresních testů a že neexistují žádná varování kompilátoru, ale také přidání odpovídajících nových testů pro uplatnění nově implementovaných funkcí.

Po dokončení implementace nové funkce ve vašem místním úložišti použijte funkci Git diff k vytvoření opravy. Opravy se zasílají e-mailem do mailing listu pgsql-hackers ke kontrole a komentářům, ale nemusíte čekat, až bude vaše práce dokončena… chytrou praxí by bylo žádat o zpětnou vazbu postupně. Stránka Wiki popisuje očekávání ohledně formátu a užitečného vysvětlujícího kontextu a jak projevit respekt k času, který kontrolor kódu tráví.

Hlavní vývojáři pravidelně plánují slavnosti odevzdání, během nichž jsou všechny nashromážděné neaplikované záplaty přidány do úložiště zdrojového kódu autorizovanými autoritami. Jako přispěvatel bude váš kód podroben přísné kontrole a pravděpodobně pro něj budou lepší vaše vlastní vývojářské dovednosti. Abychom vám to vrátili, očekává se, že budete věnovat čas recenzování patchů od ostatních.

Nejlepší webové stránky, kde můžete získat informace nebo se naučit PostgreSQL

Pár nástrojů, bez kterých se neobejdete

Základní nástroje příkazového řádku pro práci s databází PostgreSQL jsou součástí normální distribuce. Tahounem je nástroj příkazového řádku psql, který poskytuje interaktivní rozhraní se spoustou funkcí pro dotazování, zobrazování a úpravu metadat databáze a také spouštění příkazů definice dat (DDL) a manipulace s daty (DML).

Mezi další užitečné nástroje patří pg_basebackup pro vytvoření základní linie pro zálohování založené na replikaci, pg_dump pro extrahování databáze do souboru skriptu nebo jiného archivního souboru, pg_restore pro obnovu z archivu pg_dump a další. Všechny tyto nástroje mají vynikající manuálové stránky a také jsou podrobně popsány ve standardní dokumentaci a četných online výukových programech.

pgAdmin je velmi oblíbený nástroj grafického uživatelského rozhraní, který poskytuje podobnou funkcionalitu jako nástroj příkazového řádku psql, ale s pohodlím ukaž a klikni. Obrázek 2 ukazuje snímek obrazovky pgAdmin III. Vlevo je panel zobrazující všechny databázové objekty v clusteru na připojeném hostitelském serveru. Můžete proniknout do struktury a zobrazit seznam všech databází, schémat, tabulek, pohledů, funkcí atd. a dokonce otevřít tabulky a pohledy a prozkoumat obsažená data. Pro každý objekt nástroj vytvoří SQL DML pro vypuštění a opětovné vytvoření objektu, jak je znázorněno na pravém dolním panelu. Toto je pohodlný způsob provádění úprav během vývoje databáze.

Několik mých oblíbených nástrojů pro týmy vývojářů aplikací je Sqitch (http://sqitch.org/), pro řízení změn databáze a pgTAP (http://pgtap.org/). Sqitch umožňuje samostatnou správu změn a iterativní vývoj pomocí skriptů napsaných v dialektu SQL nativním pro vaši implementaci, nejen PostgreSQL. Pro každou změnu návrhu databáze napíšete tři skripty:jeden pro nasazení změny, jeden pro vrácení změny v případě, že je nutný návrat k předchozí verzi, a jeden pro ověření nebo testování změny. Skripty a související soubory lze udržovat ve vašem systému řízení revizí přímo vedle kódu vaší aplikace. PgTAP je testovací rámec, který obsahuje sadu funkcí pro ověření integrity databáze. Všechny skripty pgTAP jsou podobně prosté textové soubory vyhovující normálním procesům správy revizí a změn. Jakmile jsem začal používat tyto dva nástroje, bylo pro mě těžké si představit, že bych bez nich ještě někdy pracoval s databází.

Tipy a triky

Obecný mailing list PostgreSQL je nejaktivnější z různých komunitních seznamů a je hlavním komunitním rozhraním pro bezplatnou podporu uživatelům. V tomto seznamu se objevuje poměrně široká škála otázek, které někdy generují zdlouhavé přemísťování tam a zpět, ale nejčastěji dostávají rychlé, informativní a věcné odpovědi.

Při odesílání dotazu souvisejícího s používáním PostgreSQL obecně chcete vždy zahrnout informace o pozadí včetně verze PostgreSQL, kterou používáte (uvedená nástrojem příkazového řádku psql s „psql --version“), operační systém, na kterém je server spuštěné a poté možná popis operačního prostředí, například zda může být převážně náročné na čtení nebo zápis, typický počet uživatelů a problémy se souběžností, změny, které jste provedli oproti výchozí konfiguraci serveru (tj. pg_hba.conf a postgresql.conf) atd. Často je cenný popis toho, čeho se snažíte dosáhnout, spíše než nějaká tupá analogie, protože můžete dostat návrhy na zlepšení, o kterých jste sami ani neuvažovali. Nejlepší odezvu také získáte, pokud zahrnete aktuální DDL, DML a ukázková data ilustrující problém a umožníte ostatním znovu vytvořit to, co vidíte – ano, lidé skutečně spustí váš ukázkový kód a budou s vámi spolupracovat.

Pokud se navíc ptáte na zlepšení výkonu dotazů, budete chtít poskytnout plán dotazů, tj. výstup EXPLAIN. To je generováno spuštěním vašeho dotazu beze změny, s výjimkou doslovného uvedení předpony slovem „EXPLAIN“, jak je znázorněno na obrázku 3 v nástroji pgAdmin nebo v nástroji příkazového řádku psql.

V části EXPLAIN server namísto skutečného spuštění dotazu vrátí plán dotazů, který uvádí podrobný výstup o tom, jak bude dotaz proveden, včetně indexů, které budou použity k optimalizaci přístupu k datům, kde může docházet ke skenování tabulek a odhadů náklady a množství dat souvisejících s každým krokem. Pomoc, kterou získáte od zkušených odborníků, kteří monitorují seznam adresátů, může určit problémy a pomoci navrhnout možné nové indexy nebo změny kritérií filtrování nebo připojení.

A konečně, když se účastníte diskuzí o e-mailových konferencích, jsou dvě důležité věci, které byste měli mít na paměti.

Nejprve je server mail listu nastaven tak, aby odesílal zprávy nakonfigurované tak, že když odpovíte, váš e-mailový software ve výchozím nastavení odpovídá pouze původnímu autorovi zprávy. Abyste si byli jisti, že se vaše zpráva dostane do seznamu, musíte použít funkci „reply-all“ vašeho poštovního softwaru, která pak bude obsahovat jak autora zprávy, tak adresu seznamu.

Zadruhé, konvence na e-mailových konferencích PostgreSQL je odpovídat přímo na řádku a NEPODÁVAT TOP PŘÍSPĚVEK. Tento poslední bod je v této komunitě dlouhodobou konvencí a pro mnoho nově příchozích se zdá dost neobvyklý, že jemné napomenutí jsou velmi běžné. Názory se různí na to, jak velkou část původní zprávy zachovat pro kontext ve vaší odpovědi. Někteří lidé se rozčilují nad někdy nemotorným nárůstem velikosti zprávy, když je celá původní zpráva zachována v mnoha diskuzích tam a zpět. Já osobně rád smažu vše, co se netýká toho, na co konkrétně odpovídám, aby zpráva zůstala stručná a soustředěná. Jen mějte na paměti, že existuje desetiletí historie seznamu adresátů uchovávaných online pro historickou dokumentaci a budoucí výzkum, takže zachování kontextu a toku JE považováno za velmi důležité.

Tento článek vám pomůže začít, nyní pokračujte a ponořte se do toho!