Как безопаснее использовать таблицы MyISAM?

Question

Мне нравится безопасность, согласованность и самоконтроль InnoDB.

Но мне нужна скорость и легкий вес MyISAM.

Как я могу сделать MyISAM менее подверженным повреждению из-за сбоев, неверных данных и т. Д.? Для проверки требуется вечность (CHECK TABLE или myisamchk).

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

ОБНОВЛЕНИЕ: Я не спрашиваю, как быстрее загрузить данные в таблицы. Я уже ударился об это и решил, что использование таблиц MyISAM для моих данных LOAD DATA просто намного быстрее. То, что я сейчас ищу, это снижение рисков использования таблиц MyISAM. То есть уменьшая шансы на урон, увеличивая скорость восстановления.

Answer 1

Предполагаемые преимущества MyISAM в скорости могут быстро исчезнуть - тот факт, что в нем отсутствует блокировка на уровне строк, означает, что небольшие обновления могут привести к блокировке больших объемов данных и блокированию запросов. Из-за этого я скептически отношусь к заявленным преимуществам MyISAM по скорости: начните выполнять несколько ОБНОВЛЕНИЙ, и количество запросов в секунду будет уменьшаться.

Думаю, вам лучше спросить: «Как сделать приложения с InnoDB быстрее?» и тогда ответ касается данных кэширования, возможно, на уровне объектов, в облегченных кэшах - для ACID существует определенная плата, а для, скажем, веб-приложений она на самом деле не нужна.

Если ОБНОВЛЕНИЯ редки (если это не так, MyISAM не является хорошим выбором), то вы даже можете использовать кеш запросов MySQL.

memcached (http://www.danga.com/memcached/) - очень популярная опция для кеширования объектов. В зависимости от вашего приложения у вас есть и другие опции (HTTP-кеши и т. Д.)

Answer 2

Хотя я согласен с комментариями innodb, я дам решение вашей проблемы с MyISAM.

Хорошим способом предотвращения коррупции и увеличения скорости было бы использование MERGE таблиц

Вы можете использовать 2 или более файлов MyISAM. Одна обычно предназначена для резервного копирования старых данных, которые используются не так часто, а другая - более новые данные. Тогда у вас будет 2 FRM (файлы таблиц MyISAM) на жестком диске, и один будет защищен. Обычно вы сжимаете старые таблицы MyISAM, и тогда они демонстративно не будут повреждены, поскольку они становятся доступными только для чтения.

Этот метод обычно используется для ускорения больших таблиц MyISAM, но вы можете применить его и здесь.

Надеюсь, это помогло вашему вопросу. Хотя я понимаю, что на самом деле MyISAM не защищает от сбоев, он действительно обеспечивает достаточную защиту.

Answer 3

в обычной практике не должно быть коррупции. если вы получаете повреждение, вам нужно посмотреть на такие вещи, как плохая память, плохой жесткий диск, плохой контроллер диска или, возможно, ошибка MySQL.

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

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

Answer 4

Преимущества MyISAM по производительности в некоторых случаях довольно минимальны; вам нужно сравнить свои собственные приложения MyISAM против InnoDB. Использование транзакционного механизма InnoDB также дает и другие преимущества.

В моем тестировании InnoDB будет занимать, как правило, примерно на 150% больше дискового пространства, чем MyISAM - это связано с его блочной структурой и отсутствием сжатия индекса.

Если вы можете себе это позволить, просто используйте InnoDB.

Что касается ответа на ваш фактический вопрос: если вы разбиваете свою таблицу на несколько таблиц MyISAM, объем восстановления, необходимый в случае сбоя, будет намного меньше; если ваши данные большие, это может быть хорошей идеей в любом случае по другим причинам.

Answer 5

Получите хороший ИБП с приличным питанием. Запуск на стабильном и резервном оборудовании.

Я не доверяю таблицам MyISAM, чтобы они когда-либо переживали сбой во время записи, поэтому я думаю, что ваш лучший выбор - уменьшить количество сбоев (и записей).

Answer 6

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

Однажды вы можете сделать запись в копию таблицы InnoDB, а затем скопировать ее в копию MyISAM. Преимущества MyISAM по производительности в основном ориентированы на чтение.

Разумеется, при репликации у вас будет задержка между чтением и записью

Answer 7

Ваш комментарий:

Нет, главная проблема заключается в удивительно начальный импорт данных на диск в стол. MyISAM время: 12 минут. Время InnoDB: 3+ часа. После моего начальная загрузка, ОБНОВЛЕНИЯ отсутствуют и вставки редки. Не известно Решение InnoDB разочаровывает операция загрузки.

предлагает удалить ограничения и индексы, а затем включить / перестроить их после загрузки, может значительно ускорить ее - я полагаю, вы пробовали это? Это улучшило ситуацию?

Answer 8

Вы женаты на MySQL? Postgres совместим с ACID (например, innoDB) и (при правильной настройке) почти такой же быстрый, как MyISAM.