База данных или другой метод хранения и динамического доступа к ОГРОМНЫМ двоичным объектам

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

Было бы достаточно легко сохранить эти записи в виде строк данных BLOB в реляционной базе данных, но есть много случаев, когда я хочу загрузить в память только определенные столбцы всего набора данных (скажем, образцы 1000–2000). Какой способ сделать это наиболее эффективно с точки зрения памяти и времени?

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

РЕДАКТИРОВАТЬ: Чтобы уточнить размеры данных ... Один файл состоит из: 100 000 строк (записей) по 2 000 000 столбцов (образцов). Большинство исследованных мною реляционных баз данных позволяют разместить в таблице от нескольких сотен до пары тысяч строк. Опять же, я мало что знаю об объектно-ориентированных базах данных, поэтому мне интересно, может ли что-то подобное помочь здесь. Конечно, любое хорошее решение приветствуется. Спасибо.

РЕДАКТИРОВАТЬ: чтобы прояснить использование данных ... Доступ к данным будет осуществляться только пользовательским настольным / распределенным серверным приложением, которое я напишу. Существуют метаданные (дата сбора, фильтры, частота дискретизации, владелец и т. Д.) Для каждого «набора» данных (который до сих пор я называл файлом размером 200 ГБ). Существуют также метаданные, связанные с каждой записью (которые, как я надеялся, будут строкой в ​​таблице, чтобы я мог просто добавить столбцы для каждой части метаданных записи). Все метаданные согласованы. Т.е. если конкретная часть метаданных существует для одной записи, она также существует для всех записей в этом файле. Сами образцы не имеют метаданных. Каждая выборка представляет собой 8 бит простых двоичных данных.


person Eric    schedule 29.12.2011    source источник
comment
Не уверен, должен ли это быть комментарий или ответ, но связанные вопросы stackoverflow.com/questions/7963656/ и stackoverflow.com/questions/8952/ может дать некоторое просветление.   -  person    schedule 29.12.2011
comment
Каким образом можно будет получить доступ к данным? Вы пишете настольное приложение, веб-сайт и планируете использовать Excel? Какие метаданные существуют о файлах и образцах? Согласован ли он в схеме, т.е. есть ли у каждого файла и образца одинаковые поля?   -  person Neville Kuyt    schedule 29.12.2011
comment
@MarkBannister - ответы на эти вопросы в некоторой степени полезны для общих случаев хранения данных BLOB в базах данных, однако мое желание получить доступ к данным по столбцам может сделать мой случай другим. Хотя, может, и нет.   -  person Eric    schedule 30.12.2011


Ответы (4)


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

Я бы порекомендовал сохранить файл на диске, но создать индекс на основе БД. Большинство файловых систем становятся капризными или медленными, если в папке / каталоге / и т. Д. Имеется> 10 тыс. Файлов. Ваше приложение может сгенерировать имя файла и сохранить метаданные в БД, а затем организовать их по сгенерированному имени на диске. Недостатком является то, что содержимое файла не может быть прямо видно из имени. Однако вы можете легко создавать резервные копии измененных файлов без специализированных плагинов резервного копирования БД и сложной схемы инкрементного резервного копирования с разбиением на разделы. Кроме того, поиск в файле стал намного проще (переход вперед, перемотка назад и т. Д.). Как правило, поддержка этих операций в файловой системе лучше, чем в БД.

person saarp    schedule 29.12.2011

Интересно, почему вы думаете, что СУБД будет ограничена простыми тысячами строк; нет никаких причин, по которым это могло бы быть так.

Кроме того, по крайней мере, некоторые базы данных (например, Oracle) разрешают прямой доступ к частям LOB-данных без загрузки полного LOB-объекта, если вы просто знаете смещение и длину, которые хотите иметь. Итак, у вас может быть таблица с некоторыми доступными для поиска метаданными, а затем столбец LOB и, если необходимо, дополнительная таблица метаданных, содержащая метаданные о содержимом LOB, чтобы у вас было какое-то отношение ключевого слова -> (смещение, длина). для частичной загрузки больших объектов.

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

person Juha Laiho    schedule 29.12.2011
comment
Ах, блин ... Я имел в виду тысячи столбцов. Отредактирую правку. - person Eric; 03.01.2012

Насколько велик каждый сэмпл и насколько велика каждая запись? Вы говорите, что каждая запись - это 2000000 сэмплов или каждый файл? (это можно прочитать в любом случае)

Если 2 миллиона выборок составляют 200 ГБ, тогда каждая выборка составляет ~ 10 КБ, а каждая запись - 200 КБ (чтобы иметь 100000 на файл, что составляет 20 выборок на запись)?

Это кажется вполне разумным размером для размещения ряда в БД, а не файла на диске.

Что касается загрузки в память только определенного диапазона, если вы проиндексировали образцы идентификаторов, вы можете очень быстро запросить только нужное подмножество, загружая в память только этот диапазон из результата запроса БД.

person Andrew Kuklewicz    schedule 29.12.2011
comment
Извините, наверное, я вложил слишком много слов. Последнее предложение первого абзаца следует читать так: Один файл содержит 100 000 записей по 2 000 000 сэмплов в каждом. - person Eric; 30.12.2011

Я думаю, что Microsoft SQL делает то, что вам нужно, с типом поля varbinary (MAX) КОГДА, используемым в сочетании с хранилищем файлового потока.

Прочтите TechNet, чтобы получить более подробную информацию: (http: // technet .microsoft.com / en-us / library / bb933993.aspx).

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

Надеюсь, это поможет - я знаю, что это открывает в моей голове всевозможные возможности. ;-)

person frozenjim    schedule 29.12.2011