On 2013-05-13 12:05, M.M. wrote:
> W dniu poniedziałek, 13 maja 2013 09:59:47 UTC+2 użytkownik Michal Kleczek napisał:
>
>> W calym watku to sie pojawia wielokrotnie:
>> 1. twoje rozwiazania tego nie zapewniaja bo operuja na poziomie systemu
>> plikow - a od systemu plikow do fizycznego rozlozenia danych na
>> nosnikach jeszcze baaaaaaardzo daleka droga
> Czy potrafisz to jakos uzasadnic?
>

Tak, ale nie chce mi sie, bo to oczywista oczywistosc dla kogokolwiek,
kto ma chocby blade pojecie co to jest i jak dziala system plikow oraz
czym "plik" tak naprawde jest.

>
>> 2. DBMS jest dokladnie pod to projektowany, by minimalizowac ilosc
>> operacji we/wy przy dostepie do danych
> Tu na pewno mylisz sie. Pisalem w tym watku kilka razy, napisze jeszcze raz:
> projektowany jest po pierwsze pod ogolny przypadek. Poza tym projektowany
> jest pod wygode, elastycznosc, bezpieczenstwo, transakcje, wielodostepnosc
> itd. Minimalizowanie operacji we/wy ma ktorys z kolei priorytet.
>

Jasne. I dlatego wlasnie ktos wymysla struktury danych typu B-drzewa -
specjalizowane wlasnie w celu minimalizacji ilosci operacji we/wy.

>
>> Wziac dobry (odpowiedni do zastosowan) DBMS. NIE probowac robic "lepiej".
> Nie mam bladego jak uzywasz slowa "lepiej", pewnie zupelnie inaczej niz ja.
>
>
>> Kazdy indeks jest po to, zeby minimalizowac czas dostepu do danych.
>> Rozne rodzaje indeksow sa przeznaczone do
>> a) roznego rodzaju dostepu
>> b) roznych rodzajow danych
>> Sa rozne rodzaje indeksow. Na poczatek:
>> http://en.wikipedia.org/wiki/Database_index
> A jesli dane sa rozrzucone po dysku, to zaden indeks nie pomoze i
> trzeba zrobic tyle odczytow, ile jest danych, prawda?
>

_Zawsze_ trzeba odczytac przynajmniej tyle, zeby potrzebne dane z dysku
wczytac do pamieci. Kwestia jest jak te dane na dysku znalezc, zeby
zminimalizowac koniecznosc niepotrzebnych dodatkowych odczytow.

Przyklad z twoim plikiem CSV posortowanym po dacie. Zalozmy, ze zawiera
N rekordow. Pierwszy ma w kolumnie daty wartosc 2001-01-01. Ile potrzeba
odczytow, zeby znalezc rekordy z data 2011-02-23?

>
>> Trzymanie danych "obok siebie" niekoniecznie jest najlepsza strategia.
> Dobrze rozumiem: Niekoniecznie, czyli może być najlepszą?
>

Moze.

>
>>> Clustered mozna
>>> zakladac tylko na jedno pole, wiec odpada, prawda?
>> Nieprawda.
> Czytalem ze tylko na jedno, no ale dobra. Wiec pytanie: jak w bazach
> jest realizowany clustered na więcej niż jednym polu?
>

Nie rozumiem pytania... Tak samo jak na jednym.

>
>
>> Jestem - probuje ci chyba bezskutecznie uswiadomic, ze proponowane przez
>> ciebie rozwiazania to nic innego jak indeksy w DBMS.
> Moze sie mylisz? Moje rozwiazanie w jednym programie potrzebuje kilku
> sekund a na sqlite trwalo 90 minut na nieplnej bazie.
>

Mozesz pokazac kod jednego i drugiego? W szczegolnosci strukture bazy i
zapytanie?
Bo jesli masz taka roznice, to znaczy, ze cos straszliwie schrzaniles.

