MySQL - свободная реляционная система управления базами данных

Обратите внимание: чтобы создать суперпользователя, необходимо создать запись таблицы user с полями привилегий, установленными в значение 'Y'. Нет необходимости задавать значения в записях таблиц db или host.

Столбцы привилегий в таблице user в последнем операторе INSERT (для пользователя dummy) не были заданы явно, поэтому данным столбцам был присвоено принятое по умолчанию значение 'N'. Точно так же действует команда GRANT USAGE.

В приведенном ниже примере добавляется пользователь custom, который может подсоединяться с компьютеров localhost, server.domain и whitehouse.gov. Он хочет получать доступ к базе данных bankaccount только с компьютера localhost, к базе данных expenses - только с whitehouse.gov, и к базе данных customer - со всех трех компьютеров, а также использовать пароль stupid при подсоединении со всех трех компьютеров.

Чтобы задать эти привилегии пользователя при помощи оператора GRANT, выполните следующие команды:

shell> mysql --user=root mysql

mysql> GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP

-> ON bankaccount.*

-> TO custom@localhost

-> IDENTIFIED BY 'stupid';

mysql> GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP

-> ON expenses.*

-> TO custom@whitehouse.gov

-> IDENTIFIED BY 'stupid';

mysql> GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP

-> ON customer.*

-> TO custom@' %'

-> IDENTIFIED BY 'stupid';

Привилегии для пользователя custom мы назначаем потому, что этот пользователь хочет получать доступ к MySQL как с локального компьютера через сокеты Unix, так и с удаленного компьютера whitehouse.gov через протокол TCP/IP.

Чтобы задать привилегии пользователя путем непосредственного внесения изменений в таблицы назначения привилегий, выполните следующие команды (обратите внимание на команду FLUSH PRIVILEGES в конце примера):

shell> mysql --user=root mysql

mysql> INSERT INTO user (Host,User,Password)

-> VALUES('localhost','custom',PASSWORD('stupid'));

mysql> INSERT INTO user (Host,User,Password)

-> VALUES('server.domain','custom',PASSWORD('stupid'));

mysql> INSERT INTO user (Host,User,Password)

-> VALUES('whitehouse.gov','custom',PASSWORD('stupid'));

mysql> INSERT INTO db

-> (Host,Db,User,Select_priv,Insert_priv,Update_priv,Delete_priv,

-> Create_priv,Drop_priv)

-> VALUES

-> ('localhost','bankaccount','custom','Y','Y','Y','Y','Y','Y');

mysql> INSERT INTO db

-> (Host,Db,User,Select_priv,Insert_priv,Update_priv,Delete_priv,

-> Create_priv,Drop_priv)

-> VALUES

-> ('whitehouse.gov','expenses','custom','Y','Y','Y','Y','Y','Y');

mysql> INSERT INTO db

-> (Host,Db,User,Select_priv,Insert_priv,Update_priv,Delete_priv,

-> Create_priv,Drop_priv)

-> VALUES(' %','customer','custom','Y','Y','Y','Y','Y','Y');

mysql> FLUSH PRIVILEGES;

Первые три оператора INSERT добавляют в таблицу user записи, которые позволят пользователю custom подключаться с различных компьютеров с указанным паролем, но не дают ему никаких привилегий (все привилегии установлены в принятое по умолчанию значение 'N'). Следующие три оператора INSERT добавляют записи в таблицу db, в которой назначаются привилегии для пользователя custom по отношению к базам данных bankaccount, expenses и customer, но только если доступ осуществляется с определенных компьютеров. Как обычно, после внесения изменений непосредственно в таблицы назначения привилегий серверу необходимо дать команду на перезагрузку этих таблиц (при помощи FLUSH PRIVILEGES), чтобы внесенные изменения вступили в силу.

Если необходимо предоставить определенному пользователю доступ с любого компьютера к определенному домену, можно воспользоваться оператором GRANT следующим образом:

mysql> GRANT...

-> ON *.*

-> TO myusername" %.mydomainname.com"

-> IDENTIFIED BY 'mypassword';

Чтобы сделать то же самое путем непосредственного внесения изменений в таблицы назначения привилегий, выполните следующие действия:

mysql> INSERT INTO user VALUES ('%.mydomainname.com', 'myusername',

-> PASSWORD('mypassword'),...);

mysql> FLUSH PRIVILEGES;

4.2 Ограничение ресурсов пользователя

Начиная с MySQL версии 4.0.2 можно ограничивать определенные ресурсы, выделяемые пользователям.

До этой версии единственным возможным методом ограничения использования ресурсов сервера MySQL была установка переменной запуска max_user_connections в значение, отличное от нуля. Но этот метод действует только на глобальном уровне и не позволяет управлять отдельными пользователями. Он может представлять определенный интерес только для провайдеров услуг Internet.

На уровне отдельного пользователя теперь введено управление следующими тремя ресурсами:

· Количество всех запросов в час: все команды, которые может запускать пользователь.

· Количество всех обновлений в час: любая команда, которая изменяет таблицу или базу данных.

· Количество соединений, сделанных за час: новые соединения, открытые за час.

Пользователь в упомянутом выше контексте представляет собой отдельную запись в таблице user, которая уникальным образом идентифицируется своими столбцами user и host.

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

GRANT... WITH MAX_QUERIES_PER_HOUR N1

MAX_UPDATES_PER_HOUR N2

MAX_CONNECTIONS_PER_HOUR N3;

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

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

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

Кроме того, текущие значения для всех пользователей сбрасываются, если производится перезагрузка привилегий (на сервере или при использовании команды mysqladmin reload) или если выполняется команда FLUSH USER_RESOURCES.

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

Необходимым условием для включения данной функции является наличие в таблице user базы данных mysql дополнительного столбца, как это определено в скриптах создания таблиц mysql_install_db и mysql_install_db.sh в подкаталоге scripts.



