Wskazówki i porady dotyczące poruszania się po społeczności PostgreSQL

Ten blog dotyczy społeczności PostgreSQL, jej działania i najlepszego sposobu poruszania się po niej. Zwróć uwagę, że to tylko przegląd ... istnieje wiele dokumentacji.

Omówienie społeczności, jak działa programowanie

PostgreSQL jest rozwijany i utrzymywany przez rozproszoną po całym świecie sieć wysoko wykwalifikowanych wolontariuszy pasjonujących się relacyjnymi bazami danych, zwaną PostgreSQL Global Development Group. Kilku członków podstawowego zespołu wspólnie zajmuje się specjalnymi obowiązkami, takimi jak koordynowanie działań związanych z wydaniem, specjalna komunikacja wewnętrzna, ogłoszenia dotyczące zasad, nadzorowanie uprawnień do zatwierdzania i infrastruktury hostingowej, dyscyplinarne i inne kwestie związane z kierownictwem, a także indywidualna odpowiedzialność za obszary kodowania specjalistycznego, rozwoju i utrzymania . Około czterdziestu dodatkowych osób jest uważanych za głównych współtwórców, którzy, jak sama nazwa wskazuje, podjęli kompleksowe działania związane z rozwojem lub konserwacją ważnych funkcji bazy kodu lub blisko powiązanych projektów. A kilkadziesiąt innych osób aktywnie wnosi różne inne wkłady. Oprócz aktywnych współpracowników, za pracę nad projektem wyróżniana jest długa lista byłych współpracowników. To umiejętności i wysokie standardy tego zespołu zaowocowały bogatym i solidnym zestawem funkcji PostgreSQL.

Wielu współpracowników ma pełnoetatowe prace, które są bezpośrednio związane z PostgreSQL lub innym oprogramowaniem Open Source, a entuzjastyczne wsparcie ich pracodawców umożliwia ich trwałe zaangażowanie w społeczność PostgreSQL.

