Kuris variantas geresnis?

Sveiki,

filmų vertinimo svetainė, vartotojų apie 1 mln., vartotojai gali įvertinti filmus ir rašyti komentarus.

Dabar galvoju, koks variantas būtų pats geriausias:

A) Turėti ConcurrentDictionary¹, kuris saugotų visus vartotojų įvertintus filmus, ir kitą tokį patį su vartotojų komentarais. Kas N laiko ciklas sudėtų informaciją į duomenų bazė.

B) Visus vartotojų įvertintus filmus ir parašytus komentarus iš karto saugome į duomenų bazę (INSERT/UPDATE/DELETE), traukiame taip pat tiesiai iš DB (SELECT).

Mano nuomone - geriausias variantas būtų A, bet įdomu ką manote Jūs. Būtų malonu, jeigu atsakymai būtų su argumentais. Ačiū.

^{1 - Java programavimo kalboje būtų ConcurrentMap.}

EDIT:

Atsakymas: http://stackoverflow.com/questions/40318645/which-one-way-is-better

Aš klydau, geriausias variantas būtų B, visa info rasite stackoverflow forum'e.

Naudok tiesiogiai duomenų bazę + Redis cache'ui ir nematysi problemų :)

Atsakymas: http://stackoverflow.com/questions/40318645/which-one-way-is-better

Nei tu klydai nei tu ką. Jeigu tau dabar servo performanso užtenka, tai nematau tikslo aplamai kažką daryti, na nebent dar optimizuoti pačias užklausas. Bet ateina laikas, kaip B) variantas tampa rakštis šiknoje ir tada labiau reikia linkti prie kažko panašaus į A). Tas SQL kešavimas, kurį tau taip gražiai apibūdino, nėra kažkoks super gėris, nes kaip supratai apkrauna atmintį, o atmintis gali greitai būti užkišta.

"NEVER keep data only in memory unless it is transient. What happens if your app or site crashes?" - teisingai, bet reikia apsibrėžti savoką, kas yra "laikini duomenys".

Pilnai gali dinamiškus duomenis laikinai saugoti į kažkokią NoSQL saugyklą(pvz. kaip minėjo kropcik Redis), o duomenų bazėje išsaugoti visus duomenis tarkim kas 5s(tam gali naudoti queue), ko pasekoje į duomenų bazę per minutę vietoje 1000 atsitiktinių užklausų, turėsi tik 12 organizuotų. Ir tikrai nereikės baimintis dėl užlūžusio servo ir dėl prarastų duomenų.

Nei tu klydai nei tu ką. Jeigu tau dabar servo performanso užtenka, tai nematau tikslo aplamai kažką daryti, na nebent dar optimizuoti pačias užklausas. Bet ateina laikas, kaip B) variantas tampa rakštis šiknoje ir tada labiau reikia linkti prie kažko panašaus į A). Tas SQL kešavimas, kurį tau taip gražiai apibūdino, nėra kažkoks super gėris, nes kaip supratai apkrauna atmintį, o atmintis gali greitai būti užkišta.

 

"NEVER keep data only in memory unless it is transient. What happens if your app or site crashes?" - teisingai, bet reikia apsibrėžti savoką, kas yra "laikini duomenys".

Pilnai gali dinamiškus duomenis laikinai saugoti į kažkokią NoSQL saugyklą(pvz. kaip minėjo kropcik Redis), o duomenų bazėje išsaugoti visus duomenis tarkim kas 5s(tam gali naudoti queue), ko pasekoje į duomenų bazę per minutę vietoje 1000 atsitiktinių užklausų, turėsi tik 12 organizuotų. Ir tikrai nereikės baimintis dėl užlūžusio servo ir dėl prarastų duomenų.

Mano nuomonę jie visi buvo teisus ir naudojant variantą A, būtų bloga praktika. Geriausias būdas yra naudoti varianta B. Kaip ir minėjau visi atsakymai yra stackoverflow.

Jeigu variantas B tampa rakštis šiknoje, kaip Jūs sakote, tada geriausias variantas būtų optimizuoti pačias SQL užklausas, tada reikėtu pasižiūrėti ar nėra jokių bottleneck'u pačiam kode, nepamirškime visų IIS, SQL Server konfiguracijų, pačio serverio, taip pat, nežinia koks serverio buildas, gal jis nėra skirtas 1 mln. vartotojų.

