Хранилище данных Falcon

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

Хранилища MySQL

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

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

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

Хранилище Falcon

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

В настоящее время (5.2.0-alpha), хранилище находится в состоянии alpha, т.е. в нем нет всей запланированной функциональности и возможны ошибки кода. Тем не менее, эта версия позволяет оценить будущее хранилище и понять, насколько оно хорошо будет подходить к использованию с вашими приложениями.

Запланированная функциональность Falcon

При разработке Falcon планировалось создать следующую функциональность:

• полная поддержка транзакций (full ACID)
• поддержка ссылочной целостности таблиц
• хранение всех типов данных MySQL
• оптимизации для работы с большим количеством оперативной памяти
• полная мультиверсионность, позволяющая уменьшить, а иногда полностью устранить необходимость в блокировках
• сжатие данных

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

Falcon в файловой системе

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

Пусть мы создаем Falcon-таблицу в базе данных test:

mysql> CREATE TABLE tbl (a INT) ENGINE=Falcon;
Query OK, 0 rows affected (1.24 sec)

При этом сервер автоматически создает следующие файлы в каталоге данных:

• test/tbl.frm — файл структуры таблицы, такой же, как и для других типов хранилищ
• test.fts — файл данных Falcon (содержит данные, индексы и прочую информацию о всех таблицах Falcon в базе test)
• test.fl1, test.fl2 — файлы журналов Falcon (содержат журналы транзакций, которые используются для отката и применения транзакций)

Очевидно, что отсутствие возможности настройки названий этих файлов приводит к ограничению на переносимость таблиц и баз данных на другие диски (в MyISAM, например, можно переносить отдельные таблицы на другие физические диски, увеличивая производительность, а в InnoDB — отдельные файлы данных). Вы все еще можете воспользоваться методом переноса файлов в UNIX-системах с помощью символических ссылок, однако для Windows рабочего метода пока еще нет (и не работает старый метод переноса всех баз данных, т.к. файлы данных Falcon хранятся вне основного каталога базы).

Оптимизации Falcon

Несмотря на многие указанные ограничения, хранилище Falcon создавалось как хранилище более быстрое, чем InnoDB. Скорость работы Falcon во многом зависит от того, какое количество памяти вы выделяете для его работы. Вы можете настроить ресурсы хранилища (так же, как и для любого другого хранилища), установив значения серверных переменных.

mysql> SHOW VARIABLES LIKE 'falcon%';
+--------------------------+----------+
| Variable_name            | Value    |
+--------------------------+----------+
| falcon_log_dir           |          |
| falcon_max_record_memory | 20971520 |
| falcon_min_record_memory | 0        |
| falcon_page_cache_size   | 4194304  |
| falcon_log_mask          | 0        |
| falcon_debug_server      | OFF      |
| falcon_page_size         | 4096     |
+--------------------------+----------+
7 rows in set (0.01 sec)

Помимо различных переменных, предназначенных для разработчиков, в этом списке есть переменные, которые непосредственно влияют на производительность хранилища. Это переменные falcon_max_record_memory, falcon_min_record_memory и falcon_page_cache_size.

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

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

falcon_page_cache_size устанавливает размер кэша страниц при чтении данных с диска. В этот кэш попадают страницы данных из файла данных. Обратите внимание, что данные типа BLOB не попадают в record_cache (ввиду их возможно значительного размера), однако они могут попасть в page_cache. Тем не менее, оптимизация происходит при работе с record_cache, поэтому если вы используете небольшое количество BLOB-данных, вам следует выделить больше памяти под record_cache, иначе - сбалансировать кэши по объему.

Работа Falcon с диском

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

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

При чтении и записи данных на диск, Falcon использует два потока. Один из потоков («gopher») переносит данные из кэша на диск. Он же объединяет новые индексы с индексами, хранящимися на диске. Второй поток в фоновом режиме освобождает место на диске и обновляет кэш страниц данных.

При записи данных на диск они архивируются, что позволяет уменьшить занимаемое данными на диске место. В оперативной памяти данные хранятся в распакованном состоянии, поэтому уменьшения производительности практически нет.

Заключение

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