База данных или другой метод хранения и динамического доступа к огромным двоичным объектам
У меня есть несколько больших (200 ГБ это нормально) плоских файлов данных, которые я хотел бы сохранить в какой-то базе данных, чтобы к ней можно было быстро и интуитивно понятным образом организовать логическую организацию данных. Думайте об этом как о больших наборах очень длинных аудиозаписей, где каждая запись имеет одинаковую длину (сэмплы) и может рассматриваться как ряд. Один из этих файлов обычно содержит около 100 000 записей по 2 000 000 сэмплов каждый.
Было бы достаточно легко сохранить эти записи в виде строк данных BLOB в реляционной базе данных, но во многих случаях я хочу загружать в память только определенные столбцы всего набора данных (например, выборки 1000–2000). Какой самый эффективный способ памяти и времени?
Пожалуйста, не стесняйтесь спрашивать, если вам нужно больше разъяснений по поводу моих данных, чтобы дать рекомендации.
РЕДАКТИРОВАТЬ: Чтобы уточнить размеры данных... Один файл состоит из: 100 000 строк (записей) на 2 000 000 столбцов (образцов). Большинство реляционных баз данных, которые я исследовал, допускают максимум от нескольких сотен до пары тысяч строк в таблице. Опять же, я не очень разбираюсь в объектно-ориентированных базах данных, поэтому мне интересно, может ли что-то подобное здесь помочь. Конечно, любое хорошее решение приветствуется. Благодарю.
РЕДАКТИРОВАТЬ: Чтобы уточнить использование данных... Данные будут доступны только через пользовательское приложение для настольного компьютера / распределенного сервера, которое я напишу. Есть метаданные (дата сбора, фильтры, частота выборки, владелец и т. Д.) Для каждого "набора" данных (который я до сих пор называл файлом 200 ГБ). Есть также метаданные, связанные с каждой записью (я надеялся, что это будет строка в таблице, чтобы я мог просто добавить столбцы для каждой части метаданных записи). Все метаданные согласованы. Т.е., если для одной записи существует определенный фрагмент метаданных, он также существует для всех записей в этом файле. Сами образцы не имеют метаданных. Каждый образец представляет собой 8 битов простых двоичных данных.
4 ответа
Хранение БД не может быть идеальным для больших файлов. Да, это может быть сделано. Да, это может работать. Но как насчет резервных копий БД? Содержимое файла, вероятно, будет меняться не часто - после добавления они останутся прежними.
Моя рекомендация - хранить файл на диске, но создавать индекс на основе БД. Большинство файловых систем становятся неуклюжими или медленными, если у вас есть> 10k файлов в папке / директории /etc. Ваше приложение может сгенерировать имя файла и сохранить метаданные в БД, а затем упорядочить по сгенерированному имени на диске. Недостатки содержимого файла могут быть не очевидны из названия. Тем не менее, вы можете легко создавать резервные копии измененных файлов без специальных плагинов для резервного копирования БД и сложной системы секционирования и инкрементного резервного копирования. Кроме того, поиск в файле становится намного проще (пропустить вперед, перемотать и т. Д.). Как правило, эти операции лучше поддерживаются в файловой системе, чем в БД.
Интересно, что заставляет вас думать, что СУБД будет ограничена тысячами строк; нет никаких причин, чтобы это было так.
Кроме того, по крайней мере некоторые базы данных (например, Oracle) разрешают прямой доступ к частям данных больших объектов без загрузки полного большого объекта, если вы просто знаете смещение и длину, которые вы хотите иметь. Таким образом, вы можете иметь таблицу с некоторыми доступными для поиска метаданными, а затем столбец LOB и, если необходимо, дополнительную таблицу метаданных, содержащую метаданные в содержимом LOB, чтобы у вас было какое-то отношение "ключевое слово ->(смещение, длина)". для частичной загрузки больших объектов.
Отчасти повторяя еще один пост здесь, инкрементные резервные копии (которые вы, возможно, хотели бы иметь здесь) не совсем осуществимы с базами данных (хорошо, возможно, но, по моему опыту, как правило, к ним прикреплен неприятный ценник).
Я думаю, что Microsoft SQL делает то, что вам нужно, с типом поля varbinary(MAX), который используется в сочетании с хранилищем файлового потока.
Прочитайте TechNet для более подробной информации: (http://technet.microsoft.com/en-us/library/bb933993.aspx).
По сути, вы можете вводить любые описательные поля, как правило, в вашу базу данных, но фактический BLOB хранится в NTFS, управляется механизмом SQL и ограничивается по размеру только вашей файловой системой NTFS.
Надеюсь, что это поможет - я знаю, что это вызывает всевозможные возможности в моей голове.;-)
Насколько велик каждый сэмпл и насколько велика каждая запись? Вы хотите сказать, что каждая запись содержит 2000 000 сэмплов или каждый файл? (это можно прочитать в любом случае)
Если 2 миллиона выборок составляют 200 ГБ, то каждая выборка составляет ~10 К, а каждая запись - 200 КБ (чтобы иметь 100 000 на файл, что составляет 20 выборок на запись)?
Кажется, это очень разумный размер для размещения в строке в БД, а не в файле на диске.
Что касается загрузки в память только определенного диапазона, если вы проиндексировали примеры идентификаторов, то вы могли бы очень быстро запросить только то подмножество, которое вам нужно, загрузив только этот диапазон в память из результата запроса БД.