Какую же подсистему хранения выбрать? 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.