которые при генерации отчета как либо аггрегируются.
это чуть ли не наисложнейшая задача для баз данных, 80м записей тем более
Партицируйте прямо по суткам.
Убирайте транзакции,
нафиг вам тут innodb когда хватит myisam, оно на запись быстрее, у вас база write once read ... тоже once.
У вас там база данных упирается случайно не в работу с диском? в облаке можно взять несколько дисков, они будут независимыми, раскидай по ним таблицы (myisam штатно поддерживает симлинки), что может дать прирост в скорости в разы только за счет этого, даже если они ssd, например
отделить хранение индексов от данных или отделить старые данные от сегодняшних.
На время обработки аналитики можно потюнить файловую
систему и отключить flush для файлов таблиц (например ext4 data writeback и можно отключить журнал) - сильно ускоряет именно запись, особенно если много ram, это включает большой риск потери/порчи данных при сбросе ос но с другой стороны вероятность этого очень мала и как я понимаю, данные в базу и так пишутся из какого то другого хранилища, т.е. при проблеме с сервером просто перезапускается обработка за текущие сутки.
Уберите индексы на запись, все, сначала пусть идет вставка данных без их индексации, затем создаете индекс (это на порядок быстрее) и уже потом строите аналитику.
Общая аналитика должна не работать с самими данными, а с их посуточной выжимкой (возможно в результате и хранить их не придется) считай это самодельные индексы. Грубо говоря если в запросе на аналитику стоит count,max,min,.. то достаточно сложить посуточные значения и для глобальных считать уже по ним... само собой если запросы с условиями и сложными группировками, то надо думать но все решаемо.. грубый пример нужно считать агрегацию по часам, вот в индексы и пиши суточные значения по часам, а если надо постранично то для каждой страницы для каждых суток считаешь, потом агрегируешь уже по этим результатам.
Средний
Средний