4.3 Задание паролей

В большинстве случаев для задания пользователей и их паролей следует пользоваться командой GRANT, поэтому приведенная ниже информация предназначена для опытных пользователей. See Раздел 4.3.1, "Синтаксис команд GRANT и REVOKE".

В примерах, приведенных в предыдущих разделах, демонстрируется важный принцип, который заключается в следующем: при сохранении непустых паролей с использованием операторов INSERT или UPDATE для их шифрования должна применяться функция PASSWORD(). Это делается потому, что в таблице user пароли хранятся в зашифрованном виде, а не как простой текст. Предположим, что мы упустили это из виду и задали пароли следующим образом:

shell> mysql -u root mysql

mysql> INSERT INTO user (Host,User,Password)

-> VALUES(' %','jeffrey','biscuit');

mysql> FLUSH PRIVILEGES;

В результате выполнения этих команд в таблице user будет сохранено значение пароля biscuit в виде простого текста. Когда пользователь jeffrey попытается подсоединиться к серверу, используя этот пароль, клиент mysql зашифрует его при помощи функции PASSWORD(), сгенерирует вектор аутентификации, основанный на зашифрованном пароле и случайно выбранном числе, полученном от сервера, и направит результат на сервер. Сервер использует значение password из таблицы user (в данном случае, это незашифрованное значение biscuit), чтобы осуществить точно такие же вычисления, и сравнит результаты. Результаты не совпадут, и сервер не позволит установить соединение:

shell> mysql -u jeffrey -pbiscuit test

Access denied

Перед занесением в таблицу user пароли необходимо зашифровывать, поэтому оператор INSERT должен использоваться следующим образом:

mysql> INSERT INTO user (Host,User,Password)

-> VALUES(' %','jeffrey',PASSWORD('biscuit'));

При использовании оператора SET PASSWORD также необходимо применять функцию PASSWORD():

mysql> SET PASSWORD FOR jeffrey" %" = PASSWORD('biscuit');

Если пароль задается при помощи оператора GRANT... IDENTIFIED BY или команды mysqladmin password, нет необходимости использовать функцию PASSWORD(). Обе эти команды самостоятельно производят шифровку пароля, поэтому пароль следует указывать как biscuit, например, таким образом:

mysql> GRANT USAGE ON *.* TO jeffrey" %" IDENTIFIED BY 'biscuit';

или

shell> mysqladmin -u jeffrey password biscuit

Примечание: Функция PASSWORD() шифрует пароли отличным от Unix образом. Не следует полагать, что если ваши пароли для Unix и для MySQL совпадают, то функция PASSWORD() выдаст точно такой же результат шифрования, как и файл паролей Unix.

Механизм управления и разграничения доступа пользователей к базам и таблицам в MySQL. Работает этот механизм, естественно, через служебные таблицы. В списке баз данных есть одна служебная база под названием "mysql", в которой хранятся в нескольких таблицах все служебные данные, необходимые для работы сервера. Пока нас интересует только управление правами доступа, за которые отвечают следующие таблицы:

? columns_priv - доступ на уровне столбцов таблицы;

? db - доступ к отдельным базам данных;

? host - доступ к базам с конкретных хостов/IP;

? tables_priv - доступ к отдельным таблицам базы данных;

? user - глобальные настройки доступа для конкретных пользователей.

Давайте детально рассмотрим таблицу user и специфику работы с ней, работа же с остальными таблицами аналогична и не будет сложнее.

Права, определяемые в таблице user, являются глобальными, это значит, что они применяются ко всем базам данных, к которым имеет доступ конкретных пользователь. Также в этой таблице хранятся сами имена пользователей и их пароли. Причем имена пользователей хранятся в виде открытого текста, а пароли зашифрованы функцией PASSWORD(). Сервер MySQL применяет свой метод шифрования вместо системного (если такая функция предоставляется ОС, к примеру, Linux/UNIX).

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

Если для одного и того же пользователя надо разрешить доступ с различных компьютеров, то в таблице привилегий надо создать две (три или больше - сколько понадобится) записей, определяя в каждой отдельный параметр доступа. К примеру, для доступа пользователя root с компьютеров localhost и 192.168.1.138 надо в таблицу user внести две одинаковые записи, которые различаются только полем host. Хотя можно, конечно, и не делать их одинаковыми - тогда тот же пользователь, но в зависимости от места, откуда он подключился, будет иметь разные привилегии.

Значение столбца host можно задавать в различных форматах. Это может быть как имя хоста - localhost, так и IP-адрес - 192.168.1.138. При необходимости, можно применять символы подстановки. Они аналогичны тем же. Что применяются в синтаксисе SQL-запросов. Символ "_" означает любой символ, а " %" - любое количество символов. К примеру, для разрешения доступа с любого компьютера, содержащего в имени hostinfo.ru надо прописать %.hostinfo.ru в столбце host. Таким же способом можно задавать и диапазоны IP-адресов. Для задания маски сети доступен также вариант написания через слеш - 192.168.1/255. Для глобального задания доступа можно в столбце host прописать только символ " %" или оставить его пустым, что равнозначно.

Следующие поля - user и password, определяют имя и пароль пользователя. Эти поля уже, в отличие от host, различают регистр введенных символов, поэтому пользователь Root и root - это два разных пользователя. Знаки подстановки в этом поле уже не работают - имя пользователя %" означает не "любой пользователь", а именно "пользователь с именем %". Для задания анонимного пользователя надо просто оставить поле пустым, иначе любой символ будет считаться именем пользователя. Так же и в поле password - пароль хранится в зашифрованном виде, знаки подстановки недействительны, а пустое поле означает, что пользователь вовсе не должен указывать пароль, а не то, что пароль может быть произвольным. Напомним, что просто пароль (пусть и зашифрованный) нельзя помещать в поле password, предварительно его надо шифровать функцией PASSWORD("пароль_открытым_текстом"). Например:

