Хранение и обработка большого количества информации
От: Twirl Швеция  
Дата: 17.06.08 13:07
Оценка:
Добрый день!
Передо мной возникла следующая задача.

Имеется некий лог от некого устройства. Лог представляет из себя набор строчек в формате cvs с переменным числом параметров (общий формат timestamp _тип события_,arg1, arg2 ..., argN). В среднем в логе находится от 100 до 500 тысяч событий. Таких логов, со временем, предпологается иметь очень много (от 50 до 100 тысяч). По каждому конкретному логу необходимо строить статистику. Статистика может быть как заранее определенная (допустим количество событий N типа), так и заданная пользователем (например сумма arg3 для всех событий типа N за определенный промежуток времени в логе). Логи отдаются серверу поштучно и данные в конретном логе не меняются.

Как это наиболее эффективно реализовать хранение и обработку такого количества информации?
Re: Хранение и обработка большого количества информации
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 17.06.08 14:35
Оценка: 4 (1)
Здравствуйте, Twirl, Вы писали:

T>Как это наиболее эффективно реализовать хранение и обработку такого количества информации?

В виде базы данных. Далее, в зависимости от дополнительных условий, описанная Вами абстрактная проблема может преобразоваться в конкретные задачи:

  1. Как извлечь данные из текстовых файлов и поместить их в таблицы реляционной базы данных (например, MS SQL, Oracle или My SQL)? Какой DB-сервер выгоднее выбрать? Какие должны быть таблицы и рилейшены?
  2. Как самостоятельно создать файловую базу данных? Какие абстрактные типы данных выгоднее использовать для хранения данных? Какие будут таблицы в этой файловой базе данных?
  3. Как сгруппировать существующие лог-файлы по каталогам? И как лучше организовать поиск по существующим лог-файлам без изменения их формата?

Каждая задача имеет свои технические решения. Чтобы подойти к решениям, Вам для начала нужно выбрать задачу. А выбрать её будет можно только после того, как Вы определитесь, какие будут запросы к базе данных, какая будет на неё нагрузка и какая будет допустимая наихудшая производительность для каждого запроса при полной нагрузке.
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re: Хранение и обработка большого количества информации
От: Darth Jurassic  
Дата: 17.06.08 15:50
Оценка: 4 (1)
Здравствуйте, Twirl, Вы писали:

T>Добрый день!

T>Передо мной возникла следующая задача.

T>Имеется некий лог от некого устройства. Лог представляет из себя набор строчек в формате cvs с переменным числом параметров (общий формат timestamp _тип события_,arg1, arg2 ..., argN). В среднем в логе находится от 100 до 500 тысяч событий. Таких логов, со временем, предпологается иметь очень много (от 50 до 100 тысяч). По каждому конкретному логу необходимо строить статистику. Статистика может быть как заранее определенная (допустим количество событий N типа), так и заданная пользователем (например сумма arg3 для всех событий типа N за определенный промежуток времени в логе). Логи отдаются серверу поштучно и данные в конретном логе не меняются.


T>Как это наиболее эффективно реализовать хранение и обработку такого количества информации?


Перечислить собираемые статистики. Далее попробовать описать поведение каждой статистики:
1. как очередной лог влияет на статистику;
2. как реализовать изменение статистики с наименьшими потерями точности.
Re: Хранение и обработка большого количества информации
От: Аноним  
Дата: 17.06.08 16:46
Оценка: 2 (2)
Здравствуйте, Twirl, Вы писали:

T>Имеется некий лог от некого устройства ... Логи отдаются серверу поштучно и данные в конретном логе не меняются.

T>Как это наиболее эффективно реализовать хранение и обработку такого количества информации?

OLAP?
Ведь если данные не меняются, то максимальная эффективность будет при построении информационного куба, где статистика по измерениям пересчитывается лишь при добавлении новых данных, а разные запросы не вызывают пересчетов, лишь извлекают уже готовые (пусть и избыточные) статистические данные.
Re[2]: Хранение и обработка большого количества информации
От: Jericho113 Украина  
Дата: 18.06.08 05:37
Оценка:
Здравствуйте, Аноним, Вы писали:

