Библиотека/структура данных для обработки огромных данных

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

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

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

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

"Служебные" RDBMS, такие как Postgre, MSSQL, MySQL, не могут быть и речи, инструмент должен быть прост в использовании в любом месте без каких-либо проблем.

EDIT: О, и кто-нибудь знает, имеет ли режим SQLite ": память" какие-либо ограничения на размер БД или он просто заполнит виртуальную память до полного ее заполнения?

Ответы

Ответ 1

Отъезд STXXL - стандартная библиотека шаблонов для сверхбольших наборов данных.

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

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

Ответ 2

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

SQLite будет хорошо работать для этого, хотя нереляционное хранилище данных может использовать меньше места. Однако, если вы хотите выполнять поиск по нескольким "записям", DB определенно подходит.

Ответ 3

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

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

Ответ 4

Как насчет использования какой-либо памяти, подключенной к I/O, что-то вроде Java MappedByteBuffer и свернуть собственный инструмент?

Чтобы перефразировать из ответа SO на MBB,

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

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

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

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

Рекомендации по производительности этот сайт отличный.

Ответ 5

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

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

Ответ 6

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

Ответ 7

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

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

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

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

Ответ 8

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

Ответ 9

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

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

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

И самое главное, api встроен в ОС.

..

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