O dokumentach, procesach, bazach danych i JSON. No i o przyszłości.
Mówiąc o jakichkolwiek procesach biznesowych wcześniej czy później trafiamy na pojęcie dokumentu. To wokół dokumentu buduje się procesy – dokumentem może być jakiś papier wędrujący przez organizację, faktura, sprawa zarejestrowana w jakimś systemie, nadesłany przez klienta email z zażaleniami i tak dalej. Jeśli chcemy taki proces ‘zinformatyzować’ to również dokumenty muszą zostać w jakiś sposób przetworzone na postać cyfrową i zarejestrowane w jakimś systemie.
W przypadku NGinn nastawiłem się na maksymalną elastyczność w temacie dokumentów do których odnoszą się procesy – mianowicie elastyczność wynika z całkowitego pominięcia tego tematu. Procesy w NGinn operują na danych (zostało to opisane we wcześniejszych artykułach) i te dane zawierają wszystkie informacje istotne z punktu widzenia działania procesu. W szczególności założyłem że będą mogły zawierać odnośnik do odpowiedniego dokumentu w systemie zewnętrznym – na przykład numer faktury w systemie księgowym albo numer zgłoszenia w systemie wsparcia klientów. Sam system NGinn nie wnika w to w jakim systemie i w jaki sposób są te dokumenty przechowywane, natomiast oferuje mechanizmy integracyjne pozwalające na wymianę danych z takimi systemami i pobieranie odpowiednich informacji o dokumencie jeśli to konieczne. To pozwala twierdzić że NGinn znakomicie nadaje się do rozszerzania możliwości istniejących w firmie systemów oraz do ich integrowania, ale zupełnie pomija przypadek gdy odpowiedniego systemu nie ma w firmie a dokumenty dopiero czekają na bazę danych która je przechowa. No właśnie, co wtedy?
Pierwszy pomysł to wykorzystanie danych procesu. NGinn pozwala na definiowanie własnych struktur danych dla procesów, więc nic nie stoi na przeszkodzie żeby danymi procesu był cały dokument. Projektujemy strukturę danych tak żeby uwzględnić wszystkie pola dokumentu i wtedy zawartość naszego ‘dokumentu’ jest przechowywana przez NGinn razem z innymi informacjami o procesie. Zaletą jest to że nie musimy się martwić o przechowywanie tych danych, wad za to jest kilka – przede wszystkim dokument istnieje tylko razem z procesem i ‘zamiera’ gdy proces się kończy, dodatkowo NGinn bardzo ogranicza to co można zrobić z danymi procesu. Tak więc ten sposób jest dobry tylko dla prostych struktur danych, nieistotnych poza procesem który ich dotyczy.
Druga możliwość wiąże się z pewną rozbudową NGinn. Otóż w tej chwili NGinn przechowuje stan procesów i zadań w postaci JSON. Każde zadanie zapisywane jest w postaci pojedynczego dokumentu JSON zawieracjącego wszystkie jego dane i informacje potrzebne do działania procesu. Dzięki temu mamy elastyczność i dowolność w definiowaniu struktury procesu i jego danych. No i jeśli byśmy chcieli rozszerzyć NGinn o bazę dokumentów to możemy po prostu wykorzystać ten sam mechanizm i przechowywać dowolne dokumenty w postaci JSON – wtedy zarówno dokument jak i proces toczący się wokół niego były by obsługiwane w ten sam sposób, jako dokumenty JSON. Pomysł interesujący według mnie, ale czy są z nim jakieś problemy?
Są, ale to raczej ‘wyzwania’ niż problemy. Chodzi o to że w tej chwili do przechowywania dokumentów JSON ze stanem procesu jest wykorzystywana baza danych (MSSQL) – jest tam jedna tabela z polem tekstowym (ntext) do której wrzucany jest cały dokument JSON. Dla NGinn to jest wystarczające, ale gdybyśmy w ten sposób chcieli przechowywać dokumenty z danymi które chcemy przeszukiwać to szybko się okaże że szukanie odpada, nie da się efektywnie takiej postaci danych przeszukiwać a i aktualizacja jest mocno ograniczona. Rozwiązaniem według mnie jest przejście na nierelacyjną bazę danych, na przykład taką przeznaczoną do obsługi dokumentów JSON. Takich baz danych jest bardzo wiele, komercyjnych i darmowych. Powstały jako ‘back-end’ dla serwisów internetowych obsługujących bardzo duży ruch i wymagacjących ogromnej skalowalności bazy danych – np bardzo popularnych serwisów społecznościwych i sprawdzają się w takich zastosowaniach o wiele lepiej niż bazy relacyjne. Dodatkowo są bardzo elastyczne jeśli chodzi o struktury danych, a to jest wg mnie kluczowa sprawa przy obsłudze dużych (raczej bardzo dużych) ilości dokumentów. Wystarczy pomyśleć co się dzieje gdy chcemy np zmienić strukturę istniejącej bazy relacyjnej:
- czas: jeśli tabela jest bardzo duża (miliony rekordów) to dodanie nowej kolumny może trwać bardzo długo gdyż może wywołać zwiększenie rozmiaru rekordu i reorganizację całego pliku bazy danych. Długo to znaczy np 5 godzin, gdy nasze ‘okienko serwisowe’ to 30 minut.
- dostępność: na czas aktualizacji bazy relacyjnej musimy wyłączyć aplikację gdyż operacje modyfikacji bazy wykluczają jej odczyt (blokada dostępu do tabel na czas aktualizacji)
- inne problemy: np konieczność zdejmowania i ponownego zakładania constraintów przy operacjach na danych, czasami prosta aktualizacja wymaga niezmiernie skomplikowanych operacji na więzach integralności i indeksach
- no właśnie, indeksowanie, nie można z nim przesadzić gdyż nadmierne poindeksowanie danych spowalnia ich aktualizację
W przypadku bazy dokumentów JSON nie musimy w żaden sposób zmieniać jej struktury gdy modyfikujemy strukturę naszych dokumentów, zaś indeksowanie jest w trybie ‘offline’ czyli nie wpływa na wydajność aktualizacji. Dodając do tego fakt że JSON jest podstawowym formatem dokumentu w NGinn użycie tekstowej bazy dokumentów wydaje się naturalnym pomysłem. A dobrym kandydatem wydaje mi się baza ‘Persevere’ (http://www.persvr.org/) – jest to kompletna baza danych dokumentów JSON z dostępem poprzez HTTP/REST i z rozbudowanymi funkcjami ‘bazodanowymi’ takimi jak indeksowanie, przeszukiwanie czy zarządzanie zawartością bazy. Polecam zapoznanie się choć pobieżnie z jego możliwościami oraz potencjalnymi zastosowaniami, wg mnie to bardzo otwiera oczy na możliwości tych ‘nowych’ baz danych oraz ich potencjalne zastosowania. Jak by wyglądał NGinn po przejściu na bazę Persevere (lub inną tego typu)? Przede wszystkim myślę że wtedy nie będzie używał żadnej bazy relacyjnej, a po drugie myślę że byłby wydajniejszy i bardziej elastyczny, zwłaszcza gdyby dać możliwość dowolnego indeksowania dokumentów i danych w procesach w celu ich łatwego przeszukiwania. Na pewno poświęcę temu niedługo więcej czasu.
P.S. Bazy w rodzaju Persevere zwykle nie obsługują transakcji rozproszonych ani two-phase commit. To jest duże ograniczenie dla NGinn i główny problem do przezwyciężenia. Chodzi o to że w tej chwili NGinn wykorzystuje transakcje rozproszone (transactionscope) do zapewnienia spójności stanu procesu w razie jakichś problemów.
