Oracle - exadata

Odpowiedz Nowy wątek
2020-02-19 11:05

Rejestracja: 5 miesięcy temu

Ostatnio: 4 miesiące temu

0

Witam,

Działam na oracle sql developerze, jest możliwość pobrania jakoś za darmo Oracle Database Exadata Express?
Potrzebuję to do zrobienia hybrydowej kompresji kolumnowej.
Pozdrawiam

Pozostało 580 znaków

2020-02-19 11:38

Rejestracja: 5 lat temu

Ostatnio: 2 godziny temu

1

Exadata to mix softu i hardware, więc cięzko ściągnąć soft i oczekiwać funkcjonalności HW :-)

Co to znaczy "do zrobienia hybrydowej kompresji kolumnowej"? Chcesz sobie coś przećwiczyć?

Pozostało 580 znaków

2020-02-19 11:52

Rejestracja: 5 miesięcy temu

Ostatnio: 4 miesiące temu

0

Ogólnie chciałbym zrobić tabele w orientacji kolumnowej, przy użyciu columnstore. (https://pdf.helion.pl/or12pr/or12pr.pdf - coś jak tu, str. 65)
Potrzebuję porównać kompresję danych w tabeli kolumnowej i wierszowej poprzez wykonywanie różnych zapytań SELECT.
Jestem w tym dość początkujący.

Pozostało 580 znaków

2020-02-19 12:24

Rejestracja: 5 lat temu

Ostatnio: 2 godziny temu

0

Oracle nie wspiera storage kolumnowego. Oracle SQL Developer to klient bazodanowy. Jeśli chodzi o HCC, to będzie to dla Ciebie raczej męka ;-)

To co można zrobić to zrobić jakąś encję Foobar (id, attr1, attr2, ..., attrN) i zaimplementować ją na różne sposoby:
1) Tabelka: (id, attr1, ..., attrN) - storage wierszowy
2) N tabelek: (id, attr1), ..., (id, attrN) - kulawa imitacja storage kolumnowego

Wypełnić to danymi i spróbować wyciągnąć te same informacje, np. agregacja po attrX,attrY,attrZ, zliczanie etc.

Inne podejście, to skorzystanie z emulacji storage -> https://www.oracle.com/techne[...]n/ovm3-nfs-120315-2798409.pdf
Nie wiem jednak czy na tym zrobisz HCC, żeby porównywać perfromance, raczej żeby poćwiczyć składnię poleceń.

Jeszcze inne podejście:
1) Wybierasz 2 bazy: Oracle (row storage) i coś co ma kolumnowy storage (Sybase, Vertica, ...)
2) Implementujesz tę samą encją na różnych silnikach i badasz różne zapytania

Pozostało 580 znaków

2020-02-19 12:30

Rejestracja: 5 miesięcy temu

Ostatnio: 4 miesiące temu

0

Dziękuję za wyjaśnienie. Zastanowię się co wybrać i będę próbował.

Pozostało 580 znaków

2020-03-11 00:26

Rejestracja: 5 miesięcy temu

Ostatnio: 4 miesiące temu

0

Witam ponownie,
nie chcąc zakładać nowego tematu, a mam pytanie odnośnie oracle wykorzystam obecny.
Powiedzmy, że zrobiłem 2 takie same identyczne tabele z milionem wierszy, tyle, że jedna z nich jest skompresowana, a druga nie. Oczywiście jedna z nich ma mniejszy rozmiar i na pewno jest odblokowana opcja ADVANCED COMPRESSION a druga ma status DISABLED. Czy czasy wykonania prostych zapytań w tabeli nieskompresowanej mogą zajmować więcej czasu? Mowa o takich samych zapytaniach dla obu tabel.

Pozostało 580 znaków

xy
2020-03-11 07:21
xy

Rejestracja: 1 rok temu

Ostatnio: 1 dzień temu

1

Mogą działać dłużej na nieskompresowanej, bo jest więcej danych do odczytania z dysku. Widocznie ten dodatkowy czas odczytu przeważa na dodatkowym czasem pracy procesora na dekompresję w tym drugim przypadku.

Pozostało 580 znaków

2020-03-11 09:31

Rejestracja: 5 lat temu

Ostatnio: 2 godziny temu

0

Dokładnie tak jak kolega @xy napisał.

Warto pochylić się nad następującymi elementami:

  1. Procedura pomiaru czasu wykonania

  2. Procedura generowania danych testowych
    2.1 bez kompresji
    2.2 z kompresją

    • "słaba" kompresja
    • "średnia" kompresja
    • "dobra" kompresja
  3. Dane partycjonowane, bez partycjonowania

  4. Różne zapytania testowe

    • przebieg po całym zbiorze (np. agregacje)
    • przebieg po wybranej partycji (np. partycjonowanie po zakresie dat)

Ad.1 W wersji minimum procedury testowej, warto czyścić bufory bazy

alter system flush shared_pool;
alter system flush buffer_cache;

oraz cache systemowy (dla Linuksa -> https://linux-mm.org/Drop_Caches).

Pozostało 580 znaków

2020-03-11 09:42

Rejestracja: 5 miesięcy temu

Ostatnio: 4 miesiące temu

0

W sumie to pisałem już to późno i się pomyliłem. Miałem na myśli, że dla tabeli skompresowanej czas jest większy. Chociaż to też zależy. Przy zapytaniu robiącym pełen skan tabeli dla skompresowanej tabeli wyszło to dużo szybciej. Przy jakimkolwiek pobieraniu danych czasy są bardzo podobne lub na nieskompresowanej tabeli jest to nawet szybsze, jest to bardzo zróżnicowane. Jednak przy skorzystaniu z explain_plan widać, że koszt przy skompresowanej tabeli jest niższy i chyba głównie na tym będę się opierać, a nie na czasie. I dzięki ponownie za rozjaśnienie tematu.

edytowany 2x, ostatnio: pavulonn, 2020-03-11 09:47

Pozostało 580 znaków

2020-03-11 09:53

Rejestracja: 5 lat temu

Ostatnio: 2 godziny temu

0

Twój wybór jak robisz porównania i jakie wnioski będzie można z takich porównań wysnuć. Jeśli chcesz używać czasów z planów wykonania, to powinieneś zebrać statystyki na tabelach (rozkład danych) oraz statystyki systemowe (charakterystyka wydajności komponentów systemu).

Jak masz jakieś małe ilości danych, które mieszczą się w buforach bazy, to po pierwszym przejechaniu przez tabele, trafią one do cache'a bazy i kolejne zapytania po prostu nie wykażą zauważalnej różnicy.
Stąd też moje uwaga n.t. czyszczenia cache bazy i systemu operacyjnego przed wykonaniem zapytania oraz uwaga dotyczącego różnego generowania danych, tak by efekt kompresji był zauważalny. Kompresja będzie miała znaczenie przy odczycie danych i zapisie, a jak już są w pamięci to nie ma różnicy z jakiej tabeli zostały załadowane.

Pozostało 580 znaków

Odpowiedz

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0