Подходит ли реляционная база данных для мягкой системы реального времени?

Question

Я работаю над системой анализа видео в реальном времени, которая обрабатывает видеопоток кадр за кадром. В каждом кадре он может генерировать несколько событий, которые должны быть записаны, а некоторые доставлены в другую систему через сеть. Система работает в режиме реального времени, то есть задержки сообщения выше 25 мс крайне нежелательны, но не смертельны.

Подходят ли реляционные базы данных (в частности, MySQL и Postgres) в качестве хранилища данных для такой системы?

Можно ли ожидать, что БД будет хорошо работать, если она установлена ​​на своем собственном сервере и имеет ~ 50 25fps потоков однорядных вставок SQL, поступающих по сети?

РЕДАКТИРОВАТЬ: Я думаю, что в целом производительность не будет проблемой, но я беспокоюсь о дисперсии задержки. Если это будет время от времени задерживаться на 1000 мс, это было бы очень плохо.

О, и система работает круглосуточно, поэтому БД может расти как угодно большой. Это ухудшает задержку вставки?

Answer 1

Самые большие проблемы заключаются в том, насколько непредсказуемой будет латентность и как она никогда не снижается, а всегда увеличивается.Но современное оборудование на помощь, указывайте машину с достаточным количеством процессорных ядер.Вы можете рассчитывать как минимум на два, получить четыре легко.Таким образом, вы можете раскрутить поток и выделить одно ядро ​​для обновлений dbase, изолируя его от своего мягкого кода в реальном времени.Теперь вас не волнует изменчивость задержек, по крайней мере, до тех пор, пока обновления базы данных не занимают так много времени, что вы генерируете данные быстрее, чем они могут потреблять.

Установите сервер dbase и загрузите егоПолучив поддельные данные, удвойте количество, которое, как вы думаете, нужно хранить.Непрерывно тестируйте, пока вы разрабатываете, добавьте код инструмента, который вам нужен, чтобы оценить, как он работает на ранней стадии проекта.

Answer 2

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

Answer 3

Как я уже писал, если вы ставите в очередь строки, которые необходимо сохранить, и сохраняете их асинхронным способом (чтобы не останавливать «основной» поток), проблем быть не должно ... НО !!!

Вы хотите сохранить их в БД ... Так что кто-то еще будет читать строки в то же время, когда они пишутся.К сожалению, обычно довольно сложно сказать БД: «эта работа имеет очень высокий приоритет, все остальное можно остановить, но не это».Так что, если кто-то делает:

BEGIN TRANSACTION
    SELECT COUNT(*) FROM TABLE
    WAITFOR DELAY '01:00:00'

(я использую T-Sql здесь ... Но я думаю, что это вполне понятно. Попросите СЧЕТ (*) таблицы, чтобы была блокировкана столе и затем ПОДОЖДИТЕ час)

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