Используй ту конкретную реализацию key-value которая не будет вызывать у тебя танцев 

Как только поработаю с этим на практике так сразу смогу тебе ответить более конкретно  Пока таких задач не было и в обозримом будущем не предвидится.


Не-не-не. Тут все не так просто. сессия - это небольшой кусочек данных. Поэтому пару тысяч сессий легко умещаются в файловые кеши (блин, ну не работал я с *nix плотно в качестве админа, но откуда-то висит в памяти цифра в пару мегабайт именно в ассоциации с кешем файловой структуры (не путать с файловым кешем))
Когда речь идет о кешировании гигабайтов.... Чуйка говорит что не все так просто и память должна быть лучше. А чуйке я верю 

А вот со сложностью реализации - понятия не имею. 

Дай пруфлинки (что файловый кеш лучше по скорости чем хранение в памяти при сопоставимой сложности реализации), раз ты с этим сталкивался и работал 

Снова-здорово!  Обновил свой первый пост  


В задании ТС ни чего не говориться о размерах значений, но скорее всего речь идет о небольших значениях. Т.ч. тут миллион точно таких-же маленьких кусочков данных, что в сумме вряд-ли дотянет до гигабайта.

Пара пруфлинков в подтверждение применимости файлового кеша:
http://sysoev.ru/nginx/docs/http/ngx_http_...l#fastcgi_cache - используется файловый кеш для fcgi запросов. Замечу, что nginx считается одним из самых быстрых www-серверов.
http://httpd.apache.org/docs/2.2/mod/mod_file_cache.html - в реальных проектах не встречал, но думаю, этот модуль вполне может использоваться и на относительно нагруженных проектах
http://ie2.php.net/manual/en/intro.session.php - дефолтный механизм так же способен работать на высоко нагруженных проектах, но в highload проектах обычно используется memcache, это связано не столько с производительностью, сколько с необходимостью распределенного доступа к ним.

Дай мне конкретную задачу и я тебе скажу какой, на мой взгляд, механизм кеширования лучше применить для ее решения. А сравнение сферических коней в вакууме достаточно бессмысленное занятие.

В том-то и дело  что распределенность обычно возникает как ответ на требования производителности 

Ладно. И на том спасибо 



Да нет у меня такой конкретной задачи  Я обычно работаю  с сложными (в плане множества функций и внутренних связей) задачами, но к хайлоаду отнести их никак нельзя.
Была бы задача, я давно бы уже нашел решение. А так.... 

Как в анекдоте

Опять же задачи разные бывают, где-то для лучшей производительности наоборот выгоднее использовать независимые изолированные локальные хранилища, т.к. в этом случае есть множество своих плюсов (к примеру, таких как лучшая эффективность при большом количестве конкурирующих запросов или даже вовсе неблокирующий доступ). Но в случае с сессиями - это просто необходимо, т.к. www серверов может быть не одна ферма, но при этом любая сессия может потребоваться на любом сервере.

А как же без индекса быстро удалять устаревшие записи ? Понятно что часть таких записей удалиться при get(). А если идет set() и закончилось свободное место ? Ходить по всем папкам и искать expired-файлы ? ИМХО индекс существенно ускорит удаление устаревших записей.

Запуск раз в час по крону

практически никакой нагрузки не создаст.

И потом, что для вас важнее: быстрая и эффективная работа кеша или быстрое удаление устаревших записей? Скорость второго, по моему, вообще не имеет никакого значения.

Это сообщение отредактировал(а) sTa1kEr - 6.12.2009, 15:08

Тогда и для винды надо команду не забыть.


Важнее конечно скорость. Но место под кеш может закончится раньше, чем через час. Допустим через пол часа. Получается остальные полчаса ничего записывать не будем ? Или принудительно запускать очистку ? По сути дела, при куче файлов (например 20 млн.) это займет значительное время. Лучше удалить несколько самых старых файлов, освободив только необходимое свободное место. А тут без индекса не обойдешься.

Вообще, в принципе я согласен, что это все какие-то заморочки. Лучше проследить сколько кэша набирается в час пик. Задать под кэш в 1,5 раза больше места и не париться с индексами. Это все же ближе к жизни.

Пфф. Зачем? Запомните: в highload проектах универсальность совершенно не нужна, в highload систему настраивают под проект, а не проект под систему(ы). 

Все вышесказанное мной в этой теме про файловый кеш относится к *nix, насколько будет эффективен файловый кеш в Windows я понятия не иммею.


Не может.
Во первых, перед тем как вести разработку механизма кеширование, вы должны проанализировать какого примерно объема в нем будут храниться данные и сколько нужно выделить памяти.
Во вторых. Идеология кеша такова, что он не может гарантировать 100% сохранность данных. Любые данные из кеша могут быть удалены в любой момент времени.
В третьих. Если у вас вообще возникает проблема нехватки памяти, то скорее всего принудительная очистка кеша от старых записей даст лишь кратковременный результат. Тут уже надо думать об увеличении памяти или создании дополнительного хранилища.


Вы ошибаетесь.

Это сообщение отредактировал(а) sTa1kEr - 6.12.2009, 16:01

sTa1kEr, да не кому вопросы уточняющие по заданию задавать, вот и мудрю.   

Это сообщение отредактировал(а) webtech - 6.12.2009, 16:18

webtech, 
я все понимаю, но на мой взгляд это задание надо было закончить еще 4-6 дней назад.

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

Simpliest, да не, ты что, я не все это время только этим и занимаюсь  Думаю суммарное время не превысит 2-3 рабочих дней.

ага самый простой и самый бестолковый, про размер кластера забываете господа, в *nix не знаю, в винде по умолчанию кластер = 4 кб, 
т.е. у вас может быть записано одно число в файлик (количество юзеров онлайн например)  - а занимать он будет все равно 4 килобайт. 
Даже при заполнении файлов 70% в среднем на миллионе файлов потери будут астрономические. 
Вот эта строка для наглядности:
1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 
120 байт весит, т.е. в стандартный кластер можно еще 34 таких куска запихнуть.
Не уверен, но сдается, что на серверах кластер еще больше для ускорения обращения к файлам.

они не имеют значения для кеша.

я когда предлагал сохранять несколько значений в файл исходил исключительно из того, что чтение происходит в любом случае блоком.
Т.е. исключительно для ускорения чтения, но не для экономии места на диске 

      

1кБ не использованный * 1 000 000 файликов =  грубо 1 ГБ
 меня бы убили 

MyDarkSide, знаете такую поговорку "промолчи, глядишь за умного сойдешь"?

Во первых, если мы возьмем reiserfs, то в ней более гибкая структура позволяющая размещать в одном блоке части различных фалов. Более того в ней очень маленькие файлы хранятся в своем inode, что означает значительное увеличение производительности при чтении маленьких файлов(т.к. вовсе не придется читать ни одного блока, сам файл будет получен вместе с ее метаданными) и еще более эффективное использование дискового пространства.
А во вторых


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

Добавлено через 3 минуты и 12 секунд

Вы не путайте, всякие "интернет магазины" и highload проекты - это два совершенно разных уровня задач.

Добавлено через 3 минуты и 57 секунд
Пруфлинк по reiserfs http://www.citforum.ru/operating_systems/l...bins/fs01.shtml