вращающегося хранилища, например, для управления сеансом?

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

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

 CREATE TABLE `session` (
     `session_id` VARCHAR (32) NOT NULL,
     `session_data` ТЕКСТ NOT NULL,
     `t_created` DATETIME NOT NULL,
     `t_updated` DATETIME NOT NULL,
     ПЕРВИЧНЫЙ КЛЮЧ (`session_id`)
 ) ENGINE = INNODB DEFAULT CHARSET = utf8;

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

Детали:

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

Результаты:

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

Ожидаемый срок службы строк (например, длительность сеанса):

30%: 0 с-30
20%: 30 с-5 м
30%: 5 м-1 ч
20%: 1ч-8ч

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

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

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

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

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

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 (Binary Large OBject) здесь более применим, так как вы, скорее всего, сохраняете что-то отличное от TEXT.
t_created и t_updated – TIMESTAMP – вычисления выполняются быстрее, хотя вы ограничены временным диапазоном 1901-2038, но это должно быть хорошо для этого приложения.
ИНДЕКСЫ на t_created и t_updated являются дорогостоящими и не совсем необходимыми, но они могут действительно помочь производительности при запросе этих столбцов.
Таблицы MEMORY, хотя и невероятно быстрые, имеют свои ограничения. Если ваш mysqld перезагружается, все данные будут потеряны.

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

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

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