🚀 go-pugleaf

W dniu wtorek, 7 maja 2013 09:21:55 UTC+2 użytkownik R.e.m.e.K napisał:

> 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.
Ok, jak nie ma to nie ma. Chociaz... troche nie ufam, poszukam jeszcze :)


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


> 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.
Brzmi logicznie, ale nie ma cudow. Jesli tabela jest ogromna, to w
pesymistycznym przypadku DB musi nastawic glowice tyle razy ile jest
rekordow do odczytania.


> Ale jesli nie bedzie read-only to stopien komplikacji wlasnego rozwiazania
> rosnie ogromnie. 
To zalezy od szczegolow problemu. Ostatnio duzo sie bawilem rozwiazaniami
opartymi na SQL i CSV. Az tak bardzo trudno nie jest. Wieksze problemy
mialem gdy byly nieoczekiwane zmiany w projekcie.


> Do tego mozna takze uzyc serwera SQL. Raz na dobe zrobic nim widok i go
> zmaterializowac (materialized view). Efekt bedzie podobny, a roboty ZERO.
Zgadza sie. Przy okazji zyskuje sie transakcje, prosta mozliwosc zrobienia
kopii - niby sa zalety. Ale dane w takich plikach sa nadmiarowe, zawsze
mozna je odtworzyc - czyli transakcji nie potrzebuje. W kopii zapasowej
takie dane tez jak kula u nogi. Po plikach bazy danych trudno iterowac...
Masz racje ze mozna, ale w takim przypadku baza to niepotrzebna warstwa.
Lepiej takie dane zrzucic do pliku binarnego, potem w golym C po takim
pliku iterowac. Struktury z C mapuja sie bez zadnych konwersji do danych w
pliku binarnym - wydajnosc i wygoda w jednym.


> E, czemu tylko jedna kolumne? Indeks moze obejmowac kilka kolumn. 
Hmmm, ale i tak to chyba nie ma nic wspólnego z jakąś metodą na 
układanie potrzebnych danych obok siebie.


> Wiedziec a to zrobic to przepasc liczona w setkach roboczogodzin ;-) 
Samo sie nie zrobi, pytanie czy warto :)


> No i dochodzimy do meritum. Jesli zapytania wykonuja sie po kilkadziesiat
> sekund to (zaznacz wlasciwe pola):
> - masz spieprzona strukture logiczna bazy
O tej samej bazie mozna powiedziec ze jest optymala i spieprzona. Moja jest
optymalizowana na elastycznosc, na to zeby latwo mozna bylo cos zmienic,
cos dodac. Mozna zrobic tak jak wyzej proponowales, ze tabel sa odpowiednikami
plikow na ktorych to dziala szybciej. Tyle ze wtedy taka baza wydaje sie jak
kula u nogi.

> - nie korzystasz prawidlowo z indeksow
Raczej tak.


> - piszesz zle zapytania SQL
Nie popelniam wielkich bledow, ale nie sprawdzalem jeszcze czy szybciej
zadziala zlaczenie join, czy moze jakies sprytne podzapytanie.


> - uzywasz produktu serweropodobnego
Ostatnio uzywam dwoch: SQLite i Postresql


> - wyciagasz w wyniku miliony rekordow wraz z polami typu blob i podsystem
> dyskowy nie wyrabia
Blob nie uzywam. Ilosc rekordow rozna, rzadko powyzej 100tys, ale zdarza sie.

> Ale wlasnie, czy aby na pewno sa one przemyslane? Czy struktura jest 
> znormalizowana? A jesli tak to moze zbyt znormalizowana? 
Jak na wydajnosc to jest zbyt znormalizowana, jak na zarzadzanie, to jest
znormalizowana w sam raz - jesli mozna tak powiedziec :) 

> 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.
Z tego co widze, to mozna w ten sposob duzo poprawic. Pytanie tylko, czy
robienie tabel z redundantnymi danymi nie jest gorze niz zewnetrzne pliki.

Pozdrawiam