Capture de paquet vers la base de données?

Question

Je suis un débutant complet dans la base de données/application de PC s'il vous plaît pardonnez mon ignorance. Je souhaite capturer des paquets dans une base de données en temps réel afin que plusieurs applications aient la possibilité de surveiller les données d'E/S physiques renvoyées via des paquets udp d'un automate et j'ai quelques questions à poser.

À long terme, il faudra que ce soit multi-plateforme, mais pour le moment j'utilise une bibliothèque de capture de paquets C# sous Windows. Des suggestions sur le type de base de données MySQL vs SQlite? À ~ 1500 paquets de 200 octets par seconde, est-il faisable d'insérer un paquet 1500 fois par seconde? J'ai lu que SQlite a quelques problèmes avec la concurence, si j'ai une application qui interroge les paquets de données dans la base de données ~ 10 fois par seconde sur un délai de 25-50 ms -est-ce faisable?

Je pense que "seulement" besoin de stocker 20 Mo ou plus de données dans le DB à un moment donné. La base de données peut-elle être forcée à fonctionner en mémoire seulement? Lors de l'écriture des données par paquets, le paquet de données (tableau d'octets) peut-il être écrit dans une instruction plutôt que d'insérer itérativement chaque octet/mot? Je suppose que je pourrais le transformer en une chaîne mais je pense que cela rendrait presque impossible d'interroger avec n'importe quelle vitesse. Je ne vois aucune mention de quelque chose comme un "type tableau d'octets" dans l'une des bases de données que j'ai brièvement examinées. FWIW Toutes les données arrivent à une carte réseau dédiée sur une adresse IP statique. Les paquets sont séquentiels (je sais que ce n'est pas garanti avec UDP mais je n'en ai jamais vu en panne). Je pouvais facilement parcourir les données si la base de données supportait un type de tableau. -C'est bien, pas de recherches aléatoires?

Merci d'avoir pris le temps de lire ceci.

Bob

Answer 1

EDIT: J'ai oublié que vous travaillez en C#.

Tout d'abord, prévoyez-vous d'interroger la base de données à partir de plusieurs ordinateurs? Si oui, vous voudriez utiliser MySQL. Sinon, SQLite est probablement un bon choix. Mais notez que MySQL est probablement nécessaire pour plusieurs applications C# et une base de données en mémoire. Si vous choisissez MySQL, utilisez MySQL Connector/NET. Pour SQLite, il y a System.Data.SQLite (que j'ai utilisé pour une application WinForms et que je peux recommander).

Vous dites que vous devez effectuer 1500 instructions d'insertion de 200 octets chaque instruction. SQLite reports qu'il peut faire 50 000 par seconde. La principale mise en garde est que cela fait référence aux insertions brutes, pas aux transactions. Commettre une transaction vous ralentit, car cela signifie généralement le vidage sur le disque.

Les deux SQLite (voir leur In-Memory Databases) et MySQL (voir leur MEMORY (HEAP) Storage Engine) peuvent utiliser des bases de données en mémoire. Cependant, pour SQLite, cela peut aller à l'encontre de votre objectif de permettre à plusieurs applications d'y accéder. Avec SQLite, il existe un document non documenté (et "pas garanti pour les versions futures de SQLite"), vous permettant de partager des bases de données en mémoire (par exemple, en utilisant la mémoire partagée). Il a été discuté dans un prior SO question; voir aussi le linked mail message de l'auteur principal de SQLite. Notez que le partage d'une base de données en mémoire SQLite ne sera probablement pas possible si vous vous en tenez au code managé. Vous pouvez certainement avoir une base de données MySQL en mémoire partagée entre plusieurs clients. En utilisant un client C#, vous devriez être capable d'insérer un paquet entier sur une seule ligne avec un DbParameter (par exemple SQLiteParameter ou MySqlParameter). Notez les propriétés Value et Size en particulier.

