Е, ако се надявате на нов отговор, това означава, че вероятно сте чели отговорите ми, а аз звуча като счупена плоча. Вижте Блог за разделяне за малкото случаи на използване, при които разделянето може да помогне за производителността. Вашият не звучи като всеки от 4-те случая.
Свиване на device_id
. INT
е 4 байта; наистина ли имате милиони устройства? TINYINT UNSIGNED
е 1 байт и диапазон от 0..255. SMALLINT UNSIGNED
е 2 байта и диапазон от 0..64K. Това ще свие малко таблицата.
Ако вашият истински Въпросът е как да управляваме толкова много данни, тогава нека „мислим извън кутията“. Прочетете.
Графика... Какви периоди от време изобразявате?
- „Последният“ час/ден/седмица/месец/година?
- Произволен час/ден/седмица/месец/година?
- Произволен диапазон, който не е обвързан с границите ден/седмица/месец/година?
Какво рисувате?
- Средна стойност за един ден?
- Макс/мин за деня?
- Свещници (и т.н.) за ден или седмица или каквото и да било?
Независимо от случая, трябва да изградите (и постепенно да поддържате) обобщена таблица с данни. Ред ще съдържа обобщена информация за един час. Бих предложил
CREATE TABLE Summary (
device_id SMALLINT UNSIGNED NOT NULL,
sensor_id TINYINT UNSIGNED NOT NULL,
hr TIMESTAMP NOT NULL,
avg_val FLOAT NOT NULL,
min_val FLOAT NOT NULL,
max_val FLOAT NOT NULL
PRIMARY KEY (device_id, sensor_id, hr)
) ENGINE=InnoDB;
Една обобщена таблица може да е 9 GB (за текущо количество данни).
SELECT hr,
avg_val,
min_val,
max_val
FROM Summary
WHERE device_id = ?
AND sensor_id = ?
AND hr >= ?
AND hr < ? + INTERVAL 20 DAY;
Ще ви даде hi/lo/avg стойности за 480 часа; достатъчно за графика? Вземането на 480 реда от обобщената таблица е много по-бързо от грабването на 60*480 реда от таблицата с необработени данни.
Получаването на подобни данни за една година вероятно би задушило пакет с графики, така че може струва си да изградите резюме на резюмето - с резолюция от един ден. Ще бъде около 0,4 GB.
Има няколко различни начина за изграждане на обобщената таблица(и); можем да обсъдим това, след като размишлявате върху красотата му и прочетете блог за обобщени таблици . Може да се окаже, че събирането на данни за един час и след това увеличаването на обобщената таблица е най-добрият начин. Това би било донякъде като дискутирания джапан моят блог за Staging table .
И ако сте имали почасовите обобщения, наистина ли имате нужда от данните за минута? Помислете да го изхвърлите. Или може би данни след, да речем, един месец. Това води до използване на разделяне, но само в полза на изтриването на стари данни както е обсъдено в "Случай 1" от блог за разделяне
. Това означава, че ще имате ежедневни дялове, като използвате DROP
и REORGANIZE
всяка вечер, за да изместите часа на таблицата "Факт". Това ще доведе до намаляване на вашия 145GB отпечатък, но без загуба на много данни. Нов отпечатък:около 12 GB (почасово обобщение + подробности за последните 30 дни минута по минута)
PS:блогът с обобщена таблица показва как да получите стандартно отклонение.