Здравствуйте, 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 добиться такой же производительности как при оптимизированной записи в файловую систему.