INSERT INTO user SET host="192.168.1.138", user="raiden", password=PASSWORD("my_password");

Следующим полем является поле базы данных - db. В других таблицах оно также присутствует, поэтому во всех таблицах правила написания имен баз данных должны быть одинаковыми. Разрешается использовать символы подстановки " %" и "_", пустое значение соответствует "все базы". Поле чувствительно к регистру!

Далее идет целый набор столбцов, разрешающие те или иные действия для пользователя. К примеру, Select_priv, Insert_priv, Update_priv, Delete_priv, Index_priv и Alter_priv стоит установить в "Y" (разрешено) для обычного пользователя, так как такие запросы чаще всего встречаются в обычных приложениях. Остальные возможности для большей безопасности надо отключить для всех пользователей (особенно, если есть учетная запись анонимного пользователя). Поэтому в следующих столбцах - Create_priv, Drop_priv, Reload_priv, Shutdown_priv, Process_priv, File_priv, Grant_priv и References_priv надо выставить значение "N"(запрещено), а при необходимости разрешить действия только администратору и максимально ограничить возможности подключения такого пользователя - указать конкретный IP-адрес или имя компьютера, выбрать длинный и сложный для подбора пароль.

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

При подключении пользователя сервер MySQL сначала обрабатывает таблицу user (записанные там правила доступа глобальные), а потом, если прав недостаточно или нельзя определить права доступа к конкретной базе - тогда уже поиск продолжается в таблице db. Если же и во второй таблице нет соответствующих привилегий, сервер пробует найти их в таблицах tables_priv и columns_priv. И только когда на основании информации со всех доступных таблиц сервер определяет, что клиенту не разрешено запрошенное действие, он отвергает клиентский запрос.

Таблица host также аналогична описанным выше, только вместо имен и паролей пользователей для идентификации привилегий служит имя хоста или IP-адрес. На первый взгляд, есть существенное дублирование информации. Ведь таблицы db и host почти равнозначны и содержат одинаковые данные. На самом деле это немного не так. Таблица host недоступна для изменения через операторы SQL GRANT и REVOKE, ее можно только править непосредственно. Когда сервер принимает решение о допуске клиента к базам, он сначала ищет упоминание имени хоста или IP в таблице host. Если там присутствует соответствующая запись, то тогда права из таблиц host и db обьединяються и клиент получает некоторые привилегии. Если же в таблице host нет указаний на счет хоста или IP, то сервер даже не рассматривает дальше таблицу db, так как если клиенту не разрешено подключение с хоста, то тогда бессмысленно искать права на доступ к отдельным базам.

И, напоследок, давайте остановимся на одном нюансе при определении привилегий. Сервер MySQL, когда ищет и сравнивает привилегии, не сравнивает их напрямую. К примеру, символьное обозначение параметра имеет больший приоритет, чем использование символов подстановки. Пример: если есть две записи - %.hostinfo.ru и admin.hostinfo.ru, то вторая запись имеет больший приоритет. Поэтому если для одного пользователя существуют разные привилегии в зависимости от хоста или других параметров, то будет выбираться первой та запись, где более точно и однозначно указан параметр. Это же касается и IP-адресов.

5. История

MySQL - СУБД (система управления базами данных). На данный момент MySQL принадлежит компании Oracle Corporation. Изначально MySQL принадлежала компании MySQL AB. Потом, 16 января 2008 года между компаниями MySQL AB и Sun Microsystems было объявлено соглашение о покупки компанией Sun Microsystems компанию MySQL AB. Поглощение компании MySQL AB состоялось 26 февраля 2008 года. 27 января 2010 года компанию Sun Microsystems купила компания Oracle Corporation.

На данный момент MySQL портирована на множество платформ: OS/2 Warp, Mac OS X, Linux, Open VMS, AIX, FreeBSD, семейство Windows (95, 98, NT, 2000, XP, server 2002, Vista, 7) и другие. На сайте MySQL вы можете скачать как исходный код, так и скомпилированные модули СУБД.

История выпусков:

· Первый внутренний выпуск MySQL состоялся 23 мая 1995 года.

· Версия для Windows систем (Windows 95 и NT) выпущена 8 января 1998.

· Версия 3.23: бета-версия в июне 2000, релиз в январе 2001.

· Версия 4.0: бета в августе 2002, релиз в марте 2003.

· Версия 4.1: бета в июне 2004, релиз в октябре 2004.

· Версия 5.0: бета в марте 2005, релиз в октябре 2005.

· Версия 5.1: разработка велась с ноября 2005, релиз в ноябре 2008.

· Версия 5.4: бета в апреле 2009, не была выпущена.

· Версия 5.5: релиз в декабре 2010.

· Версия 6.0: в разработке.

MySQL 4.0. Несмотря на то, что версия 4.0 является устаревшей, она всё ещё имеет значительное распространение. Основные возможности этой версии:

· практически полная реализация ANSI SQL-99, плюс расширения;

· межплатформенная совместимость;

· независимые типы таблиц (MyISAM для быстрого чтения, InnoDB для транзакций и ссылочной целостности);

· транзакции;

· поддержка SSL;

· кэширование запросов;

· репликация: один головной сервер на одного подчинённого, много подчинённых на одного головного;

· полнотекстовая индексация и поиск с использованием типа таблиц MyISAM;

· внедрённая библиотека базы данных;

· поддержка Юникода (UTF-8);

· таблицы InnoDB, обеспечивающие соответствие требованиям ACID;

· встроенный сервер, позволяющий включать MySQL в автономные приложения.

MySQL 4.1. Рекомендованной версией на 2005 год является MySQL 4.1 вышла 27 октября 2004. Она содержит следующие нововведения:

· вложенные запросы и производные таблицы;

· новая система кодировок и сортировок;

