On 13.05.2013 14:46, Michal Kleczek wrote:
>
> Chociaz to chyba i tak bez sensu w dobie zaawansowanych macierzy
> dyskowych, SAN, volume managers, wirtualizacji itd itp...

Dzisiaj pewnie tak. Słyszałem to na wykładzie kilka lat temu na temat
tego jak wyglądał rozwój baz, więc stawiam okolicę lat 90 jak to badano.
Dzisiaj traktować to chyba można raczej w charakterze ciekawostki na
temat tego jakie optymalizacje robiono - ram jest na tyle tani, że
najlepiej mieć bazę w ramie.

Kiedyś było "baza danych jako system plików dla rekordów" teraz
większość systemów plików to obiektowe bazy danych (obsługa równoległego
dostępu, transakcji, wersji, etc).

--
Pozdrawiam
Michoo

do góry

W dniu poniedziałek, 13 maja 2013 14:28:05 UTC+2 użytkownik Michoo napisał:

> Co znaczy, �e CSV jest w buforach. Skonfiguruj baz� danych tak aby
> pracowa�a w trybie wy��czno�ci i spr�buj ponownie. Do tego bazy
> si� specjalnie DEnormalizuje aby poprawi� wydajno�� pewnych operacji.

Mozna denormalizowac. Pytanie tylko, czy to jest celowe i czy warto. Baze
uzywa sie dla wygody, dla czytelnosci, elastycznosci. A jak sie dane
wielokrotnie powieli, widoki sie zmaterializuje, to sie zrobi straszny
bajzel. Zastanawiam sie, czy moze lepiej zrzucic dane do do plikow binarnych i
potem uzywac innych narzedzi.

Pozdrawiam

do góry

On 13.05.2013 15:02, M.M. wrote:
> W dniu poniedziałek, 13 maja 2013 14:23:11 UTC+2 użytkownik Michal Kleczek napisał:
>
>> Ok :-)
>> A moze wykazesz, ze dane w pliku sa na dysku ulozone sekwencyjnie
> Panowie przeciez mozna bardzo prosto, a zarzucacie mi ze jestem
> niedouczony. Co z Wami? Zapisujemy za posrednictwem systemu
> operacyjnego sekwencyjnie dane. Nastepnie mierzymy czas odczytu
> np. 1000 rekordow z poczatku pliku, a potem 1000 z losowych adresow.

I dowiadujemy się...nic.

Porównaj:
/dev/mapper/system-home:
Timing cached reads: 9062 MB in 2.00 seconds = 4533.87 MB/sec
Timing buffered disk reads: 306 MB in 3.00 seconds = 101.88 MB/sec

Jeżeli na bazie danych wymusisz dostęp do dysku w tym drugim trybie to
nic dziwnego, że dostęp do "czystego" pliku w trybie pierwszym będzie
"bardzo szybki", ale to dlatego, że już na początku spowolniłeś bazę 30
razy.

>> Po trzecie - po co zlaczenia?
> A wiesz jakie korzysci plyna z dobrze znormalizowanej bazy danych, czy
> jak ktos proponuje dobra normalizacje to tez pytasz po co?

Poza oszczędnością miejsca i mniejszym czasem dostępu? No jakie?

Zbytnio znormalizowana baza to często błąd. Przy przetwarzaniu dużych
wolumenów danych dane się specjalnie DEnormalizuje.

>
>
>> Po czwarte - jestes pewny, ze z RDBMS wycisnales co sie da? Robiles
>> analize planu zapytania? Uzyles najlepszych mozliwych indeksow? W
>> ostatecznosci - uzyles zmaterializowanych widokow?
> O... dochodzimy do sedna, a juz tracilem nadzieje. Materializowane widoki
> sa tym samym co mozna zrobic na plikach, tyle ze na plikach nie ma
> narzutu kobylastej bazy i moge se napisc w C++ procedure ktora po tym
> pliku przeiteruje i 1000 razy efektywniej przeprowadzi obliczenia niz
> w skrypciaku wewnetrznym bazy.

Nie ma też "udoskonaleń" bazy jak np nie wczytywanie jeszcze raz tego co
zostało już wczytane.

>
>
>
>> Model relacyjny jest _logiczny_ i jako taki ma sie nijak do modelu
>> _fizycznego_. Mowienie o ograniczeniach modelu logicznego jest troche
>> bez sensu...
> A to ze glowny problem z wydajnoscia sie bierze z odszukiwania danych
> na podstawie relacji to oczywiscie jest niewazne.

Jeżeli jest to twoje główne ograniczenie to znaczy, ze masz skopaną
strukturę. I tak, zrobienie tego samego na pliku będzie pewnie trochę
szybsze. Tylko szybsze w sensie pisania tego byłoby użycie bazy zamiast
pisania samemu jej fragmentów.

--
Pozdrawiam
Michoo

do góry

