Есть задача — хранить статистику с веб-ресурсов(логи) и генерить по ней отчеты. Нагрузка предполагается очень приличная, даже после агрегации 50-100млн( в пиках до полумиллиарда) записей в сутки. Выборки не сложные: диапазон, точное совпадение, group by.


Какой сторадж посоветуете?

Здравствуйте, Аноним, Вы писали:

А>Есть задача — хранить статистику с веб-ресурсов(логи) и генерить по ней отчеты. Нагрузка предполагается очень приличная, даже после агрегации 50-100млн( в пиках до полумиллиарда) записей в сутки. Выборки не сложные: диапазон, точное совпадение, group by.

А>Какой сторадж посоветуете?

Итого по максимуму
500 000 000 / (24 * 60 *60) ~ 6000 insert'ов в секунду. Это не считая запросов на выборку.
А в IOPS'ах будет и того больше.

Весьма приличная нагрузка, разбиение на несколько серверов не рассматривается? Или накопление пула в in-memory СУБД, с пакетной загрузкой в обычную СУБД для дальнейшего анализа?

А>Весьма приличная нагрузка, разбиение на несколько серверов не рассматривается? Или накопление пула в in-memory СУБД, с пакетной загрузкой в обычную СУБД для дальнейшего анализа?

Да, естественно, накопление пула в памяти (например 60сек или 100мб) и переодическое сбрасывание в сторадж. Шардинг хотелось бы нативный иметь. Сейчас засматриваюсь на NoSQL, но в силу отсутствия опыта работы с ними — окончательный выбор сделать сложновато.

Здравствуйте, Аноним, Вы писали:

А>Есть задача — хранить статистику с веб-ресурсов(логи) и генерить по ней отчеты. Нагрузка предполагается очень приличная, даже после агрегации 50-100млн( в пиках до полумиллиарда) записей в сутки. Выборки не сложные: диапазон, точное совпадение, group by.

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

А>Какой сторадж посоветуете?

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

Здравствуйте, Дельгядо Филипп, Вы писали:

ДФ>А насколько сложные отчеты и какие требования к производительности?

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

Производительность на запись — данные должны успевать попадать в сторадж ранее следующей порции.

Чтение — оператор не должен успеть заснуть(хотя отложенная генерация отчетов вполне допустима).

ДФ>А то для нескольких десятков гигов логов в сутки для отчетов вполне хватало текстовых файлов и стандартных средств типа grep, awk и всяких построителей графиков.

Набор отчетов не статичен, пользователей не очень много, но несколько десятков вполне вероятно.

ДФ>Ну, если писать данные большими блоками и анализировать "потоком", то почти любой

Прихожу к мысли, что не столь писать, сколь удобно читать надобно. =)

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

Вы об этом? http://ru.wikipedia.org/wiki/Hadoop


Совсем не понятно, как оно применимо к моей задаче? =(

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

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

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

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

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

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

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



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

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


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

Здравствуйте, Аноним, Вы писали:

А>Какой сторадж посоветуете?

Column-oriented NoSQL с MapReduce. Таких всего три Hadoop/HBase, Cassandra и Hypertable. Погоняй все три на тестах и выбери. Лично я склоняюсь к HBase.

Почему не SQL? Потому что такой объем в любом случае потребует partitioning и, скорее всего, OLAP. Что на MS SQL, что на Oracle это будет стоить лютых денег, которые ты вместо того чтобы освоить отдашь дядям.