Data Hub – architektura Business Intelligence w trybie real-time z wykorzystaniem DBPLUS Data Replikator

Sytuacja wyjściowa
Renomowana sieć sklepów z częściami motoryzacyjnymi, prowadząca swoją działalność handlową w Polsce oraz w 16 krajach europejskich, zdecydowała o wdrożeniu projektu centralnego systemu raportowania. System miał obsługiwać całą organizację oraz sieć partnerów biznesowych.

Oczekiwania biznesu

Dostarczanie aktualnych informacji dotyczących bieżącej sprzedaży, stanów magazynowych oraz innych danych biznesowych (dane klientów, adresy dostaw, itd.).
Dane dostępne centralnie, aktualizowane w czasie rzeczywistym.

Problem do rozwiązania

Opóźnienie w raportowaniu kluczowych danych biznesowych, takich jak sprzedaż czy stany magazynowe (aktualizacja danych co 24h).
Brak spójności raportów z poszczególnych rynków.
Ograniczona możliwość wprowadzania zamian w raportach – konieczność koordynacji wdrożenia ze wszystkimi lokalnymi działami IT.

Architektura rozwiązania

Dane przetwarzane w nocy, w każdej z 16 lokalnych baz danych.
Przesyłanie ekstraktu danych do lokalizacji centralnej.
Każdy z rynków obsługiwany przez system ERP hostowany lokalnie.

Rozwiązanie

Centralny Data Hub zasilany systemem replikacji danych biznesowych DBPLUS Data Replicator w trybie real-time z lokalnych baz danych.

Korzyści

Kluczowe dane biznesowe z każdego rynku (sprzedaż, stany magazynowe, kontakty CRM) dostępne są w czasie rzeczywistym.
Możliwość wykonywania raportów o dowolnej porze.
Dostęp do stanów magazynowych aktualizowanych online umożliwił klientowi zaoferowanie nowych usług oraz lepszą optymalizację łańcucha dostaw (dostawa produktów może odbywać się także z magazynów w innych państwach).
Brak konieczności codziennego, nocnego przetwarzania danych, co w istotny sposób odciążyło pracę działów IT.

Architektura docelowa

DBPLUS Data Replicator replikuje dane z każdego lokalnego, krajowego systemu ERP do centralnego Data Hub z maksymalnym opóźnieniem 1,5 sek.
Wykorzystywany przez klienta system ERP to Microsoft Navision oparty na bazie Microsoft SQL Server
Data Hub wykorzystuje silnik baz danych Oracle.

Artur Boguszewski

Software Architect

Zmiana planu wykonania w SQL Server: Przyczyny i rozwiązania

Plany wykonania – złożone mapy wykreślone przez optymalizator SQL Server, dyktują najbardziej efektywną ścieżkę pobierania danych. Plany nie są jednak statyczne. Zmieniają się i dostosowują pod wpływem wielu czynników, od zmian ilości danych po aktualizacje systemu. Każda ze zmian planu wykonania w SQL Server może potencjalnie znacząco wpłynąć na wydajność.

Zrozumienie przyczyn tych zmian, a co ważniejsze, zrozumienie tego jak skutecznie nimi zarządzać, przekłada się na utrzymanie optymalnej wydajności w środowiskach SQL Server.

Od analizy do akcji: Przezwyciężanie zmiany w planie wykonania

Plany wykonania wybierają sposób, w jaki zapytania SQL są wykonywane przez mechanizm bazy danych. Jako takie stanowią różnicę między płynnie działającą bazą danych a taką, która potyka się pod obciążeniem. Zmiany w planie wykonania mają różne powody – często zmieniają się po cichu i bez ostrzeżenia – a dalekosiężne skutki mogą być ogromne.

Najbardziej bezpośrednim skutkiem zmiany planu wykonania jest spadek wydajności zapytań. Zapytanie, które kiedyś działało płynnie i liczone było w milisekundach, może, z powodu zmienionego planu, zacząć pochłaniać sekundy. Ten wzrost czasu zapytania może kaskadowo przełożyć się na dłuższy czas ładowania aplikacji, frustrację użytkowników końcowych i poważne reperkusje finansowe w środowiskach o wysokiej stawce, takich jak finansowe platformy transakcyjne lub usługi danych w czasie rzeczywistym.

03/09/2021