In-memory info nėra saugi, nes jeigu bus crashas visa informacija dings, kaip į vandenį.

Taip, aš sutinku, jeigu informacija yra nekintanti (dinamiška), gali ją cachinti, bet kam, jeigu pats SQL Server turi cache. Tas pats liečia dėl atidarytu connectionų, yra .NET connection poolingas, kuris nesukels tau problemų, jeigu ir vienu metu 100k vartotojų išsaugos info į DB.

Mano nuomonę jie visi buvo teisus ir naudojant variantą A, būtų bloga praktika. Geriausias būdas yra naudoti varianta B. Kaip ir minėjau visi atsakymai yra stackoverflow.

 

Jeigu variantas B tampa rakštis šiknoje, kaip Jūs sakote, tada geriausias variantas būtų optimizuoti pačias SQL užklausas, tada reikėtu pasižiūrėti ar nėra jokių bottleneck'u pačiam kode, nepamirškime visų IIS, SQL Server konfiguracijų, pačio serverio, taip pat, nežinia koks serverio buildas, gal jis nėra skirtas 1 mln. vartotojų.

 

In-memory info nėra saugi, nes jeigu bus crashas visa informacija dings, kaip į vandenį.

Taip, aš sutinku, jeigu informacija yra nekintanti (dinamiška), gali ją cachinti, bet kam, jeigu pats SQL Server turi cache. Tas pats liečia dėl atidarytu connectionų, yra .NET connection poolingas, kuris nesukels tau problemų, jeigu ir vienu metu 100k vartotojų išsaugos info į DB.

Taip, jie gal ir teisūs, bet žiūrint iš kurios pusės pažiūrėsi.

Jeigu jau naudojamas ".NET connection poolingas" - tai reikėtų visų pirmą teisingai suformuluoti klausimą, nes čia į variantą(B) kada užklausos apdorojamos tiesiogiai nepanašu. Kažką panašaus aš ir siūliau ankstesniame pranešime sakydamas, kad užklausas dėti į eilę.

Kalbant apie laikiną atmintį - laikina atmintis ir yra laikina, o ne ta, kurioje kažkas saugojama ir laikoma. Po crasho viskas būna atstatoma iš duomenų bazės ir puslapis vėl važiuoja. Ir kaip matau nelabai supranti, kaip veikia tas SQL cache, nes jis būtent pats ir yra saugojamas laikinojoje atmintyje, kuri po to pačio crasho neišlieka.

SQL cache nėra kažkoks beribis gėris, nebent tau negaila švaistyti pinigus ant galingo servo ir nuolat didinti resursus - pirmyn, bet tai neišeitis, nes su srautu didės ir išlaidos.

Trumpai tariant - nebūtų problemų, nebūtų kažkiokių cache alternatyvų.

A very important aspect to watch for is whether SQL Server is using the maximum memory available on the system (assuming the system is dedicated to SQL Server). A system with a fully utilized memory may be prone to performance bottlenecks when competition for resources increases. Prepared Transact-SQL statements, for example, may suffer when the procedure cache is unable to expand due to fully utilized buffer caches.

Galima nustatyti, kiek RAM galėtu maximaliai pasiimti SQL Serveris. Kaip ir minėjau, jeigu turi daug vartotojų ir sistema nėra paprasta, tau neužteks paprasto VPS, tas pats liečia konfiguracijas, kad ir to pačio SQL Serverio, negali palikti default nustatymų, kurie leidžia esant reikalui pasiimti 2147483647 MB.

http://i.imgur.com/t4UdOHu.png

Pasidariau testus, su daugiau negu 1 mln. vartotojų ant nešiojamo kompiuterio, SELECT nors ir paprastas pagal ID (int) arba NAME (varchar), suveikė tikrai labai greitai, tai parodo, kad paprastiems query net neverta daryti dar vieno papildomo cache, aš įsivaizduoju, kad ant gero serverio šitas procesas užtruktu dar trumpiau. Jeigu informacijos labai daug ir ji bus tokia pati t.y. grąžinama po kažkokio veiksmo, cache daryčiau, kad bereikalo vėl nesikreiptų į DB, išsaugodamas List'e, Dictionary arba tam pačiam MemoryCache, kas yra in-memory + lengvai galėčiau manipuliuoti gautą informaciją.

Taip, jie gal ir teisūs, bet žiūrint iš kurios pusės pažiūrėsi.

 

