|
Задавайте вопросы, мы ответим
Вы не зашли.
Страниц: 1
Вопрос достаточно общий, но приведу конкретный пример.
Имеется игра, для которой записывается таблица рекордов пользователей, у игры допустим 500 уровней. У каждого уровня своя таблица рекордов, но все результаты пишутся в общую таблицу с указанием поля `level_id`.
При этом на один INSERT или UPDATE приходится десяток SELECT'ов. Вроде бы напрашивается использование кэширования результатов выборки, но, учитывая, что пока случится второй SELECT (кэшированный) для одного уровня, почти наверняка произойдет UPDATE для одного из 499 других, то есть результаты кэширования будут сброшены и его использование не даст никакого эффекта.
В связи с этим возникает вопрос - есть ли смысл разбивать одну общую таблицу на 500 однотипных, чтобы 9 из 10 SELECT'ов отдавались из кэша, или, может, существует какой-либо другой способ решения проблемы?
Неактивен
Имеет смысл перейти на InnoDB. +))
Большая таблица?
Неактивен
Относительно. От 1000 до 2500 записей по каждому уровню, в общей сложности около 1 млн. И продолжает расти.
Я только осваиваю MySQL и реляционные БД в целом, но по-моему вопрос актуален почти в каждом проекте, соответственно цифры могут быть разными.
InnoDB по-моему не имеет отношения к кэшированию, или я ошибаюсь?
Неактивен
Кеширование вам нужно для повышения производительности, верно? +))
Начните с InnoDB, чтоб вся таблица при обновлении не блокировалась, в этом месте часто теряется производительность. Продолжайте с индексами и запросами.
Выше ваш комментарий дает понять, что кеширование с таким частым обновлением не будет работать в пределах одной большой таблицы. Поэтому я бы начал с оптимизации индексов и запросов. Когда там будет достигнут предел, только тогда задумался бы о делении таблицы на части, потому как 1 млн записей не так уж и много. 500 таблиц многовато, я бы поделил на 10. По 50 уровней в каждой.
ЗЫ. Мысль родилась об InnoDB потому, что я в свое время перешел, запросы оптимизировал, над индексами поработал, сегодня о кеше как методе повышения производительности даже не задумываюсь. Где работает — хорошо, где нет — ну и черт с ним. +))
Неактивен
Т.е. я всегда стараюсь делать ставку на быструю отработку запросов. Нежели на кеширование тяжелых и медленных запросов. Ибо всегда этот (медленный, тяжелый) запрос должен отработать, чтобы попасть в кеш.
Неактивен
Александр Трофимов прав. Преждевременная оптимизация - зло, а именно такое впечатление создается из вашего запроса. Тоже кэширование, например, хорошо в первую очередь для тяжелых запросов (с подзапросами, джойнами, группировками и т.д.)
Посмотрите
С чего начинать оптимизацию MySQL?
Кэширование запросов в MySQL
Неактивен
Конечно, любой пост нуба в MySQL вызывает ощущение "преждевременной оптимизации", но в данном случае речь идет о в меру успешной игре, которая УЖЕ вертится на нереляционной базе данных (GAE). Дороговизна сервера (сейчас обходится в 10 долларов в месяц при 1000 уников в сутки) заставила задуматься о переходе на MySQL. И естественно я задумываюсь об оптимизации, чтобы не получилось, что переход приведет к увеличению затрат на сервер.
Неактивен
stahon, начните с правильно выбранного типа таблиц и правильно построенных запросов. Кеш подождет.
Если очень хотите делить таблицу, делите. Просто прироста скорости можете не ощутить.
Неактивен
stahon, Innodb поможет вам тем, что кроме кэша запросов содержит buffer_pool, который кэширует сами данные. Если запрос выполняется по индексу, он буде быстрым, а за счет buffer_pool обойдется без диска. К разбиению таблиц следует прибегать в крайнем случае, так как решая одну проблему, порождает другие.
Неактивен
Страниц: 1
