Analiza wydajności raportów Tableau zbudowanych na SQL Server i MongoDB

Chciałbym zaprezentować wyniki mojej małej analizy wydajności raportów Tableau zbudowanych na dwóch różnych źródłach danych: SQL Server  i MongoDB. Najważniejszym rezultatem jest to, że dla prostego scenariusza, czasy generowania raportów Tableau wzrastają bardzo szybko wraz z ilością danych testowych, ale tylko w przypadku MongoDB. Dodatkowo raport Tableau zbudowany na MongoDB nie renderuje się w akceptowalnym czasie przy użyciu sterownika SQL, co może być spowodowane niedoskonałościami sterownika MongoDB ODBC.

1. Wprowadzenie

Czas renderowania raportów BI jest jednym z największych problemów z jakimi borykają się dziś użytkownicy BI. Opóźnienia te mogą mieć kilka przyczyn, od złożoności raportów, poprzez ilość danych, aż po złożoność modelibazy danych. Problem z wydajnością pojawił się w kilku moich projektach i dlatego zdecydowałem się przeprowadzić małe dochodzenie dlaczego tak się dzieje. Moim celem było porównanie czasów renderowania raportów Tableau zarówno dla rozwiązań SQL jak i NoSQL. Do tego celu użyłem „SQL Server 2017” i „MongoDB 4.0.10”. Do budowy raportów i pomiaru wydajności użyłem „Tableau Desktop 2018”. Największym problemem w tworzeniu odpowiedniego środowiska była integracja Tableau Desktop – Mongo DB poprzez sterownik MongoDB ODBC. Polecam użycie „MongoDB BI Connector & ODBC driver” jako przewodnika, co pozwala zaoszczędzić mnóstwo cennego czasu inżyniera IT. Środowisko zostało skonfigurowane na maszynie lokalnej dzięki czemu nie było problemów z siecią, które mogłyby wpływać na wydajność. W przypadku struktur DB ograniczyłem modele do prostego przypadku: 2 tabele w serwerze SQL i 2 kolekcje dla MongoDB.

2. Testy

Tableau Desktop posiada wbudowaną funkcjonalność do pomiaru wydajności renderowania raportów. Dzięki temu możliwe jest monitorowanie kilku komponentów wydajnościowych jak np: czas wykonywania zapytań, renderowanie, czas potrzebny na podłączenie do źródła danych itp. Monitorowałem tylko istotne wartości – wyższe niż 0.1 [s].

2.1 Dane testowe

Do celów analizy wyników wykorzystałem dane historyczne amerykańskich stóp procentowych dla obligacji skarbowych na okres 10 lat, 2 lat i 3 miesięcy. Pierwotnie 10 tysięcy rekordów zostało pomnożone przez iloczyn kartezjański, osiągając 1 milion rekordów. Wyrenderowane dane znajdują się na [Rysunek 1].

2.2 Przypadki testowe

Postanowiłem zmierzyć wydajność raportów Tableau dla następujących trzech scenariuszy testowych:

Rysunek 1: Dane testowe – 10-letni Skarbiec Minus  3-miesięczny (u góry) i 10-letni Skarbiec Minus 2-letni (u dołu)

1.        Ile czasu potrzebuje Tableau Desktop na wygenerowanie raportów zbudowanych na obu bazach danych. Zaczynając od 250k rekordów, a kończąc na 1 milionie rekordów.

2.        Ile czasu potrzebuje Tableau Desktop na renderowanie raportów zbudowanych na obu bazach danych dla prypadku wykonania połączenia dwóch tabel/kolekcji.

3.        Ile czasu potrzebuje Tableau Desktop na renderowanie raportów zbudowanych na obu bazach danych przy użyciu „customowych” zapytań.

3. Wyniki

Zauważyłem, że ilość danych znacząco wpływa na renderowanie raportów zbudowanych na MongoDB i tylko w niewielkim stopniu raportów SQL Server. Przy rosnącej ilości danych potrzebnych, generowanie raportów rośnie niemal wykładniczo w przypadku MongoDB, jak widać na rysunku 2. Na [Rysunku 3] i [Rysunku 4] pokazuję, jak czasy generowania raportów różnią się w zależności od źródła danych. W rzeczywistości jedyną różnicą jest wykonywanie zapytania, podczas gdy renderowanie, łączenie się ze źródłem danych i pozostałe komponenty generowania raortu pozostają podobne, przy różnej ilości danych i złożoności zapytania.

4. Wnioski

Jak widać z wyników testów, raporty Tableau zbudowane na SQL Server są lepszym wyborem niż MongoDB, przynajmniej w przypadku prostego modelu DB. Wynika to głównie z kilkukrotnego „tłumaczenia” zapytań w przypadku MongoDB. Zauważyłem, że aby wykonać zapytanie do MongoDB za pośrednictwem sterownika MongoDB ODBC, Tableau musi wygenerować zapytanie SQL, dalej zapytanie MySQL, a na koniec zapytanie MongoDB. Oczywitym jest, że powoduje to różnicę czasu. Bardziej złożony model DB zdecydowanie odpowiedziałby na pytanie, które rozwiązanie jest lepsze. Należy również pamiętać, że MongoDB został stworzony dla celów innych niż SQL, dlatego nie powinniśmy bezpośrednio tłumaczyć modelu SQL DB na model MongoDB.

Podziękowania

Chciałbym podziękować Markowi Januszkiewiczowi i Michalinie Smolarkiewicz za pomocne uwagi i rady.


Rysunek 2: Czas [s] potrzebny do wygenerowania raportu w stosunku do ilości danych



Rysunek 3: Czas [s] potrzebny na ukończenie głównych komponentów – Połączono dwie tabele z 10000 rekordami każda

Rysunek 4: Czas [s] potrzebny na ukończenie głównych komponentów – niestandardowe zapytanie w dwóch tabelach z 1 tys. rekordów każda.

Przemek Jagodziński

Bibliografia

“MongoDB 4.0.10”. In: https: // www. mongodb. com/ download-center/ community .

“MongoDB BI Connector & ODBC driver”. In: https: // www. mongodb. com/ products/ bi-connector & https:

// github. com/ mongodb/ mongo-odbc-driver/ releases .

“SQL Server 2017”. In: https: // www. microsoft. com/ en-us/ sql-server/ sql-server-editions-express .

“Tableau Desktop 2018”. In: https: // www. tableau. com/ products/ desktop/ download .

(EN) We use cookies only for collective statistical purposes and to adapt the website to the user's needs.
(PL) Używamy cookies w celach statystycznych oraz w dostosowaniu serwisu do użytkownika.