Sekwencja – uporządkowany ciąg znaków, następujący po sobie w ściśle określonej kolejności. W PostgreSQL (a szerzej w kontekście baz danych), specjalny obiekt bazodanowy – tak pożyteczny, a zarazem już tak w zasadzie ...
Kolejna odsłona porad związanych z psql: rozwiniemy temat posługiwania się psql w trybie interaktywnym, pokażemy zastosowania trybu nieinteraktywnego i funkcjonalności z najnowszych wersji narzędzia.
Wśród doświadczonych administratorów panują podzielone opinie na temat przewagi trybu tekstowego nad graficznym. Nie da się zaprzeczyć, że umiejętność sprawnego poruszania się w konsoli jest ważna. Nie stanowi to zmartwienia dla użytkowników silnika PostgreSQL, którzy do dyspozycji mają tak sprytne narzędzie jak psql.
Jedną ze zmór administratorów baz danych są sesje, które rozpoczęły blok transakcyjny poleceniem BEGIN, ewentualnie wykonały jakieś operacje i „zamarły”. Mogą stanowić sporą przeszkodę w sprawnej pracy klastra – alokują zasoby, mogą być przyczyną problemów z lokowaniem tabel (LOCK TABLE), ograniczają pulę połączeń, opóźniają replikację i procesy VACUUM.
Dobrze zaprojektowana baza oparta o relacyjny system zarządzania powinna w jakimś (i to raczej w większym) stopniu uwzględniać postulaty Edgara F. Codda – także te dotyczące postaci normalnych. Respektowanie tych założeń powoduje powstanie w strukturze tabel przechowujących klucze główne do wielu innych tabel. Tabele te są bardzo często przeszukiwane – np. podczas filtrowania. Warto zatem zadbać o ich optymalizację pod tym kątem. Artykuł ten porównuje wydajność dwóch indeksów: b-tree oraz bloom na silniku PostgreSQL w wersji 10.
Przetwarzanie dużej ilości danych zawsze stanowi wielopoziomowe wyzwanie. Począwszy od doboru sprzętu i oprogramowania, przez projekt struktury przechowywanych danych aż po finalną optymalizację zapytań. Poniższy artykuł porównuje wydajność dwóch funkcjonalności silnika PostgreSQL 10 – partycjonowania tabel i indeksu typu BRIN, służących między innymi do optymalizacji wyszukiwania na obszernych zbiorach danych.
Systemy bazodanowe, zgodnie z ich podstawowym zastosowaniem, podlegają zmianom w czasie. Zmienia się szereg czynników takich jak ilość danych, sposób ich wykorzystania, wykorzystywane procedury, mechanizmy dostępu, pula klientów. Zmienność zależna jest od wielu czynników i nie da się jej jednoznacznie opisać. Naturalnie, zmienność ta powoduje zmiany w kondycji systemu bazodanowego. Przed użytkownikami odpowiedzialnymi za wydajność i stabilność aplikacji staje zadanie sprawdzenia tej kondycji i podjęcia odpowiednich kroków.
Często przed administratorami oraz architektami odpowiedzialnymi za systemy wykorzystujące bazy danych, staje wyzwanie w postaci wykorzystania rozproszonej architektury, w celu optymalizacji rozwiązania. Niezależnie od tego, jakie to rozwiązanie, pojawia się zagadnienie replikacji. I o tym kilka słów w tym artykule.