[elektro] Paypal és Facebook

[Tanács Dávid Szilveszter]

Azert a storageba nem a haztartasi ssd szokott kerulni...

2013-05-07 13:14 időpontban Vajk Fekete ezt írta:
> Egy mezei ssd jo ha tud parezer muvelet/masodpercet.
> Probald ki, engedj ra egy diszk tesztert random access modban.
>
> Vajk
>
>
> 2013/5/7 Xorn <toth.endre at gmail.com>
>
>> Egy mezei SSD simán... Sőt.
>>
>> Best regards,
>> Andy
>>
>> 2013/5/7 Vajk Fekete <vajkhu at gmail.com>:
>> > Van egy masik kalkulacio is, amit vegig kell csinalni.
>> >
>> > Egy mezei vinyo nem kepes 100 keres per sec-et sem kiszolgalni. Ha 
>> nem
>> > egymas mellett van az ugyfel minden adata, es persze kell 
>> indexeket is
>> > hasznalni hogy megtalald, egy ilyen tortenelem lekerdezes siman 
>> tobb szaz
>> > muvelet. Sokszaz userrel beszorozva az jon ki, hogy az a 2T az 
>> inkabb
>> 10T,
>> > es tobbszaz vinyon kell szetszorni hogy legyen performancia.
>> >
>> > Es meg nem logoltad hogy ki mit csinal, nem ellenoriztel 
>> jogosultsagot,
>> nem
>> > csinaltad meg a rendes elvalasztast az internetes es a hatter 
>> rendszer
>> > kozott. Valojaban ez meg egy tobb mint 10-es szorzot betesz. A 
>> bank nem
>> > google, hogy boven eleg ha egy hozzavetoleges valaszt hozzadvag 
>> gyorsan.
>> >
>> > Vajk
>> >
>> >
>> > 2013/5/7 Móczik Gábor <pm_levlista at progzmaster.hu>
>> >
>> >> 2013.05.07. 11:06 keltezéssel, Vajk Fekete írta:
>> >> > ot ev es 3 honap kozott eleg durva a kulonbseg, ugy 20szoros. 
>> es nem
>> az a
>> >> > fo kulonbseg, hogy 20szor annyi winyo kell, (bar ez sem
>> elhanyagolhato),
>> >> > hanem hogy 20szor annyi adat kozul elovenni azt ami most 
>> erdekel, az
>> >> > mindenkeppen tovabb tart vagy sokkal eroforrasigenyesebb. tehat 
>> a
>> >> rengeteg
>> >> > tortelem ugyanabban a rendszerben tarolasa a napi ugymenetet 
>> lassitana
>> >> vagy
>> >> > tenne eroforrasigenyesebbe.
>> >>
>> >> Eszméletlen technikai kihívás az X időnél régebbi adatokat egy 
>> lassabb
>> >> bár nagy archív tárolóhelyre továbbítani, valamint egy 
>> adatbázisban
>> >> tárolni hogy az X időpont előtti adatok az archívban vannak, az 
>> újabbak
>> >> meg a napi rendszerben. Ez gondolom egyébként is megtörténik, 
>> ettől
>> >> talán bonyolultabban, ha egyszer kötelesek megőrizni.
>> >>
>> >> Ezt az egészet azért érzem igencsak bagatel problémának, mert egy
>> >> számlakivonat tartalma még titkosítási illetve egyéb 
>> adminisztrációs
>> >> overhead-del is annyira minimális, hogy nem kell űrtechnika a
>> >> tárolásához. Ha egy banknak van 1millió ügyfele, akinek 72 
>> hónapra
>> >> visszamenőleg kellene tudni számlakivonatot adni, egy 
>> számlakivonat
>> >> pedig mondjuk 32Kbyte, akkor ha jól számolok az kb. 2T tárhelyet
>> >> igényel. Ez háztartási körülmények között is olcsón elérhető, 
>> nehogy már
>> >> egy banknak milliárdos bevételek mellett ez problémát okozzon.
>> >> A szerver terhelésről meg annyit, hogy pl. az index.hu vagy 
>> hasonló
>> >> weboldal hálózati forgalma szerintem több nagyságrenddel nagyobb 
>> mint
>> >> egy ilyen számlakivonat szolgáltatásé.
>> >>
>> >> De különben sem lenne kritikus, mert még mindig elfogadhatóbb 
>> lenne, ha
>> >> kiírná, hogy az archív rendszer terhelése miatt csak 5 perc vagy 
>> 1 óra
>> >> múlva tudom megkapni az adatokat, minthogy ezért személyesen a 
>> bankba
>> >> kelljen befáradnom, vagy levelet küldeni.
>> >>
>> >> -----------------------------------------
>> >>           elektro[-flame|-etc]
>> >>
>> > -----------------------------------------
>> >           elektro[-flame|-etc]
>>
>> -----------------------------------------
>>           elektro[-flame|-etc]
>>
> -----------------------------------------
>           elektro[-flame|-etc]

-- 
dá