Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
Pages : 1
#1 Re : Optimisation » [Table Enormes] Demande de renseignements / 'Best practices' » 04/10/2011 12:41:09
Pardon de sonner un peu 'mieleux/démago', mais je voudrais vous remercier pour votre rapidité, professionalisme et votre courtoisie (se faire 'vouvoyer' sur un forum, cela commençait à me manquer sérieusement...)
Je vous réponds un peu en vrac:
- l'idée est donc vraiment d'aboutir, soit à des rapports générés spontanément (daily, weekly,..) en PDFs (donc la vitesse n'importe peu), soit via l'interface Web, relativement sobre, mais si possible des plus fluides, utilisant des technologies assez récente HTML/5, CSS/3 et JQuery pour faire des graphes vraiment interactifs (zoom, drill-down,....)
Les drill-down/zooms doivent justement permettre de gagner en granularité: on ne voit pas les points plus gros en zoomant, mais on en voit plus (= une autre définition), je trouve que c'est particulièrement là que le bas blesse.
- Je ne connaissais pas EdenWall/immun, très intéressant mais nous nous situons plutôt dans une démarche de monitoring/perf. que de sécurité ici.
- Oui, bien sûr, le lien entre les tables se fait par UNION et non pas des JOIN, pardonnez cet égaremment 
- Merci de m'avoir éclairé sur le double tranchant des trigger-procedures: en effet, on a des heures pour faire rentrer tous les fichiers SQL et des minutes pour afficher des graphes...c'est pas vivable. Cela dit, les données en production arriveraient au fur et à mesure dans la DB, donc l'entrée pourrait être lente, ce n'est pas très grave. Mais la lecture des données (agrégées ou pas) doit Être vraiment immédiate.
- L'existant: nous avons un PostgreSQL configuré à la Warrior, avec des stored procedure et 25 tables de 100KB à 1MB, sauf une (les paquets) qui fait + d'une 20aine de GB (réparti 50-50% entre la Table Size et l'indexes Size), avec seulement 6 champs pourtant.
Les requêtes SQL sont actuellement faites maison avec PHP, une vilaine couche d'HTML et le tout servi en graphiques SVG (à abandonner au plus vite)
CREATE TABLE packets
(
pkid bigserial NOT NULL,
flid smallint,
pktime timestamp without time zone,
pksig bytea,
pksize smallint,
pkflag character(1),
CONSTRAINT packets_pkey PRIMARY KEY (pkid),
CONSTRAINT packets_flid_fkey FOREIGN KEY (flid)
REFERENCES flows (flid) MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE CASCADE,
CONSTRAINT packets_flid_key UNIQUE (flid, pktime, pksig)
)
#2 Optimisation » [Table Enormes] Demande de renseignements / 'Best practices' » 04/10/2011 10:15:05
- blietaer
- Réponses : 9
Bonjour,
Je m’attelle tout doucement à un projet de monitoring réseau.
En très bref: il s'agit de sniffer des paquets à différents endroits et de les stocker, consolider, agréger et présenter.
Cette dernière présentation se fait de manière passive (dashboard), interactive (graphes clickables/zoomables) et automatisée (rapport PDFs émis daily, weelky, nightly,..)
Cela fait bcp de données (=paquets IP), mais pas très lourdes (on ne garde qu'une signature du header+timestamp+endroit où il a été vu)
Je commence par me demander la validité de 'LAMP' ici, (ou plutôt 'LAPP', puisque PostgreSQL est présenti ici plutôt que MySQL)
L'idée est qu'un utilisateur qui se connecte à l'interface arrive d'abord sur une page de type 'dashboard' avec un apperçu de l'état du réseau (latence, capacité, volume,..) assez générique, après, on peut imaginer des onglets avec des graphes plus interactif qui permettent de remonter dans le temps, zoomer, drill-down,...
La couche d'accès à la DB se ferait par quelque chose de propre, genre un beau Framework PHP/MVC, avec un DBAL/ORM (genre Doctrine2)
Le nerf de la guerre: les I/O et la fluidité de l'interface en général.
Les questions pour lesquelles je serais ravis de partager vos expériences/conseils/remarques:
I. La structure de la DB:
a.) Le choix de PostgreSQL jsutement: est-ce que les outils libres SQL sont valables?
On dit souvent que des recherches sont plus rapides sur des flat-files, la complexité ici est de permettre une dimension en plus: l’agrégation des données (stored/trigger procedure?) Nos tables sont clairement relativement maigres (une 20aine de champs) mais kilométrique (imaginons que l'on garde les données des paquets jusqu'il y a un mois!)
b.) L’agrégation justement: bien que je ne l'ai jamais fait, il semble que l'on peut rendre une DB 'vivante' avec des triggers et des nested routines, qui spontanément vont faire du 'house-keeping' des données, soit directement à l'insert, soit plus tard, selon une date/durée d'expiration.
Est-ce intéressant? efficace? Mieux vaut tout laisser en granularité maximale et laisser la partie 'query & display' faire les arrangements?
Est-ce franchement abérant de vouloir tout mettre dans une table? mieux vaut passer à une table par jour et possibilité de 'LEFT JOIN' si jamais on fait des recherches sur une nuit qui couvre 2 tables?
II. Le support HW:
c.) Bien que l'idée soit de partir d'un serveur "moyen" ici sous la main (raid-SAS, 10aine de Go RAM, 4/8 cores), je me demande s'il y a moyen de gagner en I/O autrement.
J'ai découvert (ici même) qu'il y avait moyen de balancer toute la DB en RAM au boot. Malin? Bricolage? limitation?
Est-il possible de ne mettre en RAM unquement qu'une partie (table des données du jour, par ex.) ?
Y a-t-il des nouvelles révolutions en la matière? (les fameux clouds? le faite de taper 2 de nos serveurs ensemble, en //?)
III. L'extraction des données:
d.) Ecrire sa propre petite librairie PHP pour faire des requêtes SQL semble un sport spécifique et pourtant rendu très automatique par les ORM/DBAL en PHP: je me dis que cette communautée a certainement plus d'expérience que moi (même si je fait du PHP/SQL depuis +/-8ans) et que leur requêtes générées seront plus optimisées. Mais tiendront-elles compte de la taille de mes tables?
Est-ce vraiment la panacée dans mon cas?
Merci beaucoup pour vos éclaircissements.
Bien à vous,
Bli
Pages : 1