| Autor | Zpráva | ||
|---|---|---|---|
| vybrano Profil |
Mám tabulku:
id(int) user(int) priceA(int) priceB(int) time(int) Každých 30 minut je každému uživateli vytvořen jeden záznam (tedy 1 uživatel = 17520 řádků / rok). -------------------------------- Dokáže mi někdo říci, kolik tato MySQL bude zabírat za rok např. pro 1 000, 10 000, 100 000 uživatelů? -------------------------------- Jde mi o to, že mám limitovaný MySQL prostor na hostingu (cca 200 MB). A pokud toto budu dělat, tak jestli velmi brzy narazím? Nebo jestli je toto únosné? Nemám nejmenší představu. |
||
| pcmanik Profil |
vybrano:
INT zaberá 4 bajty, teda jeden záznam v tabuľke bude mať 20 bajtov (nerátam index). Za rok je to na jedného užívateľa 0.35 Mb z toho si už vieš vypočítať koľko užívateľov sa ti tam vojde. Nezabudni na veľkosť indexu + prípadne nejaké metadáta čo si mysql ukladá. Ako bezpečnú hranicu by som videl 0.4 Mb na užívateľa za rok, teda v konečnom dôsledku to máš tak na 500 ľudí, ak som sa niekde v počtoch neobabral :D Ale máš to nejaké celé čudné, cena ako Int? čas ako int? Čo sa vlastne pokúšaš ukladať? Si si istý že potrebuješ INT (4 bajty)? Nestačí ti MEDIUMINT (3 bajty), prípadne SMALLINT (2 bajty)? |
||
| Alphard Profil |
#3 · Zasláno: 17. 10. 2017, 23:48:13
Tady je spíš podezřelá ta věta „Každých 30 minut je každému uživateli vytvořen jeden záznam“. Působí to jako docela nešťastný návrh, kdy bude každá mrtvá duše alokovat další a další prostor. Nešlo by to líp?
|
||
| vybrano Profil |
Jedná se o web, který sleduje pohyb investice. A tato tabulka každých 30 minut zaznamenává investovanou částku / aktuální cenu (z čehož generuji graf).
Konkrétní data vypadají následovně: id: 28 (int) user: 14 (int) investováno: 65565 (int) aktuálnícena: 72634 (int) time: 150822540 (int) - Nevidím zde příležitost k použití smallint. - Mohl by jsem mazat neaktivní profily. To mi ale pomůže velmi minimálně. //žádné indexy/meta data nastavené nemám |
||
| vybrano Profil |
#5 · Zasláno: 18. 10. 2017, 03:51:55
Tak jsem to změnil.
Mám tabulku 1 den (30 minut step)= 48 záznamů. (staré mažu) Mám tabulku 1 rok (1 den step)= 365 záznamů. Tedy namísto původních 17520 user / rok nyní mám 413 user / rok. Což by dle pcmanik propočtu mělo být dostatečné pro 21 000 uživatelů. |
||
| Alphard_ Profil * |
#6 · Zasláno: 18. 10. 2017, 09:38:07
vybrano [#4]:
Aha, můj dotaz směřoval trochu jiným směrem. Občas se tady objeví tazatelé, kteří se snaží o online hru, při implementaci nadužívají cron a ukládají hromadu dat, které ve skutečnosti není třeba ukládat (lze je spočítat). Napadlo mě, jestli to není tento případ. 1. Nevidím do pozadí, aktuální cenu predikovat nejde? Třeba uložit si nějaký globální koeficient a pak jen počítat? Pokud jsou změny pro každého uživatele unikátní, je vše v pořádku, není jiná možnost, než je ukládat. 2. Ukládat pak data agregovaná po jednom dni bude asi rozumné, jestli to aplikaci stačí. I kvůli výpisům, group by je docela drahá konstrukce. Stará data byste nemusel nutně mazat, ale mohla by se vyexportovat a zazipovat. Velikost bude minimální a necháte si otevřené dveře do budoucna.
|
||
| vybrano Profil |
#7 · Zasláno: 18. 10. 2017, 12:04:14
Alphard
Můžeš se podívat na konkrétní ukázku: www.coinparator.com/cgqnYQ ---- Ukládat každých 30 minut, pro každého uživatele, celkovou cenu jeho portfolia, je dle mě datově/výkonově nejméně náročné. ---- Pokud bych se snažil ukládat historii cen absolutně všech "coins", a potom se při každém načtení snažil přepočítávat hodnotu absolutně celého portfolia pro 48 bodů v grafu, tak by to bylo dle mě ještě horší. |
||
|
Časová prodleva: 7 let
|
|||
0