Вы точно не говорите, насколько большие таблицы, какие они таблицы, как они заполняются и как они используются.Итак, я просто собираюсь дать несколько случайных мыслей:)
Когда вы сообщаете о больших объемах данных, вы в основном ограничены скоростью вашей дисковой системы, то есть с какой скоростью ваши диски доставляютданные в MySQL.Этот показатель обычно измеряется в мегабайтах / секунду.Таким образом, если вы можете получить 100 МБ / с, то вы не сможете выполнить select sum () или count (*) для таблицы, превышающей 100 МБ, если вы хотите получить время отклика менее секунды (на мгновение полностью игнорируя кэш БД).Обратите внимание, что 100 МБ - это что-то вроде 20 миллионов записей с размером строки 50 байтов.
Это работает до определенного момента, и тогда все просто умирает.Обычно, когда размер базы данных становится больше доступной памяти, а количество одновременно работающих пользователей увеличивается.
Вам может потребоваться изучить возможность создания сводных таблиц , чтобы можно было уменьшитьколичество мегабайт, которое вам нужно просмотреть.Это лучше всего объяснить на примере.Предположим, что ваша текущая таблица показателей выглядит примерно так:
measures(
user_id
,timestamp
,action
)
Для каждого выполненного действия (вход в систему, выход из системы, нажатие на это, пердение, нажатие на это) вы сохраняете идентификатор пользователя и отметку временикогда это произошло.
Если вы хотите построить ежедневный номер входа в систему с начала года, вам придется выполнить подсчет (*) для всех 100 000 000 миллионов строк и сгруппировать по day(timestamp).
Вместо этого вы можете предоставить предварительно рассчитанную таблицу, такую как:
daily_actions(
day
,action
,occured
,primary key(day, action)
)
Эта таблица обычно загружается с чем-то вроде:
select day(timestamp)
,action
,count(*)
from measures
group
by day(timestamp)
,action
Если бы у вас было 100 возможныхдействия, вам нужно всего 36 500 строк для хранения действий за весь год.Пользователи, использующие статистику, графики, отчеты и другие данные, не будут тяжелее ваших типичных транзакций OLTP.Конечно, вы также можете хранить его ежечасно (или вместо этого) и получать 876 000 строк в год.Вы также можете сообщать о недельных, месячных, временных или годовых показателях, используя приведенную выше таблицу.ЕСЛИ вы можете сгруппировать свои пользовательские действия по категориям действий, например, «Весело», «Не так весело», потенциально вредно »и« Неверно », вы можете уменьшить объем хранилища с 100 возможных действий до 4.
Очевидно, что ваши данные более сложны, чем эти, но вы почти всегда можете найти подходящее количество агрегированных таблиц, которые могут ответить практически на любой вопрос на высоком уровне агрегации., вы можете использовать все эти фильтры, и тогда вы можете обнаружить, что очень возможно выбрать из таблицы с наименьшей детализацией, используя определенный date и определенный action.