А>OLAP?

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

до олапа еще дорасти нада
я в смысле того что если нужны четко определенные отчеты то смысла заморачиваться с построением кубов /измерений и мер
большого нет.
В случае четко определенных отчетов нужно просто собирать агрегированную статистику по параметрам датчиков которые будут входить в отчеты
а сырые данные хранить в отдельной большой (желательно партиционированной ) таблице.
NetDigitally yours ....
Re: Хранение и обработка большого количества информации
От: stump http://stump-workshop.blogspot.com/
Дата: 18.06.08 06:35
Оценка: 4 (1)
Здравствуйте, Twirl, Вы писали:

T>Добрый день!

T>Передо мной возникла следующая задача.

T>Имеется некий лог от некого устройства. Лог представляет из себя набор строчек в формате cvs с переменным числом параметров (общий формат timestamp _тип события_,arg1, arg2 ..., argN). В среднем в логе находится от 100 до 500 тысяч событий. Таких логов, со временем, предпологается иметь очень много (от 50 до 100 тысяч). По каждому конкретному логу необходимо строить статистику. Статистика может быть как заранее определенная (допустим количество событий N типа), так и заданная пользователем (например сумма arg3 для всех событий типа N за определенный промежуток времени в логе). Логи отдаются серверу поштучно и данные в конретном логе не меняются.


T>Как это наиболее эффективно реализовать хранение и обработку такого количества информации?


Довольно типичная задача. Решается в три этапа: ETL — Data Storage — OLAP

1. Загрузка поступающих данных в промежуточное реляционное хранилище (ctage storage). Обычно структура хранилища повторяет структуру входных данных. Здесь данные хранятся до загрузки в основное хранилище (обычно очень не долго).
2. Очиска, нормализация и свертка данных. Выбираем данные из промежуточноего хранилища и группируем их по аналитическим признакам. Например данные с устройства снимаются каждые 10 мсек, а для анализа достаточно грануляции в 1 сек — сворачиваем данные группируя их по времени, это уменьшит хранимый объем в 100 раз. Аналитические признаки ( напр _тип события_) кроме времени, выносятся в связанные таблицы — это нормализация.
3. Резултаты п.2 сохраняются в основном хранилище. Его структура нормализована и оптимизирована для хранения и выборки большого объема данных.
4. На основе хранилища строим OLAP кубы в соответствии с потребностями анализа. Делаем фиксированные отчеты или прикручиваем какого нибудь OLAP клиента для свободного анализа по кубам.
Понедельник начинается в субботу
Re: Хранение и обработка большого количества информации
От: splix  
Дата: 18.06.08 08:07
Оценка: 4 (1)
Еще можно посмотреть на подход mapreduce, а именно на Apache Hadoop + PIG, может вам подойдет.
Re: Хранение и обработка большого количества информации
От: Twirl Швеция  
Дата: 18.06.08 08:15
Оценка:
Здравствуйте, Twirl, Вы писали:

T>Добрый день!

T>Передо мной возникла следующая задача.

T>Имеется некий лог от некого устройства. Лог представляет из себя набор строчек в формате cvs с переменным числом параметров (общий формат timestamp _тип события_,arg1, arg2 ..., argN). В среднем в логе находится от 100 до 500 тысяч событий. Таких логов, со временем, предпологается иметь очень много (от 50 до 100 тысяч). По каждому конкретному логу необходимо строить статистику. Статистика может быть как заранее определенная (допустим количество событий N типа), так и заданная пользователем (например сумма arg3 для всех событий типа N за определенный промежуток времени в логе). Логи отдаются серверу поштучно и данные в конретном логе не меняются.


T>Как это наиболее эффективно реализовать хранение и обработку такого количества информации?


Спасибо за ответы. Буду копать оптимальное решение.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.