W dniu czwartek, 9 maja 2013 08:58:57 UTC+2 użytkownik Tomek Kańka napisał:

> I naprawdę potrzebujesz zaprezentować 70 tys. informacji na stronie?
Niekoniecznie, ale takie rozwiazanie moze byc lepsze niz inne.

Po pierwsze 70tys to dosc malo danych na przeslanie, gzip moze to spakuje do
70kb. Po drugie przewiduje ze jakbym to rozbil na male kawalki, to uzytkownik i
tak odpyta o wszystkie. Po trzecie skrypt w PHP moze czasami szybciej
wykonac na tych danych jakis algorytm niz SQL i cos odfiltrowac. Po czwarte
gdy przegladarka otrzyma cale 70 tys to uzytkownik ma komfort, bo po
kolejnych kliknieciach strona laduje sie zero sekund. Po piate, zapytania
moga miec wielokrotnie zalozona funkcje max na malych wynikach podzapytan -
wiec zmniejszenie danych do 7 tys nie przyspieszy zapytania - ale to jest
zwiazane z trzecim powodem.

Pozdrawiam

do góry

Dnia Thu, 9 May 2013 06:58:57 +0000 (UTC), Tomek Kańka napisał(a):

>> Zapytanie nie ma sortowania, ani grupowania. Wynikiem zapytania jest
>> srednio 70tys rekordow.
>>
>
> I naprawdę potrzebujesz zaprezentować 70 tys. informacji na stronie?

To bylo moje kolejne pytanie. Wyciaganie na kazdym "kliku" 70 tys rekordow
smierdzi na kilometr.

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

do góry

W dniu czwartek, 9 maja 2013 02:10:02 UTC+2 użytkownik M.M. napisał:
> W dniu środa, 8 maja 2013 23:29:02 UTC+2 użytkownik R.e.m.e.K napisał:
>
>
>
> > Ciagle nie wiem skad bierzesz te 10 sekund. Po piewsze to zalezy od
>
> > komputera, jesli na Twoim lapku trwa to 10 sekund to na serwerze z
>
> > prawdziwego zdarzenia moze trwac 0,1 s.
>
>
>
> Sprawdzam na lapku i na stacjonarnym, oba kompy sa dosc nowe, ale
>
> na pewno nie sa to serwery z prawdziwego zdarzenia. Czasami na lapku
>
> dziala szybciej. Domniemam ze wynika to z ulozenia danych w tabelach.
>
> Jesli na lapku dane sa obok siebie, to zapytanie bedzie dzialalo
>
> szybciej niz nawet na serwerze z prawdziwego zdarzenia - zaraz ktos mi
>
> zarzuci ze pisze oczywiste rzeczy :D
>
>
>
> Czy da sie z 10s zejsc do 0.1s tylko dzieki:
>
> 1) lepszej konfiguracji (np. indeksy, buforowanie w RAM)
>
> 2) zastosowaniu lepszego sprzetu
>
> 3) zastosowaniu wiekszej ilosci komputerow?
>
>
>
> AD1) powiedzmy ze indeksy juz mam dobre, a buforow RAM nie bede zwiekszal,
>
> bo w koncu i tak i tak zabraknie.
>
> AD2) nie mam pod reka dyskow SSD zeby sprawdzic.
>
> AD3) nie wiem jak sie zachowuje postgres uruchomiony na klastrze,
>
> zdaje sie ze jest taka mozliwosc, ale nigdy nie korzystalem z niej.
>
>
>
> > Po drugie jakie to zapytania sa?
>
>
>
> W pierszym lepszym zapytaniu slowo JOIN mam 11 razy. Docelowe
>
> rozmiary czterech najwieksych tabel z tego zapytania szacuje
>
> mniej/wiecej tak: 1mln, 10mln, 100mln i 1mld rekordow. Obecne
>
> rozmiary 135543, 135543, 12578310, 20573317. Pozostale tabele sa raczej
>
> male, do 50tys rekordow, raczej zmieszcza sie w boforze RAM.
>
> Kazda duza tabela jest laczona joinem tylko jeden raz. Jedna
>
> mala table wystepuje w zapytaniu dwa razy - ale to bez znaczenia.
>
>
>
> W tym zapytaniu wszystkie zlaczenia sa po klucz_glowy==klucz_obcy.
>
> Wszystkie klucze to biginty. W klazuli where jest:
>
> tabel1.klucz_glowy = stala_1 AND tabela2.klucz_glowny = stala_2;
>
>
>
> Zapytanie nie ma sortowania, ani grupowania. Wynikiem zapytania jest
>
> srednio 70tys rekordow.
>
>

