W dniu czwartek, 9 maja 2013 21:55:04 UTC+2 użytkownik Edek napisał:

> 3 i pół. Plus problemy typu kto rodziela ruch - są dedykowane
> rozwiązania failover.
3 i pol to moze byc calkiem duzo, jesli da sie taki efekt osiagac
przy pomocy samej konfiguracji i podlaczeniu nowych komputerow.


> 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.
Policzenie wydaje sie trudne, nawet jesli przyblizone.


> 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.
Takie rozwiazanie jest najlepsze na poczatek. Jak wystarczy to good. Jak nie,
to trzeba dalej szukac.


> 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.
To sie dopiero okaze za dluzszy czas. Nie mam pewnosci ile pieniedzy
odwaza sie wpakowac w reklame i na ile bedzie skuteczna.


> Ja specjalnie mówię o rzeczach dostępnych za free (poza sprzętem).
> To byłoby skalowaniem w górę.
Prawdopodobnie nie bede mial innego wyjscia. Zakup srzetu i tak wychodzi
taniej niz dodatkowy rok rzezbienia w jakims MPI.


> Może poćwicz na amazonie, na pewno są gotowe rozwiązania nawet
> jak nie ma benchmarków.
Na amazonie to chyba jedynie rozwiazania klastrowe. Chcialbym jeszcze
sprawdzic jak rosnie wydajnosc bazy na jakims RAID z kilku SSD.


> 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 ;)
Heh :)

Pozdrawiam

do góry

W dniu piątek, 10 maja 2013 12:33:49 UTC+2 użytkownik darekm napisał:

> Bazy SQL �rednio si� zr�wnoleglaj�, aby spe�nic ACID
> ma zwoje wymagania.
To na pewno tez, ale ja bym sie doszukiwal przyczyny w tym, ze bazy
danych musza miec algorytmy i struktury wydajne w ogolnym przypadku.


> 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
Problem w tym, ze na prototyp mam malo czasu i pieniedzy. Musze zrobic
szybko i tanim kosztem. Potem moze bedzie wiekszy budzet, ale glupio
wywalac pol roku roboty kilku ludzi i przechodzic na drastycznie
inne rozwiazanie. Fajne byloby jakies lagodne przejscie, np. zwykla
baza SQL, a potem tylko lepsze macierze dyskowe, dyski SSD i modyfikacja
tylko niektorych algorytmow. Jakbym mial od razu duzo srodkow, to bym
od razu zrobil w wszystko w C++ i MPI na jakims klastrze ze 100 zwyklych
komputerow.


> Popatrz na Google, ma miliony razy wi�ksz� baz�, miliony razy wi�cej
> zapyta� a odpowiada w czasie kr�tszym od 0.1 s
Nie wiem ile w tym prawdy, ale slyszalem ze on nawet swoj system plikow
napisali.


Pozdrawiam

do góry

W dniu piątek, 10 maja 2013 12:57:09 UTC+2 użytkownik Michal Kleczek napisał:

> A co to znaczy "fizyczne"?
To znaczy minimalizowac ilosc operacji dyskowych poprzez lepsze-fizyczne
rozlozenie danych na nosnikach.


> Kt�ry talerz/sciezka/glowica, czy co tam
> jeszcze w tych dyskach siedzi? A jesli jest RAID? A jesli jest SSD?
Obojetnie, byle dzialalo szybko.


> Poczytaj o poziomach abstrakcji.
Jakis link do lektury?

> Tylko, ze to nic innego jak indeksy w DBMS.
Nie wiem, moze czegos nie zrozumialem. Jakie inne indeksy
umozliwia trzymanie danych obok siebie? Clustered mozna
zakladac tylko na jedno pole, wiec odpada, prawda?


> Zgadza siďż˝ - utrzymanie indeksow ma swoj koszt.
Ale nnie o to chodzilo, nie mam juz sily powtarzac tego samego.


> Bez indeksow? Hmm... Kolejny patent?
Nie pamietasz tego o czym pisalismy kilka postow wyzej, albo jestes
po prostu zlosliwy.


> Niewatpliwie. RDBMS to za Ciebie zalatwi.
Wwiem ze zalatwi, nie wiem tylko jak wolno.

> Bardzo chetnie Ci pomoge... Napisz na priv, to stawke
> ponegocjujemy
Niesadze abys chcial w takich warunkach robic. Troche szukalem i
na razie nie ma sensu.

Pozdrawiam

do góry

Dnia 08-05-2013 o 22:51:56 M.M. <m...@g...com> 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.

To zdecydowanie za dużo. Jeżeli już na początku (serwis jeszcze nie jest
popularny = mało danych), na pierwszych stronach serwisu masz zapytania,
które trwają po 2 sek, to zdecydowanie coś mocno skaszaniłeś. 200 ms to
chyba maksimum, na które sobie możesz pozwolić.

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

