Есть у меня задачка по обработке и зранению аудио/видео. Если с обработкой ещё более-менее понятно, то вот с хранением пока неразбериха, в основном из-за того, что помимо простого видео-файла есть ещё онлайн-потоки видео и аудио. Так как БД транзакционны (может есть и другие), то это накладывает ограничение, что данные не могут идти бесконечно. Набор данных, т.е. транзакция. В моём же случае поток как раз бесконечен (в идеале ).
И вопросы:
Есть ли какие-то решения по хранению real-time потоков данных в БД?
Какую БД можно использовать для такой работы?
Может быть вообще не использовать БД, а просто юзать файловую систему? У кого-то есть опыт разработки таких решений?
Пока есть только одна идея — написать утилиту, которая будет собирать поток в буфер и периодически сбрасывать в БД.
30.11.09 13:02: Перенесено модератором из 'Java' — Blazkowicz
Здравствуйте, Polosatiy, Вы писали:
P>Может быть вообще не использовать БД, а просто юзать файловую систему? У кого-то есть опыт разработки таких решений?
А какие тут вообще бенефиты от использования БД? Файловая система однозначно. Постоянное чтение больших объемов данных из БД уложит не только сам сервер БД, но и канал между базой и приложением. Так что всем остальным запросам придется ждать достаточно долго.
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, Polosatiy, Вы писали:
P>>Может быть вообще не использовать БД, а просто юзать файловую систему? У кого-то есть опыт разработки таких решений? B>А какие тут вообще бенефиты от использования БД? Файловая система однозначно. Постоянное чтение больших объемов данных из БД уложит не только сам сервер БД, но и канал между базой и приложением. Так что всем остальным запросам придется ждать достаточно долго.
Бенефиты от того, что в БД потоки можно параметризовать ещё куче параметров + репликация + нет кучи файлов вокруг. А как решается вопрос записи и чтения онлайн видео при использовании файловой системы? Вомможно ли сразу и писать в файл и читать из него on the fly?
Здравствуйте, Polosatiy, Вы писали:
P>Бенефиты от того, что в БД потоки можно параметризовать ещё куче параметров + репликация + нет кучи файлов вокруг.
Про параметризацию я не понял. Мы наверное говорим о какой-то конкретной БД? Репликация реализуется каким либо доступным решением.
P>А как решается вопрос записи и чтения онлайн видео при использовании файловой системы? Вомможно ли сразу и писать в файл и читать из него on the fly?
А зачем читать из файла в который ещё пишутся данные?
> Бенефиты от того, что в БД потоки можно параметризовать ещё куче > параметров + репликация + нет кучи файлов вокруг. А как решается вопрос > записи и чтения онлайн видео при использовании файловой системы? > Вомможно ли сразу и писать в файл и читать из него on the fly?
1. Ссылку на файл можно держать в базе. Рядом можно сделать поле "файл
записан полностью".
2. Можно руками реализовать механизм shared/exclusive locks. Это не
очень сложно.
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, Polosatiy, Вы писали:
P>>Бенефиты от того, что в БД потоки можно параметризовать ещё куче параметров + репликация + нет кучи файлов вокруг. B>Про параметризацию я не понял. Мы наверное говорим о какой-то конкретной БД? Репликация реализуется каким либо доступным решением.
Нет. О любой БД. Ну например нуджны данные кто записал, откуда, когда и т.п. Репликация поддерживается многими БД. На файлах репликацию можно через RAID настроить, как вариант.
P>>А как решается вопрос записи и чтения онлайн видео при использовании файловой системы? Вомможно ли сразу и писать в файл и читать из него on the fly? B>А зачем читать из файла в который ещё пишутся данные?
Ну например есть плеер, который показывает видео с видеокамеры. В real-time режиме плеер работает напрямую с потоком без каких-либо файлов. Этот же поток пишется параллельно в архив. Но вдруг пользователю понадобилось промотать назад на 5 минут и посмотреть. Тут уже надо из архива, в который пишется поток, достать нужные данные и отдать на проигрывание. Т.е. получается и чтение и запись одновременно.
B>Я перенесу тему в соответствующий форум?
Да. Я просто не знал куда поместить, но так как меня это интересует в контексте Java, то сюда и поместил
>> Бенефиты от того, что в БД потоки можно параметризовать ещё куче >> параметров + репликация + нет кучи файлов вокруг. А как решается вопрос >> записи и чтения онлайн видео при использовании файловой системы? >> Вомможно ли сразу и писать в файл и читать из него on the fly?
_>1. Ссылку на файл можно держать в базе. Рядом можно сделать поле "файл _>записан полностью".
Дык у него нет статуса "записан полностью". Он пишется постоянно.
_>2. Можно руками реализовать механизм shared/exclusive locks. Это не _>очень сложно.
Спасибо. Посмотрю.
_>3. Ну, если, действительно репликация, может JCR?
JCR, как я понял, решает задачу только по добавленю метаданных к объектам.
Здравствуйте, Polosatiy, Вы писали:
P>Нет. О любой БД. Ну например нуджны данные кто записал, откуда, когда и т.п.
Метаданные, конечно же, в RDB.
P>Ну например есть плеер, который показывает видео с видеокамеры. В real-time режиме плеер работает напрямую с потоком без каких-либо файлов. Этот же поток пишется параллельно в архив. Но вдруг пользователю понадобилось промотать назад на 5 минут и посмотреть. Тут уже надо из архива, в который пишется поток, достать нужные данные и отдать на проигрывание. Т.е. получается и чтение и запись одновременно.
Так это уже бизнес требование, для которого нужно продумать решение. Достаточно разделить чтение и запись. А читаемые данные переодически обновлять... Вообще пока даже не ясно то ли у системы тасячи пользователей, которые постоянно получают контент, то ли десяток избранных, которым нужны наиболее актуальные данные с камер.
B>>Я перенесу тему в соответствующий форум? P>Да. Я просто не знал куда поместить, но так как меня это интересует в контексте Java, то сюда и поместил
Если в обсуждаемом вопросе заменить Java на PHP, то ничего особо не изменися.
B>Здравствуйте, Polosatiy, Вы писали:
P>>Ну например есть плеер, который показывает видео с видеокамеры. В real-time режиме плеер работает напрямую с потоком без каких-либо файлов. Этот же поток пишется параллельно в архив. Но вдруг пользователю понадобилось промотать назад на 5 минут и посмотреть. Тут уже надо из архива, в который пишется поток, достать нужные данные и отдать на проигрывание. Т.е. получается и чтение и запись одновременно.
Неправда ваша, сдвижка времени -- проблема плеера, а не сервера...
Кроме того, обычно, запись настраивается не сквозняком а по так называемым Alarm'ам как-то: срабатывание датчика движения, считывание карты доступа итп...
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, Polosatiy, Вы писали:
P>>Нет. О любой БД. Ну например нуджны данные кто записал, откуда, когда и т.п. B>Метаданные, конечно же, в RDB.
P>>Ну например есть плеер, который показывает видео с видеокамеры. В real-time режиме плеер работает напрямую с потоком без каких-либо файлов. Этот же поток пишется параллельно в архив. Но вдруг пользователю понадобилось промотать назад на 5 минут и посмотреть. Тут уже надо из архива, в который пишется поток, достать нужные данные и отдать на проигрывание. Т.е. получается и чтение и запись одновременно. B>Так это уже бизнес требование, для которого нужно продумать решение. Достаточно разделить чтение и запись. А читаемые данные переодически обновлять... Вообще пока даже не ясно то ли у системы тасячи пользователей, которые постоянно получают контент, то ли десяток избранных, которым нужны наиболее актуальные данные с камер.
Пользователей, которым нужны актуальные данные может быть порядка 50. Не думаю что больше чем 100 когда-либо будет. Давайте резберем простой пример. Есть файл, в который пишется бесконечный поток. Понадобилось прочитать какую-то часть данных из файла. Не произойдёт ли в этот момент блокировка файла на чтение? Или как разделить чтение и запись? Писать сразу в 2 файла и когда надо что-то прочитать, то прекращать запись в один файл и открывать его на чтение?
B>>>Я перенесу тему в соответствующий форум? P>>Да. Я просто не знал куда поместить, но так как меня это интересует в контексте Java, то сюда и поместил B>Если в обсуждаемом вопросе заменить Java на PHP, то ничего особо не изменися.
Здравствуйте, srggal, Вы писали:
B>>Здравствуйте, Polosatiy, Вы писали:
P>>>Ну например есть плеер, который показывает видео с видеокамеры. В real-time режиме плеер работает напрямую с потоком без каких-либо файлов. Этот же поток пишется параллельно в архив. Но вдруг пользователю понадобилось промотать назад на 5 минут и посмотреть. Тут уже надо из архива, в который пишется поток, достать нужные данные и отдать на проигрывание. Т.е. получается и чтение и запись одновременно. S>Неправда ваша, сдвижка времени -- проблема плеера, а не сервера...
Про сдвижку времени не понял.
S>Кроме того, обычно, запись настраивается не сквозняком а по так называемым Alarm'ам как-то: срабатывание датчика движения, считывание карты доступа итп...
Здравствуйте, Polosatiy, Вы писали:
P>Пользователей, которым нужны актуальные данные может быть порядка 50. Не думаю что больше чем 100 когда-либо будет. Давайте резберем простой пример. Есть файл, в который пишется бесконечный поток. Понадобилось прочитать какую-то часть данных из файла. Не произойдёт ли в этот момент блокировка файла на чтение? Или как разделить чтение и запись? Писать сразу в 2 файла и когда надо что-то прочитать, то прекращать запись в один файл и открывать его на чтение?
Вы принципиально не рассматриваете буферизацию текущих видеоданных в памяти?
Здравствуйте, Polosatiy, Вы писали:
P>Пользователей, которым нужны актуальные данные может быть порядка 50. Не думаю что больше чем 100 когда-либо будет. Давайте резберем простой пример. Есть файл, в который пишется бесконечный поток. Понадобилось прочитать какую-то часть данных из файла. Не произойдёт ли в этот момент блокировка файла на чтение? Или как разделить чтение и запись? Писать сразу в 2 файла и когда надо что-то прочитать, то прекращать запись в один файл и открывать его на чтение?
Данные пишутся в один файл. Содержимое этого файла переодически реплицируется в файлы для чтения. Если предполагается что большенство пользователей будут получать именно оперативные данные, то их вообще лучше всего держать в памяти, чтобы уменьшить задержки из-за обновления файлов чтения.
Здравствуйте, srggal, Вы писали:
S>Здравствуйте, Polosatiy, Вы писали:
P>>Пользователей, которым нужны актуальные данные может быть порядка 50. Не думаю что больше чем 100 когда-либо будет. Давайте резберем простой пример. Есть файл, в который пишется бесконечный поток. Понадобилось прочитать какую-то часть данных из файла. Не произойдёт ли в этот момент блокировка файла на чтение? Или как разделить чтение и запись? Писать сразу в 2 файла и когда надо что-то прочитать, то прекращать запись в один файл и открывать его на чтение?
S>Вы принципиально не рассматриваете буферизацию текущих видеоданных в памяти?
Рассматриваю, но не хранить же в памяти весь поток? А сколько хранить не понятно, так как пользователь может захотеть посмотреть хоть с начала всё. Я в самом первом посте писал, что пока есть только одна идея: хранить текущий поток в памяти и по достижении определенного условия (размер, время и т.п.), сохранять его в файл или БД при этом сам поток сбрасывать, высвобождая память. Таким образом можно разделить чтение и запись. Вот спросил, может у есть ещё варианты или вообще есть что-то готовое.
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, Polosatiy, Вы писали:
P>>Пользователей, которым нужны актуальные данные может быть порядка 50. Не думаю что больше чем 100 когда-либо будет. Давайте резберем простой пример. Есть файл, в который пишется бесконечный поток. Понадобилось прочитать какую-то часть данных из файла. Не произойдёт ли в этот момент блокировка файла на чтение? Или как разделить чтение и запись? Писать сразу в 2 файла и когда надо что-то прочитать, то прекращать запись в один файл и открывать его на чтение?
B>Данные пишутся в один файл. Содержимое этого файла переодически реплицируется в файлы для чтения. Если предполагается что большенство пользователей будут получать именно оперативные данные, то их вообще лучше всего держать в памяти, чтобы уменьшить задержки из-за обновления файлов чтения.
Оперативные данные, т.е. те, что онлайн, вообще с файлами не работают, а работают через real-time протоколы. Например RTSP. А каким образом реплицировать файл, открытый на постоянную запись?
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, Polosatiy, Вы писали:
P>>Пользователей, которым нужны актуальные данные может быть порядка 50. Не думаю что больше чем 100 когда-либо будет. Давайте резберем простой пример. Есть файл, в который пишется бесконечный поток. Понадобилось прочитать какую-то часть данных из файла. Не произойдёт ли в этот момент блокировка файла на чтение? Или как разделить чтение и запись? Писать сразу в 2 файла и когда надо что-то прочитать, то прекращать запись в один файл и открывать его на чтение?
B>Данные пишутся в один файл. Содержимое этого файла переодически реплицируется в файлы для чтения. Если предполагается что большенство пользователей будут получать именно оперативные данные, то их вообще лучше всего держать в памяти, чтобы уменьшить задержки из-за обновления файлов чтения.
На самом деле все ещё интересней, если упростить:
Вводим понятие фрейма. Фрейм содержит точно n-секунд видео всегда занимающее m-байт... (если nсекунд видео не всегда равно m, то всё чуть сложней, нужен индекс файла)...
Данные обрабатываются фреймами: кэшируются, флушатся, отправляются на плеер...
Файл открыт на добавление и чтение...
Пдеер знает кол-во фреймов (окно) которое флушится за раз, и держит несколько окон, если перемотка не попадает в это окно, то фреймовая математика нам поможет..
Я думаю тебе нужно посмотреть на http://www.ccnx.org/content/welcome
Сам я эту штуку не использовал но судя по архитектуре системы что-то лучше чем CCN для подобных задач придумать весьма не просто.
Ты с ходу получишь архивирование, реплицирование, кеширование, балансировку нагрузки, трансляцию множеству клиентов броадкастом и/или через промежуточные кеширующие серверы(те нагрузка на основной сервер будет смешной),...
Я сам занимался подобной задачей некоторое время назад. Жаль я тогда про CCN не знал.
Если придется делать подобное еще раз то я начну с серьезного тестирования CCN'а.
Начать можно отсюда http://www.ccnx.org/pipermail/ccnx-users/2009-October/thread.html смотри письма с заголовком VLC Plug-in там обсуждают почти твою задачу.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, srggal, Вы писали:
S>Здравствуйте, Blazkowicz, Вы писали:
B>>Здравствуйте, Polosatiy, Вы писали:
P>>>Пользователей, которым нужны актуальные данные может быть порядка 50. Не думаю что больше чем 100 когда-либо будет. Давайте резберем простой пример. Есть файл, в который пишется бесконечный поток. Понадобилось прочитать какую-то часть данных из файла. Не произойдёт ли в этот момент блокировка файла на чтение? Или как разделить чтение и запись? Писать сразу в 2 файла и когда надо что-то прочитать, то прекращать запись в один файл и открывать его на чтение?
B>>Данные пишутся в один файл. Содержимое этого файла переодически реплицируется в файлы для чтения. Если предполагается что большенство пользователей будут получать именно оперативные данные, то их вообще лучше всего держать в памяти, чтобы уменьшить задержки из-за обновления файлов чтения. S>На самом деле все ещё интересней, если упростить:
S>Вводим понятие фрейма. Фрейм содержит точно n-секунд видео всегда занимающее m-байт... (если nсекунд видео не всегда равно m, то всё чуть сложней, нужен индекс файла)...
Тут всё зависит от формата видео, механизмов сжатия и т.п. Так что будет как раз сложней. Плюс в этом случае понятие фрейма должно настраиваться.
S>Данные обрабатываются фреймами: кэшируются, флушатся, отправляются на плеер...
S>Файл открыт на добавление и чтение... S>Пдеер знает кол-во фреймов (окно) которое флушится за раз, и держит несколько окон, если перемотка не попадает в это окно, то фреймовая математика нам поможет..
S>Где-то так..
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Polosatiy, Вы писали:
WH>Я думаю тебе нужно посмотреть на http://www.ccnx.org/content/welcome WH>Сам я эту штуку не использовал но судя по архитектуре системы что-то лучше чем CCN для подобных задач придумать весьма не просто. WH>Ты с ходу получишь архивирование, реплицирование, кеширование, балансировку нагрузки, трансляцию множеству клиентов броадкастом и/или через промежуточные кеширующие серверы(те нагрузка на основной сервер будет смешной),... WH>Я сам занимался подобной задачей некоторое время назад. Жаль я тогда про CCN не знал. WH>Если придется делать подобное еще раз то я начну с серьезного тестирования CCN'а. WH>Начать можно отсюда http://www.ccnx.org/pipermail/ccnx-users/2009-October/thread.html смотри письма с заголовком VLC Plug-in там обсуждают почти твою задачу.
Спасибо. Буду смотреть. Пока не понял как это работает Чё-то с доками и описанием фич у них проблемы...
Здравствуйте, Polosatiy, Вы писали:
P>Спасибо. Буду смотреть. Пока не понял как это работает Чё-то с доками и описанием фич у них проблемы...
Думаю первые 2 pdf'ника прольют свет на то что это такое http://www.ccnx.org/content/content-centric-networking-resources
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Polosatiy, Вы писали:
P>>Спасибо. Буду смотреть. Пока не понял как это работает Чё-то с доками и описанием фич у них проблемы... WH>Думаю первые 2 pdf'ника прольют свет на то что это такое WH>http://www.ccnx.org/content/content-centric-networking-resources
Да. Я уже в презентацию вникаю Идея в общем понятная. Можно что угодно с чем угодно связать и при этом не испоьлзуя IP адреса и т.п.
Здравствуйте, Polosatiy, Вы писали:
P>Да. Я уже в презентацию вникаю Идея в общем понятная. Можно что угодно с чем угодно связать и при этом не испоьлзуя IP адреса и т.п.
Идея понята не правильно.
Система не занимается связью чего угодно с чем попало. Этим занимается сеть на основе IP.
CCN вообще не волнуют конкретные машины. Вся работа построена вокруг контента. Именно это и обеспечивает дикую масштабируемость и отказоустойчивость системы в целом.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
). 
