Comments on: Raportowanie a CQRS http://simon-says-architecture.com/2010/03/11/raportowanie-a-cqrs/ Szymon Pobiega about software engineering and architecture Fri, 03 Feb 2012 10:29:36 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Szymon Pobiega http://simon-says-architecture.com/2010/03/11/raportowanie-a-cqrs/comment-page-1/#comment-706 Szymon Pobiega Thu, 11 Mar 2010 15:43:02 +0000 http://simon-says-architecture.com/?p=495#comment-706 Jak już pisałem, nie jestem ekspertem od BI, ale moje dotychczasowe doświadczenie z systemami OLTP pozwala mi stwierdzić, że gdybym był odpowiedzialny za budowę nowego rozwiązania na pewno oddzieliłbym funkcjonalność raportową do osobnej bazy. Po prostu zbyt wiele problemów powoduje uruchamianie na bazie transakcyjnej bardzo skomplikowanych zapytań dla raportów. Kwestia, jak często ją aktualizować jest interesująca i zapewne zależy od potrzeb biznesu. W pewnych przypadkach wystarczy raz dziennie i moje rozwiązanie z CQRS byłoby przesadą. W innych natomiast ważne jest, aby raporty agregujące dane były aktualne co do minut. @Procent Dlaczego baza do zapytań jest szybsza? 1. Bo jest zdenormalizowana :) i zapytania na potrzeby list/szczegółów mają mniej joinów 2. Bo można uruchomić dowolną ilość serwerów bazodanowych hostujących bazę do odczytu i w ten sposób skalować tę warstwę niemal liniowo @Gutek Co jest nie tak z tą normalizacją? Czegoś nie zajarzyłem? ;-) Jak już pisałem, nie jestem ekspertem od BI, ale moje dotychczasowe doświadczenie z systemami OLTP pozwala mi stwierdzić, że gdybym był odpowiedzialny za budowę nowego rozwiązania na pewno oddzieliłbym funkcjonalność raportową do osobnej bazy. Po prostu zbyt wiele problemów powoduje uruchamianie na bazie transakcyjnej bardzo skomplikowanych zapytań dla raportów.

Kwestia, jak często ją aktualizować jest interesująca i zapewne zależy od potrzeb biznesu. W pewnych przypadkach wystarczy raz dziennie i moje rozwiązanie z CQRS byłoby przesadą. W innych natomiast ważne jest, aby raporty agregujące dane były aktualne co do minut.

@Procent

Dlaczego baza do zapytań jest szybsza?
1. Bo jest zdenormalizowana :) i zapytania na potrzeby list/szczegółów mają mniej joinów
2. Bo można uruchomić dowolną ilość serwerów bazodanowych hostujących bazę do odczytu i w ten sposób skalować tę warstwę niemal liniowo

@Gutek

Co jest nie tak z tą normalizacją? Czegoś nie zajarzyłem? ;-)

]]> By: Gutek http://simon-says-architecture.com/2010/03/11/raportowanie-a-cqrs/comment-page-1/#comment-705 Gutek Thu, 11 Mar 2010 13:25:10 +0000 http://simon-says-architecture.com/?p=495#comment-705 -- uwaga, jezeli dobrze zrozumialem tresc art :) to komentarz jest poprawny :) jezeli nie to sorki ;) Jezeli chodzi o trzecia baze. IMO do raportow (w sensie prawdziwym) przewaznie powinno sie tworzy baze agregujaca dane na scisle okreslonych zasadach - jak te dane beda agregowane i kiedy to zalezy juz od nas. @Procent baza raportowa to nie to samo co baza zwykla. Tutaj istnieje sens pchania danych wtedy kiedy potrzebne (oczywiscie i bez tego co jakis czas ta baza powinna sie aktualizowac). Dodatkowo przewaznie raporty nie stanowia Widoku na dane w bazie, ale jakies konkretne agregacje danych. W tym wypadku moga one znaczaco obciazyc serwer bazodanowy. w zaleznosci od projektu albo stosowalem kostki albo osobna baze. sposob aktualizacji bazy raportowej zalezal stricte od ograniczenia wybranego rodzaju rozwiazania. @Procent i @Szymon uwazajcie ze slowem normalizacja w bazach danych :) – uwaga, jezeli dobrze zrozumialem tresc art :) to komentarz jest poprawny :) jezeli nie to sorki ;)

Jezeli chodzi o trzecia baze. IMO do raportow (w sensie prawdziwym) przewaznie powinno sie tworzy baze agregujaca dane na scisle okreslonych zasadach – jak te dane beda agregowane i kiedy to zalezy juz od nas.

@Procent
baza raportowa to nie to samo co baza zwykla. Tutaj istnieje sens pchania danych wtedy kiedy potrzebne (oczywiscie i bez tego co jakis czas ta baza powinna sie aktualizowac). Dodatkowo przewaznie raporty nie stanowia Widoku na dane w bazie, ale jakies konkretne agregacje danych. W tym wypadku moga one znaczaco obciazyc serwer bazodanowy.

