MySQL: выбор подходящей подсистемы хранения (InnoDB, MyISAM и др.)

Выбор подсистемы хранения для базы данных MySQLКакую же подсистему хранения выбрать? InnoDB редко подводит, и мы очень рады, что компания Oracle сделала ее подсистемой по умолчанию в версии MySQL 5.5. Принятие решения о том, какую подсистему хранения применять, можно свести к фразе: «Используйте InnoDB, пока вам не понадобится какая-то функция, которую она не предоставляет и для которой нет хорошего альтернативного решения». Напри­мер, когда нужен полнотекстовый поиск, мы обычно используем InnoDB в сочетании со Sphinx, вместо того чтобы выбрать MyISAM с ее возможностью полнотекстового индексирования.


Оглавление статьи[Показать]


Мы задействуем что-то отличное от InnoDB, когда нам не нужны функции InnoDB, а другая подсистема хранения обеспечивает существенные преиму­щества при отсутствии недостатков. Например, мы можем использовать MyISAM, когда нам не мешают ее ограниченная масштабируемость, слабая поддержка кон­курентного доступа и отсутствие устойчивости к сбоям, а настоящей проблемой становится значительное потребление пространства подсистемой InnoDB.

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

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

  • Транзакции. Если приложение нуждается в транзакциях, то наиболее стабильной, хорошо интегрированной, проверенной подсистемой хранения для него станет InnoDB (или XtraDB). MyISAM может стать хорошим вариантом, если задача не требует транзакций и в основном предъявляет запросы типа SELECT или INSERT. Иногда в эту категорию попадают отдельные компоненты приложения, например ведение журнала.
  • Резервное копирование. Необходимость регулярно выполнять резервное копиро­вание также может повлиять на ваш выбор. Если есть возможность периодически останавливать работу сервера для выполнения этой процедуры, то подойдет лю­бая подсистема хранения данных. Однако если требуется осуществлять резервное копирование без остановки сервера, то нужна InnoDB.
  • Восстановление после сбоя. Если объем данных велик, то вы должны серьезно оценить количество времени, которое займет восстановление базы после сбоя. Таблицы MyISAM легче получают повреждения и требуют значительно больше времени для восстановления, чем таблицы InnoDB. Это одна из самых важных причин, по которой многие используют подсистему InnoDB, даже не нуждаясь в транзакциях.
  • Специальные возможности. Наконец, может оказаться, что приложению требуют­ся конкретные возможности или оптимизации, которые могут обеспечить лишь отдельные подсистемы хранения MySQL. Например, многие приложения ис­пользуют оптимизацию кластерных индексов. В то же время только MyISAM под­держивает геопространственный поиск. Если подсистема хранения соответствует одному или нескольким важнейшим требованиям, но не соответствует другим, то нужно либо найти компромисс, либо выбрать разумное проектное решение. Часто вы можете получить то, что нужно, от подсистемы хранения, которая на первый взгляд не соответствует вашим требованиям.

Нет необходимости принимать решение прямо сейчас. Далее в моем блоге вы найдете множество материалов, касающихся сильных и слабых сторон каждой подсистемы хранения, а также немало советов по архитектуре и проектированию. В общем, возможностей, вероятно, значительно больше, чем вы пока способны представить, а дальнейшее чтение поможет вам сделать оптимальный выбор. Если вы сомневае­тесь, просто смотрите в сторону InnoDB. Она безопасна по умолчанию, и нет причин выбирать что-то иное, если вы еще четко не знаете, что вам нужно.

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

 

Журналирование

Предположим, вы хотите использовать MySQL для ведения в режиме реального времени журнала всех телефонных звонков, поступивших с центрального телефонного коммутатора. Или, возможно, вы установили утилиту modlogsql для Apache и теперь можете хранить сведения обо всех посещениях сайта прямо в таблице. В та­ких приложениях, вероятно, самым важным является обеспечение быстродействия.

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

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

Например, можно использовать встроенную функцию репликации MySQL для дублирования данных на второй сервер, где затем будут запущены запросы, активно потребляющие ресурсы центрального процессора (ЦП). Таким образом, главный сервер останется свободным для вставки записей и вы сможете делать любые за­просы, не беспокоясь о том, как создание отчета повлияет на ведение журнала в реальном времени.

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

Другой вариант — вести журнал в таблице, имя которой составлено из года и на­звания или номера месяца, например web_logs_2008_01 или web_logs_2008_jan. Если вы будете адресовать запросы к таблицам, в которые уже не производится запись, то приложение сможет непрерывно сохранять новые данные журнала в текущую таблицу.

 

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