· более быстрый и гибкий протокол клиент-сервер с поддержкой подготовленных запросов, обеспечивающий их оптимальное исполнение;

· новая программа установки и настройки для Microsoft Windows и Linux;

· защищённые через OpenSSL соединения клиент-сервер;

· высоко-оптимизированная библиотека, которая может быть использована в сторонних программах;

· полноценная поддержка Юникода (UTF-8 и UCS2);

· стандартные пространственные типы данных GIS, для хранения географической информации;

· улучшенный полнотекстовый поиск и система помощи.

MySQL 5.0. Версия MySQL 5.0 вышла 24 октября 2005 года, в этой версии значительно расширена функциональность, которая ставит MySQL в один ряд с коммерческими СУБД. Если раньше СУБД MySQL обвиняли в недостаточной поддержке стандарта SQL, то с появлением пятой версии этой популярной базы данных, появилась практически полная поддержка стандарта SQL. MySQL 5.0 содержит следующие нововведения:

· хранимые процедуры и функции;

· обработчики ошибок;

· курсоры;

· триггеры;

· представления;

· информационная схема (так называемый системный словарь, содержащий метаданные).

MySQL 5.1. Версия MySQL 5.1 продолжает путь к стандарту SQL:2003. MySQL 5.1 содержит следующие нововведения.

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

· Изменено поведение ряда операторов, для обеспечения большей совместимости со стандартом SQL2003.

· Построчная репликация (англ. row-based replication), при которой в бинарный лог будет записываться только информация о реально измененных строках таблицы вместо оригинального (и, возможно, медленного) текста запроса. Построчную репликацию можно использовать только для определенных типов sql-запросов, в терминах MySQL - смешанная репликация (англ. mixed replication).

· Встроенный планировщик периодически запускаемых работ. По синтаксису добавление задачи похоже на добавление триггера к таблице, по идеологии - на crontab.

· Дополнительный набор функций для обработки XML, реализация поддержки XPath.

· Новые средства диагностики проблем и утилиты для анализа производительности. Расширены возможности по управлению содержимым лог-файлов, логи теперь могут быть сохранены и в таблицах general_log и slow_log. Утилита mysqlslap позволяет провести нагрузочное тестирование БД с записью времени реакции на каждый запрос.

· Для упрощения операции обновления подготовлена утилита mysql_upgrade, которая выполнит проверку всех существующих таблиц на предмет совместимости с новой версией, и при необходимости выполнит надлежащие корректировки.

· MySQL Cluster отныне выпущен как отдельный продукт, базирующийся на MySQL 5.1 и хранилище NDBCLUSTER.

· Значительные изменения в работе MySQL Cluster, такие, как, например, возможность хранения табличных данных на диске.

· Возврат к использованию встроенной библиотеки libmysqld, отсутствовавшей в MySQL 5.0.

· API для плагинов, которое позволяет загружать сторонние модули, расширяющие функциональность (например, полнотекстовый поиск), без перезапуска сервера.

· Реализация парсера полнотекстового поиска в виде plug-in.

· Новый тип таблиц Maria (устойчивый к сбоям клон MyISAM).

Тип таблиц Maria. Maria (начиная с версии 5.2.x - Aria) - новый MySQL тип таблиц для хранения данных. Maria представляет собой расширенную версию хранилища MyISAM, с добавлением средств сохранения целостности данных после краха.

Основные достоинства Maria ^[9].

· В случае краха производится откат результатов выполнения текущей операции или возврат в состояние до команды LOCK TABLES. Реализация через ведение лога операций.

· Возможность восстановления состояния из любой точки в логе операций, включая поддержку CREATE/DROP/RENAME/TRUNCATE. Может быть использовано для создания инкрементальных бэкапов, через периодическое копирование лог файла.

· Поддержка всех форматов столбцов MyISAM, расширена новым форматом "rows-in-block", использующим страничный способ хранения данных, при котором данные в столбцах могут кэшироваться.

· В будущем будет реализовано два режима: транзакционный и без отражения в логе транзакций, для не критичных данных.

· Размер страницы данных равен 8Кб (в MyISAM 1Кб), что позволяет достичь более высокой производительности для индексов по полям фиксированного размера, но медленнее в случае индексирования ключей переменной длины.

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

· Использование по умолчанию движка InnoDB.

· Поддержка полусинхронного (semi-synchronous) механизма репликации, основанного на патчах к InnoDB от компании Google.

· Улучшение функций по партицированию данных. Расширенный синтаксис для разбиения больших таблиц на несколько частей, размещенных в * разных файловых системах (partitioning). Добавлены операции RANGE, LIST и метод оптимизации "partition pruning".

· Новый механизм оптимизации вложенных запросов и JOIN операций.

· Переработана система внутренних блокировок.

· Интегрированы патчи Google с оптимизацией работы InnoDB на CPU с большим количеством ядер.

MySQL 6.0. Версия MySQL 6.0 была заморожена на стадии альфа-тестирования. Первоначально было принято решение о создании версии 5.2, вскоре эта версия была переименована в 6.0. Однако, позже информация о MySQL 6.0 исчезла с сайта, а разработчики сосредоточились на версии 5.5 и следующей за ней версии 5.6. mysql копирование целостность доступ

Одним из основных нововведений версии 6.0 планировался новый тип таблиц Falcon, разработанный в качестве потенциальной замены для InnoDB компании InnoBase, приобретённой компанией Oracle. В связи с приобретением в 2010 году Sun Microsystems тем же Oracle, судьба Falcon остаётся под вопросом.



6. Клоны MySQL

