no_one_safe
@no_one_safe

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

Добрый день.
Хочу посоветоваться с сообществом по следующему вопросу:
Суть:
Есть проект на первом ZendFramework (Думаю, что это не так уж и важно)
Есть таблица в БД вида:
643fcd48188b4df8a265672971672c06.png
Как видно из скриншота таблица имеет следующую структуру:
idPRIMARY 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млн., что было несколько опрометчиво.
  • Вопрос задан
  • 494 просмотра
Решения вопроса 1
Melkij
@Melkij
PostgreSQL DBA, contributor
5,5 лямов записей в год?
За десять лет смешные 55 лямов? Право, какая фигня. Даже для mysql. С чего вы взяли, что это - большие данные? Вот 50 лямов ежедневно - уже можно с натяжкой большими данными назвать.

Две таблицы:
id name и чего ещё надо для самой сущности.
date, entity_id, low, middle, high. Можно партицировать поквартально.
Ответ написан
Пригласить эксперта
Ответы на вопрос 1
sim3x
@sim3x
Не занимайся premature optimization

Для начала хватит хранения в 3НФ
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы