Od kilku dni piszę sobie proste aplikacyjki testowe na platformie CouchDB, stanowiącej jeden z przykładów jak może wyglądać baza danych bez SQL (patrz NoSQL). Dla osoby przyzwyczajonej do tabel i zapytań SQL jest to całkowita zmiana myślenia o strukturach danych i sposobach ich odpytywania. Wymaga tego przede wszystkim projektowanie funkcji, która wywołana dla każdego "rekordu" w bazie zwróci tylko te, które nas interesują (Map) i drugiej, która je dodatkowo zagreguje, zsumuje czy co tam jeszcze potrzeba (Reduce).

Wszystko w imię zrównoleglenia, ale to akurat żadna niespodzianka bo nawet konkursy na algorytmy kryptograficzne jako jeden z wymogów stawiają wydajne przetwarzanie równoległe. Dużą barierą mentalną w korzystaniu z tych technologii stanowi fakt, że takie formy przetwarzania danych mogą zwracać wyniki nie w pełni precyzyjne. A ściślej takie, których precyzja rośnie z czasem.

Taka metoda liczenia nie ma raczej sensu gdy przygotujemy zlecenie przelewów pensji do banku albo liczymy pozycje na fakturze, bo deterministyczny wynik jest potrzebny tu i teraz. Ale ma głęboki sens gdy chcemy przeszukać bazę faktur zawierającą 100 tys. pozycji albo wyświetlić zgrubne wyniki sprzedaży za ostatnie kilka lat.

Kiedy odbiorcą tych wyników jest człowiek, to taka zmienna w czasie precyzja jest zupełnie wystarczająca. Można się o tym przekonać wyszukując coś w Google czy Facebooku - pierwsze strony wyników wyświetlają się momentalnie i zawierają zapewne jakieś 90% wyników. Gdy je przeglądamy swoim powolnym, ludzkim tempem, system spokojnie dalej generuje ..setne strony wyników, zbliżając się do stuprocentowej precyzji. Wystarczy myśleć o przetwarzaniu deterministycznym jako o metodzie droższej i bardziej czasochłonnej, i stosować ją po prostu tam gdzie potrzeba.

Z punktu widzenia bezpieczeństwa to też trochę nowa architektura, choć nie do końca. Ponieważ baza danych nie zwraca statycznego zbioru wyników, tylko ciągle wyrzuca nowe rekordy, strona musi być aktualizowana przez działający po stronie klienta JavaScript. To komplikuje analizę kodu takich aplikacji bo poszczególne funkcje są podzielone między klientem a serwerem. Dominującym formatem wymiany danych między klientem a serwerem jest surowy JSON, i dopiero po stronie klienta jest on przepakowywany w ładnie wyglądający HTML. Czas zaprzyjaźnić się z analizą granic zaufania..

W przypadku CouchDB na programistów czyha jeszcze jedna pułapka - JavaScript jest podstawowym językiem programowania zapytań po stronie bazy (czyli coś jak stored procedures w SQL) i łatwo iejest stracić rachubę, który JavaScript gdzie się uruchamia. A co za tym idzie, które dane gdzie filtrować i walidować. Zapuszczenie popularnego skanera BurpSuite na kilku popularnych aplikacjach przykładowych w CouchDB zwróciło dłuugą listę dziur, głównie Cross-Site Scripting. Czas zainteresować programistów piszących w CouchDB modułem OWASP ESAPI JS...