Библиотека / структура данных для обработки огромных данных - PullRequest
14 голосов
/ 09 августа 2010

У меня есть несколько огромных двоичных журналов драйверов (около 2-5 ГБ каждый и, вероятно, примерно в 10 раз больше после преобразования их в читаемую форму), и мне нужно написать инструмент, который позволил бы мне последовательно просматривать, сортировать, искать иэффективно фильтровать их (чтобы находить и устранять ошибки).

Каждая запись в журнале имеет несколько атрибутов, таких как отметка времени, тип, сообщение, некоторые идентификаторы GUID.Записи являются однородными, никаких отношений, нет необходимости хранить данные после «проверки».

Я действительно не знаю, как обращаться с таким большим количеством данных.Хранить все в памяти было бы глупо, то же самое относится и к хранению данных в плоском файле.Я думал об использовании небольших СУБД, таких как SQLite, но я не уверен, что это будет достаточно быстро, и мне не нужны многие функции DMBS - только сортировка и поиск.В этом случае я бы с готовностью променял место на скорость, если это возможно.

Существует ли какая-либо библиотека (или, возможно, структура данных), которая помогла бы мне обрабатывать такие объемы данных?

«Обслуживаемые» СУБД, такие как Postgre, MSSQL, MySQL, исключены, инструментдолжно быть легко использовать в любом месте без каких-либо хлопот.

РЕДАКТИРОВАТЬ: Да, и кто-нибудь знает, если режим SQLite ": память" имеет какие-либо ограничения на размер БД, или он просто заполнит виртуальную память, пока не будет заполненполностью

Ответы [ 9 ]

12 голосов
/ 17 августа 2010

Check STXXL - Стандартная библиотека шаблонов для очень больших наборов данных.

"Ядром STXXL является реализация стандартной библиотеки шаблонов C ++ STL для вычислений внешней памяти (вне ядра), то есть STXXL реализует контейнеры и алгоритмы, которые могут обрабатывать огромные объемы данных, которые соответствуют только размерам.на дисках. В то время как совместимость с STL поддерживает простоту использования и совместимость с существующими приложениями, еще одним приоритетом разработки является высокая производительность. "

Кроме того, если вы можете выделить несколько компьютеров для выполнения задачи, отметьте Hadoop.Особенно HBase, Hive и MapReduce.

6 голосов
/ 09 августа 2010

Я думаю, что хранение этого в СУБД является подходящим подходом. Сортировка и поиск - это задачи, которые DB выполняет превосходно, и при таком большом количестве данных использование специально разработанного инструмента станет огромным преимуществом.

SQLite хорошо подойдет для этого, хотя нереляционное хранилище данных может использовать меньше места. Однако, если вы хотите выполнить поиск по нескольким «записям», БД - это определенно правильный путь.

5 голосов
/ 18 августа 2010

Формат файла HDF5 и связанная с ним библиотека предназначены для хранения огромных объемов данных и обеспечения быстрого и эффективного ввода-вывода через него.

Проект pytables предоставляет хороший способ использовать их из python и предоставляет методы для сортировки и поиска.

3 голосов
/ 18 августа 2010

Как насчет использования некоторого вида ввода-вывода с отображением в памяти, что-то вроде MappedByteBuffer в Java и развертывания собственного инструмента?

Перефразировать из ответа SO на МББ ,

По сути, этот механизм использует систему подкачки виртуальной памяти ОС, чтобы «отобразить» ваши файлы и представить их программно в виде байтовых буферов. ОС будет управлять перемещением байтов на / с диска и памяти автоматически и очень быстро.

Для вас имеет смысл создать такие файлы для каждого из ваших файлов журнала, чтобы прочитать их. Предостережение заключается в том, что вы должны использовать 64-битную версию, поскольку это дает вашим файлам ограничение в ТБ, а не в ГБ.

Просмотр, фильтрация и сортировка Простое отображение файлов в некоторой иерархии и использование метрики, такой как имя файла или отметка времени, для их сортировки должно быть простым с вашим собственным кодом, когда вы имеете дело с MBB. Каковы ваши критерии фильтра?

Поиск Теперь, если вы хотите выполнить поиск по ним - Lucene, работающий поверх этого, даст вам хороший метод для индексации файлов. Вы также можете использовать это различными способами - используйте hadoop и Map / Reduce, как уже упоминали другие, для распределения задач по нескольким машинам.

Советы по повышению производительности на этом сайте великолепны.

2 голосов
/ 20 августа 2010

Log parser.Я предлагаю вам взглянуть на парсер журнала msft.Это входит в комплект ресурсов iis и предоставляет много того, что вы ищете.Пожалуй, самая полезная функция - это возможность выполнять SQL-запросы к плоскому файлу.Это можно сделать даже в разных файлах.

2 голосов
/ 17 августа 2010

Я рекомендую использовать некоторую реализацию MapReduce, возможно, Hadoop или что-то подобное. У меня не было возможности поработать с Hadoop после теоретической презентации, которую мне дали, но она выглядит многообещающей.

Альтернативой является использование коммерческих инструментов, таких как Splunk .

1 голос
/ 21 августа 2010

Один из вариантов: Berkeley DB или какой-либо аналогичный встраиваемый менеджер баз данных.

Я не использовал Berkely DB, но, по беглому взгляду, я предполагаю, что он похож на многие менеджеры баз данных ISAM, которые были много лет назад - в основном это библиотека для обработки ключа на диске-> данных индекса данных структур. Единственное предупреждение - я видел упоминание о хеш-таблицах, поэтому он может не выполнять последовательную часть ISAM, но я ожидаю, что это так - в самой последней версии даже есть поддержка SQL.

Вам не обязательно переводить полный двоичный журнал в читаемую форму. Вы можете выполнить начальное сканирование индексации, которое сохраняет смещения в исходных файлах. Одним из полезных индексов может быть просто номер строки в диапазоне байтов, поэтому вы можете быстро отобразить определенный диапазон строк - хотя, конечно, только если записи журнала имеют переменную длину.

Если это что-то вроде Btrieve (который я использовал несколько лет назад), это должно быть достаточно просто.

0 голосов
/ 24 августа 2010

"отметка времени, тип, сообщение, некоторые идентификаторы GUID. Записи являются однородными, никаких отношений, нет необходимости сохранять данные после« проверки »их.»

Рассматривали ли вы просто сохранение дискретных записей какОтдельные файлы в каталоге?

Если вам просто нужно выполнить простую сортировку, то создайте имя файла из полей сортировки и поместите остальные в файл.Выбор быстрый, если вы знаете, какие поля вам нужны.

И, что лучше всего, API встроен в ОС.

..

Очевидно, что если вам что-то нужноболее гибкий, тогда вам понадобится правильная БД, но она может работать в зависимости от ваших требований.

0 голосов
/ 24 августа 2010

Вы не указали язык.Так что просто предоставив модуль, позволяющий вам осуществлять произвольный доступ к файлу, предположительно эффективным способом: http://perldoc.perl.org/Tie/File.html

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...