The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Каталог документации / Раздел "Базы данных, SQL" / Оглавление документа
Глава 2. Типы памяти и таблиц

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

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

Эта глава описывает каждый из типов памяти MySQL, кроме NDB Cluster. Это также содержит описание новой архитектуры хранения.

2.1. Краткий обзор архитектуры хранения данных в MySQL

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

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

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

2.1.1. Общий уровень сервера базы данных

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

Чем вообще отличаются типы памяти? Основные отличия включают:

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

2.1.2. Съемная архитектура памяти

В MySQL 5.1 MySQL AB представила новую съемную архитектуру памяти, которая позволяет загружать и выгружать типы памяти (ранее известные как драйверы таблиц) по мере надобности, не перезапуская сервер.

2.1.2.1. Подключение типа памяти

Прежде, чем тип памяти сможет использоваться, сменная общедоступная библиотека должна быть загружена в MySQL используя инструкцию INSTALL PLUGIN. Например, если сменный тип памяти EXAMPLE называется ha_example, а общедоступная библиотека именована ha_example.so, то Вы загружаете это следующей инструкцией:

INSTALL PLUGIN ha_example SONAME 'ha_example.so';

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

2.1.2.2. Отключение типа памяти

Чтобы отключить тип памяти, используйте инструкцию UNINSTALL PLUGIN:

UNINSTALL PLUGIN ha_example;

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

2.1.2.3. Безопасность и сменные типы памяти

Чтобы устанавливать съемный тип памяти, сменный файл должен быть размещен в сменном каталоге MySQL, а пользователь, выдающий инструкцию INSTALL PLUGIN должен иметь привилегию INSERT для таблицы mysql.plugin.

2.2. Обеспечиваемые типы памяти

MySQL 5.1 поддерживает следующие типы памяти:

Эта глава описывает каждый из типов памяти MySQL, кроме MySQL Cluster.

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

2.2.1. Выбор типа памяти

Различные типы памяти, обеспеченные MySQL, разработаны для различных случаев использования. Чтобы использовать съемную архитектуру памяти, хорошо иметь представление относительно выгод и недостатков различных типов памяти (хранения). Следующая таблица обеспечивает краткий обзор некоторых вариантов, обеспеченных MySQL:

Свойство MyISAM Memory InnoDB Archive NDB
Ограничения памяти256 TBДа64TB Нет384 EB[4]
ТранзакцииНетНетДаНет Да
Блокировка степени детализацииТаблицаТаблица СтрокаСтрокаСтрока
MVCC (кадр чтения)НетНетДа ДаНет
ГеографияДаНетДа[1] Да[1]Да[1]
Индексы B-treeДаДаДа НетДа
Hash-индексыНетДаНетНет Да
Поисковые индексы Full-textДаНетНет НетНет
Индексы для кластераНетНетДа НетНет
Кэширование данныхНетНе определеноДа НетДа
Кэширование индексовДаНе определеноДа НетДа
Сжатие данныхДаНетНетДа Нет
Шифрование данных[2]ДаДа ДаДаДа
ClusterНетНетНет НетДа
Репликация[3]ДаДа ДаДаДа
Поддержка внешнего ключаНетНетДа НетНет
Копия / восстановление на момент времени[3] ДаДаДаДаДа
Поддержка кэша запросовДаДаДа ДаДа
Модификация статистики для словаря данныхДаДа ДаДаДа

Некоторые необходимые пояснения:

2.2.2. Сравнение транзакционных и не транзакционных таблиц

Транзакционно-безопасные таблицы (TST) имеют несколько преимуществ над не транзакционно-безопасными таблицами (NTST):

Вы можете объединять транзакционно-безопасные и не транзакционно-безопасные таблицы в тех же самых инструкциях. Однако, хотя MySQL поддерживает несколько транзакционно-безопасных типов памяти (хранения), для самых лучших результатов, Вы не должны смешивать различные типы внутри транзакции с заблокированным autocommit. Например, если Вы делаете это, изменения для не транзакционно-безопасной таблицы все еще совершены немедленно и не могут быть прокручены обратно.

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

2.2.3. Другие типы памяти

Другие типы памяти могут быть доступны от третьих лиц, которые использовали Custom Storage Engine interface.

Вы можете находить подробную информацию в списке типов памяти третьего лица на странице MySQL Forge Storage Engines http://forge.mysql.com/projects/search.php?t=tag&k=storage%20engine.

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