w zaleznosci od projektu albo stosowalem kostki albo osobna baze. sposob aktualizacji bazy raportowej zalezal stricte od ograniczenia wybranego rodzaju rozwiazania.

@Procent i @Szymon
uwazajcie ze slowem normalizacja w bazach danych :)

]]> By: Thomas http://simon-says-architecture.com/2010/03/11/raportowanie-a-cqrs/comment-page-1/#comment-704 Thomas Thu, 11 Mar 2010 09:06:13 +0000 http://simon-says-architecture.com/?p=495#comment-704 Jedyne czego sie obawiam oprocz problemu ktory poruszyl Procent w swoim komentarzu jest takze strafa techniczna ktora ma zajac sie aktualizacja bazy raportowej. W przypadku bardziej skomplikowanych aplikacji mapping pomiedzy baza do zapytan i baza raportowa moze byc bardzo skomplikowany. Z drugiej strony patrzac na to ze czesto generowanie raportow moze byc traktowane jako inny projekt lub podczesc projektu, dodatkowa praca nad tym aspektem wcale mnie nie przeraza. Mysle jednak ze trzecia baza bylaby najlepszym rozwiazaniem. Jedyne czego sie obawiam oprocz problemu ktory poruszyl Procent w swoim komentarzu jest takze strafa techniczna ktora ma zajac sie aktualizacja bazy raportowej. W przypadku bardziej skomplikowanych aplikacji mapping pomiedzy baza do zapytan i baza raportowa moze byc bardzo skomplikowany.
Z drugiej strony patrzac na to ze czesto generowanie raportow moze byc traktowane jako inny projekt lub podczesc projektu, dodatkowa praca nad tym aspektem wcale mnie nie przeraza.
Mysle jednak ze trzecia baza bylaby najlepszym rozwiazaniem.

]]> By: Procent http://simon-says-architecture.com/2010/03/11/raportowanie-a-cqrs/comment-page-1/#comment-703 Procent Thu, 11 Mar 2010 07:15:45 +0000 http://simon-says-architecture.com/?p=495#comment-703 Czekałem na bardziej odpowiedni post z zadaniem tego pytania, ale jednak zadam teraz:). Odnośnie fragmentu: "posiadają wbudowany mechanizm wypychania danych z bazy transakcyjnej w czasie rzeczywistym (służący do zasilania bazy dla zapytań)" No właśnie... jak to się ma do wydajności względem "tradycyjnego" podejścia? Normalnie operacje zapisu/odczytu przeplatają się, a baza "zapytaniowa" teoretycznie ma być szybsza, ponieważ jest tylko do odczytu. Ale przecież nie jest, ponieważ non stop zachodzą w niej takie same zmiany jak w bazie transakcyjnej. Może nawet zachodzi w niej zmian wynikających z jej zdenormalizowanej natury. Widziałem rozwiązania "optymalizujące" pchające zmiany do bazy raportowej w paczkach jedynie wtedy, gdy przychodzi jakieś żądanie tak aby niepotrzebnie tej bazy nie aktualizować. Ale wydaje mi się to trochę bez sensu - po co wstrzymywać się z aktualizacją bazy do momentu, w którym będzie obciążona zapytaniami? :) Czy masz jakieś przemyślenia dotyczące właśnie tego tematu - aktualizacji bazy raportowej/zapytaniowej, ew. różnych podejść do tego problemu? Czekałem na bardziej odpowiedni post z zadaniem tego pytania, ale jednak zadam teraz:). Odnośnie fragmentu:

“posiadają wbudowany mechanizm wypychania danych z bazy transakcyjnej w czasie rzeczywistym (służący do zasilania bazy dla zapytań)”

No właśnie… jak to się ma do wydajności względem “tradycyjnego” podejścia? Normalnie operacje zapisu/odczytu przeplatają się, a baza “zapytaniowa” teoretycznie ma być szybsza, ponieważ jest tylko do odczytu. Ale przecież nie jest, ponieważ non stop zachodzą w niej takie same zmiany jak w bazie transakcyjnej. Może nawet zachodzi w niej zmian wynikających z jej zdenormalizowanej natury.
Widziałem rozwiązania “optymalizujące” pchające zmiany do bazy raportowej w paczkach jedynie wtedy, gdy przychodzi jakieś żądanie tak aby niepotrzebnie tej bazy nie aktualizować. Ale wydaje mi się to trochę bez sensu – po co wstrzymywać się z aktualizacją bazy do momentu, w którym będzie obciążona zapytaniami? :)
Czy masz jakieś przemyślenia dotyczące właśnie tego tematu – aktualizacji bazy raportowej/zapytaniowej, ew. różnych podejść do tego problemu?

]]>