MySQL Session Table подход

Question

Я занимаюсь разработкой мультитенантного веб-приложения с использованием LAMP. Все мои данные сеанса пользователя в настоящее время хранятся в MySQL с типом таблицы InnoDB.

Можно ли каким-либо образом использовать табличный тип MEMORY (ранее HEAP) для хранения текущих сеансов и использовать функцию сборщика мусора обработчика сеансов для перемещения сеансов между InnoDB (обычная таблица) и (in) Таблица ПАМЯТИ?

Также будет ли эта конфигурация влиять каким-либо образом, когда я хочу кластеризацию и конфигурацию master-slave на более позднем этапе?

Заранее спасибо, ocptime

Answer 1

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

Схема что-то вроде (снято с изменениями из предыдущего вопроса )

CREATE TABLE IF NOT EXISTS `session` (
  `id` char(32) NOT NULL,
  `data` varchar(20000) NOT NULL,
  `time_created` timestamp NOT NULL default '0000-00-00 00:00:00',
  `time_updated` timestamp NOT NULL default '0000-00-00 00:00:00' on update CURRENT_TIMESTAMP,
  PRIMARY KEY  (`id`),
  KEY `time_created` (`time_created`),
  KEY `time_updated` (`time_updated`)
) ENGINE=MEMORY DEFAULT CHARSET=utf8;

тогда вам просто нужно определить функции обработчика сеанса, как описано в ссылке выше или в этом учебном пособии . Если вы хотите сохранить информацию о сеансе во время сборки мусора, вам просто нужно создать таблицу, идентичную приведенной выше, с использованием механизма INNODB и добавить бит в конце функции gc(), которая копирует строку из MEMORY до INNODB таблиц.

Однако MEMORY таблицы имеют довольно значительные ограничения. Они не могут использовать столбцы BLOB или TEXT - вот почему у меня выше уродливо varchar(20000). Они имеют максимальный размер 16 МБ. Если у вас много пользователей, вы сохраняете много состояний или у вас проблемы со сборкой мусора, вы можете достичь этого предела и вылететь.

Лучше всего использовать обработчик сеанса memcache , особенно если вам не нужно хранить информацию о сеансе в отдаленном будущем. Я почти уверен, что memcached быстрее, чем любая СУБД (даже с MEMORY таблицами), и он хорошо масштабируется в соответствии с дизайном. Кроме того, вам не придется писать собственные функции обработчика сеансов.

Answer 2

InnoDB: ~40 milliseconds Cons: (Slowest)
MEMORY: ~22 milliseconds Cons: (16MB Max)
MyISAM: ~25 milliseconds Cons: (Table-level locking)

---

Я использую (gs), поэтому я не могу сделать memcache, но это было бы лучше.

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

Моя рассматриваемая php-страница кэшируется в smarty, поэтому единственные операции, которые здесь происходят, - это поиск по URL-адресу и захват сеанса sql, чтобы проверить, вошел ли пользователь в систему.

В любом случае вот результаты: с InnoDB я получал ~ 40 миллисекунд ожидания по запросу. (Я измерял это в chrome с помощью инструментов разработчика.) После переключения таблицы на MEMORY я получил ~ 20 миллисекунд на запрос. Вот Это Да! 50% улучшение! Но подождите ... как насчет MyISAM? Я попробовал это, и я получил ~ 22-23 миллисекунды за запрос. Ох. ​​

Это я тестирую, а не полнофункциональное приложение. В реальном приложении каждую секунду тысячи людей пишут в эту таблицу, и MyISAM выполняет блокировку на уровне таблицы, что может быть плохо ( Какой механизм базы данных MySQL лучше подходит для хранения сеансов и данных сеансов: MyISAM или InnoDB? ).

Так что я пока держусь за память. Это огромное улучшение для этих кэшированных страниц, но я призываю вас в профиле! Если ваш сайт перестраивает каждую страницу, 10 миллисекунд могут не иметь значения.

Answer 3

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