Поскольку MySQL предоставляет API для подключаемых подсистем хранения, с 2007 года появилось великое множество подсистем хранения, предназначенных для разных целей. Некоторые из них устанавливались на сервер, но большинство были продуктами сторонних разработчиков или проектами с открытым исходным кодом. Здесь мы обсудим часть подсистем хранения, которые, по нашему мнению, являются довольно полезными и все еще остаются актуальными.
Подсистемы хранения OLTP
Разработанная компанией Percona подсистема хранения XtraDB, интегрированная в Percona Server и MariaDB, является модифицированной версией InnoDB. Ее усовершенствования направлены на увеличение производительности, масштабируемости и операционной гибкости. Она может заменить InnoDB, так как способна читать и записывать файлы данных, совместимые с InnoDB, и выполнять все запросы, которые может выполнять InnoDB.
Существует несколько других подсистем хранения OLTP, похожих на InnoDB в ключевых вопросах, например в обеспечении соответствия ACID и MVCC. Одной из них является подсистема РВХТ, разработанная Полом Маккуллахом (Paul McCullagh) и компанией Primebase GMBH. В ней совмещаются репликация на уровне подсистемы, ограничения внешнего ключа и сложная архитектура, что делает ее пригодной для хранения на твердотельных накопителях и позволяет ей эффективно управлять большими значениями, например типа BLOB. РВХТ широко применяется как подсистема совместного хранения и входит в состав MariaDB.
TokuDB использует новую структуру индексов, называемую fractal trees (фрактальные индексные деревья), которая не привязана к кэшу. По этой причине индексы не замедляют работу, когда их размер превышает объем памяти, не устаревают и не фрагментируются. TokuDB позиционируется на рынке как подсистема хранения больших данных, поскольку имеет высокие коэффициенты сжатия и может поддерживать множество индексов на больших объемах данных. На момент написания книги TokuDB представляет собой ранний релиз и имеет существенные ограничения конкурентности. Эти особенности делают подсистему отличным вариантом для работы с аналитическими наборами данных с интенсивной записью новых данных, но все может измениться в следующих версиях.
RethinkDB изначально позиционировалась как подсистема хранения, предназначенная для твердотельных накопителей, хотя, похоже, с течением времени она стала менее узкоспециализированной. Ее отличительной особенностью можно назвать применение работающей только на запись, копирующей только при записи структуры данных с использованием индексов, упорядоченных на основе В-деревьев. Эта подсистема все еще находится на ранней стадии разработки, и у нас не было возможности внимательно посмотреть на нее и оценить ее работу.
Подсистема Falcon продвигалась на рынок как следующее поколение транзакционной подсистемы хранения данных для MySQL в то время, когда компания Sun поглощала MySQL АВ, но работа над ней давно прекращена. Джим Старки (Jim Starkey), главный архитектор Falcon, основал компанию для создания новой облачной NewSQL СУБД NuoDB (прежнее название NimbusDB).
Подсистемы хранения, ориентированные на столбцы
По умолчанию MySQL ориентируется на строки. Это означает, что данные каждой строки хранятся в одном месте и сервер при выполнении запросов ориентируется на строку как на рабочую единицу. Но при очень больших объемах данных более эффективным может быть ориентирование на столбцы. Это позволяет подсистеме извлекать меньше данных в ситуациях, когда строка целиком не нужна, а столбцы хранятся отдельно друг от друга, и их можно сжимать более качественно.
Ведущей подсистемой хранения, ориентированной на столбцы, является Infobright, которая хорошо работает с очень большими объемами данных (десятки терабайт).
Она спроектирована для использования в тех случаях, когда требуется аналитический подход или работа с хранилищем данных. Подсистема хранит данные в сильно сжатых блоках. А также хранит набор метаданных для каждого блока, что позволяет ей пропускать блоки или даже выполнять запросы, просто просматривая метаданные. Все дело в том, что Infobright не поддерживает индексы — при таких огромных размерах они бесполезны, а блочная структура представляет собой своего рода квазииндекс. Подсистема хранения требует пользовательских настроек сервера, потому что части сервера должны быть перезаписаны для работы с данными, ориентированными на столбцы. Некоторые запросы не могут быть выполнены подсистемой хранения в режиме, ориентированном на столбцы, поэтому сервер возвращается в режим, ориентированный на строки, что замедляет работу. Infobright существует как в версии с открытым исходным кодом, так и в коммерческой.
InfiniDB от Calpont — еще одна подсистема хранения данных, ориентированная на столбцы. Она доступна и в коммерческой версии, и в версии с открытым исходным кодом. InfiniDB предоставляет возможность делать запросы через кластер. Однако среди наших знакомых никто не использовал ее для работы.
Кстати, если вы хотите приобрести СУБД, ориентированную на столбцы, но не имеющую отношения к MySQL: мы оценили также LucidDB и MonetDB. Результаты эталонного тестирования и наше мнение о них вы найдете в MySQL Performance Blog, хотя с течением времени они, вероятно, несколько устареют.
Подсистемы хранения, создаваемые сообществом разработчиков
Полный список подсистем хранения данных от сообщества разработчиков насчитывал бы десятки или даже сотни систем, если бы мы принялись скрупулезно перечислять их. Однако можно с уверенностью сказать, что большинство из них обслуживают очень узкие ниши и практически неизвестны или используются малым количеством людей. Мы просто упомянем некоторые из них, так как большинство из них не видели в работе. {tip title="Caveat emptorl' content="Покупатель, будь бдителен! (Лат.)"}Caveat emptorl'/tip}
- Aria. Aria, ранее называемая Maria, разрабатывается командой, создавшей MySQL, и позиционируется как преемница MyISAM. Она доступна в СУБД MariaDB. Многие из ее инструментов, которые изначально были заявлены, похоже, были отложены ради улучшения других частей сервера MariaDB. На момент написания книги, пожалуй, стоит охарактеризовать ее как защищенную от сбоев версию MyISAM, имеющую также несколько других усовершенствований, среди которых возможность кэшировать данные (а не только индексировать) в собственной памяти.
- Groonga. Это подсистема хранения данных с полнотекстовым поиском, которая, как утверждается, обеспечивает точность и высокую скорость.
- OQGraph. Эта подсистема хранения от Open Query поддерживает операции с графами (думаем, в виде «найдите кратчайший путь между узлами»), которые нецелесообразно или невозможно выполнять в SQL.
- Q4M. Реализует очередь внутри MySQL с поддержкой операций, которые для самой SQL являются довольно сложными или невыполнимыми в рамках одной инструкции.
- SphinxSE. Эта подсистема хранения предоставляет интерфейс SQL для полнотекстового поискового сервера Sphinx, о котором мы подробнее поговорим в приложении Е.
- Spider. Разделяет данные на несколько сегментов, эффективно реализуя прозрачное сегментирование, и выполняет запросы параллельно в различных сегментах данных, которые могут быть расположены на разных серверах.
- VPForMySQL. Эта подсистема хранения поддерживает вертикальное разбиение таблиц с помощью своего рода прокси-подсистемы хранения. То есть вы можете нарезать таблицу на несколько наборов столбцов и хранить их отдельно друг от друга, но использовать в запросах как одну таблицу. Разработчик тот же, что и у подсистемы Spider.
