Reklama: Wysokie zyski z Twojej strony www , DOŁĄCZ DO NAS
Dołącz do grupy

Stwórz profil

Musisz wpisać swoje imię
Musisz wpisać swoje nazwisko
Musisz wpisać poprawny e-mail
Musisz wpisać hasło (min. 8 znaków)
Musisz zaakceptować regulamin

Krzysztof Drelczuk Architekt Systemów
IT

Temat: Bardzo dużo widoków w bazie - źle czy dobrze?

Właśnie jestem w trakcie projektowania pewnego rozwiązania i napotkałem pewną zagwozdkę.

W systemie planowana jest jedna wielka tabela z dużą ilością wpisów (przyrost około 500-750 tys rekordów miesięcznie w pierwszym roku i około 1-1,5 mln miesięcznie w kolejnych trzech latach). Wyszukiwanie w takim czymś będzie koszmarem, szczególnie że dane mają być agregowane po czasie.

Dlatego naturalnie powstał pomysł stworzenia widów zindeksowanych i pogrupowaniu danych po pewnej cesze charakteryzującej obiekty w tej tabeli a będącej zawsze w warunku where. Problem jednak z tym że takich grup jest sporo i nie jest ona z góry niczym ograniczona. Szacunkowo takich widoków powstawałoby około 1 do 2 tys miesięcznie .

I teraz pytanie:
Czy ktoś z Was pracował kiedyś na takiej bazie? O ile wiem z MS SQL Server ilość widoków jest nieograniczona ale ciekawi mnie czy posiadanie kilkunastu tysięcy widoków - a co za tym idzie kilkunastu tysięcy indeksów, które będzie trzeba utrzymywać (choć indeksowany będzie czas po którym następować będzie agregacja - więc defragmentacja wewnętrzna nie powinna być duża) będzie bardziej kłopotliwe niż ta jedna tabela.

Reasumując. Czy ktoś ma jakiekolwiek doświadczenia z bazą, z powiedzmy 50 tys. widoków, czy też jest to słaby pomysł.

Z góry dziękuje za wszelkie spostrzeżenia.

ps. Partycjonowanie tabeli niestety nie wchodzi w rachubę. Dziwne umowy hostingowe ;/Krzysztof Drelczuk edytował(a) ten post dnia 18.01.10 o godzinie 16:09
18.01.2010, 16:09
Link do wypowiedziLink | Cytuj

Przemysław R. pracownik

Temat: Bardzo dużo widoków w bazie - źle czy dobrze?

niech ci nawet przez myśl lnie przejdzie projektowanie takiego czegoś
pomyśl do każdego widoku indeks/indeksy - makabra

polecam forum: http://wss.pl/frmThreads.aspx?gid=17
18.01.2010, 16:17
Link do wypowiedziLink | Cytuj

Krzysztof Drelczuk Architekt Systemów
IT

Temat: Bardzo dużo widoków w bazie - źle czy dobrze?

Takie też jest moje odczucie. Moim pomysłem są kolumny wyliczeniowe do wcześniejszej agregacji. Czyli coś jak to:

create table SomeTable
(
InputDate DateTime,
InputYear as datepart(year,getdate()),
InputMonth as datepart(month,getdate())
-- i tak dalej week, day, hour, minute
)

oraz indeks wielokolumnowy na: InputYear , InputMonth , InputWeek, InpuDay, InpuHour, InpuMinute z kolumnami dołączonymi. Jednak jak pisałem tabela jest wielka (stanowić będzie około 90% całej bazy) i pojawił się pomysł z widokami jako mniej pamięciochłonny.
Pomysł z kolumnami wyliczeniowymi praktycznie podwoi fizycznie wielkość tej tabeli. I to jest fakt.

Dlatego pojawiło się wcześniejsze pytanie. O takim rozwiązaniu multi-widokowym nigdy nie słyszałem więc ciężko mi je było odrzucić jedynie na podstawie swoich odczuć.
18.01.2010, 16:49
Link do wypowiedziLink | Cytuj

Krzysztof Drelczuk Architekt Systemów
IT

Temat: Bardzo dużo widoków w bazie - źle czy dobrze?

I jak się okazało właśnie mój pomysł jest jeszcze gorszy bo nie działa wcale:

Column 'InputYear' in table 'SomeTable' cannot be used in an index or statistics or as a partition key because it is non-deterministic.

Niestety nie można ich oznaczyć jako persisted. ;/