Współpracujące osoby koordynują pracę za pomocą narzędzi do współpracy, takich jak Internet Relay Chat (irc://irc.freenode.net/PostgreSQL) i społecznościowe listy mailingowe PostgreSQL (https://www.PostgreSQL.org/community/lists). Jeśli jesteś nowy na IRC lub listach dyskusyjnych, postaraj się przeczytać o etykiecie i protokołach (jeden dobry artykuł znajduje się na https://fedoramagazine.org/beginners-guide-irc/), a po dołączeniu wydaj trochę czasu po prostu słuchając trwających rozmów i przeszukuj archiwa w poszukiwaniu poprzednich podobnych pytań, zanim wskoczysz do swoich własnych problemów.

Pamiętaj, że zespół nie jest statyczny:każdy może zostać współpracownikiem poprzez, cóż, wnosząc swój wkład… ale oczekuje się, że Twój wkład będzie spełniał te same wysokie standardy!

Zespół prowadzi stronę Wiki (https://wiki.postgresql.org/), która wśród wielu bardzo szczegółowych i pomocnych informacji, takich jak artykuły, samouczki, fragmenty kodu i nie tylko, zawiera listę TODO błędów i próśb o nowe funkcje oraz inne obszary, w których może być potrzebny wysiłek. Jeśli chcesz być częścią zespołu, to dobre miejsce do przeglądania. Pozycje są dodawane dopiero po dokładnej dyskusji na liście dyskusyjnej programistów.

Społeczność postępuje zgodnie z procesem przedstawionym jako kroki na rysunku 1.

Oznacza to, że wartość każdej nietrywialnej implementacji nowego kodu powinna być najpierw omówiona i uznana (w drodze konsensusu) za pożądaną. Następnie inwestuje się w projekt:projekt interfejsu, składnię, semantykę i zachowania oraz uwzględnienie kwestii kompatybilności wstecznej. Chcesz przekonać społeczność programistów, jaki jest problem do rozwiązania i co przyniesie ta implementacja. Zdecydowanie NIE chcesz iść i rozwijać czegoś w próżni na własną rękę. Zespół ma dosłownie dziesięciolecia zbiorowego doświadczenia o bardzo wysokiej jakości, a Ty chcesz i oczekujesz, że pomysły zostaną wcześnie zweryfikowane.

Kod źródłowy PostgreSQL jest przechowywany i zarządzany za pomocą systemu kontroli wersji Git, więc lokalną kopię można pobrać z https://git.postgresql.org/, aby rozpocząć implementację. Należy pamiętać, że w celu zapewnienia trwałej konserwacji, łatki muszą wtapiać się w otaczający kod i przestrzegać ustalonych konwencji kodowania (http://developer.postgresql.org/pgdocs/postgres/source.html), więc dobrym pomysłem jest zapoznanie się z każdym podobnym kodem sekcje do nauki i naśladowania konwencji. Generalnie używany jest standardowy format BSD. Pamiętaj również, aby odpowiednio zaktualizować dokumentację.

Testowanie obejmuje najpierw upewnienie się, że istniejące testy regresji powiodły się i że nie ma ostrzeżeń kompilatora, ale także dodanie odpowiednich nowych testów w celu sprawdzenia nowo zaimplementowanych funkcji.

Po zakończeniu implementacji nowej funkcjonalności w lokalnym repozytorium, użyj funkcjonalności Git diff, aby utworzyć poprawkę. Łatki są przesyłane e-mailem na listę dyskusyjną pgsql-hackers w celu przejrzenia i komentarzy, ale nie musisz czekać na zakończenie swojej pracy… mądrą praktyką byłoby stopniowe proszenie o opinie. Strona Wiki opisuje oczekiwania dotyczące formatu i przydatnego kontekstu wyjaśniającego oraz sposobu okazywania szacunku dla czasu recenzenta kodu.

Najważniejsi programiści okresowo planują okresy zatwierdzania, podczas których wszystkie skumulowane niezastosowane poprawki są dodawane do repozytorium kodu źródłowego przez autoryzowanych twórców. Jako współtwórca Twój kod zostanie poddany rygorystycznym przeglądom i prawdopodobnie Twoje własne umiejętności programistyczne będą dla niego lepsze. Aby odwdzięczyć się za przysługę, oczekuje się, że poświęcisz czas na przeglądanie poprawek od innych.

Najlepsze strony internetowe do zdobywania informacji lub nauki PostgreSQL

Kilka narzędzi, bez których nie możesz żyć

Podstawowe narzędzia wiersza poleceń do pracy z bazą danych PostgreSQL są częścią normalnej dystrybucji. Koń roboczy to narzędzie wiersza poleceń psql, które zapewnia interaktywny interfejs z wieloma funkcjami do odpytywania, wyświetlania i modyfikowania metadanych bazy danych, a także wykonywania definicji danych (DDL) i instrukcji manipulacji danymi (DML).

Inne warte odnotowania narzędzia to pg_basebackup do ustanawiania bazowej kopii zapasowej opartej na replikacji, pg_dump do wyodrębniania bazy danych do pliku skryptu lub innego pliku archiwum, pg_restore do przywracania z archiwum pg_dump i inne. Wszystkie te narzędzia mają doskonałe strony podręcznika, a także są szczegółowo opisane w standardowej dokumentacji i licznych samouczkach online.

pgAdmin to bardzo popularne narzędzie graficznego interfejsu użytkownika, które zapewnia podobną funkcjonalność jak narzędzie wiersza poleceń psql, ale z wygodą wskaż i kliknij. Rysunek 2 przedstawia zrzut ekranu pgAdmin III. Po lewej stronie znajduje się panel przedstawiający wszystkie obiekty bazy danych w klastrze na podłączonym serwerze hosta. Możesz zagłębić się w strukturę, aby wyświetlić wszystkie bazy danych, schematy, tabele, widoki, funkcje itp., a nawet otworzyć tabele i widoki w celu zbadania zawartych danych. Dla każdego obiektu narzędzie utworzy SQL DML do upuszczania i ponownego tworzenia obiektu, jak pokazano w prawym dolnym panelu. Jest to wygodny sposób wprowadzania zmian podczas tworzenia bazy danych.

Kilka z moich ulubionych narzędzi dla zespołów programistów aplikacji to Sqitch (http://sqitch.org/), do kontroli zmian w bazie danych i pgTAP (http://pgtap.org/). Sqitch umożliwia samodzielne zarządzanie zmianami i iteracyjny rozwój za pomocą skryptów napisanych w dialekcie SQL natywnym dla Twojej implementacji, a nie tylko PostgreSQL. Dla każdej zmiany projektu bazy danych należy napisać trzy skrypty:jeden do wdrożenia zmiany, jeden do cofnięcia zmiany w przypadku konieczności przywrócenia poprzedniej wersji oraz jeden do weryfikacji lub testowania zmiany. Skrypty i powiązane pliki mogą być utrzymywane w systemie kontroli wersji wraz z kodem aplikacji. PgTAP to platforma testowa zawierająca zestaw funkcji do weryfikacji integralności bazy danych. Wszystkie skrypty pgTAP są podobnie zwykłymi plikami tekstowymi zgodnymi z normalnymi procesami zarządzania wersjami i kontroli zmian. Kiedy zacząłem używać tych dwóch narzędzi, trudno mi było sobie wyobrazić, że kiedykolwiek wykonywałem pracę z bazami danych.

Wskazówki i wskazówki

Ogólna lista mailingowa PostgreSQL jest najbardziej aktywną z różnych list społeczności i jest głównym interfejsem społeczności zapewniającym bezpłatne wsparcie dla użytkowników. Na tej liście pojawia się dość szeroki zakres pytań, czasami generujących długie tam i z powrotem, ale najczęściej otrzymujemy szybkie, pouczające i rzeczowe odpowiedzi.

Kiedy publikujesz pytanie związane z używaniem PostgreSQL, zazwyczaj chcesz podać podstawowe informacje, w tym wersję PostgreSQL, której używasz (wymienioną w narzędziu wiersza poleceń psql z „psql --version”), system operacyjny, na którym znajduje się serwer uruchomiony, a następnie może opis środowiska operacyjnego, na przykład, czy może być głównie odczytywany lub zapisywany, typowa liczba użytkowników i problemy ze współbieżnością, zmiany wprowadzone w domyślnej konfiguracji serwera (tj. pg_hba.conf i postgresql.conf) itp. Często opis tego, co próbujesz osiągnąć, jest cenny, a nie jakąś tępą analogię, ponieważ możesz otrzymać sugestie ulepszeń, o których nawet nie pomyślałeś. Ponadto najlepszą odpowiedź uzyskasz, jeśli dołączysz rzeczywiste DDL, DML i przykładowe dane ilustrujące problem i ułatwiające innym odtworzenie tego, co widzisz – tak, ludzie faktycznie uruchomią Twój przykładowy kod i będą z Tobą pracować.

Dodatkowo, jeśli pytasz o poprawę wydajności zapytań, będziesz chciał podać plan zapytania, tj. Wyjście EXPLAIN. Jest to generowane przez uruchomienie zapytania w niezmienionej postaci, z wyjątkiem dosłownego poprzedzania go słowem „EXPLAIN”, jak pokazano na rysunku 3 w narzędziu pgAdmin lub narzędziu wiersza poleceń psql.

W obszarze EXPLAIN, zamiast faktycznie uruchamiać zapytanie, serwer zwraca plan zapytania, który zawiera szczegółowe dane wyjściowe dotyczące sposobu wykonania zapytania, w tym indeksy użyte do optymalizacji dostępu do danych, miejsca, w których może nastąpić skanowanie tabel oraz oszacowanie koszt i ilość danych związanych z każdym krokiem. Rodzaj pomocy, jaką otrzymasz od doświadczonych praktyków monitorujących listę mailingową, może wskazać problemy i pomóc zasugerować możliwe nowe indeksy lub zmiany w kryteriach filtrowania lub dołączania.

Wreszcie, biorąc udział w dyskusjach na listach dyskusyjnych, należy pamiętać o dwóch ważnych rzeczach.

Po pierwsze, serwer listy mailingowej jest skonfigurowany do wysyłania wiadomości tak, aby podczas odpowiadania domyślnie program pocztowy odpowiadał tylko oryginalnemu autorowi wiadomości. Aby mieć pewność, że Twoja wiadomość trafi na listę, musisz użyć funkcji „odpowiedz wszystkim” programu pocztowego, która będzie zawierać zarówno autora wiadomości, jak i adres listy.

Po drugie, konwencją na listach dyskusyjnych PostgreSQL jest odpowiadanie w trybie on-line i NIE TOP POST. Ten ostatni punkt jest długoletnią konwencją w tej społeczności i dla wielu nowoprzybyłych wydaje się na tyle niezwykły, że łagodne napomnienia są bardzo powszechne. Opinie różnią się w zależności od tego, ile oryginalnej wiadomości należy zachować dla kontekstu w odpowiedzi. Niektórzy ludzie irytują się czasem nieporęcznym wzrostem rozmiaru wiadomości, gdy cała oryginalna wiadomość jest zachowywana w wielu dyskusjach w obie strony. Ja osobiście lubię usuwać wszystko, co nie jest istotne dla tego, na co odpowiadam, aby wiadomość była zwięzła i skoncentrowana. Pamiętaj tylko, że istnieją dziesięciolecia historii list mailingowych przechowywanych online w celu dokumentacji historycznej i przyszłych badań, więc zachowanie kontekstu i przepływu JEST uważane za bardzo ważne.

Ten artykuł pozwoli Ci zacząć, teraz ruszaj i zanurkuj!