Projektowanie systemu. Różnice pomiędzy grafową oraz relacyjną bazą danych

Odpowiedni wybór bazy danych jest bardzo istotny w planowaniu, implementacji, utrzymaniu oraz w dalszym rozwoju każdego systemu. Reprezentacja danych może ułatwić lub utrudnić dalsze prace. Obecnie możemy wybierać spośród wielu rozwiązań. Najbardziej popularne są bazy dokumentowe oraz relacyjne. Stosunkowo od niedawna możemy również zastosować grafową bazę danych. W tym artykule skupię się na porównaniu relacyjnej oraz grafowej bazy danych z punktu widzenia CTO w zakresie projektowania systemu.

Franciszek Poniedziałek. Javascript developer w Tectonic Interactive. Do 2017 roku Head of Technology w Devolution Software House. Absolutny pragmatyk i racjonalista. Aktualnie pracuje nad startupem związanym z branżą Bar & Nightclub. Pasjonat literatury, muzyki i przyrody.

Projektowanie aplikacji

Będąc programistą, przywykłem do projektowania systemu opierając się głównie na wymaganiach oraz diagramie bazy danych. Z mojego punktu widzenia wybór bazy był prosty — jeśli system miał mieć kilka kolekcji i nie było planu dalszego rozszerzania zbioru danych, wybór padał na dokumentową bazę danych. Z drugiej strony, jeśli system miał mieć wiele powiązanych ze sobą tabel lub istniały plany dalszego rozwoju systemu, wybór padał na bazę relacyjną. Z punktu widzenia CTO sprawa jest nieco bardziej skomplikowana.

Każdy projekt składa się z wielu ściśle powiązanych ze sobą elementów. Poczynając od budżetu (który, jak wiadomo jest nieprzekraczalny) poprzez odpowiedni wybór technologii, znalezienie odpowiedniego zespołu czy hostingu. Każdy z tych elementów powinien być odpowiednio przemyślany.

Zobacz też

Backend Od hackathonu do pracy w Allegro. Historia Patryka Gutenplana

Reprezentacja danych

Zbiór połączonych ze sobą tabel to najpopularniejszy sposób reprezentacji danych. Już od lat 80-tych podejście to stosuje się w obszarach takich jak księgowość, przemysł czy logistyka. Odpowiednia konstrukcja modelu relacyjnego jest jednak pewną abstrakcją, ponieważ relacje oczywiste dla człowieka jak student — uniwersytet czy pracownik — fabryka muszą zostać przekształcone w encje powiązane relacjami 1 – 1, M – 1 lub M : N. Poniższy schemat przedstawia bazę danych systemu zarządzania serwerownią.

Grafowa baza danych pozwala na znacznie prostsze tworzenie modelu. W uproszczeniu można stwierdzić, że tworzenie diagramu jest działaniem naturalnym i praktycznie każdy z nas świadomie lub nie przynajmniej raz taki model stworzył. Przedstawiając pomysły, często rysujemy elementy połączone ze sobą za pomocą strzałek. Schemat grafowej bazy danych wygląda bardzo podobnie. Znajomość terminów takich jak encja czy relacja jest dość powszechne. W przypadku grafowej bazy danych spróbujmy jednak zdefiniować jej podstawowe elementy.

Node (wierzchołek) -​- mniej więcej odpowiednik encji,

Edge (krawędź) — ​reprezentuje połączenie między wierzchołkami. Zawsze ma swój początek i koniec. Nazwa i kierunek relacji pomagają ustalić kontekst semantyczny, łącząc dwa wierzchołki w sensowny sposób,

Label (etykieta) — ​określa rolę wierzchołka w grafie,

Property​ (właściwość) -​- elementy typu klucz — wartość, są one elementami wierzchołków lub krawędzi.

Powyższy diagram przedstawia model grafowej bazy danych systemu zarządzania serwerownią. Istnieje jedna bardzo ważna różnica między oboma diagramami (relacyjnym i graficznym). Powyższy model przedstawia tylko jedną instancję (wierzchołek) każdego z istniejących asset’ów. Taki model można łatwo rozszerzyć, dodając dodatkowe wierzchołki i krawędzie, nie martwiąc się o migracje.

