Доброго дня!
Стоит задача оптимизации хранения истории значений по параметрам объектов.
Т.е. есть таблица объектов(Id, Name), параметров(Id, Name, ObjId), всех значений параметров(Id, ParameterId, ChangeTime, Value) и таблица с текущими(актуальными) значениями (ParameterId, ParameterValueId).
Последняя таблица нужна для быстрого отображения текущих значений.
А вот с выборкой значений за какой-то период беда. Также необходимо строить отчеты, усреднять, анализировать и т.д.
Прирост данных в таблицу со значениями примерно 2 млн строк в неделю. В будущем это значение будет только увеличиваться. сложно прогнозировать до какого значения, но полагаю 2 млн в сутки это реально.

Собственно вопрос: как лучше организовать хранение такого рода данных. СУБД MSSQL Server
Есть следующие идеи:
1. под каждый объект создавать отдельную таблицу и писать значения туда. Число объектов думаю будет порядка 100 000;
2. значения за последние сутки(т.к. в 50% случаях используются именно эти данные) хранить в отдельной таблице;
3. Разбивать данные по месяцам либо даже неделям и хранить их в отдельных таблицах.

Дайте совет у кого был такого рода опыт.

Спасибо.

Доброго дня! Спасибо за внимание к моей задаче.

soulsurferTemporal tables - https://msdn.microsoft.com/en-us/library/dn935015.aspx ?
Интересная вещь, но в чистом виде задачу не решает

DirksDRSelectIgor,

1.этот вариант мне категорически не нравится
2.имхо, это излишне, если 3
3.я отстал от жизни MSSQL, думаю, там должно быть партицирование, например, по месяцам.
Сам не пробовал, есть ли там резервное сохранение отдельных партиций?
А то таблица большая, с бакапами могут быть сложности.

У нас есть АСУ, где каждый день сваливается в отдельную таблицу с именем tYYMMDD, автоматом строятся вьюхи по месяцам - LYYMM.
Мне не сильно нравится, данные для анализа за период приходится выбирать ХП, а внурти ХП динамически формировать запросы.
Объемы много меньше Ваших, поэтому временные характеристики терпимые, до 10 сек месяц.

Почему запросы в хп динамически формируются? Если к примеру сделать партицированную вьюху, то как мне видится оптимизатор сам заставит сервак обращаться к нужным таблицам.

SERG1257buven Здесь сильно пахнет OLAP+1 http://www.sql.ru/forum/olap-dwh

>1. под каждый объект создавать отдельную таблицу и писать значения туда.
Плохо

2 и 3 на самом деле одно и тоже - партиции (секционирование). Если редакция EE то пользоватся встроенным в MS SQL плюс в EE есть другие плюшки в виде columnstore, page compression чтобы уменьшить объем сырых данных
если SE то ваш выбор partitioned views
https://technet.microsoft.com/en-us/library/ms190019(v=sql.105).aspx
Это для хранения сырых данных.

Дальше из вашего EAV надо создать нормальные таблицы для отчетов. Индексные вьюхи скорее всего создать не получится.
Либо поднимайте analysis services.

Имею standart edition. Эксперименты провожу на express.
Решение задачи видится в партицировании по месяцам. Т.к. сервак не EE, то собственно вопрос есть ли хорошие практики по автоматизации всего этого дела.
Решение вижу следующим:
1. Оставляю таблицу с актуальными(текущими) значениями и создаю таблиц на лет 10 вперед с нужными ограничениями по дате(т.е. если таблица за август, то другие данные не вставить), первичный ключ сделать составным (Код параметра, дата);
2. Создать партицированное представление с UNION ALL;
3. Тут вопрос. Что лучше написать хп, которая смотря на дату будет кидать в нужную таблицу(а может быть и создавать таблицу если ее нет и перестраивать вьюху) либо триггер на таблицу с актуальными данными(т.е. после вставки нового значения старое переносить а архив)?
4. Обращение за архивными данными делать через вьюху;

Вроде как-то так. Сейчас еще про olap кубы копаю. Никогда с ними не работал.

Alexander2SelectIgor,

сколько у вас параметров?

Данное значение варьируется от объекта к объекту. Параметров мб много порядка 10 т. на объекте, но интенсивность обновления значений разная.

Спасибо!