Twoja arytmetyka nie jest do końca poprawna, ponieważ serwery potrafią
równolegle wykonywać kilkadziesiąt zapytań, bez zauważalnej straty
wydajności. A użytkowników jak założyłeś jest wielu.

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

To zależy jak bardzo spójna ta baza musi być. O ile nie robisz systemu
finansowego, to chyba można zadowolić się weak consistency.

Facebook zrobił własną bazę danych non-sql, obecnie Apache Cassandra, po
tym jak mu MySQL przestał wystarczać. Polecam sprawdzić, w jakim języku
jest napisany silnik tej bazy.

> 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 :)

Albo dwa razy za mało: http://goo.gl/79J4

--
Boguś
/Każdy skutek ma swoją przyczynę/

do góry

W dniu sobota, 11 maja 2013 21:25:04 UTC+2 użytkownik Bogusław Szczepanowski napisał:
> To zdecydowanie za dużo. Jeżeli już na początku (serwis jeszcze nie jest
> popularny = mało danych), na pierwszych stronach serwisu masz zapytania,
> które trwają po 2 sek, to zdecydowanie coś mocno skaszaniłeś. 200 ms to
> chyba maksimum, na które sobie możesz pozwolić.
To oczywiste.


> Twoja arytmetyka nie jest do końca poprawna, ponieważ serwery potrafią
> równolegle wykonywać kilkadziesiąt zapytań, bez zauważalnej straty
> wydajności. A użytkowników jak założyłeś jest wielu.
To tylko szacowanie, nie znam rozkladu zapytan w czasie i kosztu
opracowania pojedynczego zapytania.


> To zależy jak bardzo spójna ta baza musi być. O ile nie robisz systemu
> finansowego, to chyba można zadowolić się weak consistency.
Na utrate spojnosci czy bledy nie moge sobie pozwolic. Natomiast moge
pozwolic sobie na pewnie opoznienia. Dlatego mysle zeby do sekwencyjnych
zbiorow danych zrzucac dane i uaktualniac je tylko co jakis czas.


> Facebook zrobił własną bazę danych non-sql, obecnie Apache Cassandra, po
> tym jak mu MySQL przestał wystarczać. Polecam sprawdzić, w jakim języku
> jest napisany silnik tej bazy.
Slyszalem ze w PHP, a potem skompilowane jakims kompilatorem/optymalizatorem.


> > 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 :)
> Albo dwa razy za mało: http://goo.gl/79J4
Chcialbym miec tyle w domu ;-)

400mln/60tys ~ 7tys userow na kompa, pewnie rzadko korzysta
przecietny uzytkowik.

Pozdrawiam

do góry

Użytkownik "M.M." <m...@g...com> napisał w wiadomości
news:93e7ba93-5d8a-4dea-a3b7-921471d5b8ab@googlegrou
ps.com...
W dniu sobota, 11 maja 2013 21:25:04 UTC+2 użytkownik Bogusław Szczepanowski
napisał:

>> Facebook zrobił własną bazę danych non-sql, obecnie Apache Cassandra, po
>> tym jak mu MySQL przestał wystarczać. Polecam sprawdzić, w jakim języku
>> jest napisany silnik tej bazy.
>Slyszalem ze w PHP, a potem skompilowane jakims
>kompilatorem/optymalizatorem.

Myslisz baze danych z jezykiem bezposrednio generujacym html.

do góry

W dniu niedziela, 12 maja 2013 07:43:33 UTC+2 użytkownik Ghost napisał:
> Myslisz baze danych z jezykiem bezposrednio generujacym html.
Ok, dzieki za zwrocenie uwagi.

do góry

On 2013-05-11 01:25, M.M. wrote:
> W dniu piątek, 10 maja 2013 12:57:09 UTC+2 użytkownik Michal Kleczek napisał:
>
>> A co to znaczy "fizyczne"?
> To znaczy minimalizowac ilosc operacji dyskowych poprzez lepsze-fizyczne
> rozlozenie danych na nosnikach.
>

W calym watku to sie pojawia wielokrotnie:
1. twoje rozwiazania tego nie zapewniaja bo operuja na poziomie systemu
plikow - a od systemu plikow do fizycznego rozlozenia danych na
nosnikach jeszcze baaaaaaardzo daleka droga
2. DBMS jest dokladnie pod to projektowany, by minimalizowac ilosc
operacji we/wy przy dostepie do danych

>
>> Kt�ry talerz/sciezka/glowica, czy co tam
>> jeszcze w tych dyskach siedzi? A jesli jest RAID? A jesli jest SSD?
> Obojetnie, byle dzialalo szybko.
>

Wziac dobry (odpowiedni do zastosowan) DBMS. NIE probowac robic "lepiej".

>
>> Poczytaj o poziomach abstrakcji.
> Jakis link do lektury?
>

Na poczatek moze:
http://en.wikipedia.org/wiki/Database_design#Types_o
f_Database_design

