W dniu 2013-05-07 09:23, firr kenobi pisze:
> W dniu wtorek, 7 maja 2013 01:48:09 UTC+2 użytkownik M.M. napisał:
>> W dniu poniedziałek, 6 maja 2013 23:28:02 UTC+2 użytkownik R.e.m.e.K napisał:
>>
>>
>>
>>> 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?
>>
>> Nie wiem jakie systemy plikow co maja zaimplementowane, ale istnieje
>>
>> algorytm bardzo odporny na fragmentacje. Poczatek pliku zaklada sie
>>
>> "w srodku" najwiekszej wolnej przestrzeni. Gwarantuje to duze prawdop.
>
> to bylby wlasnie chyba najszybszy
> sposob na zajechanie dysku, wrzucasz
> np na dysk 1 tys empetrójek i masz
> dysk pociety na 1000 kawalków

Ale jeżeli te pliki mają rosnąć, to do każdego z nich można coś dopisać
nie tworząc dodatkowych fragmentów, bo między każdymi dwoma jest wolne
miejsce...

do góry

W dniu wtorek, 7 maja 2013 11:56:14 UTC+2 użytkownik Piotr Chamera napisał:
> W dniu 2013-05-07 09:23, firr kenobi pisze:
>
> > W dniu wtorek, 7 maja 2013 01:48:09 UTC+2 u�ytkownik M.M. napisa�:
>
> >> W dniu poniedzia�ek, 6 maja 2013 23:28:02 UTC+2 u�ytkownik R.e.m.e.K
napisaďż˝:
>
> >>
>
> >>
>
> >>
>
> >>> 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?
>
> >>
>
> >> Nie wiem jakie systemy plikow co maja zaimplementowane, ale istnieje
>
> >>
>
> >> algorytm bardzo odporny na fragmentacje. Poczatek pliku zaklada sie
>
> >>
>
> >> "w srodku" najwiekszej wolnej przestrzeni. Gwarantuje to duze prawdop.
>
> >
>
> > to bylby wlasnie chyba najszybszy
>
> > sposob na zajechanie dysku, wrzucasz
>
> > np na dysk 1 tys empetr�jek i masz
>
> > dysk pociety na 1000 kawalk�w
>
>
>
> Ale je�eli te pliki maj� rosn��, to do ka�dego z nich mo�na co�
dopisaďż˝
>
> nie tworz�c dodatkowych fragment�w, bo mi�dzy ka�dymi dwoma jest wolne
> miejsce...

mysle ze te algorytmy ktore są robia to lepiej
- zresztą defragmentacja duzego pliku na dwa
czy trzy czesci chyba specjalnie nie boli,
o tyle chybas lepszym algorytmem bylby taki ktory
zapisuje wszystkieme male pliki w jednej czesci
dysku obok siebie, wieksze w innej czesci dysku
a najwieksze w jeszcze innej czesci dysku,
wtedy ta straszliwa polucja jaka wprowadzają male
pliki dotyczylaby tylko czesci dysku zwierajacej
male pliki, i zaqwsze bylyby lite obszary na
duze ciagle piki -- (poki jest troce miejsca na
dysku)

