Исходные данные
на входе льется:
- поток из видеокамер, аудио и других подобных источников данных, которые по большому счету можно представить как "большие медиа файлы внутри которых СУБД копаться не должно".суммарная скорость порядка 60..80 мегабайт в секунду;
- поток мета информации к указанному выше, и прочие данные, допустим измерения с приборов. скорость до 3 мБ/сек.

все это должно связываться с некими "фактами" (мгновенные либо растянутые во времени события).
суммарный объем хранилища - до 200 терабайт.

на выходе - из клиентского ПО, необходима возможность подгрузить данные либо по "факту", либо за интервал времени.

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


одновременное количество:
- источников данных - до 40
- клиентов отображения/редактирования - до 5

сеть закрытая, среда скорей всего линукс.

варианты которые видятся:
- СУБД + блоб;
- СУБД + файловое хранилище.

лично по мне, писать столько в блоб - извращенство, и, учитывая отсутствия дикой конкурентности, жестких требований к безопасности, сложных моделей данных, сложных запросов - вполне справится Postgre (хранение фактов, связей с файлами) или даже MySQL, + размазанная по нескольким серверам NFS (или ftp или samba) для хранения файлов.
но в коллективе есть мнение, что оракл - "наше все" и ещё не такое переварит.

допускаю что могу всего не знать, и интересует сообщества на тему вариантов:
- Oracle + blob
- Oracle + NFS (samba, ftp)
- Postgre + NFS (samba, ftp)
- MySQL+ NFS (samba, ftp)
- какие-то еще варианты?
в разрезе критериев целесообразности, надежности и требовательности к железу.

очепятка
интересует мнение сообщества на тему...

чаша весов в сторону файлов фактически окончательно перевесила )))
отдельного oracle dba - нет.

хранение видимо будет на нескольких сетевых хранилищах, терабайт по 20..50.
и наверно получится размазать по ним нагрузку, например от каждого типа источника писать в физически отдельное хранилище.
с чтением проблем не много... клиент указывает временной интервал, например "сутки", и может покурить с минутку, пока подгрузится гигабайта 2, далее работать с локальными копиями. либо асинхронно тянуть нужные блоки.
5 пользователей не будут постоянно жарить хранилище запросами.

GlusterFS - по описаниям очень заманчиво, но в статье вот пишут что производительность заметно падает, по сравнению с обычным IO ( http://habrahabr.ru/post/216461/ )
да и клиент может быть на win, а с этим у GlusterFS только через самбу.

GridFS, Nginx - как я понимаю заточка на "много пользователей на чтение". есть сомнения что это актуально в моей задаче.

получается... у сетевых хранилищ стоит либо винда Storage Server, либо unix подобное, то есть либо шара на NetBIOS, либо NFS or samba, от туда же и клиенты читают.
и без блобов, остальные задачи будут пустяковыми для любой СУБД

так?

какую нагрузку на запись обеспечивают сетевые хранилища, например это dell-powervault-nx3000.html ?
если только запись?
если запись/чтение - 60/40?
только чтение?
хотя бы примерно

Basil A. Sidorov "Dell+PowerVault+NX3000"+IOPS ?
ох как не любит производитель такие характеристики выкладывать
удалось найти под одним из хранилищ цифру в 15К IOPS.
но, как я понимаю, без точного знания размера блоков и latency, точность расчетов будет примерно как "на глаз"

мдя... акцент вопроса сместился в сторону от "выбора СУБД" к подбору дискового хранилища способного гарантированно переварить 80мб/сек
+ подбор методики как это можно посчитать зная характеристики дисков и сетевых интерфейсов