Форум MySQL

Попросили меня обдумать вот какую задачу. Есть n-ное количество датчиков (в перспективе — до 256 штук), эти датчики раз в несколько минут опрашиваются, и их показания записываются в базу данных MySQL. Система должна работать годами, при этом оператор (то есть пользователь) должен иметь возможность в любой момент запросить данные, например, с 1 по 10 января прошлого года с датчиков номер 6, 54 и 142. Проблема мне видится в том, что записей при таком подходе будет довольно приличное количество (при опросе раз в минуту получается 525 600 строк в год, каждая минимум по 256 байт, то есть примерно 128 Мб; а если датчики будут с большей разрядностью, чем 8 бит, то уже 256 Мб). Поэтому хочется как-то организовать архив. Сделать просто дамп нельзя — тогда не будет быстрого доступа. Решение вроде бы есть здесь], но нет ли более изящного способа?

Или я зря беспокоюсь, и MySQL такие объёмы данных ничуть не смутят?

вот тут некоторые размышления

>можно использовать что-то типа буфера (ещё одна таблица куда сплошным потоком будут >записываться ! домен ! страница ! юзер ! , а потом уже раз в час или сутки будут обрабатываться >результаты и на их основе будут изменяться данные в основных таблицах, а буфер очищаться.

Увы, у меня нет обработки данных. То есть этот вариант сводится к тому, что описан по моей ссылке — просто периодическое скидывание свежей информации в другую таблицу.

да, но не забывайте о том что в этот буфер идут сплошные инсерты, селект допустим раз в сутки или на тот момент как понадобится свежая статистика, поэтому все поля можно оставить без индекса
а уже в основной таблице можно грамотно расставить индексы

Хм. А что значит (в данном случае) "грамотная расстановка индексов"? Одна таблица, все строки вида id | datetime | val1 | val2 | ... valN. Что тут можно придумать с индексами?

>id | datetime | val1 | val2 | ... valN
Зря, кстати, так храните, добавится у вас через несколько лет еще пару тысяч датчиков и узнаете, каково это с терабайтной многолетней таблицей связываться... Лучше бы еще нормализовать до уровня
id | datetime | N | val
тогда бы таблица могла обслуживать сколько хочешь датчиков, более того, часть датчиков можно было бы выключать из статистики и вообще система была бы более гибкой... не зря же от параллельных интерфейсов COM, LPT, отказываются в пользу последовательных, но более универсальных USB. Только тут экономите место и увеличиваете гибкость.

А ведь это отличная мысль! Тем более что в момент запуска ожидается не больше десятка датчиков, а остальные «когда-нибудь потом».
Вот так поговоришь с умным человеком, сразу всё проще станет)

С сегментацией, к сожалению, не знаком; попробовал на скорую руку погуглить, нашёл ссылку на вашу книгу) Может, есть какие-нибудь статьи на эту тему?

UPD Погуглил более вдумчиво, нашёл вот это. Кажется, это в точности то, что мне нужно. Ещё раз спасибо!

Ищите по ключевому слову Partitioning (Partition) - 17 глава мануала. Если возникнут трудности спрашивайте (только лучше в новой теме).

А ведь это отличная мысль!
это не совсем так, это всего лишь соблюдение правил и норм построения баз данных
правила нормализации базы данных
просто со временем они доводятся до автоматизма :)

Всё в мире относительно) Я с БД работал только на уровне INSERT/UPDATE/SELECT, так что для меня это именно «отличная мысль»=)

Вы же вероятно не ограничены версией MySQL, значит можете использовать сегментацию? Хоть по годам, хоть по месяцам пилите таблицу - физически они будут храниться отдельно, вплоть до расположения на разных дисках, а логически будут выглядеть как единая таблица.