Jak już to będzie trzeba je robić w insercie i pilnować aktualizacji. Też nie ładnie.Krzysztof Drelczuk edytował(a) ten post dnia 18.01.10 o godzinie 16:55
18.01.2010, 16:53
Link do wypowiedziLink | Cytuj

Przemysław R. pracownik

Temat: Bardzo dużo widoków w bazie - źle czy dobrze?

Krzysztof Drelczuk:
Jak już to będzie trzeba je robić w insercie i pilnować aktualizacji. Też nie ładnie

masz dwa wyjścia robisz agregaty do których dodajesz dane cyklicznie np. raz dziennie o określonej porze np. 4:00 w nocy, albo robisz to triggerem przy każdej transakcji - wybór należy do ciebie oraz oczywiście od potrzeb biznesowych

teraz pytanie co ile potrzebujesz dokładnych danych co dziennie, co tydzień, co miesiąc?
18.01.2010, 17:06
Link do wypowiedziLink | Cytuj

Łukasz Rakowiecki HICRON

Temat: Bardzo dużo widoków w bazie - źle czy dobrze?

Zastanawiam się nad sensem takiego rozwiązania ponieważ z tego co piszesz po roku czasu na każdy widok przypadało by koło ~5000 rekordów. Po drugie baza z sql z kilkoma milionami rekordów radzi sobie bez najmniejszych problemów, a przyrost rzędu 25000 też nie jest nadzwyczaj duży dodatkowo dane do bazy spływają w sposób który zmniejsza fragmentacje indeksów więc czas potrzebny na maintanace spada i SLA zawsze będzie atutem. Najpierw rozważył bym wszystkie opcje z dynamic sql, a dopiero szedł bym drogą tworzenia jakichkolwiek dodatkowych statycznych struktur w takiej ilości, ponieważ sam stworzysz sobie piekiełko z utrzymaniem tego. Ogólnie ujmując tyle mogę doradzić z tak małej ilości danych.
19.01.2010, 00:30
Link do wypowiedziLink | Cytuj

Jakub Suchocki Analityk Systemów
Logistycznych

Temat: Bardzo dużo widoków w bazie - źle czy dobrze?

Wg. mnie dane powinieneś archiwizować w tabelach co miesiąc z jakimiś sensownymi podsumowaniami. i potem sie do nich odwoływać
19.01.2010, 08:45
Link do wypowiedziLink | Cytuj

Łukasz Rakowiecki HICRON

Temat: Bardzo dużo widoków w bazie - źle czy dobrze?

Jeśli tak zrobi to niestety w przypadku zapytań na cały zakres w bazie będzie musiał bawić się w union dla tych tabel archiwalnych.
Następnym problemem będzie propagacja danych po archiwalnych tabelach co spowoduje że będzie wymagany dłuższy czas SLA na utrzymanie bazy a już nie mówię o pisaniu skryptów które będą wstanie dynamicznie dostosować się w przypadku dodania nowej tabeli archiwalnej dla zadanego okresu.
Archiwizację zaczął bym w przypadku gdyby ilość danych przekroczyła by ~40-50 kk rekordów choć i tym wtedy szukał bym innego rozwiązania, naprawdę przy dobrze zorganizowanych indeksach nie będzie problemów z kwerendami.
Abyś miał 100% pewności stwórz benchmark dla zakładanego schematu bazy i przetestuj różne warianty to da Ci najlepsza odpowiedz.
19.01.2010, 09:49
Link do wypowiedziLink | Cytuj

Przemysław R. pracownik

Temat: Bardzo dużo widoków w bazie - źle czy dobrze?

być albo mieć
albo mamy szybkie dane i nie zarzynamy zasobów na generowanie dynamicznym SQL, bzdury typu fragmentacja indeksów przy tej ilości rekordów są pomijalne
albo zarzynamy zasoby i nie budujemy struktur pośrednich, fakt nie mamy indeksów, ale generowanie raportu może wyłączyć serwer na dłuższą chwilę
19.01.2010, 10:08
Link do wypowiedziLink | Cytuj

Piotr L. IT - projekt &
implementacje

Temat: Bardzo dużo widoków w bazie - źle czy dobrze?

Krzysztof, a czy ty przypadkiem nie chcesz zrobić hurtowni danych?

Tutaj jak pobawić się w to za darmo z PostgreSQL
19.01.2010, 17:12
Link do wypowiedziLink | Cytuj

