Użytkownik "M.M." <m...@g...com> napisał w wiadomości
news:e80da607-ce5c-4d19-bbea-1a287d6f11ab@googlegrou
ps.com...
W dniu czwartek, 9 maja 2013 10:21:52 UTC+2 użytkownik Stachu 'Dozzie' K.
napisał:

>Idealna bylaby relacja kogos kto pracowal przy czyms takim.

Takim czyli jakim? Poki co widac tylko jakies strzepy tajemnicy.

do góry

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

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

Masz czas 13-14 maja oraz wolne 1,5 tys pln? ;-)

http://niebezpiecznik.pl/post/poznan-atmosphere-2013
/

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

do góry

W dniu czwartek, 9 maja 2013 13:57:19 UTC+2 użytkownik R.e.m.e.K napisał:
> Masz czas 13-14 maja oraz wolne 1,5 tys pln? ;-)
> http://niebezpiecznik.pl/post/poznan-atmosphere-2013
/

Jesli wyklad bedzie taki:
[
Moim zdaniem każdy może oprzeć stronę o mysql i css.
Wszelkie operacje, które można wykonać w mysql przenosić właśnie na mysql.
Odciąża to znacząco prace serwera www.
Dodatkowo jeśli chodzi o ciężar witryny to zamiast opierać stronę o obrazki .png
.jpg. .gif itd to tworzyć wszystkie możliwe elementy w css. Jest to bardzo optymalne,
odciąża serwer i wszystko stworzone w css nie traci jakości wraz ze skalowaniem
wielkości witryny.
]
to juz umiem :)

Ale moze dla rozrywki zajrze :)

Pozdrawiam

do góry

W dniu czwartek, 9 maja 2013 14:21:19 UTC+2 użytkownik M.M. napisał:
> to juz umiem :)
> Ale moze dla rozrywki zajrze :)
Musze odszczekac powyzsze, tam jednak jest duzo ciekawych zagadnien :)
Chyba warto sie stawic :)
Pozdrawiam

do góry

Dnia Thu, 9 May 2013 05:37:58 -0700 (PDT), M.M. napisał(a):

>> to juz umiem :)
>> Ale moze dla rozrywki zajrze :)
> Musze odszczekac powyzsze, tam jednak jest duzo ciekawych zagadnien :)
> Chyba warto sie stawic :)

Ufff, bo juz sie zaczalem o Ciebie martwic ;-)

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

do góry

Dnia Wed, 08 May 2013 17:32:52 -0700 po głębokim namyśle M.M. rzekł:

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

3 i pół. Plus problemy typu kto rodziela ruch - są dedykowane
rozwiązania failover.

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

Można podejść bardzo różnie, ale przede wszystkim policzyć. A żeby
policzyć trzeba mieć doświadczenie albo fake it till you make it
czyli zacząć od google.

Np. nie wiem czy NAS: ZFS + na SSD: ZIL + duży L2ARC nie załatwiłby
jedną maszyną storydżu bazy danych. Stawia się to na dowolnym sprzęcie
z dyskami SATA, jednym/dwa ssd i ma się tyle co niezły raid -
10Gb przepustowości co najmniej i opóźnienia niewiele większe
niż latency sieci. To znaczy przy dużym ruchu potrzeba tylko
ile wlezie RAMu i szybki proc. Ale to też zależy od bazy i rodzaju
dostępów i jasne, jest jakiś limit, a widzę plany masz typu sky is
the limit.

Ja specjalnie mówię o rzeczach dostępnych za free (poza sprzętem).

To byłoby skalowaniem w górę. Optymalizacja algorytmów owszem,
ale ona nigdy nie jest oderwana od sprzętu. Chyba że jak google
zakłada się sprzęt taki jak z półki w sklepie.

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

Może poćwicz na amazonie, na pewno są gotowe rozwiązania nawet
jak nie ma benchmarków.

