partycjonowanie bazy danych

Mam pytanie odnośnie koncepcji pozycjonowania w bazie danych.
Model mojej bazy wygląda tak że mam główną encję 'Produkt' i powiązane z nim encje (m.in 'Klient' przez tabelę łączącą).
Jako że baza jest już dosyć spora i mam raptem kilka typów produktów to chciałbym zrobić partycjonowanie po typie produktu.

Zastanawiam się nad sensem gdyż tabelę klienta nie bardzo mam jak partycjonować. Czy partycjonowanie dla przypadku gdy mamy klika ściśle powiązanych ze sobą tabel ma w ogóle sens? Klienta dołączam (join) do praktycznie każdego produktu.

A moze index z warunkiem? np

 INDEX1 ... WHERE KlientId = 1;
INDEX2 ... WHERE KlientId = 2;
etc

a ja bym powiedział, że najpierw to się należy zastanowić nad tym, czy w ogóle partycjonowanie jest potrzebne. Bo jeśli struktura i zapytania są do d**y to ani serwer za grube miliony ani partycjonowanie nie pomoże. Jak coś działa wolno to najpierw należy się przyjrzeć konfiguracji samej bazy (ale oczywiście o tym, aby napisać co to za SZBD to już genialny umysł nie wpadł) a następnie planom wykonania samych zapytań. BTW ta spora baza to ile ma 10GB, 100GB, więcej czy 100MB i "już" działa wolno.

Inna sprawa, że partycjonowanie ma zazwyczaj sens w przypadku danych archiwalnych. Za takie dane można uznać np. poprzednie lata z danymi dotyczącymi sprzedaży. Wtedy zasadne jest partycjonować te dane wg roku, w którym była sprzedaż. Przy dużej ilość danych nawet po miesiącu sprzedaży.

W Twoim wypadku nie widzę sensu przeprowadzania takiej operacji. No ale jak zwykle pytacz się wysilił i zalał nas taką ilością informacji, że nie wiem nawet jak zacząć je interpretować...

Dzięki za odpowiedzi.

abrakadaber napisał(a):

a ja bym powiedział, że najpierw to się należy zastanowić nad tym, czy w ogóle partycjonowanie jest potrzebne
Bo jeśli struktura i zapytania są do d**y to ani serwer za grube miliony ani partycjonowanie nie pomoże. Jak coś działa wolno to najpierw należy się przyjrzeć konfiguracji samej bazy (ale oczywiście o tym, aby napisać co to za SZBD to już genialny umysł nie wpadł) a następnie planom wykonania samych zapytań. BTW ta spora baza to ile ma 10GB, 100GB, więcej czy 100MB i "już" działa wolno.

Baza oracle, około 30GB. Wcale nie działa wolno ale możliwy jest w najbliższym czasie znaczny wzrost liczby operacji. Struktura i zapytania są ok, partycjonowanie rozważane jest jako jedna z metod optymalizacji bazy. Jak da się zaoszczędzić trochę zasobów...

abrakadaber napisał(a):

Inna sprawa, że partycjonowanie ma zazwyczaj sens w przypadku danych archiwalnych. Za takie dane można uznać np. poprzednie lata z danymi dotyczącymi sprzedaży. Wtedy zasadne jest partycjonować te dane wg roku, w którym była sprzedaż. Przy dużej ilość danych nawet po miesiącu sprzedaży.

Dla przytoczonego przez Ciebie przypadku to działa w ten sposób że co miesiąc (lub co rok) tworzę nową partycję z kolejnym miesiącem (rokiem) danych?

crowa napisał(a):

A moze index z warunkiem? np

INDEX1 ... WHERE KlientId = 1;
INDEX2 ... WHERE KlientId = 2;
etc

Czyli przyjmując że już zrobiłem te partycje ze względu na rodzaj poduktu. Jak miałby wyglądać ten index? Jeden produkt może mieć wiele klientów. Z Twojego przykładu rozumiem ze każdy klient będzie miał swój index? To chyba nie jest możliwe.

lolecki napisał(a):

Dla przytoczonego przez Ciebie przypadku to działa w ten sposób że co miesiąc (lub co rok) tworzę nową partycję z kolejnym miesiącem (rokiem) danych?

