Захват пакета в базу данных? - PullRequest
1 голос
/ 30 мая 2009

Я новичок в работе с базами данных / ПК, прошу прощения за мое невежество.

Я хотел бы захватывать пакеты в базе данных в режиме реального времени, чтобы несколько приложений могли отслеживать физические данные ввода-вывода, возвращаемые через пакеты udp из ПЛК, и у меня возникло несколько вопросов.

В долгосрочной перспективе она должна быть кроссплатформенной, но пока я использую библиотеку захвата пакетов C # в Windows. Любые предложения по типу базы данных MySQL против SQlite?

При ~ 1500 200 байтовых пакетах в секунду возможно ли вставить пакет 1500 раз в секунду? Я читал, что у SQlite есть некоторые проблемы с конкуренцией, если у меня есть приложение, запрашивающее пакетные данные в базе данных ~ 10 раз в секунду с задержкой 25-50 мс - это выполнимо?

Я ожидаю, что «только» необходимо хранить около 20 МБ данных в БД в любой момент времени. Можно ли принудительно запустить базу данных только в памяти? При записи данных пакета можно ли записать пакет данных (байтовый массив) в одном выражении, а не вставлять каждый байт / слово итеративно? Я полагаю, я мог бы превратить это в строку, но я ожидаю, что это сделает практически невозможным запрос с любой скоростью. Я не вижу упоминаний о чем-либо вроде «типа байтового массива» ни в одной из баз данных, на которые я кратко ознакомился. FWIW Все данные поступают на выделенный сетевой адаптер по статическому IP. Пакеты являются последовательными (я знаю, что это не гарантировано с UDP, но я никогда не видел один из них не в порядке), я мог бы легко просмотреть данные, если база данных поддерживает тип массива. -Это хорошо, нет случайных поисков?

Спасибо, что нашли время, чтобы прочитать это.

Боб

Ответы [ 3 ]

2 голосов
/ 30 мая 2009

Какое предполагаемое преимущество вы ищете в реляционной базе данных для этого? Поскольку вы говорите, что не очень много разбираетесь в базах данных, вот краткое изложение обычных причин, почему SQL является опцией, возможно, она поможет вам уточнить ваши требования и ваши опции:

  1. Queryability. Если вы хотите предоставить данные для поиска rich , который включает опции для фильтрации записей, сортировки результатов, агрегирования вычислений, тогда действительно базы данных SQL предлагают такие возможности. Они не приходят бесплатно, хотя. Чтобы ускорить поиск, ядро ​​базы данных должно дублировать части данных в несколько индексов, что увеличивает время вставки / обновления, поскольку все эти индексы должны поддерживаться.
  2. восстанавливаемость. Базы данных могут гарантировать, что данные хранятся в согласованном состоянии в случае сбоя. Используя либо журнал записи с опережением, либо версионные обновления, они записывают изменения таким способом, который гарантирует клиенту, что, когда его заявление вернулось к нему, внесенные изменения были долговечными (для простоты я опускаю кучу деталей).
  3. Последовательность. Выделяя изменения между пользователями до тех пор, пока они явно не передадут группу связанных операций, база данных всегда предоставляет зрителю непротиворечивое состояние. Для этого в базе данных необходимо будет установить блокировку или управление версиями.
  4. Масштабируемость. Базы данных могут позаботиться о поддержке очень больших наборов данных, намного больше, чем жизнеспособное адресное пространство процесса. Они будут использовать буферный пул для хранения кэшированных «горячих» страниц и управления соответствующим отображением смещения файла в адрес памяти, а также всех необходимых операций ввода-вывода для чтения с диска и записи изменений. Они также будут представлять несколько файлов в качестве единой области хранения, что превосходит ограничения на размер файла ОС, если таковые имеются.
  5. Interoperability. Другие процессы могут использовать стандартные библиотеки (например, ODBC, ADO и т. Д.) И языки (SQL) для работы с данными, поэтому нет необходимости разрабатывать пользовательский API библиотеки / доступа.

