nieoptymalne zapytania do CRM

Nieoptymalne zapytania do CRM to pobieranie pełnych rekordów tam, gdzie wystarczyłyby wybrane pola.

Techniczne uwarunkowania pobierania danych z systemów CRM

W architekturze systemów klasy Customer Relationship Management (CRM) wymiana informacji między bazą danych, serwerem aplikacyjnym oraz klientem końcowym opiera się na ściśle zdefiniowanych zapytaniach. Nieoptymalne konstruowanie tych zapytań, najczęściej objawiające się pobieraniem kompletnych rekordów w sytuacjach wymagających jedynie wycinka informacji, to jeden z głównych czynników degradujących wydajność. Problem ten wynika nierzadko ze stosowania mapowania obiektowo-relacyjnego (ORM), które w domyślnej konfiguracji zachęca do operowania na pełnych encjach. Przykładowo, pobranie listy klientów do wyświetlenia w prostej tabeli zawierającej tylko imię, nazwisko i adres e-mail, może w tle skutkować wykonaniem instrukcji równoważnej do SQL-owego polecenia SELECT *. W rezultacie silnik relacyjnej bazy danych odczytuje z dysku lub pamięci podręcznej wszystkie kolumny przypisane do danej tabeli, w tym obszerne pola tekstowe z notatkami, historię zmian, flagi statusów oraz klucze obce do tabel powiązanych.

Zjawisko to ma bezpośrednie przełożenie na każdą warstwę infrastruktury. Po stronie serwera bazy danych następuje niepotrzebne obciążenie podsystemu wejścia/wyjścia (I/O) oraz zajmowanie cennej przestrzeni w buforach pamięci operacyjnej (buffer pool). Następnie, nadmiarowe dane muszą zostać przesłane przez sieć lokalną lub publiczną do serwera aplikacyjnego. Tam z kolei następuje proces deserializacji lub mapowania na obiekty w pamięci, co konsumuje cykle procesora i alokuje pamięć RAM. W przypadkach dużych systemów, dla tabel zawierających kilkadziesiąt kolumn i tysiące wierszy, różnica w wielkości transferowanego ładunku (payload) między zoptymalizowanym zapytaniem a zapytaniem nieoptymalnym wynosi od kilku do kilkunastu megabajtów na pojedyncze żądanie. Z perspektywy inżynierii oprogramowania jest to marnotrawstwo zasobów, które w miarę wzrostu liczby jednoczesnych użytkowników prowadzi do zauważalnych opóźnień (latency) i obniżenia przepustowości całego środowiska sieciowego.

Analiza narzutu wydajnościowego i mechanizmy selekcji danych

Zrozumienie skali zjawiska wymaga analizy tego, co zachodzi w architekturze w momencie wykonania nieoptymalnego zapytania. Kiedy aplikacja CRM żąda pełnego rekordu, silnik bazy danych musi odnaleźć odpowiednie strony danych na nośnikach lub w pamięci. Jeżeli rekord zawiera typy danych o dużej pojemności, takie jak BLOB (Binary Large Object) używane do przechowywania plików binarnego formatu lub TEXT dla długich komentarzy, serwer często zmuszony jest wykonać dodatkowe operacje odczytu z niezależnych obszarów alokacji, ponieważ takie informacje rzadko są przechowywane bezpośrednio w głównym klastrze wiersza. Przesyłanie takich nadmiarowych bloków zatyka pasmo transmisyjne. Zoptymalizowane podejście opiera się na technice określanej jako projekcja (projection). Polega ona na jawnym zdefiniowaniu w warstwie kodu wyłącznie tych atrybutów, które w danej transakcji są niezbędne do realizacji logiki biznesowej lub wygenerowania docelowego widoku dla klienta.

W środowiskach wykorzystujących interfejsy programistyczne REST (Representational State Transfer), inżynierowie wdrażają mechanizmy nazywane Sparse Fieldsets. Dają one klientowi możliwość określenia żądanych pól poprzez parametry w adresie URL. W architekturach opartych na języku GraphQL selektywność zapytań stanowi integralny element samego standardu wymiany danych. Klient jest zobowiązany jawnie wyspecyfikować strukturę, którą chce uzyskać, co eliminuje problem nadmiarowego pobierania encji już w fazie projektowania interfejsu. Na poziomie warstwy dostępu do danych (Data Access Layer), zastosowanie obiektów transferu danych (DTO - Data Transfer Objects) połączone ze zoptymalizowanymi zapytaniami z użyciem narzędzi ORM, zapewnia przekazywanie do pamięci serwera aplikacyjnego wyłącznie przetworzonych, zredukowanych struktur. Rozwiązania te obniżają zapotrzebowanie na pamięć i skracają czas przetwarzania informacji przez jednostkę centralną.

