Generalnie chciałbym myśleć o jednej warstwie widoku lub zmaterializowanej warstwy widoku dla użytkowników sprawozdań. Moje preferencje, o ile nie występują konkretne problemy z wydajnością, byłyby zgodne z poglądami mającymi na celu tworzenie okazjonalnych zmaterializowanych widoków, które wykorzystują przepisywanie zapytania w celu przyspieszenia wybranych raportów.
Jeśli użyjesz zmaterializowanych widoków, po raz drugi zmaterializujesz dane, ale w formacie, który spowoduje mniej wydajne przechowywanie. Oznacza to, że większość przestrzeni w systemie zostanie przydzielona do zdenormalizowanych zmaterializowanych widoków i ich indeksów. To może wygenerować całkiem spory rachunek od producenta dysku i może spowodować rywalizację o zasoby SAN.
Materializowane widoki oznaczają również większą konkurencję o przestrzeń pamięci podręcznej między OLTP a raportowaniem użytkowników. Ponieważ są przechowywane w różnych obiektach, raporty, które szukają ostatniej aktywności, nie będą mogły korzystać z gorących bloków w pamięci podręcznej z działania OLTP i na odwrót. Możesz zaradzić temu problemowi, rzucając na niego pamięć RAM lub przesyłając raportowanie poza godzinami szczytu, ale nie jest to najskuteczniejsze rozwiązanie. Jeśli masz prawie wyłącznie historyczne raporty, to prawdopodobnie nie jest to wielka sprawa - i tak nie byłoby dzielenia się, ponieważ procesy są zainteresowane zupełnie innymi blokami - ale jeśli masz dużo raportowania operacyjnego, staje się znaczący.
Materializowane widoki również będą mniej elastyczne. Jeśli chcesz prezentować te same dane na wiele sposobów, to zmaterializowanie go wielokrotnie powoduje realne koszty zarówno w przypadku dysku, jak i pamięci podręcznej, jak również zwiększenie czasu wymaganego do okresowego odświeżenia zmaterializowanej warstwy widoku. W praktyce oznacza to zazwyczaj, że raportowanie użytkowników uzyskuje najmniej wspólny mianownik danych i musi ponownie wymyślić koło, kiedy kroi i kroi dane, ponieważ IT nie chce stworzyć dla nich nowego zmaterializowanego widoku.
Jak już wcześniej wspomniałem, moja preferencja byłaby zwykłą warstwą widoku. Pozwala to uniknąć wielokrotnego przechowywania danych i umożliwia współdzielenie bloków w pamięci podręcznej między OLTP a raportowaniem zapytań. Daje również stosunkowo łatwy dostęp do różnych widoków danych i eliminuje potrzebę informowania użytkowników biznesowych o tym, jak nieaktualne są dane, które są raportowane. Jeśli i kiedy wydajność staje się problemem, ponieważ model danych OLTP nie obsługuje rodzajów zapytań, które chcesz uruchomić, możesz utworzyć ukierunkowane zmaterializowane widoki, które zachowają się jak indeksy za pośrednictwem query rewrite. Oznacza to, że użytkownicy mogą wysyłać zapytania do zwykłych widoków, a administrator bazy danych może później dodać zmaterializowany widok, który generuje całość lub część wyniku, a optymalizator może zmienić plan kwerendy, aby użyć nowego zmaterializowanego widoku, zamiast skanowania tabeli (tabel) i robienia rzeczy jak agregowanie danych w czasie wykonywania.
W pewnym momencie prawdopodobnie będziesz chciał przenieść ruch raportowania, aby trafić do prawdziwej hurtowni danych z bardziej wymiarowym modelem danych. Jeśli okaże się, że naprawdę potrzebujesz wydajności zmaterializowanej warstwy widoku, a nie zwykłej warstwy widoku, zdecydowanie zastanawiałbym się nad przejściem do prawdziwej hurtowni danych z faktami i wymiarami. Dostaniesz coś, co jest o wiele bardziej elastyczne w raportowaniu z zasadniczo tymi samymi problemami ETL, które prawdopodobnie uzyskasz z pełną zmaterializowaną warstwą widoku.
Przepraszam, że nie wspominam, że jest to wydanie korporacyjne 10g. – Sherry
@ Sherry- przerobiono wpis dla przedsiębiorstwa, a nie ekspresowe. –
dziękuję za reposting z wersją korporacyjną, a także punkt poświęcony magazynowaniu i problemom z zasobami MV. – Sherry