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

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

Bazy danych sa srubowane pod wzgledem wydajnosci, bo to jeden z priorytetow.
Mechanizmow temu sprzyjajacych maja wiele, w koncu to temat stary jak cale
IT, ale nie sadze by byla mozliwosc grzebania w tak niskopoziomowych
parametrach jak polozenie stron w sektorach dysku.

> Wystarczy ze plik nie jest w ogromnej ilosci malych kawaleczkow.
> Gwarancja nie jest potrzebna, wystarczy ze prawdopodobienstwo
> fragmentacji jest znikome.

Ale jesli plik baza bedzie mial kilkadziesiat GB, to podejrzewam, ze nawet
najlepszy system plikow nie zagwarantuje, ze znajdzie taki obszar w jednym
kawalku.

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

Optymalizator jest wbudowany w engine serwera i sie korzysta z niego
wykonujac zapytania. Mozna wplynac na jego decyzje wymuszajac mu plan
zapytania, ale w dobrych serwerach wiecej takim wymuszeniem mozna zaszkodzic
niz pomoc, w gorszych (ze slabym optymalizatorem) mozna poprawic wiele.

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

Ale jesli nie bedzie read-only to stopien komplikacji wlasnego rozwiazania
rosnie ogromnie.

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

Do tego mozna takze uzyc serwera SQL. Raz na dobe zrobic nim widok i go
zmaterializowac (materialized view). Efekt bedzie podobny, a roboty ZERO.

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

E, czemu tylko jedna kolumne? Indeks moze obejmowac kilka kolumn.

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

Wiedziec a to zrobic to przepasc liczona w setkach roboczogodzin ;-)

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

No i dochodzimy do meritum. Jesli zapytania wykonuja sie po kilkadziesiat
sekund to (zaznacz wlasciwe pola):
- masz spieprzona strukture logiczna bazy
- nie korzystasz prawidlowo z indeksow
- piszesz zle zapytania SQL
- uzywasz produktu serweropodobnego
- wyciagasz w wyniku miliony rekordow wraz z polami typu blob i podsystem
dyskowy nie wyrabia

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

Ale wlasnie, czy aby na pewno sa one przemyslane? Czy struktura jest
znormalizowana? A jesli tak to moze zbyt znormalizowana? W praktyce dla
zwiekszenia wydajnosci stosuje sie czesto denormalizacje oraz celowa
redundancje danych. Mysle, ze struktura bazy danych moze byc tu kluczowa dla
wydajnosci, mozna nia bardzo duzo poprawic oraz ...zepsuc.

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