>> No a temat replikacji to osobna dziedzina.
> Jakze rozna od zapisywania danych na dysku :D

Heh. Mieliśmy takie maszynki co obsługiwały dziesiątki milionów
transakcji na godzinę i mieliśmy: ekspertów od dysków, ekspertów
od połączeń do dysków, ekspertów od bazy, a eksperci od replikacji
to siedzieli od tamtych dość daleko... No ale tu to musiałbyś
się zapożyczyć żeby kupić jeden kabelek ;)

--
Edek

do góry

Dnia Wed, 08 May 2013 17:32:52 -0700 po głębokim namyśle M.M. rzekł:

>> No a temat replikacji to osobna dziedzina.
> Jakze rozna od zapisywania danych na dysku :D

Nie wiem czy to było oczywiste: nie replikacji bazy,
tylko replikacji pomiędzy nodami klastra, takiej online.

--
Edek

do góry

W dniu 2013-05-09 02:10, M.M. pisze:
> 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.

tymi sposobami nie osiągniesz dwóch rzędów przyspieszenia.
a przy przyroście danych możesz się spodziewać kwadratowego przyrostu czasu.
> AD3) nie wiem jak sie zachowuje postgres uruchomiony na klastrze,
> zdaje sie ze jest taka mozliwosc, ale nigdy nie korzystalem z niej.
>

Bazy SQL średnio się zrównoleglają, aby spełnic ACID ma zwoje wymagania.

Masz dwie możliwości.
1. Zmienić architekturę rozwiązania. Zamiast za każdym razem pytać bazę
buforować tabele z danymi pośrednimi, łatwiej kupić dodatkowy dysk niż
zwiększyć moc obliczeniową
2.Drastycznie zmienić podejście : MapReduce , noSQL itp

Dzięki rozluźnieniu reguł ACID można efektywnie podejść do
zrównoleglenia, tym bardziej że 10 zwykłych komputerów jest tańszych niż
jeden dwa razy szybszy.



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

Popatrz na Google, ma miliony razy większą bazę, miliony razy więcej
zapytać a odpowiada w czasie krótszym od 0.1 s


--
Darek

do góry

On 2013-05-08 18:09, M.M. wrote:
> W dniu środa, 8 maja 2013 11:04:07 UTC+2 użytkownik Michal Kleczek napisał:
>> W RDBMS to siďż˝ nazywa "clustered index". Jakies inne pomysly?
> Czyli jednak można ingerować w fizyczne ułożenie danych w tabelach.

A co to znaczy "fizyczne"? Który talerz/sciezka/glowica, czy co tam
jeszcze w tych dyskach siedzi? A jesli jest RAID? A jesli jest SSD?

Poczytaj o poziomach abstrakcji.

> Niby dobrze, ale właśnie...
>> Tylko po dacie?
> tylko po jednym polu. Pliki csv czy xml mozna zrobic np. w trzech wersjach:
> po dacie, po nazwie uzytkownika i po nazwie leku.

Tylko, ze to nic innego jak indeksy w DBMS.

> Wiadomo jakie to
> pociaga za soba narzuty, ale moze sie oplacac gdy:
> 1) malo jest modyfikacji bazy
> 2) mozna podawac dane troche zdeakutalizowane, a uaktualniac np. raz na dobe.
>

Zgadza się - utrzymanie indeksow ma swoj koszt.

>
>> A co z przeszukiwaniem?
> Nie wiem, to wydaje sie bardzo proste na plikach. Jak dotąd nie miałem z
> tym żadnych problemów.

Bez indeksow? Hmm... Kolejny patent?

> Większe problemy są z aktualizowaniem dużej ilości
> plików.

Niewatpliwie. RDBMS to za Ciebie zalatwi.

--
Michal

do góry

On 2013-05-09 11:28, M.M. wrote:
>
> 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.
>

Bardzo chetnie Ci pomoge... Napisz na priv, to stawke ponegocjujemy

--
Michal

do góry