OpenEdge Table Partitioning - Technical Forum - PUG Poland - Progress Community
 Technical Forum

OpenEdge Table Partitioning

  • Już kilka osób pytało mnie co to takiego OpenEdge Table Partitioning. Starsi użytkownicy Progressa pamiętaja zapewne v8 gdy wszystkie dane w tabelach i indexach były wymieszane i nie można było zdecydować dla baz wielo-wolumenowych, gdzie znajdują się dane poszczególnych obiektów bazy.

    Od wersji 9. mamy możliwość definiowania tych obiektów w obszarach, a te z kolei są przechowywane w plikach, których lokalizację możemy określić. Ma to duże znaczenie dla wydajności i zarządzania danymi.

    W wersji OE 11.4, która ukazała się w sierpniu br. wprowadzono OpenEdge Table Partitioning (oddzielny produkt), który ma za zadanie tzw. "poziomy" podział danych w oparciu o wybraną kolumnę w tabeli. Ma to dodatkowo poprawić wydajność, a także dostępność danych i łatwość zarządzania. Przed wyborem tabeli do podziału na partycje i wyborem kolumny w tabeli należy przeprowadzić analizę danych i rozważyć szereg aspektów. Np. kolumna (pole) musi być na pierwszym miejscu w definicji indexu, nie może zawierać nieznanych wartości (?) itd.

    Przykładem podziału danych na partycje może być pole daty w zamówieniu: dzielimy dane np. na lata lub kwartały, a te z kolei możemy podzielić na sub-partycje np. na miesiące itp.

    Więcej o partycjach napiszę niebawem. Piszcie jeśli macie pytania.

  • W jaki sposób można praktycznie stosować table partitioning? Może jakiś przykład?

  • table partitioning slide.ppt

    Dzien dobry - 

    Ilustrujac to, co powiedzial Piotr, zalaczam slajd. Wroce za moment z innym materialem. 

    Pozdrawiam

    Kinga

  • Table Partitioning stosuje sie np. wowczas, gdy mamy w firmie, badz przedsiebiorstwie do czynienia z bardzo duza iloscia danych, ktore narozly przez lata.

    Np wyobrazmy sobie firme, obecan od wielu lat na rynku, z duza iloscia kontrahentow, ze wszystkich regionow Polski. Mozemy wykaz np. faktur, ktory obecnie jest w jednym 'worku' podzielic na obszary: 'faktury od 1990 do 2000" "faktury od 2001 do 2010" itd. Ponadto mozna zdefiniowac obszary, ktore odpowiadaja mapie wojewodztw. Wowczas podzialy te mozna na siebie nalozyc i mozemy miec szybszy wglad do kategorii "faktury z wojewodztwa pomorskiego z okresu pomiedzy 1990-2000".

    Przypuszczam, ze wszedzie tam, gdzie mamy do czynienia z duza iloscia danych, gdzie znalezienie konkretnej informacji, albo konkretnego dokumentu, zajmuje duzo czasu, table partitioning jest propozyja warta przetestowania.

  • dodatkowe informacje nt table partitioning znajduja sie rowniez tu na communities, prosze zerknac: community.progress.com/.../1120.aspx

    czy jest to przydatny material?

  • tp.pdf

    Odpowiadając szerzej na pytanie odnośnie partycji, rozumiem, że chodzi o wyjaśnienie bardziej techniczne.

    Wcześniej Kinga i ja podaliśmy nieco ogólnych informacji o Table Partitioning.

    Cały proces definiowania partycji i zarządzania nimi nie da się opisać w kilku zdaniach.

    Podam trochę informacje aby wiadomo było "czym się to je" od strony administratora baz.

    Kilka zrzutów ekranowych znajdziecie w załączonym pliku pdf.

    TP polega na rozbiciu tabeli na partycje z punktu widzenia bazy danych, a nie aplikacji. Dla aplikacji ten podział jest transparentny.

    Do tworzenia/zarządzania TP służą narzędzia: OE Explorer (OE Management), instrukcje ABL, komendy SQL, polecenia w oknie komend.

    Dane z jednej tabeli mogą znajdować się w kilku obszarach, a to gdzie trafią zależy od wartości określonych pól w rekordach.

    Do włączenia TP baza musi mieć zdefiniowane obszary TYP II.

    Załóżmy, że mamy już bazę z dodanymi takimi obszarami (np. obszar USA). (Trzeba mieć oczywiście licencję dla Table Partitioning).

    W OE Management w Database Connections definiuję połączenie z moją bazą i włączam TP (rys. 1 i rys. 2).

    Następnie tworzy się Partition Policy (rys. 3) np. dla obszaru Customer. Podaje się tutaj pole, wg którego będzie podział i index.

    Tutaj polem jest Country, a indexem CountryPost (rys. 4).

    System tworzy Partition Policy i musimy teraz zaznaczyć, które z nich mają stać się fizycznymi partycjami.

    Na rys. 5 widać taką partycję dla pól Country = "USA".

    Dane nie są jeszcze fizycznie podzielone. Uruchamiamy w oknie komend polecenie:

    proutil baza -C partitionmanage split table customer composite initial

    Teraz gdy zmienimy pole w jakimś rekordzie Customer np. z "Italia" na "USA", to ten rekord zostanie przeniesiony do nowo stworzonej partycji USA.

    Można tworzyć także partycje dla zakresu danych (np. dla zakresu dat, lub wartości liczbowych).

    Do zarządzania partycjami istnieje szereg poleceń, np. można odbudować indexy online! dla konkretnej partycji. Partycje można także scalać.

    To tyle w dużym skrócie. Więcej informacji znajdziecie w dokumentacji.