Python: unikalne kombinacje z dwóch list (sztuczka start

2020-12-09

Załóżmy, że mamy listę portów lotniczych i zastanawiamy się, jakie można zbudować trasy między nimi:

ports = ['WAW', 'KRK', 'GDN', 'KTW', 'WMI', 'WRO', 'POZ', 'RZE', 'SZZ',
 'LUZ', 'BZG', 'LCJ', 'SZY', 'IEG', 'RDO']
 
routes = [ (start, stop) for start in ports for stop in ports]
print(routes)
print(len(routes))

ports = ['WAW', 'KRK', 'GDN', 'KTW', 'WMI', 'WRO', 'POZ', 'RZE', 'SZZ',

'LUZ', 'BZG', 'LCJ', 'SZY', 'IEG', 'RDO']

routes = [ (start, stop) for start in ports for stop in ports]

print(routes)

print(len(routes))

W routes zostanie wygenerowanych 255 tras, ale niestety znajdą się w niej zbędne wartości. Będzie trasa WAW-WAW, ale znajdą się też duplikaty WAW-KRK oraz KRK-WAW. Jak je wykluczyć? Zmieniając wyrażenie generujące wartości dostaniemy już tylko 210 wyników, ale wyeliminowaliśmy tylko trasy z tego samego miasta do tego samego miasta:

routes = [ (start, stop) for start in ports for stop in ports if start != stop]
print(routes)
print(len(routes))

routes = [ (start, stop) for start in ports for stop in ports if start != stop]

print(routes)

print(len(routes))

No to idźmy dalej. Polecenie w tej postaci da o wiele lepszy wynik – 105 tras:

routes = [ (start, stop) for start in ports for stop in ports if start &lt; stop]
print(routes)
print(len(routes))

routes = [ (start, stop) for start in ports for stop in ports if start < stop]

print(routes)

print(len(routes))

Zapis start<stop jest nieco dziwny. Porównujemy napisy: A<B, B<C, C<D itd. Tak jak lista obecności w dzienniku szkolnym. Ten znak ostrej nierówności to „sztuczka programistyczna”. Skoro A jest mniejsze od B, to nasz wzór wykryje tylko połączenie A do B, ale połączenie B do A pominie, bo B nie jest mniejsze od A.

Programowanie to nie tylko instrukcje i kod. Programowanie to też sztuczki, które sprawiają, że ten sam problem da się rozwiązać na kilka(set) różnych sposobów – a my musimy tylko wybrać ten lepszy z pewnego punktu widzenia!

Komentarze (0)

Więcej

By Rafał Kraik in Python

Python: kolejność wyznaczania wartości logicznej

2020-12-09

Wyrażenia logiczne w Pythonie są wyznaczane od lewej do prawej. Jeśli więc masz w if wyrażenie logiczne expr1 and expr2, to expr2 będzie wyliczane tylko wtedy jeśli expr1 ma wartość True. Jest to całkiem oczywiste z punktu widzenia optymalizacji liczby wykonywanych obliczeń – gdyby expr1 już miało wartość False, to nie ma sensu wyliczać wartości dla expr2, bo ostateczna wartość dla expr1 and expr2 to False!

Jednak informacja o kolejności wyznaczania wartości jest istotna. Popatrz na ten przykład:

i = 0
box = ['ab','bcd','cde']


while len(box[i])&gt;0 and i &lt; len(box):
   print(box[i])
   i += 1

i = 0

box = ['ab','bcd','cde']

while len(box[i])>0 and i < len(box):

print(box[i])

i += 1

Uruchomienie skryptu skończy się błędem

IndexError: list index out of range

Dlaczego? Bo w pewnym momencie i będzie wynosiło 3 i odwołanie do box[i] nie ma sensu. Jeśli jednak zmieni się kolejność warunków w while:

i = 0
box = ['ab','bcd','cde']


while i &lt; len(box) and len(box[i])&gt;0:
   print(box[i])
   i += 1

i = 0

box = ['ab','bcd','cde']

while i < len(box) and len(box[i])>0:

print(box[i])

i += 1

To nim odwołamy się do box[i], najpierw odbędzie się sprawdzenie, czy i<len(box). To wyrażenie zwróci wartość False, a co za tym idzie nie odbędzie się obliczanie dla prawej części wyrażenia and.

Sprytne!

Komentarze (0)

Więcej

By Rafał Kraik in Python

Postgres: Automatyczne przerywanie zapytania po przekroczeniu wartości progrowych

2020-11-15

Postgres pozwala zdefiniować progi wybranych liczników, po przekroczeniu których, aktywność użytkownika może być usunięta z serwera. Kilka z nich to:

deadlock_timeout – czas po jakim zapytanie oczekujące na zwolnienie deadlock ma się „poddać”. Domyślna wartość to 1000 ms. Użytkownik może przedefiniować ten parametr
statement_timeout – czas po jakim długo wykonujące się polecenie ma się przerwać. Można je ustawić globalnie lub dla wybranej funkcji. Domyślna wartość zero oznacza, że takiego limitu nie ma
lock_timeout – czas po jakim długo trwające oczekiwanie na lock ma się przerwać. Ponieważ update statements muszą w pierwszej kolejności uzyskać lock na modyfikowanych rekordach, to lock_timeout powienien być mniejszy niż statement_timeout. Domyślnie ta wartość wynosi zero, co znaczy, że czekanie odbywa się bez limitu. Parametr ustawia się na sesję lub dla funkcji.
idle_in_transaction_session_timeout – maksymalny czas, przez jaki może trwać transakcja nie podejmując żadnych nowych czynności. Jeśli ten czas zostanie przekroczony, to transakcja zostanie wycofana. Domyślna wartość zer określa, że nie ma żadnego limitu.

Technicznie zmiana parametru jest wykonywana poleceniem

SET configuration_parameter TO values;

1	SET configuration_parameter TO values;

Jeśli więc jedna sesja wykonała polecenie:

START TRANSACTION;

DELETE FROM rental WHERE rental_id=2

START TRANSACTION;

DELETE FROM rental WHERE rental_id=2

a druga wykona:

START TRANSACTION;
 
 SET lock_timeout TO 5000;
 
 UPDATE rental SET last_update = NOW() WHERE rental_id = 2

START TRANSACTION;

SET lock_timeout TO 5000;

UPDATE rental SET last_update = NOW() WHERE rental_id = 2

to po ok. 5 sekundach otrzymasz błąd w sesji drugiej:

ERROR: canceling statement due to lock timeout
CONTEXT: while locking tuple (0,1) in relation „rental”
SQL state: 55P03

Aby przywrócić oryginalną wartość parametru wystarczy wykonać:

SET lock_timeout TO values;

1	SET lock_timeout TO values;

Komentarze (0)

Więcej

By Rafał Kraik in PostgreSQL

PostgreSQL: Sprawdzanie aktywności na serwerze

2020-11-08

Jednym z zadań administratora jest obserwacja aktywności użytkowników i w skrajnych przypadkach przerwanie niepoprawnych lub zbyt intensywnych zapytań.

Sprawdzenie aktywności można wykonać poleceniem

SELECT * FROM pg_stat_activity;

1	SELECT * FROM pg_stat_activity;

W odpowiedzi zostanie zwrócony data set zawierający informacje o tym kto i co w danej chwili robi na serwerze:

Czytaj dalej »

Komentarze (0)

Więcej

By Rafał Kraik in PostgreSQL

Postgres: pg_hba.conf – ograniczanie połączeń z określonych IP

2020-11-08

Postgres można skonfigurować do przyjmowania połączeń tylko z określonych adresów IP. Służy do tego konfiguracja zapisana w pliku pg_hpa.conf. To nie jest tak, że jeśli adres IP zostanie wprowadzony do tego pliku, to połączenie będzie po prostu nawiązywane (poza metodą „trust”). Konieczność jakiegoś uwierzytelnienia będzie zawsze obowiązywać. Plik ten należy traktować raczej jako dodatkowy front obrony. Jeśli są jakieś sieci lub adresy z których można się łączyć, to muszą tu być dodane, a jeśli chcesz żeby połączenie się nie odbywało, to albo dodaj taki adres z wpisem „reject”, albo po prostu nie dodawaj go do pliku. Modyfikacja pliku wymaga restartu serwera.

Plik jest czytany od góry do dołu i jego analiza kończy sie w momencie napotkania pierwszego pasującego wpisu. Np. konfiguracja w tej postaci:

# TYPE DATABASE USER ADDRESS METHOD

# following 2 lines were added to provoke connection failure on the local host
host all all 127.0.0.1/32 reject
host all all ::1/128 reject
# "local" is for Unix domain socket connections only
local all all scram-sha-256
# IPv4 local connections:
host all all 127.0.0.1/32 scram-sha-256
# IPv6 local connections:
host all all ::1/128 scram-sha-256
# Allow replication connections from localhost, by a user with the
# replication privilege.
local replication all scram-sha-256
host replication all 127.0.0.1/32 scram-sha-256
host replication all ::1/128 scram-sha-256

# TYPE DATABASE USER ADDRESS METHOD

# following 2 lines were added to provoke connection failure on the local host

host all all 127.0.0.1/32 reject

host all all ::1/128 reject

# "local" is for Unix domain socket connections only

local all all scram-sha-256

# IPv4 local connections:

host all all 127.0.0.1/32 scram-sha-256

# IPv6 local connections:

host all all ::1/128 scram-sha-256

# Allow replication connections from localhost, by a user with the

# replication privilege.

local replication all scram-sha-256

host replication all 127.0.0.1/32 scram-sha-256

host replication all ::1/128 scram-sha-256

spowoduje zablokowanie połączeń z adresu 127.0.0.1 lub z odpowiednika ipv6 ::1. Czytaj dalej »

Komentarze (0)

Więcej

By Rafał Kraik in PostgreSQL

PodtgreSQL: Ważne parametry serwera

2020-11-01

PostgreSQL ma mnóstwo parametrów określających jego pracę, ale kilka jest na prawdę kluczowych:

listen_addresses – adres na którym nasłuchuje serwer i pozwala się łączyć. Można go ustawić na konkretny adres IP, albo zmienić na *, co oznacza każdy interfejs
port – określa port, na którym serwer nasłuchuje. Domyślny port to 5432 – chyba programista wybrał z klawiatury kolejne liczby….
max_connections – ile maksymalnie może być nawiązanych połączeń. Jeśli wartość jest przekroczona, to połączenie koOperationalError: FATAL: sorry, too many clients already
log_destination – określa format generowanych danych i sposób ich generowania. Domyślna opcja stderr określa, że informacje są wysyłane na standardowe wyjście, a pozmianie na csvlog, generowane dane będą w postaci nadającej się do dalszej analizy. Parametr może wymagać włączenia opcji logging_collection
shared_buffers – współdzielona między sesjami pamięć cache, w której są przechowywane strony odczytane z dysku. Zazwyczaj wartość powinna być duża – zależnie od systemu np 25% wielkości pamięci RAM
effective_cache_size – planowana ilość pamięci przewidziana do wykorzystania przez serwer. Wartość wpływa na to, jak serwer zdecyduje się wykonywać zapytania, np. niska ilość pamięci sprawia, że postgres będzie tak planował wykonywanie zapytań, aby w jak najmniejszym stopniu korzystać z pamięci, co zazwyczaj spowoduje wolną pracę serwera
work_mem – maksymalna ilość pamięci przewidziana do wykonania pojedynczej czynności takiej jak sortowanie, join lub scan. Z jednej strony wysoka wartość tego parametru pozwala na szybkie wykonanie zadanej czynności, z drugiej ta wartość musi być pomnożona przez liczbę jednocześnie pracujących użytkowników. Zbyt wysoka wartość spowoduje więc szybką konsumpcję dostęnych zasobów
maintenance_work_mem – opcja podobna do work_mem, ale dotyczy czynności administracyjnych i związanych z housekeepingiem. Nie powinna przekraczać 1GB
max_parallel_workers_per_gather, max_parallel_workers – pozwalają zdefiniować liczbę wątków, które mogą być jednocześnie wykorzystane do wykonania jednego zapytania. Wartość nie może przekraczać max_parallel_workers

Komentarze (0)

Więcej

By Rafał Kraik in PostgreSQL

PostgreSQL: Jak zmieniać konfigurację serwera – postgres.conf

2020-11-01

Serwer PostgreSQL jest konfigurowany za pomocą plików konfiguracyjnych. Te pliki można konfigurować bezpośrednio na poziomie systemu operacyjnego, ale coraz częściej takie podejście nie jest zalecane.

Np. zamiast modyfikować plik postgresql.conf można utworzyć nowy plik o nazwie postgresql.auto.conf i w nim umieścić przedefiniowane wartości parametrów. Jednak i to nie jest najlepsze rozwiązanie. Dodana w kolejnych wersjach posgresa komenda ALTER SYSTEM pozwala wprowadzać modyfikacje systemu z poziomu SQL:

ALTER SYSTEM SET max_connections = 130;

1	ALTER SYSTEM SET max_connections = 130;

Dzięki temu ważne pliki konfiguracyjne pozostają w swojej oryginalnej postaci i co za tym idzie przechowują początkowe ustawienia. Modyfikacja plików wykonywana za pomocą komend pozwala unikać literówek, bądź wprowadzenia nonsensownych ustawień, które pozostają w konflikcie z innymi ustawieniami – polecenie ALTER SYSTEM chroni po prostu administratora przed niepoprawnymi modyfikacjami plików.

(Można też tworzyć własne pliki konfiguracyjne i dołączać je korzystając ze słowa include. Ta możliwość przyda się gdy modyfikujesz dużą liczbę parametrów).

Aktualne wartości parametrów można sprawdzić poleceniem