ExtSQL. В развитии разных веток их разработчики пошли разными концептуальными путями. С одной стороны, сделана попытка наращивания ещё большей функциональности и добавление множества новых фичей, - например, это проект компании Software Workshop под названием ExtSQL. Проект параллельно ведет две ветви разработки, базирующихся соответственно на кодовой ветке 4-ой и 5-ой версий оригинального MySQL. ExtSQL разрабатывался с сильным уклоном для специализированного использования в системах web-хостинга и призван решить проблемы, связанные с организацией учета потребления ресурсов. Администраторы ExtSQL получают возможность полного мониторинга активности пользователей, всех баз и соединений.

Например, запрос "SHOW STATISTICS select, insert FROM user HISTORY" позволит узнать число запросов "select" и "insert" совершенных пользователями за последний час. Естественно, для этого в бывший MySQL добавлены новые команды и расширен диалект SQL, при этом сохранена полная обратная совместимость с MySQL. Кроме поддержки своей версии MySQL, организация-разработчик Software Workshop входит в состав технического комитета INCITS H2, участвующего в развитии стандарта SQL, и активно пытается добиться расширения SQL в плане добавления возможностей для учета потребления серверных ресурсов. В целом, если говорить языком цифр, то независимые тестирования показывают, что плата за подобные надстройки над MySQL выражается в потери производительности сервера в среднем на 5 % на обычных задачах, и на 15-20 % при интенсивной работе с реально большими базами данных. Итак, ExtSQL - это своего рода редакция "MySQL Server Advanced Hoster Edition", для особенно требовательных пользователей СУБД этого класса.

Drizzle. Совершенно противоположной дорогой пошел другой популярный форк MySQL - проект Drizzle. Этот проект основан бывшим директором MySQL по архитектуре Брайаном Эйкером, и представляет собой упрощенный и более быстрый вариант MySQL, в котором тщательно отобраны и удалены все ресурсоемкие и маловостребованные возможности MySQL 5. Часть из этих возможностей всё же возможно реализовать через подключаемые плагины. Эта СУБД позиционируется как высокоскоростная и высоконадежная БД, с поддержкой ACID-транзакций. В качестве хранилища используется InnoDB и PBXT. Что интересно, что весь сишный исходный код из MySQL был полностью переписан на языке C++. Управление проектом находится в руках независимого сообщества.

В отличие от SQLite, Drizzle не претендует на роль встраиваемого решения и реализован в виде сервера. Архитектура Drizzle построена на основе идеи микроядра, исповедует максимальное упрощение структуры БД и вынос логики на сторону приложений. В частности, такой дизайн СУБД позволяет организовать обработку просто ОГРОМНОГО числа параллельных запросов, при выполнении которых в полной мере задействуются мощности современных многоядерных CPU, как результат - Drizzl'овские пиковые показатели интенсивности обмена запросами-ответами с web-приложением завесят любой стандартный сервер MySQL 5.1, который просто захлебнётся под такой нагрузкой (тыс.ячи или десятки тыс.яч сетевых соединений в случае "обычного" MySQL почти гарантированно вызывают проблемы с памятью сервера БД - см. открытые ошибки bug#26590, bug#33948, bug#49169, так что не думайте, что при такой нагрузке достаточно просто обновить железо сервера).

Кроме этого, в Drizzle дополнительно реализованы встроенные средства для разнесения данных по ключевому полю (шардинг) на кластер из нескольких машин, для создания эффективной балансировки нагрузки для по-настоящему сверхнагруженных проектов. По сравнению с MySQL в Drizzle удалена поддержка хранимых процедур (вместо CREATE FUNCTION следует использовать связываемые объекты), триггеров, кэша запросов (query cache), представлений (view), операции GRANT и ALTER, ограничений ACL, команды SHOW, предварительно подготовленных запросов (prepared statement) и др. Прекращена поддержка малоиспользуемых типов данных из MySQL. На вопросы оппонентов, как же можно использовать БД, например, без view'ов, разработчики отвечают в том ключе, что "все те, кому действительно серьёзно нужны view'ы - уже давно сидят на PostgreSQL или Oracle, это же касается и всех других продвинутых фичей".

Да, действительно, для запуска очень многих, например, блоговых движков написанных в связке с MySQL уже под Drizzle - понадобится модификация и некоторый тюнинг кода этих движков, впрочем, как успокаивают разработчики, изменения эти невелики и возможностей Drizzle на самом деле более чем достаточно для полноценного функционирования большинства популярных CMS, тем более что сообщество уже кастомизировало многие известные php-движки под Drizzle, что позволяет показывать их рекордную производительность на том же железе, на котором раньше крутился старый-добрый MySQL. В качестве приятного побочного эффекта, на Drizzle перестали проходить многие популярные разновидности sql-injections для MySQL, так что безопасность стала невольным бонусом этого проекта, попутно демонстрируя нам всем глубокие философские выводы о том, что минимализм есть почти тождество слова безопасность.

SkySQL. Рассмотрев, так сказать крайности, макси- и мини-варианты оригинального MySQL, давайте посмотрим какие есть т.с. более традиционно-классические, продолжения этого известного проекта. На фоне тотального исхода из Oracle разработчиков MySQL (из Oracle добровольно "катапультировалось" уже более 70 % оригинальной команды MySQL AB), они, разбредаясь по миру, пытаются как-то заново пристроиться уже под новую историческую эпоху для MySQL.

Так появилась компания SkySQL, основанная уволившимися из Oracle разработчиками MySQL, частично финансируемая несколькими бывшими инвесторами MySQL AB и возглавляемая Ульфом Санбергом, бывшим вице-президентом по предоставлению глобальных сервисов MySQL. Новая компания пока не намерена развивать свой форк MySQL, а займется предоставлением коммерческой технической поддержки, консалтинговых услуг, обучением и продажей готовых решений на базе MySQL. Кроме того, SkySQL занялась выпуском и поддержкой альтернативной промышленной сборки MySQL - SkySQL Enterprise. Продукт распространяется по подписке и снабжен полноценной технической поддержкой (помощь в решении проблем, консультации по настройке, устранение последствий сбоев) и консалтинговым сервисом (планирование внедрения и проведение оптимизации), т.е. фактически полностью перезапустила бизнес своего прототипа, ныне доставшегося Oracle, шведской компании MySQL AB. Так вот, здесь очень интересно, что входит в состав этой самой SkySQL Enterprise? А входит туда, кроме сопутствующих утилит, "прозрачная замена" MySQL - MariaDB Server.