>
>
>> Prawie na pewno szybciej, niz zrobi to kod pisany przez ciebie.
> Tez to pisalem wiele razy. Nie chodzi o sciganie sie z baza danych
> na poziomie samego kodu. Chodzi jeszcze o sciganie sie na poziomie
> stuktur danych.

Dokladnie :-)

--
Michal

do góry

W dniu poniedziałek, 13 maja 2013 13:24:32 UTC+2 użytkownik Michal Kleczek napisał:

> Tak, ale nie chce mi sie, bo to oczywista oczywistosc dla kogokolwiek,
> kto ma chocby blade pojecie co to jest i jak dziala system plikow oraz
> czym "plik" tak naprawde jest.
Nie umiesz uzasadnic.


> Jasne. I dlatego wlasnie ktos wymysla struktury danych typu B-drzewa -
> specjalizowane wlasnie w celu minimalizacji ilosci operacji we/wy.
To uzasadnij jak b-drzewo umozliwia oczytanie np. 30 losowo rozrzuconych
rekordow po dysku w sekwencyjny sposob.


> _Zawsze_ trzeba odczytac przynajmniej tyle, zeby potrzebne dane z dysku
> wczytac do pamieci. Kwestia jest jak te dane na dysku znalezc, zeby
> zminimalizowac koniecznosc niepotrzebnych dodatkowych odczytow.
To polowa problemu i w dodatku ta, co co ktorej nie kwestionuje
skutecznosci baz danych.


> Przyklad z twoim plikiem CSV posortowanym po dacie. Zalozmy, ze zawiera
> N rekordow. Pierwszy ma w kolumnie daty wartosc 2001-01-01. Ile potrzeba
> odczytow, zeby znalezc rekordy z data 2011-02-23?
Nie wiem, za malo danych podales. U mnie budowanie z normalizowanej
bazy tego co jest w pliku csv trwa 10-30 sekund. Wyszukanie pliku csv
na dysku i wczytanie trwa ulamek sekundy.



> >> Trzymanie danych "obok siebie" niekoniecznie jest najlepsza strategia.
> > Dobrze rozumiem: Niekoniecznie, czyli mo�e by� najlepsz�?
> Moze.
Ciesze sie ze dobrze zrozumialem.


> Nie rozumiem pytania... Tak samo jak na jednym.
Ja czytalem ze to jest niemozliwe i logika podpowaida to samo: ze bez
dodatkowych zabiegow jest to niemozliwe. Pytam wiec jakie dodatkowe
zabiegi stosuja silniki baz danych aby bylo mozliwe indeksowanie
culstered po kilku polach.



> Mozesz pokazac kod jednego i drugiego? W szczegolnosci strukture bazy i
> zapytanie?
Po co? Przeciez to oczywiste ze kazde zlaczenie trwa potencjalnie dluzej niz
odczytanie gotowych danych z csv.


> Bo jesli masz taka roznice, to znaczy, ze cos straszliwie schrzaniles.
Nie zchrznilem, model relacyjny, choc moze byc perfekcyjnie
zaindeksowany, ma swoje ograniczenia.



> >> Prawie na pewno szybciej, niz zrobi to kod pisany przez ciebie.
> > Tez to pisalem wiele razy. Nie chodzi o sciganie sie z baza danych
> > na poziomie samego kodu. Chodzi jeszcze o sciganie sie na poziomie
> > stuktur danych.
> Dokladnie :-)
Co dokladnie?


Pozdrawiam

do góry

On 2013-05-13, M.M. <m...@g...com> wrote:
> W dniu poniedziałek, 13 maja 2013 13:24:32 UTC+2 użytkownik Michal Kleczek napisał:
>
>> Tak, ale nie chce mi sie, bo to oczywista oczywistosc dla kogokolwiek,
>> kto ma chocby blade pojecie co to jest i jak dziala system plikow oraz
>> czym "plik" tak naprawde jest.
> Nie umiesz uzasadnic.

