MySQL: радости и горести - 2

Чуть раньше мы поговорили о том, как все плохо и непродуманно в MySQL (читаем по ссылке первую часть). Но если все так плохо, то почему же эта СУБД пользуется такой популярностью? Ведь не только из-за своей бесплатности? Разумеется, не только. Ведь при всех недостатках мы имеем СУБД, умеющую обрабатывать SQL-запросы, что само по себе уже не мало.

Добавим к этому поддержку (с оговорками) трансакций, поддержку нескольких баз данных (табличных пространств) одновременно, разграничение прав доступа, возможность создания и использования индексов, а также блокировку (для таблиц типа BDB и InnoDB), что позволяет разрабатывать системы, корректно работающие в многопользовательском режиме. Производительность MySQL позволяет рассматривать систему как вполне конкурентоспособный продукт.

Что у нас хорошего?

Мне встречалось множество различных результатов сравнительного тестирования СУБД. По одним из них MySQL работает быстрее, чем тот же MS SQL Server, по другим — медленнее, и такой разнобой понятен: сравнение проводилось в разных условиях, с использованием разных ОС, драйверов, аппаратных средств и т. д. Поэтому я не хотел бы делать однозначных выводов. На мой взгляд, производительность MySQL вполне сравнима с производительностью ее основных конкурентов.

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

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

Некоммерческий характер разработки

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

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

Чтобы не быть голословным, приведу основные характеристики этих типов.

Итак, типы таблиц ISAM, HEAP и MyISAM являются базовыми, их поддержка обеспечивается независимо от того, с какими опциями был скомпилирован сервер.

Ни один из этих трех видов не поддерживает трансакции. Тем не менее при работе с ними можно употреблять предложения BEGIN TRANSACTION, ROLLBACK и COMMIT. Только не стоит при этом забывать, что никаких действий со стороны сервера эти магические слова не вызовут, и тыква в карету не превратится. С другой стороны, использование этих типов таблиц требует меньшего дискового пространства, меньшего объема оперативной памяти для управления и обеспечивает более высокую скорость работы.

Как я уже отмечал выше, MyISAM — это тип таблиц, используемый по умолчанию. Он обеспечивает хранение информации в машинно-независимом формате, что позволяет легко портировать таблицы между, скажем, серверами на платформах Intel и Sparc.

Другой тип таблиц — ISAM — считается морально устаревшим. По возможностям он очень схож с типом MyISAM, однако данные в этих таблицах хранятся в машинно-зависимом формате, что делает невозможным их перенос на другую платформу, а объем хранимых в таблице данных имеет ограничение в 4 Гбайт.

Таблицы типа HEAP во время работы хранятся в памяти. Понятно, что производительность при работе с ними максимальна, а вот надежность — минимальна.

А вот такие типы таблиц, как MERGE, InnoDB и BDB, поддерживаются лишь в том случае, если сервер скомпилирован с соответствующими опциями.

Строго говоря, MERGE — это не особый тип, а объединение нескольких таблиц типа MylSAM, работа с которым происходит как с одной таблицей. Трансакций это объединение, соответственно, тоже не поддерживает. Он применяется, например, при необходимости разнесения данных по нескольким дискам, что может повысить как производительность, так и надежность. При этом, однако, приходится жертвовать такими радостями, как автоинкремент (что не очень страшно), и возможностью удалять данные из таблиц (что меня, например, напугало, несмотря на то, что UPDATE все же поддерживается).

Приложение MySQL Front — профессионально выполненная программа, позволяющая производить все необходимые операции с базой данных

Наконец, типы InnoDB и BDB (Berkley DB) поддерживают трансакции. При этом тип InnoDB обеспечивает блокировку таблиц на уровне записи, а BDB — на уровне страниц.

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

Среди положительных моментов хотелось бы особенно отметить многоплатформенность системы. На сегодняшний день существуют версии MySQL для Linux, Solaris, FreeBSD, Windows, MacOS, HP-UX, AIX, SCO, Irix, Dec OSF, BSDi. Выбор, прямо скажем, неплохой. В том случае, если ваша задача — создание информационной основы для максимально переносимого продукта, становится трудно рекомендовать что-то другое.

Где это работает

Ну а теперь, имея перечень достоинств и недостатков, можно очертить примерную зону применения продукта. Я не имею в виду те случаи, когда основным критерием выбора становится такой фактор, как мнение заказчика. Если заказчик боготворит MS Access и файлы MDB, это его право. Если же заказчик не против выслушать ваши предложения, то приведенная ниже информация поможет не ударить лицом в грязь.

Итак, для каких задач я бы мог рекомендовать MySQL. В первую очередь там, где потеря информации или нарушение ее целостности не слишком критичны. Например, данные опросов и голосований, проводимых при изучении общественного мнения, форумы и гостевые книги, статистика посещаемости сайта, прейскуранты и прайс-листы (особенно в тех случаях, когда публикация производится по расписанию: здесь всегда имеется некоторая несогласованность фактических и опубликованных данных).

Этот список можно продолжать очень долго, но основное направление обрисовано достаточно четко.

В состав MySQL входят средства диагностики и восстановления испорченных данных. Восстановить данные, впрочем, удается не всегда

Для некоторых задач MySQL, на мой взгляд, абсолютно не подходит. К этой группе я бы отнес любые задачи, связанные с финансовыми операциями, требующими повышенной надежности: системы электронной торговли, информационные базы, содержащие важную информацию. Несмотря на то, что с использованием MySQL разработано довольно много решений для коммерции (например, для организации интернет-магазинов VShop3), я бы в данном случае рисковать не стал.

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

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

Я уже отмечал, что иногда система на базе MySQL может оказаться более дорогой, чем на базе какой-либо другой, коммерческой СУБД. Но с тем же успехом может случиться и обратное. Особенно это актуально для простых систем, в разработку которых не планируется вкладывать значительные средства, и для тех организаций, где эта СУБД уже используется.

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

Павел Давыдов