MariaDB Server. Давайте остановимся и зададимся вопросом - что же такое MariaDB Server? Для этого немного откатимся в краткий исторический обзор, чтобы понять, откуда и зачем взялся этот очередной новый форк MySQL. Майкл "Монти", создатель и бессменный лидер проекта СУБД MySQL, покинув в конце 2008 года компанию Sun Microsystems и после прекращении непосредственного участия в разработке MySQL, задумал создать максимально совместимый с MySQL, но идейно новый сервер, базирующийся на принципиально новом движке хранилища данных. Используемое новое хранилище данных Maria - это устойчивый к сбоям клон MyISAM. Многие специалисты отмечают, что Maria Engine это, как минимум, один из лучших движков для выборки данных, из всех что сейчас существуют, тогда как в классическом MySQL дефолтный MyISAM - её самое слабое место.

В новой компании вместе с Монти над ним работает около 20 сотрудников - бывших разработчиков из MySQL AB, ушедших из Sun вслед за своим идейным лидером. Создатель MySQL заявляет, что MariaDB Server - это максимально точная и совместимая интерфейсная копия SQL используемого в оригинальном MySQL 5, тогда как внутри - он уже во многом превосходит свой протип, давший ему жизнь и стартовую кодовую базу. Более того, Монти заявил, что MariaDB отныне - это единственная официальная версия MySQL, тогда как Oracle MySQL - "is now dead". Самое страшное в этом молодом проекте это то, что многие недовольны женским названием новой БД: ну так одну из дочерей автора MySQL зовут My, а вторую - Maria. Отсюда и названия баз данных. Есть правда ещё один сын, и зовут его, на всякий случай, Макс. И MaxDB уже, кстати, создана, но здесь о ней не будет сказано ни слова.

Таким образом, суммируя, часть разработчиков после ухода из Sun и Oracle осели в компании Monty Program, где день и ночь пилят новый-старый MySQL, но под уже новым названием - MariaDB Server, тогда как вторая часть программистов и сервисного персонала из бывшего MySQL AB - основали компанию SkySQL по сопровождению и поддержке MariaDB Server. И кстати, по-моему мнению, MariaDB Server - это самая качественная и сбалансированная замена для MySQL, после того как Oracle его похоронит (а по моему субъективному мнению, ждать этого осталось уже не долго, и первые звоночки как бы даже уже позванивают).

Например, на моем хостинге MariaDB прекрасно работает в связке с PHP5, обслуживая обычные WordPress'ы и прочие популярные движки, для работы с БД настроен обычный PhpMyAdmin, сами пользователи хостинга о существовании такой БД даже и не подозревают, принимая её за всамделишный MySQL. Хотя ради справедливости стоит заметить, что сами разработчики говорят, что расхождение с кодовой базой MySQL уже сейчас достигло примерно 20 процентов, и будет конечно нарастать и дальше. Также мною проверялась работа MariaDB в связке с MySQL Proxy и специализированным файрволлом для MySQL - GreenSQL: обе софтины работали с MariaDB прямо как с родной MySQL, так что думаю, что как минимум одна достойная и очень перспективная альтернатива для MySQL уже состоялась.

Хочется добавить, что MariaDB Server, также, как и Drizzle - очень активно развиваются и эволюционируют, и кроме того, каждый из этих двух проектов очень хорошо смотрится для своих, несколько разных целевых ниш. И, кстати говоря, буквально на днях, у MariaDB вышел первый официально стабильный релиз за всю её молодую историю.

OurDelta. Следующий проект, который мы кратко рассмотрим - это дистрибутивы от проекта OurDelta. На самом деле это популярные ре-сборки двух upstream-проектов: для MySQL 5 поддерживаются два параллельных дистрибутива, это OurDelta и OurDelta-Sail. Если в первый включаются билды собранные с применением к стандартным сырцам MySQL 5 только хорошо протестированной коллекции сторонних "неканонических" патчей, то во вторую, экспериментальную отчасти ветвь, включается всё самое прогрессивное и максимально свежее что имеется на момент релиза, но, как понятно, часто оно толком ещё не обкатано в реальных условиях как следует, со всеми вытекающими отсюда последствиями.

Кроме этого, OurDelta точно также в параллельной ветке расширяет функциональность и MariaDB 5, которую считает прямым конкурентом и приемником MySQL, но здесь на данный момент есть только одна ветвь сборок - стабильная для MariaDB. Что же это за такие патчи, которыми регулярно потчует нас проект OurDelta?

Основная часть рабочего материала - это адаптация в одну ветвь суммарных наработок проектов MariaDB Server, а также патчсета компании Google, который она развивает для своих собственных нужд, масштабируя и, порой весьма радикально, расширяя функциональность оригинального MySQL. Следующий крупный донор проекта - это патчсеты от Марка Калагхана из Facebook, который ожесточенно "пилит под себя" MySQL для этой компании уже пятый год, ну и также от ряда других компаний, перечислять которые здесь нет смысла, в силу их абсолютной малоизвестности широкому кругу читателей и писателей, навроде меня. Таким образом, проект OurDelta - это своего рода "MySQL/MariaDB на стероидах", делающий продвинутые накачанные новой функциональностью сборки MySQL/MariaDB на любой цвет и вкус. Хотелось лишь отметить, что в OurDelta очень охотно используют патчи также и от такого самобытного проекта-форка, как Percona, на котором давайте сейчас немного остановимся поподробнее.