Daniel Ś. ...

Temat: Bardzo dużo widoków w bazie - źle czy dobrze?

Może nie doczytałem, ale podejrzewam, że nie masz możliwości tworzenia tabel z wynikami agregacji? Gdybyś miał taka opcję to proponuję dodatkowe tabele i tak jak napisał Przemysław, tzn. harmonogram generowania agregatów z zapisem do nowych tabel.
Ja pracuję z bazą systemu automatyki - stała wielkość około 12 giga (dane zmienne z 2 tygodni to 9 giga). Tworzenie widoków z obliczanymi kolumnami i agregacjami to makabra dla systemu... zwłaszcza, kiedy każdy generuje raport o 7 rano w czasie robienia kawy. Obecnie skłaniam się do rozwiązania PostgreSQL + serwer o niezbyt wygórowanych parametrach do trzymania danych zagregowanych na potrzeby raportów.
19.01.2010, 17:29
Link do wypowiedziLink | Cytuj

Bogdan Pieńkowski Konsulting,
programowanie
(.NET), analizy,
bazy danych. ...

Temat: Bardzo dużo widoków w bazie - źle czy dobrze?

Baza MS SQL 2008 Enterprise. Kilka tablic > 30mln rekordów każda. Największa tablica 62mln rekordów rozmiar 3,6GB, cała baza danych 85GB. Od kilku do kilkunastu wpisów na sekundę. Wyszukiwanie to nie jest aż taki problem. Większy problem to np. tzw. agregacja. Takie dane generujemy cyklicznie i zapisujemy do bazy statystycznej. Dane statystyczne są aktualne zatem na dzień bieżący-1.Bogdan Pieńkowski edytował(a) ten post dnia 20.01.10 o godzinie 18:15
20.01.2010, 15:06
Link do wypowiedziLink | Cytuj

Krzysztof Drelczuk Architekt Systemów
IT

Temat: Bardzo dużo widoków w bazie - źle czy dobrze?

Dziękuje wszystkim za sugestię. Zrobiłem testy wyszukiwania przy kolumnach wyliczeniowych i indeksach na nich. Okazuje się że jest o niebo lepiej niż zakładałem na początku. Tak więc widoków nie będzie. :)
21.01.2010, 10:57
Link do wypowiedziLink | Cytuj

Szymon P. Trzymać życia
rytm, a nie szarpać
się z nim

Temat: Bardzo dużo widoków w bazie - źle czy dobrze?

Tutaj poprzednicy już właściwie wszystko wyjaśnili - ja tylko dodam, że widoków, podobnie jak triggerów nie należy nadużywać w bazie danych. W przypadku triggerów wiadomo tracimy po części kontrolę nad kodem, a w przypadku widoków wiadomo, że w zdecydowanej większości przypadków można je zastąpić procedurami składowanymi. Zaletą takiego rozwiązania jest to, że porcedura po pierwszym wykonaniu ma już zcache'owany exectuion plan więc działa znacznie szybciej

ale widać że z problemem już sobie poradziłeś, więc to tylko na marginesie
26.01.2010, 13:28
Link do wypowiedziLink | Cytuj

Michał Z. ɐʇsıɯɐɹƃoɹd

Temat: Bardzo dużo widoków w bazie - źle czy dobrze?

Szymon P.:
Tutaj poprzednicy już właściwie wszystko wyjaśnili - ja tylko dodam, że widoków, podobnie jak triggerów nie należy nadużywać w bazie danych. W przypadku triggerów wiadomo tracimy po części kontrolę nad kodem, a w przypadku widoków wiadomo, że w zdecydowanej większości przypadków można je zastąpić procedurami składowanymi. Zaletą takiego rozwiązania jest to, że porcedura po pierwszym wykonaniu ma już zcache'owany exectuion plan więc działa znacznie szybciej
Z tej wypowiedzi wynika, że ten silnik nie buforuje planów dla widoków. ?!?!? MS SQL Serwer nie jest silnikiem, o którym mam dużą wiedzę, ale google twierdzi, że jednak ten silnik buforuje plany dla widoków. Do tego widoki są lżejsze. Polecanie procedur składowanych zamiast widoków jest chyba nadużyciem. Nie wiem z czego to wynika, ale na tym silniku wszystko robione jest na procedurach. Jak dla mnie - jak potrzebuję dodatkowej warstwy abstrakcji i widok wystarcza - to robię widok. Z triggerami jest trochę inaczej, bo AFAIR na tym silniku to są MS triggery, i procedury są wygodniejsze. Tak czy siak - jak można coś zrobić mniejszym młotkiem - po co brać największy jaki jest na półce? ;)
30.01.2010, 12:31
Link do wypowiedziLink | Cytuj

