-
121. Data: 2013-05-08 21:29:26
Temat: Re: jsp vs php
Od: "R.e.m.e.K" <g...@d...null>
Dnia Wed, 8 May 2013 12:07:07 -0700 (PDT), M.M. napisał(a):
>>>> Nie. To po prostu zenujace.
>>>Nie ja zadawa�em oczywiste pytanie.
>> Ehhhh...
> Masz rację, lepiej na grupie pokłóćmy się o to do czego jest ajax, to
> nie jest żenujące ani oczywiste.
Ale wiesz, ze w DB mozesz sobie dane insertowac bez zadnej kolejnosci i
zadnych innych specjalnych warunkow a odczytasz w dowolnej, potrzebnej
kolejnosci?
A co jesli dane naplywaja bez tej wymaganej kolejnosci?
--
pozdro
R.e.m.e.K
-
122. Data: 2013-05-08 22:51:56
Temat: Re: jsp vs php
Od: "M.M." <m...@g...com>
W dniu środa, 8 maja 2013 21:29:26 UTC+2 użytkownik R.e.m.e.K napisał:
> Ale wiesz, ze w DB mozesz sobie dane insertowac bez zadnej kolejnosci i
> zadnych innych specjalnych warunkow a odczytasz w dowolnej, potrzebnej
> kolejnosci?
Tak, doskonale zdaje sobie z tego sprawe i nie mam ambicji napisania
"ogolnie lepszej" bazy danych. Umiem korzystac z baz danych w sposob
jaki najczesciej jest przydatny. Nie mam tylko doswiadczenia w "dziwnych
jak na web-developera" przypadkach :D
Zastanawiam sie jak to jest z intensywnie reklamowanymi serwisami. Leci
jakas reklama, potem wszyscy wlaczaja internet i probuja sie zalogowac.
Powiedzmy ze w ciagu 5 minut wejdzie na strone 1000 ludzi i kazdy sobie
jeszcze troche poklika - to pdobno niezbyt duzo. Zapytanie do bazy niech
trwa 2s. Z prostej arytmetyki wynika, ze laczny czas potrzebny na zapytania
wyniesie jakies 1-2 godzin - okolo 20 razy za wolno, a zapytani do bazy
moga trwac i 10 sekund.
Co sie robi w tak mocno obciazonych serwisach? Po prostu stawia sie baze
danych na klastrze 100 komputerow? Oczywiste jest, ze zrownoleglenie
niektorych operacji na bazie danych w ogle nie jest mozliwe. Do tego
wiele operacji nie skaluje sie liniowo. A jednak taki face-book dziala...
Nie wiem ile w tym prawdy, ale gdzies czytalem, ze face-book jest
uruchomiony na klastrze zlozonym z 30tys komputerow - wydaje mi sie, ze
jedno zero za duzo :)
> A co jesli dane naplywaja bez tej wymaganej kolejnosci?
Jesli dane moga naplywac w dowolnej kolejnosci; jesli rekordy maja wiele
pol o roznorodnych wartosciach; jesli dane czesto sa zmieniane, dodawane i
usuwane; jesli zapytania moga zawierac dowolne filtry, dowlne sortowanie i
dowolne grupowanie; to nie mozna zrobic nic szczegolnie lepszego niz
oferuje dobra baza danych. Scigac mozna sie z bazami tylko w konkretnych
przypadkach, np. gdy dane naplywaja w wiadomej kolejnosci, albo gdy
sortowanie bedzie tylko po dwoch polach.
Pozdrawiam
-
123. Data: 2013-05-08 23:29:02
Temat: Re: jsp vs php
Od: "R.e.m.e.K" <g...@d...null>
Dnia Wed, 8 May 2013 13:51:56 -0700 (PDT), M.M. napisał(a):
> Zastanawiam sie jak to jest z intensywnie reklamowanymi serwisami. Leci
> jakas reklama, potem wszyscy wlaczaja internet i probuja sie zalogowac.
> Powiedzmy ze w ciagu 5 minut wejdzie na strone 1000 ludzi i kazdy sobie
> jeszcze troche poklika - to pdobno niezbyt duzo. Zapytanie do bazy niech
> trwa 2s. Z prostej arytmetyki wynika, ze laczny czas potrzebny na zapytania
> wyniesie jakies 1-2 godzin - okolo 20 razy za wolno, a zapytani do bazy
> moga trwac i 10 sekund.
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. Po drugie jakie to zapytania sa?
Pokaz przyklad, bo jesli to zwykly select wyciagajacy kilka rekordow z
jednym czy dwoma joinami to nie powinien trwac 10 sekund w normalnych
warunkach.
Kilka lat temu zrobilem w PHP pewien serwis (powiedzmy, ze
paraspolecznosciowy). Strona dziala do dzis, nie jest mocno obciazona, ale
ma obecnie w najwiekszej tabeli prawie milion rekordow. Podczas generowania
jednej z podstron sa z niej odczytywane rekordy w liczbie od jednego do
kilkudziesieciu, zapytanie to ma tez jednego joina. Strona na jedno
odswiezenie wykonuje kilka zapytan i generuje caly kod w np. "0.0307 s" -
skopiowalem to teraz ze strony - bylo tam kilka zapytan SQL w tym jedno z
tej sporej tabeli. Baza MySQL. Hosting home.pl, wirtualka.
Pokaz zatem strukture tabel i zapytanie. A moze przenies te galaz watku na
grupe pl.comp.bazy-danych?
> Co sie robi w tak mocno obciazonych serwisach? Po prostu stawia sie baze
> danych na klastrze 100 komputerow? Oczywiste jest, ze zrownoleglenie
> niektorych operacji na bazie danych w ogle nie jest mozliwe.
Nie bylbym pewien czy niemozliwe, teoretycznie bym to potrafil sobie
wyobrazic. Ale nie mam takich doswiadczen, gdyz nie pracuje z duzymi bazami.
http://en.wikipedia.org/wiki/Oracle_RAC
http://en.wikipedia.org/wiki/Oracle_Clusterware
i...
http://en.wikipedia.org/wiki/Oracle_Cluster_File_Sys
tem
...przy okazji okazuje sie, ze sa specjalne systemy plikow dla baz - prawie
to co chciales :-) Ale obawiam sie, ze koszty takich rozwiazan zmusilyby Cie
do sprzedania calej rodziny na 3 pokolenia w przod ;-)
--
pozdro
R.e.m.e.K
-
124. Data: 2013-05-08 23:57:50
Temat: Re: jsp vs php
Od: Edek <e...@g...com>
Dnia Wed, 08 May 2013 13:51:56 -0700 po głębokim namyśle M.M. rzekł:
> Co sie robi w tak mocno obciazonych serwisach? Po prostu stawia sie baze
> danych na klastrze 100 komputerow? Oczywiste jest, ze zrownoleglenie
> niektorych operacji na bazie danych w ogle nie jest mozliwe. Do tego
> wiele operacji nie skaluje sie liniowo. A jednak taki face-book
> dziala... Nie wiem ile w tym prawdy, ale gdzies czytalem, ze face-book
> jest uruchomiony na klastrze zlozonym z 30tys komputerow - wydaje mi
> sie, ze jedno zero za duzo :)
Generalnie potrzebujesz szybką bazę. Jak z każdym skalowaniem,
można "w górę" i "w bok". Te pierwsze to duże szafy z szybkimi
macierzami dysków (raid, bbwc na start) i rozwiązania takie jak
IntentLog czy inne cache, osobno do odczytu (spory) i do zapisu
(non-volatile). Stosuje się chociażby ssd do tych celów,
albo zerknij na karty Fusion-IO.
Te "w bok", czyli mnóstwo kompputerów, to różne rozwiązania, gdzie
wiele dzieje się w RAM. Tak naprawdę przy odpowiedniej replikacji
dane w RAM są bezpieczne i jednocześnie błyskawicznie dostępne.
No a temat replikacji to osobna dziedzina.
--
Edek
-
125. Data: 2013-05-09 02:10:02
Temat: Re: jsp vs php
Od: "M.M." <m...@g...com>
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.
Na klucze obce w duzych tabelach sa zalozone indeksy. Indeks hash byl
minimalnie szybszy od b-tree. Indeksy na malych tabelach nic nie daly.
Na klucze glowne postges zalozy sam indeksy.
Nie wiem co jest jeszcze wazne... Moze to, ze wraz z rozrostem bazy,
nie bedzie zwiekszala sie ilosc rekordow zwracanych przez te
czasochlonne zapytania. Raczej z rozrostem bedzie rosla ilosc zapytan
jakie mozna zadac, a otrzyma sie podobna ilosc danych.
> Pokaz przyklad, bo jesli to zwykly select wyciagajacy kilka rekordow z
> jednym czy dwoma joinami to nie powinien trwac 10 sekund w normalnych
> warunkach.
Nam nadzieje ze powyzszy opis wystarczy :)
> Kilka lat temu zrobilem w PHP pewien serwis (powiedzmy, ze
> paraspolecznosciowy). Strona dziala do dzis, nie jest mocno obciazona, ale
> ma obecnie w najwiekszej tabeli prawie milion rekordow. Podczas generowania
> jednej z podstron sa z niej odczytywane rekordy w liczbie od jednego do
> kilkudziesieciu, zapytanie to ma tez jednego joina. Strona na jedno
> odswiezenie wykonuje kilka zapytan i generuje caly kod w np. "0.0307 s" -
> skopiowalem to teraz ze strony - bylo tam kilka zapytan SQL w tym jedno z
> tej sporej tabeli. Baza MySQL. Hosting home.pl, wirtualka.
Tez robilem podobne rzeczy w oparciu o bazy danych, sam nie wiem ile tego
bylo. Moze z 50 serwisow w PHP i drugie tyle programow/programikow w C++.
W niektorych tabele sa znacznie wieksze niz 1mln rekordow. Nie pamietam
ile czasu trwaja zapytania. Moze w tej chwili nie pamietam jakiegos
upierdliwego przypadku, ale raczej nigdy operacje dyskowe nie byly
waznym problemem. Tez nigdy nie zrobilem strony www dla ktorej "10 tys
uzytkownikow to nic".
> Nie bylbym pewien czy niemozliwe, teoretycznie bym to potrafil sobie
> wyobrazic. Ale nie mam takich doswiadczen, gdyz nie pracuje z duzymi bazami.
Pewnie sie skonczy tak, ze gdzies wykupie jakas chmure do testow,
zainstaluje baze i pomierze czasy. Tez nie wiem jakie operacje bazodanowe w
jakim stopniu sie zrownoleglaja. Szukac w necie i czytac az sie boje,
trduno odroznic co jest przechwalkami producentow, a co rzetelnym testem.
> http://en.wikipedia.org/wiki/Oracle_RAC
> http://en.wikipedia.org/wiki/Oracle_Clusterware
> http://en.wikipedia.org/wiki/Oracle_Cluster_File_Sys
tem
Dzieki, popatrze, ciekawe ile kosztuja Oracle na klaster :)
> ...przy okazji okazuje sie, ze sa specjalne systemy plikow dla baz - prawie
> to co chciales :-)
Czasami docieraly do mnie takie doniesienia jak specjalny system plikow pod
baze danych, albo pod wyszukiwarke internetowa... pierwszy raz bede musial
sprawdzic to na wlasnej skorze :)
> Ale obawiam sie, ze koszty takich rozwiazan zmusilyby Cie
> do sprzedania calej rodziny na 3 pokolenia w przod ;-)
Ostatnio prawie stracilem przytomnosc, jak dowiedzialem sie, ze koszt
jednej, w sumie niezbyt duzej, reklamy, to okolo 800tys pln :) Niesadze
zeby serwis w ogle mogl zarobic az na taka reklame. Niemniej koszty
sprzetu i oprogramowania moga okazac sie relatywnie niskie.
Pozdrawiam
-
126. Data: 2013-05-09 02:32:52
Temat: Re: jsp vs php
Od: "M.M." <m...@g...com>
W dniu środa, 8 maja 2013 23:57:50 UTC+2 użytkownik Edek napisał:
> Generalnie potrzebujesz szybką bazę. Jak z każdym skalowaniem,
> można "w górę" i "w bok".
Jak wyglada skalowanie baz w bok? Mamy duzo komputerow. Komputery niech
sa sredniej jakosci, moze tylko niech maja dobre karty sieciowe i kable.
Nie ma zadnego super-komputera, zadnych urzadzen dedykowanych, tylko
dostawiamy kolejna skrzynke i podpianmy do sieci. Na tym pracuje jakas
baza sql, moze byc nawet jakas droga. Powiedzmy ze bylo tych skrzynek 10, a
po dostawieniu jest sto skrzynek. Ktore operacje dzialaja:
1) wolniej,
2) bez zmian,
3) minimalnie szybciej
4) szybciej prawie liniowo.
> Te pierwsze to duże szafy z szybkimi
> macierzami dysków (raid, bbwc na start) i rozwiązania takie jak
> IntentLog czy inne cache, osobno do odczytu (spory) i do zapisu
> (non-volatile). Stosuje się chociażby ssd do tych celów,
> albo zerknij na karty Fusion-IO.
Hmmm dyski SSD pewnie beda w zasiegu budzetu. Zastanawiam sie tylko
co jest lepsze:
1) skalowanie w bok na zwyklych maszynkach
2) skalowanie w bok na maszynach z dyskami SSD
3) optymalizacja algorytmow i struktur danych
Kazde z tych rozwian jest zwiazane z jakimis kosztami i niesie jakies
korzysci.
> Te "w bok", czyli mnóstwo kompputerów, to różne rozwiązania, gdzie
> wiele dzieje się w RAM.
Przecietny tani komp moze miec chyba 32GB ram. Kilka TB to 100 komputerow -
moze by starczylo. Jeden dobry dysk SSD kosztuje tyle co 15 komputerow -
moze to jest bardziej sensowna droga niz by sie wydawalo.
> Tak naprawdę przy odpowiedniej replikacji
> dane w RAM są bezpieczne i jednocześnie błyskawicznie dostępne.
No tak.
> No a temat replikacji to osobna dziedzina.
Jakze rozna od zapisywania danych na dysku :D
Pozdrawiam
-
127. Data: 2013-05-09 08:44:15
Temat: Re: jsp vs php
Od: Tomasz Sowa <t...@N...ttmath.org>
On 2013.05.09 02:10, M.M. wrote:
> 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?
0.1 sekundy także cię nie ratuje bo pierwszy lepszy gimnazjalista
zajedzie ci serwis dosem.
Jeśli to nie są jakieś wysoko krytyczne dane które przy każdym zapytaniu
muszą być przeliczane od nowa to ja bym zrobił warstwę pośrednią (tak
jak pisałeś w postaci tych plików csv/xml albo dodatkową tabelę w bazie
trzymająca to co już się wyprodukowało z tych joinów). A w tle jakiś
demon który co pewien interwał czasu aktualizuje.
--
Tomek
-
128. Data: 2013-05-09 08:58:57
Temat: Re: jsp vs php
Od: Tomek Kańka <t...@t...eu.org>
M.M. <m...@g...com> napisał(a)
>
> Zapytanie nie ma sortowania, ani grupowania. Wynikiem zapytania jest
> srednio 70tys rekordow.
>
I naprawdę potrzebujesz zaprezentować 70 tys. informacji na stronie?
--
Tomek
-
129. Data: 2013-05-09 09:01:55
Temat: Re: jsp vs php
Od: "Ghost" <g...@e...pl>
Użytkownik "Tomek Kańka" <t...@t...eu.org> napisał w wiadomości
news:slrnkomi9h.ha6.tom@tv2.dom.local...
> M.M. <m...@g...com> napisał(a)
>>
>> Zapytanie nie ma sortowania, ani grupowania. Wynikiem zapytania jest
>> srednio 70tys rekordow.
>>
>
> I naprawdę potrzebujesz zaprezentować 70 tys. informacji na stronie?
Ja mysle, ze gdyby M&Ms podal informacje o jaki projekt chodzi dopiero
byloby rozrywkowo.
-
130. Data: 2013-05-09 09:04:09
Temat: Re: jsp vs php
Od: "M.M." <m...@g...com>
W dniu czwartek, 9 maja 2013 08:44:15 UTC+2 użytkownik Tomasz Sowa napisał:
> Je�li to nie s� jakie� wysoko krytyczne dane kt�re przy ka�dym
> zapytaniu
> musz� by� przeliczane od nowa to ja bym zrobi� warstw� po�redni� (tak
> jak pisa�e� w postaci tych plik�w csv/xml albo dodatkow� tabel� w bazie
> trzymaj�ca to co ju� si� wyprodukowa�o z tych join�w). A w tle jaki�
> demon kt�ry co pewien interwa� czasu aktualizuje.
Wyglada na to, ze kilka osob widzi sens w takim rozwiazaniu, nie tylko ja
sam. Wiec moze PHP, JSP, albo inne ASP oferuje jakis zestaw oprogramowania i
bibliotek do takich rozwiazan? Czy trzeba wszystko samemu wyrzezbic?
Pozdrawiam