Dnia Mon, 6 May 2013 12:55:09 -0700 (PDT), M.M. napisał(a):

>> A co z fragmentacja dysku?
> Z tego co słyszałem, problem fragmentacji dysku na dobrych systemach
> plików nie występuje przy spełnieniu prostego warunku: dysk nie może
> być zapełniony, musi na nim być zawsze pewien zapas wolnego miejsca.

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?

>> Co Ci da to, ze dane beda "obok" siebie w pliku
> Nie chodzi o to co da, ale co zlikwiduje. Zlikwiduje zbędne naprowadzania
> głowicy. Będzie odczyt sekwencyjny zamiast random.

No tak, przy zalozeniu, ze fragmentacja dysku nie istnieje.

>> skoro beda na dwoch koncach dysku?
> O ile się nie mylę, na dobrych systemach plików tak się dzieje bardzo rzadko.

Podaj nazwy tych dobrych systemow plikow.

>> Pomijajac juz taki detal, ze nie ma zadnego mechanizmu ukladania
>> danych w tabelach wg swoich widzimisie.
> Skoro znasz tak dobrze silniki bazodanowe, to wierzę, że takiego mechanizmu
> żaden silnik nie oferuje. Ja je znam bardzo pobieżnie... umiem założyć
> tabelę, indeksy, zrobić zapytanie, ewentualnie umiem dodać jakiś triger.

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

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

> Myślałem że może są jakieś zaawansowane optymalizatory.

Optymalizatory sa, ale nie alokacji danych na dysku 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.

>> Tym zarzadza serwer i nie masz do tego dostepu. Nie istnieje takie
>> pojecie jak kolejnosc ulozenia danych w pliku bazy danych.
> Kilka dni temu też tak powiedziałem, kumpel na to mi odrzekł: znasz góra
> 10% możliwości dwóch baz, lepiej się upewnij. Rozumiem że Ty znasz
> bazy danych w 100% i mogę na tej informacji polegać?

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

>> Z pewnoscia moge zaryzykowac stwierdzenie, ze chocbys stanal na glowie nie
>> jestes w stanie zrobic nic wydajniejszego niz wspolczesne silniki DB.
> Nie mogę, a jakimś dziwnym trafem kilka razy w swoim życiu zrobiłem. Kilka
> ostatnich programów które napisałem działają setki razy szybciej na plikach
> csv niż na bazach postgres i sqlite. Działają dlatego szybciej, że w jednym
> plik csv mam dokładnie to, co z bazy muszę wyciągać skomplikowanym zapytaniem.

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

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

>> Powiem wiecej, wydaje mi sie, ze trwonisz czas na nieistotnych rzeczach,
>> bazy danych dzialaja z setkami milionow rekordow, ze zlaczeniami i innymi
>> "utrudnieniami" i daja rade.
> Dają radę, tak jak mogą. Masz setki milionów rekordów. Wśród nich masz tysiąc
> rozrzuconych losowo przeznaczonych do wyciągnięcia. Jeśli rekordy nie są w
> cache, to:
> 1) jeśli nie są zaindeksowane - trzeba przejrzeć setki milionów, aby znaleźć
> ten tysiac;

Lub pozwolic serwerowi zrobic indeks.

> 2) jeśli są zaineksowane - w pesymistycznym przypadku trzeba naprowadzić
> tysiąc razy głowicę + jeszcze trochę naprowadzeń na odczyt indeksów.

Lub w sprzyjajacych warunkach (zalezy od rodzaju danych) odczytac dane
bezposrednio z indeksu (to tez "w locie i po cichu" potrafia dobre RDBMS).

> A gdy ten tysiąc rekordów leży w liniowym pliku, albo są w pamięci
> RAM, bo programista napisał specjalistyczny algorytm cache, to dane
> są w ułamku sekundy natychmiast.

Heh, myslisz, ze serwery SQL nie trzymaja ile sie da w ramie? To jeden z
fundamentow wydajnosci. Nawet cale bazy potrafia trzymac jak maja odpowiedni
sprzet (czyt. kupe ramu).

>> Na 90% zrobisz w swoim sofcie wiecej waskich gardel niz to, ktore
>> dostaniesz od serwera SQL.
> Nigdy nie twierdziłem że wyręczanie serwera SQL to łatwe zadanie i
> pierwsza wersja wyrzeźbiona ręcznie będzie na pewno szybsza. Każdy
> proces optymalizacji jest trudny i daje wiele możliwości na pogorszenie.

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.

>> Oczywiscie serwerowi tez
>> mozesz pomoc lub podlozyc noge projektujac dobra lub zla strukture tabel.
> No właśnie pytałem czy bazy danych oferują coś do układania potrzebnych
> danych obok siebie :)

Chodzilo mi tu o dobra, przemyslana strukture tabel i indeksow. Do
zarzadzania plikami serwer uzywa inzynierow swojego producenta ;-)

--
pozdro
R.e.m.e.K