Piotr L. IT - projekt &
implementacje

Temat: Bardzo dużo widoków w bazie - źle czy dobrze?

Michał Z.:
Szymon P.:
Tutaj poprzednicy już właściwie wszystko wyjaśnili - ja tylko dodam, że widoków, podobnie jak triggerów nie należy nadużywać w bazie danych. W przypadku triggerów wiadomo tracimy po części kontrolę nad kodem, a w przypadku widoków wiadomo, że w zdecydowanej większości przypadków można je zastąpić procedurami składowanymi. Zaletą takiego rozwiązania jest to, że porcedura po pierwszym wykonaniu ma już zcache'owany exectuion plan więc działa znacznie szybciej
Z tej wypowiedzi wynika, że ten silnik nie buforuje planów dla widoków. ?!?!? MS SQL Serwer nie jest silnikiem, o którym mam dużą wiedzę, ale google twierdzi, że jednak ten silnik buforuje plany dla widoków.

Nawet jeśli, to przecież plan do widoku nie jest pełnym planem wykonania. Tylko procedura składowana ma pełny plan i to wtedy jeśli nie wykorzystuje dynamicznych SQLi.
Jak nie lubisz procedur składowanych zawsze możesz się przerzucić na COBOL-a (BIND PLAN) :)
30.01.2010, 14:35
Link do wypowiedziLink | Cytuj

Michał Z. ɐʇsıɯɐɹƃoɹd

Temat: Bardzo dużo widoków w bazie - źle czy dobrze?

Po pierwsze - sztywny, plan wykonania wcale nie musi być dobry. Statystyki mogą się zmieniać...
Kolejna sprawa - kompletnie nie rozumiem jak statyczny widok jest potencjalnie gorzej obsługiwany niż dynamiczna procedura. Nie mam "problemu" z procedurami. Chciałem tylko dowiedzieć się skąd parcie w tym kierunku. Być może to właśnie jest odpowiedź - silnik dobrze obsługuje procedury - resztę rozwiązań traktując po macoszemu vel. marketingowemu.
30.01.2010, 15:27
Link do wypowiedziLink | Cytuj

Przemysław R. pracownik

Temat: Bardzo dużo widoków w bazie - źle czy dobrze?

dynamiczny SQL obsługujący takie widoki jest be

jak chcecie możecie się spotkać w połowie drogi - funkcje tabelaryczne - ni to widok, nit to procedura
30.01.2010, 19:35
Link do wypowiedziLink | Cytuj

Roman G. DB2/REXX/C/TWS/JCL/W
MB/SMPE/DB2 TOOLS...

Temat: Bardzo dużo widoków w bazie - źle czy dobrze?

Michał Z.:
Po pierwsze - sztywny, plan wykonania wcale nie musi być dobry. Statystyki mogą się zmieniać...

Co z tego. Reoptymalizacja planu przy uruchomieniu załatwia sprawę.
Poza tym, sensowne dbmsy np potrafią porzucić nieefktywny index w czasie przetwarzania zapytania...

Poza tym - o czym wy tutaj do licha dyskutujecie??
Kilka tysięcy indeksów na *jednej* tabeli? - To brzmi równie zabawnie jak podróż na Marsa przy pomocy hulajnogi.
1.02.2010, 12:21
Link do wypowiedziLink | Cytuj

Piotr L. IT - projekt &
implementacje

Temat: Bardzo dużo widoków w bazie - źle czy dobrze?

Przemysław R.:
Krzysztof Drelczuk:
Jak już to będzie trzeba je robić w insercie i pilnować aktualizacji. Też nie ładnie

masz dwa wyjścia robisz agregaty do których dodajesz dane cyklicznie np. raz dziennie o określonej porze np. 4:00 w nocy, albo robisz to triggerem przy każdej transakcji - wybór należy do ciebie oraz oczywiście od potrzeb biznesowych

Ja jednak mam nadzieje, że to nie jest system transakcyjny, a jedynie raportujący...
31.01.2012, 09:53
Link do wypowiedziLink | Cytuj
« Wróć do tematów
Odpowiedz
Dołącz do grupy



Wyślij zaproszenie do

Anuluj