SQL

by aljandor on Dump Links, Git, PostgreSQL, SQL

Dump links #27

Przy piątku pora na zrzut linków.

  • https://dev.to/tiaeastwood/how-to-create-a-fake-rest-api-for-your-project-with-json-server-214e
  • https://adamj.eu/tech/2022/06/20/how-to-find-and-stop-running-queries-on-postgresql/
  • https://explain.dalibo.com/
  • https://idea-instructions.com/
  • https://github.com/Netflix/suro
  • https://riemann.io
  • https://lbrito1.github.io/blog/2020/02/repurposing-android.html
  • https://architecturenotes.co/things-you-should-know-about-databases/
  • https://en.m.wikipedia.org/wiki/Punycode
  • https://www.depesz.com/2022/07/05/understanding-pg_stat_activity/
  • https://github.com/WangYihang/GitHacker
  • https://semaphoreci.com/blog/monolith-microservices
  • https://dev.to/dailydevtips1/using-the-native-web-share-javascript-api-23ei

 

 
by aljandor on Aljandor, Kontrola wersji, PHP, PostgreSQL, Projekty, Python, różności, SQL, Web

Deployment – jak je robimy?

Zależnie od inftastruktury aplikacji, jej architektury zawsze planujemy deplyment tak aby był jak najmniej uciążliwy dla użytkownika końcowego systemu. Często nasze stsytemy aktualizujemy podczas nocnych okienek serwisowych. I tak jedna z aplikacji, która ma 20, a w sezonie 30-40 req/sec jest aktualizowana głównie poza sezonem. W trakcie szczytu, gdzie dziennie jest kilkadziesiąt tysięcy wizyt przeprowadzamy jedynie krytyczne poprawki – jeśli są niezbędne do prawidłowego oraz stabilnego działania systemu.

Poza sezonem aplikacja jest aktualizowana we wtorki oraz czwartki, w godzinach 16-18. Zmiany są przygotowywane oraz testowane we wcześniejszym tygodniu. Jeśli trwa sezon, utrzymuje się spory ruch, deployment przeprowadzamy jedynie w nocnych oknach serwisowych – które zaczyna się od 1 w nocy, a kończy o 3 rano.

Każde z wdrożeń niezależnie od pory jest możliwe do cofnięcia w krótkim czasie. Jeśli aktualizujemy większa aplikacje często przepinamy ruch na czas wdrożenia na zapasowe środowisko produkcyjne (które jest w stanie przejęć 100% ruchu w razie problemów z głównym środowiskiem) tak aby zminimalizować ryzyko down time (metoda Blue-Green).

 
by aljandor on PostgreSQL, SQL

TimeStamp w PostgreSQL

Każdy kto pracuje z PostgreSQL używał wbudowanej funkcji NOW() – zwraca ona 'aktualny’ TimeStamp. Jednak czas jaki zwraca funkcja może w niektórych przypadkach nieco zmylić.

poniżej prosty select:

aljandor=# select now();
              now
-------------------------------
 2017-02-28 19:34:50.054909+00
(1 row)

aljandor=# select now();
              now
-------------------------------
 2017-02-28 19:35:23.217189+00
(1 row)

zobaczmy co się stanie jeśli zawrzemy dwa powyższe selecty w transakcji:

aljandor=# BEGIN;
BEGIN

aljandor=# select now();
              now
-------------------------------
 2017-02-28 19:40:28.228707+00
(1 row)

aljandor=# select now();
              now
-------------------------------
 2017-02-28 19:40:28.228707+00
(1 row)

aljandor=# COMMIT;
COMMIT

 

Zdziwiony? Dzieje się tak, iż funkcja now() zwraca time-samp czasu rozpoczęcia transakcji. Tak więc jeśli potrzebny nam dokładny znacznik czasu, użyjmy funkcji clock_timestamp():

aljandor=# BEGIN;
BEGIN

aljandor=# select clock_timestamp();
       clock_timestamp
-----------------------------
 2017-02-28 19:45:38.977532+00
(1 row)

aljandor=# select clock_timestamp();
        clock_timestamp
-------------------------------
 2017-02-28 19:45:43.540535+00
(1 row)

aljandor=# COMMIT;
COMMIT

jak widać, funkcja zwraca zawsze aktualny time-stamp. Nieświadome używanie funkcji now() może powodować bardzo groźne sytuacje w przypadkach dla których ważne jest utrzymanie rzeczywistego znacznika czasu.

 

 
by aljandor on SQL

Globalna zmiana czasu w phpbb3

Gry potrzebujemy zmienić czas z zimowego na letni (lub odwrotnie) zmiana strefy czasowej w panelu administracyjnym nie jest wystarczająca. Użytkownicy którzy są już zarejestrowani muszą ręcznie samemu zmienić swoją strefę czasową w profilu użytkownika. Możemy im to ułatwić zmieniając globalnie wszystkim użytkownikom strefę czasową wykonując odpowiednio poniższe zapytania SQL:

Zmiana ustawień strefy czasowej w panelu administracji nie wystarczy. Różnice zauważą wtedy tylko goście. Zarejestrowani użytkownicy muszą samemu zmienić ustawienia swojego profilu (Moje konto => Ustawienia witryny). Mając dostęp do phpMyAdmina, możemy dokonać masowej zmiany czasu dla użytkowników, przez odpowiednie zapytanie SQL.

Zmiana czasu na zimowy:

UPDATE forum_users SET user_dst = 0 WHERE user_timezone = 1.00;

zmiana czasu na letni:

UPDATE forum_users SET user_dst = 1 WHERE user_timezone = 1.00;

Dodatkowo opakowałem oba SQL’e w procedury -> dzięki temu nie trzeba ich wklepywać od zera tylko wykonujemy procedurę.