Здравствуйте уважаемые форумчане!
Я бы хотел поинтересоваться, насчёт возможностей Mysql. Провести эксперимент пока трудно. Но позже всё обязательно проверю.

Ситуация такая.
Есть скрипт, который записывает /insert/ в БД Mysql данные каждую секунду.
Данные - 70 двузначных чисел. То есть в БД есть таблица с 71 колонкой - id и 70 колонок под эти числа.

Есть скрипт, который выводит данные по запросу пользователя - эти 70 чисел. Выбрать первую запись /select * from base where id=1/, тридцатую запись и т.д.


Вопрос такой - через какое время лопнет Mysql или накроется сервер? От перегрузки, от переполнения и так далее. А может чем больше размер БД, тем больше ресурсов использует сервер (сам не верю, ну а вдруг)?
Место на диске под БД не ограничено.

Или такая ситуация в принципе невозможна? И вне зависимости от количества записей в БД, её размера - не будет существенного снижения быстродействия?

И ещё вопрос - как будет работать скрипт , который выводит данные по запросу пользователя -/select from base/ если БД огромна и там 10 миллионов записей?

Вот такие вопросы. С огромными БД не работал.
Записей в БД действительности будет около 40 миллионов, а может и больше.

netwind,
В интернете пишут, что обычный лимит у myisam-таблиц 2^32 то есть 4 миллиарда записей. В теории.
И БД в среднем достигает 2ГБ. А максимальный размер 4.

У меня будет 60 записей в минуту -это около 32 миллионов записей в год. В ограничение 4 миллиарда укладываюсь.
Размер базы, исходя из моих данных 140 мб. (не уверен, но должно быть так) В ограничение 4 ГБ укладываюсь.
Я даже близко не подошел к теоретическим ограничениям.

Почему БД или сервер должны стать неработоспособными, существенно замедлить свою работу?

вадя, что вы этим хотели сказать?
Базы данных располагаются на диске. Что мускул, что инно, что оракл.
Базы данных созданы для хранения множества данных и быстрого доступа к ним.
Ваше утверждение не имеет смысла т.к. любая база, ОС, сервис или скрипт, физически размещён на диске.

Спасибо за ответы.
Уточню - данные не удаляются. Нужны данные за прошлый месяц, год. Но можно сделать с ожиданием.
В 90% случаев - выборка select -это смежные значения.

Сейчас вижу такие варианты решения
Вопрос в "маштабе".

1 Вариант
Хранить все данные за год в одной базе. Каждый год создавать новую базу.
1 база, 1 таблица с данными - всего 31 104 000 строк.

2 Вариант
Хранить все данные за год в одной базе. Каждый год создавать новую базу.
Хранить все данные за текущий месяц в одной таблице. Каждый месяц создавать новую таблицу.
1 база, 12 таблиц с данными - всего 31 104 000 строк, в каждой таблице 2 592 000 строк

3 Вариант
Хранить все данные за месяц в одной базе. Каждый месяц создавать новую базу.
1 база, 1 таблица с данными - всего 2 592 000 строк.

4 Вариант
Хранить все данные за месяц в одной базе. Каждый месяц создавать новую базу.
Хранить все данные за текущий день в одной таблице. Каждый день создавать новую таблицу.
1 база, 365 таблиц с данными - всего 2 592 000 строк, в каждой таблице 86 400 строк.

Какой из вариантов лучше?
И в принципе, соседство большой базы (пусть с 40 млн строк и размером 2Гб) с другой базой влияет на работу-быстродействие другой базы?
Если большая база лежит "мёртвым грузом" и к ней нет обращения. А с другой базой идёт работа.

PS
chabapok, вы правы. Но на данном этапе я не могу писать велосипеды.
И насчёт программы вы правы. Но сначала, перед тестами, надо понять какой вариант тестировать. Иначе тесты может не хватить времени.

netwind,
"rrdtools, то обнаружили бы, что там навязывают предагрегацию - данные за прошлый месяц хранятся, но интервал суммируется и хранится уже сумма за каждый день, например." - это что-то сложное.
Погуглил - Цитата из интернета
--
RRD – это кольцевая база данных. Главная особенность данной БД заключается в том, что она всегда имеет фиксированный размер. То есть когда, будет достигнут конец в каком-нибудь поле в такой БД, то данные будут записываться в самое начало, тем самым, затирая предыдущие.
--
Мне нужны все данные. Никакие данные не должны быть стёрты.
Работа в 90% случаев, будет производится с последними данными, записями. Но иногда нужно просмотреть "архив".
Выгружать "архив" в файл по принципу дампа - плохой вариант. Желательно всё хранить в базе.

Пока, я хочу сделать всё проще.
Скорее всего, сделаю по четвёртому варианту

4 Вариант
Хранить все данные за месяц в одной базе. Каждый месяц создавать новую базу.
Хранить все данные за текущий день в одной таблице. Каждый день создавать новую таблицу.
1 база, 365 таблиц с данными - всего 2 592 000 строк, в каждой таблице 86 400 строк.

Зачем усложнять задачу на данном этапе, когда этот вариант не вызовет проблем? Ведь не вызовет? :-)
Для начала мне нужно минимум проблем-глюков, лагов. И простая структура базы.

А когда понадобится что-то большее, специфическое- то я возможно сменю базу.