Нужна консультация косательно сервера БД

← →
NiGGa © (2005-10-11 20:09) [0]

Доброго времени суток.
Что такое SQL и концепции построения БД я знаю довольно хорошо, на теоритическом уровне. Таблички рисовал, нормализацией занимался и советы давал, но вот самому до данного момента, на практике заниматся не приходилось. Но вот, по объективным причинам пришлось.

Это присказка. Теперь сказка. Нужны рекомендации по реализации. Есть выбор MySQL и MSSQL, что выбрать? И соответственно какими средствами лучше работать? Желательно личные соображения и послать туда где есть примеры. Т.к. чтение ТД меня очень утомляет, длительный процес знаете ли, а вот хороший пример посмотреть, это совсем другое.

И последнее. Мне нужно хранить видеоархив. Правильный ли подход хранить кадры в блобах в БД и в последствии(одна из основных функций, что должны присутствовать = это просмотр видеоархива, с разными скоростями) доставать? Потому как мне кажется, что идея хранить это на винте и через сокет-конекшн передавать клиенту,не совсем умно.

Всем заранее спасибо.

← →
Desdechado © (2005-10-11 21:18) [1]

я бы хранил видео во внешних файлах при условии, что они имеют постоянное место
а в таблицах хранил бы ссылки на эти файлы
многие SQL-сервера позволяют использовать внешние файлы в качестве файлов данных
выбор СУБД зависит от многих факторов (платность, мнокопользовательность, особенности задач, скорость и надежность работы)
требования не приведены, поэтому советовать не буду
просто обрати внимание на указанное
и еще - почему выбор между 2 противоположными по назначению СУБД? Другие варианты возможны?

← →
mango (2005-10-11 21:48) [2]

MSSQL нормально было бы.

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

либо хранить и передавать, либо не хранить.

← →
Anatoly Podgoretsky © (2005-10-11 21:55) [3]

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

← →
Карелин Артем © (2005-10-12 06:25) [4]

Если хранить покадрово, то скорее всего на клиенте будет слайдшоу и сеть будет загружена.
Может посмотреть в сторону сервера потокового видео? Он впроде как по рекламе М$ умеет пережимать данные на лету под пропускную способность сети.

← →
NiGGa © (2005-10-13 16:49) [5]

2 Desdechado
- мнокопользовательность. да, 10 и более клиентов постоянно.
- надежность. это безусловный фактор для многопользовательской системы.
- особенности задач. Около 8- клиентов с частотой 1Герц ложат в базу некую нфу и главное видеокадр, для архива который. Остальные занимаются в основном просмотром данных и опять же главное должны иметь возможность просмотра любого из видеоархивов в обычном и ускоренных режимах.

Искуственность выбора СУБД создана без меня и в принципе особо изменить я не могу, я могу лишь разрешить эту дилему в пользу мускла или МС. А какие есть хорошие алтернативы(кроме интербейза), задача в первом приближении обрисована?

2 mango
либо хранить и передавать, либо не хранить.
это есть логическая тавтология.

2 Карелин Артем
Поподробнее про этот сервер. Хорошо ли он будет уживатся с СУБД на одном хосте?

2 Anatoly Podgoretsky
Пасиба за консультацию.

← →
Курдль © (2005-10-13 17:13) [6]

> Anatoly Podgoretsky © (11.10.05 21:55) [3]
> Хранение в блобах по эффективности не отличается от обычных файлов

Хранение может и не отличается, а вот работа с ними...
Как "натравить" средство просмотра видеоролика на BLOB поле? Через OLE Container? Через потоки? Или сначала выгружать в файл?
Как поведет себя "блокировщик" MS SQL (MySQL даже не рассматривается) по отношению к сторонним пользователям той же таблицы, пока будет происходить выгрузка неслабого поля размерчиком в 700 мегов?

← →
ANB © (2005-10-13 17:46) [7]

Имхо. Придется писать сервер приложения и кэшировать в нем читаемые ролики. Тогда не будет мешать блокировка MS SQL. MySQL скорее всего такой большой объем данных не выдержит. Я бы посмотрел в сторону оракла.

← →
NiGGa © (2005-10-13 18:25) [8]

2 Курдль
А почему 700 мегов? Или по вашему хранить каждый кадр в отдельной записи не правильно, тогда почему? Также если хранить видеоархив большими кусками видео возникает вопрос эффективности, т.к. пользователь в принципе может запросить видеоархивчик с любого по любое время(любое в смысле - заданное пользователем).
И что значит натравить средство просмотра? В первых какое средство просмотра? Во вторых почему в блобе сразу же видеоролик лежит?

← →
NiGGa © (2005-10-13 18:25) [9]

Удалено модератором

← →
NiGGa © (2005-10-13 18:26) [10]

Удалено модератором

← →
Курдль © (2005-10-14 09:58) [11]

> NiGGa © (13.10.05 18:25) [8]
> А почему 700 мегов? Или по вашему хранить каждый кадр в
> отдельной записи не правильно, тогда почему?

Я не совсем понял, Вы хотите сделать собственый инструмент для просмотра, монтажа и хранения видеоальбомов? Хранить ролики покадрово в БД и надеяться, что кадры будут приходить от СУБД со скоростью ~30 к/с? И с такой же скоростью отображаться средствами Delphi?

← →
ANB © (2005-10-14 10:20) [12]

> NiGGa © (13.10.05 18:25) [8]
Кадры по отдельности ? Одуреть. Тогда готовьте сервак покруче и на скорость больше 5 кадров в секунду тут расчитывать нечего. Плюс все сжатие - коту под хвост.

