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

Question

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

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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

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

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