scoreboard keszitese

Algoritmusok

(Pl. bizonyos) webszerverek biztositanak egy olyan feature-t, hogy az egyes child processzek eppen milyen allapotban jarnak. A kerdes az, hogy hova erdemes irni ezeket az allapot infokat?

Hirtelen felindulasbol csinaltam egy mysql memory tablat, es oda mennek az 'update status ....' sql query-k (ezt jelenleg tesztelem). De gondoltam meg arra is, menjenek ezek az update-ek inkabb memcached-be. Ti hogy oldanatok meg ezt a feladatot? (Amugy egy C-ben irt demonrol van szo).

  • 2538 megtekintés

( lx | 2015. 03. 25., sze – 16:21 )

A redis kevésbé tradícionális, mint az rdb, de nem kevésbé jó.

Rendben, ehhez a legelso es legfontosabb: milyen surun irodik ki adat ebbe a tablaba vagy "tablaba"? Mennyire kell ezt akar reportinghoz vagy barmi mashoz ugy kiolvasni, hogy mas MySQL-ben levo adattal joinolva? Meg ugy eleve: milyen surun olvasnal ki ebbol barmit is egyaltalan, es amit kiolvasol, azt hogy szeretned szurni es/vagy csoportositani?
1 nap alatt hany rekord szuletik?

maga a tabla faek egyszeru, nincs semmivel sem join-olva, stb. Nincs szukseg semmilyen kulonleges szuresre vagy csoportositasra. Egy select * a kiolvasas jellemzo formaja, percenkent kb. 1x, azaz relative ritkan.

A rekordok szama a child processzek szamaval megegyezik (egy spamszurorol van szo amugy), tehat igen jo esellyel 100 alatt van. Amikor egy child processz letrejon, akkor tortenik egy insert, ha meghal, akkor delete. Amig meg dolgozik a child, addig frissitgetem a hozza tartozo messages, status es ts oszlopokat. Azt mondanam, kb. 1000...5000 update / sec muvelet tortenik. Egy olyan tarolot keresek (a perzisztencia nem annyira kritikus), ami ezt minel kisebb eroforrasigennyel kepes ezt megvalositani.


mysql> select * from status;
+-------+----------+--------+------------+
| pid | messages | status | ts |
+-------+----------+--------+------------+
| 17060 | 1498 | I | 1427297534 |
| 17058 | 1509 | I | 1427297533 |
| 17125 | 1498 | I | 1427297533 |
| 17061 | 1500 | I | 1427297533 |
| 17059 | 1497 | I | 1427297533 |
| 17126 | 1488 | I | 1427297533 |
| 17121 | 1491 | I | 1427297534 |
| 17124 | 1506 | I | 1427297534 |
| 17057 | 1521 | I | 1427297534 |
| 17123 | 1492 | I | 1427297534 |
+-------+----------+--------+------------+
10 rows in set (0.01 sec)

--
"Van olyan ember sok az oldalon, akinek a kommentjeinek 100%-a zaj, oket miert nem kommentelitek ilyen lelkesen?" (hrgy84)

Akkor itt a connection time a szuk keresztmetszet, meg a suru iras, maga az adatmennyiseg semennyire sem, valamint annak a bonyolult formaja illetve fuggosegei sem.

Nos, oszinte leszek, nem ismerek ilyen jellegu teszteredmenyeket fejbol, de erre elso ranezesre egy "minel egyszerubb NoSQL megoldas" lenne a szavazatom, akar meg a kollega redis-e is befuto lehetne, de azt lattam mar erthetetlenul lelassulni, mikor meg kevesbe kovettem a dolgokat es nem volt kozom az adminolasahoz.

Ami a legfontosabb, hogy barmi is a megoldas, mindenkeppen a ramban tarold (bosegesen elfer), akar tmpfs-ben, ha jol veszem ki diskre kiirnod ezt nem is nagyon kell egy esetleges restartkor sem.

+1 redis vagy tmpfs, de akkor már inkább redis.
redis -t én még csak dump-nál láttam belassulni, de ott az egész gépet megrángatta és azért (az meg egy hibás ssd következménye. Egyébként meg O(1) komplexitású a kulcsok elérése, így meg főleg nem tudom értelmezni a "belassult" dolgot:)

Mi használjuk nagy mennyiségű adat tárolására, saját benchmarkok alapján kb 120k query/sec -el lehet gyötörni, viszont itt már a cpu volt a szűk keresztmetszet, mivel a redis single thread rendszerű. Ha több magra akarod skálázni, akkor cpuid-hez kötve több instance-t indítasz és shard-olod (és akkor magonként 120k query jött ki)

// Happy debugging, suckers
#define true (rand() > 10)

Nem, én nem értek hozzá, már huszonegykét éve nem. Ez a karmám.

Viszont vagyok akkora vénség a bizniszben, hogy nem engedhetem meg magamnak, hogy ne tanuljak a nálam fiatalabbaktól, tekintetbe nem véve szájhigiéniai hiányosságaikat és a gyermekszobájuk takarítására használatos vasvilla hosszát, ezért még a te javaslataidat is árgus szemekkel figyelem a kolléga topicjában.

Attol, hogy huszoneve vagy a szakmaban, meg vonhattal le rossz kovetkeztetest szakmai tapasztalataid megszerese soran. Ami projekten most dolgozom, a lengnagyobb szart egy olyan kollega bugjai utan kell takaritani, aki pont 21 eve programozik (o a legregebb ota a csapatbol).

Egyebkent meg sj kerdesere akar jo valasz is lehet a redis (amint tobb infot megtudunk, kiderul erdemes-e egyaltalan attenni barmire is, de a topiknyito nem volt eleg ennek megallapitasara). A baj az volt, hogy "jobb, mint az rdb". Nem jobb. Mas. Es ezt huszoniksz ev alatt megtanulhattad volna.

Szeretném, ha idéznéd azt a részt az egy szál összetett mondatomból, amely szerinted azt jelenti, hogy "a redis jobb".

Lehet, hogy a huszonpár év nem garancia semmire, de a jelek szerint az azt megelőző kor tancsinénijei és az általuk tartott beszéd- és értelemgyakorlatok hatékonyabbak voltak.

(Amúgy nincs harag, bárki benézheti - ezért felesleges a nagy mellényben indítani.)