WebMoney:  WMZ Z294115950220  WMR R409981405661  WME E134003968233	Visa  4274 3200 2453 6495

Глава 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 представляет собой компонент сервера базы данных, который является ответственным за выполнение фактических операции ввода-вывода данных для базы данных, а также предоставления и предписания некоторых наборов свойств, в которых нуждается специфическая прикладная программа. Главная польза в том, что Вы в любой момент используете то, что Вам удобно, затрачивая минимум усилий и экономя много ресурсов системы сервера. Чем вообще отличаются типы памяти? Основные отличия включают: Concurrency: некоторые прикладные программы имеют более гранулированные требования блокировки (типа блокировок уровня строки) чем другие. Выбор правильной блокирующей стратегии может уменьшать непроизводительные затраты и, следовательно, улучшать полную эффективность. Эта область также включает поддержку возможностей типа многоверсионного управления параллелизма или предоставления кадра чтения. Transaction Support: не каждая прикладная программа нуждается в транзакциях, но для тех, которым это надо, имеются очень хорошо определенные требования типа совместимости с ACID. Referential Integrity: иногда надо, чтобы сервер в реляционной базе данных поддерживал справочную целостность через DDL-определенные внешние ключи. Physical Storage: это включает все от полного размера страницы для таблиц и индексов до формата, используемого для сохранения данных на физический диск. Index Support: различные прикладные программы имеют тенденцию извлекать пользу из различных индексных cтратегий. Каждый тип памяти вообще имеет собственные методы индексации, хотя некоторые (типа индексов B-tree) общие на почти всех типах. Memory Caches: различные прикладные программы лучше отвечают одним кэширующим cтратегиям, чем другим, хотя некоторые кэши памяти общие на всех типах хранения. Performance Aids: это включает многократные потоки ввода-вывода для параллельных операций, параллелизма потоков, введения контрольных точек базы данных, объемной обработки вставки и тому подобных функций. Miscellaneous Target Features: это может включать поддержку для географических операций, ограничения защиты для некоторых операций манипулирования данными и других подобных свойств. Каждый набор съемных компонентов инфраструктуры памяти разработан, чтобы предложить выборочный набор выгод для специфической прикладной программы. Наоборот, уход от набора лишних свойств компонента уменьшает ненужные непроизводительные затраты. Надо усвоить, что понимание набора требований специфической прикладной программы и выбор соответствующего типа памяти 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 поддерживает следующие типы памяти: MyISAM: применяемый по умолчанию тип памяти MySQL, который наиболее используется в Web, хранилищах данных и других средах прикладных программ. MyISAM обеспечивается во всех конфигурациях MySQL. Описан в книге "Руководство администратора СУБД MYSQL", глава 7, раздел "7.1 Таблицы MyISAM". InnoDB: использован для прикладных программ диалоговой обработки запросов и ряда свойств, включая поддержку транзакций ACID и внешние ключи. InnoDB включен по умолчанию во все двоичные дистрибутивы MySQL 5.1. Описан в книге "Руководство администратора СУБД MYSQL", глава 7, раздел "7.6 Таблицы InnoDB". Falcon: работает с многократными потоками и безопасной средой транзакции, которая безопасно хранит данные при обеспечении весьма высокой производительности. ПРЕДУПРЕЖДЕНИЕ: Falcon в настоящее время обеспечивается только внутри ветки MySQL 5.1 и не рассматривается готовым к выпуску. Это обеспечивается только для целей тестирования и оценки на этой стадии. Memory: сохраняет все данные в RAM для чрезвычайно быстрого доступа в средах, которые требуют быстрых поисковых таблиц. Этот тип памяти был прежде известен как HEAP. Описан в книге "Руководство администратора СУБД MYSQL", глава 7, раздел " 7.4 Таблицы HEAP". Merge: позволяет MySQL DBA или разработчику логически группировать ряд идентичных MyISAM-таблиц и ссылаться на них как на один объект. Хороши для VLDB-сред, типа хранилищ данных. Описан в книге "Руководство администратора СУБД MYSQL", глава 7, раздел " 7.2 Таблицы MERGE". Archive: обеспечивает совершенное решение для сохранения и восстановления больших количеств редко используемых исторических, архивированных данных. Federated : предлагает способность связать отдельные серверы MySQL, чтобы создать одну логическую базу данных из многих физических. Очень хорош для распределенной среды данных. NDB Cluster (он же NDB): кластерный вариант базы данных, который особенно подходит для прикладных программ с высокоэффективными потребностями поисковой таблицы, которые также требуют самой высокой возможной степени полезного времени и доступности. Описан подробно в моей работе " MySQL Cluster". CSV: хранит данные в текстовых файлах, использующих отделяемый запятыми формат значений. Вы можете использовать CSV, чтобы легко обмениваться данными между другим программным обеспечением и прикладными программами, которые могут импортировать и экспортировать в формате CSV. Blackhole : принимает к записи, но не сохраняет данные, а поиски всегда возвращают пустой набор. Функциональные возможности могут использоваться в распределенном проекте базы данных, где данные автоматически скопируются, но не сохранены локально. Example: это тип памяти, который не делает ничего. Вы можете создавать таблицы с ним, но никакие данные не могут быть сохранены в них или восстановлены из них. Цель этого типа памяти в том, чтобы служить примером того, как вообще надо писать типы памяти. Это прежде всего представляет интерес для разработчиков. Эта глава описывает каждый из типов памяти 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] Да Да Да Да Да Поддержка кэша запросов Да Да Да Да Да Модификация статистики для словаря данных Да Да Да Да Да Некоторые необходимые пояснения: [1] Поддерживает пространственные типы данных, но не выполняет индексацию таких данных. [2] Выполнено в сервере (через функции шифрования), а не в типе памяти. [3] Выполнено в сервере, а не в типе памяти. [4] EB = exabyte (экзабайт = 1024 * 1024 терабайт). 2.2.2. Сравнение транзакционных и не транзакционных таблиц Транзакционно-безопасные таблицы (TST) имеют несколько преимуществ над не транзакционно-безопасными таблицами (NTST): Они более надежные. Даже если MySQL терпит крах, или Вы получаете аппаратные проблемы, Вы можете получить Ваши данные обратно автоматическим восстановлением или из копии плюс файл регистрации транзакции. Вы можете объединять много инструкций и принимать их все в то же самое время инструкцией COMMIT (если autocommit выключен). Вы можете выполнять ROLLBACK, чтобы игнорировать Ваши изменения (если autocommit выключен). Если произошел сбой модификации, все Ваши изменения вернутся. С не транзакционно-безопасными таблицами все изменения, которые имели место, постоянны. Транзакционно-безопасные типы памяти могут обеспечивать лучший параллелизм для таблиц, которые делают много модификаций одновременно с чтением. Вы можете объединять транзакционно-безопасные и не транзакционно-безопасные таблицы в тех же самых инструкциях. Однако, хотя 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. Для дальнейшей информации, документации, руководств по установке, ошибкам, сообщениям, любой справки или помощи по работе с этими типами памяти, пожалуйста, входите в контакт с разработчиком непосредственно. На текущий момент есть следующие сторонние типы памяти: PrimeBase XT (PBXT): PBXT был разработан для современного web-основанного параллелизма. RitmarkFS RitmarkFS позволяет Вам обращаться и управлять файловой системой, используя SQL-запросы. RitmarkFS также поддерживает репликацию файловых систем и трэкинг изменений. Distributed Data Engine: Open Source проект, который специализирован, чтобы обеспечить поддержку распределенных данных согласно статистике рабочей нагрузки. mdbtools: съемный тип памяти, который позволяет доступ только для чтения к .mdb-файлам базы данных Microsoft Access. solidDB for MySQL разработан для задание-критических реализаций, которые требуют транзакционные базы данных. solidDB многопоточный драйвер, который полностью поддерживает ACID со всеми ожидаемыми уровнями изоляции транзакции, блокировкой уровня строки и многоверсионным управлением параллелизма (MVCC) с не блокируемыми чтением и записью. Для подробной информации относительно разработки типа памяти, который может использоваться со съемной архитектурой памяти обратитесь к 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 поддерживает ряд главных особенностей, которые делают возможным его применение в среде с большими нагрузками: Multi Version Concurrency Control (MVCC) дает возможность записям и таблицам модифицироваться без непроизводительных затрат, связанных с блокировками уровня строки. Реализация MVCC фактически устраняет потребность блокировать таблицы или строки в течение процесса модификации. Гибкая блокировка, включая гибкие уровни блокировки и интеллектуальное обнаружение тупика хранит защищенные данные и транзакции, выполняя текущие операции в максиальном быстродействии. Оптимизирован для современных CPU, чтобы поддерживать много потоков, позволяя много транзакций и быструю обработку каждой транзакции. Transaction-safe (полностью совместим с ACID) и способен обрабатывать многократные параллельные транзакции. Последовательный файл регистрации обеспечивает высокую эффективность и возможности восстановления без того, чтобы жертвовать эффективностью. Продвинутые индексы B-Tree. Сервер предписывает справочную целостность и всегда гарантирует проверку правильности данных. Сжатие данных сохраняет информацию на диск в сжатом формате, сжимая и декомпрессируя данные на лету. Результат в меньших и более эффективных физических размерах данных. Интеллектуальное дисковое управление автоматически управляет размером файла на диске, расширениями и восстановлением места. Данные и индексное кэширование обеспечивают быстрый доступ к данным без требования загрузить индексные данные с диска. Неявные точки сохранения гарантируют целостность данных в течение транзакций. 2.4.2. Параметры конфигурации Параметры конфигурированы через стандартный файл my.cnf или my.ini. Параметры могут быть конфигурированы, определяя имя параметра и соответствующее значение через пробел. Значения Memory могут быть определены в байтах или числом, сопровождаемым kb, mb или gb. falcon_min_record_memory (Record Cache Base) устанавливает минимальный объем памяти, который будет распределен для кэширования данных при записи. Когда кэш-память убирает мусор, процесс остановится, пока использование кэша не достигнет этого значения. Значение по умолчанию: falcon_max_record_memory/2 (10 MB). falcon_max_record_memory (Record Cache Top) устанавливает максимальный размер памяти, которая будет распределена для кэширования данных при записи. Значение по умолчанию 20 MB. falcon_page_cache_size (Page Cache Size) устанавливает объем памяти, который будет распределен для кэширования страниц из файла пространства таблицы. Значение по умолчанию 4 MB. Связь между кэшем записи и кэшем страницы управляется информацией, которая кэшируется каждой системой. Целые записи, которые находятся в активном использовании (читаемые или модифицируемые) сохранены внутри кэша записи, однако, данные BLOB сохранены только внутри кэша страницы. Кэш страницы используется, чтобы сохранить метаданные базы данных, данные BLOB и индексы таблицы. Параметры Falcon также могут быть установлены в командной строке mysqld через использование следующих параметров командной строки: --falcon-max-record-memory=# --falcon-min-record-memory=# --falcon-page-cache-size=# Вы можете также допускать и отключать тип памяти Falcon при запуске, обеспечивая эти параметры mysqld, если этот mysqld включает тип памяти Falcon: --falcon включает Falcon. --skip-falcon выключает 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 объединяет продвинутые методы с упрощенной структурой, которая приводит к высокоэффективной транзакционной базе данных, которая требует небольшого сопровождения или поиска неисправностей администратором базы данных. Файл данных пользователя сохраняет данные Falcon. Последовательный файл регистрации Falcon содержит недавно совершенные изменения данных, индексные изменения и транзакционную информацию. Также обеспечивает средства восстановления данных. Кэш страницы хранит страницы базы данных. Кэш записи хранит копии активных и нейтральных записей. Память системы хранит информацию контекста транзакции, индексные акселераторы и метаданные системы. Рабочие потоки являются фоновыми потоками. Имеются два потока: поток "gopher" перемещает данные из последовательный файла регистрации Falcon в кэш страницы базы данных и из кэша страниц на диск. Второй поток программы записи страницы, который пишет страницы с blob. 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. Процесс обратной перемотки Обратные перемотки транзакции обработаны потоком для соответствующей транзакции. Процесс обратной перемотки выполняет следующие действия: Отступающие индексные модификации. Отменяет любые данные blob, созданные транзакцией. Освобождает распределенные слоты записи. Отменяет версию записи, созданную в памяти. 2.4.5.2.2. Групповое завершение транзакций Для эффективности Falcon использует систему, которая гарантирует, что все ждущие обработки модификации последовательного файла регистрации записаны на диск в то же самое время. Falcon может иметь многократные активные транзакции, но транзакции записывают все ждущие обработки изменения последовательного файла регистрации на диск только однократно, уменьшая число записей на диск и улучшая полную эффективность последовательного файла регистрации. Например: Транзакция 1 создает все необходимые входы файла регистрации и начинает записывать файл регистрации на диск. В то время как транзакция 1 завершается, транзакции 2 и 3 записывают их входы в последовательный файл регистрации. Как только транзакция 1 закончила физическую запись, или транзакция 2 или 3 (но не обе) запишут незаписанную часть данных, находящуюся в оперативной памяти, файл регистрации будет готов к сбросу на диск. Потому как обе транзакции произошли после с последней записи на диск последовательного файла регистрации, информация для обемх записана на диск в то же самое время. В то время как транзакции 2 и 3 записывают, транзакции 4, 5 и 6 записываются в журнал в оперативной памяти. Когда запись для 2 и 3 завершается, входы для 4, 5 и 6 записаны. Результат вышеупомянутого процесса: имеются только три физические записи на диск, даже при том, что имеется шесть транзакций в последовательности: Транзакция 1, Транзакции 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 относительно кэширования памяти включают: Log Cache информация файла регистрации сохраняется в памяти и сбрасывается на диск, когда транзакции совершаются. Falcon хранит восемь окон для чтения и записи в журнал, и каждое окно 1 MB. System and Index Cache данные, необходимые Falcon (определения таблицы и полей, состояние транзакции и т.д.) также поддерживаются в памяти для справочника. Кроме того, локальные индексные акселераторы представляют индексные сегменты, созданные выполняющейся транзакцией, также сохранены в памяти системы. Когда транзакция изменяет индексированные поля, это формирует индексный раздел акселератора в памяти системы, представляя изменения. При завершении транзакции все индексные измене ния для транзакции записаны в сортируемом порядке в последовательный вход и позже объединены с постоянным индексом. Page Cache страницы базы данных читаются с диска для специфической базы данных. Размер кэша страницы управляется параметром falcon_page_cache_size, значение по умолчанию которого 4 MB установлено в файле my.cnf. Хотя изменения записи и индекса идут в последовательный файл регистрации прежде, чем запишутся в страницы базы данных, данные blob записаны непосредственно в кэш страницы. Это не дает регистрировать большие элементы данных, которые редко вызваны или изменены транзакцией, которая создает их. Record Cache кэш записи представляет собой область памяти в зоне ожидания строк, которые были запрошены запросами конечного пользователя для специфической базы данных или созданы активными транзакциями. Обратите внимание, что этот кэш отличается от традиционных кэшей данных тем, что только специфические строки, необходимые прикладным программам, постоянно находятся в кэше в противоположность всем данным страницы (которая может содержать только подмножества необходимой информации). Кэш записи может хранить несколько версий записей, которые изменились или удалены. Эта методика гарантирует, что активные данные, необходимые, чтобы удовлетворять запросы пользователя находятся в памяти, сокращают время доступа к строке и уменьшают кэш, не включая незапрошенную информацию. Кэш записи также помогает в обеспечении механизм многоверсионного управления параллелизма (MVCC). Кэш записи управляется двумя параметрами. Параметр falcon_min_record_memory (заданный по умолчанию в 10 MB) определяет минимальное количество RAM, обеспеченной кэшу записи, а falcon_max_record_memory (заданный по умолчанию в 20 MB) ограничивает общую сумму памяти, доступной кэшу. Из-за поддержки кэша записи транзакциями, используется поток-мусоросборщик, чтобы гарантировать только горячие данные постоянно находятся в кэше. Когда ограничение falcon_max_record_memory достигнуто, Falcon рассматривает демографию данных в кэше и удаляет самые старые поколения. Этот процесс более усложнен, чем стандартный алгоритм LRU, используемый многими системами баз данных, но это более эффективно и быстро. 2.4.5.5. Потоки Falcon Falcon использует два рабочих потока, чтобы обработать информацию внутри структур Falcon. Один поток посвящен перемещению совершенных изменений данных из файла регистрации на страницы и объединению индексных изменений с постоянными индексными данными. Второй обрабатывает периодический сброс кэша страницы и убирает мусор, распределенный внутри кэша записи. 2.4.5.6. Сжатие данных Данные, сохраненные в пространстве таблиц Falcon сжаты на диске, но сохранены в несжатом формате в памяти. Сжатие происходит автоматически, когда данные переданы на диск. 2.4.5.7. Слот записи Слот записи представляет собой внутренний идентификатор записи, который используется, чтобы найти записи в памяти и на диске. Это по существу указатель на страницы, которые содержат данные для специфической записи. Новый слот записи создан для каждой записи на время продолжительности существования этой записи. Слот записи освобожден только, когда запись удалена из базы данных. 2.4.6. Ограничения Имеется ряд ограничений в alpha-версии Falcon. В дальнейшем они постепенно будут сниматься: Не работает SELECT FOR UPDATE. Для Alpha-версии максимальная длина ключа ограничена 1100 байтами. Уровни изоляции Serializable не обеспечиваются. Конфигурация времени ожидания для блокировки не обеспечивается. Распределенные транзакции не обеспечиваются. Имеется ограничение 232 (4.29 миллиарда) строк для одиночной таблицы. Используя много таблиц внутри того же самого пространства таблиц Вы можете иметь больше, чем это число записей. В будущем выпуске это ограничение будет удалено. Размеры страницы с перестраиваемой конфигурацией не обеспечиваются, но запланированы на будущий выпуск. Таблицы Falcon могут поддерживать до 32000 столбцов. Каждое пространство таблиц имеет ограничение в 232 страниц внутри одиночного пространства. Через комбинацию размера страницы и максимального числа страниц имеется ограничение 140737488355328 байт (128 TB) одиночного пространства таблиц. Интерактивное резервирование не обеспечивается, но поддержка запланирована в будущем выпуске. Поддержка внешнего ключа в настоящее время недоступна. Хотя максимальная доступная память внутри пространства таблиц 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. Дополнительные ресурсы: Форум, специализированный на типе FEDERATED, доступен на http://forums.mysql.com/list.php?105. 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. Поток информации таков: SQL-обращения выданы локально. Используется MySQL handler API (данные в формате драйвера). Клиентский API MySQL (данные преобразованы в обращения SQL). Удаленная база данных -> клиентский API MySQL. Конвертация набора результатов (если надо) к формату драйвера. 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 не поддерживает: В первой версии удаленный сервер должен быть MySQL-сервером. Поддержка FEDERATED для других СУБД может быть добавлена в будущем. Удаленная таблица, на которую указывает таблица FEDERATED, ДОЛЖНА существовать прежде, чем Вы попробуете обращаться к ней через драйвер FEDERATED. Возможно для одной таблицы FEDERATED указывать на другую, но Вы должны быть внимательны, чтобы не создать цикл. Не имеется никакой поддержки транзакций. Не имеется никакого способа, чтобы узнать, изменилась ли удаленная таблица. Причина этого в том, что эта таблица должна работать подобно файлу данных, который никогда не был записан в чем-нибудь другом, чем база данных. Целостность данных в локальной таблице могла бы быть нарушена, если бы имелось любое изменение для удаленной базы данных. FEDERATED понимает SELECT, INSERT, UPDATE, DELETE и индексы. Это не поддерживает ALTER TABLE или любые инструкции Data Definition Language, кроме DROP TABLE. Текущая реализация не использует подготовленные инструкции. Любая инструкция DROP TABLE, выданная для таблицы FEDERATED, удалит только локальную таблицу, но не удаленную. Реализованы SELECT, INSERT, UPDATE и DELETE, но не HANDLER. Таблицы 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. Имеются несколько типов вставок, которые используются: Инструкция INSERT только помещает строки в буфер сжатий, а буферные пишется по мере необходимости. Вставка в буфер защищена блокировкой. SELECT сбрасывает все данные на диск, если вставки не были INSERT DELAYED (такие сбрасываются по мере необходимости). Объемная вставка видима только после того, как завершается, если другие вставки не происходят в то же самое время, тогда это может быть замечено частично. SELECT никогда не вызывает сброс объемной вставки, если нормальная вставка не происходит в это время. Поиск: при поиске строки несжаты по требованию, не имеется никакого кэша строк. Операция SELECT выполняет полный просмотр таблицы. Когда происходит SELECT, это выясняет, сколько строк в настоящее время доступны, и читает это число строк. SELECT выполняется как непротиворечивое чтение. Обратите внимание, что большое количество инструкций SELECT в течение вставки может ухудшать сжатие, если только отсроченные вставки не используется. Чтобы достигать лучшего сжатия, Вы можете использовать OPTIMIZE TABLE или REPAIR TABLE. Число строк в таблицах ARCHIVE, сообщенное SHOW TABLE STATUS, всегда точно. Дополнительные ресурсы: Форум, специализированный на типе ARCHIVE, доступен на http://forums.mysql.com/list.php?112. 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: Проверка синтаксиса файла дампа. Измерение непроизводительных затрат из двоичной регистрации, сравнивая эффективность, используя BLACKHOLE с и без двоичной регистрации. 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? Поддержка изменилась следующим образом: Поддержка для таблиц ISAM была удалена в MySQL 5.0, и Вы должны теперь использовать таблицы MyISAM вместо ISAM. Чтобы преобразовать таблицу tblname из типа ISAM в MyISAM, просто выдайте инструкцию типа этой: ALTER TABLE tblname ENGINE=MYISAM; Внутренний RAID для таблиц MyISAM был также удален в MySQL 5.0. Это прежде использовалось, чтобы позволить большие таблицы в файловых системах, которые не поддерживали размеры файла больше, чем 2 GB. Все современные файловые системы учитывают большие таблицы, кроме того, теперь имеются другие решения типа таблиц MERGE и views. Тип столбца VARCHAR теперь сохраняет конечные пробелы во всех типах памяти. Таблицы MEMORY (прежде известные как таблицы HEAP) также могут содержать столбцы VARCHAR.

Поиск На сайте В Яндексе