Propagator zmian w bazie danych do składów NoSQL
Transkrypt
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ę