Blog

Wraz z rozwojem sprzętu, na którym wykonywany jest kod aplikacji, atomizacją procesów oraz coraz większym zasięgiem technologi informacyjnej, zwiększa się także ilość nierelacyjnych struktur danych. Nie jest to zjawisko nowe, bo taką formę pełniły, i do dziś pełnią pliki, do których mogą sięgać aplikacje. Jednak w miarę powstawania kolejnych rozwiązań, opartych o odrębne, wyspecjalizowane usługi, zwiększa się potrzeba dostępu do danych tego typu z różnych usług i przy wykorzystaniu wydajniejszych metod.

Znacznie swobodniejsze podejście do modeli danych wśród twórców aplikacji, a także tendencja do utrzymywania większego stopnia swobody w zarządzaniu danymi, doprowadziła do tego, że deweloperzy coraz częściej korzystają z danych o dynamicznej strukturze. Dodatkowym aspektem, który należy rozważyć w oparciu o swoją własną ekspertyzę, jest to, czy najmłodsi w naszej branży deweloperzy przykładają należytą staranność do modelowania danych pod kątem najwyższej wydajności? Kolejną istotną kwestią jest to, jakie straty ponosi organizacja na blokowaniu rozwoju nowych technologi kosztem utrzymania rygoru strukturalnego? Spróbujemy wspólnie poszukać odpowiedzi na te ważne pytania.

Odwieczna wojna DBA i deweloperów?

Relacyjne bazy danych bardzo długo nie pozwalały na składowanie danych EAV (nie bez powodu). Jednak nawet najbardziej zaciekły opór DBA nie był w stanie zatrzymać postępu, a w szczególności wyeliminować rozwiązań, które ułatwiają życie deweloperom. Pokrótce przyjrzyjmy się patologiom, które w ostatnich latach zdarzało nam się napotkać w różnorakich systemach. Deweloperzy pozbawieni wsparcia ze strony administratorów, bez wsparcia ze strony silnika bazy danych „radzili” sobie na różne sposoby. Zaczniemy od tych najmniej szkodliwych.

Utrzymywanie w relacyjnej bazie danych klucza, jako identyfikatora w zewnętrznym systemie (np. MongoDB, CouchDB, ElasticSearch etc.). Na pierwszy rzut oka wydaje się to nie być problemem, ot, heterogeniczne środowisko można by rzec. Jednakże każdy szef pionu utrzymania od razu zdaje sobie sprawę, że to kolejna usługa do utrzymania, dla której należy zapewnić plan zachowania ciągłości biznesowej (HA, DR, backupy). To kolejny punkt przechowywania i przetwarzania informacji, dla którego należy stworzyć i utrzymywać zasady bezpieczeństwa, kolejne potencjalne źródło danych do systemów BI, oraz co finalnie najbardziej kosztowne, w odpowiedniej skali kolejne licencje i/lub kompetencje w zespole. Oczywiście w pewnych przypadkach jest to działanie uzasadnione, ale tych przypadków jest naprawdę niewiele (na przykład wyszukiwanie pełnotekstowe w bardzo długich tekstach gdzie systemy oparte o Apache Lucene będą najwydajniejsze). Ale już w wypadku danych w formacie JSON, które nie są przeszukiwane, a jedynie zawierają dane w modelu EAV odnośnie encji, doskonale adresuje ten przykład.

Znacznie gorzej jest, kiedy w bazie, na skutek braku innej możliwości, znajduje się obiekt będący zserializowanym do typu bytea obiektem Python/Java/Ruby etc. W tym wypadku (jeżeli nie takie było zamierzenie) dane czytelne są tylko dla aplikacji. Nie możemy z nich skorzystać do raportowania ani nie możemy wykorzystać większości mechanizmów bazodanowych do takich danych. Czy zatem jesteśmy skazani na nieustanną walkę pomiędzy developerami, a DBA? Czy koniecznie jest namnażanie technologii, aby zaspokoić zapotrzebowanie na nowe rozwiązania? Na szczęście nie.

PostgreSQL sposobem na rozstrzygnięcie sporu?

Z pomocą przychodzą rozszerzenia dostępne w PostgreSQL, a zatem także w EuroDB, pozwalające zaadresować te przypadki.