На текущий момент есть следующие сторонние типы памяти:

Для подробной информации относительно разработки типа памяти, который может использоваться со съемной архитектурой памяти обратитесь к Writing a Custom Storage Engine в MySQL Internals.

2.3. Установка типа памяти

Когда Вы создаете новую таблицу, Вы можете определять, который тип памяти использовать, добавляя опцию ENGINE к инструкции CREATE TABLE:

CREATE TABLE t (i INT) ENGINE = INNODB;

Если Вы опускаете опцию ENGINE или TYPE, используется заданный по умолчанию памяти. Обычно это MyISAM, но Вы можете изменять это, используя опцию сервера --default-storage-engine или --default-table-type, либо устанавливая опцию default-storage-engine или default-table-type в файле конфигурации my.cnf.

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

SET storage_engine=MYISAM;

Когда MySQL установлен на Windows, используя MySQL Configuration Wizard, InnoDB может быть выбран как значение по умолчанию вместо MyISAM.

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

ALTER TABLE t ENGINE = MYISAM;

Если Вы пробуете использовать тип памяти, который не компилируется в сервер (или компилируется, но дезактивирован), MySQL взамен создает таблицу, использующую заданный по умолчанию тип памяти, обычно MyISAM. Это поведение удобно, когда Вы хотите копировать таблицы между серверами MySQL, которые поддерживают различные типы памяти.

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

Для новых таблиц MySQL всегда создает .frm-файл, чтобы сохранить определения столбцов и таблицу. Индекс таблицы и данные может быть сохранен в одном или большем количестве других файлов, в зависимости от типа памяти. Сервер создает .frm-файл выше уровня типа памяти. Индивидуальные типы создают любые дополнительные файлы, требуемые для таблиц, с которыми они управляются. Если имя таблицы содержит специальные символы, имена для файлов таблицы содержат закодированные версии тех символов. База данных может содержать таблицы различных типов. То есть, не все таблицы должны быть созданы с тем же самым типом памяти.

2.4. Тип памяти Falcon

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

Предупреждение

Falcon в настоящее время Alpha-релиз и не должен использоваться в промышленных средах. Falcon в настоящее время обеспечивается только внутри ветви MySQL 5.1 и не рассматривается готовым. Это обеспечивается только для целей оценки и тестирования. Обратите внимание, что MySQL 5.1 Falcon не может включать все ошибки или свойства, которые применяются к главному дереву 5.1.

Falcon в настоящее время доступен только для 32-разрядной Windows и 32 или 64-разрядной Linux. Дополнительные платформы будут добавлены после alpha-версии.

2.4.1. Свойства Falcon

Falcon был разработан для систем, которые способны поддерживать большую память и многопоточные или мультиядерные среды CPU. Большинство 64-битных систем представляют собой идеальные платформы для Falcon, где имеется большое доступное пространство памяти и 2, 4 или 8-ядерные CPU. Это также может быть развернуто внутри стандартной 32-разрядной среды.

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

2.4.2. Параметры конфигурации

Параметры конфигурированы через стандартный файл my.cnf или my.ini. Параметры могут быть конфигурированы, определяя имя параметра и соответствующее значение через пробел. Значения Memory могут быть определены в байтах или числом, сопровождаемым kb, mb или gb.

Связь между кэшем записи и кэшем страницы управляется информацией, которая кэшируется каждой системой. Целые записи, которые находятся в активном использовании (читаемые или модифицируемые) сохранены внутри кэша записи, однако, данные BLOB сохранены только внутри кэша страницы.

Кэш страницы используется, чтобы сохранить метаданные базы данных, данные BLOB и индексы таблицы.

Параметры Falcon также могут быть установлены в командной строке mysqld через использование следующих параметров командной строки:

Вы можете также допускать и отключать тип памяти Falcon при запуске, обеспечивая эти параметры mysqld, если этот mysqld включает тип памяти Falcon:

2.4.3. Создание пространства таблиц Falcon

Внутри Falcon все данные внутри одной базы данных сохранены внутри одиночного пространства таблиц, которое в свою очередь сохранено внутри одного файла в структуре каталогов MySQL. Одиночная база данных Falcon создаст три главных файла. Один файл содержит данные Falcon и будет сохранен в файле с именем базы данных Falcon с расширением .fts. Например, таблицы Falcon определенные в базе данных test, будут сохранены внутри файла test.fts в каталоге баз данных MySQL.

