On 2013-05-06, R.e.m.e.K <g...@d...null> wrote:
> 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?

XFS choćby.

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

Dlatego pliki baz danych nie przyrastają po jednym bajcie, tylko po
kilkaset mega i więcej. Albo alternatywnie baza wymaga ręcznego dodania
nowego miejsca (np. pliku) do składowania danych -- wtedy się dodaje
miejsce w ilości rzędu gigabajtów.

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

To już silnik bazodanowy powinien optymalizować.

Swoją drogą, zupełnie nie rozumiem po co rozważać ułożenie plików na
dysku w kontekście webaplikacji. To jak martwić się o kolejność
wykonania instrukcji maszynowych dla kodu napisanego w Prologu czy innym
Haskellu. Ani widać wpływ drugiego na pierwsze, ani da się go w ogóle
mierzyć...

--
Secunia non olet.
Stanislaw Klekot