Jeigu jau naudojamas ".NET connection poolingas" - tai reikėtų visų pirmą teisingai suformuluoti klausimą, nes čia į variantą(B) kada užklausos apdorojamos tiesiogiai nepanašu. Kažką panašaus aš ir siūliau ankstesniame pranešime sakydamas, kad užklausas dėti į eilę.

 

Kalbant apie laikiną atmintį - laikina atmintis ir yra laikina, o ne ta, kurioje kažkas saugojama ir laikoma. Po crasho viskas būna atstatoma iš duomenų bazės ir puslapis vėl važiuoja. Ir kaip matau nelabai supranti, kaip veikia tas SQL cache, nes jis būtent pats ir yra saugojamas laikinojoje atmintyje, kuri po to pačio crasho neišlieka.

SQL cache nėra kažkoks beribis gėris, nebent tau negaila švaistyti pinigus ant galingo servo ir nuolat didinti resursus - pirmyn, bet tai neišeitis, nes su srautu didės ir išlaidos.

 

Trumpai tariant - nebūtų problemų, nebūtų kažkiokių cache alternatyvų.

Bet kodėl dauguma naudoja tiesiogiai DB?

Tarkime, kas 5s iš eilės rašo į DB. Per tą laiką prisikiaupia 100k įrašų eilėj. Sistema, nespėjus pradėti rašymo į DB - lūžta.

Ar tada tikrai toks sprendimas (A) yra geras, patikimas?

Ar tai labiau priklauso apie ką kalbama, pvz vienoks dalykas, jei ta informacija yra tiesiog kažkokie eventai, kuriems pradingus pasaulis nežlugs. Bet visai kas kitka, jeigu tai yra informacija apie pinigų pervedimus, ne?

Be to, naudojant NoSQL - negeriau iškart MongoDB naudot ir tiek?

Bet kodėl dauguma naudoja tiesiogiai DB?

Tarkime, kas 5s iš eilės rašo į DB. Per tą laiką prisikiaupia 100k įrašų eilėj. Sistema, nespėjus pradėti rašymo į DB - lūžta.

Ar tada tikrai toks sprendimas (A) yra geras, patikimas?

Ar tai labiau priklauso apie ką kalbama, pvz vienoks dalykas, jei ta informacija yra tiesiog kažkokie eventai, kuriems pradingus pasaulis nežlugs. Bet visai kas kitka, jeigu tai yra informacija apie pinigų pervedimus, ne?

Be to, naudojant NoSQL - negeriau iškart MongoDB naudot ir tiek?

Dauguma naudoja tiesiogiai DB, nes taip saugiau, geriau ir greičiau. O DB serveris nėra kvailas (cachina ir pnš), plius jeigu atlieki papildomas konfiguracias ir moki parašyti gerą SQL niekada neturėsi problemų. Čia kalba ėjo apie C# programavimo kalbą, kuri turi savo niuansiu, kurie padeda, vienas iš jų connection pooling.

1. Žinoma, kad nėra geras, pats dar pasakei problemą, nėra saugumo, nes appsas/webas gali nulūžti ir visa tavo informacija išeis, kaip į vandenį.

2. Tau net nereikia cachinti `SELECT`, nes jis jau yra cachinimas tavo DB serverio dėka, kaip ir minėjau, nebent operacija tikrai sunki (užtrunka daug laiko, BET čia jau spėju blogas SQL arba blogas sprendimas) ir/arba reikės manipuliuoti su gauta informacija ir pvz.: ją atvaizduosi vėl tokią pačią po kito vartotojo veiksmo, kuris pvz.: yra 'Grįžti atgal', bet vėl gi, jeigu operacija paprasta ir tau nereikės tos informacijos apdoroti, tiesiog paprastas `SELECT`, pvz.: `SELECT vardas FROM vartotojai WHERE id = @id;`, tau tikrai nereikia dar papildomai cachinti jo į appso/webo atmintį.

3. Gali paskaityti, kuom skiriasi MongoDB nuo MySQL ir sužinosi veikimo principus - https://www.mongodb.com/compare/mongodb-mysql, tada galėsi nuspręsti, ko tavo appsui/webui reikės.

Premature optimization is the root of all evil

Ypač kai iš šitoje temoje parašytų pranešimų susidaro įspūdis, kad nežinai, ką nori optimizuoti. Pirmas pranešimas lyg ir apie duomenų bazes, po to ant galo parašai, jog čia klausimas apie C# niansus...