Umie. To naprawdę są podstawy architektury współczesnych systemów
operacyjnych. Możemy ci polecić dowolny kurs na ten temat, ewentualnie
literaturę ("Podstawy systemów operacyjnych", Galvin, Silberschatz).

Chodzi o to, że nie ma sensu dyskusja zaawansowana technicznie z kimś,
kto w temacie jest jeszcze niedouczony.

--
Secunia non olet.
Stanislaw Klekot

do góry

W dniu poniedziałek, 13 maja 2013 14:12:43 UTC+2 użytkownik Stachu 'Dozzie' K.
napisał:
> Umie. To naprawd� s� podstawy architektury wsp�czesnych system�w
> operacyjnych. Mo�emy ci poleci� dowolny kurs na ten temat, ewentualnie
> literatur� ("Podstawy system�w operacyjnych", Galvin, Silberschatz).
> Chodzi o to, �e nie ma sensu dyskusja zaawansowana technicznie z kim�,
> kto w temacie jest jeszcze niedouczony.

Nie umiecie, bo tego nie da sie uzasadnic.
Pozdrawiam

do góry

On 2013-05-13 13:51, M.M. wrote:
> W dniu poniedziałek, 13 maja 2013 13:24:32 UTC+2 użytkownik Michal Kleczek napisał:
>
>> Tak, ale nie chce mi sie, bo to oczywista oczywistosc dla kogokolwiek,
>> kto ma chocby blade pojecie co to jest i jak dziala system plikow oraz
>> czym "plik" tak naprawde jest.
> Nie umiesz uzasadnic.
>

Ok :-)
A moze wykazesz, ze dane w pliku sa na dysku ulozone sekwencyjnie
(cokolwiek by to mialo znaczyc)?

>
>> Jasne. I dlatego wlasnie ktos wymysla struktury danych typu B-drzewa -
>> specjalizowane wlasnie w celu minimalizacji ilosci operacji we/wy.
> To uzasadnij jak b-drzewo umozliwia oczytanie np. 30 losowo rozrzuconych
> rekordow po dysku w sekwencyjny sposob.
>

Tego nie umozliwia bo nie po to jest. Odpowiadalem na twoje twierdzenie,
ze bazy danych nie sa projektowane pod minimalizacje ilosci operacji we/wy.

>
>> _Zawsze_ trzeba odczytac przynajmniej tyle, zeby potrzebne dane z dysku
>> wczytac do pamieci. Kwestia jest jak te dane na dysku znalezc, zeby
>> zminimalizowac koniecznosc niepotrzebnych dodatkowych odczytow.
> To polowa problemu i w dodatku ta, co co ktorej nie kwestionuje
> skutecznosci baz danych.
>

To jest ta "wieksza polowa".

>
>> Przyklad z twoim plikiem CSV posortowanym po dacie. Zalozmy, ze zawiera
>> N rekordow. Pierwszy ma w kolumnie daty wartosc 2001-01-01. Ile potrzeba
>> odczytow, zeby znalezc rekordy z data 2011-02-23?
> Nie wiem, za malo danych podales.

Jakich jeszcze brakuje? Chetnie podam.

> U mnie budowanie z normalizowanej
> bazy tego co jest w pliku csv trwa 10-30 sekund. Wyszukanie pliku csv
> na dysku i wczytanie trwa ulamek sekundy.
>

A co to ma do rzeczy?

>
>
>>>> Trzymanie danych "obok siebie" niekoniecznie jest najlepsza strategia.
>>> Dobrze rozumiem: Niekoniecznie, czyli mo�e by� najlepsz�?
>> Moze.
> Ciesze sie ze dobrze zrozumialem.
>
>
>> Nie rozumiem pytania... Tak samo jak na jednym.
> Ja czytalem ze to jest niemozliwe i logika podpowaida to samo: ze bez
> dodatkowych zabiegow jest to niemozliwe.

Gdzie czytales? Mozna zrodlo? Mozna rowniez prosic o wywod logiczny,
ktory tego dowodzi?
Bo np tu:
http://msdn.microsoft.com/en-us/library/aa933131(v=s
ql.80).aspx
w czwartym zdaniu jest napisane cos zgola innego.

