Здравствуйте, SSDD, Вы писали:

SSD>Отчеты не сложные( как текст, так и графики), но могут быть достаточно разнообразные(произвольные интервалы времени, различный набор критериев), например: клики за вчера с 12 до 17 часов, с географическим таргетингом Москва, от рекламодателя такого-то, стоимостью в дипазоне таком-то(подобный случай один из самых сложных)

В том числе — и "за два последних года"? Или объем нужных данных ограничен?

Хм, если записи в лог в удобном формате, то awk (если не просто grep) такое вполне соберет.
А всяких графопостроителей под Linux хватает.
При этом же и запись и чтение идет "потоком", так что если одновременно не строится несколько отчетов, то все хорошо.
Вот если строится — то уже печальнее.

SSD>Производительность на запись — данные должны успевать попадать в сторадж ранее следующей порции.
Ну, тут в любом случае надо буферизовать, тогда это не станет существенным.

SSD>Чтение — оператор не должен успеть заснуть(хотя отложенная генерация отчетов вполне допустима).
SSD>Набор отчетов не статичен, пользователей не очень много, но несколько десятков вполне вероятно.

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



ДФ>>Ну или смотреть в сторону Hadoop, оно как раз для таких задач....

SSD>Вы об этом? http://ru.wikipedia.org/wiki/Hadoop
Ага. Посмотрите на MapReduce как идею и погуглите про анализ логов с Hadoop.
Но это решение популярно при терабайтах, при меньших объемах проще по старинке...


Я бы еще поуточнял, за какое время отчеты нужны реально, за какое — сразу многим сотрудникам.
И прикинул, может, можно все за год хранить на одном компе, а последнюю неделю — держать на трех одновременно и гонять отчеты там.