← →
Курдль © (2005-10-14 10:30) [13]

> ANB © (14.10.05 10:20) [12]
> Плюс все сжатие - коту под хвост.

Я не особо интересовался системами сжатия, но сейчас есть, как я понял, 2 основные - DV и DVD. В первой, кажись, сжатие именно покадровое. А во второй - уже межкадрово корелляционное (это я только что придумал :)

← →
ANB © (2005-10-14 10:33) [14]

> Курдль © (14.10.05 10:30) [13]

Почти во всех системах видеосжатия межкадровка используется. Сжатие кадра по принципу JPEG дает слишком мало эффекта. Тогда бы фильмы на CD не влезали.

← →
Курдль © (2005-10-14 10:40) [15]

> ANB © (14.10.05 10:33) [14]
> Почти во всех системах видеосжатия межкадровка используется.
> Сжатие кадра по принципу JPEG дает слишком мало эффекта.
> Тогда бы фильмы на CD не влезали.

Вот статья, которая противоречит вышесказанному: http://www.videomax.ru/tests/dvd403/

← →
msguns © (2005-10-14 10:46) [16]

Приходится по долгу "службы" иногда общаться с областным радио. У них свой (правда звуковой), но весьма обширный проект. Все хранится в МП3 (старые записи архива с кассет оцифровываются, "эмпэшатся" и переносятся на "болванки". Есть "сервер", куда можно ставить сразу до 8 CD (8 приводов), доступный в сети.
Есть программка, которая имеет БД, где записана инфа о названии, дате, № CD и названии файла мп3. Если нажать соотв. "конпульку", то прога лезет на "сервер" и дает запрос на нужный сидюк. Висящая на "сервере" простенькая прога - "сервер" принимает запрос и "оглядывает" имеющиеся активные девайсы. Если нужного диска нет, то выдается соотв. требование для установки на один из свободных девайсов (указывается тут же) сиди с нужным номером. Девочка - оператор быстренько находит сидюк (в номере диска присутствует стеллаж, полка, ряд и №).
"Сервер" сначала копирует содержимое диска на жесткий диск (типа кэша), а потом просто возвращает "клиенту" полный путь к этому файлу.

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

← →
msguns © (2005-10-14 10:48) [17]

Пардон, вместо слова "проект" в самом первом предложении следует читать "архив"

← →
Курдль © (2005-10-14 10:52) [18]

> msguns © (14.10.05 10:46) [16]

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

← →
ANB © (2005-10-14 10:57) [19]

Мона еще много винчестеров наставить на сервак.

Если хранить кадры, а не полные ролики в блобах, то самым важным требованием к СУБД будет скорость выборки. MySQL - самый быстрый читатель, с ним только Oracle может потягаться в скорости

> Как "натравить" средство просмотра видеоролика на BLOB поле?
> Через OLE Container? Через потоки? Или сначала выгружать
> в файл?

Есть идейка пложить на форму TTimer в обработчике которого шуровать селекты по определенному временному интервалу(это в к вопросу скорости воспроизведения) и отображать карды в обычном TImage. Синхронно или асинхронно показывать с использованием буффера это уже практика покажет, экспериментировать надо

> DSKalugin © (14.10.05 14:33) [20]

Все ИМХО.
MySQL не пробовал, но оракл не вытянет такой нагрузки. Особливо в многопользовательском режиме. Надо искать способ сжатия для уменьшения трафика. А степень сжатия полного ролика выше, плюс есть куча готовых кодеков.

> экспериментировать надо

Не надо :-(
Сразу скажу - средствами Delphi, даже без обращения к БД а просто "отображать карды в обычном TImage" и получить кино НЕ ПОЛУСИТСЯ :-(

Начну отвечать с конца, уж извините.
2 Курдль
Никто не указывал на то, что компонент типа TImage присутствует.

2 ANB
Кодеков то куча, но тогда клиенты, те которых 6-, должны еще заниматся сжатием видеопотока, на самом деле у них и так задач хватает.

Многие фильмы и так на CD не влазят, я это уже давно заметил, буквально с появлением DVD.

Межкадровое сжатие используется, теми кому оно нужно. Но это не есть стандарт.

2 DSKalugin
Спасиба. Действительно никто не собирался на каждый кадр делать по запросу.

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

Также тогда конкретизируйте обратное. Если хранить видео кусками, то насколько большими и пр.

> Кто не согласен с покадровым хранением, могли бы вы кроме
> "одуреть, долбанись-перевернись, готовь ложку к кобеду"
> конкретизировать и обосновать хоть чем-то псевдо-научным
> свои убеждения.

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

Да и сетка должна быть нехилая для такой работы...

:) Класическая 100МБит - это нехилая или еще нет?

как я понял, ты делаешь систему видеонаблюдения с 8 камер с частотой записи 1 кадр/сек? если так, то:

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

если я не прав и запись 8 видео потоков в сети 100мбит будет вестись с частой 25-30fps, то легче приобрести специальное оборудование для этого

2 0bsid
Почему же, вы почти все правильно поняли. Исключение составляет тот момент, что каждая камера "присоеденена" к отдельному хосту, т.к. задача не видеонаблюдения на самом деле, но некоторыми пунктами схожа.

Впрочем некоторое решение уже найдено и по сути вопрос можно считать закрытым, всем внесшим конструктив - спасибо.

Нужна консультация косательно сервера БД Найти похожие ветки