InnoDB: подсистема хранения базы данных MySQL

InnoDB - система хранения таблиц в СУБД MySQLInnoDB является транзакционной подсистемой хранения по умолчанию в MySQL, а также наиболее значимой и широко используемой подсистемой хранения в целом. Она была создана для обработки большого количества краткосрочных транзакций, которые выполняются благополучно намного чаще, чем откатываются. Высокая про­изводительность и автоматическое восстановление после сбоя делают ее популярной и для нетранзакционных целей. Вам следует применять InnoDB для своих таблиц, пока не возникнет необходимость использовать другую подсистему хранения. Если вы хотите изучить подсистемы хранения, не стоит рассматривать их все слишком подробно, но обязательно потратьте время на глубокое ознакомление с InnoDB, чтобы узнать о ней как можно больше.



 

История InnoDB

История релизов InnoDB довольно сильно запутана, но очень помогает разо­браться в этой подсистеме хранения данных. В 2008 году для версии MySQL 5.1 был выпущен так называемый плагин InnoDB. Это было следующее поколение InnoDB, созданное компанией Oracle, которой в то время принадлежала InnoDB, но не MySQL. По разным причинам, которые лучше обсуждать за кружкой пива, MySQL продолжала поставлять более старую версию InnoDB, скомпилированную на сервер. Но вы могли по собственному желанию отключить ее и установить новый, более эффективный и лучше масштабируемый плагин InnoDB. В конце концов компания Oracle приобрела компанию Sun Microsystems и, следовательно, СУБД MySQL и удалила старую кодовую базу, заменив ее «плагином» по умолча­нию в версии MySQL 5.5. (Да, это означает, что теперь «плагин» фактически скомпилирован, а не установлен как плагин. Старая терминология изживается с трудом.)

Современная версия InnoDB, представленная в качестве плагина InnoDB в MySQL 5.1, обеспечивает новый функционал, например построение индексов путем сортировки, возможность удаления и добавления индексов без перестройки всей таблицы, новый формат хранения данных, который предполагает сжатие, новый способ хранения больших объемов данных, таких как столбцы BLOB, и управления форматом файлов. Многие люди, которые работают с MySQL 5.1, не применяют этот плагин, чаще всего потому, что не подозревают о нем. Если вы используете MySQL 5.1, убедитесь, по­жалуйста, в том, что применяете плагин InnoDB. Он намного лучше более ранней версии InnoDB.

InnoDB настолько важна, что в ее разработку внесли свой вклад не только коман­да Oracle, но и многие другие люди и компании, в частности Ясуфуми Киносита (Yasufumi Kinoshita), а также компании Google, Percona и Facebook. Некоторые из внесенных ими усовершенствований были включены в официальный исходный код InnoDB, многие другие были немного переработаны командой InnoDB и затем вне­дрены. В целом развитие InnoDB значительно ускорилось за последние несколько лет, улучшения коснулись инструментария, масштабируемости, способности к из­менению конфигурации, производительности, функций и поддержки для Windows и прочих важных вещей. Лабораторные превью и релизы ключевых изменений, вно­симых в версию MySQL 5.6, также представляют множество замечательных новых функций InnoDB.

Oracle инвестирует колоссальные ресурсы и проделывает огромную работу для улучшения производительности InnoDB (и здесь очень полезным оказывается вклад, который вносят внешние разработчики). Во втором издании этой книги мы отмечали, что InnoDB выглядела довольно жалко, работая на основе четырехпро­цессорных ядер. Теперь она хорошо масштабируется до 24 ядер процессора, а воз­можно, и до 32 или даже большего количества в зависимости от сценария.

 

Обзор InnoDB

InnoDB сохраняет данные в одном или нескольких файлах данных, которые называ­ются табличным пространством (tablespace). Табличное пространство, в сущности, является черным ящиком, которым управляет сама InnoDB. В MySQL 4.1 и более поздних версиях InnoDB может хранить данные и индексы каждой таблицы в от­дельных файлах. Кроме того, она может располагать табличные пространства в «сы­рых» (неформатированных) разделах диска. Но современные файловые системы делают эту возможность бессмысленной.

InnoDB использует MVCC для обеспечения высокой степени конкурентности и реа­лизует все четыре стандартных уровня изолированности SQL. Уровнем изоляции по умолчанию является REPEATABLE READ, а стратегия блокировки следующего ключа предотвращает фантомные чтения на этом уровне: вместо того чтобы блокировать только строки, затронутые в запросе, InnoDB блокирует пропуски в структуре ин­декса, предотвращая вставку фантомных строк.

Таблицы InnoDB строятся на кластеризованных индексах, которые мы детально рас­смотрим в следующих главах. Структуры индексов в InnoDB значительно отлича­ются от используемых в других подсистемах хранения. В результате эта подсистема обеспечивает более быстрый поиск по первичному ключу. Однако вторичные индексы (индексы, не являющиеся первичным ключом) содержат все столбцы первичного ключа, так что если первичный ключ большой, то все прочие индексы тоже будут большими. Если в таблице планируется много индексов, нужно стремиться к тому, чтобы первичный ключ был небольшим. Формат хранения данных не зависит от платформы. Это означает, что вы можете без проблем скопировать файлы данных и индексов с сервера Intel на PowerPC или Sun SPARCI.

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

Подсистема InnoDB очень сложна, и если вы ее используете, то мы настоятельно ре­комендуем вам прочитать раздел «InnoDB Transaction Model and Locking» («Транз­акционная модель и блокировки в InnoDB») руководства по MySQL. Из-за наличия архитектуры MVCC в работе подсистемы InnoDB есть много тонкостей, о которых вы должны узнать прежде, чем создавать приложения. Работа с подсистемой хране­ния, поддерживающей согласованные представления данных для всех пользователей, даже когда некоторые пользователи меняют данные, может быть сложной.

В качестве транзакционной подсистемы хранения InnoDB поддерживает горячее онлайновое резервное копирование с помощью различных меха­низмов, включая запатентованную Oracle Enterprise Backup и Percona XtraBackup с открытым исходным кодом. В других подсистемах хранения MySQL нет горячих резервных копий — чтобы получить согласованную резервную копию, вам необхо­димо остановить все процессы записи в таблицу, которые при смешанной рабочей нагрузке на чтение и запись обычно заканчиваются также остановкой чтения.

Вас заинтересует / Intresting for you:

MyISAM: подсистема хранения ба...
MyISAM: подсистема хранения ба... 525 просмотров Ирина Светлова Mon, 07 Jan 2019, 13:15:48
Использование MySQL в качестве...
Использование MySQL в качестве... 448 просмотров Андрей Волков Tue, 01 Oct 2019, 05:41:51
Обзор версий MySQL - какой рел...
Обзор версий MySQL - какой рел... 1786 просмотров Ирина Светлова Thu, 10 Jan 2019, 08:02:16
Модель развития базы данных My...
Модель развития базы данных My... 449 просмотров Ирина Светлова Thu, 10 Jan 2019, 12:29:03

Войдите чтобы комментировать

iVoron аватар
iVoron ответил в теме #9363 23 фев 2019 06:50
Спасибо за обзор движка InnoDB! Транзакционные свойства, конечно, главное в нем.