Ответ

JustDoit 18.06.2010 15:47

К счастью (тьфу-тьфу), концепция моего проекта 99% расчитана на скачивание и лишь 1% возможно на запись, если не реже, причем записи не требуют тут же доступа на чтение, то есть закачка премодерируемая. Таким образом я почти свободно могу плодить сущности паралеллельных серверов, и в "почтовые часы" (ненагруженное время) например делать уже подтяжку данных, репликацию там, синхронизацию... То есть про проектирование БД и бэкенды есть некие знания по крайней мере представления в рамках моего проекта должно хватить. Интересует именно мироустройство самого Парсера. Если он так прожорлив на hdd а это естетственно при таком удобстве иерархии файлов и прочего...
Вижу палку о двух концах:

С одной стороны:
Кэш-файлы парсера -- не грузят вычисление при рендере страницы, зато I/O много

С другой: БД -- возможно кэширует в памяти частозапрашиваемые данные на отдачу, чем разгружает I/O, но тогда грузится парсер вычислениеями.

Что вижу: Может имеет смысл засунуть как-то кэш страницы как binary или text-данные в БД, а на стороне Парсера реализовать свой кэш-обертку, который будет подгружать с БД как нить (я полагаюсь на БД что она подтянет горячие данные в память) ...
А может тупо - смонтировать RAM-диск на системе и положить туда кэш-файлы
и вот тогда уже будет и "дудочка и корзиночка"?

---