Предложение базы данных для обработки / создания отчетов для большого количества данных типа файла журнала

Question

У нас есть приложение, которое создает текстовые файлы журнала запросов к нему. Довольно типичный материал в файле журнала, разделенный пробелами (дата, время, URL, http-код, ip, пользовательский агент и т. Д.).

В настоящее время мы генерируем около 500 тыс. Записей в файлах текстового журнала в день.

В настоящее время мы проводим большой анализ текстовых файлов с помощью sed / awk / grep. Однако в действительности это масштабироваться не будет, тем более что мы хотим начать составлять отчеты за несколько дней:

например. - Сколько раз этот IP-адрес попадал на этот URL за последние 5 дней - Какой процент запросов привел к 500-ым для определенных URL

Достаточно просто выполнять регулярный импорт в базу данных mysql и извлекать данные этого типа с помощью select / group-bys. Однако даже при наличии нескольких сотен тысяч строк запросы выполняются относительно медленно.

Я n00b, когда дело доходит до некоторых новых БД no-sql (Casandra, Dynamo, BigTable), но подойдет ли какой-нибудь из них для этого? Я продолжаю читать их, но, возможно, у этой команды были некоторые рекомендации.

Спасибо!

Answer 1

У нас была похожая проблема на работе, и нам удалось ее решить, сбросив данные в базу данных на основе столбцов. Такие базы данных гораздо лучше справляются с аналитическими запросами того типа, который вы описываете. Есть несколько вариантов:

http://en.wikipedia.org/wiki/Column-oriented_DBMS

У нас был хороший опыт работы с InfiniDB:

http://infinidb.org/

Используя этот подход, нам удалось ускорить запросы прибл. 10x, однако, это не серебряная пуля, и в конечном итоге вы снова столкнетесь с теми же проблемами.

Возможно, вы захотите взглянуть на разбиение ваших данных для повышения производительности.

Answer 2

Есть несколько причин, по которым я бы не стал сразу искать решение NoSQL:

• Ваша известная схема звучит так, как будто она не изменится.

• Кажется, что у вас нет большого денормализующего потенциала, так как у вас в значительной степени есть структура с одним плоским столом.

• Вы не указали масштабируемость приложения (количество пользователей), только размер запроса.

И это три большие «победы» для NoSQL, насколько я знаю.

Как говорится, я не эксперт, и я точно не знаю, что это не поможет быстрее читать, так что это определенно стоит попробовать!