Большие объемы данных

#data_structures #sql #mysql #база_данных

Необходимо предоставить пользователям доступ к записям некоторой таблицы. 
В таблице имеется 11 столбцов, каждый из которых является некоторым идентификатором
записи в другой таблице. 
В день кол-во записей в данной таблице увеличивается на 30 миллионов записей.
Пользователям необходимо знать кол-во событий, подходящих под заданный ими набор
фильтров.
Скорость выполнения запроса допустима в пределах 1 - 3 секунд.
Всего около 5 пользователей.
Как оптимизировать работу таблицы?
Возможно, необходимо построить правильные индексы, но это все же не спасает. 
Возможно, стоит просчитывать кол-во записей, которые попадают под каждый из всевозможных
фильтров. Но тогда кол-во записей возрастет во много раз.
Возможно, есть другие варианты?    

Ответы

Ответ 1

30 миллионов - это много. Даже на самых хороших индексах это будет медленно. В этих
случаях используют предвычисления. 
К примеру, собирал статистику каждый час в отдельную таблицу(таблицы). В этом случае
можно будет очень быстро с дополнительной таблицы получить данные, а остаток за последний
час выбрать с основной таблицы.
Но делать постоянные выборки - это неверно. Особенно в высоконагруженных проектах.
В этих случаях берут какой нибудь MQ (message Queue, например, RabbitMQ)  и данные
льются в него одним потоком. А другой сервер вычитывает и обновляет счетчики. В этом
случае можно будет сделать даже realtime отображение статистики. Если счетчиков много,
то серверов обработки может быть много.
Понятно, что на все фильтры заранее не наготовишь счетчиков, но если подойти грамотно,
то большинство задач можно покрыть. А вот редкие специфические запросы можно уже и
с базы аккуратно вытянуть (я думаю, пользователи с этим смирятся).


Ответ 2

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