1. Приветствуем Вас на неофициальном форуме технической поддержки XenForo на русском языке. XenForo - коммерческий форумный движок от бывших создателей vBulletin, написанный на PHP.

InnoDB vs MyISAM для XenForo

Тема в разделе "Оптимизация XenForo", создана пользователем infis, 02.11.2015.

Загрузка
  1. infis

    infis Местный

    Регистрация:
    27.06.11
    Сообщения:
    5 966
    Симпатии:
    3 548
    Версия XF:
    1.5.9
    Это плохое решение, так как InnoDb в отличие от MyISAM сильно уступает в производительности в некоторых случаях. В частности для "горячей" таблицы такое делать не рекомендуется. А таблица xf_session как раз и является "горячей" в приложении XenForo.
    Надо решать вопрос с падениями MySQL, а не пытаться смягчить эти падения. То есть нужно бороться с причиной, а не со следствием.
     
    Последнее редактирование модератором: 02.11.2015
  2. FractalizeR

    FractalizeR XenForo Addicted

    Регистрация:
    27.09.10
    Сообщения:
    1 085
    Симпатии:
    832
    Версия XF:
    1.3.2
    Я думаю, что в некоторых случаях и MyISAM уступает в производительности InnoDb.

    Разумеется, нужно решить вопрос с причиной падения сервера. Но если пользователь на форуме спрашивает о том, как избавиться от "table crashed and needs to be repaired", разбор причин падения демона будет для него непосильной задачей. Гораздо проще для него в таком случае выполнив один SQL запрос решить проблему, пусть даже и принеся в жертву Х% производительности.
     
  3. infis

    infis Местный

    Регистрация:
    27.06.11
    Сообщения:
    5 966
    Симпатии:
    3 548
    Версия XF:
    1.5.9
    Это почти из области фантастики. Вы лучше прочитайте о различиях этих движков. Если в двух словах, то на операциях INSERT и SELECT движок MyISAM будет быстрее InnoDb почти всегда. А вот на операциях DELETE и UPDATE разница будет уже незначительной. Но на транзакциях InnoDb, естественно, выиграет, так как MyISAM их банально не умеет. Кстати, InnoDb еще сильно сливает движку MyISAM при использовании COUNT(*).
     
  4. Yoskaldyr

    Yoskaldyr Пользователь

    Регистрация:
    27.09.10
    Сообщения:
    1 921
    Симпатии:
    1 163
    Версия XF:
    1.0.4
    Судя по этому сообщению логичный вывод для всех таблиц использовать MyISAM. Но это бред. MyISAM быстр из-за того что он очень прост и туп. Недостаток этого он вообще не параллелится. Как следствие быстро работает только когда клиентов не много - в идеале когда только 1 клиент.

    По поводу темы топика.
    Единственный правильный ответ пинать хостера, т.к. это полностью его проблема.
    Но т.к. это реальный мир и не всегда есть возможность что-то менять в хостинге, то решение с изменением типа таблицы на InnoDB как раз идеально подходит для таблицы xf_session (кстати это надо делать в первую очередь на любом посещаемом ресурсе). Для других таблиц это правило применяется только с оговорками.
     
  5. FractalizeR

    FractalizeR XenForo Addicted

    Регистрация:
    27.09.10
    Сообщения:
    1 085
    Симпатии:
    832
    Версия XF:
    1.3.2
    Я все же предпочитаю смотреть на тесты. Например, на вот такие:
    Я не адвокат InnoDB. Но производительность - это такая вещь, о которой очень сложно сказать "X быстрее Y". Всегда есть множество обстоятельств, которые необходимо учитывать.

    Я не очень понял, как можно сравнивать производительность InnoDb и MyISAM в транзакциях, если MyISAM вообще их не поддерживает?

    Внешне все выглядит именно так. Но нужно иметь ввиду, что это справедливо только для COUNT(*) без WHERE предикатов. Все дело в том, что за счет отсутствия необходимости поддержании транзакций, MyISAM просто хранит в заголовке таблицы текущее общее количество строк таблицы. Фактически, это кеш значения.

    В других движках, которые поддерживают транзакции, подсчет числа строк таблицы, это всегда скан. Либо таблицы, либо индекса. Но в других движках есть свои способы получить приблизительное количество строк таблицы. Например, в PostgreSQL, с которым я сейчас работаю, можно сделать так:

    Код:
        /**
         * @return int
         */
        public function count()
        {
            $result = DB::selectOne(
                "
                SELECT
                  reltuples
                FROM pg_class C
                LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
                WHERE
                  nspname NOT IN ('pg_catalog', 'information_schema') AND
                  relkind='r'
                  AND nspname = ? AND relname = ?
            ",
                [$this->schemaName, $this->tableName]
            );
    
            return $result['reltuples'];
        }
    
    Для InnoDB можно воспользоваться
    Код:
    SELECT TABLE_ROWS
    FROM information_schema.tables
    WHERE TABLE_SCHEMA = 'database_name'
          AND TABLE_NAME = 'table_name';
    
    В случае наличия WHERE условия, InnoDB и MyISAM будут в равных условиях. Преимущество MyISAM в скорости пропадает. Кстати, я бы не назвал быстрый подсчет общего числа строк таблицы серьезным преимуществом. Это по-настоящему нужно бывает редко, на мой взгляд.
     
  6. infis

    infis Местный

    Регистрация:
    27.06.11
    Сообщения:
    5 966
    Симпатии:
    3 548
    Версия XF:
    1.5.9
    Речь была о таблицах, в которых данные не важны. И таблица xf_session, к слову, как раз и относится к таблицам, которая при крахе никак не нарушит целостность данных. Самое важное в переводе на InnoDb этой таблицы - применение блокировок только одной записи, а не всей таблицы. И да, это положительно скажется на посещаемом ресурсе. На небольшом ресурсе тип InnoDb, на мой взгляд, только съест больше памяти. Если на сервере памяти ограниченно, и сервер слабый, то совсем не факт, что изменение на InnoDb улучшит производительность. Судя по всему у человека явно проблемы с сервером. И перевод таблицы на другой тип ему явно не поможет.
    Переводить все таблицы в InnoDb также глупо, как и держать все таблицы в MyISAM. Во всяком случае пока.
    --- добавлено : Nov 2, 2015 12:58 PM ---
    Тесты достаточно стары, чтобы им верить на рабочих версиях.
    Когда требуется произвести запись сразу в несколько таблиц, то транзакция позволит это сделать безопасно и быстро. В случае отсутствия транзакции придется самостоятельно отслеживать целостность данных. Естественно, намного производительнее доверить целостность серверу, а не отслеживать ее самостоятельно. Извиняюсь, что легкий сарказм Вам был непонятен.

    Ну а PG, конечно же, на голову выше MySQL. Как по производительности, так и по уровню работы с данными. О нем можно было и не упоминать. А то давайте еще сюда и Oracle приплетем :) Он тут всех уделает в производительности на огромных выборках (на мощных кластерах). У нас другие задачи.
     
    Последнее редактирование модератором: 10.11.2015
  7. FractalizeR

    FractalizeR XenForo Addicted

    Регистрация:
    27.09.10
    Сообщения:
    1 085
    Симпатии:
    832
    Версия XF:
    1.3.2
    В XenForo все таблицы InnoDB и только несколько MyISAM. Общий размер MyISAM таблиц даже на небольших форумах ничтожен по сравнению с таковым InnoDB. Поскольку InnoDB использует статичный пул памяти для работы, перевод или не перевод одной небольшой таблицы на InnoDb практически не скажется на потреблении памяти сервером MySQL.

    Как минимум, при падении демона MySQL после перехода на InnoDB его не нужно будет поднимать вручную через REPAIR TABLE. Я думаю, отсутствие простоя это достаточно важное обстоятельство. Проблемы производительности тут ни при чем. Мы ведь все еще обсуждаем мой комментарий относительно решения проблемы "table is marked as crashed", если вы помните. Я не предлагал лечить проблемы производительности XenForo миграцией на другой движок таблиц вроде бы. Я только утверждаю, что в целом нельзя однозначно сказать, что MyISAM всегда быстрее InnoDb или наоборот.

    Есть чем подкрепить это утверждение?

    У вас есть другие тесты, подтверждающие вашу точку зрения о том, что MyISAM всегда быстрее InnoDB? Вы считаете, что с увеличением версии MySQL производительность InnoDB только ухудшается? Ведь MyISAM больше не развивается. Начиная с MySQL 5.5 InnoDB является движком по умолчанию. Безусловно, не все так просто. Однако, нужно признать, что MyISAM сегодня уже устарел.

    Я ведь говорил как раз о том, что ни PostgreSQL, ни Oracle не умеют оптимизировать COUNT(*) без WHERE так, как это делает MyISAM в MySQL. Так что это не InnoDB тормозит. Вернее, не только он. Это просто следствие кеширования некоторой информации движком MyISAM, которое возможно только при условии отсутствия транзакций.

    От себя еще добавлю, что я бы выбрал монолитное InnoDB приложение (не в XF в частности, а вообще в принципе) еще и по следующим причинам:
    • Мне как разработчику привычно понятие транзакции. Я не слишком хочу держать в голове то обстоятельство, что на некоторые таблицы это понятие не распространяется.
    • В InnoDB и MyISAM планировщики запросов могут по-разному рассчитывать стоимость исполнения отдельных частей запросов, что может неожиданным образом повлиять на исполнение запросов (В XF xf_session в общем-то более-менее изолирован от основной части системы, так то этот довод к нему практически отношения не имеет)
    --- добавлено : 2 ноя 2015 в 16:52 ---
    Кстати, еще замечу, что у нас в FORUMHOUSE xf_session работает на MyISAM движке и мы не наблюдаем проблем с производительностью. Правда, у нас MariaDB 10 стоит, но думаю, это несущественно. А форум у нас, все же, достаточно велик.
     
    Последнее редактирование модератором: 10.11.2015
  8. Yoskaldyr

    Yoskaldyr Пользователь

    Регистрация:
    27.09.10
    Сообщения:
    1 921
    Симпатии:
    1 163
    Версия XF:
    1.0.4
    Значит кто-то вернул :) Раньше xf_session точно был в InnoDB, на MyISAM некоторые запросы из-за блокировок при большом онлайне были до полусекунды (особенно на главной). Но это было когда вся стата на главной отображалась + по другому работа со списком пользователей была.
     
  9. infis

    infis Местный

    Регистрация:
    27.06.11
    Сообщения:
    5 966
    Симпатии:
    3 548
    Версия XF:
    1.5.9
    Дабы не устраивать срач (в инете куча тестов, которые по сути являются синтетикой и мало значат для реальных приложений), соглашусь, что MyISAM устарел, а InnoDb уже практически догнал MyISAM по производительности на некоторых запросах. Не смогу быстро найти тесты или хорошие статьи по реальному потреблению памяти на разных движках, но точно видел, что InnoDb был явно прожорливее, что на слабых серверах может печально сказаться.
    Если сервер крашится, то надо решать эту проблему в любом случае. Ремонтировать таблицы, кстати, можно даже кроном.

    Ну а в целом могу сказать, что каждое приложение может и обычно использует особенности каждого движка и каждого сервера.
     
  10. FractalizeR

    FractalizeR XenForo Addicted

    Регистрация:
    27.09.10
    Сообщения:
    1 085
    Симпатии:
    832
    Версия XF:
    1.3.2
    Я тоже думаю, что вследствие MVCC архитектуры InnoDB более требователен к памяти.

    Согласен. Правда, я думаю, ремонт таблиц кроном может скрыть проблему. Ведь она кроется не только в том, что MySQL просто пометил таблицу, как сбойную. Сама информация внутри таблицы может быть повреждена. Поэтому, совершенно точно вопрос с хостером нужно решать.
     
  11. infis

    infis Местный

    Регистрация:
    27.06.11
    Сообщения:
    5 966
    Симпатии:
    3 548
    Версия XF:
    1.5.9
    Так потому я и говорил про "горячие" таблицы. Таблица xf_session не содержит важных данных, а потому можно не беспокоиться об этом. А так да, в случае важных данных есть большая вероятность потерять эти данные полностью, либо частично. В InnoDb вероятность потери данных минимальна. В любом случае мы сошлись на том, что хостера надо привлекать к решению проблемы.
     
  12. Oleg-2012

    Oleg-2012 Местный

    Регистрация:
    21.04.12
    Сообщения:
    700
    Симпатии:
    297
    Почитал я топик и сразу возник вопрос, если кому-то нужно максимальная производительность и надёжность, то не проще тогда включить кеширование сессии в память, там-же они не большие, много памяти не займут, тогда и ненужно ничего переводить в InnoDB, также и производительность улучшится, правда памяти всё-же надо по больше выделить под кеш, в зависимости от посещалки ! :)
    --- добавлено : Nov 4, 2015 12:47 PM ---
    А падения MyISAM, может-быть критично на VPS, у меня пару раз было после презагрузки хостером физического сервера, это ладно когда есть время что-то там восстанавливать, а когда его нет, получится "простой" ресурса... :(

    Кеширование должно помочь в этой ситуации, но повторюсь нужно увеличить кеш в памяти, для нормальной работы ! :)
     
    Последнее редактирование модератором: 12.11.2015

Поделиться этой страницей