ФорумПрограммированиеPHP для идиотов → Всегда задавался этим вопросом, Myisam или innodb

Всегда задавался этим вопросом, Myisam или innodb

  • malaba

    Сообщения: 165 Репутация: N Группа: Кто попало

    Spritz Июль 27, 2011, 4:40 д.п.

    Доброй ночи пыхари)
    решил сделать простенький форум, выглядит так

    – таблица разделов форума
    CREATE TABLE IF NOT EXISTS `forum_section`(
    `id` INT(11) UNSIGNED AUTO_INCREMENT PRIMARY KEY, – id
    `content` TEXT, – описание раздела
    `counter_theme` INT(11) UNSIGNED DEFAULT 0, – колво тем в разделе
    `count_message` INT(11) UNSIGNED DEFAULT 0, – колво сообщений в разделе
    `last_theme` VARCHAR(100) NULL, – заголовок последней добавленной темы
    `last_theme_date` DATETIME, – дата последней темы
    `last_theme_uid`INT(11) UNSIGNED – id юзера кто добавил
    `last_theme_username` VARCHAR(20) NULL, – имя юзера
    `last_theme_id` INT(11) UNSIGNED – id последней темы
    )TYPE=innoDB CHARACTER SET utf8 COLLATE utf8_bin;

    — таблица тем форума
    CREATE TABLE IF NOT EXISTS `forum_theme`(
    `id` INT(11) UNSIGNED AUTO_INCREMENT PRIMARY KEY, – id
    `date` DATETIME, – дата добавления
    `name` VARCHAR(100), – заголовок
    `section_id` INT(11) UNSIGNED, – id раздела
    `last_message_date` DATETIME, – дата последнего сообщения
    `last_message_uid`INT(11) UNSIGNED – id юзера кто добавил
    `last_message_username` VARCHAR(20) NULL, – имя юзера
    `counter_message` INT(11) UNSIGNED – колво сообщений в теме
    )TYPE=MYISAM CHARACTER SET utf8 COLLATE utf8_bin;

    — таблица сообщений форума
    CREATE TABLE IF NOT EXISTS `forum_message`(
    `id` INT(11) UNSIGNED AUTO_INCREMENT PRIMARY KEY, – id
    `date` DATETIME, – дата добавления
    `text` TEXT, – заголовок
    `theme_id` INT(11) UNSIGNED, – id темы
    `user_id` INT(11) UNSIGNED – id юзера
    )TYPE=MYISAM CHARACTER SET utf8 COLLATE utf8_bin;

    и хочу поинтересоваться, какой тип все же лучше выбрать для таблиц!?
    насколько я читал и насколько понял, то myiasm лучше использовать для статичных данных, (таблица редко обновляються и инсертится)
    innodb же, блокирует отдельную строку допустим при обновлении, и скорей всего лучше использовать как раз для форума.
    Но это все в теории, мне вот интересно как себя поведут, таблицы если допустим в `forum_message` будет примерно 150.000 записей (как на пыхе)),
    и сделать такой стандартный запрос

    SELECT * FROM `forum_message` WHERE `theme_id`=154 LIMIT 10

    ???
    может я конечно загоняюсь, и париться по этому поводу не стоит, так как на локальной машине я пробовал делать такие таблицы с 3.000.000 записей и они работают пиздец как быстро, но все же это локальная машина, охуенные мозги и оперативка, а хостинг совсем другое….поделитесь пожайлуста опытом, ну или своими соображениями, по поводу типов таблиц….. или структуру может другую посоветуете)
    Спустя 173 сек.
    блядь только сейчас заметил))) сорри

    – таблица разделов форума
    CREATE TABLE IF NOT EXISTS `forum_section`(
    `id` INT(11) UNSIGNED AUTO_INCREMENT PRIMARY KEY,– id
    `content` TEXT, – описание раздела
    `counter_theme` INT(11) UNSIGNED DEFAULT 0, – колво тем в разделе
    `count_message` INT(11) UNSIGNED DEFAULT 0, – колво сообщений в разделе
    `last_theme` VARCHAR(100) NULL, – заголовок последней добавленной темы
    `last_theme_date` DATETIME, – дата последней темы
    `last_theme_uid`INT(11) UNSIGNED – id юзера кто добавил
    `last_theme_username` VARCHAR(20) NULL, – имя юзера
    `last_theme_id` INT(11) UNSIGNED – id последней темы
    )TYPE=innoDB CHARACTER SET utf8 COLLATE utf8_bin;



    — таблица тем форума
    CREATE TABLE IF NOT EXISTS `forum_theme`(
    `id` INT(11) UNSIGNED AUTO_INCREMENT PRIMARY KEY,– id
    `date` DATETIME, – дата добавления
    `name` VARCHAR(100), – заголовок
    `section_id` INT(11) UNSIGNED, – id раздела
    `last_message_date` DATETIME, – дата последнего сообщения
    `last_message_uid`INT(11) UNSIGNED – id юзера кто добавил
    `last_message_username` VARCHAR(20) NULL, – имя юзера
    `counter_message` INT(11) UNSIGNED – колво сообщений в теме
    )TYPE=MYISAM CHARACTER SET utf8 COLLATE utf8_bin;



    — таблица сообщений форума
    CREATE TABLE IF NOT EXISTS `forum_message`(
    `id` INT(11) UNSIGNED AUTO_INCREMENT PRIMARY KEY, – id
    `date` DATETIME, – дата добавления
    `text` TEXT, – заголовок
    `theme_id` INT(11) UNSIGNED, – id темы
    `user_id` INT(11) UNSIGNED – id юзера
    )TYPE=MYISAM CHARACTER SET utf8 COLLATE utf8_bin;
  • artoodetoo

    Сообщения: 5147 Репутация: N Группа: в ухо

    Spritz Июль 27, 2011, 7:49 д.п., спустя 3 часа 8 минут 33 секунды

    ты хочешь чтобы мы за тебя выбрали? ))) читай в чем разница и сам принимай решение. оба типа имеют право на жизнь, тут никаких deprecated не существует
    ιιlllιlllι унц-унц
  • mexys

    Сообщения: 19 Репутация: N Группа: Кто попало

    Spritz Июль 27, 2011, 8:22 д.п., спустя 32 минуты 58 секунд

    У innodb как минимум плюс - автоматическое восстановление после сбоев. А вообще похуй, сменить хранилище в любое время можно. Если не видишь разницы, значит на данном этапе — оно не так важно. Главное чтоб индексы правильно расставлены были.

    Кстати, для текущей задачи COLLATE utf8_general_ci все-же предпочтительнее
  • master

    Сообщения: 3244 Репутация: N Группа: Джедаи

    Spritz Июль 27, 2011, 8:25 д.п., спустя 2 минуты 56 секунд

    на слабой нагрузке до пизды какой тип таблиц. на большой, когда много народу, любой сложный запрос, длящийся несколько секунд, блокирует 100500 остальных пользователей и у всех FUUUUUUUU. например у нас был форум на движке vbulletin использующий по дефолту myisam, стал подтупливать, перевели таблицы на innodb - вроде стало получше, но это имеет смысл если оперативы у тебя например 8 гигов. на говнохостинге можешь вообще не париться
    не всё полезно, что в swap полезло
  • adw0rd

    Сообщения: 22959 Репутация: N Группа: в ухо

    Spritz Июль 27, 2011, 9:50 д.п., спустя 1 час 25 минут 1 секунду

    MyISAM частенько крешиться, не поддерживает транзакции - это мои веские причины. И мой выбор InnoDB
    https://smappi.org/ - платформа по созданию API на все случаи жизни
  • AlexB

    Сообщения: 4306 Репутация: N Группа: в ухо

    Spritz Июль 28, 2011, 12:15 д.п., спустя 14 часов 25 минут 4 секунды


    MyISAM частенько крешиться, не поддерживает транзакции - это мои веские причины. И мой выбор InnoDB
    +100
    Хуй поймешь почему, крешится и все … абсолютно непрогнозируемо. Причем репэрится обычно довольно легко, но блядь ПОЧЕМУ упал?

    Ну и конечно транзакции, внешние ключи, каскадное удаление … просто непонятно, как без всего этого делать мало мальски серьезный проект.

    Так что InnoDB без вариантов.
  • Абырвалг

    Сообщения: 6480 Репутация: N Группа: Джедаи

    Spritz Июль 28, 2011, 1:47 д.п., спустя 1 час 31 минуту 43 секунды

    есть проект, ему лет 10. Ежедневно тыщ по 15-20 уников. Ничего не крашится. Что они делают не так?

    да, небольшая посещаемость, но все же, 10 лет прошло.


    зы: я сам на инно перехожу, и присматриваюсь к форкам всяким
  • malaba

    Сообщения: 165 Репутация: N Группа: Кто попало

    Spritz Июль 31, 2011, 2:43 д.п., спустя 3 дня 56 минут

    спасибо большое за советы, полазал почитал и пришел к тому что рано или поздно придеться на innodb переходить))
  • AlexB

    Сообщения: 4306 Репутация: N Группа: в ухо

    Spritz Июль 31, 2011, 10:34 д.п., спустя 7 часов 51 минуту 21 секунду


    есть проект, ему лет 10. Ежедневно тыщ по 15-20 уников. Ничего не крашится. Что они делают не так?
    Я же грю … абсолютно пепредсказуемо. Один проект 10 лет работает, в другом, на том же самом движке, какая-нибудь таблица раз в неделю упорно крешится, почему - XЗ.

    И потом движок без внешних ключей и каскадных удалений, ИМХО, несерьезно на сегодняшний день.
  • malaba

    Сообщения: 165 Репутация: N Группа: Кто попало

    Spritz Авг. 1, 2011, 12:54 д.п., спустя 14 часов 19 минут 49 секунд

    чтоб не создвавть еще одну тему, вопрос

    CREATE TRIGGER `insert` AFTER INSERT ON `comment_help`
    FOR EACH
    ROW
    BEGIN
    UPDATE `counter_help` SET `counter_comment` = `counter_comment` +1 WHERE `id` = NEW.`id` LIMIT 1 ;


    Ответ MySQL:
    #1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 7

    вообще понять не могу, не получаеться создать триггер для любой таблицу, пробовал любые вариации, че за хрень?)
    Спустя 149 сек.
    END в конце поставил. (недокопировал)))
  • fgets

    Сообщения: 1099 Репутация: N Группа: Кто попало

    Spritz Авг. 1, 2011, 2:33 д.п., спустя 1 час 39 минут 18 секунд



    есть проект, ему лет 10. Ежедневно тыщ по 15-20 уников. Ничего не крашится. Что они делают не так?
    Я же грю … абсолютно пепредсказуемо. Один проект 10 лет работает, в другом, на том же самом движке, какая-нибудь таблица раз в неделю упорно крешится, почему - XЗ.

    И потом движок без внешних ключей и каскадных удалений, ИМХО, несерьезно на сегодняшний день.


    А помоему это свистелки и перделки. Внешние ключи только замедляют работу таблиц + InnoDB жрет дохуя памяти, это нужно тоже иметь ввиду вешая на него огромные таблицы. Грамотнее будет подбирать тип для каждой таблицы по отдельности, а не разом "с MYISAM на INNODB" (типа бля все таблицы сначала были в myisam а потом бля переделал их в innodb и стало ебать как охуенно, навешал внешних ключей и каскадных удалений чтобы было солидно и охуенно). Их в конце концов не два а дохуя. Но лучше наверное не вешать на базу логику управления данными - пускай с этим справляется скрипт ибо у базы должно быть две функции - хранить и отдавать. У кого MYISAM "крашится" посмотрите в сторону Maria. XtraDB тоже ничего
  • AlexB

    Сообщения: 4306 Репутация: N Группа: в ухо

    Spritz Авг. 1, 2011, 4:53 п.п., спустя 14 часов 19 минут 31 секунду


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

    это нужно тоже иметь ввиду вешая на него огромные таблицы. Грамотнее будет подбирать тип для каждой таблицы по отдельности, а не разом "с MYISAM на INNODB" (типа бля все таблицы сначала были в myisam а потом бля переделал их в innodb и стало ебать как охуенно, навешал внешних ключей и каскадных удалений чтобы было солидно и охуенно). Их в конце концов не два а дохуя.
    Их, конечно, до хуя, но много ли тебе известно проектов, где бы другие типы таблиц были осмысленно заюзаны? Лично я знаю такие примеры только в отношении мемори таблиц, но это вообще отдельная песня, они не вместо иннодб, а скорее вдобавок к нему ..

    Но лучше наверное не вешать на базу логику управления данными - пускай с этим справляется скрипт ибо у базы должно быть две функции - хранить и отдавать.
    Ага, триггеры и хранимые процедуры лохи придумали, реальные пацаны такой фигней не страдают ))))
  • vasa_c

    Сообщения: 3131 Репутация: N Группа: в ухо

    Spritz Авг. 1, 2011, 4:59 п.п., спустя 5 минут 54 секунды

    А отсутствие внешних ключей очень сильно замедляет работу всей компании, когда программист лажанулся и в здоровой базе данные потеряли целостность.

    А так программист лажанулся и каскадно всё потёр :)
  • Nyaah

    Сообщения: 574 Репутация: N Группа: Джедаи

    Spritz Авг. 1, 2011, 5 п.п., спустя 54 секунды




    есть проект, ему лет 10. Ежедневно тыщ по 15-20 уников. Ничего не крашится. Что они делают не так?
    Я же грю … абсолютно пепредсказуемо. Один проект 10 лет работает, в другом, на том же самом движке, какая-нибудь таблица раз в неделю упорно крешится, почему - XЗ.

    И потом движок без внешних ключей и каскадных удалений, ИМХО, несерьезно на сегодняшний день.


    А помоему это свистелки и перделки. Внешние ключи только замедляют работу таблиц + InnoDB жрет дохуя памяти, это нужно тоже иметь ввиду вешая на него огромные таблицы. Грамотнее будет подбирать тип для каждой таблицы по отдельности, а не разом "с MYISAM на INNODB" (типа бля все таблицы сначала были в myisam а потом бля переделал их в innodb и стало ебать как охуенно, навешал внешних ключей и каскадных удалений чтобы было солидно и охуенно). Их в конце концов не два а дохуя. Но лучше наверное не вешать на базу логику управления данными - пускай с этим справляется скрипт ибо у базы должно быть две функции - хранить и отдавать. У кого MYISAM "крашится" посмотрите в сторону Maria. XtraDB тоже ничего

    Самый примитивный пример - человек нажал на кнопку подтвердить платёж, после чего нужно:
    а) в таблицу транзакций добавить запись о платеже;
    б) в таблице заказов поставить для указанного заказа галочку оплачено и айди транзакции;
    в) списать с баланса пользователя необходимое количество бабла.
    Сколько кода будет без транзакций в бд на php, чтобы гарантировать целоствность данных, и сколько с транзакциями?
    Work, buy, consume, die
  • AlexB

    Сообщения: 4306 Репутация: N Группа: в ухо

    Spritz Авг. 1, 2011, 5:06 п.п., спустя 6 минут 24 секунды

    Nyaah, ты прав, но тут даже дело не столько в объеме кода, сколько в том что делать связанные с деньгами вещи без транзакций - безумие.

Пожалуйста, авторизуйтесь, чтобы написать комментарий!