Je ne pense pas que vous ayez besoin de "type de tableau". Vous pouvez simplement avoir une colonne de clé primaire incrémentée (INTEGER PRIMARY KEY) et une colonne de contenu de paquet (BLOB ou TEXT).Je ne suis pas sûr que BLOB ou TEXT vous donnera les meilleures performances pour SQLite. Votre schéma SQLite pourrait ressembler à

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

Ensuite, vous pouvez facilement sélectionner par ex. paquets dans une certaine plage de clés primaires. Bien sûr, vous pouvez ajouter une colonne datetime, mais cela nécessitera une indexation. Pour MySQL, ce serait quelque chose comme:

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

J'espère que cela aide. Gardez à l'esprit que le profilage est la meilleure façon d'être sûr de ce qui fonctionne bien pour votre application.

Answer 2

Quel est l'avantage perçu que vous recherchez dans une base de données relationnelle pour cela? Puisque vous dites que vous n'êtes pas beaucoup dans les bases de données, voici un bref exemple de raisons pour lesquelles SQL est une option, peut-être cela vous aide à clarifier vos besoins et vos options:

1. Queryability. Si vous souhaitez exposer les données pour une recherche riche qui inclut des options pour filtrer les enregistrements, trier les résultats, agréger les calculs alors en effet les bases de données SQL offrent de telles fonctionnalités. Ils ne viennent pas gratuitement cependant. Pour accélérer les recherches, un moteur de base de données doit dupliquer des parties des données dans plusieurs index, ce qui ajoute aux temps d'insertion/de mise à jour car tous ces index doivent être conservés.
2. Récupérabilité. Les bases de données peuvent garantir que les données sont conservées dans un état cohérent en cas de panne. En utilisant le journal d'écriture anticipée ou les mises à jour versionnées, ils écrivent les changements d'une manière qui garantit au client que lorsque sa déclaration lui est retournée, les changements effectués sont durables (j'omets un tas de détails pour plus de simplicité).
3. Cohérence. En isolant les changements entre les utilisateurs jusqu'à ce qu'ils commettent explicitement un groupe d'opérations connexes, la base de données expose toujours un état cohérent à un visualiseur. Pour ce faire, une base de données devra déployer soit le verrouillage, soit le versioning.
4. Évolutivité. Les bases de données peuvent prendre soin de maintenir de très grands ensembles de données, beaucoup plus gros qu'un espace d'adressage viable. Ils utiliseront un pool de mémoire tampon pour conserver les pages actives en mémoire cache et gérer le mappage d'adresse de fichier-décalage-en-mémoire sous-jacent ainsi que toutes les E/S nécessaires pour lire et modifier les modifications. Ils présenteront également plusieurs fichiers en tant qu'un espace de stockage uni, dépassant ainsi les limites de taille de fichier OS, le cas échéant.
5. Interopérabilité. D'autres processus peuvent utiliser des bibliothèques standard (ODBC, ADO, etc.) et des langages (SQL) pour fonctionner sur les données, il n'est donc pas nécessaire de développer une bibliothèque personnalisée/API d'accès.

Maintenant, l'un de ces éléments est-il requis par votre scénario? Y a-t-il autre chose que j'ai omis? Je pose ces questions parce que ce que vous voulez accomplir n'est pas trivial. Vous pouvez atteindre 1500 insertions par seconde avec une relative facilité, mais il est beaucoup plus difficile de le faire que et offrent des performances de lecture décent. En outre, il semble que la plupart des bases de données relationnelles (cohérence, recouvrabilité, évolutivité) ne constituent pas un objectif pour vous. Il existe un certain nombre de produits spécifiquement adaptés à la niche en mémoire qui sont beaucoup plus rapides que ce que vous obtiendriez d'une base de données relationnelle orientée disque typique.

Answer 3

libpcap, Wireshark fichiers round robin

Regardez autour, jouer avec Wireshark, regardez comment il obtient des résultats semblables à la vôtre.