W dniu poniedziałek, 6 maja 2013 23:28:02 UTC+2 użytkownik R.e.m.e.K napisał:

> A jaki system plikow tak dziala? Pytam z ciekawosci, bo o ile mi wiadomo
> linuksowy Ext4 sie fragmentuje, NTFS wiadomo ze tak, jablkowy HFS takze.
> Jaki nie?
Nie wiem jakie systemy plikow co maja zaimplementowane, ale istnieje
algorytm bardzo odporny na fragmentacje. Poczatek pliku zaklada sie
"w srodku" najwiekszej wolnej przestrzeni. Gwarantuje to duze prawdop.
ze bedzie miejsce bezposrednio za plikiem, gdy bedziemy chcieli dopisac
dane na jego koncu. Istnieje jeszcze kilka innych technik, mysle ze
mozna poczytac i wybrac dobry system plikow dla danego zastosowania.



> Ogolna zasada budowy plikow bazy danych jest taka, ze plik jest zbudowany ze
> stron, kazda taka strona ma okreslony rozmiar i jest alokowana w chwili, gdy
> poprzednia strona sie "skonczy".
Nie wiem, ale nie sadze aby bazy dane nie oferowaly lepszych mozliwosci - co
akurat w jakims stopniu przemawia przeciwko optymalizacji recznej :)

> Juz sam fakt korzystania ze stron i ich dynamicznego przydzialu powoduje,
> ze beda one rozrzucone po dysku. Nie sadze by jakikolwiek system plikow
> gwarantowal, ze konkretnemu plikowi bazy danych da ciagly obszar dysku.
Wystarczy ze plik nie jest w ogromnej ilosci malych kawaleczkow.
Gwarancja nie jest potrzebna, wystarczy ze prawdopodobienstwo
fragmentacji jest znikome.


> Nawet gdyby tak bylo, to np. dane tabeli A moglby
> byc w stronach 2, 10, 23, 65, 127, etc. Czyli i tak nie po kolei.
Wlasnie, tak moze byc, a to jest argument za reczna optymalizacja.

> Tu masz o MS SQLu troche od kuchni. W innych serwerach jest podobnie.
> http://edu.pjwstk.edu.pl/wyklady/szb/scb/wyklad15/w1
5.htm
Dzieki.


> > Myślałem że może są jakieś zaawansowane optymalizatory.
> Optymalizatory sa, ale nie alokacji danych na dysku
Ok, o to pytalem.


> a zapytan, tworzace plan
> zapytania z uwzglednieniem indeksow (lub nawet tworzeniem ich w locie w
> razie potrzeby, jak umie czynic to MS SQL) i "inteligentnych" zlaczen.
Cos widzialem, kiedys od przypadku nawet korzystalem z jakiegos.


> Nie mozesz oczywiscie, nikt nie jest omnibusem, ale przynajmniej masz
> material do weryfikacji i przemyslen :-)
Ok, dzieki.


> Nie no.. oczywiscie. Ale nie o to mi chodzilo. Chodzilo mi o zrobienia
> enginu analogicznego do RDBMS, czyli takich "plikow CSV" i ich obslugi, ze
> mozesz dodawac miliony nowych wpisow w dowolnej kolejnosci do dowolnych
> plikow,
Moze by sie dalo, ale chodzi wlasnie o to, aby nie robic w pelni
funkcjonalnej bazy danych, tylko baze bardzo specjalistyczna i
duzo szybsza.



> laczyc podczas wyszukiwania dane z roznych plikow po jakims
> kluczu/kluczach, wyszukiwanie pozwalaloby zakladac warunki wybierajace tylko
> niektore wpisy z plikow (zlozona klauzula WHERE na kilku plikach).
> Bo jesli mowa o stalej (read only) strukturze danych, ktora jest ulozona w
> kolejnosci odczytu i odczyty sa sekwencyjne (np. 500 rekordow od setnego) to
> oczywiscie tak, mogles to napisac bez wiekszego trudu.
Nie chodzi o cos az tak prostego, ale idea jest wlasnie taka.



> > Zrób eksperyment. Załóż bazę która zawiera 5-7 tabel dużych tabel. Połącz
> > wszystkie tabele jakimiś relacjami. Napisz zapytanie do wyciągania danych.
> > Zmierz czas zapytania. Potem zapisz wyniki zapytania w pliku, w postaci
> > liniowych rekordów. Ostatecznie zmierz czas odczytania tego pliku ( w
> > jakimś dobrym języku, może Java, albo C++). Zobacz jakie będą różnice w
> > czasie.

> Ale czekaj... co znaczy "Potem zapisz wyniki zapytania w pliku, w postaci
> liniowych rekordów. Ostatecznie zmierz czas odczytania tego pliku"? Czyli
> RDBMS odwali cala robote z szukaniem, a potem mam mierzyc wczytanie pliku
> textowego z wynikami i to porownywac z baza?? Cos mi tu nie halo.
Chodzilo o cos innego, ale tak jak napisales czasami tez mozna zrobic.
Trzymamy dane w bazie i korzystamy z zalet bazy. Raz na dobe wyciagamy
dane z bazy do plikow tekstowych. Uzytkownikom podajemy dane lekko
zdeaktualizowane, ale z plikow liniowych, bez wykonywania kosztownych zlaczen.


> Lub pozwolic serwerowi zrobic indeks.
To mialem na mysli.

> Lub w sprzyjajacych warunkach (zalezy od rodzaju danych) odczytac dane
> bezposrednio z indeksu (to tez "w locie i po cichu" potrafia dobre RDBMS).
Ale to chyba tylko gdy chcemy dane z jednej kolumny? W przeciwnym razie to
by oznaczalo wlasnie taka mozliwosc o jaka pytalem, czyli sekwencyjne
ulozenie potrzebnych danych.


> Heh, myslisz, ze serwery SQL nie trzymaja ile sie da w ramie?
Chodzilo mi o przypadek, gdy RAM jest np. 100 razy mniej niz danych
na dyskach.


> To jeden z
> fundamentow wydajnosci. Nawet cale bazy potrafia trzymac jak maja odpowiedni
> sprzet (czyt. kupe ramu).
Zgoda, ale w specjalistycznym przypadku programista moze lepiej wiedziec
ktore dane i w jaki sposob buforowac w RAM.


> Zycze Ci oczywiscie sukcesow, ale imho skupiasz energie w zlym miejscu. Lub
> moze inaczej, warto sie tym zajmowac wtedy, gdy wszystko inne bedzie
> stuningowane na maksa.
Nie wiem czy w zlym miejscu. Licze ile kosztuje sprzet, ile reklamy, ile
praca... Do tego moj klient twierdzi ze 10tys uzytykownikow to jest nic...
Patrze na czasy zapytan i widze to 2 sekundy, to 10 sekund, czasami nawet
ponad 100 sekund...

10tys userow * 5sekundy * 30 odslon na jednego usera = 420 godzin na same
zapytania - jakby na odslone bylo jedno zapytanie :/


> Chodzilo mi tu o dobra, przemyslana strukture tabel i indeksow. Do
> zarzadzania plikami serwer uzywa inzynierow swojego producenta ;-)
No ale mnie to boli pomimo przemyslanych struktur tabel i indeksow :)

Pozdrawiam