W dniu poniedziałek, 6 maja 2013 08:33:21 UTC+2 użytkownik R.e.m.e.K napisał:

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


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


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


> 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.
Myślałem że może są jakieś zaawansowane optymalizatory.


> 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ć?


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

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.

No ale ja nie znam perfekcyjnie wszystkich możliwości jakie oferują bazy...
może na bazach też da się uzyskać taki efekt... może coś robię źle...
Nie wiem, ja raczej pytałem w tym poście o radę.


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

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.

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


> 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 :)


Pozdrawiam