Percona. Компания Percona основана в 2008 году двумя отечественными разработчиками, уже бывшими членами MySQL dev.team, Петром Зайцевым и Вадимом Ткаченко. Их БД-сервер основывается на кодовой базе MySQL 5.1, которая дополнена собственными многочисленными, и что хочется отдельно подчеркнуть, весьма качественными патчами, направленными на добавление новой функциональности, повышения стабильности работы и удобства администрирования. Но главная фича проекта - интеграция собственного движка XtraDB, основанного на коде InnoDB-plugin и полностью совместимого с ним, но отличающегося существенно более высокой производительностью. По умолчанию XtraDB не изменяет дефолтный формат хранения данных в InnoDB. Вы можете прозрачно переключаться между XtraDB и InnoDB по нескольку раз в день.

Кроме того, Percona поставляет вместе с этим движком очень мощную бэкаповую систему XtraBackup, которая позволяет решать и автоматизировать даже самые экзотические задачи из области сохранности вверенных на хранение серверу БД данных.

Так вот, в экспертных кулуарах сейчас (на конец 2010 года) как бы считается, что основная острая конкуренция разгорается именно между движками Maria Engine (движок совсем недавно был переименован в Aria) и как раз Percona XtraDB - никаких более продвинутых на данный момент storage engines просто нет в природе, так что старичок MySQL будет потихоньку по-любому сдавать свои позиции на фоне его более активных и озабоченных развитием конкурентов, если конечно Oracle вдруг не опомнится и не станет вкладывать силы/ресурсы в его дальнейшую глубокую разработку.

В дополнение, интересное видео с выступлением по-русски и подробным обзором проекта Percona можно посмотреть здесь с Евгением Степченко.

NoSQL. В заключении хотелось бы сказать, что подбор наиболее подходящей к конкретному техническому заданию модификации MySQL вовсе не ограничивается выбором оптимального дистрибутива и тюнинга его настроек, но также и принципиальным режимом работы самого сервера. В качестве примера приведу недавнюю успешную реализацию подхода NoSQL на базе MySQL-сервера. Yoshinori Matsunobu, автор этого метода и нового плагина HandlerSocket, ещё один бывший участник MySQL dev.team, в своей подробной технической статье "Использование MySQL в режиме NoSQL - История о том, как достичь обработки 750,000 запросов в секунду" рассказывает об этой новой методике, а также делится тестами и реальным кодом клиентов, который можно уже прямо сейчас использовать в своих высоконагруженных проектах.

Ну что тут сказать - решение очень красивое, - при этом позволяет гибко переключаться между обычным SQL-синтаксисом из обычных клиентов, так и собственным HandlerSocket-протоколом для переключения в режим сверхвысокой производительности через реализованный в виде плагина NoSQL-режим работы MySQL, и всё это чудо мгновенного преобразования в суперпроизводительную БД - на самом обычном железе! Работая в этом режиме, автор фактически уперся в пропускную способность имеющегося 1Gb канала.



Глоссарий (версия для печати и PDA)

А

Aгент. Программа, работающая в Microsoft Windows 2000 или в Windows 2000 независимо, как бы "сама по себе", и выполняющая какое-либо обслуживание. Агент обычно имеет некоторую конкретную задачу, например, планирование операций или исполнение заданий репликации. В операционных системах семейства UNIX такие программы называются "демонами" (daemons).

Агрегатная функция (aggregate function). Функция, выполняющая операцию над набором величин и возвращающая одно значение. В SQL Server имеются следующие агрегатные функции: AVG, COUNT, DISTINCT, GROUP BY, HAVING, MAX, MIN, STDEV, STDEVP, SUM, VAR и VARP.

Адаптер главной шины (HBA, host bus adapter). Компонента компьютера, служащая для взаимодействия с шиной ввода-вывода.

Администратор баз данных (DBA, database administrator). Человек или люди, отвечающие за поддержку базы данных. Обязанности администраторов баз данных могут в различных фирмах могут сильно отличаться.

Активные серверные страницы. См. ASP-страница (Active Server Pages page).

Анализатор запросов См. SQL Query Analyzer.

Асинхронный режим передачи (ATM, Asynchronous Transfer Mode). Аппаратный сетевой протокол ATM-стандартизованная Международным союзом по телекоммуникациям (ITU) сетевая технология, заключающаяся в пересылке данных в форме ячеек (cells), то есть пакетов фиксированной длины. Передача данных является асинхронной в том смысле, что передача ячеек (пакетов) с информацией от отдельных пользователей производится необязательно периодически.

Б

База данных (database). Хранилище данных. Масштабы баз данных могут варьировать от небольшого списка имен до записей данных обо всех людях в мире.

Блок (block). См. страница.

Блокировка (lock, locking). Объект-"замок", используемый для того, чтобы к ресурсу мог бы иметь доступ одновременно только один поток. Блокировка при помощи таких замков очень важна, особенно для симметричных многопроцессорных систем (SMP systems, symmetric multiprocessor systems), потому что возможны ситуации, когда к ресурсу пытаются осуществить доступ несколько процессов одновременно.

В

Ввод-вывод (input/output, I/O). Перемещение данных от одной компоненты компьютера к другой. Этот термин применяется при описании доступа к дисковой подсистеме или к другим компонентам для передачи данных.

Виртуальная память (virtual memory). Механизм управления памятью, благодаря которому Windows NT/2000 может обращаться к памяти, большей, чем память, фактически установленная в компьютере. Это возможно благодаря подкачке страниц (свопингу). В каждый момент времени в оперативной памяти на самом деле размещается лишь часть виртуальной памяти.

Внешнее соединение (outer join). Операция, которая возвращает все строки из хотя бы одной таблицы или представления, упомянутых в предложении FROM, когда их строки удовлетворят какому-либо условию поиска WHERE или. HAVING.