(z dyskami mam zle przygody bo pol roku temu
uszkodzilo mi sie "master file table" na 1T
dysku na usb i nie wiem jak naprawic to mft tak by moc odzyskac dane z zachowana
struktura katalogów :C sprawdzilem z 5 progsów i 4 znich
do niczego sie nie nadaja, wywalaja sie, dziala
tylko program "Recuva" ale on odzyskuje groch z kapustą (i to raczej z poczatku
dysku bo zawsze jedzie od poczatku :c )

do góry

On 2013-05-06 21:55, M.M. wrote:
> W dniu poniedziałek, 6 maja 2013 08:33:21 UTC+2 użytkownik R.e.m.e.K napisał:
>
>> 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.
>

I mozesz tez dane w tym pliku wydajnie przeszukiwac i - dajmy na to -
sortowac? Ale magia... Wniosek patentowy juz zlozyles?

--
Michal

do góry

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

do góry

W dniu wtorek, 7 maja 2013 15:02:05 UTC+2 użytkownik Michal Kleczek napisał:
> I mozesz tez dane w tym pliku wydajnie przeszukiwac i - dajmy na to -
> sortowac? Ale magia... Wniosek patentowy juz zlozyles?
Normalnie sortujesz, normalnie przeszukujesz... o co chodzi?
Pozdrawiam.

do góry

On 2013-05-07 18:06, M.M. wrote:
> W dniu wtorek, 7 maja 2013 15:02:05 UTC+2 użytkownik Michal Kleczek napisał:
>> I mozesz tez dane w tym pliku wydajnie przeszukiwac i - dajmy na to -
>> sortowac? Ale magia... Wniosek patentowy juz zlozyles?
> Normalnie sortujesz, normalnie przeszukujesz... o co chodzi?

Normalnie to moze i tak... Ale czy tak samo wydajnie jak RDBMS?

--
Michal

do góry

W dniu wtorek, 7 maja 2013 20:15:46 UTC+2 użytkownik Michal Kleczek napisał:

> Normalnie to moze i tak... Ale czy tak samo wydajnie jak RDBMS?

Zależy od konkretnego przypadku. Generalnie baza musi mieć algorytmy
uniwersalne. W konkretnym przypadku można uzyskać lepszą wydajność niż w
ogólnym - ale obarczone to jest nakładem pracy. W plikach
CSV (albo w binarnych) można trzymać częściowe wyniki już posortowane, więc
koszt sortowania na plikach CSV będzie równy zero.

W przypadku sortowania po dacie może to być bardzo łatwe, gdyż dane mogą
napływać do systemu z rosnącą datą.


Pozdrawiam

do góry

Użytkownik "M.M." <m...@g...com> napisał w wiadomości
news:e30f409d-0f8d-449c-93f2-9abf7383886f@googlegrou
ps.com...
W dniu wtorek, 7 maja 2013 20:15:46 UTC+2 użytkownik Michal Kleczek napisał:

>> Normalnie to moze i tak... Ale czy tak samo wydajnie jak RDBMS?

>Zależy od konkretnego przypadku. Generalnie baza musi mieć algorytmy
>uniwersalne. W konkretnym przypadku można uzyskać lepszą wydajność niż w
>ogólnym - ale obarczone to jest nakładem pracy. W plikach
>CSV (albo w binarnych) można trzymać częściowe wyniki już posortowane, więc
>koszt sortowania na plikach CSV będzie równy zero.

>W przypadku sortowania po dacie może to być bardzo łatwe, gdyż dane mogą
>napływać do systemu z rosnącą datą.

Ojkaciekrece, ostatecznie otwarles mi oczy.

do góry

W dniu poniedziałek, 6 maja 2013 09:25:39 UTC+2 użytkownik Tomek Kańka napisał:

> > Frameworki w takim PHP maja pelno bledow.
> Tak, w przeciwieństwie do home-made rozwiązań.
W starszej wersji Cake w każdej aplikacji zrobionej według
tutoriala czasami można było dodawać dane do niektórych
pól w tabeli, np. przy rejestracji można było sobie dodać
prawa moderatora. Ile aplikacji na joomli było blokowanych
przez przeglądarki jako "strony dokonujące ataków? Na
nową wersję joomli czy Cake ile czekali użytkownicy?
Pół roku, rok?


> Oraz stworzenia kodu, ktorego nikt poza nimi nie będzie już umiał
> poprawić.
Kazdy kod mozna napisac czytelnie albo przejrzyscie, niezaleznie czy
sie go pisze w domu czy w lesie.



> PS. Jak już ktoś napisał, zajmujesz się dziwnymi rzeczami, jak na
> web-developera, jakieś głowice/pliki i inne głupoty.
Mnie to jest zupelnie obojetne czy uzytkownik czeka 100 sekund na strone,
czy 1 sekunde. Tak samo mnie jest obojetnie czy odbiorca aplikacji bedzie
musial kupic 10 komputerow czy 1000. Chodzi o to, ze dla nich takie
rzeczy nie sa gupotami.


> Jak chcesz ten swój
> projekt zrobic szybko pisz w tym, co znasz najlepiej. Jak chcesz się
> nauczyć Javy/Pythona/what-ever i czas nie jest krytyczny pisz w
> Java/Pythonie/what-ever.
Wyglada na to, ze sie nie dowiem jak jak to jest w Javie czy Pythonie,
dopóki sam nie spróbuję.

Pozdrawiam

do góry

W dniu wtorek, 7 maja 2013 21:59:01 UTC+2 użytkownik Ghost napisał:

> Ojkaciekrece, ostatecznie otwarles mi oczy.
Co mam odpisać, gdy ktoś pyta, czy to bedzie wydajniej niz na bazie
danych?

Pozdrawiam

do góry