Pierwszym mechanizmem, który pozwolił na przechowywanie danych, z dużą dozą dowolności, był hstore – prosty mechanizm zapisu park „klucz” => „wartość”. Wśród licznych ograniczeń tego rozwiązania szczególnie dwa są dotkliwe: jeden poziom (brak możliwości zagnieżdżania) oraz obsługa tylko tekstu (zarówno klucz, jak i wartość są z punktu widzenia bazy danych tekstem). Czym zatem hstore różni się od pliku csv lub innego zawierającego dwie kolumny? Format ten pozwala na założenie indeksów oraz wykorzystanie operatorów. Zarówno na kluczach, jak i indeksach (GiST i GIN). Wspierany jest również standard XML, który ciągle jest bardzo popularny w świecie Javy / SOAP. Jednakże z uwagi na wiek tego standardu i stopniowe ograniczanie jego znaczenia, wsparcie dla tego typu danych w bazach danych nie jest już rozwijane, a samo wsparcie w PostgreSQL można śmiało nazwać fragmentem wstecznej kompatybilności.

Finalnie w EuroDB najważniejszą rolę bezschematowego sposobu przechowywania danych jest format JSON i JSONB będący natywną implementacją JavaScript Object Notation. Pozwala ona na zachowanie dowolności w strukturze dokumentu na poziomie konkretnego dokumentu (a nie tabeli). W ramach konkretnego przykładu wyobraźmy sobie nowoczesną aplikację i dostosowany do niej nowoczesny model danych.

Posługujemy się obiektami klasy osoba w naszym systemie, oczywiście istnieją pewnie niezbędne pola (id, imię i nazwisko, pesel) oraz bardzo duża liczba parametrów opcjonalnych. W tym wypadku nie musimy tworzyć tabeli, która ma 1000 kolumn, z czego ogromna większość to NULL.
Taka sytuacja sprowadza się do prostej definicji:

CREATE TABLE osoba (
id SERIAL,
name VARCHAR(128),
pesel VARCHAR(12),
data JSON NOT NULL,
PRIMARY KEY (id)
)

Jednakże na tym nie kończą się benefity. Pole „data” jest zrozumiałe dla silnika, o który oparto EuroDB i zapewnia odpowiednie metody i operacje. Na potrzeby większości podstawowych operacji w systemie wystarczające są kolumny zawarte w tradycyjnym modelu. W polu z dodatkowymi danymi znajdują się dane o tej osobie, takie, jakimi dysponujemy w odpowiednim formacie. Na polach typu JSON możliwe jest:

• tworzenie indeksów w tym też indeksów opartych o wyrażenie (nawet 1000x (sic!) razy szybsze przeszukiwanie)
• pobieranie konkretnych elementów z obiektu (według klucza numerycznego lub tekstowego)
• sprawdzenie, czy obiekt zawiera w sobie zadany element
• weryfikacja, czy zadany element należy do obiektu
• zbadanie, czy w obiekcie istnieje zadany klucz tekstowy (oraz czy istnieje jeden z wielu lub wszystkie)
• konkatenacja obiektów
• usunięcie z obiektu zadanego elementu (wedle klucza, pozycji lub ścieżki)
• funkcje tworzące poprawne obiekty JSON z przekazanych danych lub rekordów
• operator zwracający listę elementów w obiekcie
• rozpakowanie obiektu do krotek klucz wartość
• wyodrębnienie elementu na podstawie ścieżki
• wyodrębnienie wyłącznie kluczy
• wyodrębnienie wyłącznie elementów
• konwersja obiektów JSON na zdefiniowany typ bazodanowy
• weryfikacja struktury danych na najwyższym poziomie obiektu JSON
• pobranie obiektu JSON jako rekordu zdefiniowanego w trakcie pobierania
• pobranie obiektu JSON z pominięciem pól o wartości NULL
• pobranie obiektu JSON podmieniając w locie dowolny fragment w ścieżce.

Zatem mariaż nowoczesnej technologii spełniającej wymogi deweloperów z dobrze znaną i wpieraną platformą bazodanową jest nie tylko możliwy, ale i opłacalny.

Konkluzja

Podsumowując, możliwy jest kompromis pomiędzy tym, co dobre, znane i sprawdzone, a tym, co nowe i kuszące. Możemy pozwolić na rozwój oprogramowania, dopuszczając nieustrukturyzowane dane, a jednocześnie zachować wsparcie producenta i nie mnożyć technologii (tam, gdzie nie jest to niezbędne). Jeżeli chciałbyś dowiedzieć się więcej, skontaktuj się z nami.

tel.: +48 22 243 22 33
e-mail: sales { na } euro-linux.com