Как организовать хранение большого количества данных?

Question

[no_one_safe]

Добрый день.
Хочу посоветоваться с сообществом по следующему вопросу:
Суть:
Есть проект на первом ZendFramework (Думаю, что это не так уж и важно)
Есть таблица в БД вида:

Как видно из скриншота таблица имеет следующую структуру:

id	PRIMARY AUTO_INCREMENT
name	Имя сущности. Может повторяться (у разных id с одинаковыми именами - разные характеристики) - никогда не меняется
low	Некая характеристика - ее нижний показатель - изменяемая величина
middle	Та же характеристика - ее средний показатель - изменяемая величина
high	Та же характеристика - ее высокий показатель - изменяемая величина

Записей в таблице порядка ~30К. Ежегодно добавляются порядка 2000 записей.
Ежедневно у примерно ~15k записей меняются величины low, middle и high.
На сайте страница сущности - это вывод всех сущностей с характеристиками сгруппированными по полю name.

Задача:
Хочется собирать статистику по изменению величин low, middle и high (ежедневное изменение у примерно 15000 записей) как минимум за год и красиво показывать все на графиках на страницах сущностей.
Вопрос:
Какую стратегию хранения данных выбрать?
Очевидные варианты решения:

• MySql - создаем таблицу с id, entity_id, low, middle, high, date - каждый день добавляем туда по 15000 записей. За год -> 5475000 записей. Не очень что то мне это нравится. Или норм?
  
• Файловое хранение - создаем 15000 файлов, где в сериализованном массиве храним данные. Каждый день изменяем все 15000 файлов. Тоже как то костыльно.
  
• Также рассматриваю варианты каким то образом оптимизировать хранение, объединив данные по полю name. Пока ничего путного в голову не пришло.
  

Саму таблицу хранения сущностей менять нельзя (только добавлять поля)
Есть идеи?

UPD:
Всем спасибо за мнения. Остановлюсь все таки на первом варианте с таблицей MySql. Испугался цифры в 5млн., что было несколько опрометчиво.

Comments

[Павел Волынцев]

Первый вариант норм. Просто и быстро.

Answer 1

[Melkij]

5,5 лямов записей в год?
За десять лет смешные 55 лямов? Право, какая фигня. Даже для mysql. С чего вы взяли, что это - большие данные? Вот 50 лямов ежедневно - уже можно с натяжкой большими данными назвать.

Две таблицы:
id name и чего ещё надо для самой сущности.
date, entity_id, low, middle, high. Можно партицировать поквартально.

Comments

[no_one_safe]

За десять лет смешные 55 лямов? Право, какая фигня. Даже для mysql. С чего вы взяли, что это - большие данные? Вот 50 лямов ежедневно - уже можно с натяжкой большими данными назвать.

Да, возможно я слишком испугался данной цифры. Вы, скорее всего, правы.

Answer 2

[sim3x]

Не занимайся premature optimization

Для начала хватит хранения в 3НФ