ISAM, Indexed Sequential Access Method — индексно-последовательный метод доступа, способ хранения данных для быстрого доступа к ним. Способ изначально был разработан компанией IBM для мейнфреймов, в настоящее время это основной способ представления данных почти во всех базах данных (реляционных и пр.).
В ISAM отдельно хранятся записи с данными и индексы (служебные данные), служащие для быстрого доступа к записям. Данные хранятся последовательно (изначально ISAM использовался для хранения данных на ленточных накопителях, обеспечивающих только последовательные чтение/запись). Второй набор данных — хеш-таблица — индексы, содержащие указатели, которые позволят извлечь определенные записи без поиска по всей базе данных. Это несколько отличается от индексов в современных поисковых базах данных, так как в них индексы хранятся прямо в записях. Ключевая особенность ISAM — индексы малы, и поиск по ним быстр. Изменение в записях не требует изменять все записи, требуется только перестроить индекс.
Реляционные базы данных могут быть построены на способе хранения данных ISAM с добавленной логикой по сохранению целостности связей между таблицами. Обычно поле, используемое для связи (внешний ключ), индексируется для быстрого поиска. Конечно, это медленнее, чем просто хранить указатели на нужные записи в другой таблице непосредственно в записях, но зато изменения на физическом уровне хранения данных не потребуют изменения указателей.
ISAM легко реализуется и это дешевый метод. Плата за это — каждая клиентская машина должна держать собственные соединения с каждым файлом, к которому происходит доступ. Это может привести к конфликтам при одновременной работе нескольких клиентов при попытке изменить или вставить новые значения и привести к потере данных. Обычно эта проблема решается добавлением клиент-серверного приложения, которое обслуживает запросы пользователей и управляет ими, чтобы сохранять целостность данных. Это основная концепция СУБД, которая создает клиентский уровень над надлежащими данными.
ISAM был заменен IBM методологией, названной VSAM (Virtual Storage Access Method). Позднее, IBM разработал DB2, которая стала основной СУБД от IBM.
VSAM — это способ физического хранения данных в DB2.
MySQL реализовало расширение ISAM — MyISAM.
MyISAM — одна из основных (наряду с InnoDB) систем хранения данных в СУБД MySQL. Она основывается на коде ISAM и обладает в сравнении с ним рядом полезных дополнений.
Таблицы MyISAM прекрасно подходят для использования в WWW и других средах, где преобладают запросы на чтение. Таблицы типа MyISAM показывают хорошие результаты при выборках SELECT. Во многом это связано с отсутствием поддержки транзакций и внешних ключей. Однако при модификации и добавлении записей вся таблица кратковременно блокируется, это может привести к серьёзным задержкам при большой загрузке.
Для таблиц этого типа создан ряд специализированных утилит, позволяющих манипулировать табличными файлами. Сюда входят утилита myisamchk для проверки и восстановления таблиц и индексов (требует полной остановки процесса MySQL и создает время неработоспособности системы, исполнение заключается в создании с нуля нового целостного файла таблицы и перезаписи данных в него) и утилита myisampack для создания сжатых таблиц.
Таблицы MyISAM являются платформенно-независимыми. Табличные файлы можно перемещать между компьютерами разных архитектур и разными операционными системами без всякого преобразования. Для этого MySQL хранит все числа с плавающей запятой в формате IEEE, а все целые числа — в формате с прямым порядком следования байтов.
Индексные файлы имеют расширение .MYI (MYIndex). Файлы с расширением .MYD (MYData) содержат данные, а с расширением .frm — схему таблицы. Если индексный файл по какой-то причине теряется, программа перестраивает индексы, используя информацию из frm-файла.По умолчанию в каждой таблице может быть не более тридцати двух индексов, но это значение можно повысить до шестидесяти четырёх. Индексы создаются в виде двоичных деревьев. Разрешается индексировать столбцы типа BLOB и TEXT, а также столбцы, допускающие значения NULL.
В таблицах MyISAM могут быть фиксированные, динамические либо сжатые записи. Выбор между фиксированным и динамическим форматом диктуется определениями столбцов. Для создания сжатых таблиц предназначена утилита myisampack.
Отсутствие самовосстановления по журналу при сбоях (возможность присутствует во всех развитых СУБД).
Отсутствие блокировок регионов, меньших, чем целые таблицы. Приводит к отсутствию масштабируемости, то есть к сильной деградации производительности с повышением нагрузки.
Отсутствие средств резервного копирования. Утилита mysqldump, предлагаемая для создания резервных копий, является не инструментом резервного копирования, а инструментом экспорта в текст (в последовательность операторов INSERT, воссоздающих содержимое таблицы). Для выполнения задачи с сохранением целостности базы данных mysqldump захватывает блокировку таблицы, приводя к полной остановке работы системы на все время своего исполнения. Останов процесса MySQL и создание копии инструментами копирования файлов из UNIX приводит к меньшему времени простоя системы. Особенно удачен для этого gzip в режиме минимальной компрессии, который при незначительной для современного оборудования нагрузке процессора снижает объём данных, подлежащих записи в полученный файл, и тем самым ускоряет операцию.
Слабая реализация сортировки, которой является клауза ORDER BY языка SQL при отсутствии подходящего индекса. MyISAM сортирует данные слиянием, с использованием qsort для первоначально сливаемых небольших регионов. Это требует не только крайне неоптимального по дисковому вводу/выводу создания на каждую операцию сортировки 2 временных файлов, растущих с нулевого размера, с работой с ними через неоптимальные вызовы fopen() и fwrite(), но и выделения sort buffer для каждого клиента MySQL. Размер sort buffer (устанавливается параметром настройки MySQL sort_buffer_size) для достижения оптимальной производительности должен быть порядка сотен килобайт, что под большой нагрузкой приводит к полному исчерпанию не только кучи, но и пользовательского адресного пространства в 32-битных ОС семейства UNIX (во FreeBSD на x86 — 3 ГБ), и влечет за собой отказы вызовов malloc() во всем коде MySQL, а не только в
коде сортировки. Так как такие отказы далеко не всегда проверяются в коде, результатом может быть крах MySQL по сигналу SIGSEGV. Стоит отметить, что проблема с адресным пространством пользователя не присутствует в 64-битных операционных системах и на 2009 год большая часть выпускаемых серверов снабжена значительно большим объёмом памяти, чем 4Гб, что способствует применению именно 64-битных систем для полного использования возможностей оборудования, поэтому этот недостаток в данный момент становится менее критичен.Данные недостатки проявляются в заметной степени при нагрузке порядка 400 клиентов, исполняющих сложные запросы по базе данных размером 2-3 ГБ.
В более развитых реализациях нижнего уровня MySQL, таких как InnoDB, значительная часть данных проблем решена. Данные проблемы также могут решаться их учетом при разработке приложения, работающего с MySQL.