Два других файла содержат дисковую копию последовательного файла регистрации Falcon. Они также созданы внутри области соответствующей базы данных. В будущем выпуске Вы сможете определить альтернативное расположение для этих журналов. Так с вышеупомянутым файлом данных примера test.fts журналы будет именованы test.fl1 и test.fl2.

Определения таблицы, как с другими типами памяти MySQL, сохранены в файл .frm в каталоге базы данных. Например, таблица falcontest в базе данных test создаст файл определения (описания) таблицы falcontest.frm в каталоге test.

При создании таблицы внутри базы данных MySQL, где соответствующий файл пространства таблиц Falcon не существует, это будет автоматически создано с файлом данных и журналами.

2.4.4. Создание таблиц и индексов в Falcon

Falcon поддерживает все стандартные типы данных столбцов, обеспечиваемые MySQL.

Чтобы создать таблицу, которая использует Falcon, примените опцию ENGINE = Falcon в инструкции CREATE TABLE:

CREATE TABLE names (id INT, fname VARCHAR (20),
                    lname VARCHAR (20)) ENGINE=Falcon

Индексы могут быть созданы, используя все стандартные методы, например, Вы можете явно определять индекс на столбце:

CREATE TABLE ids (id int, index (id)) ENGINE=Falcon

Генерируйте один как часть первичного ключа:

CREATE TABLE ids (id int),PRIMARY KEY (id) ENGINE=Falcon

Или Вы можете создавать много ключей и многократные индексы:

CREATE TABLE t1 (id int NOT NULL, id2 int NOT NULL, id3 int NOT NULL,
                 name CHAR(30), primary key (id, id2),
                 index index_id3 (id3)) ENGINE=Falcon

2.4.5. Принципы и терминология

Вы должны понять следующие базисные принципы и терминологию.

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

2.4.5.1. Файл и структуры данных Falcon

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

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

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

Все транзакции в базе данных регистрируются и сохранены внутри отдельного журнала. Журнал автоматически сбрасывается и изменения записываются на диск, когда имеется команда COMMIT, когда включен auto-commit или автоматически через каждые 30 секунд, когда транзакции не используются.

2.4.5.2. Последовательный файл регистрации Falcon

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

Все транзакции в Falcon записаны в последовательный файл регистрации Falcon, а затем переданы к базе данных автоматически, если включен AUTOCOMMIT, или вручную, когда используется команда COMMIT.

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

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

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

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

2.4.5.2.1. Процесс обратной перемотки

Обратные перемотки транзакции обработаны потоком для соответствующей транзакции. Процесс обратной перемотки выполняет следующие действия:

2.4.5.2.2. Групповое завершение транзакций

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

  1. Транзакция 1 создает все необходимые входы файла регистрации и начинает записывать файл регистрации на диск.

  2. В то время как транзакция 1 завершается, транзакции 2 и 3 записывают их входы в последовательный файл регистрации.

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

  4. В то время как транзакции 2 и 3 записывают, транзакции 4, 5 и 6 записываются в журнал в оперативной памяти. Когда запись для 2 и 3 завершается, входы для 4, 5 и 6 записаны.

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

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

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

2.4.5.3. Восстановление аварийного отказа Falcon

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

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

2.4.5.4. Кэши памяти Falcon

Falcon был разработан, чтобы выполняться лучше всего на системах с щедрыми объемами памяти. Кэши памяти, используемые Falcon подобны в некоторых отношениях другим СУБД и MySQL. Однако, структура кэш имеет ряд усовершенствований по сравнению с традиционной cтратегией кэширующей памяти. Механизмы, используемые Falcon относительно кэширования памяти включают:

2.4.5.5. Потоки Falcon

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

2.4.5.6. Сжатие данных

Данные, сохраненные в пространстве таблиц Falcon сжаты на диске, но сохранены в несжатом формате в памяти. Сжатие происходит автоматически, когда данные переданы на диск.

2.4.5.7. Слот записи

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

2.4.6. Ограничения

Имеется ряд ограничений в alpha-версии Falcon. В дальнейшем они постепенно будут сниматься:

Хотя максимальная доступная память внутри пространства таблиц 128 TB, истинное число записей и объем данных, которые Вы можете сохранять, зависит от ряда факторов:

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

