Reporting : Optimiser des règles IPDB

Document created by RSA Information Design and Development on Feb 6, 2017
Version 1Show Document
  • View in full screen mode
  

Cette rubrique décrit comment vous pouvez créer des définitions de règle pour améliorer la performance des rapports. Vous pouvez créer des définitions de règle pour améliorer la performance des rapports. Voici comment définir des règles pour obtenir des gains de performances :

  • Des gains de performance sont réalisés si les variables de la clause WHERE contiennent des variables d'index IPDB avec des clauses de correspondance exacte (« = », « IN »).
  • Les améliorations des performances ne sont PAS visibles lorsque les clauses de correspondance exacte telles que les opérateurs « LIKE », GREATER THAN « > » et LESS THAN « < » sont utilisés avec les variables d'index IPDB.

Les exemples de requêtes du tableau ci-dessous vous aident à comprendre l'impact de la requête sur la performance des rapports.

                                          
Numéro de requêteClause WhereGain de performance attenduRemarques
1IndexedVar1 = ‘value1’ AND
UnIndexedVar2 = ‘value2’
OuiL'index de filtre IPDB pour IndexedVar1 est vérifié afin de déterminer si « value1 » existe ou non. Si « value1 » existe, le fichier de données est lu. Autrement, il est ignoré. 
2UnIndexedVar2 = ‘value2’ AND
IndexedVar1 = ‘value1’
OuiL'index de filtre IPDB est appliqué uniquement surIndexedVar1 pour vérifier si « value1 » existe ou non. Si « value1 » existe, le fichier de données est lu. Autrement, il est ignoré.
L'ordre des variables
indexées et non indexées est sans importance.
3IndexedVar1 = ‘value1’ OR
UnIndexedVar2 = ‘value2’
NonL'index de filtre IPDB ne peut pas décider de la disponibilité des données en raison de l'opérateur « OR »
opérateur entre la variable indexée et non indexée.
4IndexedVar1 = ‘value1’ OR
IndexedVar2 = ‘value2’
OuiL'index de filtre IPDB sera appliqué aux deux
IndexedVar1 and IndexedVar2 to
Recherche respective de « value1 » et de « value2 ». Si l'une des valeurs existent, le fichier de données est lu, sinon il est ignoré.
5IndexedVar1 = ‘value1’ AND
UnIndexedVar2 LIKE ‘value%’
OuiL'index de filtre IPDB est appliqué uniquement surIndexedVar1 pour vérifier si « value1 » existe ou non. Si « value1 » existe, le fichier de données est lu. Autrement, il est ignoré.
6IndexedVar1 LIKE ‘value1%’
AND UnIndexedVar2 LIKE
‘value2%’
NonAucun index de filtre IPDB fonctionne uniquement avec les clauses de correspondance exacte.
7IndexedVar1 LIKE ‘value1%’
AND UnIndexedVar2 LIKE
‘value2%’ AND IndexedVar3 =
‘value3’
OuiL'index de filtre IPDB est appliqué uniquement surIndexedVar3 pour vérifier si « value3 » existe ou non. Si « value1 » existe, le fichier de données est lu. Autrement, il est ignoré.

Quelques exemples de définitions de règles avec des variables indexées sont fournis dans cette section.

Exemple de cas 1 : Variable indexée avec l'opérateur AND 

Voici un exemple de requête pour le cas 1 : 

            
Numéro de requêteClause WhereGain de performance attenduRemarques
1.IndexedVar1 = ‘value1’ AND

UnIndexedVar2 = ‘value2’
OuiL'index de filtre IPDB pour IndexedVar1 est vérifié afin de déterminer si value1 existe ou non. Si « value1 » existe, le fichier de données est lu. Autrement, il est ignoré. 

La requête est définie pour afficher les adresses IP de destination avec une valeur de niveau spécifique. Notez que la clause where contient la variable indexée ip.dst et le niveau de variable non indexée avec l'opérateur AND. 

BloomFilterRule1.png

Bien que les enregistrements soient en millions, le rapport est rendu rapidement avec l'aide de la variable indexée : 

BloomFilterResult1.png

Exemple de cas 5 : Variable indexée avec la fonction LIKE 

Voici un exemple de requête pour le cas 5 :

            
Numéro de requêteClause WhereGain de performance attenduRemarques
5.IndexedVar1 = ‘value1’ AND
UnIndexedVar2 LIKE ‘value%’
OuiL'index de filtre IPDB est appliqué uniquement à
IndexedVar1 pour vérifier si « value1 »
existe ou non. Si « value1 » existe, le fichier de données est lu. Autrement, il est ignoré.

 Voici un exemple de requête pour afficher les adresses IP source pour un utilisateur spécifique. Notez que la clause where contient la variable indexée ip.src et la variable non indexée user.dst avec l'option LIKE tel que mentionné dans le cas 5 du tableau. 

BloomFilterRule7.png

Exemple de cas 3 : Variable indexée avec l'opérateur OR 

Voici un exemple de requête pour le cas 3 : 

            
Numéro de requêteClause WhereGain de performance attenduRemarques
3.<IndexedVar1 = ‘value1’ OR
UnIndexedVar2 = ‘value2’
NonL'index de filtre IPDB ne peut pas décider de la
disponibilité des données en raison de l'opérateur « OR »
entre la variable indexée et
la variable non indexée.

La requête ci-dessous est définie pour afficher les adresses IP de destination avec une valeur de niveau spécifique. Notez que la clause where contient la variable indexée ip.dst et le niveau de variable non indexée avec l'opérateur OR. Il n'y aura pas de gain de performances avec la requête ci-dessous. 

BloomFilterRule3.png

Previous Topic:Tester une règle
You are here
Table of Contents > Utilisation des règles de Reporting > Définir des groupes de règles et des règles > Optimiser des règles IPDB

Attachments

    Outcomes