Видеонаблюдение перестало быть нишевой задачей охранных служб. Президентские выборы 4 марта вывели тему на новый масштаб: десятки тысяч камер на участках за один день сгенерировали петабайты записей, и эти данные нужно хранить, искать и выдавать по запросу. Мы прошли этот путь на проекте видеонаблюдения за выборами и формулируем здесь практические выводы по архитектуре видеоархива.

Главная ошибка – считать видеоархив обычным файловым хранилищем. Это поток, который пишется непрерывно, растёт линейно и почти никогда не удаляется до истечения регламентного срока. Проектировать его нужно от объёма и от сценария доступа, а не от привычной СУБД.

Считайте объём до закупки железа

Одна камера 720p в H.264 при умеренном битрейте 2 Мбит/с пишет около 21 ГБ в сутки. Тысяча камер – это 21 ТБ ежедневно и порядка 7,5 ПБ в год при круглосуточной записи. Цифры пугают, но они предсказуемы, и в этом сила: ёмкость планируется арифметически.

Сократить объём помогают три рычага. Первый – кодек: H.264 даёт двукратную экономию против MPEG-4 Part 2 при том же качестве. Второй – запись по движению вместо непрерывной там, где это допустимо регламентом. Третий – снижение частоты кадров в архивной копии: 25 fps нужны оператору в реальном времени, для последующего разбора инцидента хватает 6–8 fps. Эти приёмы мы закладывали ещё при проектировании потоковой трансляции видео, где экономия канала и хранилища решала исход проекта.

Многоуровневое хранение и сроки

Не держите весь архив на быстрых дисках. Разделите данные по «температуре». Горячий слой – последние сутки-двое на SAS- или SSD-массиве для оперативного просмотра. Тёплый слой – недели и месяцы на ёмких SATA-дисках. Холодный слой – длительное хранение по требованиям регулятора, где приемлемы ленточные библиотеки LTO с низкой стоимостью терабайта.

Сроки задаёт не ИТ, а закон и отраслевой регламент. Для объектов транспортной безопасности и ряда госзадач счёт идёт на месяцы, иногда на год. Архитектуру нужно проектировать под максимальный срок, а не под средний, иначе через полгода эксплуатации хранилище переполнится в самый неподходящий момент.

Индексация: архив без поиска бесполезен

Петабайт записей ничего не стоит, если оператор не может за минуту найти нужный фрагмент. Поэтому видео – это только половина системы. Вторая половина – метаданные: камера, время, событие детектора движения, метка оператора. Их место в индексируемой базе, по которой строится выборка, а само видео лежит в объектном хранилище по ссылке.

Здесь подключается аналитика. Журнал доступа, статистика по нагрузке камер, отчёты по инцидентам, выгрузки по запросу контролирующих органов – всё это живёт в отдельном хранилище данных с BI-отчётностью, а не на видеосервере. Разделение ответственности между потоковым слоем и аналитическим слоем делает систему управляемой. Кстати, рост числа мобильных клиентов-просмотрщиков – после выхода Android 4.0 Ice Cream Sandwich мы видим спрос на доступ к архиву с планшетов – тоже ложится на этот слой через API, а не на сам видеохранилище.

Вывод

Видеоархив – это инженерная задача по управлению большими данными, а не покупка дисков. Считайте объём заранее, разносите данные по уровням хранения, выносите метаданные в индексируемый слой и стройте сроки от регламента. Тогда петабайты остаются ресурсом, а не проблемой.