Skutki uboczne i diagnozowanie przeciążenia infrastruktury serwerowej

Brak optymalizacji zapytań w kodzie systemów CRM skutkuje ciągiem sprzężonych ze sobą problemów operacyjnych, które stają się dostrzegalne w trakcie skalowania platformy. Pierwotnym, zewnętrznym symptomem są wydłużone czasy odpowiedzi interfejsu, jednak przyczyny źródłowe tkwią na niższych poziomach architektury. Nadmiarowe informacje alokowane w stercie (heap) serwera aplikacyjnego wymuszają częstsze inicjowanie procesów odśmiecania pamięci (Garbage Collection). Przy wystąpieniu mechanizmu Stop-The-World, funkcjonowanie aplikacji ulega wstrzymaniu na czas zwolnienia nieużywanych referencji, co powoduje skoki opóźnień (latency spikes). Na poziomie serwera bazodanowego, obciążanie buforów pełnymi wierszami prowadzi do zjawiska szybkiego wypłukiwania często używanych indeksów z pamięci podręcznej. Skutkuje to zwiększoną liczbą odwołań do wolniejszych nośników fizycznych zamiast bezpośredniej obsługi żądań z szybkiej pamięci RAM.

Współistniejącym problemem jest nasycanie puli połączeń do bazy danych (connection pool exhaustion). Szerokie zapytania przetwarzają się dłużej, w związku z czym pojedyncza sesja pozostaje zablokowana. Przy narastającej liczbie równoległych żądań HTTP, kolejne wątki aplikacyjne oczekują na alokację połączenia, tworząc wąskie gardła. W celu diagnozowania opisanych defektów, zespoły techniczne polegają na oprogramowaniu klasy Application Performance Monitoring (APM), profilerach kodu oraz systemach analizy planów wykonania (execution plans) zagnieżdżonych w silnikach SQL. Zestawy te umożliwiają lokalizację zapytań obciążonych największym kosztem I/O oraz identyfikację miejsc braku projekcji kolumn. Analiza dzienników zapytań (slow query logs) pozwala na wskazanie sekcji kodu wymagających przebudowy indeksów lub implementacji stronicowania wyników (pagination), redukując ryzyko skanowania całych tabel.

Architektura oprogramowania a kompetencje serwisu sprzętowego

Analiza, profilowanie oraz przebudowa zapytań kierowanych do relacyjnych czy nierelacyjnych baz danych w systemach CRM stanowią zadania inżynierii oprogramowania. Wymagają dostępu do kodu źródłowego, środowisk deweloperskich oraz uprawnień kontroli wersji po stronie dostawcy systemu. Jako punkt zajmujący się infrastrukturą fizyczną, Warszawskie Pogotowie Komputerowe diagnozuje i usuwa sprzętowe usterki urządzeń klienckich. Do naszych kompetencji należy wymiana układów chłodzenia, lutowanie komponentów SMD na płytach głównych, naprawa torów zasilania, instalacja nowych matryc LCD/OLED, wymiana klawiatur oraz sprzętowy odzysk danych z uszkodzonych dysków talerzowych i półprzewodnikowych w laptopach oraz jednostkach stacjonarnych.

W przeszłości, gdy oprogramowanie często funkcjonowało lokalnie na rzadkim i przestarzałym dziś sprzęcie, użytkownicy próbowali niwelować powolne działanie aplikacji poprzez bezpośrednią rozbudowę podzespołów w swoich stacjach roboczych. Zgłoszenia, w których klient oczekuje przyspieszenia działania zewnętrznego systemu CRM poprzez fizyczną modyfikację własnego komputera, są obecnie w serwisie rzadkością. Zjawisko obciążenia sieci i serwerów na skutek nieoptymalnych zapytań wykracza całkowicie poza możliwości serwisu sprzętowego. Jeżeli aplikacja chmurowa ładuje wybrane moduły z dużym opóźnieniem z powodu redundancji pobieranych pól, modernizacja lokalnego układu chłodzenia czy instalacja szybszego nośnika SSD nie usunie wąskiego gardła znajdującego się w kodzie warstwy serwerowej. Ingerencja naprawcza w strukturę zapytań ORM, konfigurację klastrów bazy danych czy redukcję nadmiarowości API wymaga prac programistycznych i pozostaje domeną twórców używanego oprogramowania biznesowego.