SQLinfo.ru - Все о MySQL

Форум пользователей MySQL

Задавайте вопросы, мы ответим

Вы не зашли.

#1 22.03.2015 23:49:37

stahon
Участник
Зарегистрирован: 22.03.2015
Сообщений: 4

Разбивка таблицы для оптимизации кэширования

Вопрос достаточно общий, но приведу конкретный пример.
Имеется игра, для которой записывается таблица рекордов пользователей, у игры допустим 500 уровней. У каждого уровня своя таблица рекордов, но все результаты пишутся в общую таблицу с указанием поля `level_id`.
При этом на один INSERT или UPDATE приходится десяток SELECT'ов. Вроде бы напрашивается использование кэширования результатов выборки, но, учитывая, что пока случится второй SELECT (кэшированный) для одного уровня, почти наверняка произойдет UPDATE для одного из 499 других, то есть результаты кэширования будут сброшены и его использование не даст никакого эффекта.
В связи с этим возникает вопрос - есть ли смысл разбивать одну общую таблицу на 500 однотипных, чтобы 9 из 10 SELECT'ов отдавались из кэша, или, может, существует какой-либо другой способ решения проблемы?

Неактивен

 

#2 23.03.2015 00:00:37

Александр Трофимов
Завсегдатай
Откуда: Юрмала
Зарегистрирован: 19.09.2011
Сообщений: 95

Re: Разбивка таблицы для оптимизации кэширования

Имеет смысл перейти на InnoDB. +))

Большая таблица?

Неактивен

 

#3 23.03.2015 00:14:49

stahon
Участник
Зарегистрирован: 22.03.2015
Сообщений: 4

Re: Разбивка таблицы для оптимизации кэширования

Относительно. От 1000 до 2500 записей по каждому уровню, в общей сложности около 1 млн. И продолжает расти.
Я только осваиваю MySQL и реляционные БД в целом, но по-моему вопрос актуален почти в каждом проекте, соответственно цифры могут быть разными.
InnoDB по-моему не имеет отношения к кэшированию, или я ошибаюсь?

Неактивен

 

#4 23.03.2015 00:48:05

Александр Трофимов
Завсегдатай
Откуда: Юрмала
Зарегистрирован: 19.09.2011
Сообщений: 95

Re: Разбивка таблицы для оптимизации кэширования

Кеширование вам нужно для повышения производительности, верно? +))

Начните с InnoDB, чтоб вся таблица при обновлении не блокировалась, в этом месте часто теряется производительность. Продолжайте с индексами и запросами.

Выше ваш комментарий дает понять, что кеширование с таким частым обновлением не будет работать в пределах одной большой таблицы. Поэтому я бы начал с оптимизации индексов и запросов. Когда там будет достигнут предел, только тогда задумался бы о делении таблицы на части, потому как 1 млн записей не так уж и много. 500 таблиц многовато, я бы поделил на 10. По 50 уровней в каждой.

ЗЫ. Мысль родилась об InnoDB потому, что я в свое время перешел, запросы оптимизировал, над индексами поработал, сегодня о кеше как методе повышения производительности даже не задумываюсь. Где работает — хорошо, где нет — ну и черт с ним. +))

Неактивен

 

#5 23.03.2015 00:50:25

Александр Трофимов
Завсегдатай
Откуда: Юрмала
Зарегистрирован: 19.09.2011
Сообщений: 95

Re: Разбивка таблицы для оптимизации кэширования

Т.е. я всегда стараюсь делать ставку на быструю отработку запросов. Нежели на кеширование тяжелых и медленных запросов. Ибо всегда этот (медленный, тяжелый) запрос должен отработать, чтобы попасть в кеш.

Неактивен

 

#6 23.03.2015 11:18:00

vasya
Архат
MySQL Authorized Developer
Откуда: Орел
Зарегистрирован: 07.03.2007
Сообщений: 5827

Re: Разбивка таблицы для оптимизации кэширования

Александр Трофимов прав. Преждевременная оптимизация - зло, а именно такое впечатление создается из вашего запроса. Тоже кэширование, например, хорошо в первую очередь для тяжелых запросов (с подзапросами, джойнами, группировками и т.д.)
Посмотрите
С чего начинать оптимизацию MySQL?
Кэширование запросов в MySQL

Неактивен

 

#7 23.03.2015 15:24:06

stahon
Участник
Зарегистрирован: 22.03.2015
Сообщений: 4

Re: Разбивка таблицы для оптимизации кэширования

Конечно, любой пост нуба в MySQL вызывает ощущение "преждевременной оптимизации", но в данном случае речь идет о в меру успешной игре, которая УЖЕ вертится на нереляционной базе данных (GAE). Дороговизна сервера (сейчас обходится в 10 долларов в месяц при 1000 уников в сутки) заставила задуматься о переходе на MySQL. И естественно я задумываюсь об оптимизации, чтобы не получилось, что переход приведет к увеличению затрат на сервер.

Неактивен

 

#8 23.03.2015 15:37:15

Александр Трофимов
Завсегдатай
Откуда: Юрмала
Зарегистрирован: 19.09.2011
Сообщений: 95

Re: Разбивка таблицы для оптимизации кэширования

stahon, начните с правильно выбранного типа таблиц и правильно построенных запросов. Кеш подождет.
Если очень хотите делить таблицу, делите. Просто прироста скорости можете не ощутить.

Неактивен

 

#9 23.03.2015 16:12:18

rgbeast
Администратор
MySQL Authorized Developer and DBA
Откуда: Москва
Зарегистрирован: 21.01.2007
Сообщений: 3878

Re: Разбивка таблицы для оптимизации кэширования

stahon, Innodb поможет вам тем, что кроме кэша запросов содержит buffer_pool, который кэширует сами данные. Если запрос выполняется по индексу, он буде  быстрым, а за счет buffer_pool обойдется без диска. К разбиению таблиц следует прибегать в крайнем случае, так как решая одну проблему, порождает другие.

Неактивен

 

Board footer

Работает на PunBB
© Copyright 2002–2008 Rickard Andersson