On 13.05.2013 15:17, M.M. wrote:
> W dniu poniedziałek, 13 maja 2013 14:28:05 UTC+2 użytkownik Michoo napisał:
>
>> Co znaczy, �e CSV jest w buforach. Skonfiguruj baz� danych tak aby
>> pracowa�a w trybie wy��czno�ci i spr�buj ponownie. Do tego bazy
>> si� specjalnie DEnormalizuje aby poprawi� wydajno�� pewnych operacji.
>
> Mozna denormalizowac. Pytanie tylko, czy to jest celowe i czy warto. Baze
> uzywa sie dla wygody, dla czytelnosci, elastycznosci. A jak sie dane
> wielokrotnie powieli, widoki sie zmaterializuje, to sie zrobi straszny
> bajzel. Zastanawiam sie, czy moze lepiej zrzucic dane do do plikow binarnych i
> potem uzywac innych narzedzi.

Są jeszcze bazy obiektowe - to raz. A od tego są widoki, trigery,
procedury składowane, żeby nie było bajzlu. Taki przykład ze światka
postgresql, który widziałem:
- w bazie trzymany json jako tekst
- dodana funkcja attr(key) zwracająca wartość na podstawie klucza
- utworzony indeks funkcyjny dla różnych, popularnych wywołań atr(key)
Masz prosty storage, szybki dostęp do danych (cache, optymalizacja) i
SQL pozwalający na szybkie filtrowanie/sortowanie danych.

--
Pozdrawiam
Michoo

do góry

On 2013-05-13 15:02, M.M. wrote:
> W dniu poniedziałek, 13 maja 2013 14:23:11 UTC+2 użytkownik Michal Kleczek napisał:
>
>> Ok :-)
>> A moze wykazesz, ze dane w pliku sa na dysku ulozone sekwencyjnie
> Panowie przeciez mozna bardzo prosto, a zarzucacie mi ze jestem
> niedouczony. Co z Wami? Zapisujemy za posrednictwem systemu
> operacyjnego sekwencyjnie dane. Nastepnie mierzymy czas odczytu
> np. 1000 rekordow z poczatku pliku, a potem 1000 z losowych adresow.
>

Sposob, w jaki chcesz mi to udowodnic swiadczy o twojej zupelnej ignorancji.

[ciach]
>> Po trzecie - po co zlaczenia?
> A wiesz jakie korzysci plyna z dobrze znormalizowanej bazy danych, czy
> jak ktos proponuje dobra normalizacje to tez pytasz po co?
>
>
>> Po czwarte - jestes pewny, ze z RDBMS wycisnales co sie da? Robiles
>> analize planu zapytania? Uzyles najlepszych mozliwych indeksow? W
>> ostatecznosci - uzyles zmaterializowanych widokow?
> O... dochodzimy do sedna, a juz tracilem nadzieje.

Nie - sedno jest w tym, ze jeszcze nie pokazales struktury bazy -
zarowno model logiczny jak i fizyczny. Twierdzisz, ze jest optymalny i
jedynym wyjsciem jest przetwarzanie danych poza DBMS. No wiec ja
twierdze, ze najczestszym przypadkiem problemow z wydajnoscia RDBMS jest
nieumiejetne jego wykorzystanie, ew. uzycie kiepskiego RDBMS (jak
chociazby SQLLite).
Dopoki nie pokazesz nam go, twoje twierdzenia o rzekomym 1000krotnym
przyspieszeniu beda bezpodstawne.

> Materializowane widoki
> sa tym samym co mozna zrobic na plikach, tyle ze na plikach nie ma
> narzutu kobylastej bazy i moge se napisc w C++ procedure ktora po tym
> pliku przeiteruje i 1000 razy efektywniej przeprowadzi obliczenia niz
> w skrypciaku wewnetrznym bazy.
>
>
>
>> Model relacyjny jest _logiczny_ i jako taki ma sie nijak do modelu
>> _fizycznego_. Mowienie o ograniczeniach modelu logicznego jest troche
>> bez sensu...
> A to ze glowny problem z wydajnoscia sie bierze z odszukiwania danych
> na podstawie relacji to oczywiscie jest niewazne.
>

No ale przeciez jak zrozumialem w twoim systemie jest potrzebne
przeszukiwanie danych. Jezeli nie jest potrzebne to nie ma o czym mowic.

Dla mnie EOT.

--
Michal

do góry

W dniu poniedziałek, 13 maja 2013 15:23:19 UTC+2 użytkownik Michoo napisał:

> Sďż˝ jeszcze bazy obiektowe - to raz. A od tego sďż˝ widoki, trigery,
> procedury sk�adowane, �eby nie by�o bajzlu. Taki przyk�ad ze �wiatka
> postgresql, kt�ry widzia�em:
> - w bazie trzymany json jako tekst
> - dodana funkcja attr(key) zwracaj�ca warto�� na podstawie klucza
> - utworzony indeks funkcyjny dla r�nych, popularnych wywo�a� atr(key)
> Masz prosty storage, szybki dost�p do danych (cache, optymalizacja) i
> SQL pozwalaj�cy na szybkie filtrowanie/sortowanie danych.

Dla mnie denormalizacja bazy i materializacja duzej ilosci widokow to
bajzel i zrodlo problemow. Wydaje sie ze lepiej miec przejrzysta baze, a
z problemami wydajnosciowymi radzic sobie poza baza.

