Tips en trucs voor het navigeren door de PostgreSQL-gemeenschap

Deze blog gaat over de PostgreSQL-gemeenschap, hoe deze werkt en hoe u er het beste door kunt navigeren. Merk op dat dit slechts een overzicht is ... er is veel bestaande documentatie.

Overzicht van de community, hoe ontwikkeling werkt

PostgreSQL is ontwikkeld en onderhouden door een wereldwijd verspreid netwerk van zeer bekwame vrijwilligers die gepassioneerd zijn door relationele databasecomputing, de PostgreSQL Global Development Group. Een handvol kernteamleden handelt samen speciale verantwoordelijkheden af, zoals het coördineren van release-activiteiten, speciale interne communicatie, beleidsaankondigingen, het toezicht houden op commit-privileges en de hostinginfrastructuur, disciplinaire en andere leiderschapskwesties, evenals individuele verantwoordelijkheid voor speciale codering, ontwikkeling en onderhoud bijdragegebieden . Ongeveer veertig extra personen worden beschouwd als belangrijke bijdragers die, zoals de naam al aangeeft, uitgebreide ontwikkelings- of onderhoudsactiviteiten hebben ondernomen voor belangrijke codebase-functies of nauw verwante projecten. En nog enkele tientallen andere individuen leveren actief verschillende andere bijdragen. Afgezien van de actieve bijdragers, wordt een lange lijst van eerdere bijdragers erkend voor hun werk aan het project. Het zijn de vaardigheden en hoge standaarden van dit team die hebben geresulteerd in de rijke en robuuste functieset van PostgreSQL.

Veel van de bijdragers hebben een voltijdbaan die rechtstreeks verband houdt met PostgreSQL of andere Open Source-software, en de enthousiaste steun van hun werkgevers maakt hun blijvende betrokkenheid bij de PostgreSQL-gemeenschap haalbaar.

