PostgreSQL
 sql >> Database >  >> RDS >> PostgreSQL

Suggerimenti e trucchi per navigare nella community di PostgreSQL

Questo blog parla della community di PostgreSQL, di come funziona e del modo migliore per navigarla. Nota che questa è solo una panoramica... c'è molta documentazione esistente.

Panoramica della community, come funziona lo sviluppo

PostgreSQL è sviluppato e gestito da una rete diffusa a livello globale di volontari altamente qualificati appassionati di elaborazione di database relazionali denominata PostgreSQL Global Development Group. Una manciata di membri del team centrale gestiscono insieme responsabilità speciali come coordinare le attività di rilascio, comunicazioni interne speciali, annunci politici, supervisionare i privilegi di commit e l'infrastruttura di hosting, questioni disciplinari e di leadership, nonché la responsabilità individuale per la codifica di specialità, lo sviluppo e le aree di contributo di manutenzione . Circa quaranta persone in più sono considerate importanti contributori che, come suggerisce il nome, hanno intrapreso attività di sviluppo o manutenzione complete per funzionalità significative della base di codice o progetti strettamente correlati. E molte altre dozzine di persone stanno attivamente dando vari altri contributi. A parte i contributori attivi, un lungo elenco di contributori passati è riconosciuto per il lavoro sul progetto. Sono l'abilità e gli elevati standard di questo team che hanno portato al ricco e solido set di funzionalità di PostgreSQL.

Molti dei contributori hanno lavori a tempo pieno che si riferiscono direttamente a PostgreSQL o ad altri software Open Source e il supporto entusiasta dei loro datori di lavoro rende possibile il loro impegno duraturo con la comunità di PostgreSQL.

