Я создаю приложение, которое должно хранить и повторно использовать большие объемы данных за сеанс.
Например, пользователь выбирает большой список элементов списка (скажем, 2000 или значительно больше), которые имеют числовое значение в качестве своего ключа, затем сохраняют этот выбор и переходят на другую страницу, делают что-то еще, а затем возвращаются к оригиналу страницы и нужно загрузить их выбор на эту страницу.
Каков самый быстрый и эффективный способ хранения и повторного использования этих данных?
В текстовом файле, сохраненном с идентификатором сеанса?
В таблице временного БД?
В самих сеансовых данных (сеансы БД, размер которых не является пределом), используя сериализованную строку или используя gzcompress или gzencode ?
Хотя обычно я всегда рекомендую пользователям хранить свои данные в базе данных, а не в простых файлах, это исключение. В общем, есть небольшие накладные расходы при хранении данных в базе данных по сравнению с файлами, но первый обеспечивает большую гибкость при доступе и устраняет многие проблемы с блокировкой. Однако, если вы не ожидаете, что ваша страница станет особенно медленной, и пользователи будут работать с несколькими браузерами, получающими доступ к одному и тому же сеансу, то параллелизм не будет большой проблемой, т.е.
Использование любой базы данных будет медленнее
(также, если вы собираетесь иметь дело с большим кластером веб-серверов – более 200 – совместно использовать один и тот же сеанс, то да, распределенная база данных может превзойти файловую систему кластера в SAN).
Вероятно, вы хотите подумать о том, как часто сессия будет написана. Обработчик по умолчанию записывает данные обратно на диск каждый раз, независимо от того, был ли он изменен или нет – для такого большого сеанса я предлагаю вам использовать ваш собственный обработчик сеанса, который записывает не только сериализованные данные сеанса в файл , но также хранит хэш сериализованных данных – когда вы читаете в сеансе, храните хеш в статической переменной. В обработчике сохранения создайте новый хеш и сравните его со статической переменной, заполненной во время загрузки, – только запишите сеанс, если он изменился. Вы можете продолжить это, применив эвристику для разделения сеанса на части, которые часто обновляются, и части, которые менее часто меняются, а затем записывают их в отдельные файлы.
Использование сжатия для этого на самом деле не поможет в производительности.
Конечно, есть множество возможностей для настройки уровня ОС, чтобы оптимизировать это, но вы не говорите, что такое ваша ОС. Предполагая, что его POSIX и ваша система еще не на коленях, ваши хиты превалирования будут:
Задержка доступа к файлу данных и анализ данных
(время для чтения файла относительно невелико, и запись должна буферизироваться).
До тех пор, пока будет достаточно кеша, файл будет считан из памяти, а не из диска, поэтому латентность будет незначительной.
C.
в любом случае вы хотите. Но независимо от того, что вы выберете, массив будет сериализован в строку и сохранен либо в файле (неявно, используя сеансы), либо в поле базы данных. Чтение и запись выполняется быстрее в файле, так что это поиск. Я не вижу причин использовать для этого базу данных.
Для альтернативной сериализации ознакомьтесь с этим инструментом: http://msgpack.sourceforge.net/
База данных будет работать для этого. Просто свяжите сеанс с таблицей посетителей и создайте таблицу с именем visitor_list_items, которая сохраняет выбранные элементы в виде строк.
2000 не является безумным номером для извлечения. Я имею в виду, geez, если они собираются сидеть и выбирать 2000 элементов списка, они могут подождать одну секунду для загрузки страницы! (Вы уверены, что нет способа разбить этот процесс выбора на этапы?)
Если он находится в db, вы можете использовать обычные db-приложения (т. Е. Более легко запускать отчеты о том, какие пользователи выбирают, когда они приходят на ваш сайт и т. Д.).