🚀 go-pugleaf

Użytkownik Witek Świerzy napisał:
> Maciej Zobniow wrote:
> 
>> Piotr KUCHARSKI wrote:
>>
>>> Witek Świerzy <wswier@sgh.waw.pl> wrote:
>>>
>>>>> Mam nadzieje ze mnie dobrze zrozumiales: do systemu na spoko, gdzie 
>>>>> klientami jest parunastu pijacych kawe, leniwych analitykow ;).
>>>>
>>>>
>>>>
>>>> Nie - do systemu ktorego klientami sa setki lub tysiace operatorow 
>>>> "porozkladanych" na terenie calego kraju.
>>>
>>>
>>>
>>>
>>> Wydaje mi się, że to mniej więcej sedno problemu. Tam, gdzie inni
>>> stawiają duże w ich mniemaniu bazy na mysql, tam Ty widzisz jakąś
>>> mikrobazkę (która niemal równie dobrze może być na flatfile :>),
>>> a przez "duża baza" masz na myśli ze dwa rzędy wielkości więcej.
>>
>>
>>
>> Oczywiscie problem skali istnieje, ale dlatego na samym poczatku 
>> dyskusji podalem pare danych o mojej bazie. Pozatym mysle ze w tym 
>> konkretnym przypadku rozumujesz niewlasciwie poniewaz opierajac sie na 
>> komplementarnych danych z mojego systemu, do tych ktore skomentowales 
>> z postu Witka wychodzi ze ja mam w systemie 8107200 "operatorow", 
>> rozsianych po calym globie.
>>
>> Pozdro
>> Maciek
> 
> Wydaje mi sie, ze Piotr ma duzo racji. Oprocz liczby sesji liczy sie 
> jeszcze tempo przyrostu danych. Twoja baza, Macku, uzbierala tych danych 
> (o ile sobie dobrze przypominam)  - ok 35 GB przez 4 lata 
> funckjonowania, czyli ok. 9GB rocznie srednio liczac.

Blednie zalozyles ze rosla rownomiernie w czasie. Przyrost ten jest 
narazie raczej zblizony do wykladniczego. Np. od czasu rozpoczecia tej 
dyskusji baza przyrosla o ...2GB (da sie odczuc przedswiateczna 
goraczke). Jedno gigabajtowy bin-log replikacji (mysql loguje tam 
wszystkie zmieniajace dane queries: insert, update, delete etc.) 
zapelnia sie czasem w ciagu jednego dnia. Rok temu w styczniu miala 
jakies 9GB (kupilem wtedy dwa dual opterony+12GB ram do klastra bazy i 
bylem zadowolony ze wszystkie tabele pomieszcza sie w cache i jeszcze 
zostanie wystarczajaco duzo miejsca na query i index cache).

  Znam systemy
> przyrastajace o kilka rzedow wielkosci szybciej - jak sadze, OS by 
> raczej tego nie uciagnal.

hehe...wciaz powtarzasz te przesady. Naprawde wierzysz ze to kwestia 
licencji?

  Zreszta w moim poscie chcialem przede
> wszystkim uwypuklic koniecznosc pracy takich systemow 7x24. Wszak 
> niemoznosc wykonania jakielkolwiek transakcji przynosi takiej instytucji 
> latwo wyliczalne straty (srednia_kwota_przelewu * prowizja_banku). Wiec 
> 2-godzinny przestoj o ktorym wspominales poprzednio kosztuje calkiem 
> spore pieniadze, a wiec jest nieakceptowalny. I wlasnie dlatego stosuje 
> sie tam systemy _NIE_OS_. 

Powtorze sie: "nieakceptowalny" znaczy czasem cos zupelnie innego dla 
roznych przypadkowi. W przypadku b2b nieakceptowalny problem moze 
doprowadzic do tego ze jakis klient nam "podziekuje", co jak sie 
domyslasz moze byc bardzo bolesne jesli tych klientow masz powiedzmy 50 
a nie 500k. W tym segmencie niestety,  klienci sa o niebo bardziej 
wymagajacy niz zwykli konsumenci

Dysponuja one naprawde szerszymi mozliwosciami
> uodpornienia sie na awarie od OS. Nie chcialbym wchodzic na tej liscie w 
> szczegoly (temat baz danych jest tu troche OT, bylo nie bylo :-), ale 
> proponuje Ci abys poczytal np. o mozliwosciach klastrowania Oracle, 
> bazach standby, architekturze data guard itp. Wydaje sie, ze zaden 
> system OS nie dysponuje takimi mozliwosciami. Tak wiec, gdybys 
> przerzucil swoj system np. na oracle ( posluguje sie tutaj najczesciej 
> tym przykladem z racji doswiadczen zawodowych) to moze rzadziej bylbys 
> budzony o 4 am w niedziele. 

Moj system jest dobrze zabespieczony na roznego typu sytuacje, problemy, 
jak to zwykle bywa, najczesciej powoduje tzw. czynnik ludzki.

Inna sprawa to oczywiscie koszty -
> najpewniej taniej jest Cie obudzic o 4 (nie mowie, ze bezpieczniej - 
> wszak dobry Polak, to Polak najedzony i wyspany ;-) rano niz wydac spora 
> kwote pieniedzy na system komercyjny. 

I co by to dalo? Myslisz ze klienci byliby mniej wcurwieni jesli by im 
sie powiedzialo ze to Oracle padl, a support enginer jest w drodze? 
Niestety zaden "wujek z kosmosu" nie pomoze, jesli problem bedzie tkwil 
gdzies gleboko w systemie. Wrecz przciwnie, z wlasnego doswiadczenia 
wiem ze wezwanie support enginera do systemow typu asp zazwyczaj 
poteguje klopoty. Dzieje sie tak dlatego ze zazwyczaj ich pierwszym 
zadaniem jest restart. Niestety o ile w windows ta metoda czasem pomaga, 
na Unixie czesto jeszcze bardziej szkodzi.

Poza tym liczy sie rowniez
> bezpieczenstwo w sensie odpornosci na potencjalne wlamania - i tutaj tez 
> wydaje sie, ze systemy komercyjne dysponuja wieksza liczba zabezpieczen 
> od darmowych (pomijam tu rzecz oczywista jak dostep po https do web 
> serwera - to sie rozumie samo przez sie, ale mowie juz o mechanizmach 
> zaszytych w DBMS-ach - no ale znowu OT, wiec nie rozwijam tematu bez 
> wyraznego zaproszenia :-).

Raczej sie mylisz. Akurat moim zdaniem otwarte systemy sa zazwyczaj 
bespieczniejsze. Dzieje sie tak chocby dlatego ze dysponujac zrodlami 
mozesz zawsze przekompilowac dany komponent (kernel, apache i jego 
moduly i inne otwarte na swiat servisy sa zazwyczaj rutynowo 
kompiliowane ze zrodel w systemach produkcyjnych), wywalajac lub dodajac 
potrzebne moduly. Program wynikowy, jest wtedy unikalny i raczej 
niekoniecznie beda na niego dzialaly exploity spreparowane dla 
defaultowych kompilacji.
W kazdym razie, w przypadku DBMS trzeba sie postarac raczej o 
zapewnienie zewnetrznych mechanizmow ochrony, krotko mowiac nalezy baze 
odciac od jakiegokolwiek, bezposredniego zewnetrznego dostepu.

Pozdro
Maciek