Теперь, нужен ли какой-либо из них по вашему сценарию? Есть что-то еще, что я пропустил? Я задаю эти вопросы, потому что то, что вы хотите достичь, не тривиально. Вы можете добиться 1500 вставок в секунду с относительной легкостью, но гораздо сложнее сделать это, если и обеспечивают приличную производительность чтения. Также кажется, что многое из того, что предлагают реляционные базы данных (согласованность, возможность восстановления, масштабируемость), не является целью для вас. Существует целый ряд продуктов, специально настроенных для ниши в памяти, которые намного быстрее, чем те, которые вы получаете от типичной диско-ориентированной реляционной базы данных.

0 голосов
/ 30 мая 2009

libpcap, файлы круглого робота wireshark

Посмотрите вокруг, поиграйте с wireshark, посмотрите, как он достигает результатов, аналогичных вашим.

0 голосов
/ 30 мая 2009

РЕДАКТИРОВАТЬ: я забыл, что вы работаете в C #.

Прежде всего, планируете ли вы запрашивать базу данных с более чем одного компьютера? Если это так, вы хотели бы использовать MySQL. В противном случае, SQLite, вероятно, является хорошим выбором. Но обратите внимание, что MySQL, вероятно, необходим для нескольких приложений C # и базы данных в памяти. Если вы выбираете MySQL, используйте MySQL Connector / NET . Для SQLite существует System.Data.SQLite (который я использовал для приложения WinForms и могу рекомендовать).

Вы говорите, что должны делать 1500 операторов вставки 200 байтов для каждого оператора. SQLite сообщает , что он может делать 50 000 в секунду. Ключевое предостережение заключается в том, что это относится к необработанным вставкам, а не транзакциям. Фиксация транзакции замедляет работу, поскольку обычно это означает сброс на диск.

И SQLite (см. Их Базы данных в памяти ), и MySQL (см. Их MEMORY (HEAP) Storage Engine ) могут использовать базы данных в памяти. Тем не менее, для SQLite это может нанести ущерб вашей цели - предоставить «нескольким приложениям» доступ к нему. В SQLite существует недокументированный (и «не гарантированный, что он будет работать в будущих выпусках SQLite») способ, которым вы сможете совместно использовать базы данных в памяти (например, используя разделяемую память). Это обсуждалось в предыдущем вопросе SO ; см. также связанное почтовое сообщение от основного автора SQLite. Обратите внимание, что совместное использование базы данных SQLite в памяти, вероятно, будет невозможно, если вы будете придерживаться управляемого кода. Вы можете определенно иметь базу данных MySQL в памяти, совместно используемую несколькими клиентами.

Используя любой клиент C #, вы должны иметь возможность вставить весь пакет в одну строку с DbParameter (т.е. SQLiteParameter или MySqlParameter). Обратите особое внимание на свойства Value и Size.

Я не думаю, что вам нужен какой-либо "тип массива". Вы можете просто иметь увеличивающийся столбец первичного ключа (INTEGER PRIMARY KEY) и столбец содержимого пакета (BLOB или TEXT). Я не уверен, какой из BLOB или TEXT даст вам лучшую производительность для SQLite. Ваша схема SQLite может выглядеть как

CREATE TABLE packets ( id INTEGER PRIMARY KEY, packet BLOB);

Затем вы можете легко выбрать, например, пакеты в пределах определенного диапазона первичных ключей. Конечно, вы можете добавить столбец datetime, но это потребует индексации. Для MySQL это будет что-то вроде:

CREATE TABLE packets ( id INTEGER PRIMARY KEY, packet VARCHAR(200)) ENGINE=MEMORY;

Надеюсь, это поможет. Имейте в виду, что профилирование - это лучший способ убедиться, что хорошо работает для вашего приложения.

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