Здравствуйте, MOG2, Вы писали:
MOG>-возможно ли при первом способе добиться производительности первого, ну хотя бы 80%. Если да то за счет чего? И какую БД выбрать.
MOG>-возможно ли при втором способе добиться удобства как в первом. Скорость разработки, тоже важна.
MOG>Для меня ответ очевиден, но может чего не знаю. И еще нужна аргументация, что бы убедить коллег.
Это плохая идея пихать терабайты данных в БД. Если очень хочется, то можно заюзать filestream в sql servere, что в какой-то степени позволит объединить оба подхода.
Здравствуйте, MOG2, Вы писали:
MOG>есть два варианта:
MOG>1. пишем каждый поток в SQLite или какую-то другую SQL БД, отдельные фреймы (кадры) храним в сжатом виде (H.264, JPG) в BLOB-ах. Размер фреймов всегда разный от 20 до 200 кБ.
Не понял, как именно пишем? 1 фрейм = 1 строка в таблице?
MOG>2. В SQL храним только линки на данные и описатели этих данных, причем постоянной длинны. А сами потоки данных храним в файловой системе. Причем пишем так что бы исключить фрагментации ФС. (для этого пишем в файлы равного размера, при создании и удалении файлов доступ к диску монопольный). SQL индекс хранится на системном диске, а файловый архив на отдельном (возможно рэйд).
А это еще зачем?
MOG>Для меня ответ очевиден, но может чего не знаю. И еще нужна аргументация, что бы убедить коллег.
А для меня нет. Поделись своим видением.
Для меня все зависит от сценариев доступа, их частоты и необходимой производительности. Ты их пока не описал.
Ну и общая рекомендация — изучить существующие аналоги. Чужой опыт точно не помешает.
Делаем часть системы безопасности. Видео архив. Необходимо писать\читать видео в\из архив. Всего N потоков на запись и N на одновременное чтение. N = 10-20.
Архив циклический, т.е. с возможностью перезаписи старых данных новыми. Длинна цикла одного потока несколько ТБ или несколько дней. Желательно что бы доступ к файлам был с минимальной задержкой.
есть два варианта:
1. пишем каждый поток в SQLite или какую-то другую SQL БД, отдельные фреймы (кадры) храним в сжатом виде (H.264, JPG) в BLOB-ах. Размер фреймов всегда разный от 20 до 200 кБ.
2. В SQL храним только линки на данные и описатели этих данных, причем постоянной длинны. А сами потоки данных храним в файловой системе. Причем пишем так что бы исключить фрагментации ФС. (для этого пишем в файлы равного размера, при создании и удалении файлов доступ к диску монопольный). SQL индекс хранится на системном диске, а файловый архив на отдельном (возможно рэйд).
Вообщем вопроса два:
-возможно ли при первом способе добиться производительности первого, ну хотя бы 80%. Если да то за счет чего? И какую БД выбрать.
-возможно ли при втором способе добиться удобства как в первом. Скорость разработки, тоже важна.
Для меня ответ очевиден, но может чего не знаю. И еще нужна аргументация, что бы убедить коллег.
Здравствуйте, wildwind, Вы писали:
W>Здравствуйте, MOG2, Вы писали:
MOG>>есть два варианта:
MOG>>1. пишем каждый поток в SQLite или какую-то другую SQL БД, отдельные фреймы (кадры) храним в сжатом виде (H.264, JPG) в BLOB-ах. Размер фреймов всегда разный от 20 до 200 кБ.
W>Не понял, как именно пишем? 1 фрейм = 1 строка в таблице?
да 1 фрейм 1 строка. для h.264 это 1 nal unit. от 20-200 кБ.
MOG>>2. В SQL храним только линки на данные и описатели этих данных, причем постоянной длинны. А сами потоки данных храним в файловой системе. Причем пишем так что бы исключить фрагментации ФС. (для этого пишем в файлы равного размера, при создании и удалении файлов доступ к диску монопольный). SQL индекс хранится на системном диске, а файловый архив на отдельном (возможно рэйд).
W>А это еще зачем?
Просто есть мнение что при циклической записи (перезапись старых данных, новыми, причем размер данных все время разный) в базу данных, одновременно более десяти медиа потоков данных с общим битрейтом 50-400 мегабит в секунду и одновременно читать из нескольких клиентов с таким же суммарным битрейтом, то она, база, будет а) сильно фрагментироваться, б) тормозить, в) распухать (вакум на ней будет делать не просто, т.к. работать она должна 24х7 кроме, а объем одного потока может быть до 1 ТБ). г). кроме самой базы будет еще и фрагментироваться файловая система. само по себе фрагментирование и как следствие общее падение производительности системы, уже неприятно, но еще хуже что при этом эта производительность не постоянная, а ухудшается со временем, т.е. один раз настроить и использовать длительное время не удастся, т.к. со временем скорость чтения\записи начнет падать.
Вот собственно для устранения этих проблем и предлагается сами стримы с постоянной скоростью писать в файлы, а в базе хранить индекс, структуру и описание этих файлов. Т.е. как бы удобство доступа, поиска данных получаем использованием SQL, а производительность как при записи в файл.
MOG>>Для меня ответ очевиден, но может чего не знаю. И еще нужна аргументация, что бы убедить коллег.
W>А для меня нет. Поделись своим видением. W>Для меня все зависит от сценариев доступа, их частоты и необходимой производительности. Ты их пока не описал.
см. выше.
W>Ну и общая рекомендация — изучить существующие аналоги. Чужой опыт точно не помешает.
подскажите куда капать? я видел две системы в которых данные писались в БД. Одна юзала MS SQL, не знаю может как то не правильно реализовали, но все работало крайне плохо, вторая была сделана на Oracle, более удачная, но там большой производительности и не требовалось.
Я по этому и спрашиваю. Потому что не знаю как используя SQLite добиться такой же производительности как при оптимизированной записи в файловую систему.
Здравствуйте, MOG2, Вы писали:
MOG>Я по этому и спрашиваю. Потому что не знаю как используя SQLite добиться такой же производительности как при оптимизированной записи в файловую систему.
1. Скорее всего никак.
2. Некоторые СУБД могут хранить данные на RAW разделе — у вас отпадают проблемы с фрагментацией ФС.
Но я бы писал в бд только описание конкретного файла с видео.
Здравствуйте, BlackEric, Вы писали:
BE>Здравствуйте, MOG2, Вы писали:
MOG>>Я по этому и спрашиваю. Потому что не знаю как используя SQLite добиться такой же производительности как при оптимизированной записи в файловую систему.
BE>1. Скорее всего никак. BE>2. Некоторые СУБД могут хранить данные на RAW разделе — у вас отпадают проблемы с фрагментацией ФС.
Вот это интересно. Какие СУБД позволяют решить проблему с фрагментацией ФС?
BE>Но я бы писал в бд только описание конкретного файла с видео.
Да я тоже так думаю, но мне нужны железобетонные аргументы что бы убедить коллег.
Сейчас они пытаются в SQLite параллельно заливать десятки потоков по 3-6 мегабита/сек каждый. собственно это решение было принято для того что бы не писать свою систему управления архивом. что в принципе понятно. СУБД уже умеет делать все что нужно для хранения и поиска. Но вот производительность и следовательно надежность сильно хромает.
Мой вариант был как раз использовать систему управления на основе СУБД, а потоки заливать в файл. не могу убедить. Не хватает аргументов.
Здравствуйте, MOG2, Вы писали:
MOG>Здравствуйте, BlackEric, Вы писали:
BE>>Здравствуйте, MOG2, Вы писали:
MOG>>>Я по этому и спрашиваю. Потому что не знаю как используя SQLite добиться такой же производительности как при оптимизированной записи в файловую систему.
BE>>1. Скорее всего никак. BE>>2. Некоторые СУБД могут хранить данные на RAW разделе — у вас отпадают проблемы с фрагментацией ФС.
MOG>Вот это интересно. Какие СУБД позволяют решить проблему с фрагментацией ФС?
Здравствуйте, MOG2, Вы писали:
MOG>Вот это интересно. Какие СУБД позволяют решить проблему с фрагментацией ФС?
Oracle позволяет (и реально пишет!) писать в RAW разделы. В общем, ему вообещ поыиг, в какую ФС писать данные.
MOG>Мой вариант был как раз использовать систему управления на основе СУБД, а потоки заливать в файл. не могу убедить. Не хватает аргументов.
В общем, более правильно. ИМХО, конечно. Тем более, что то же Oracle вполне себе позволяет писать в БД данные типа BFILE. Другой вопрос — синхронизация данных в разрезе ФС — БД. Но это уже есть предмет более другого обсуждения...
Здравствуйте, LuciferArh, Вы писали:
LA>Здравствуйте, MOG2, Вы писали:
MOG>>Вот это интересно. Какие СУБД позволяют решить проблему с фрагментацией ФС?
LA>Oracle позволяет (и реально пишет!) писать в RAW разделы. В общем, ему вообещ поыиг, в какую ФС писать данные.
MOG>>Мой вариант был как раз использовать систему управления на основе СУБД, а потоки заливать в файл. не могу убедить. Не хватает аргументов. LA>В общем, более правильно. ИМХО, конечно. Тем более, что то же Oracle вполне себе позволяет писать в БД данные типа BFILE. Другой вопрос — синхронизация данных в разрезе ФС — БД. Но это уже есть предмет более другого обсуждения...
Какие могут быть проблемы в этом подходе? С чем бороться?