Pozdrawiam

do góry

Użytkownik "M.M." <m...@g...com> napisał w wiadomości
news:dadb95bf-e4d6-4d49-ae4f-70316cebf63b@googlegrou
ps.com...
W dniu poniedziałek, 13 maja 2013 14:37:17 UTC+2 użytkownik Stachu 'Dozzie'
K. napisał:
>> > Nie umiecie, bo tego nie da sie uzasadnic.
>> Da siďż˝, to tylko ty nie znasz siďż˝ na podstawach. Zresztďż˝ na tej
>> grupie
>> sam si� przyznawa�e� do braku formalnego przygotowania
>> informatycznego
>> (je�li dobrze pami�tam), a z kalibru pyta� to wida� jeszcze
>> lepiej.
>Stachu, odczytywales z raz w zyciu dane z pliku? Probowales kiedy odczytac
>z sekwencyjnych adresow? A moze tez probowales z losowych adresow?
>Mierzyles
>czasy stoperem, czy bylo widac roznice golym okiem? Ja z kalibru Twoich
>postow wnioskuje, ze nigdy nie oczytywales danych z pliku.

Kiedy trzy osoby mowia ci bys sie przespal, to znaczy, ze naprawde jestes
pijany.

do góry

Użytkownik "M.M." <m...@g...com> napisał w wiadomości
news:1e7d112f-a549-40f2-a7fa-e03c1f43be34@googlegrou
ps.com...
W dniu poniedziałek, 13 maja 2013 15:23:19 UTC+2 użytkownik Michoo napisał:

>> Sďż˝ jeszcze bazy obiektowe - to raz. A od tego sďż˝ widoki, trigery,
>> procedury sk�adowane, �eby nie by�o bajzlu. Taki przyk�ad ze
>> �wiatka
>> postgresql, kt�ry widzia�em:
>> - w bazie trzymany json jako tekst
>> - dodana funkcja attr(key) zwracaj�ca warto�� na podstawie klucza
>> - utworzony indeks funkcyjny dla r�nych, popularnych wywo�a�
>> atr(key)
>> Masz prosty storage, szybki dost�p do danych (cache, optymalizacja) i
>> SQL pozwalaj�cy na szybkie filtrowanie/sortowanie danych.

>Dla mnie denormalizacja bazy i materializacja duzej ilosci widokow to
>bajzel i zrodlo problemow. Wydaje sie ze lepiej miec przejrzysta baze, a
>z problemami wydajnosciowymi radzic sobie poza baza.

Kolejny samouk.

do góry

W dniu poniedziałek, 13 maja 2013 15:30:17 UTC+2 użytkownik Michal Kleczek napisał:

> Sposob, w jaki chcesz mi to udowodnic swiadczy o twojej zupelnej ignorancji.
Widzisz, czasami mozna prosto udowodnic, bez wnikania w milion zbednych
szczegolow? Wiem ze mozna samochod wziac do laboratorium, przez rok go
mierzyc i badac, a potem podac jaka osiga predkosc maksymalna. Chodzi oto,
ze mozesz tez do niego wziasc, wcisnac gaz do dechy i masz ten sam efekt w
30 minut a nie w rok.


> Nie - sedno jest w tym, ze jeszcze nie pokazales struktury bazy -
> zarowno model logiczny jak i fizyczny. Twierdzisz, ze jest optymalny i
> jedynym wyjsciem jest przetwarzanie danych poza DBMS.
Nie twierdze ze to jedyne wyjscie. Zobacz ile razy pisalem ze
clustered plus materializowanie widokow plus denormalizacja tez
zapewni duza efektywnosc.


> No wiec ja
> twierdze, ze najczestszym przypadkiem problemow z wydajnoscia RDBMS jest
> nieumiejetne jego wykorzystanie, ew. uzycie kiepskiego RDBMS (jak
> chociazby SQLLite).
Gdy sprawdzalem, to akurat SQLite dzialal u mnie okolo 15 razy szybciej
niz postgres, na prawie identycznej bazie.


> Dopoki nie pokazesz nam go, twoje twierdzenia o rzekomym 1000krotnym
> przyspieszeniu beda bezpodstawne.
Nie ma sensa.


> No ale przeciez jak zrozumialem w twoim systemie jest potrzebne
> przeszukiwanie danych. Jezeli nie jest potrzebne to nie ma o czym mowic.
Nie widze zwiazku.

Pozdrawiam

do góry

On 2013-05-13, Michal Kleczek <m...@k...org> wrote:
[...]
> No wiec ja
> twierdze, ze najczestszym przypadkiem problemow z wydajnoscia RDBMS jest
> nieumiejetne jego wykorzystanie, ew. uzycie kiepskiego RDBMS (jak
> chociazby SQLLite).

Przepraszam, SQLite nie jest kiepski. On nie nadaje się do pewnej klasy
zastosowań, trzeba jedynie wiedzieć do jakiej klasy się nadaje (to
znaczy do czego był projektowany).

Ale to tylko tak dla formalności.

--
Secunia non olet.
Stanislaw Klekot

do góry