2.5. Тип памяти EXAMPLE

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

Тип памяти EXAMPLE включен в двоичные дистрибутивы MySQL-Max. Чтобы его включить, если Вы формируете MySQL из исходного текста, вызовите configure с опцией --with-example-storage-engine.

Чтобы исследовать исходник типа памяти EXAMPLE, смотрите каталог storage/example исходных текстов MySQL.

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

mysql> CREATE TABLE test (i INT) ENGINE = EXAMPLE;
Query OK, 0 rows affected (0.78 sec)
mysql> INSERT INTO test VALUES(1),(2),(3);
ERROR 1031 (HY000): Table storage engine for 'test' doesn't ┬╗
                    have this option
mysql> SELECT * FROM test;
Empty set (0.31 sec)

Тип EXAMPLE не поддерживает индексацию.

2.6. Тип памяти FEDERATED

Тип памяти FEDERATED обращается к данным в таблицах удаленных баз данных, а не в локальных таблицах.

Тип памяти FEDERATED включен в двоичные дистрибутивы MySQL-Max. Чтобы его включить, если Вы формируете MySQL из исходного текста, вызовите configure с опцией --with-federated-storage-engine.

Чтобы исследовать исходник типа памяти FEDERATED, смотрите каталог sql исходных текстов MySQL.

Дополнительные ресурсы:

2.6.1. Описание типа памяти FEDERATED

Когда Вы создаете таблицу типа FEDERATED, сервер создает файл формата таблицы в каталоге баз данных. Имя файла начинается с имени таблицы и имеет расширение .frm. Никакие другие файлы не созданы, потому что фактические данные находятся в удаленной таблице. Это отличается от способа, которым работают типы памяти для локальных таблиц.

Для локальных таблиц базы данных файлы данных локальны. Например, если Вы создаете MyISAM-таблицу с именем users, драйвер MyISAM создает файл данных, именованный users.MYD. Драйвер для локальных таблиц читает, вставляет, удаляет и модифицирует данные в локальных файлах данных, и строки сохранены в частном формате драйвера. Чтобы читать строки, драйвер должен анализировать данные в столбцах. Чтобы записывать строки, значения столбцов должны быть преобразованы в формат строки, используемый драйвером и записаны в локальный файл данных.

А вот в типе памяти FEDERATED не имеется никаких локальных файлов данных для таблицы (например, нет файла .MYD). Вместо этого удаленная база данных сохраняет данные, которые обычно были бы в таблице. Локальный сервер соединяется с удаленным и использует клиентское API MySQL, чтобы читать, удалять, модифицировать и вставлять данные в удаленной таблице. Поиск данных инициализирован через инструкции SQL SELECT * FROM tbl_name. Чтобы читать результат, строки выбраны по одной, используя функцию C API mysql_fetch_row(), а затем преобразуя столбцы в наборе результатов SELECT к формату, который ожидает получить драйвер FEDERATED.

Поток информации таков:

  1. SQL-обращения выданы локально.

  2. Используется MySQL handler API (данные в формате драйвера).

  3. Клиентский API MySQL (данные преобразованы в обращения SQL).

  4. Удаленная база данных -> клиентский API MySQL.

  5. Конвертация набора результатов (если надо) к формату драйвера.

2.6.2. Как использовать таблицы FEDERATED

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

Сначала Вы должны иметь таблицу на удаленном сервере, к которой Вы хотите обращаться, используя таблицу FEDERATED. Предположите, что удаленная таблица находится в базе данных federated и определена подобно этому:

CREATE TABLE test_table (id INT(20) NOT NULL AUTO_INCREMENT,
                         name VARCHAR(32) NOT NULL DEFAULT '',
                         other INT(20) NOT NULL DEFAULT '0', PRIMARY KEY(id),
                         INDEX name (name), INDEX other_key (other))
                         ENGINE=MyISAM DEFAULT CHARSET=latin1;

Пример использует таблицу MyISAM, но таблица могла бы использовать любой тип памяти.

Затем создайте таблицу FEDERATED на локальном сервере для доступа к удаленной таблице:

CREATE TABLE federated_table (id INT(20) NOT NULL AUTO_INCREMENT,
                              name VARCHAR(32) NOT NULL DEFAULT '',
                              otherINT(20) NOT NULL DEFAULT '0',
                              PRIMARY KEY(id), INDEX name (name),
                              INDEX other_key (other)) ENGINE=FEDERATED
                              DEFAULT CHARSET=latin1
       CONNECTION='mysql://root@remote_host:9306/federated/test_table';