Таблицы с данными, которые используются для создания каталога или списка (вакансии, аукционы, недвижимость и т. п.), обычно характеризуются тем, что считывание из них происходит значительно чаще, чем запись в них. С такими таблицами хорошо применять MyISAM — если не думать о том, что происходит при ее сбое. Но не стоит недооценивать важность этого фактора. Многие пользователи не понимают, как рискованно применять подсистему хранения, которая даже не пытается извлечь данные, записанные на диск. (MyISAM просто записывает данные в память и пред­полагает, что операционная система сбросит их на диск позже.)

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

Не стоит слепо доверять народной мудрости сообщества, которая гласит: «MyISAM быстрее, чем InnoDB». Категоричность этого утверждения спорна. Мы можем пере­числить десятки ситуаций, когда InnoDB на голову опережает MyISAM, особенно в приложениях, где применяются кластерные индексы или данные целиком разме­щаются в памяти. По мере дальнейшего чтения вы начнете понимать, какие факторы влияют на производительность подсистемы хранения (размер данных, требуемое количество операций ввода/вывода, первичные ключи и вторичные индексы и т. п.) и какие из них более значимы в вашем приложении.

Проектируя подобные системы, мы используем InnoDB. Сначала MyISAM может произвести впечатление хорошо работающей подсистемы, но при большой нагруз­ке она просто рухнет. Все будет заблокировано, и при сбое сервера вы потеряете данные.

 

Обработка заказов

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

 

Доски объявлений и дискуссионные форумы

Тематические дискуссии являются интересной задачей для пользователей MySQL. Существуют сотни бесплатных систем на основе языков РНР и Perl, которые позволяют организовывать тематические дискуссии. Многие из них не умеют эффек­тивно использовать базу данных, в результате чего для каждого обслуживаемого обращения в них запускается множество запросов. Некоторые из них разработаны, чтобы обеспечить независимость от используемой базы данных, поэтому их запросы не извлекают должной выгоды из возможностей конкретной СУБД. Подобные системы также зачастую обновляют счетчики и собирают статистику по различным дискуссиям. Большинство из них использует для хранения всего объема данных лишь несколько монолитных таблиц. В результате несколько основных таблиц оказываются перегруженными операциями записи и чтения, и возникает значи­тельная конкуренция блокировок, необходимых для обеспечения целостности данных.

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

Эти пользователи не учитывают, что приложение запускает довольно специфические запросы, например, вот такого вида:

mysql> SELECT COUNT(*) FROM table;

Проблема заключается в том, что не все подсистемы хранения могут быстро выпол­нить подобные запросы: MyISAM на это способна, а другие — не всегда.

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

 

Приложения на CD

Если вам когда-нибудь потребуется распространять приложения, использующие файлы данных MySQL, на CD или DVD, подумайте о применении таблиц типа MyISAM или сжатых таблиц MyISAM, которые можно легко изолировать и скопи­ровать на другой носитель. Сжатые таблицы MyISAM занимают значительно меньше места, чем несжатые, но они предназначены только для чтения. В некоторых прило­жениях это может стать проблемой, но, поскольку данные все равно предназначены для записи на носитель, поддерживающий только чтение, нет оснований избегать использования сжатых таблиц для этой конкретной задачи.

 

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

Слишком много — это сколько? Мы проектировали (и управляли) — или помогали проектировать (и управлять) — множество баз данных размером от 3 до 5 Тбайт или даже больше, работавших с подсистемой InnoDB. И это на одном сервере, без сегментирования. Это вполне осуществимо, но нужно с умом подойти к выбору обо­рудования, а также запланировать для сервера возможность справляться с большим объемом операций ввода/вывода. При таких размерах крах MyISAM становится настоящей катастрофой.

Если вы предусматриваете значительный размер базы данных, например десятки терабайт, то, вероятно, проектируете хранилище данных. В этом случае подсистема хранения Infobright будет лучшим выбором. Очень большие базы данных, для которых не подходит Infobright, вероятно, могут использовать TokuDB.

 

Вас заинтересует / Intresting for you:

InnoDB: подсистема хранения ба...
InnoDB: подсистема хранения ба... 2592 просмотров Ирина Светлова Mon, 07 Jan 2019, 06:34:07
MyISAM: подсистема хранения ба...
MyISAM: подсистема хранения ба... 1221 просмотров Ирина Светлова Mon, 07 Jan 2019, 13:15:48
Модель развития базы данных My...
Модель развития базы данных My... 790 просмотров Ирина Светлова Thu, 10 Jan 2019, 12:29:03
Обзор версий MySQL - какой рел...
Обзор версий MySQL - какой рел... 4965 просмотров Ирина Светлова Fri, 05 Feb 2021, 17:19:41
Войдите чтобы комментировать