Rašymas tiesiai į DB yra būtent tas variantas, nuo kurio turi pradėti. Normali duomenų bazė neužsivers nuo kelių milijonų įrašų, o tie visi milijonas vartotojų vis tiek vienu metu neprisijungs ir tavo serverio nenu'DDOS'ins.

SQL visada yra paprastesnis ir saugesnis pasirinkimas. NoSQL duomenų bazę imi tuo atveju, jei tavo duomenys neturi schemos arba reikia spartos, talpos ar kokio funkcionalumo, kurio SQL duombazės negali pasiūlyti (NoSQL duombazės tuo ir skiriasi nuo SQL, kad jos paaukoja dalį SQL funkcionalumo tam, kad pagerintų našumą, išplėčiamumą ar kitas savybes).

Ypač kai iš šitoje temoje parašytų pranešimų susidaro įspūdis, kad nežinai, ką nori optimizuoti. Pirmas pranešimas lyg ir apie duomenų bazes, po to ant galo parašai, jog čia klausimas apie C# niansus...

 

Rašymas tiesiai į DB yra būtent tas variantas, nuo kurio turi pradėti. Normali duomenų bazė neužsivers nuo kelių milijonų įrašų, o tie visi milijonas vartotojų vis tiek vienu metu neprisijungs ir tavo serverio nenu'DDOS'ins.

 

SQL visada yra paprastesnis ir saugesnis pasirinkimas. NoSQL duomenų bazę imi tuo atveju, jei tavo duomenys neturi schemos arba reikia spartos, talpos ar kokio funkcionalumo, kurio SQL duombazės negali pasiūlyti (NoSQL duombazės tuo ir skiriasi nuo SQL, kad jos paaukoja dalį SQL funkcionalumo tam, kad pagerintų našumą, išplėčiamumą ar kitas savybes).

Tai, kad aiškiai temoje buvo parašyta `ConcurrentDictionary`, tai turėtum suprasti, kad kalba ėjo apie DB su C# sąveika. Nes klausimas ir buvo ar gerai yra laikyti duomenis `ConcurrentDictionary`, o po to sukti ciklą ir viską sudėti į DB, o atvaizdavimui, tiesiog viską ištraukti iš to pačio `ConcurrentDictionary`. Bet atsakymas jau seniai aiškus, kad NE, taip daryti nėra gerai. O dėl NoSQL pasidalinau nuoroda, kurioje yra aiškiai parašyta, kuom skiriasi MongoDB nuo MySQL, net su pavyzdžiu.

Dėl citatos: "Premature optimization is the root of all evil", pilnai sutinku, paklausdamas šitos temos čia ir stackoverflow, plius papildomai googlindamas supratau, kad šitas sprendimas nėra geras ir pati programavimo kalba bei DB serveris jau atlieka tai už tave, todėl papildomai kažką darydamas tu padarysi tik blogiau, šiuo atveju, jeigu naudosi sprendimą A, o ne B.

Bet kodėl dauguma naudoja tiesiogiai DB?

Tarkime, kas 5s iš eilės rašo į DB. Per tą laiką prisikiaupia 100k įrašų eilėj. Sistema, nespėjus pradėti rašymo į DB - lūžta.

Ar tada tikrai toks sprendimas (A) yra geras, patikimas?

Ar tai labiau priklauso apie ką kalbama, pvz vienoks dalykas, jei ta informacija yra tiesiog kažkokie eventai, kuriems pradingus pasaulis nežlugs. Bet visai kas kitka, jeigu tai yra informacija apie pinigų pervedimus, ne?

Be to, naudojant NoSQL - negeriau iškart MongoDB naudot ir tiek?

Nereikia tų 5s. Aš tiesiog daviau kaip pvz. Esmė, ne intervalai, o sujungimų kontroliavimas, nes visos "tiesioginės užklausos" labai greitai gali užkišti atmintį. Autorius minėjo, kad viskas su tuo pas jį gerai, tai viskas kaip ir ok.

Bet jeigu pakomentuojant dar tuos lūžimus, tai atsimink, kad duomenų bazės duomenys saugomi tame pačiame serveryje kaip ir įvairių NoSQL duomenų bazių duomenys, o ne kažkur kosmose. Be backup'o, nei vieno nei kito neatstatysi.