Обратите внимание: CONNECTION заменяет COMMENT, используемый в некоторых предыдущих версиях MySQL.

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

Тип памяти FEDERATED создает только файл test_table.frm в базе данных federated.

Удаленная информация хоста указывает удаленный сервер, с которым Ваш локальный соединяется, а база данных и информация таблицы указывают, которую удаленную таблицу использовать как источник данных. В этом примере удаленный сервер обозначен как remote_host (порт 9306), так что на удаленной системе должен быть сервер MySQL, слушающий порт 9306.

Общая форма строки подключения в опции CONNECTION такова:

scheme://user_name[:password]@host_name
[:port_num]/db_name/tbl_name

Только mysql обеспечивается как значение scheme в этот момент, пароль и номер порта факультативны.

Имеются некоторые примеры строк подключения:

CONNECTION='mysql://username:password@hostname:port/database/tablename'
CONNECTION='mysql://username@hostname/database/tablename'
CONNECTION='mysql://username:password@hostname/database/tablename'

Использование CONNECTION для определения строки подключения не оптимально и, вероятно, измениться в будущем.

Потому что любой пароль, заданный в строке подключения, сохранен как простой текст, он может быть замечен любым пользователем, который может применить SHOW CREATE TABLE или SHOW TABLE STATUS для таблицы FEDERATED или сделать запрос таблицы TABLES в базе данных INFORMATION_SCHEMA.

2.6.3. Ограничения типа памяти FEDERATED

Далее перечислены свойства, которые FEDERATED не поддерживает:

Некоторые из этих ограничений могут сниматься в будущих версиях драйвера FEDERATED.

2.7. Тип памяти ARCHIVE

Тип памяти ARCHIVE используется для сохранения больших количеств данных без индексов в очень маленьком файле.

Тип памяти ARCHIVE включен в двоичные дистрибутивы MySQL. Чтобы его включить, если Вы формируете MySQL из исходного текста, вызовите configure с опцией --with-archive-storage-engine.

Чтобы исследовать исходник типа памяти ARCHIVE, смотрите каталог storage/archive исходных текстов MySQL.

Вы можете проверять, является ли доступным тип памяти ARCHIVE этой инструкцией:

mysql> SHOW VARIABLES LIKE 'have_archive';

Когда Вы создаете таблицу типа ARCHIVE, сервер создает файл формата таблицы в каталоге баз данных. Имя файла начинается с имени таблицы и имеет расширение .frm. Драйвер памяти создает и другие файлы, имена коих начинаются с имени таблицы. Данные и файлы метаданных имеют расширения .ARZ и .ARM, соответственно. Файл .ARN может появляться при операциях оптимизации.

Драйвер типа памяти ARCHIVE понимает INSERT и SELECT, но не DELETE, REPLACE или UPDATE. Это поддерживает операции ORDER BY столбцы BLOB и в основном все, кроме пространственных, типы данных. Блокировка уровня строки использована в ARCHIVE.

Начиная с MySQL 5.1.6, тип ARCHIVE поддерживает атрибут столбца AUTO_INCREMENT. Такие столбцы могут иметь уникальный или не-уникальный индекс. Попытка создавать индекс на любом другом столбце приводит к ошибке. Тип памяти ARCHIVE также поддерживает опцию таблицы AUTO_INCREMENT в CREATE TABLE и ALTER TABLE, чтобы определить начальное значение последовательности для новой таблицы или сбросить значение последовательности для существующей таблицы, соответственно.

Начиная с MySQL 5.1.6, тип ARCHIVE игнорирует столбцы BLOB, если они не запрошены, и просматривает их прошлое при чтении. Прежде, следующий две инструкции имели ту же самую логику, но с 5.1.6 вторая намного более эффективна, чем первая:

SELECT a, b, blob_col FROM archive_table;
SELECT a, b FROM archive_table;

