[elektro] Paypal és Facebook

[Xorn]

A "100-at sem"-nél ez már nagyságrendileg több. :-)

És nem csak "mezei SSD" létezik. Jó pénzért van annál sokkal jobb is.

Best regards,
Andy

2013/5/7 Vajk Fekete <vajkhu at gmail.com>:
> 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]