Bazy danych skazane na rozproszenie

W czasach dzisiejszych, gdy biznesy często są globalne a działalność operacyjna większości przedsiębiorstw opiera się na systemy informatyczne, pojawiają się problemy z dostępnością danych czy serwisu ogółem. Zcentralizowane systemy jak najbardziej zdają egzaminy w większości przypadków, da się bez problemu używać z systemu uruchomionego w Europie będąc fizycznie w Australii czy na Hawajach, ale doświadczenie klientów z takimi systemami może być oceniane średnio – głównie za sprawą niskiej wydajności sieci. Choć o tzw latency rzędu maks 2s-3s można było kiedyś tylko pomarzyć – pamiętam jeszcze czasy dial-up i te długie minuty buforyzowania filmiku na youtube, – ale w dziś takie czasy odpowiedzi już są uznawane za mauvais ton.

Inżynierowie systemów informatycznych borykają się z problemamy wydajnościowymi chyba od udostępnienia pierwszych publicznych serwisów, czy to bankowych systemów transakcyjnych czy zwykłej strony internetowej. Często dla rzadko zmieniających się danych stosuje się cache, czy to na CDN, czy w web serwerze czy jakiś Redis lub podobny. Takie cache są ok, aż do momentu jak dane zaczną się zmieniać tak często że koszt aktualizacji cache jest większy od round-tripa do instancji bazy.

Czytaj dalej

Kiedy wybieram AWS DynamoDB, zaczynam liczyć bajty

Tak jest. Maksymalny rozmiar wpisu w tabeli DynamoDB wynosi 400KB, jak wskazuje oficjalna dokumentacja. Natomiast, oficjalna dokumentacja nie wspomina o metodzie wyliczania rozmiaru wpisu.

Otóż, na końcowy rozmiar wpisu w tabeli DynamoDB składa się: rozmiar nazwy atrybutu zakodowane w utf-8 (w większości przypadków będzie to 1 bajt per symbol) oraz rozmiar wartości atrybutu. Rozmiar wartości atrybutu zależy od typu danych wykorzystanych, np. jeśli jest to zwykły string to rozmiarem wartości będzie wartość zakodowana w UTF-8 (od 1 do 4 bajtów na symbol). Jeśli natomiast będzie to Map (objekt w plain JSON), to trzeba doliczyć jeszcze 3 bajty (const) oraz po 1 bajcie na każdą parę klucz-wartość, no i rozmar samych par klucz-wartość też trzeba policzyć – w wyniku tego, nawet pusta mapa będzie miała co najmniej 3 bajty.

400KB to jest wystarczajćo dla mniejszych dokumentów, natomiast kiedy dokumenty przechowywane w DynamoDB są generowane na podstawie danych wprowadzonych przez użytkowników, to trzeba liczyć się z tym, że prędziej czy później dostaniemy błąd

An error occurred (ValidationException) when calling the PutItem operation: Item size has exceeded the maximum allowed size
Czytaj dalej

Optymalizacja implementacji `Insert or Update` zapytań na bazie danych

Proszę Państwa, czasem jest potrzeba zrobić coś a’la Insert or Update. Zadanie jest dość trywialne, ale nie zawsze optymalne zarówno pod względem czasu implementacji jak i czasu wykonania – pierwsze co wpada do głowy, to implementacja czterech kroków:

  1. Wyciągnij wpisy z tabeli które spełniają wymagania
  2. Sprawdź czy wynik poprzedniego zapytania jest pusty
  3. Jeśli odpowiedź jest pozytywna – wykonaj UPDATE
  4. W przeciwnym razie wykonaj INSERT

W takich sytuacjach bardzo się przydaje zgłębienie wiedzy w narzędziach i zapytaniach wychodzących poza zakres ANSI SQL np. Transact-SQL (MS Sql Server) lub PL/pgSQL (Postgres). Oba te wyżej wspomniane języki mają cudowne narzędzie umożliwiające wykonanie całej roboty InsertOrUpdate za jednym zapytaniem – tzw UPSERT.

Nazwa pochodzi od połączenia dwóch słów – UPDATE oraz INSERT. Założenie takiej kwerendy jest proste – spróbuj wstawić nowy rekord do tabeli, i w przypadku pojawienia się błędu o duplikacje, zrób update.

Czytaj dalej