>
>> Mozesz pokazac kod jednego i drugiego? W szczegolnosci strukture bazy i
>> zapytanie?
> Po co? Przeciez to oczywiste ze kazde zlaczenie trwa potencjalnie dluzej niz
> odczytanie gotowych danych z csv.
>

Po pierwsze - niekoniecznie.
Po drugie - jesli nawet, to byc moze roznica jest pomijalna.
Po trzecie - po co zlaczenia?

Po czwarte - jestes pewny, ze z RDBMS wycisnales co sie da? Robiles
analize planu zapytania? Uzyles najlepszych mozliwych indeksow? W
ostatecznosci - uzyles zmaterializowanych widokow?

>
>> Bo jesli masz taka roznice, to znaczy, ze cos straszliwie schrzaniles.
> Nie zchrznilem, model relacyjny, choc moze byc perfekcyjnie
> zaindeksowany, ma swoje ograniczenia.
>

Model relacyjny jest _logiczny_ i jako taki ma sie nijak do modelu
_fizycznego_. Mowienie o ograniczeniach modelu logicznego jest troche
bez sensu...

--
Michal

do góry

On 13.05.2013 13:51, M.M. wrote:
> W dniu poniedziałek, 13 maja 2013 13:24:32 UTC+2 użytkownik Michal Kleczek napisał:
>
>> Tak, ale nie chce mi sie, bo to oczywista oczywistosc dla kogokolwiek,
>> kto ma chocby blade pojecie co to jest i jak dziala system plikow oraz
>> czym "plik" tak naprawde jest.
> Nie umiesz uzasadnic.
>
>
>> Jasne. I dlatego wlasnie ktos wymysla struktury danych typu B-drzewa -
>> specjalizowane wlasnie w celu minimalizacji ilosci operacji we/wy.
> To uzasadnij jak b-drzewo umozliwia oczytanie np. 30 losowo rozrzuconych
> rekordow po dysku w sekwencyjny sposob.

W "bazie na literkę O" afaik jeżeli umieścisz bazę na osobnej partycji a
nie w pliku to:
- odczytuje adresy bloków do załadowania
- ustala sekwencję odczytu tak aby sekwencja seeków była najkrótsza
(czasami czyta się trochę danych sekwencyjnie tylko po to, żeby nie
marnować czasu na seek)
- ładuje rekordy do pamięci i sortuje wg zadanej sekwencji.

>
>> Przyklad z twoim plikiem CSV posortowanym po dacie. Zalozmy, ze zawiera
>> N rekordow. Pierwszy ma w kolumnie daty wartosc 2001-01-01. Ile potrzeba
>> odczytow, zeby znalezc rekordy z data 2011-02-23?
> Nie wiem, za malo danych podales. U mnie budowanie z normalizowanej
> bazy tego co jest w pliku csv trwa 10-30 sekund.
> Wyszukanie pliku csv
> na dysku i wczytanie trwa ulamek sekundy.

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.


>> Nie rozumiem pytania... Tak samo jak na jednym.
> Ja czytalem ze to jest niemozliwe i logika podpowaida to samo: ze bez
> dodatkowych zabiegow jest to niemozliwe. Pytam wiec jakie dodatkowe
> zabiegi stosuja silniki baz danych aby bylo mozliwe indeksowanie
> culstered po kilku polach.

http://www.dba-oracle.com/oracle_tip_hash_index_clus
ter_table.htm


>
>
>
>> Mozesz pokazac kod jednego i drugiego? W szczegolnosci strukture bazy i
>> zapytanie?
> Po co? Przeciez to oczywiste ze kazde zlaczenie trwa potencjalnie dluzej niz
> odczytanie gotowych danych z csv.

Jeżeli CSV jest mały i zbuforowany w pamięci to może. Jeżeli kilka
wartości się powtarza bardzo często to JOIN może być szybszy bo wykona
się w pamięci, nie trzeba będzie czytać tych samych danych wielokrotnie.