Le persone che contribuiscono si coordinano utilizzando strumenti di collaborazione come Internet Relay Chat (irc://irc.freenode.net/PostgreSQL) e mailing list della comunità PostgreSQL (https://www.PostgreSQL.org/community/lists). Se non conosci IRC o le mailing list, fai uno sforzo specifico per leggere l'etichetta e i protocolli (un buon articolo appare su https://fedoramagazine.org/beginners-guide-irc/) e dopo esserti iscritto, spendi un po' di tempo ascoltando semplicemente le conversazioni in corso e cercando negli archivi precedenti domande simili prima di saltare con i tuoi problemi.

Nota che il team non è statico:chiunque può diventare un collaboratore, beh, contribuendo... ma ci si aspetta che il tuo contributo soddisfi gli stessi standard elevati!

Il team gestisce una pagina Wiki (https://wiki.postgresql.org/) che, tra molte informazioni molto dettagliate e utili come articoli, tutorial, frammenti di codice e altro, presenta un elenco TODO di bug PostgreSQL e richieste di funzionalità e altre aree in cui potrebbe essere necessario uno sforzo. Se vuoi far parte della squadra, questo è un buon posto per navigare. Gli elementi vengono aggiunti solo dopo un'approfondita discussione sulla mailing list degli sviluppatori.

La comunità segue un processo, visualizzato come i passaggi nella Figura 1.

Figura 1. Schema concettuale del processo di sviluppo di PostgreSQL.

Cioè, il valore di qualsiasi nuova implementazione di codice non banale dovrebbe essere prima discusso e ritenuto (per consenso) desiderabile. Quindi si investe nella progettazione:progettazione dell'interfaccia, sintassi, semantica e comportamenti e considerazione dei problemi di compatibilità con le versioni precedenti. Vuoi ottenere il consenso della comunità degli sviluppatori su quale sia il problema da risolvere e cosa realizzerà questa implementazione. Sicuramente NON vuoi andare fuori e sviluppare qualcosa nel vuoto da solo. Ci sono letteralmente decenni di esperienza collettiva di altissima qualità incarnata nel team e tu vuoi, e si aspettano, che le idee vengano esaminate in anticipo.

Il codice sorgente di PostgreSQL viene archiviato e gestito utilizzando il sistema di controllo della versione Git, quindi è possibile estrarre una copia locale da https://git.postgresql.org/ per iniziare l'implementazione. Nota che per una manutenibilità duratura, le patch devono fondersi con il codice circostante e seguire le convenzioni di codifica stabilite (http://developer.postgresql.org/pgdocs/postgres/source.html), quindi è una buona idea studiare qualsiasi codice simile sezioni per imparare ed emulare le convenzioni. Generalmente, viene utilizzato lo stile BSD in formato standard. Inoltre, assicurati di aggiornare la documentazione in modo appropriato.

Il test implica prima di tutto assicurarsi che i test di regressione esistenti abbiano esito positivo e che non vi siano avvisi del compilatore, ma anche l'aggiunta di nuovi test corrispondenti per esercitare le funzionalità appena implementate.

Quando l'implementazione della nuova funzionalità nel tuo repository locale è completa, usa la funzionalità Git diff per creare una patch. Le patch vengono inviate via e-mail alla mailing list di pgsql-hacker per la revisione e i commenti, ma non devi aspettare fino al completamento del tuo lavoro … una pratica intelligente sarebbe quella di chiedere feedback in modo incrementale. La pagina Wiki descrive le aspettative riguardo al formato e al contesto esplicativo utile e come mostrare rispetto per il tempo del revisore del codice.

Gli sviluppatori principali pianificano periodicamente dei commit fest, durante i quali tutte le patch non applicate accumulate vengono aggiunte al repository del codice sorgente da committenti autorizzati. In qualità di collaboratore, il tuo codice sarà stato sottoposto a una revisione rigorosa e probabilmente le tue capacità di sviluppatore saranno le migliori. Per ricambiare il favore, ci si aspetta che dedichi del tempo alla revisione delle patch di altri.

Scarica il whitepaper oggi Gestione e automazione di PostgreSQL con ClusterControlScopri cosa devi sapere per distribuire, monitorare, gestire e ridimensionare PostgreSQLScarica il whitepaper

I migliori siti Web per ottenere informazioni o imparare PostgreSQL

Sito web della community:questo è il principale punto di partenza per la vita con PostgreSQL https://www.postgresql.org/
Wiki - Argomenti ad ampio raggio relativi a PostgreSQL https://wiki.postgresql.org/
Canale IRC - Gli sviluppatori sono partecipanti attivi qui irc://irc.freenode.net/PostgreSQL
Repository del codice sorgente https://git.postgresql.org/
client GUI pgAdmin https://www.pgadmin.org/
Biografia di membri significativi della comunità https://www.postgresql.org/community/contributors/
Il famoso post di Eric Raymond sulle domande intelligenti http://www.catb.org/esr/faqs/smart-questions.html
Controllo della modifica dello schema del database http://sqitch.org/
Test delle unità di database http://pgtap.org/

I pochi strumenti senza i quali non puoi vivere

Gli strumenti da riga di comando fondamentali per lavorare con un database PostgreSQL fanno parte della normale distribuzione. Il cavallo di battaglia è l'utilità della riga di comando psql, che fornisce un'interfaccia interattiva con molte funzionalità per eseguire query, visualizzare e modificare i metadati del database, nonché eseguire istruzioni di definizione dei dati (DDL) e manipolazione dei dati (DML).

Altre utilità incluse degne di nota includono pg_basebackup per stabilire una baseline per il backup basato sulla replica, pg_dump per estrarre un database in un file di script o in un altro file di archivio, pg_restore per ripristinare a da un archivio pg_dump e altri. Tutti questi strumenti hanno eccellenti pagine di manuale oltre ad essere dettagliati nella documentazione standard e numerosi tutorial online.

pgAdmin è uno strumento di interfaccia utente grafica molto popolare che fornisce funzionalità simili all'utilità della riga di comando psql, ma con la comodità del puntatore e del clic. La figura 2 mostra uno screenshot di pgAdmin III. Sulla sinistra c'è un pannello che mostra tutti gli oggetti del database nel cluster sul server host collegato. È possibile approfondire la struttura per elencare tutti i database, schemi, tabelle, viste, funzioni, ecc. e persino aprire tabelle e viste per esaminare i dati contenuti. Per ogni oggetto, lo strumento creerà anche il DML SQL per rilasciare e ricreare l'oggetto, come mostrato nel pannello in basso a destra. Questo è un modo conveniente per apportare modifiche durante lo sviluppo del database.

Figura 2. L'utilità pgAdmin III.

Un paio dei miei strumenti preferiti per i team di sviluppatori di applicazioni sono Sqitch (http://sqitch.org/), per il controllo delle modifiche al database e pgTAP (http://pgtap.org/). Sqitch consente la gestione autonoma delle modifiche e lo sviluppo iterativo per mezzo di script scritti nel dialetto SQL nativo per la tua implementazione, non solo PostgreSQL. Per ogni modifica alla progettazione del database, scrivi tre script:uno per distribuire la modifica, uno per annullare la modifica nel caso sia necessario ripristinare una versione precedente e uno per verificare o testare la modifica. Gli script e i file correlati possono essere mantenuti nel sistema di controllo delle revisioni insieme al codice dell'applicazione. PgTAP è un framework di test che include una suite di funzionalità per la verifica dell'integrità del database. Tutti gli script pgTAP sono allo stesso modo semplici file di testo compatibili con i normali processi di gestione delle revisioni e di controllo delle modifiche. Una volta che ho iniziato a utilizzare questi due strumenti, è stato difficile immaginare di poter mai più lavorare sui database senza.

Suggerimenti e trucchi

La mailing list generale di PostgreSQL è la più attiva delle varie community list ed è l'interfaccia principale della community per il supporto gratuito agli utenti. In questo elenco viene visualizzata una gamma piuttosto ampia di domande, che a volte generano lunghi avanti e indietro, ma il più delle volte ottengono risposte rapide, informative e puntuali.

Quando si posta una domanda relativa all'utilizzo di PostgreSQL, in genere si desidera includere sempre informazioni di base inclusa la versione di PostgreSQL in uso (elencata dallo strumento da riga di comando psql con "psql --version"), il sistema operativo su cui è installato il server in esecuzione, e quindi forse una descrizione dell'ambiente operativo, ad esempio se può essere prevalentemente letto o scritto pesantemente, numero tipico di utenti e problemi di concorrenza, modifiche apportate dalla configurazione del server predefinita (ad esempio, pg_hba.conf e postgresql.conf), ecc. Spesso, una descrizione di ciò che stai cercando di ottenere è preziosa, piuttosto che qualche ottusa analogia, poiché potresti ricevere suggerimenti per il miglioramento a cui non avevi nemmeno pensato da solo. Inoltre, otterrai la risposta migliore se includi DDL, DML e dati di esempio effettivi che illustrano il problema e facilitano gli altri a ricreare ciò che stai vedendo:sì, le persone eseguiranno effettivamente il tuo codice di esempio e lavoreranno con te.

Inoltre, se stai chiedendo di migliorare le prestazioni della query, dovrai fornire il piano della query, ovvero l'output EXPLAIN. Questo viene generato eseguendo la tua query inalterata tranne che per prefissarla letteralmente con la parola "EXPLAIN", come mostrato nella Figura 3 nello strumento pgAdmin o nell'utilità della riga di comando psql.

Figura 3. Creazione di un piano di query con EXPLAIN.

In EXPLAIN, invece di eseguire effettivamente la query, il server restituisce il piano di query, che elenca l'output dettagliato di come verrà eseguita la query, inclusi gli indici che verranno utilizzati per ottimizzare l'accesso ai dati, dove potrebbero verificarsi scansioni delle tabelle e stime del costo e quantità di dati coinvolti in ogni passaggio. Il tipo di aiuto che riceverai dai professionisti esperti che monitorano la mailing list può individuare problemi e aiutare a suggerire possibili nuovi indici o modifiche ai criteri di filtro o unione.

Infine, quando si partecipa a discussioni sulla mailing list, ci sono due cose importanti che vuoi tenere a mente.

Innanzitutto, il server dell'elenco di posta è configurato per inviare messaggi configurati in modo tale che quando si risponde, per impostazione predefinita il software di posta elettronica risponderà solo all'autore del messaggio originale. Per essere sicuro che il tuo messaggio vada nell'elenco, devi utilizzare la funzione "rispondi a tutti" del tuo software di posta, che includerà quindi sia l'autore del messaggio che l'indirizzo dell'elenco.

In secondo luogo, la convenzione sulle mailing list di PostgreSQL è di rispondere in linea e NON TOP POST. Quest'ultimo punto è una convenzione di vecchia data in questa comunità, e per molti nuovi arrivati ​​sembra abbastanza insolito che gli ammonimenti gentili siano molto comuni. Le opinioni variano su quanto del messaggio originale conservare per il contesto nella tua risposta. Alcune persone si irritano per la crescita a volte ingombrante delle dimensioni del messaggio quando l'intero messaggio originale viene mantenuto in molte discussioni avanti e indietro. Personalmente, mi piace eliminare tutto ciò che non è rilevante per ciò a cui sto rispondendo in modo specifico in modo da mantenere il messaggio conciso e mirato. Tieni solo a mente che ci sono decenni di cronologia delle mailing list conservate online per la documentazione storica e la ricerca futura, quindi mantenere il contesto e il flusso è considerato molto importante.

Questo articolo ti consente di iniziare, ora vai avanti e tuffati!