Bijdragende individuen coördineren met behulp van samenwerkingstools zoals Internet Relay Chat (irc://irc.freenode.net/PostgreSQL) en PostgreSQL-community-mailinglijsten (https://www.PostgreSQL.org/community/lists). Als IRC of mailinglijsten nieuw voor je zijn, doe dan specifiek je best om de etiquette en protocollen te lezen (er staat een goed artikel op https://fedoramagazine.org/beginners-guide-irc/), en nadat je lid bent geworden, besteed je enige tijd alleen maar luisteren naar lopende gesprekken en in de archieven zoeken naar eerdere soortgelijke vragen voordat u zich met uw eigen problemen bezighoudt.

Merk op dat het team niet statisch is:iedereen kan een bijdrager worden door, nou ja, bij te dragen ... maar er wordt verwacht dat uw bijdrage aan dezelfde hoge normen voldoet!

Het team onderhoudt een Wiki-pagina (https://wiki.postgresql.org/) die, naast een heleboel zeer gedetailleerde en nuttige informatie, zoals artikelen, tutorials, codefragmenten en meer, een TODO-lijst met PostgreSQL-bugs en functieverzoeken presenteert en andere gebieden waar inspanning nodig kan zijn. Als je deel wilt uitmaken van het team, is dit een goede plek om te bladeren. Items worden pas toegevoegd na grondige discussie op de mailinglijst voor ontwikkelaars.

De gemeenschap volgt een proces, gevisualiseerd als de stappen in figuur 1.

Dat wil zeggen, de waarde van elke niet-triviale nieuwe code-implementatie zal naar verwachting eerst worden besproken en (bij consensus) wenselijk worden geacht. Vervolgens wordt geïnvesteerd in ontwerp:ontwerp van de interface, syntaxis, semantiek en gedrag, en aandacht voor achterwaartse compatibiliteitsproblemen. U wilt een bijdrage van de ontwikkelaarsgemeenschap krijgen over wat het probleem is dat moet worden opgelost en wat deze implementatie zal bereiken. Je wilt absoluut NIET in je eentje iets in een vacuüm ontwikkelen. Er is letterlijk tientallen jaren aan collectieve ervaring van zeer hoge kwaliteit belichaamd in het team, en u wilt, en zij verwachten, dat ideeën vroeg worden doorgelicht.

De PostgreSQL-broncode wordt opgeslagen en beheerd met behulp van het Git-versiecontrolesysteem, dus een lokale kopie kan worden uitgecheckt vanaf https://git.postgresql.org/ om de implementatie te starten. Merk op dat voor duurzame onderhoudbaarheid, patches moeten opgaan in de omringende code en de gevestigde codeerconventies moeten volgen (http://developer.postgresql.org/pgdocs/postgres/source.html), dus het is een goed idee om gelijkaardige code te bestuderen secties om de conventies te leren en na te bootsen. Over het algemeen wordt het standaardformaat BSD-stijl gebruikt. Zorg er ook voor dat u de documentatie indien nodig bijwerkt.

Testen houdt in dat u er eerst voor zorgt dat bestaande regressietests slagen en dat er geen compilerwaarschuwingen zijn, maar ook dat u overeenkomstige nieuwe tests toevoegt om de nieuw geïmplementeerde functie(s) uit te oefenen.

Wanneer de implementatie van de nieuwe functionaliteit in uw lokale repository is voltooid, gebruikt u de Git diff-functionaliteit om een ​​patch te maken. Patches worden via e-mail naar de pgsql-hackers-mailinglijst gestuurd voor beoordeling en commentaar, maar u hoeft niet te wachten tot uw werk is voltooid ... een slimme gewoonte zou zijn om stapsgewijs om feedback te vragen. De Wiki-pagina beschrijft de verwachtingen met betrekking tot het formaat en de nuttige verklarende context en hoe respect te tonen voor de tijd van de coderecensent.

De kernontwikkelaars plannen periodiek commit-fests, waarbij alle verzamelde niet-toegepaste patches door geautoriseerde committers aan de broncoderepository worden toegevoegd. Als bijdrager heeft uw code een grondige beoordeling ondergaan en waarschijnlijk zullen uw eigen ontwikkelaarsvaardigheden er beter van worden. Om iets terug te doen, wordt verwacht dat u tijd zult besteden aan het beoordelen van patches van anderen.

Topwebsites om informatie te krijgen of PostgreSQL te leren

De weinige hulpmiddelen waar u niet zonder kunt

De fundamentele opdrachtregelprogramma's voor het werken met een PostgreSQL-database maken deel uit van de normale distributie. Het werkpaard is het psql-hulpprogramma voor de opdrachtregel, dat een interactieve interface biedt met veel functionaliteit voor het opvragen, weergeven en wijzigen van databasemetagegevens, evenals het uitvoeren van gegevensdefinitie (DDL) en gegevensmanipulatie (DML) -instructies.

Andere opmerkelijke hulpprogramma's zijn pg_basebackup voor het vaststellen van een basislijn voor op replicatie gebaseerde back-up, pg_dump voor het extraheren van een database in een scriptbestand of ander archiefbestand, pg_restore voor het herstellen van een uit een pg_dump-archief en andere. Al deze tools hebben uitstekende handleidingen en zijn gedetailleerd in de standaarddocumentatie en talrijke online tutorials.

pgAdmin is een zeer populaire grafische gebruikersinterfacetool die vergelijkbare functionaliteit biedt als het psql-opdrachtregelhulpprogramma, maar met het gemak van aanwijzen en klikken. Figuur 2 toont een screenshot van pgAdmin III. Aan de linkerkant is een paneel met alle database-objecten in het cluster op de gekoppelde hostserver. U kunt inzoomen op de structuur om alle databases, schema's, tabellen, weergaven, functies, enz. weer te geven en zelfs tabellen en weergaven te openen om de daarin opgenomen gegevens te onderzoeken. Voor elk object maakt de tool de SQL DML om het object ook te verwijderen en opnieuw te maken, zoals weergegeven in het paneel rechtsonder. Dit is een handige manier om wijzigingen aan te brengen tijdens de ontwikkeling van de database.

Een paar van mijn favoriete tools voor applicatie-ontwikkelaarsteams zijn Sqitch (http://sqitch.org/), voor databasewijzigingsbeheer, en pgTAP (http://pgtap.org/). Sqitch maakt stand-alone wijzigingsbeheer en iteratieve ontwikkeling mogelijk door middel van scripts die zijn geschreven in het SQL-dialect dat eigen is aan uw implementatie, niet alleen PostgreSQL. Voor elke wijziging in het databaseontwerp schrijft u drie scripts:een om de wijziging te implementeren, een om de wijziging ongedaan te maken als het nodig is om terug te keren naar een vorige versie en een om de wijziging te verifiëren of te testen. De scripts en gerelateerde bestanden kunnen naast uw applicatiecode in uw revisiebeheersysteem worden onderhouden. PgTAP is een testraamwerk dat een reeks functionaliteiten bevat voor het verifiëren van de integriteit van de database. Alle pgTAP-scripts zijn op vergelijkbare wijze platte tekstbestanden die voldoen aan de normale processen voor revisiebeheer en wijzigingsbeheer. Toen ik deze twee tools eenmaal begon te gebruiken, kon ik me moeilijk voorstellen dat ik ooit weer databasewerk zou doen zonder.

Tips en trucs

De algemene mailinglijst van PostgreSQL is de meest actieve van de verschillende communitylijsten en is de belangrijkste community-interface voor gratis ondersteuning van gebruikers. Er verschijnt een vrij breed scala aan vragen in deze lijst, die soms lange heen-en-weergaande vragen opleveren, maar meestal snelle, informatieve en to-the-point reacties opleveren.

Wanneer u een vraag stelt met betrekking tot het gebruik van PostgreSQL, wilt u over het algemeen altijd achtergrondinformatie opnemen, inclusief de versie van PostgreSQL die u gebruikt (vermeld door het psql-opdrachtregelprogramma met "psql --version"), het besturingssysteem waarop de server zich bevindt draaien, en dan misschien een beschrijving van de besturingssysteemomgeving, zoals of het overwegend zwaar lezen of schrijven is, typisch aantal gebruikers en problemen met gelijktijdigheid, wijzigingen die u hebt aangebracht ten opzichte van de standaard serverconfiguratie (d.w.z. de pg_hba.conf en postgresql.conf-bestanden), enz. Vaak is een beschrijving van wat u probeert te bereiken waardevol, in plaats van een stompzinnige analogie, omdat u wellicht suggesties voor verbetering krijgt waar u zelf niet eens aan had gedacht. U krijgt ook de beste respons als u daadwerkelijke DDL-, DML- en voorbeeldgegevens opneemt die het probleem illustreren en anderen in staat stelt te recreëren wat u ziet -- ja, mensen zullen uw voorbeeldcode daadwerkelijk uitvoeren en met u samenwerken.

Bovendien, als u vraagt ​​naar het verbeteren van de queryprestaties, wilt u het queryplan opgeven, d.w.z. de EXPLAIN-uitvoer. Dit wordt gegenereerd door uw query ongewijzigd uit te voeren, behalve door het letterlijk vooraf te laten gaan met het woord "EXPLAIN", zoals weergegeven in afbeelding 3 in de pgAdmin-tool of het psql-opdrachtregelhulpprogramma.

Onder EXPLAIN, in plaats van de query daadwerkelijk uit te voeren, retourneert de server het queryplan, waarin gedetailleerde uitvoer wordt vermeld van hoe de query zal worden uitgevoerd, inclusief welke indexen zullen worden gebruikt om de gegevenstoegang te optimaliseren, waar tabelscans kunnen plaatsvinden en schattingen van de kosten en hoeveelheid gegevens die bij elke stap betrokken zijn. Het soort hulp dat u krijgt van de ervaren beoefenaars die de mailinglijst controleren, kan problemen opsporen en helpen bij het voorstellen van mogelijke nieuwe indexen of wijzigingen in de filter- of deelnamecriteria.

Tot slot, als u deelneemt aan mailinglijstdiscussies, zijn er twee belangrijke dingen die u in gedachten wilt houden.

Ten eerste is de maillijstserver ingesteld om berichten te verzenden die zo zijn geconfigureerd dat wanneer u antwoordt, uw e-mailsoftware standaard alleen antwoordt naar de oorspronkelijke auteur van het bericht. Om er zeker van te zijn dat uw bericht op de lijst komt, moet u de functie "allen beantwoorden" van uw e-mailsoftware gebruiken, die dan zowel de auteur van het bericht als het lijstadres zal bevatten.

Ten tweede is de afspraak op de PostgreSQL-mailinglijsten om in-line te antwoorden en NIET TOP POST. Dit laatste punt is een al lang bestaande conventie in deze gemeenschap, en voor veel nieuwkomers lijkt het ongebruikelijk genoeg dat zachte vermaningen heel gewoon zijn. De meningen lopen uiteen over hoeveel van het oorspronkelijke bericht je moet behouden voor context in je antwoord. Sommige mensen ergeren zich aan de soms logge groei in omvang van het bericht wanneer het hele originele bericht wordt behouden in veel heen en weer discussies. Persoonlijk verwijder ik graag alles wat niet relevant is voor waar ik specifiek op reageer om het bericht beknopt en gefocust te houden. Houd er rekening mee dat er tientallen jaren aan mailinglijstgeschiedenis online wordt bewaard voor historische documentatie en toekomstig onderzoek, dus het behouden van context en stroom wordt als zeer belangrijk beschouwd.

Dit artikel helpt je op weg, ga nu verder en duik erin!