Как мы знаем, разные механизмы хранения в MySQL имеют разные файловые структуры. Каждая таблица в MySQL 5.6 должна иметь файл .frm в каталоге базы данных, соответствующий имени таблицы. Но то, где находятся остальные данные, зависит от механизма хранения.
Для MyISAM у нас есть файлы .MYI и .MYD в каталоге базы данных (если не установлены специальные настройки); для InnoDB у нас могут быть данные, хранящиеся в одном табличном пространстве (обычно ibdata1 в каталоге базы данных) или в виде файла на таблицу (или, лучше сказать, файл на раздел), создавая один файл с расширением .ibd для каждой таблицы / раздела. TokuDB, начиная с этой версии (7.1.7), имеет собственный инновационный подход к хранению содержимого таблицы.
Я создал таблицу в тесте базы данных, имеющую следующую структуру:
CREATE TABLE `mytable` ( `id` int(10) unsigned NOT NULL, `c` varchar(15) NOT NULL, `d` int(11) NOT NULL, PRIMARY KEY (`id`), KEY `c` (`c`), KEY `d` (`d`,`c`), KEY `d_2` (`d`) ) ENGINE=TokuDB DEFAULT CHARSET=latin1
В каталоге «test» базы данных нет файлов, кроме mytable.frm, однако в каталоге базы данных создано несколько файлов:
-rwxrwx--x 1 mysql mysql 40960 Jul 29 21:01 _test_mytable_key_c_22f19b0_3_19_B_0.tokudb -rwxrwx--x 1 mysql mysql 16896 Jul 29 21:02 _test_mytable_key_d_2_22f223b_3_19_B_0.tokudb -rwxrwx--x 1 mysql mysql 16896 Jul 29 21:01 _test_mytable_key_d_22f1c9a_3_19_B_0.tokudb -rwxrwx--x 1 mysql mysql 32768 Jul 29 21:01 _test_mytable_main_22f1818_2_19.tokudb -rwxrwx--x 1 mysql mysql 65536 Jul 29 21:02 _test_mytable_status_22f1818_1_19.tokudb
Как видите, таблица представлена серией файлов — файлом «status», «главной» таблицей, которая содержит индекс кластерного фрактального дерева (первичный ключ) плюс каждый индекс хранится в своем собственном файле. Обратите внимание, как называются файлы — чтобы включить имя базы данных, имя файла и имя ключа (имя, которое вы даете ключу, а не соответствующие столбцы). Затем следует что-то вроде «22f1818_1_19», которое, как я полагаю, является внутренним идентификатором объекта TokuDB.
Обратите внимание, что (по крайней мере, в моей системе) файлы создаются с установленным исполняемым битом. Я не вижу причин для этого, и это, вероятно, просто небольшая ошибка.
Другая незначительная ошибка (или предполагаемое ограничение дизайна?), Похоже, заключается в том, что TokuDB может потерять фактическое имя таблицы в имени файла при изменении таблицы. Например, когда я изменил таблицу, чтобы удалить один из ключей и добавить еще один с именем «superkey», я вижу, что имя «mytable» заменяется на «sql_390c_247», которое очень похоже на временную таблицу, которая использовалась для перестройки таблицы:
-rwxrwx--x 1 mysql mysql 32768 Jul 29 21:15 _test_sql_390c_247_key_c_22f6f7d_3_19.tokudb -rwxrwx--x 1 mysql mysql 32768 Jul 29 21:15 _test_sql_390c_247_key_d_22f6f7d_5_19.tokudb -rwxrwx--x 1 mysql mysql 32768 Jul 29 21:15 _test_sql_390c_247_key_superkey_22f6f7d_4_19.tokudb -rwxrwx--x 1 mysql mysql 32768 Jul 29 21:14 _test_sql_390c_247_main_22f6f7d_2_19.tokudb -rwxrwx--x 1 mysql mysql 32768 Jul 29 21:14 _test_sql_390c_247_status_22f6f7d_1_19.tokudb
Мне нравится подход хранения разных индексов в разных файлах, поскольку это значительно упрощает удаление индекса, а также позволяет размещать индексы в другом хранилище, если это необходимо по какой-то причине. Однако помещать все таблицы в корень базы данных — плохая идея — наличие значительного количества таблиц, особенно с несколькими индексами, каждый из которых создает огромное количество файлов, делает неудобным работу с каталогом базы данных (который часто содержит другие файлы — файлы журналов, двоичные журналы и т. д.), плюс это может привести к тому, что файловые системы достигнут своих пределов или ограничений производительности при работе с огромным количеством файлов в одном каталоге.
Многим также нравится иметь файлы в каталоге данных, поскольку это позволяет в основных конфигурациях использовать простые инструменты Unix, такие как du, чтобы увидеть, сколько места физически занимает данная база данных.
Как и InnoDB и MyISAM, TokuDB создаст отдельный набор файлов для каждого раздела, поместив его в одну и ту же директорию, имея ту же таблицу, разделенную HASH, на первичный ключ с 4 разделами, которые я наблюдаю:
-rwxrwx--x 1 mysql mysql 32768 Jul 29 21:22 _test_sql_390c_25b_P_p0_key_c_22f9f35_3_19.tokudb -rwxrwx--x 1 mysql mysql 32768 Jul 29 21:22 _test_sql_390c_25b_P_p0_key_d_22f9f35_5_19.tokudb -rwxrwx--x 1 mysql mysql 32768 Jul 29 21:22 _test_sql_390c_25b_P_p0_key_superkey_22f9f35_4_19.tokudb -rwxrwx--x 1 mysql mysql 32768 Jul 29 21:22 _test_sql_390c_25b_P_p0_main_22f9f35_2_19.tokudb -rwxrwx--x 1 mysql mysql 32768 Jul 29 21:22 _test_sql_390c_25b_P_p0_status_22f9f35_1_19.tokudb -rwxrwx--x 1 mysql mysql 32768 Jul 29 21:22 _test_sql_390c_25b_P_p1_key_c_22f9f8e_3_19.tokudb -rwxrwx--x 1 mysql mysql 32768 Jul 29 21:22 _test_sql_390c_25b_P_p1_key_d_22f9f8e_5_19.tokudb -rwxrwx--x 1 mysql mysql 32768 Jul 29 21:22 _test_sql_390c_25b_P_p1_key_superkey_22f9f8e_4_19.tokudb -rwxrwx--x 1 mysql mysql 32768 Jul 29 21:22 _test_sql_390c_25b_P_p1_main_22f9f8e_2_19.tokudb -rwxrwx--x 1 mysql mysql 32768 Jul 29 21:22 _test_sql_390c_25b_P_p1_status_22f9f8e_1_19.tokudb -rwxrwx--x 1 mysql mysql 32768 Jul 29 21:22 _test_sql_390c_25b_P_p2_key_c_22f9fe1_3_19.tokudb -rwxrwx--x 1 mysql mysql 32768 Jul 29 21:22 _test_sql_390c_25b_P_p2_key_d_22f9fe1_5_19.tokudb -rwxrwx--x 1 mysql mysql 32768 Jul 29 21:22 _test_sql_390c_25b_P_p2_key_superkey_22f9fe1_4_19.tokudb -rwxrwx--x 1 mysql mysql 32768 Jul 29 21:22 _test_sql_390c_25b_P_p2_main_22f9fe1_2_19.tokudb -rwxrwx--x 1 mysql mysql 32768 Jul 29 21:22 _test_sql_390c_25b_P_p2_status_22f9fe1_1_19.tokudb -rwxrwx--x 1 mysql mysql 32768 Jul 29 21:22 _test_sql_390c_25b_P_p3_key_c_22f9ffb_3_19.tokudb -rwxrwx--x 1 mysql mysql 32768 Jul 29 21:22 _test_sql_390c_25b_P_p3_key_d_22f9ffb_5_19.tokudb -rwxrwx--x 1 mysql mysql 32768 Jul 29 21:22 _test_sql_390c_25b_P_p3_key_superkey_22f9ffb_4_19.tokudb -rwxrwx--x 1 mysql mysql 32768 Jul 29 21:22 _test_sql_390c_25b_P_p3_main_22f9ffb_2_19.tokudb -rwxrwx--x 1 mysql mysql 32768 Jul 29 21:22 _test_sql_390c_25b_P_p3_status_22f9ffb_1_19.tokudb
Как видите, к каждому из файлов добавлены суффиксы от «P_p1 ″ до« P_p2 ″.
Какие другие файлы существуют помимо тех, которые приходят из таблиц TokuDB?
Есть несколько системных файлов
-rwxrwx--x 1 mysql mysql 32768 Jul 29 21:16 tokudb.directory -rwxrwx--x 1 mysql mysql 16384 Jul 17 19:09 tokudb.environment -rwxrwx--x 1 mysql mysql 1048576 Jul 29 21:22 tokudb.rollback
Которые, как говорят их имена, содержат «каталог» — метаданные о таблицах и индексах в системе, откат — содержит данные, которые необходимы для отката транзакции, а среда содержит некоторую информацию о среде. Я не копался в этом — я просто вижу, что этот файл не изменился после того, как я запустил экземпляр в отличие от других 2, которые изменяются при изменении структуры таблицы ( tokudb.directory ) или при изменении базы данных ( tokudb.rollback )
Далее вы увидите
-rw------- 1 mysql mysql 0 Jul 17 19:09 __tokudb_lock_dont_delete_me_data -rw------- 1 mysql mysql 0 Jul 17 19:09 __tokudb_lock_dont_delete_me_environment -rw------- 1 mysql mysql 0 Jul 17 19:09 __tokudb_lock_dont_delete_me_logs -rw------- 1 mysql mysql 0 Jul 17 19:09 __tokudb_lock_dont_delete_me_recovery -rw------- 1 mysql mysql 0 Jul 17 19:09 __tokudb_lock_dont_delete_me_temp
Я вижу, что TokuDB действительно пытается заблокировать экземпляр базы данных, предотвращая одновременный доступ к каталогу с несколькими файлами. Я думаю, что InnoDB делает это более чистым способом, устанавливая блокировку системного табличного пространства, которая не требует дополнительных файлов… хотя у команды TokuDB могла бы быть определенная причина сделать это таким образом. Может быть, Oracle имеет патент на программное обеспечение по предотвращению одновременной работы базы данных путем блокировки файла?
Наконец, есть файл журнала транзакций:
-rwx------ 1 mysql mysql 37499084 Jul 29 21:34 log000000002593.tokulog25
Файлы журналов транзакций TokuDB не выделяются заранее, как InnoDB, но они больше похожи на двоичные журналы MySQL — они последовательно увеличивают номера файлов, которые будут увеличиваться по мере создания новых файлов, сам файл будет расти по мере записи новых данных в журнал. Как я понимаю, ротация журналов происходит во время контрольной точки, и вы обычно видите только один файл журнала.
Мне нужно еще многое узнать о структуре файлов TokuDB и назначении отдельных файлов, но я надеюсь, что это даст вам хороший базовый обзор механизма хранения TokuDB MySQL.
Дальнейшее чтение: Рич Прохаска (Rich Prohaska) из команды TokuDB был любезен, чтобы поделиться со мной еще несколькими полезными материалами , для тех, кому было любопытно: файлы и дескрипторы файлов TokuDB , дизайн отдельных каталогов баз данных.