>> Tylko, ze to nic innego jak indeksy w DBMS.
> Nie wiem, moze czegos nie zrozumialem. Jakie inne indeksy
> umozliwia trzymanie danych obok siebie?

Kazdy indeks jest po to, zeby minimalizowac czas dostepu do danych.
Rozne rodzaje indeksow sa przeznaczone do
a) roznego rodzaju dostepu
b) roznych rodzajow danych

Trzymanie danych "obok siebie" niekoniecznie jest najlepsza strategia.
Sa rozne rodzaje indeksow. Na poczatek:
http://en.wikipedia.org/wiki/Database_index

> Clustered mozna
> zakladac tylko na jedno pole, wiec odpada, prawda?
>

Nieprawda.

>
>> Zgadza siďż˝ - utrzymanie indeksow ma swoj koszt.
> Ale nnie o to chodzilo, nie mam juz sily powtarzac tego samego.
>
>
>> Bez indeksow? Hmm... Kolejny patent?
> Nie pamietasz tego o czym pisalismy kilka postow wyzej, albo jestes
> po prostu zlosliwy.
>

Jestem - probuje ci chyba bezskutecznie uswiadomic, ze proponowane przez
ciebie rozwiazania to nic innego jak indeksy w DBMS.

>
>> Niewatpliwie. RDBMS to za Ciebie zalatwi.
> Wwiem ze zalatwi, nie wiem tylko jak wolno.
>

Prawie na pewno szybciej, niz zrobi to kod pisany przez ciebie.

--
Michal

do góry

On 2013-05-10 12:33, darekm wrote:
>
> 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.
>

Ja mam wrazenie, ze caly ruch "noSQL" i "anti-relational" juz osiagnal
swoje apogeum i będzie odchodzil do lamusa, jako absurdalny powrot do
czasow pre-Codd. Sygnal daje sam Google, tworzac Spannera (choc
rozwiazania tego rodzaju pojawily sie wczesniej).

Cale to "noSQL" powoduje wiecej problemow niz ich rozwiazuje. Czas na:
http://en.wikipedia.org/wiki/NewSQL

--
Michal

do góry

W dniu poniedziałek, 13 maja 2013 09:59:47 UTC+2 użytkownik Michal Kleczek napisał:

> W calym watku to sie pojawia wielokrotnie:
> 1. twoje rozwiazania tego nie zapewniaja bo operuja na poziomie systemu
> plikow - a od systemu plikow do fizycznego rozlozenia danych na
> nosnikach jeszcze baaaaaaardzo daleka droga
Czy potrafisz to jakos uzasadnic?


> 2. DBMS jest dokladnie pod to projektowany, by minimalizowac ilosc
> operacji we/wy przy dostepie do danych
Tu na pewno mylisz sie. Pisalem w tym watku kilka razy, napisze jeszcze raz:
projektowany jest po pierwsze pod ogolny przypadek. Poza tym projektowany
jest pod wygode, elastycznosc, bezpieczenstwo, transakcje, wielodostepnosc
itd. Minimalizowanie operacji we/wy ma ktorys z kolei priorytet.


> Wziac dobry (odpowiedni do zastosowan) DBMS. NIE probowac robic "lepiej".
Nie mam bladego jak uzywasz slowa "lepiej", pewnie zupelnie inaczej niz ja.


> Kazdy indeks jest po to, zeby minimalizowac czas dostepu do danych.
> Rozne rodzaje indeksow sa przeznaczone do
> a) roznego rodzaju dostepu
> b) roznych rodzajow danych
> Sa rozne rodzaje indeksow. Na poczatek:
> http://en.wikipedia.org/wiki/Database_index
A jesli dane sa rozrzucone po dysku, to zaden indeks nie pomoze i
trzeba zrobic tyle odczytow, ile jest danych, prawda?


> Trzymanie danych "obok siebie" niekoniecznie jest najlepsza strategia.
Dobrze rozumiem: Niekoniecznie, czyli może być najlepszą?


> > Clustered mozna
> > zakladac tylko na jedno pole, wiec odpada, prawda?
> Nieprawda.
Czytalem ze tylko na jedno, no ale dobra. Wiec pytanie: jak w bazach
jest realizowany clustered na więcej niż jednym polu?



> Jestem - probuje ci chyba bezskutecznie uswiadomic, ze proponowane przez
> ciebie rozwiazania to nic innego jak indeksy w DBMS.
Moze sie mylisz? Moje rozwiazanie w jednym programie potrzebuje kilku
sekund a na sqlite trwalo 90 minut na nieplnej bazie.



> Prawie na pewno szybciej, niz zrobi to kod pisany przez ciebie.
Tez to pisalem wiele razy. Nie chodzi o sciganie sie z baza danych
na poziomie samego kodu. Chodzi jeszcze o sciganie sie na poziomie
stuktur danych.

Pozdrawiam

do góry