Внешний ключ (foreign key). Поле таблицы, которое ссылается на аналогичное поле.

Восстановление из резервной копии (restore). Процесс, при котором файл резервной копии (backup file). копируется обратно в базу данных SQL Server. После выполнения восстановления база данных вернется в состояние, в котором она была в момент создания резервной копии.

Восстановление (регенерация) системы (recovery). Процесс перезапуска SQL Server после краха системы. Чтобы произвести повторное исполнение (roll forward) всех зафиксированных транзакций или откат (roll back) всех зафиксированных транзакций, необходимо воспользоваться журналом транзакций; тогда база данных придет в то состояние, которое было перед моментом краха системы.

Время отклика (response time). Продолжительность времени между моментом, когда пользователь подал запрос на доступ к данным (на исполнение ими транзакций) и возвратом данных пользователю. Время отклика часто служит для оценки производительности системы.

Время поиска дорожки (seek time). Продолжительность времени, необходимого для перехода головок дискового накопителя к дорожке, на которой находятся нужные данные.

Г

Графический пользовательский интерфейс (graphical user interface, GUI). Интерфейс приложения, имеющий графическую природу, что облегчает пользование приложением. Графический пользовательский интерфейс может применяться для наглядного отображения данных.

Группа файлов (filegroup). Группа файлов, применяемых как хранилище для объектов SQL Server. Группа файлов может состоять из одного или нескольких файлов данных. При создании объектов SQL Server они могут быть назначены тем или иным группам файлов.

Д

Данные контроля по четности (parity). Дополнительные данные (псевдоданные), применяемые для проверки или для исправления основных данных. Обычно говорят "бит четности" о бите, применяемом для дополнения относящихся к нему битов данных до четности или до нечетности. Проверяя четность либо нечетность битов данных, система может удостовериться в их правильности. Контроль по четности применяется для защиты данных в системах RAID 5.

Двухфазная фиксация транзакций (two-phase commit). Протокол, при помощи которого происходит координация транзакций между двумя независимыми системами, который обеспечивает в отношении транзакций принцип "всё или ничего". Двухфазная фиксация транзакций разделяет операцию фиксации на две фазы: сначала происходит подготовительная фаза (prepare phase), а вторая фаза называется фазой фиксации (commit phase). Эти фазы запускаются из приложений командой COMMIT.

Декартово произведение (Cartesian product). Результат соединения, не имеющего предложения WHERE. Размер результирующего набора данных равен произведению числа строк первой таблицы и числа строк второй таблицы. Декартово произведение обычно не является желанным результатом запроса.

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

Дистрибьютор (distributor). Промежуточный участник репликации SQL Server. Дистрибьютор берет данные репликации от издателя (publisher) и предлагает их подписчикам (subscribers).

Дифференциальное резервное копирование (differential backup). Режим резервного копирования, при котором сохраняются лишь данные, изменившиеся с момента предыдущего резервного копирования. При использовании этого режима вы можете копировать базу данных быстрее, чем при полном резервном копировании, при применении дифференциального резервного копирования восстановление базы данных потребует, как правило, более длительного времени.

Домен (domain). Группа компьютеров в сети Windows 2000 или Windows NT, имеющих общий список пользователей и пароли.

Ё

Ёмкость ввода-вывода (I/O capacity). Объем работы, который может выполнять подсистема ввода-вывода. Ёмкость ввода-вывода ограничена либо количеством операций ввода-вывода (если ограничивающим фактором является доступ к случайным дорожкам), либо производительностью (если происходят переходы головок на соседние дорожки диска).

Ж

Журнал транзакций (transactional log). Файл в базе данных, применяемый для записи всех изменений базы данных. В журнале транзакций также хранится информация о транзакциях, осуществивших изменения. Журнал транзакций хранит информацию, которой достаточно для отмены транзакций (если нужен откат, rollback) и для повторного выполнения транзакций (если нужно отменить откат).

З

Задержка (latency). Этот термин обозначает время, которое тратится процессом на ожидание завершения какой-либо операции. Чаще всего этот термин применяется, когда речь идет об ожидании процессом завершения операции ввода-вывода.

Задержка вращения (rotational latency). Продолжительность времени, требуемого, чтобы диск дискового накопителя повернулся бы в положение, необходимое для доступа к запрошенным данным.

Запись (record). Одна строка в базе данных.

Запрос (query). Оператор SQL SELECT, применяемый для доступа к данным, находящимся в базе данных. В нашей книге термин "запрос" означает операции, которые лишь считывают, но не изменяют данные.

Зеркальное отражение (mirroring). Методика обеспечения отказоустойчивости при помощи создания дублирующей компоненты, хранящей запасную копию, которую можно применить при отказе основной компоненты. Зеркальные отражения обычно употребляют в подсистемах ввода-вывода. Зеркальные отражения применяются в RAID 1 и в RAID 10.

И

Идентификатор системного процесса (SPID, system process identifier). Уникальное короткое целое (smallint), сопоставляемое с каждым из пользовательских соединений в момент создания соединения. Данное сопоставление не является постоянным.

Издатель (publisher). Система SQL Server, реплицирующая (распространяющая) свои данные для других систем. Получатели данных репликации называются подписчиками.

Измерения для планирования емкости (capacity planning measurement). Совокупность статистических показателей измерений производительности, применяемых для оценки использования ресурсов для исполнения рабочей нагрузки, предназначенных для планирования установки дополнительных аппаратных ресурсов. Такие измерения займут больше времени, чем измерения производительности (обычно - несколько часов или даже целый день).

Измерения производительности (performance measurement). Совокупность статистических показателей измерений производительности (называющихся показателями производительности), применяемых для слежения за состоянием компьютера и для настройки компьютера. Такие измерения производятся быстро (обычно - секунды или минуты, иногда - несколько часов) и служат для выявления и исправления аномалий производительности компьютера.

...