| Autor | Zpráva | ||
|---|---|---|---|
| MaK Profil |
#1 · Zasláno: 31. 5. 2021, 11:35:30
Mám tabulku a vedle sloupců, které nesou nějaký rozumný obsah, je tam pomocný sloupec zachycující čas.
Podle něj se záznamy starší jak rok odmazávají. U malé tabulky není co řešit, ale tady přibude 1mil řádků denně (365mil za rok). Použít typ DATE místo TIMESTAMP, nebo bez indexu a promazávat jinak? Záznam se nemusí odmazat na den přesně. MaK |
||
| N71 Profil * |
#2 · Zasláno: 31. 5. 2021, 11:49:15
Mezi Date a Timestamp není co do výkonu zásadní rozdíl. Z logiky věci, pokud to má být čas vytvoření záznamu, tak je vhodný Timestamp.
|
||
| Keeehi Profil |
#3 · Zasláno: 31. 5. 2021, 14:28:40
Pokud se ten čas využívá opravdu jen k mazání, což bude předpokládám nějaká operace která poběží někde na pozadí jednou denně, pak tam asi ten index bude zbytečný. Ne že by ale něčemu asi extra vadil. Spíš jen bude zabírat místo.
|
||
| Kajman Profil |
Je tam rozdíl jednoho bytu
dev.mysql.com/doc/refman/8.0/en/storage-requirements.html#data-types-storage-reqs-date-time což by mohl být roční rozdíl 730MB dat (data + index). Timestamp má i tu nevýhodu, že za 17 let dojde k přetečení a možná by se musela aplikace upravovat. |
||
| MaK Profil |
Keeehi:
A jak tedy smazat staré záznamy. Postupně procházet všechny řádky? Kajman: Neznám BTREE index do detailu, ale nezapříčiní: velká kardinalita budování mnohem jemnějšího stromu (časově i pamětově náročnější). Při čtení průchod takovým stromem trvá déle. zatímco nízká kardinalita budování hrubšího stromu (časově i pamětově levné). Při čtení je průchod takovým stromem rychlejší. Vím, že podobný problém byl v elasticu, kde řešením bylo místo timestampu (milliseconds-since-the-epoch) použít unixtimestamp (seconds-since-the-epoch). A tady borec popisuje, jak při selectu je date 4x rychlejší než timestamp. Create a new indexed column with only year and month VS index datetime/timestamp column directly |
||
| N71 Profil * |
#6 · Zasláno: 31. 5. 2021, 17:16:48
Kajman:
„Timestamp má i tu nevýhodu, že za 17 let dojde k přetečení a možná by se musela aplikace upravovat.“ Návratový datový typ TIMESTAMPu je časový string, tady problém nevznikne. Lze předpokládat, že před rokem 2038 bude datový typ upraven pro větší rozsah v rámci nějaké aktualizace, což se samotného webu netýká. |
||
| Kajman Profil |
MaK
Timestamp udělá jemnější strom než date (pokud se tam budou často lišit hodnoty v rámci stejného dne), takže i index by měl být větší. Ale asi jsem to neodhadl přesně (index jen o 125MB větší?). Můžeš si to zkusit. N71 Zatím je ve specifikaci timestamp omezený TIMESTAMP has a range of '1970-01-01 00:00:01' UTC to '2038-01-19 03:14:07' UTC. tak bych raději počítal s omezením. I pokud to rozšíří, tak v mysql bude nejspíše zabírat 5 bytů místo 4 a date stále 3. |
||
| Keeehi Profil |
#8 · Zasláno: 1. 6. 2021, 11:08:21
MaK:
„A jak tedy smazat staré záznamy. Postupně procházet všechny řádky?“ Z pohledu query úplně stejně. To jestli se použije index nebo se budou číst všechny záznamy si stejně rozhoduje databázový stroj sám. Index je vlastně tradeoff místa a trochy výkonu při ukládání za rychlé vyhledávání. Rychlé vyhledávání však nebývá podmínkou u údržbových jobů, co občas běží na pozadí. Jasně, pokud by to bylo neúnosně pomalé nebo by to neúměrně vytěžovalo databázový stroj tak index by tomu mohl pomoci. Ale jinak tam asi být nemusí. Pokud tě ale místo netrápí a výkonu máš na rozdávání, ničemu tam vadit nebude a klidně ho tam můžeš mít. Jinak ještě existuje partitioning. S mysql jsem to nikdy nepoužíval ale podle dokumentace to podporuje u některých typů storage enginů. Používáme to v práci prakticky na všech tabulkách co máme v hadoop clusteru. Všude máme partitioning by year, month, day. Smazání všech záznamů z daného dne/dní je pak pro cluster triviální operace. |
||
|
Časová prodleva: 3 roky
|
|||
0