Możesz przy tworzeniu tabeli od razu dodać warunki partycjonowania na 100 lat do przodu. Możesz co miesiąc dodawać nową partycję. Jak to sobie zorganizujesz - zależy tylko od Ciebie. Tu jest dość przystępnie opisane http://docs.oracle.com/cd/B10501_01/server.920/a96521/partiti.htm

Partycjonowanie ma sens praktycznie w dwóch przypadkach

1. masz dane bieżące do których sięgasz cały czas i które np. zawierają się w dwóch ostatnich miesiącach (bieżący i poprzedni) i archiwalne (cała reszta, odczytywane sporadycznie). Wtedy podzielenie tego na partycje miesięczne ma sens bo po pierwsze masz małe subtabele do odczytu a po drugie możesz dane archiwalne przenieść na wolniejszy nośnik.
2. masz dane, które są logicznie podzielone np. na działy. Np. dział zamówień obrabia tylko odbiorców a dział przyjęć towaru tylko dostawców. Co za tym idzie zapytania z działu zamówień zawsze odpytują tylko pewien podzbiór kontrahentów (tak samo zamówienia z działu przyjęć). Wtedy podzielenie tego na mniejsze bloki też ma sens.

Musisz się zastanowić, czy po podziale nie będzie tak, że i tak większość zamówień będzie "jeździła" po wszystkich partycjach bo zamiast zwiększyć wydajność może się okazać, że zmniejszyłeś

abrakadaber napisał(a):

Możesz przy tworzeniu tabeli od razu dodać warunki partycjonowania na 100 lat do przodu. Możesz co miesiąc dodawać nową partycję. Jak to sobie zorganizujesz - zależy tylko od Ciebie. Tu jest dość przystępnie opisane http://docs.oracle.com/cd/B10501_01/server.920/a96521/partiti.htm

Fakt, można zrobić przedziały czasowe do przodu i spokój. Biorę się za czytanie tej instrukcji...

abrakadaber napisał(a):

1. masz dane bieżące do których sięgasz cały czas i które np. zawierają się w dwóch ostatnich miesiącach (bieżący i poprzedni) i archiwalne (cała reszta, odczytywane sporadycznie). Wtedy podzielenie tego na partycje miesięczne ma sens bo po pierwsze masz małe subtabele do odczytu a po drugie możesz dane archiwalne przenieść na wolniejszy nośnik.
   ...

To jest mój przypadek. Przy INSERT i UPDATE SZBD sam zdecyduje po polu 'creation_date' na której partycji pracuje (i mamy wzrost wydajności). Trochę gorzej jest przy selectach, których jest zdecydowana większość. Oprócz id produktu (lub innego parametru) muszę zawsze mieć w zapytaniu 'creation_date' (klucz partycji) żeby mieć jakiś wzrost wydajności. Także w tej kwesti chyba konieczne są zmiany w aplikacji? Zmiany widzę w ten sposób że SELECT robię zawsze na najnowszej partycji, później ewentualnie na wcześniejszych. Dobrze kombinuję?

tak jak już pisałem - aby to miało sens to trzeba tak ograniczać na dzień dobry pobieranie danych z bazy aby nie grzebać bez potrzeby po wszystkich partycjach (chociaż to powinno być w każdej aplikacji opartej o bazę SQLową) a jedynie na wyraźne życzenie usera (czyli zamiast np. pokazywać faktury od początku istnienia systemu tylko te z kilku ostatnich dni)

abrakadaber napisał(a):

tak jak już pisałem - aby to miało sens to trzeba tak ograniczać na dzień dobry pobieranie danych z bazy aby nie grzebać bez potrzeby po wszystkich partycjach (chociaż to powinno być w każdej aplikacji opartej o bazę SQLową) a jedynie na wyraźne życzenie usera (czyli zamiast np. pokazywać faktury od początku istnienia systemu tylko te z kilku ostatnich dni)

Przyjmijmy że chodź większość zapytań ma w 'where' creation_date to są takie które nie mają. Jak można je zoptymalizować? Da się dodać jakiś 'hint' do zapytania aby w pierwszej kolejności wyszukiwanie było po najnowszej partycji?
Mam na myśli partycjonowanie zakresowe (a konkretnie 'interval partitioning') który kolejne partycje tworzy dla kolejnych miesięcy, według pola creation_date.