Този блог е за PostgreSQL общността, как работи и как най-добре да се ориентирате в нея. Имайте предвид, че това е само общ преглед ... има много съществуваща документация.
Преглед на общността, как работи развитието
PostgreSQL е разработен и поддържан от глобално разпръсната мрежа от висококвалифицирани доброволци, страстни към изчисленията на релационни бази данни, наричани PostgreSQL Global Development Group. Шепа членове на основния екип заедно се справят със специални отговорности като координиране на дейностите по пускане, специални вътрешни комуникации, съобщения за политики, надзор на привилегиите за ангажименти и хостинг инфраструктурата, дисциплинарни и други проблеми с лидерството, както и индивидуална отговорност за специалностите за кодиране, разработка и поддръжка. . Около четиридесет допълнителни лица се считат за основни сътрудници, които, както подсказва името, са предприели цялостни дейности по разработка или поддръжка за значими функции на кодовата база или тясно свързани проекти. И още няколко десетки лица активно дават различни други приноси. Освен активните сътрудници, дълъг списък от минали сътрудници са признати за работа по проекта. Именно уменията и високите стандарти на този екип са довели до богатия и стабилен набор от функции на PostgreSQL.
Много от сътрудниците имат работа на пълен работен ден, която е пряко свързана с PostgreSQL или друг софтуер с отворен код, а ентусиазираната подкрепа на техните работодатели прави трайната им ангажираност с общността на PostgreSQL осъществима.
Допринасящите лица координират с помощта на инструменти за сътрудничество като Internet Relay Chat (irc://irc.freenode.net/PostgreSQL) и PostgreSQL общностни пощенски списъци (https://www.PostgreSQL.org/community/lists). Ако сте нов в IRC или пощенски списъци, тогава положете усилия да прочетете специално за етикета и протоколите (една добра статия се появява на https://fedoramagazine.org/beginners-guide-irc/) и след като се присъедините, похарчете известно време просто да слушате текущи разговори и да търсите в архивите за предишни подобни въпроси, преди да се заемете със собствените си проблеми.
Имайте предвид, че екипът не е статичен:всеки може да стане сътрудник, като допринесе... но се очаква вашият принос да отговаря на същите високи стандарти!
Екипът поддържа Wiki страница (https://wiki.postgresql.org/), която, наред с много подробна и полезна информация като статии, уроци, фрагменти от код и други, представя TODO списък с грешки в PostgreSQL и заявки за функции и други области, където може да са необходими усилия. Ако искате да сте част от екипа, това е добро място за разглеждане. Елементите се добавят само след задълбочена дискусия в пощенския списък на разработчиците.
Общността следва процес, визуализиран като стъпките на фигура 1.
Фигура 1. Концептуализирано очертание на процеса на разработка на PostgreSQL. Това означава, че стойността на всяка нетривиална нова реализация на код се очаква първо да бъде обсъдена и счетена (с консенсус) за желателна. След това се инвестира в дизайна:дизайн на интерфейса, синтаксис, семантика и поведение и отчитане на проблемите с обратната съвместимост. Искате да получите подкрепа от общността на разработчиците за това какъв е проблемът, който трябва да бъде решен и какво ще постигне тази реализация. Определено НЕ искате да тръгнете и да разработите нещо във вакуум сами. В екипа има буквално десетилетия много висококачествен колективен опит и вие искате, а те очакват, идеите да бъдат проверени рано.
Изходният код на PostgreSQL се съхранява и управлява с помощта на системата за контрол на версиите Git, така че локално копие може да бъде изтеглено от https://git.postgresql.org/, за да започне внедряването. Имайте предвид, че за трайна поддръжка, пачовете трябва да се слеят със заобикалящия код и да следват установените конвенции за кодиране (http://developer.postgresql.org/pgdocs/postgres/source.html), така че е добра идея да изучавате всеки подобен код секции за изучаване и подражание на конвенциите. Обикновено се използва стандартният формат BSD стил. Също така не забравяйте да актуализирате документацията според случая.
Тестването включва първо да се уверите, че съществуващите регресионни тестове са успешни и че няма предупреждения на компилатора, но също така добавяне на съответни нови тестове за упражняване на нововъведената(ите) функция(и).
Когато внедряването на новата функционалност във вашето локално хранилище приключи, използвайте функционалността Git diff, за да създадете корекция. Пачовете се изпращат по имейл до пощенския списък на pgsql-hackers за преглед и коментари, но не е нужно да чакате, докато работата ви приключи ... интелигентната практика би била да поискате обратна връзка постепенно. Страницата в Wiki описва очакванията за форматиране и полезен обяснителен контекст и как да покажем уважение към времето на рецензента на код.
Основните разработчици периодично планират commit fests, по време на които всички натрупани неприложени пачове се добавят към хранилището на изходния код от упълномощени committers. Като сътрудник вашият код ще бъде подложен на строга проверка и вероятно вашите собствени умения на разработчик ще бъдат по-добри за него. За да върнете услугата, очакваме да отделите време за преглед на пачове от други.
Изтеглете Бялата книга днес Управление и автоматизация на PostgreSQL с ClusterControl Научете какво трябва да знаете, за да внедрите, наблюдавате, управлявате и мащабирате PostgreSQLD Изтеглете Бялата книгаНай-популярните уебсайтове за получаване на информация или изучаване на PostgreSQL
| Уебсайт на общността – това е основното място за стартиране на PostgreSQL | https://www.postgresql.org/ |
| Уики – Широкообхватни теми, свързани с PostgreSQL | https://wiki.postgresql.org/ |
| IRC канал – разработчиците са активни участници тук | irc://irc.freenode.net/PostgreSQL |
| Хранилище с изходен код | https://git.postgresql.org/ |
| pgAdmin GUI клиент | https://www.pgadmin.org/ |
| Биографии на значими членове на общността | https://www.postgresql.org/community/contributors/ |
| Прочутата публикация на Ерик Реймънд относно интелигентни въпроси | http://www.catb.org/esr/faqs/smart-questions.html |
| Контрол за промяна на схемата на базата данни | http://sqitch.org/ |
| Тестване на единици за база данни | http://pgtap.org/ |
Малкото инструменти, без които не можете да живеете
Основните инструменти на командния ред за работа с PostgreSQL база данни са част от нормалното разпространение. Работният кон е помощната програма на командния ред psql, която предоставя интерактивен интерфейс с много функционалност за запитване, показване и модифициране на метаданни на базата данни, както и изпълнение на изрази за дефиниране на данни (DDL) и манипулиране на данни (DML).
Други включени помощни програми за отбелязване включват pg_basebackup за установяване на базова линия за базирано на репликация архивиране, pg_dump за извличане на база данни в скриптов файл или друг архивен файл, pg_restore за възстановяване от pg_dump архив и други. Всички тези инструменти имат отлични страници с ръководство, както и са описани подробно в стандартната документация и множество онлайн уроци.
pgAdmin е много популярен инструмент за графичен потребителски интерфейс, който предоставя подобна функционалност като помощната програма за команден ред psql, но с удобство за насочване и щракване. Фигура 2 показва екранна снимка на pgAdmin III. Отляво е панел, показващ всички обекти на базата данни в клъстера на прикачения към хост сървър. Можете да разгледате структурата, за да изброите всички бази данни, схеми, таблици, изгледи, функции и т.н. и дори да отворите таблици и изгледи, за да разгледате съдържащите се данни. За всеки обект инструментът ще създаде SQL DML за пускане и повторно създаване на обекта, както е показано в долния десен панел. Това е удобен начин за извършване на модификации по време на разработването на база данни.
Фигура 2. Помощната програма pgAdmin III. Няколко от любимите ми инструмента за екипите на разработчиците на приложения са Sqitch (http://sqitch.org/), за контрол на промяната на базата данни и pgTAP (http://pgtap.org/). Sqitch позволява самостоятелно управление на промените и итеративно развитие чрез скриптове, написани на SQL диалект, който е роден за вашата реализация, а не само PostgreSQL. За всяка промяна в дизайна на базата данни вие пишете три скрипта:един за внедряване на промяната, един за отмяна на промяната, в случай че е необходимо връщане към предишна версия, и един за проверка или тестване на промяната. Скриптовете и свързаните с тях файлове могат да се поддържат във вашата система за контрол на ревизии точно заедно с кода на приложението ви. PgTAP е рамка за тестване, която включва набор от функционалности за проверка на целостта на базата данни. Всички pgTAP скриптове са подобни обикновени текстови файлове, съвместими с нормалното управление на ревизии и процеси за контрол на промените. След като започнах да използвам тези два инструмента, ми беше трудно да си представя някога отново да върша работа с база данни без.
Съвети и трикове
Общият пощенски списък на PostgreSQL е най-активният от различните списъци на общности и е основният интерфейс на общността за безплатна поддръжка на потребителите. В този списък се появява доста широк спектър от въпроси, които понякога генерират дълги връщане назад и напред, но най-често получават бързи, информативни и точни отговори.
Когато публикувате въпрос, свързан с използването на PostgreSQL, обикновено искате да включвате основна информация, включително версията на PostgreSQL, която използвате (изброена от инструмента на командния ред psql с „psql --version“), операционната система, на която е сървърът работи, а след това може би описание на операционната среда, като например дали тя може да се чете предимно тежко или тежко пише, типичен брой потребители и проблеми с едновременността, промени, които сте направили от конфигурацията на сървъра по подразбиране (т.е. pg_hba.conf и postgresql.conf файлове) и т.н. Често описанието на това, което се опитвате да постигнете, е ценно, а не някаква тъпа аналогия, тъй като може да получите предложения за подобрение, за които дори не сте мислили сами. Освен това ще получите най-добрия отговор, ако включите действителни DDL, DML и примерни данни, които илюстрират проблема и улесняват другите да пресъздадат това, което виждате – да, хората всъщност ще стартират примерния ви код и ще работят с вас.
Освен това, ако питате за подобряване на производителността на заявката, ще искате да предоставите плана на заявката, т.е. изхода EXPLAIN. Това се генерира чрез стартиране на заявката ви непроменена, с изключение на буквалния префикс с думата „EXPLAIN“, както е показано на фигура 3 в инструмента pgAdmin или помощната програма на командния ред psql.
Фигура 3. Създаване на план за заявка с EXPLAIN. Под EXPLAIN, вместо реално да изпълнява заявката, сървърът връща плана на заявката, който изброява подробен изход за това как ще бъде изпълнена заявката, включително кои индекси ще бъдат използвани за оптимизиране на достъпа до данни, къде може да се извърши сканиране на таблици и оценки на цена и количество данни, свързани с всяка стъпка. Видът на помощта, който ще получите от опитните практикуващи, наблюдаващи пощенския списък, може да определи проблемите и да ви помогне да предложите възможни нови индекси или промени в критериите за филтриране или присъединяване.
И накрая, когато участвате в дискусиите за пощенски списъци, има две важни неща, които искате да имате предвид.
Първо, сървърът за пощенски списък е настроен да изпраща съобщения, конфигурирани така, че когато отговорите, по подразбиране вашият имейл софтуер ще отговаря само на автора на оригиналното съобщение. За да сте сигурни, че съобщението ви отива в списъка, трябва да използвате функцията „отговор на всички“ на софтуера за поща, която след това ще включва както автора на съобщението, така и адреса на списъка.
Второ, конвенцията в пощенските списъци на PostgreSQL е да отговаряте на линия и да НЕ ОТГОВОРИТЕ. Тази последна точка е отдавнашна конвенция в тази общност и за много новодошли изглежда достатъчно необичайна, че нежните предупреждения са много често срещани. Мненията се различават за това колко от оригиналното съобщение да запазите за контекст в отговора си. Някои хора се дразнят от понякога тромавото нарастване на размера на съобщението, когато цялото оригинално съобщение се запазва в много дискусии напред-назад. Аз лично обичам да изтривам всичко, което не е от значение за това, на което конкретно отговарям, за да запазя съобщението кратко и фокусирано. Само имайте предвид, че има десетилетия на историята на пощенските списъци, запазена онлайн за историческа документация и бъдещи изследвания, така че запазването на контекста и потока СЕ счита за много важно.
Тази статия ви помага да започнете, сега продължете и се потопете!
