Прошу не пинать, может коту то на этом форуме ответ покажется очевидным. Я не специалист в данной области, потому хочется получить краткий лаконичный ответ.
Задача.
В центе геофизики ААНИИ
geophys.aari.ru
создается база данных по определенным видам наблюдений. В результате одного из методов наблюдений образуются достаточно большие файлы данных (порядка 5Мб каждый) . Частота формирования файлов такова, что в год получается порядка нескольких десятков Тб данных.
Файл состоит из заголовка, в котором имеется структура описания режимов наблюдений и, собственно, массив данных.
Нам необходимо индексировать эти результаты наблюдений.

Пока проблема решена следующим образом:
Создана SQL таблица в которой индексируются заголовки файлов. Файлы переписываются в хранилище, поле чего в таблицу добавляется путь к конкретному файлу. В данном случае имеется хорошая защита от полной потери набора данных. В случае повреждения таблицы ее легко восстановить заново проиндексировав файлы данных.
Проблема в том, что сложно формировать запрос к данным. По сути мы можем сделать выборку только по заголовку, а потом скачать файлы с сервера по их путям используя какой-либо транспортный протокол.

Вопрос:
Может будет правильнее переписать данные из каждого файла с отльную таблицу (со временим, правда, таблиц накопится многие тысячи) и сделать связи между основной заголовочной таблицей и таблицами набора данных? Тогда доступ к данным будет только посредством SQL запроса. Но возникает вопрос: справиться ли с такой организацией таблиц сама БД?
Т.е. вопрос сводится к следующему: как правильно хранить большие однотипные массивы данных?
Что в этом случае рекомендуете почитать?Заранее благодарю за грамотные ответы.

Спасибо за ответ!
С железом проблем нет. В этом году обзавелись профессиональными DELL-овскими хранилищами.
Пока в режиме тестирования используем MySQL. Понятно, что его надо менять на что-нить приличное, поэтому приобретение Оракла в плане стоит.
В принципе индексируемый заголовок имеет простую структуру, пример:
1. дата время
2. координаты места наблюдений
3. идентификатор вида наблюдений
4. некоторые параметры, заданные измерительной аппаратурой

Далее массив однотипных данных.

Структура такой базы представляется достаточно простой. Стоит ли в этом случае привлекать специалистов?

Dimitry SibiryakovtooonСтруктура такой базы представляется достаточно простой. Стоит ли в этом случае привлекать
специалистов?

Стоит. Потому что ваши "простые представления" откуда-то высосали, что "со временем таблиц
накопится многие тысячи"...

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

Спасибо, все ваши вопросы позволяют мне все больше понять как правильно сформулировать задание на создание данной БД.

Можно провести практически 100 процентный аналог нашей задаче:
По сути мы имеем множество wav файлов с фонограммами. В них есть заголовок (автор, исполнитель, год выпуска, муз направление) и потоковые данные.
Нам надо создать подобие фонотеки, которая будет сортироваться запросами по заголовочным параметрам. Очевидно, что мами потоковые данные в отдельных файлах связи никакой не имеют.
На обработку самих потоковых данных сформировать ТЗ практически не возможно, т.к. это задача дальнейших научных исследований. В любом случае элементы потоков не будут ка-либо сопоставляться, будут сопоставляться результаты их обработки.
Например, возвращаясь к примеру с фонотекой, кому-то будет интересно проследить как меняется звуковой спектр фонограмм в течении длительного времени. Например выявить тенденцию увеличения низкочастотных составляющих спектра и т.п.

MasterZivOn 12/17/2011 03:32 PM, sp wrote:

> Посмотрите в сторону SQL 2008-12 - там появилось удобное обращение с файлами в
> базе - они как-бы и файлы (лежат как файлы), но они какбы и элементы базы -
> честно зарегистренные объекты базы - filestream


Зачем ? Если им надо обрабатывать эти данные в БД, то их надо будет
структурировать (в виде таблиц). Если нет -- их нет смысла тянуть в БД.

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

Руководствуясь ответами и повтыкав в инете рассматриваю наиболее оптимальным использование BLOB объектов, которые хранятся в файловой системе, как реализовано в MSSQL:

> В SQL Server большие двоичные объекты (BLOB) могут представлять собой данные стандартного типа varbinary(max), данные которых > хранятся в таблице, либо объекты FILESTREAM типа varbinary(max), данные которых хранятся в файловой системе.

Правда есть одна проблема - у нас сервак-линуксоид.
Посмотрел реализацию БЛОБов на MySQL, там вроде реализован только первый тип записей БЛОБов, т.е. табличный. (Может я плохо смотрел).
Какая СУБД под линукс умеет делать то же самое, что и MS SQL - т.е. организовывать файловое хранилище данных?

to Злой Бобр
Собственно у нас уже реализован первый вариант, но не понятно можно получать информацию из файлов на основе sql запросов или нет? Не хочется сначала получать ссылку на файл по sql, а потом скачивать его по ftp, например. В этом случае форма запроса усложняется и теряет свою универсальность. Вот если бы можно было получить данные только посредством sql, как это реализовано в БЛОБах.