dla mnie jest to ciekawy watek, aczkolwiek
nie znam sie na tym bo w praktyce nie zajmuje
sie nie tylko bazami danych ale nawet
nie bardzo pilkami (w temacie gier to ew
straczy mi wiedza jak zbudowac plik .pak
aby wczytanie danych bylo jak najszybsze)

w kazdym razie mi wyglada to na problem
z podsystemem cache miedzy bazą a programem
(nie wiem na ile bazy taki cache obsluguja
ale pewnie chyba obslugują, zapewne mozna
scacheowac sobie wynik zapytania automatycznie
(do ramu albo na dysk) zamiast samemu

pozatym mozna przemyslec jak wyglada przeplyw
tych danych miedzy wielka bazą a programem
(ile funkcjonuje rozmaitych wynikow zapytan i
ile razy powtarza sie ktory z nich) idealna sytuacja
gdy funkcjonuje malo i powtarzaja sie czesto
i tak wykombinowac podsystem cache by wysoki
procent tych zapytan trafial w cache

da sie cos takiego zrobic w twoim wypadku?

do góry

W dniu czwartek, 9 maja 2013 09:28:10 UTC+2 użytkownik R.e.m.e.K napisał:

> To bylo moje kolejne pytanie. Wyciaganie na kazdym "kliku" 70 tys rekordow
> smierdzi na kilometr.

Dlaczego smierdzi? To nie jest typowa aplikacja, gdzie sie na strone
laduja trzy artykuly i dwa komentarze.

Ile trzeba danych zeby odrysowac w miare gladki wykres? 500 punktow?
A jak wykresow jest kilka? A jak uzytkownik ma suwak do przewijania
wykresow, albo moze skalowac wykresy? Przesuwa suwakiem i czeka 5s
na odpowiedz systemu?

Lepiej jest podac wszystkie dane do skryptu w JS i w przegladarce
zbudowac wszystko, niz ajaxem dobierac po kawaleczkach. Jedna duza
porcja mniej obciaza niz 10 malych.

Do tego bazy danych slabo optymalizuja wybieranie maxa z malej ilosci
rekordow. Te 70tys mozna zmniejszyc, ale w zapytaniu pojawi sie
funkcja max. Przypuszczam ze czas zapytania z funkcja max wzrosnie.

Pozdrawiam

do góry

W dniu czwartek, 9 maja 2013 09:56:01 UTC+2 użytkownik firr kenobi napisał:
> dla mnie jest to ciekawy watek, aczkolwiek
> nie znam sie na tym bo w praktyce nie zajmuje
> sie nie tylko bazami danych ale nawet
> nie bardzo pilkami (w temacie gier to ew
> straczy mi wiedza jak zbudowac plik .pak
> aby wczytanie danych bylo jak najszybsze)
Tez bede po jakims czasie wiedzial jakie jest
zadowalajace rozwiazanie. Ale przed analiza chcialem
sie dowiedziec jak inni doswiadczeni w takim
boju sobie radzili, jakie mieli problemy,
jaich narzedzi uzywali, jakich jezykow, jakiego
sprzetu.


> w kazdym razie mi wyglada to na problem
> z podsystemem cache miedzy bazą a programem
> (nie wiem na ile bazy taki cache obsluguja
> ale pewnie chyba obslugują, zapewne mozna
> scacheowac sobie wynik zapytania automatycznie
> (do ramu albo na dysk) zamiast samemu
Mozna, tylko czuje mase roboty, a w poczatkowym
etapie bardzo malo czasu/ludzi do pomocy.


> pozatym mozna przemyslec jak wyglada przeplyw
> tych danych miedzy wielka bazą a programem
> (ile funkcjonuje rozmaitych wynikow zapytan i
> ile razy powtarza sie ktory z nich) idealna sytuacja
> gdy funkcjonuje malo i powtarzaja sie czesto
> i tak wykombinowac podsystem cache by wysoki
> procent tych zapytan trafial w cache
> da sie cos takiego zrobic w twoim wypadku?
Pewnie jakos tak to bedzie robione.


Pozdrawiam

do góry

W dniu czwartek, 9 maja 2013 09:01:55 UTC+2 użytkownik Ghost napisał:
> Ja mysle, ze gdyby M&Ms podal informacje o jaki projekt chodzi dopiero
> byloby rozrywkowo.
http://ghost.net/

do góry

On 2013-05-09, M.M. <m...@g...com> wrote:
> W dniu czwartek, 9 maja 2013 09:28:10 UTC+2 użytkownik R.e.m.e.K napisał:
>
>> To bylo moje kolejne pytanie. Wyciaganie na kazdym "kliku" 70 tys rekordow
>> smierdzi na kilometr.
>
> Dlaczego smierdzi? To nie jest typowa aplikacja, gdzie sie na strone
> laduja trzy artykuly i dwa komentarze.
>
> Ile trzeba danych zeby odrysowac w miare gladki wykres? 500 punktow?

Eeee... Dane do wykresu? Gładki wykres? Czyli wyświetlanie danych
badawczych? Jesteś pewny, że baza relacyjna to w ogóle był dobry wybór?
Bo wiesz, to nie jest jedyny paradygmat przetwarzania danych.

--
Secunia non olet.
Stanislaw Klekot

do góry

Użytkownik "M.M." <m...@g...com> napisał w wiadomości
news:39d4356e-3f38-43eb-955a-1bce451f7bdd@googlegrou
ps.com...
W dniu czwartek, 9 maja 2013 09:01:55 UTC+2 użytkownik Ghost napisał:
>> Ja mysle, ze gdyby M&Ms podal informacje o jaki projekt chodzi dopiero
>> byloby rozrywkowo.
>http://ghost.net/

Pakuj sie do miski.

do góry

Dnia Thu, 9 May 2013 00:56:24 -0700 (PDT), M.M. napisał(a):

> Ile trzeba danych zeby odrysowac w miare gladki wykres? 500 punktow?
> A jak wykresow jest kilka? A jak uzytkownik ma suwak do przewijania
> wykresow, albo moze skalowac wykresy? Przesuwa suwakiem i czeka 5s
> na odpowiedz systemu?

Google Analytics cos takiego robi, moze da sie podejrzec choc strone
klienta.

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

do góry

W dniu czwartek, 9 maja 2013 10:21:52 UTC+2 użytkownik Stachu 'Dozzie' K. napisał:

> Eeee... Dane do wykresu? G�adki wykres? Czyli wy�wietlanie danych
> badawczych? Jeste� pewny, �e baza relacyjna to w og�le by� dobry wyb�r?
> Bo wiesz, to nie jest jedyny paradygmat przetwarzania danych.

Niewielu rzeczy jestem pewny, a juz w ogole niewielu na tym etapie.

Dyskusja ciagle brnie w jakis szczegol, to w ajax, to w przykladowe
zapytanie SQL, a ja jakos nie potrafie temu zapobiegac. Na szczegoly
za szybko, zmienia sie one jeszcze kilka razy.

Na razie musze sobie wyrobic ogolny poglad na temat wytwarzania
aplikacji webowych ktore sa mocno obciazone. Przydaja mi sie
informacje o skalowalnosci baz danych, dostepnosci bibliotek
dla roznych jezykow, mozliwosci zatrudnienia ludzi, itd.

Idealna bylaby relacja kogos kto pracowal przy czyms takim. Chetnie
bym sie dowiedzial ze gdzies uzywali jakis narzedzi, mieli jakies
problemy, przesiedli sie na inne narzedzia, problem rozwiazali, ale
bylo to obarczone jakims kosztem, a moze pojawily sie inne problemy.

Ciekawy jestem np. czy jakas wieksza aplikacje przepisano z PHP na JSP, a
jesli tak, to dlaczego i czy to w czyms pomoglo. Albo czy w jakiejs
firmie zwolniono ludzi od PHP a w ich miejsce zatrudniono ludzi od Javy i
co to cos dalo.

Pozdrawiam

do góry