Хранение: строки сжаты, когда они вставлены. Тип памяти ARCHIVE использует сжатие данных zlib без потерь (подробности на сайте http://www.zlib.net/). Вы можете использовать OPTIMIZE TABLE, чтобы анализировать таблицу и упаковывать ее в меньший формат (причины применения именно OPTIMIZE TABLE, изложены ниже). Тип памяти также поддерживает CHECK TABLE. Имеются несколько типов вставок, которые используются:

Поиск: при поиске строки несжаты по требованию, не имеется никакого кэша строк. Операция SELECT выполняет полный просмотр таблицы. Когда происходит SELECT, это выясняет, сколько строк в настоящее время доступны, и читает это число строк. SELECT выполняется как непротиворечивое чтение. Обратите внимание, что большое количество инструкций SELECT в течение вставки может ухудшать сжатие, если только отсроченные вставки не используется. Чтобы достигать лучшего сжатия, Вы можете использовать OPTIMIZE TABLE или REPAIR TABLE. Число строк в таблицах ARCHIVE, сообщенное SHOW TABLE STATUS, всегда точно.

Дополнительные ресурсы:

2.8. Тип памяти CSV

Тип памяти CSV хранит данные в текстовых файлах, использующих разделяемый запятыми формат значений.

Чтобы включить этот тип памяти, используйте опцию --with-csv-storage-engine в скрипте configure при сборке MySQL.

Тип памяти CSV включен в двоичные дистрибутивы MySQL-Max. Чтобы его включить, если Вы формируете MySQL из исходного текста, вызовите configure с опцией --with-csv-storage-engine. Чтобы исследовать исходник типа памяти CSV, смотрите каталог storage/csv исходных текстов MySQL.

Когда Вы создаете таблицу CSV, сервер создает файл формата таблицы в каталоге баз данных. Имя файла начинается с имени таблицы и имеет расширение .frm. Тип памяти также создает файл данных. Имя его начинается с имени таблицы и имеет расширение .CSV. Файл данных представляет собой простой текстовый файл. Когда Вы сохраняете данные в таблицу, тип памяти сохраняет это в файл данных в разделяемом запятыми формате значений.

mysql> CREATE TABLE test(i INT, c CHAR(10)) ENGINE = CSV;
Query OK, 0 rows affected (0.12 sec)
mysql> INSERT INTO test VALUES(1,'record one'),(2,'record two');
Query OK, 2 rows affected (0.00 sec)
Records: 2 Duplicates: 0 Warnings: 0

mysql> SELECT * FROM test;
+---+------------+
| i | c          |
+---+------------+
| 1 | record one |
| 2 | record two |
+---+------------+
2 rows in set (0.00 sec)

Начиная с MySQL 5.1.9, при создании таблицы CSV также создается соответствующий метафайл, который сохраняет состояние таблицы и число строк, которые существуют в таблице. Имя этого файла такое же, как имя таблицы, но с расширением CSM.

Если Вы исследуете файл test.CSV в каталоге баз данных созданный, выполняя предшествующие инструкции, его содержимое должно выглядеть следующим образом:

"1","record one"
"2","record two"

Этот формат может читаться и даже записываться прикладными программами электронных таблицы типа Microsoft Excel или StarOffice Calc.

2.8.1. Восстановление и проверка таблицы CSV

Функциональные возможности, представленные в версии 5.1.9.

Тип памяти CSV поддерживает команды CHECK и REPAIR, чтобы проверить и, если возможно, отремонтировать поврежденную таблицу CSV.

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

mysql> check table csvtest;
+--------------+-------+----------+----------+
| Table        | Op    | Msg_type | Msg_text |
+--------------+-------+----------+----------+
| test.csvtest | check | status   | OK       |
+--------------+-------+----------+----------+
1 row in set (0.00 sec)

Проверка на разрушенной таблице возвращает неисправность:

mysql> check table csvtest;
+--------------+-------+----------+----------+
| Table        | Op    | Msg_type | Msg_text |
+--------------+-------+----------+----------+
| test.csvtest | check | error    | Corrupt  |
+--------------+-------+----------+----------+
1 row in set (0.01 sec)

Если сбой проверки произошел, таблица отмечена как разрушенная. Если только таблица была отмечена как разрушенная, она будет автоматически восстановлена, когда Вы затем выполняете инструкцию CHECK или SELECT. Соответствующее разрушенное состояние и новое состояние будут отображаться при выполнении CHECK:

mysql> check table csvtest;
+--------------+-------+----------+----------------------------+
| Table        | Op    | Msg_type | Msg_text                   |
+--------------+-------+----------+----------------------------+
| test.csvtest | check | warning  | Table is marked as crashed |
| test.csvtest | check | status   | OK                         |
+--------------+-------+----------+----------------------------+
2 rows in set (0.08 sec)

Для ремонта таблицы Вы можете использовать REPAIR, это скопирует так много допустимых строк из существующих CSV данных, сколько возможно, а затем заменяет существующий CSV файл на восстановленные строки. Любые строки вне разрушенных данных будут потеряны.

mysql> repair table csvtest;
+--------------+--------+----------+----------+
| Table        | Op     | Msg_type | Msg_text |
+--------------+--------+----------+----------+
| test.csvtest | repair | status   | OK       |
+--------------+--------+----------+----------+
1 row in set (0.02 sec)

Предупреждение

Обратите внимание, что в течение ремонта только строки из CSV файла до первой поврежденной строки скопированы к новой таблице. Все другие строки, даже допустимые строки, до первой поврежденной строки удалены!

2.8.2. Ограничения CSV

Важно: тип памяти CSV не поддерживает индексацию.

Выделение разделов не обеспечивается для таблиц, использующих CSV. Начиная с MySQL 5.1.12, больше не возможно создать разбитую на разделы таблицу CSV (Глюк #19307).

2.9. Тип памяти BLACKHOLE

Тип памяти BLACKHOLE действует как черная дыра. Это принимает данные, но не сохраняет их. Поиски всегда возвращают пустой результат:

mysql> CREATE TABLE test(i INT, c CHAR(10)) ENGINE = BLACKHOLE;
Query OK, 0 rows affected (0.03 sec)
mysql> INSERT INTO test VALUES(1,'record one'), (2,'record two');
Query OK, 2 rows affected (0.00 sec)
Records: 2 Duplicates: 0 Warnings: 0
mysql> SELECT * FROM test;
Empty set (0.00 sec)

Тип памяти BLACKHOLE включен в двоичные дистрибутивы MySQL-Max. Чтобы его включить, если Вы формируете MySQL из исходного текста, вызовите configure с опцией --with-blackhole-storage-engine. Чтобы исследовать исходник типа памяти BLACKHOLE, смотрите каталог sql исходных текстов MySQL.

Когда Вы создаете таблицу BLACKHOLE, сервер создает файл формата таблицы в каталоге баз данных. Имя файла начинается с имени таблицы и имеет расширение .frm. Не имеется никаких других файлов, связанных с таблицей.

Тип памяти BLACKHOLE поддерживает все виды индексов. То есть, Вы можете включать индексные объявления в определении таблицы. Вы можете проверять наличие поддержки типа памяти BLACKHOLE этой инструкцией:

mysql> SHOW VARIABLES LIKE 'have_blackhole_engine';

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

Главный пишет в свой двоичный файл регистрации. Макет mysqld обрабатывает действия как подчиненный, применяя желательную комбинацию правил replicate-do-* и replicate-ignore-* после чего пишет новый, собственный, отфильтрованный двоичный файл регистрации. Этот фильтрованный файл регистрации передается подчиненному.

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

Другие возможные использования типа памяти BLACKHOLE:

Начиная с MySQL 5.1.4, тип памяти BLACKHOLE знает транзакции в том смысле, что совершенные транзакции записаны в двоичный файл регистрации, а отмененные транзакции уже нет.

2.10 MySQL 5 FAQ по таблицам и типам памяти

Questions and Answers

2.10.1: Имеются ли любые новые типы памяти в MySQL 5.1?

MySQL 5.1 представляет alpha-версию нового типа памяти Falcon.

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

2.10.2: А какие-то типы памяти были удалены в MySQL 5.1?

Да. MySQL 5.1 больше не поддерживает BDB. Любые существующие таблицы BDB должны быть преобразованы в другой тип перед обновлением до MySQL 5.1.

2.10.3: Каковы уникальные выгоды типа памяти ARCHIVE?

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

2.10.4: Какие новые свойства в MySQL 5.1 относятся ко всем типам памяти?

Общие новые свойства типа views, сохраненных процедур, триггеров, INFORMATION_SCHEMA, точной математики (тип столбца DECIMAL), а также тип столбца BIT относятся ко всем типам памяти. Имеются также добавления и изменения для специфических типов.

2.10.5: Какие изменения в поддерживаемые типы таблиц внесены в MySQL 5.1?

Поддержка изменилась следующим образом:

Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру