Propagator zmian w bazie danych do składów NoSQL

Propagator zmian w bazie danych do
składów NoSQL
Paweł Tarczykowski
Założenia

Wieloplatformowość

Brak zależności od języka programowania

Brak centralnego punktu spójności danych

Przyspieszenie przez zrównoleglenie

Wysoka konfigurowalność
Rozwiązania

Serwer w języku Java

Protokół oparty o framework Thrift



Algorytm propagacji opracowany przez Pawła
Leszczyńskiego
Aplikacja wielowątkowa bazująca na
asymetrycznym zapisie
Konfiguracja w XML oraz YAML
Obsługiwane technologie

Redis

Solr

MongoDB

Cassandra

PostgreSQL
Problemy



Architektura danych w Cassandrze
Generowanie unikalnych ID dla składów, które
same tego nie potrafią
Connection Pooling
Konfigurowanie aplikacji

Konfiguracja aplikacji jest podzielona na dwie
części

Konfiguracja składów – XML

Konfiguracja schematu - YAML
Konfigurowanie składów
<remote>
<name>Postgres</name>
<host>localhost</host>
<port>5432</port>
<user>farrel</user>
<password>haslo</password>
<driver>pl.umk.mat.propagator.driver.Postgres</driver>
<connections>1</connections>
<threads>1</threads>
<properties>
<database>farrel</database>
</properties>
</remote>
Sterowniki

Aby sterownik był poprawnie rozpoznany przez
serwer musi:

Odziedziczyć po klasie BaseDriver

Implementować jeden z dostępnych interfejsów:





FullTextSearch
DocumentStorage
KeyValue
MultiColumn
DataBase
Konfigurowanie schematu

Konfiguracja jest podzielona dwie części


Relacje – abstrakcyjny model danych, model na
którym operuje użytkownik
Projekcje – rozbicie relacji na różne składy danych,
model, na którym pracuje serwer
Konfigurowanie schematu
- name: book
primaryProjection: book_financial
attributes:
- { name: id, type: int }
- { name: author, type: text }
- { name: title, type: text }
- { name: price, type: float }
- { name: nb_of_items, type: int }
Konfigurowanie schematu
- name: book_financial
storageId: rdbms_1
primaryRelation: book
attributes:
- { name: id }
- { name: price }
- { name: nb_of_items }
Schemat działania serwera

Jeden wątek główny na żądanie




Ma dostęp do kolejek zadań dla wątków
pobocznych
Wykonuje podział żądania na mniejsze zadania
przy pomocy grafu
Wykonuje zadania pierwszorzędne dla utrzymania
spójności danych
Loguje zlecenie zadań drugorzędnych wątkom
pobocznym
Schemat działania serwera

Stała liczba wątków pobocznych



Pobiera z kolejki zadań zadanie drugorzędne i
wykonuje je
Loguje wykonanie zadania
Dwa wątki loggerów

Log zadań zleconych

Log zadań wykonanych

Przy starcie aplikacji czytane są oba logi

Zadania, które zostały zlecone, a nie zostały
wykonane zostają zlecone ponownie
Algorytm propagacji

Ograniczenia algorytmu

Brak możliwości użycia relacji wiele do wielu

Operacje na pojedynczych krotkach
Algorytm Propagacji

Krok 1


Jeśli typ modyfikacji to insert to dodajemy
odpowiednie pola do projekcji głównej
modyfikowanej relacji w celu uzyskania klucza
głównego
Krok 2

Wyszukujemy resztę projekcji, które będą
modyfikowane przez nasze rządanie
Algorytm Propagacji

Krok 3


Jeśli projekcja ma jako pierwszorzędną relację
którą modyfikujemy wykonujemy odpowiednią
operację
Jeśli nie wyszukujemy po kluczu obcym krotki, które
należy zmodyfikować i wykonujemy zmianę według
zdefiniowanego w schemacie operatora.
Dziękuję