Какова лучшая / самая быстрая схема таблиц MySQL для временного / вращающегося хранилища, например для управления сессиями?

Question

Когда речь идет о написании настраиваемого управления сеансами PHP на основе базы данных MySQL для ОЧЕНЬ динамического веб-сайта, какова наилучшая структура (самый быстрый доступ для чтения / записи) для таблицы сеансов?

Плохой пример (не оптимизирован):

CREATE TABLE `session` (
    `session_id` VARCHAR(32) NOT NULL,
    `session_data` TEXT NOT NULL,
    `t_created` DATETIME NOT NULL,
    `t_updated` DATETIME NOT NULL,
    PRIMARY KEY  (`session_id`)
) ENGINE=INNODB DEFAULT CHARSET=utf8;

Я предполагаю, что использование Memory Engine было бы лучше / быстрее, но я не уверен. Я не могу придумать хороший способ объяснить все на английском языке, поэтому я составил список требований / деталей, которые я считаю важными:

подробности:

• Категория: Оптимизация
• Подкатегория: Производительность запросов MySQL
• Цель: быстрая схема таблицы с произвольным доступом и однорядный запрос
• Распространенное использование: управление пользовательскими сеансами, временное хранилище
• Операционная система: * nix, точнее: Centos 5+ (на x86_64)
• База данных: версия MySQL: 5+ (версия для сообщества)

Результаты:

• SQL-запрос: создание таблицы
• SQL-запрос: выберите одну строку по случайному ключу (например, идентификатор сеанса PHP)
• SQL-запрос: вставка одной строки со случайным ключом (например, идентификатор сеанса PHP)
• SQL-запрос: обновить одну строку по случайному ключу (например, идентификатор сеанса)
• SQL-запрос: удаление нескольких строк по метке времени (сборка мусора, например сеансы с истекшим сроком действия)

Ожидаемая продолжительность жизни в строке (например, продолжительность сеанса):

• 30%: от 0 до 30 с
• 20%: 30 с-5 м
• 30%: 5 м-1 ч
• 20%: 1ч-8ч

Ожидаемое количество строк (например, активных сессий):

• Низкий: 128
• Средний: 1024
• Высокий: 100000

Если кто-то может придумать лучший способ сформулировать все это, пожалуйста, не стесняйтесь редактировать.

Answer 1

Рассматривали ли вы использование memcached или APC для данных сеанса? Они почти наверняка будут намного быстрее, чем любое решение СУБД.

Еще одно предложение, если вы настроены на использование MySQL: вместо механизма хранения MEMORY просто включите много памяти для различных буферных кешей. Таким образом, данные будут надежными, прозрачно обеспеченными дисковым хранилищем, но быстро доступными при их использовании.

Answer 2

Ваша интуиция кажется правильной. Я бы порекомендовал создать таблицу следующим образом:

CREATE TABLE session (
  id CHAR(32) NOT NULL,
  data BLOB NOT NULL,
  t_created TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
  t_updated TIMESTAMP,
  PRIMARY KEY (session_id),
  INDEX t_created(t_created),
  INDEX t_updated(t_updated)
)
ENGINE = MEMORY
CHARACTER SET utf8;

Примечания:

• id - CHAR дешевле, если вы знаете длину содержимого
• data - BLOB (Большой двоичный объект) более применим здесь, поскольку вы, вероятно, храните что-то отличное от TEXT.
• t_created и t_updated - TIMESTAMP - вычисления выполняются быстрее, хотя вы ограничены диапазоном времени 1901-2038, но для этого приложения это подойдет.
• ИНДЕКСЫ для t_created и t_updated требуют больших затрат памяти и не являются полностью необходимыми, но они действительно могут повысить производительность при запросах по этим столбцам.
• Таблицы ПАМЯТИ, хотя и невероятно быстрые, имеют свои ограничения. Если ваш mysqld перезапустится, все данные будут потеряны.

Примечание: Я не уверен, как вы планируете собирать мусор для своих сеансов, но если вы ожидаете, что 50% ваших сеансов будут менее 5 минут, как определяется конец сеанса? Должен ли пользователь / клиент явно завершать свой сеанс (через выход из системы)? Если вы неявно завершаете сеансы так быстро, у ваших пользователей может быть очень непростое времяпровождение с вашим сайтом.