Хранилище данных 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. Все же,
1-ые три уровня изоляции работают так, как и ожидается.

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

В файловой системе Falcon делает автоматом по три файла для каждой
базы данных, использующей таблицы Falcon. В данной версии никакие
свойства этих файлов не могут быть настроены. В предстоящем
планируется возможность опции 2-ух файлов. В отличие от 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.

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

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

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

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

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

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

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

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

Заключение

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

Аналогичный товар: Комментирование на данный момент запрещено, но Вы можете оставить ссылку на Ваш сайт.

Комментарии закрыты.