Ещё читал про хранение на стороне клиента в куках, зашифровано, с ключом и т.д. но мне вообще это не подходит. Я не доверяю данным клиента, даже id сессии из Кук проверяю. Да и ограничение данных в куках. В общем, от этого сразу отказался.
Возьмём MySQL метод хранения будет отличным от метода хранения в файлах? Без сериализации? По id сессии каждый раз запрашивать разные данные и обрабатывать их каждый запрос? Или нормальным считается получить данные, обработать их, сериализовать и сохранить в БД? Потом доставать и просто десериализовать без необходимости обработки (как в начале самом)?что об этом думаешь?
В Memcached я буду хранить кэш, который не критично потерять, не хотелось бы всё это смешивать в одной области.
… я не говорю, что соединение с мускулом дольше, чем открытие и чтение файла… я именно про запросы и получение результа- ну запрос потом ответ - это ведь время… большее, чем просто чтение. Нет что ли?)
Cегодня поработал с кэшем (именно с кэшем, не с хранилищем для сессий, чуть отойду от темы)… написал класс для кэширования, который, в зависимости от доступности или при указании, кэширует образом: Memcached, SQLite, файловая система. Некоторые данные кэшировал. Сравнил. Ну и в общем, чтение данных с фл было быстрее, чем с БД, которая была быстрее Memcahed. Я ожидал прямо противоположный результат)) А воот в плане записи в кэш - противоположный результат.
Я не сравнивал множество записей в кэш, множество чтения данных из кэша. Ну и одновременную запись в кэш множеством юзеров и одновременное чтение из кэша множеством юзеров тоже не сравнивал. Этим займусь послезавтра.