|
Задавайте вопросы, мы ответим
Вы не зашли.
Здравствуйте.
На кластерной площадке наших серверов участились перебои со светом. Данные в базе стали повреждаться и нам их нужно восстанавливать. Тип MyISAM после нескольких повреждений стал менять значения у данных. Допустим, пользователь был на сайте 10 раз, а ему 10 заменилось на 100 и т.д.
Неполадки с электричеством мы пока решить не можем и поэтому рели перейти на более надёжный тип данных. InnoDB.
Да конечно надёжность - это хорошо, но и скорость тоже важна. Наша сервис обрабатывает 169 запросов в секунду. Возможно не много. Но и не мало. Большинство обновление и удаление - (70%).
Вот и у меня вопросы стоит ли переходить на этот тип? Нельзя ли работать с несколькими типами в одной базе? И не будет ли при этом проблем, если я буду подключать MyISAM LEFT JOIN InnoDB и обратно.
И ещё я в нескольких местах использую fulltext, а в innodb его нет. Не будет ли это накладно для системы, если индекса теперь не будет.
Неактивен
Здравствуйте.
InnoDB будет работать с большим количеством изменений даже лучше, чем MyISAM. В одной базе
можно держать таблички разных типов, это очень часто используемая практика. С JOIN проблем
быть не должно.
Единственная реальная проблема - полнотекстовый индекс. Если захотите переносить полнотекстовую
табличку на InnoDB, можете попробовать разбить старую табличку на две, во второй оставить только
id и полнотекстовое поле. При поиске, соответственно, находить нужные id по полнотекстовому
ключу, а дальше уже из первой таблички JOINить остальные данные.
Неактивен
Ну, тогда я даже сделаю проще. Из той таблички, в которой fulltext обычно только выборка данных происходит. Поэтому она останется MyISAM, а несколько важных табличек я сделаю InnoDB.
А еще, допустим, есть лог действий пользователей. Большой очень. Сейчас 16 000 000 записей. Или чуть больше.
Короче в лог обычно происходит запись и потом из него обычно происходит выборки типа:
SELECT COUNT(*) AS count
FROM log
WHERE date = 'Время в формате UNIX'
AND id = 'ID пользователя'
AND ip = 'IP'
Данные (сколько раз пользователь был сегодня) потом обрабатываются для построения другой статистики. Это было нужно, чтобы разделить нагрузку, т.е. есть общий лог и более сгруппированные данные по определённому интервалу и выборка последних работает быстрее.
Вопрос будет ли InnoDB обрабатывать запрос быстрее при таких объёмах данных.
Уточню, что для лога используются общие ключи и запрос, который я привёл выше построен оптимально, но будет ли он хорош в InnoDB не уверен.
Да можно конечно изменить тип и посмотреть, но я думаю тут понимают, что 16 000 000 очень долго перегонять из одного в другой. И я полагаюсь в своих вопросах на опыт в подобных ситуациях.
Неактивен
Очень длинные таблички имеет смысл разделять на несколько, т.к. вставка в очень длинную
табличку занимает солидное время при любом типе таблиц (т.к. нужно сортировать индексы).
Бить логовую таблицу проще всего по дате (т.к. в логовые таблицы никогда не вставляются
записи "задним числом").
InnoDB очень критично относится к основному индексу (Primary Key), так что подумайте над тем,
чтобы сделать его как можно более коротким.
Неактивен
Побил пару больших табличек и действительно стало быстрее работать. В пиковое время даже запросов стало больше обрабатывать.
Большое спасибо.
Отредактированно tema (02.08.2008 13:38:31)
Неактивен