Modyfikacja modelu

RDBMS

W świecie encji i relacji budujemy model bazy danych oparty na sztywnym schemacie. Oczywiście, możemy rozszerzać model poprzez dodanie większej liczby encji i relacji, ale wymaga to ciągłego dbania o migracje czy spójność seed’ów. W przypadku RDBMS całkowita zmiana modelu pociąga za sobą istotną przebudowę istniejącego systemu.

Graph DB

W świecie wierzchołków i krawędzi możemy zapomnieć o sztywnym modelu czy migracjach. Cały model jest budowany “on the fly”, co oznacza, że w każdej chwili możemy stworzyć dowolny wierzchołek, z dowolnymi właściwościami czy krawędziami. W świecie szybko zmieniających się wymagań projektowych jest to ogromna zaleta.

Oferty pracy z

Zastosowanie

Relacyjna baza danych to dobre rozwiązanie dla prawie każdego systemu, który nie musi wyszukiwać “mutual connections”. Główne typy zadań idealne dla RDBMS:

• Inventory / warehouse records management,
• Employee management,
• Financial records,
• Manufacturing records,
• Logistical information.

Grafowa baza danych to z kolei świetne rozwiązanie, kiedy wyszukiwanie “mutual
connections” jest koniecznością. Oto najczęstsze obszary stosowania rozwiązań grafowych:

• Social networks,
• Recommendations systems,
• Music management,
• Data center management,
• Time series of trade.

Performance

Powyższy benchmark zaczerpnąłem z książki „Graph Databases by Ian Robinson, Jim Webber and Emil Eifrem”. Porównuje on wydajność rozwiązania relacyjnego oraz grafowego w zadaniu znajdowania “mutual friends” lub bardziej ogólnie znajdowanie wzajemnych powiązań w danych. Jak widać, relacyjna baza danych kiepsko radzi sobie z takimi zadaniami. Należy jednak pamiętać, że zadanie to jest specyficzne dla grafowych baz danych. Istnieją oczywiście zadania, w których relacyjna baza osiąga lepsze rezultaty. Takim zadaniem jest np. modelowanie formularzy papierowych lub struktur tabelarycznych.

Koszty

RDBMS na przykładzie RDS (MySQL) AWS:

• Licencja: zawarta w cenie instancji,
• Estymowany miesięczny koszt utrzymania jednej instancji: 200-400$,
• Miesięczna pensja dewelopera: standardowa dla danego stack’u technologicznego ze znajomością relacyjnych baz danych.

Grafowa baza danych na przykładzie No4j:

• Licencja: 18 tys. Euro rocznie,
• Miesięczny koszt 1 instancji operującej na serwerach Neo4j: 500 euro,
• Miesięczna pensja dewelopera: zdecydowanie wyższa (2-3 krotnie) w porównaniu do
  rozwiązania relacyjnego.

Deweloperzy

Ostatnim elementem, który chciałbym krótko omówić, jest dostępność programistów z wybranym stack’iem technologicznym. Jeśli mamy budżet, wybraliśmy technologie oraz mamy świetny projekt systemu, to nie zrobimy niczego, jeśli nie znajdziemy właściwych ludzi. W przypadku stack’u Node.js + Neo4j znalezienie kompetentnego i dostępnego dewelopera jest naprawdę trudnym zadaniem.

Podsumowanie

Projektowanie systemów jest interesującą i naprawdę obszerną dziedziną wiedzy. Podczas projektowania należy wziąć pod uwagę takie czynniki, jak budżet, dostępność ludzi, stack technologiczny oraz deadline. Dobrze jest również pamiętać, że technologia jest tylko narzędziem. Nie ma dobrej technologii do wszystkiego, a nawyki i preferencje deweloperów nie są niestety jedynym czynnikiem, który należy wziąć pod uwagę przy wyborze optymalnego rozwiązania. Mam nadzieję, że mój tekst nieco wyjaśnił główne różnice pomiędzy grafową oraz relacyjną bazą danych.

Zdjęcie główne artykułu pochodzi z stocksnap.io.