--
Pozdrawiam
Michoo

do góry

On 2013-05-13, M.M. <m...@g...com> wrote:
> W dniu poniedziałek, 13 maja 2013 14:12:43 UTC+2 użytkownik Stachu 'Dozzie' K.
napisał:
>> Umie. To naprawd� s� podstawy architektury wsp�czesnych system�w
>> operacyjnych. Mo�emy ci poleci� dowolny kurs na ten temat, ewentualnie
>> literatur� ("Podstawy system�w operacyjnych", Galvin, Silberschatz).
>> Chodzi o to, �e nie ma sensu dyskusja zaawansowana technicznie z kim�,
>> kto w temacie jest jeszcze niedouczony.
>
> 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.

--
Secunia non olet.
Stanislaw Klekot

do góry

On 2013-05-13 14:28, Michoo wrote:
> On 13.05.2013 13:51, M.M. wrote:
>> To uzasadnij jak b-drzewo umozliwia oczytanie np. 30 losowo rozrzuconych
>> rekordow po dysku w sekwencyjny sposob.
>
> W "bazie na literkę O" afaik jeżeli umieścisz bazę na osobnej partycji a
> nie w pliku to:
> - odczytuje adresy bloków do załadowania
> - ustala sekwencję odczytu tak aby sekwencja seeków była najkrótsza
> (czasami czyta się trochę danych sekwencyjnie tylko po to, żeby nie
> marnować czasu na seek

Dziekuje za info.

Chociaz to chyba i tak bez sensu w dobie zaawansowanych macierzy
dyskowych, SAN, volume managers, wirtualizacji itd itp...
Ale moge sie mylic :-)

--
Michal

do góry

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.


> (cokolwiek by to mialo znaczyc)?
A co to moze znaczyc, jesli temat wyszedl w kontekscie optymalizacji?


> Tego nie umozliwia bo nie po to jest.
Jesli do tego nie jest, to poco dwa posty wyzej podsuwasz mi taki rozwiazania?


> Odpowiadalem na twoje twierdzenie,
> ze bazy danych nie sa projektowane pod minimalizacje ilosci operacji we/wy.
Ale to twierdzenie padlo chyba w bardzo konkretnym kontekscie, a nie ogolnie?


> To jest ta "wieksza polowa".
Zalezy jak mierzyc. W moim przypadku niewiele daje, czyli jest to
kiepski mechanizm. Znasz takie powiedzenie o golebiu na dachu i wroblu
w garsci?


> Jakich jeszcze brakuje? Chetnie podam.
Lepiej nie, czas leci, a nic z tego dobrego ani dla mnie, ani dla Ciebie.


> A co to ma do rzeczy?
Bo o tym wlasnie rozmawiam od N postow, a nie o jakis plikach
od 2001-01-01 do 2011-02-23 z ktorymi wyskoczyles chyba jedynie
po to, aby udowodnic cos na inny temat.


> Gdzie czytales? Mozna zrodlo? Mozna rowniez prosic o wywod logiczny,
> ktory tego dowodzi?
> http://msdn.microsoft.com/en-us/library/aa933131(v=s
ql.80).aspx
Jest to napisane w dwoch pierszych zdaniach w linku ktory
mi podeslales.


> w czwartym zdaniu jest napisane cos zgola innego.
To bylo juz kilkanascie postow wyzej, wiec myslame ze zalapiesz
skrotowa forme. No ale dobra, niech bedzie moja wina, niedokladnie
napisalem.


> Po pierwsze - niekoniecznie.
Wyjasniam znaczenie slowa niekoniecznie: w 99% przypadkow tak, w 1% nie.


> Po drugie - jesli nawet, to byc moze roznica jest pomijalna.
Racja, 100 krotne przyspieszenie jest pomijalne.


> 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. 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.


Pozdrawiam

do góry

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.

do góry