Движок Maria — это расширенная версия MyISAM, которая поддерживает весь основной функционал MyISAM и в дополнение к этому предлагает: поддержку восстановления данных после сбоев (data auto-recovery, crash safe), полное логирование (включая операции CREATE, DROP, RENAME и TRUNCATE) и новый формат строк PAGE.
Планируется, что движок Maria будет входить в стандартный пакет в версиях MySQL 6.X
Основные замечания касательно сравнения Maria и MyISAM
Преимущества перед MyISAM
- Восстановление данных и индексов после сбоев
- Откат, после сбоя, в предыдущее состояние или к состоянию после последней команды LOCK TABLES
- Полное логирование операций, включая: CREATE/DROP/RENAME/TRUNCATE TABLES, LOAD DATA INFILE, SELECT… INSERT и INSERT (множество строк), ALTER TABLE
- LOAD INDEX может пропускать неиспользуемые индексные блоки
- Новый блочный формат строк, в котором данные хранятся ввиде страниц
- При использовании блочного формата строк (выбираемого теперь по умолчанию) строковые данные могут кешироваться
- Блочные тесты большинства элементов
- Поддержка как отказоустойчивых (crash safe, транзакциональных) так и нетранзакциональных таблиц. (Нетранзакцональные таблицы не логируются и для строк используется меньше места): CREATE TABLE foo (...) TRANSACTIONAL=0|1
- PAGE используется только для отказоустойчивого/транзакционального строкового формата
- PAGE формат должен дать заметное увеличение скорости на системах с плохим кешированием данных. (К примеру Windows)
Отличия от MyISAM
- Использование больших (1GB по умолчанию) лог файлов
- Использование контроля за логами (maria_log_control) и файлов логов (maria_log.???????). Файлы логов могут быть очищены автоматически, когда они уже больше не нужны, или по требованию (после бакапирования).
- По умолчанию используются 8К страницы (MyISAM использует 1К). Maria будет работать быстрее на индексах с фиксированным размером, но медленнее на ключах с переменной длиной.
Устранение недостатков на ближайшее время
- В Maria 1.0 может быть один пишущий и много читающих (MyISAM может иметь одного добавляющего и много читающих, когда используются конкурирующие добавления записей).
- Не поддерживается INSERT DELAYED
- Не поддерживается кеширование составных ключей
Устранение недостатков в следующих релизах
- Хранение очень малых строк
- Не поддерживаются MERGE таблицы
Различия, которые вероятно не будут устранены
- Страницы данных в блоковом формате увеличивают размеры: 10 байт на страницу и 5 байт на строки. Транзакции и поддержка конкурирующих записей приведут к увеличению: 7 байт на новые строки, 14 байт для удаленных строк
- Отсутствие внешнего блокирования (MyISAM имеет внешнее блокирование, но оно редко используется)
- Использование одинакового размера страниц для индекса и данных. MyISAM поддерживает различные размеры страниц для индексов
- Индексный номер требует один экстра байт на индексную страницу
- Не поддерживается внутренний MySQL RAID (выключен и в MyISAM)
- Минимальный размер файла данных формата PAGE 16К (со страницей на 8K)
Via: handynotes.ru
Комментарии (63)
norguhtar
29.01.2008 06:09Поддержки транзакций опять нет. Когда она уже будет?
grischa
29.01.2008 06:09используйте ИнноДБ
norguhtar
29.01.2008 06:09Использую. Но у него свои косяки присутствуют.
grischa
29.01.2008 06:09Например? Я уже лет 5 на ИнноДБ сижу. Никаких проблем не наблюдал.
norguhtar
29.01.2008 06:09При сбое сложно востановить базу (практически не возможно). Перенос в отличии от того же MyISAM только через dump/restore. По умолчанию валит все данные в один файл.
WanderingStar
29.01.2008 06:09Разные файлы - конфиг вам в руки. А по восстановлению соглашусь - кошмар просто.
norguhtar
29.01.2008 06:09Дык поставил. Но опять же не спасает в случае повреждения файла с метаданными. Но у меня есть нездоровое подозрение, что в коммерческой версии все хорошо :]
abstractioneer
29.01.2008 06:09innodb-tools
не пробовали?norguhtar
29.01.2008 06:09Да как-то руки не дошли. Сами то пробовали?
abstractioneer
29.01.2008 06:09не пробовал, потому и интересуюсь - судя по описанию, вещь многообещающая, а времени все никак нет добраться:)
pipboy
29.01.2008 06:09Поддержка транзакций обещается в следующем релизе
см. FAQ: http://monty-says.blogspot.com/2008/01/maria-engine-is-released.html
erock
29.01.2008 06:09поддержки транзакций в MyISAM нет намеренно.
Не так много реальных задач в веб-программировании, где действительно нужны транзакции и ACID. А механизм транзакций - это гарантированное замедление работы бд.
Поэтому всем, кому они нужны - InnoDB и новомодный Falkon в руки.norguhtar
29.01.2008 06:09
Не так много реальных задач в веб-программировании, где действительно нужны транзакции и ACID.
Я бы не был так категоричен.erock
29.01.2008 06:09Интересно было бы услышать тогда примеры.
Очень много людей, кто рассуждает о транзакциях не представляя вообще зачем они нужны. Обычно в ответ слышишь что-то типа: "Для работы с биллингом точно надо" и т.п.norguhtar
29.01.2008 06:09Как минимум для поддержания атомарности операции и как следствие целостности данных. К тому же если в MyISAM интенсивно писать в несколько потоков, то с чтением у вас будут серьезные проблемы. В InnoDB кстати с этим лучше, но надо откручивать ACID для получения нормального уровня производительности или тюнить приложение на использование транзакций.
erock
29.01.2008 06:09> интенсивно писать в несколько потоков
как много случаев, когда вам в веб-приложении приходилось интенсивно писать в одну таблицу в несколько потоков?
Уверен, что на большой проект - это одна-две таблицы. Делайте их InnoDB и будет вам счастье.norguhtar
29.01.2008 06:09в случае если у вас будет посещаемый проект типа хабра то вполне будет. Они правда используют репликацию с узлом на запись и узлом на чтение.
erock
29.01.2008 06:09> в случае если у вас будет посещаемый проект типа хабра то вполне будет.
вспоминается выступление программеров с ЖЖ, когда они говорили, что у них ВСЕ таблицы MyISAM. Вы думаете у них слабые нагрузки? На собственном опыте - мы имели > 1000 запросов\сек тоже только на MyISAM - с атомарностью и изоляциями проблем небыло.
вот разделение рид и райт коннектов - это другое дело.norguhtar
29.01.2008 06:09
> 1000 запросов\сек тоже только на MyISAM - с атомарностью и изоляциями проблем небыло.
вспоминается выступление программеров с ЖЖ, когда они говорили, что у них ВСЕ таблицы MyISAM.
у и количество читающих и пишущих. К тому же как у вас не может быть проблем с атомарностью и изоляциями если у MyISAM нет поддержки транзакций.
Мои вот измерения показывали что MyISAM дохнет на 20-30 одновременных массированых операциях записи или одной длинной массированной операции записи. Читаться от туда читается, а вот запись особо не ведется.
tol
29.01.2008 06:09Ну и сколько из этой тысячи делали запись?
erock
29.01.2008 06:09интенсивная запись была в две-три таблицы. Но с ними были проблемы не с целостностью, а с выборками из них. И тут InnoDB только замедляет.
norguhtar
29.01.2008 06:09Вы открутите ACID от InnoDB. По умолчанию оно включено, что роняет производительность раза в три.
erock
29.01.2008 06:09Гм. Вы просите поддержку транзакций от новых движков, но ни одна из A, C, I, D вам не нужна. Может вам не нужны транзакции?
norguhtar
29.01.2008 06:09ACID в случае MySQL подразумевает запись каждой транзакции в лог в fsync затем запись в базу тоже с fsync. Так что если приложение не использует транзакции или транзакции короткие, то производительность сильно падает. Для того чтобы этого не происходило есть возможность отключить принудительный fsync и синкать по таймеру. При этом ACID в целом сохраняется, хотя могут быть повреждения данных или их не попадание в базу в случае обрушения MySQL движка. Транзакции при этом продолжают работать.
norguhtar
29.01.2008 06:09
мы имели > 1000 запросов\сек тоже только на MyISAM - с атомарностью и изоляциями проблем небыло.
вспоминается выступление программеров с ЖЖ, когда они говорили, что у них ВСЕ таблицы MyISAM. Вы думаете у них слабые нагрузки?
ак нет транзакций. Мой же личный опыт показывает, что MyISAM на запись работает крайне хреново, так-как лочится вся таблица и из-за этого в случае большого числа операций записи или одной длинной операции записи можно или потерять данные или они будут поступать с запозданием.
dmach
29.01.2008 06:09Собственно это приведёт к тому, что если сейчас mySQL выигрывает у полноценных БД на операциях INSERT/UPDATE (в частности за счёт отсутствия логов этих операций), то на новой версии движка она перестанет это делать.
Alexus
29.01.2008 06:09Кажется, в MyISAM есть отключаемый бинлог.
Плохие технологии просто не будут использовать.
tszyn
29.01.2008 06:09Не перестанет - лог отключается (вместе со всеми преимуществами конечно). Кроме того Мароия поддерживает все форматы MyISAM (без логирования конечно). Дока тут : http://forge.mysql.com/wiki/Maria_Docs
sylvio
29.01.2008 06:09Те они собираются убить myisam только из-за лога запросов, которые все давно делают на уровне абстракции бд и страниц, плюс от которых достаточно сомнителен?
tszyn
29.01.2008 06:09Maria поддерживает практически все фичи MyISAM (кроме некоторых неиспользуемых) и все форматы (она сделана на основе MyISAM). Соотвестственно для старых форматов нет логирования и поддержки транзакций (в будущем - сейчас нет восстановления).
tszyn
29.01.2008 06:09Забыл добавить и в Марии можно отключить логирование (вместе с восстанавливаемостью конечно: http://forge.mysql.com/wiki/Maria_Docs )
Maximark
29.01.2008 06:09При правильной архитектуре - будет хватать и mysql 4.
Даже на сложных (по виду :) ) запросах...
anonymous
unnamed777
Да, не помешало бы. Надоели траблы с "И" и "ш"
denuka Автор
Почитайте в конце статьи В помощь вебмастеру: Linux bash скрипт для перевода сайта на новую кодировку
Вас спасет: SET NAMES 'utf8'
Spec
Вы меня прям смутили. :)
Все свои проекты перевел на UTF-8 уже 4 месяца назад и никаких глюков не заметил (по крайнер мере юзвери не писали в саппорт)
Может уточнить, где конкретно траблы?
unnamed777
Ну смотря как как переводить. У меня некоторые(вап-сайты) работают через энное место - кодировка полей cp1251, кодировка клиента и сервера тоже, но данные пишутся и читаются в утф8. Никаких проблем(кроме чтения базы через тот же sqlyog). Где конкретно траблы сейчас уже не скажу, но мучал долго и по-всякому.
Вот, кстати, наглядное проявление подобной проблемы - http://habrahabr.ru/blog/i_am_clever/347… (комментарии)
Cougar
Вот гарантированное спасение:
Сразу после mysql_connect() надо выполнить такие вот запросы:
SET NAMES utf8;
SET character_set_client=utf8;
SET character_set_connection=utf8;
SET character_set_database=utf8;
SET character_set_results=utf8;
Разумеется, кодировки БД, таблиц и полей очень не мешало бы привести к UTF-8 :)
А если база в cp1251 (она же win1251, она же windows-1251) - то скрипт, который сконвертит дамп БД в UTF8, пишется секунд за 30 :)
PS: Да, знаю, что эта пачка SQL-запросов избыточна - но во-первых, эти запросы выполняются за исчезающе малое время. И во-вторых - никаких посторонних косяков они не генерируют :)
CAJAX
Вообще WAP сайту сам бог велел быть только в UTF-8. На мобильных телефонах как правило нет возможности выбора кодировки, от чего страница в cp1251 становится абсолютно нечитаема на нелокализованых телефонах.
Проверено на апаратах во Франции и паре китайских "игрушек".
Кстати, на w3.org есть строчка о кодировках в WAPе.
unnamed777
А кто сказал, что они у меня не в утф? Я в вапе уже года три, если не больше, и прекрасно это знаю;-)
CAJAX
Нет нет, что вы, это я понял это ещё из первых строк, "..но данные пишутся и читаются в утф8..". Просто согласился с Вами :)
noise
тогда по какому поводу возмущения?
vladon
тогда откуда эти возгласы о некорректной работе с utf-8?
Википедия использует utf-8, и там с русскими буквами всё нормально