w transakcyjnych bazach danych bardzo dobrze jest stosować partycje aby: - poprawić wyszukiwanie danych na potrzeby reklamacji klienta, najczęściej z kilku ostatnich dni, tygodni, - zabezpieczyć dane przed przypadkowymi modyfikacjami, starsze partycje można przełączyć w tryb tylko do odczytu i żaden proces już nie nadpisze istniejących danych, - wykonywać przyrostową archiwizację danych, tak wiem są jeszcze inne metody ale ta jest także stosowana, - szybko odtworzyć bazę danych po awarii, gdy odtwarzamy najpierw najnowsze dane z najnowszych partycji aby jak najszybciej przywrócić system do życia, archiwalne partycje można przywrócić póżniej jeśli to konieczne, a czasami nie jest to nawet konieczne, - usuwać dane archiwalne sprzed roku lub więcej, zamiast czasochłonnego i obciążającego system DELETE, odłączamy całe partycje, co działa znacznie sprawniej, oczywiście w Oracle, bo w mikrosyfie partycje to porażka, jak i cała baza
Zgadzam się co do opisanych wyżej korzyści, tyle, że w modelowej transakcyjnej bazie danych nie przechowujemy danych historycznych, a jeśli tak to niewielki jej zakres. Równie dobrze można przechowywać dane w oddzielnej tabeli: arch_nazwa_tabeli, która będzie miała dedykowany TBS read only :) Ile projektów tyle rozwiązań. Wiem, że rzeczywistość jest dużo bardziej złożona niż opisuje w niektórych filmach, ale: 1. Odcinek może trwać kilkanaście minut by chciał go ktoś oglądać i nie o wszystkim zdążę powiedzieć 2. postaw się na miejscu osoby, która dopiero stawia pierwsze kroki i nie ma żadnego doświadczenia z hurtownią danych. Gdybym w tym nagraniu zaczął mówić o tym, że w OLTP też mamy historię, też tworzymy archiwum zmian danych to pojawiły się pytania - czym się różni baza od hurtownii w tym kontekście. Odcinek nagrywałem już ponad rok temu, ale wydaje mi się, że wspominałem na samym końcu, że taka sytuacja może zaistnieć(archiwalne dane w bazie danych). A wtedy partycjonowanie i inne techniki wykorzystywane w dwh też mają przy OLTP zastosowanie jak słusznie zauważyłeś.
@@nieinformatyk "w modelowej transakcyjnej bazie danych nie przechowujemy danych historycznych, a jeśli tak to niewielki jej zakres" - i tu jesteś w błędzie, bardzo wiele firm przechowuje dane historyczne w relacyjnych bazach danych, chociażby z tego powodu, że nie posiada hurtowni danych, np. bo nie ma takiej potrzeby, bo jest dla nich za droga, gdy skala ich biznesów nie jest tak duża aby wydawać pierdyliard złotówek na budowę i utrzymanie hurtowni danych
@@jacekkangaroo4402 ale to niczego nie zmienia z punktu widzenia teorii - modelowa baza transakcyjna nie przechowuje historii. O tym, że rzeczywistość wygląda inaczej mówiłem pod koniec nagrania - baza danych to często OLTP + trochę OLAP.
mając tabelę pokazującą aktualny stan magazynowy nie potrzebujesz indeksu na kolumnie 'number of items', wystarczy ci tylko indeks na kolumnie 'product code', także aktualizacja stanu magazynowego nie wymaga aktualizacji dodatkowego indeksu na tabeli, to tak w skrócie bez wdawania się w szczegóły, przykład do filmu nieco nietrafiony
Nie pamiętam jakiego przykładu użyłem w nagraniu, więc albo ja się pomyliłem, albo Ty mnie źle zrozumiałeś :) Jeśli chcemy czytać stan magazynowy produktów to oczywiście tak jak piszesz wystarczy indeks na kolumnie z id_produktu(+ ewentualnie data zasilania/obowiązywania danych). Indeks podlegałby wtedy aktualizacji w przypadku UPDAT-e na kluczu głównym(zmiana id_produktu).
@@nieinformatyk 11:55 "chcąc modyfikować dane w tabeli, np. stan magazynowy, jednocześnie musiałbym zmodyfikować index" - zwykle szukamy produktu przy użyciu indeksu kod produktu, a następnie w tabeli jego atrybutów, np. stan na magazynie (dwie operacje odczytu z bazy, raz index (index też jest tabelą i wymaga osobnej operacji odczytu), drugi raz tabela), ale są przypadki gdy chcemy przyścieszyć działanie odczytu i wtedy umieszczamy taką kolumnę w indeksie, wtedy faktycznie mamy nieco większy koszt w czasie modyfikacji rekordu, ale skracamy czas odczytu gdy nam na tym zależy (wszystko liczone w milisekundach także dla tysięcy transakcji na godzinę bez znaczenia, dopiero przy masowym przetwarzaniu w setkach milionów na godzinę ma znaczenie), bardzo przydatna funkcja w masowym przetwarzaniu danych, szczególnie gdy mamy chained rows w Oracle i nie możemy sobie pozwolić na przebudowę tabeli, ale to już inna historia, a tak na marginesie, to tabela stan magazynowy jest tabelą raportową, wyliczaną na podstawie dokumentów magazynowych (przyjęto na magazyn, zwrócono do magazynu, protokół zniszczenia, przeniesienia magazynowe, zamówienia klientów itp.), tworzymy takie tabele aby za każdym razem nie przeszukiwać ogromnej tabeli z dokumentami magazynowymi w celu potwierdzenia ilości towaru dostępnego do sprzedaży, a gdy nam się taka tabela rozleci, zawsze możemy ją odtworzyć z danych źródłowych, i na kolejnym marginesie, za updatey na kluczu głównym obcinałbym ręce, potem jeszcze obdzierał ze skóry, posypywał solą i na koniec zostawił aby samo zdechło :-)
Wydaje mi się, że nie do końca wskazałeś, dlaczego osobnym schematem lub tablespejsem lub nawet tabelą nie da się zrealizować wszystkiego co można zrobić w specjalistycznej instancji hurtowni bazy danych. Powiedziałeś, że ciężko albo się nie da, ale bez konkretnego przypadku/przyczyny.
Pytanie może i jest proste, ale moja odpowiedź by była zrozumiała musiałaby być bardzo długa->temat na oddzielne nagranie :) To trochę jakby próbować z auta sportowego zrobić dostawczak lub na odwrót.
@@nieinformatyk ja rozumiem, ale mogły paść dwa, trzy proste przykłady - jeśli coś jest trudne w wytłumaczeniu w 2 zdaniach znaczy się, że temat nie jest do końca zrozumiały dla samego prelegenta.;)
przykład pracownika jest bardzo nietrafiony, przede wszystkim dlatego że zmiany stanowiska nie są operacjami masowymi (masowa to jest sprzedaż w markecie, połączenia w telekomie, operacje bankowe), ponad to ze względów prawnych w systemie kadrowym powinna znajdować się cała historia zatrudnienia pracownika, wyszukanie aktualnego/historycznego stanowiska pracownika w bazie nawet tysięcy pracowników nie stanowi dla bazy danych żadnego problemu, przekombinowałeś tutaj
Jakież to polskie... Niesamowicie łatwo jest ponarzekać, a tak trudno zrobić coś pożytecznego. Jeżeli nawet dostrzegasz jakieś niedociągnięcia, mogłeś napisać jakiś konstruktywny przykład żeby uzupełnić materiał, ale oczywiście łatwiej tylko marudzić i narzekać. A jakbyś się tak lepiej zastanowił to ten przykład z pracownikami miał coś na szybko zobrazować, może nie jest najlepszy ale napewno jest wystarczający, aby zrozumieć istotę tematu. Panie Darku dziękuję w imieniu Jacka Kangaroo i wszystkich innych maruderów. Trzymaj się ciepło Panie Darku 👍😊
@@adrreb podawanie niepoprawnych przykładów jest szkodliwe, może wykształcić w młodzikach złe wzorce, które będą powodować problemy w przyszłości, dlatego zwróciłem na to uwagę aby narybek poznał także inny punkt widzenia, także nie napinaj się jak gumka w majtkach i poluzuj warkoczyk, moja opinia nie wynikała z hejtu
@@jacekkangaroo4402 Może twoja wyobraźnia nie ogarnia takich możliwości ale na ten przykład ja pracuję w ogromnej korporacji w której fluktuacja pracowników (na którą zarząd daje zgodę) jest bardzo duża i tego typu przykład jest jak najbardziej adekwatny.
@@adrreb duża baza danych to pojęcie względne, znałem nie jednego gościa co bazę 100 milionów rekordów (i to jeszcze utrzymywaną w majkrosyfie) nazywał bardzo dużą (takiej rotacji pracowników na pewno nie masz nawet przez cały rok)... ja pracowałem w firmach gdzie ładowane pliki danych miały 50-100 milionów rekordów, a zamknięcie miesiąca obejmowało przetworzenie ponad 2 miliarów rekrodów i generowało kolejne kilkaset milionów... optymalizowałem taki proces z 36 godzin do poniżej 24h a jakby posiedzieć dłużej to pewnie jeszcze coś bym urwał ale klient był już zadowolony z takiego postępu
![[Hurtownie danych] Czym jest hurtownia danych? Jak działa i jak ją zaimplementować? 🧐](/img/n.gif)
Bardzo dziękuję jak zawsze dużo cennej praktycznej wiedzy i mnóstwo pozytywnej energii! Pozdrawiam!
dzięki :)
Kolejny interesujący materiał przedstawiony w przyjemny sposób 👍
dzięki :)
Kolejny dobry materiał :)
Oby tak dalej Darku ;)
Dzięki Bartek :)
Dziękuję za to co robisz! Nikt tak nie tłumaczy jak ty 😍😍
Dziękuję :) Cieszę się, że odcinek się podobał.
Super odcinek jak zawsze, pozdro
dzięki :)
Super odcinek! Dzięki!!
Polecam się na przyszłość :)
Dzięki za materiał. Czekam na poprawiony odcinek o normalizacji.
Wartościowy materiał. Pozdrawiam Serdecznie.
Dziękuję :)
Dzięki za kolejny filmik.
Merktor - bijesz rekordy komentarzy, dzięki :)
Super!
Daję subscribe i zostaję na dłużej ❤
dzięki :)
w transakcyjnych bazach danych bardzo dobrze jest stosować partycje aby:
- poprawić wyszukiwanie danych na potrzeby reklamacji klienta, najczęściej z kilku ostatnich dni, tygodni,
- zabezpieczyć dane przed przypadkowymi modyfikacjami, starsze partycje można przełączyć w tryb tylko do odczytu i żaden proces już nie nadpisze istniejących danych,
- wykonywać przyrostową archiwizację danych, tak wiem są jeszcze inne metody ale ta jest także stosowana,
- szybko odtworzyć bazę danych po awarii, gdy odtwarzamy najpierw najnowsze dane z najnowszych partycji aby jak najszybciej przywrócić system do życia, archiwalne partycje można przywrócić póżniej jeśli to konieczne, a czasami nie jest to nawet konieczne,
- usuwać dane archiwalne sprzed roku lub więcej, zamiast czasochłonnego i obciążającego system DELETE, odłączamy całe partycje, co działa znacznie sprawniej, oczywiście w Oracle, bo w mikrosyfie partycje to porażka, jak i cała baza
Zgadzam się co do opisanych wyżej korzyści, tyle, że w modelowej transakcyjnej bazie danych nie przechowujemy danych historycznych, a jeśli tak to niewielki jej zakres. Równie dobrze można przechowywać dane w oddzielnej tabeli: arch_nazwa_tabeli, która będzie miała dedykowany TBS read only :) Ile projektów tyle rozwiązań.
Wiem, że rzeczywistość jest dużo bardziej złożona niż opisuje w niektórych filmach, ale:
1. Odcinek może trwać kilkanaście minut by chciał go ktoś oglądać i nie o wszystkim zdążę powiedzieć
2. postaw się na miejscu osoby, która dopiero stawia pierwsze kroki i nie ma żadnego doświadczenia z hurtownią danych.
Gdybym w tym nagraniu zaczął mówić o tym, że w OLTP też mamy historię, też tworzymy archiwum zmian danych to pojawiły się pytania - czym się różni baza od hurtownii w tym kontekście. Odcinek nagrywałem już ponad rok temu, ale wydaje mi się, że wspominałem na samym końcu, że taka sytuacja może zaistnieć(archiwalne dane w bazie danych). A wtedy partycjonowanie i inne techniki wykorzystywane w dwh też mają przy OLTP zastosowanie jak słusznie zauważyłeś.
@@nieinformatyk "w modelowej transakcyjnej bazie danych nie przechowujemy danych historycznych, a jeśli tak to niewielki jej zakres" - i tu jesteś w błędzie, bardzo wiele firm przechowuje dane historyczne w relacyjnych bazach danych, chociażby z tego powodu, że nie posiada hurtowni danych, np. bo nie ma takiej potrzeby, bo jest dla nich za droga, gdy skala ich biznesów nie jest tak duża aby wydawać pierdyliard złotówek na budowę i utrzymanie hurtowni danych
@@jacekkangaroo4402 ale to niczego nie zmienia z punktu widzenia teorii - modelowa baza transakcyjna nie przechowuje historii. O tym, że rzeczywistość wygląda inaczej mówiłem pod koniec nagrania - baza danych to często OLTP + trochę OLAP.
Przydatne.
dziękuję ;)
mając tabelę pokazującą aktualny stan magazynowy nie potrzebujesz indeksu na kolumnie 'number of items', wystarczy ci tylko indeks na kolumnie 'product code', także aktualizacja stanu magazynowego nie wymaga aktualizacji dodatkowego indeksu na tabeli, to tak w skrócie bez wdawania się w szczegóły, przykład do filmu nieco nietrafiony
Nie pamiętam jakiego przykładu użyłem w nagraniu, więc albo ja się pomyliłem, albo Ty mnie źle zrozumiałeś :)
Jeśli chcemy czytać stan magazynowy produktów to oczywiście tak jak piszesz wystarczy indeks na kolumnie z id_produktu(+ ewentualnie data zasilania/obowiązywania danych).
Indeks podlegałby wtedy aktualizacji w przypadku UPDAT-e na kluczu głównym(zmiana id_produktu).
@@nieinformatyk 11:55 "chcąc modyfikować dane w tabeli, np. stan magazynowy, jednocześnie musiałbym zmodyfikować index" - zwykle szukamy produktu przy użyciu indeksu kod produktu, a następnie w tabeli jego atrybutów, np. stan na magazynie (dwie operacje odczytu z bazy, raz index (index też jest tabelą i wymaga osobnej operacji odczytu), drugi raz tabela), ale są przypadki gdy chcemy przyścieszyć działanie odczytu i wtedy umieszczamy taką kolumnę w indeksie, wtedy faktycznie mamy nieco większy koszt w czasie modyfikacji rekordu, ale skracamy czas odczytu gdy nam na tym zależy (wszystko liczone w milisekundach także dla tysięcy transakcji na godzinę bez znaczenia, dopiero przy masowym przetwarzaniu w setkach milionów na godzinę ma znaczenie), bardzo przydatna funkcja w masowym przetwarzaniu danych, szczególnie gdy mamy chained rows w Oracle i nie możemy sobie pozwolić na przebudowę tabeli, ale to już inna historia,
a tak na marginesie, to tabela stan magazynowy jest tabelą raportową, wyliczaną na podstawie dokumentów magazynowych (przyjęto na magazyn, zwrócono do magazynu, protokół zniszczenia, przeniesienia magazynowe, zamówienia klientów itp.), tworzymy takie tabele aby za każdym razem nie przeszukiwać ogromnej tabeli z dokumentami magazynowymi w celu potwierdzenia ilości towaru dostępnego do sprzedaży, a gdy nam się taka tabela rozleci, zawsze możemy ją odtworzyć z danych źródłowych,
i na kolejnym marginesie, za updatey na kluczu głównym obcinałbym ręce, potem jeszcze obdzierał ze skóry, posypywał solą i na koniec zostawił aby samo zdechło :-)
Wydaje mi się, że nie do końca wskazałeś, dlaczego osobnym schematem lub tablespejsem lub nawet tabelą nie da się zrealizować wszystkiego co można zrobić w specjalistycznej instancji hurtowni bazy danych. Powiedziałeś, że ciężko albo się nie da, ale bez konkretnego przypadku/przyczyny.
Pytanie może i jest proste, ale moja odpowiedź by była zrozumiała musiałaby być bardzo długa->temat na oddzielne nagranie :) To trochę jakby próbować z auta sportowego zrobić dostawczak lub na odwrót.
@@nieinformatyk ja rozumiem, ale mogły paść dwa, trzy proste przykłady - jeśli coś jest trudne w wytłumaczeniu w 2 zdaniach znaczy się, że temat nie jest do końca zrozumiały dla samego prelegenta.;)
zastanawia mnie denormalizacja w Data Warehouse, jak bardzo dane powinny byc zdenormalizowane ?
A to zależy, temat rzeka - poczytać o modelu Inmona, Kimballa, Data Vault, Data Vault 2.0 :)
@@nieinformatyk dzięki, poczytam
@@nieinformatyk widzę, że w DW używane są star, snoflake, Galaxy schematy, czyli to nie jest błędem?
@@JanUnitra czemu błędem? model gwiazdy czy płatka śniegu to jedne z kilku podejść architektonicznych do budowy DWH
przykład pracownika jest bardzo nietrafiony, przede wszystkim dlatego że zmiany stanowiska nie są operacjami masowymi (masowa to jest sprzedaż w markecie, połączenia w telekomie, operacje bankowe), ponad to ze względów prawnych w systemie kadrowym powinna znajdować się cała historia zatrudnienia pracownika, wyszukanie aktualnego/historycznego stanowiska pracownika w bazie nawet tysięcy pracowników nie stanowi dla bazy danych żadnego problemu, przekombinowałeś tutaj
Jakież to polskie... Niesamowicie łatwo jest ponarzekać, a tak trudno zrobić coś pożytecznego. Jeżeli nawet dostrzegasz jakieś niedociągnięcia, mogłeś napisać jakiś konstruktywny przykład żeby uzupełnić materiał, ale oczywiście łatwiej tylko marudzić i narzekać. A jakbyś się tak lepiej zastanowił to ten przykład z pracownikami miał coś na szybko zobrazować, może nie jest najlepszy ale napewno jest wystarczający, aby zrozumieć istotę tematu.
Panie Darku dziękuję w imieniu Jacka Kangaroo i wszystkich innych maruderów. Trzymaj się ciepło Panie Darku 👍😊
@@adrreb podawanie niepoprawnych przykładów jest szkodliwe, może wykształcić w młodzikach złe wzorce, które będą powodować problemy w przyszłości, dlatego zwróciłem na to uwagę aby narybek poznał także inny punkt widzenia, także nie napinaj się jak gumka w majtkach i poluzuj warkoczyk, moja opinia nie wynikała z hejtu
@@jacekkangaroo4402 Może twoja wyobraźnia nie ogarnia takich możliwości ale na ten przykład ja pracuję w ogromnej korporacji w której fluktuacja pracowników (na którą zarząd daje zgodę) jest bardzo duża i tego typu przykład jest jak najbardziej adekwatny.
@@adrreb duża baza danych to pojęcie względne, znałem nie jednego gościa co bazę 100 milionów rekordów (i to jeszcze utrzymywaną w majkrosyfie) nazywał bardzo dużą (takiej rotacji pracowników na pewno nie masz nawet przez cały rok)... ja pracowałem w firmach gdzie ładowane pliki danych miały 50-100 milionów rekordów, a zamknięcie miesiąca obejmowało przetworzenie ponad 2 miliarów rekrodów i generowało kolejne kilkaset milionów... optymalizowałem taki proces z 36 godzin do poniżej 24h a jakby posiedzieć dłużej to pewnie jeszcze coś bym urwał ale klient był już zadowolony z takiego postępu
#zasieg
Dzięki :)
Wyjątek potwierdzający regułę znaczy totalnie nie to co powiedziałeś :C
Jaki wyjątek?
@@nieinformatyk Coś powiedziałeś że "wyjątek potwierdzający regułę" w ramach żartu, ale no, nie tak się tego sformułowania używa
@@MrFemex Musiałbyś wskazać konkretny fragment nagrania, bo dalej nie wiem gdzie popełniłem błąd :)