Как правильно сделать структуру большой БД?

Доброго времени,

Столкнулся с такой задачей, нужно сделать большую базу данных для маркетологов.

Задача следующая:
В БД будут добавляться магазины, к каждому магазину будет добавляться список товаров (до 1000 товаров). Далее 1 раз в неделю для каждого товара будет загружаться цифра (кол-во продаж за эту неделю). И это все нужно хранить в БД.

Потом в админке, показывать статистику продаж, по неделям/месяца. То есть в момент загрузки кол-ва продаж для товара, нужно будет еще и дату привязывать, чтобы потом по неделям/месяцам можно было делать выборку из БД.

ВОПРОС: как правильно организовать структуру БД и в каком формате хранить данные, при условии что она каждую неделю будет увеличиваться.

Например:
добавили 10 магазинов, к каждому магазину добавили по 1000 товара, это 10.000 товара. Каждую неделю для 10.000 товара будут загружать отчет, кол-во продаж, то есть каждую неделю БД будет увеличиваться на 10.000 записей, и через 3 месяца в БД будет 120.000 записей. И так далее каждый месяц она будет расти.

Раз в неделю (~52 раза в год) плюсовать 1000 позиций с 10 магазинов. Через 10 лет работы 5 лямов записей.
Это копейки даже для тупого mysql. Даже в плоской таблицей. Даже сейчас, а не через 10 лет.
Добавить партицирование, по годам или кварталам. Плюс предварительно рассчитанные данные агрегирования, для быстрой выдачи наиболее востребованных данных в админке.

А уж если возьмёте полновесный postresql - то хоть каждый день пишите по 5 лямов записей.
Что там в этой табличке надо? Идентификатор магазина - smallint наверняка хватит. Ну ладно, возьмём int. Товар - int'а более чем достаточно. Количество проданного за неделю - int наверняка тоже хватит. Плюс date 4 байта. Итого 5 лямов записей в сыром виде займут 76,3мб. В темпе записи даже ежедневно на протяжении 10 лет - меньше 300гб сырых данных. Ничего выдающегося.

Сгенерируйте себе на локальной машине базу с данными размером хотя бы с 50 лямов записей, да поиграйтесь. Это весело и за пару дней быстро изменяет отношение к вопросу "ахах, через 3 месяца будет уже 120000 записей, что делать, что делать?"

-----
PostgreSQL DBA