Mondeca

Making Sense of Content

Requêtes SPARQL avec Neptune

Dans le premier post nous avons vu comment configurer et charger des données RDF avec Amazon Neptune. Dans ce post, nous allons faire des tests d’exécution des requêtes SPARQL et mesurer les temps de réponse moyens. Les données sont basées sur le modèle FRBR ( un modèle conceptuel de données bibliographiques élaboré par un groupe d’experts de l’IFLA)  avec une ontologie propre nommée CDM.

Pour notre benchmark, nous allons utiliser un outil de benchmark assez facile à configurer, SPARQL Query Benchmarker . Evidemment, il existe d’autres outils plus sophistiqués comme celui-ci. Le but du jeu est de voir dans notre scenario si le moteur AWS Neptune tend plus vers une Lamborghini ou plutôt vers une R4. 🙂

SPARQL est le langage de requêtes des bases RDF, dont la spécification est faite par le W3C.

Requêtes SPARQL

Grâce à la générosité de l’Office de Publications, nous avons eu accès à des requêtes SPARQL utilisées en production. Ainsi, nous avons pu distinguer deux classes en fonction de leurs complexitiés. Evidemment, cette complexité implique différents délais de réponse attendus du moteur SPARQL. Ces classes de requêtes sont les suivantes:

  • Requêtes instantanées: Ce sont des requêtes qui permettent par exemple de construire de manière dynamique des pages HTML, comme celle-ci. Elles doivent donc avoir des temps de réponses de moins de 60 secondes. Un exemple est cette requête (Listing 1)  pour retrouver les titres et les résumés en francais du document avec identifiant celex 52011DC0666. Pour notre test, nous avons 20 requêtes dans cette classe.

Listing 1 – Exemple de requête instantanée

prefix cdm: <http://publications.europa.eu/ontology/cdm#>
prefix owl: <http://www.w3.org/2002/07/owl#>
prefix xsd: <http://www.w3.org/2001/XMLSchema#>
SELECT DISTINCT ?summary ?title WHERE { ?sum owl:sameAs ?summary. FILTER (REGEX(?summary, '/resource/uriserv/')).
OPTIONAL {?sum ^cdm:expression_belongs_to_work ?e. ?e cdm:expression_uses_language <http://publications.europa.eu/resource/authority/language/FRA>; cdm:expression_title ?title.}
{ SELECT DISTINCT ?sum WHERE { ?s cdm:resource_legal_id_celex "52011DC0666"^^xsd:string; ^cdm:summary_summarizes_work ?sum. }} }

Requêtes analytiques: Ce sont des requêtes permettant de faire des validations et des contrôles sur les méta données. Elles sont complexes et demandent par conséquent beaucoup plus de temps. Ainsi, le temps de réponse limite est de 600 secondes, soit 10 minutes. Un exemple de requête dans cette catégorie est: “Donner le nombre des auteurs des ressources juridiques créees en 2016” (Voir Listing 2). Pour notre test, nous avons 24 requêtes de cette classe.

Listing 2 – Exemple de requête analytique

prefix cdm:
SELECT (COUNT(*) AS ?count) where{
select distinct ?lr ?author
where {
?lr cdm:work_created_by_agent ?author.
?lr cdm:work_date_creation_legacy ?dat_cre.
?lr a cdm:resource_legal .
FILTER (!regex(str(?dat_cre), "^2016-"))
}
}

Configuration du Benchmark

Il est possible de configurer le bench en fonction de plusieurs paramètres, comme celles consistant à mettre le serveur dans les conditions de PROD (warm-up), du nombre de fois que l’on souhaite répéter une requête pour prendre la moyenne du temps de réponse, sans oublier de bien fixer le temps de réponse (time out).  Nous avons donc choisi pour chaque classe de requête la configuration suivante: Un warm-up de 20 fois le nombre de requête par catégorie, et on lancera 5 fois chaque requête pour prendre la moyenne des résultats.

Pour ce test, nous avons configuré un warm-up de 20 fois le nombre de requête par catégorie, et on lancera 5 fois après le “chauffage du serveur” chaque requête pour prendre la moyenne des résultats.

Résultats

Nous avons donc pu obtenir des résultats en fonction de notre configuration du benchmark.

    1. Temps moyen pour les requêtes instantanées: Nous remarquons (cf. tableau ci-dessous) que 9 requêtes ont un temps supérieur à la limite demandée (60s). Il s’agit des requêtes avec identifiants Q5-Q10, Q12, Q14 et Q17. Ce qui donne juste 45% de réussite avec Neptune, si celle-ci se mésure par le nombre de requête avec temps inférieur à 60s.
      Requête Temps (seconde)
      Q1 0,042s
      Q2 0,052s
      Q3 0,085s
      Q4 0,121s
      Q5 >60s
      Q6 >60s
      Q7 >60s
      Q8 >60s
      Q9 >60s
      Q10 >60s
      Q11 0,119s
      Q12 >60s
      Q13 0,086s
      Q14 >60s
      Q15 0,08s
      Q16 0,094s
      Q17 >60s
      Q18 0,205s
      Q19 0,138s
      Q20 0,087s
    2. Temps moyen pour les requêtes analytiques. Ici, on a des bien bonnes nouvelles, comme l’indique le tableau ci-dessous. Nous avons un taux de 100% de réussite (pas de réponse supérieure à 600s).
      Requête Temps (seconde)
      Q1 15,94s
      Q2 36,12s
      Q3 56,62s
      Q4 1,08s
      Q5 63,71s
      Q6 1,12s
      Q7 0,04s
      Q8 0,84s
      Q9 0,06s
      Q10 25,80s
      Q11 0,97s
      Q12 28,16s
      Q13 0,24s
      Q14 120,36s
      Q15 14,01s
      Q16 5,24s
      Q17 2,63s
      Q18 12,89s
      Q19 5,23s
      Q20 2,60s
      Q21 17,78s
      Q22 5,36s
      Q23 2,77s
      Q24 3,04s
  1. Les tests peuvent continuer pour savoir par exemple les temps de réponses en cas de simulations de plusieurs requêtes en parallèle pour voir la robustesse de la base. Nous laisserons ce test pour les plus curieux 🙂

    AWS Neptune, tel que vu dans notre scénario n’est pas encore une Lamborghini mais en tout cas, n’est pas non plus une R4. Avec un bien mauvais taux de réussite pour les requêtes instantanées, Neptune a repris un sérieux avantage pour les requêtes analytiques. Nous espérons que le moteur est en cours de perfectionnement ou encore que des bonnes pratiques vont sortir pour aider à mieux adapter les requêtes SPARQL au moteur Neptune.

    Ghislain A.

Prise en main de AWS Neptune

Amazon nous a annoncé  le 29 novembre 2017 son propre outil de gestion de graphes de données sur le cloud avec pour nom Amazon Neptune. C’est presque la nouvelle technologique de fin d’année 2017 pour tous ceux qui travaillent dans les bases graphes. MONDECA a donc décidé de se faire une idée sur le nouveau venu dans les bases RDF, après une bonne expérience sur les bases RDF populaires existantes utilisées dans les applications industrielles comme Neo4j, GraphDB, Virtuoso, Marklogic, Oracle 12c et Blazegraph. Des rumeurs aujourd’hui presque certaines, affirment qu’Amazon  a racheté la société Systap et a donc embarqué les créateurs de la base Blazegraph pour AWS Neptune.

Amazon Neptune est la révélation technologique de la fin d’année 2017 dans le domaine des bases graphes. Son arrivée dans ce domaine va certainement contribuer à résoudre les problèmes de stabilité, de robustesse, de passage à l’échelle et de fiabilité des bases graphes dans les applications industrielles.

MONDECA a donc eu un accès pour tester la version AWS Neptune Preview afin de tester la configuration et le chargement de données RDF dans Neptune. MONDECA a rempli un formulaire pour participer à la campagne de test auprès d’Amazon et a eu un accès quelques jours après pour participer au test de la version AWS de Neptune Preview. La première chose a été d’identifier une base graphe significative pour nos tests. Notre choix s’est immédiatement porté sur des données RDF de l’Office de Publications (OP) car nous avions travaillé avec eux sur un projet de benchmark des bases graphes.

Dans la section suivante, nous décrivons les grandes étapes de configuration d’un cluster Neptune, avant de montrer comment nous avons pu charger 727 millions de triplets RDF. La Figure 1 donne une idée des étapes à suivre en terme de configuration dans AWS pour atteindre “notre planète Neptune” 🙂

Figure 1: Etapes de configuration pour une instance AWS Neptune

Configurations AWS

Nous listons ici les grandes étapes de configurations sachant que AWS donne des détails pour chacune des phases.

  1. Configurer un VPC: Pour cela suivre les étapes ici. Comme Mondeca avait déjà un VPC par défaut, dans ce test nous n’avons pas eu à en créer un supplémentaire.
  2. Configurer une instance EC2: La création de l’instance EC2 est importante car c’est via cette dernière que vous pouvez lancer des scripts de chargement de la base et accéder au SPARQL endpoint. Pour Neptune Preview, on ne peut (pour l’instant) que créer une instance de type t2.micro (https://aws.amazon.com/fr/ec2/instance-types/) . Deux informations sont utiles dans cette étape: une clé privée .pem pour se connecter à l’instance, ainsi que un DNS publique. La Figure 2 donne un exemple d’informations pour un DNS. 

    Figure 2: Une instance AWS EC2 pour Neptune

  3. Configurer un compartiment (Bucket) AWS S3: Il permet de charger les données depuis sa machine vers AWS Amazon. Ce bucket doit avoir une stratégie dans laquelle on délègue le droit au RDS de faire les appels aux services. Dans notre cas précis, le but est de permettre le chargement des données depuis AWS S3 vers la base Neptune
  4. Associer un rôle IAM pour AWS S3: C’est un container permettant de créer une stratégie qui permettra ensuite de pouvoir charger les données se trouvant dans le bucket vers Neptune.
  5. Créer une instance DB Neptune: Le but est de créer une instance Neptune dans le même VPC que celui contenant le Bucket des données (east-1), avec des règles d’accès à l’instance, le port TCP 8182 du endpoint, si chiffrement ou pas, délai de sauvegarde automatique, etc. Pour l’instant, Amazon propose 2 classes instances DB, qui correspondent à des ressources matériels differentes (plus de détails ici):
    • db.r4.8xlarge – 32 vCPU, 244 GB RAM
    • db.r4.4xlarge – 16 vCPU, 122 GB RAM.  

Test de chargement graphe RDF

La Figure 3 donne une vision des étapes de test de chargement des données RDF vers Neptune en passant par le bucket S3. La méthode la plus simple est de passer par une connexion ssh sur la machine EC2 configurée et après lancer le script de chargement. Pour notre exemple, nous avons une base Neptune de typedb.r4.4xlarge (16 vCPU, 122 Go RAM). Pour cela, nous vons conseillons d’installer AWS CLI en fonction de votre système d’exploitation. Nous supposons par la suite que AWS CLI est installé sur votre OS. 

AWS CLI est votre outil permettant en ligne de commande de donner de charger vos données depuis un poste à Paris vers des instances AWS Neptune

Figure 3: Etapes de chargement de RDF dans Neptune

Les lignes suivantes sont des extraits de chargement des données sur le Bucket et ensuite du lancement du Loader ou tout autre script de benchmark.

# configure EC2 instance
aws configure
# list of buckets
aws s3 ls

# copy files/repo into a bucket
# syntaxe: aws s3 cp s3:///path --recursive

aws s3 cp /Volumes/My\ Passport/opoceData/pz_normalized_full/*.nq s3://mdk-neptune/opoceProd/ --recursive
# sync local content to bucket destination
# syntaxe: aws s3 sync s3://bucket/path

aws s3 sync /Volumes/My\ Passport/opoceData/pz_normalized_full/ s3://mdk-neptune/opoceProd/

# ssh in EC2 instance
# exemple: ssh -i /path/my-key-pair.pem ec2-user@ec2-54-167-168-79.compute-1.amazonaws.com
ssh -i /Users/gatemezing/Documents/aws/gatemezing-ec2-keys.pem ec2-user@ec2-54-167-168-79.compute-1.amazonaws.com

# scp vers EC2 instance
# scp -i /path/my-key-pair.pem /path/SampleFile.txt ec2-user@ec2-198-51-100-1.compute-1.amazonaws.com:~

scp -i /Users/gatemezing/Documents/aws/gatemezing-ec2-keys.pem loadNeptune.sh ec2-user@ec2-54-167-168-79.compute-1.amazonaws.com:~

 

Le fichier source de loadNeptune.sh se trouve ici. La figure 4 donne la sortie du chargement en cours depuis l’instance EC2 via l’api HTTP du loader qui prend en paramètre l’identifiant de la transaction.

Figure 4: Vue du chargement en cours vers Neptune

Si tout se passe bien (pas d’erreurs de chargement), on arrive à un temps de chargement de 11560s (3h 12m 40s). Ce temps est légèrement plus rapide qu’avec le triple store Virtuoso, mais dans une machine aux configurations différentes (12c, 128Go RAM, disque SATA). La sortie suivante est le résultat final à la fin du chargement

{
"status" : "200 OK",
"payload" : {
"feedCount" : [
{
"LOAD_COMPLETED" : 2195
}
],
"overallStatus" : {
"fullUri" : "s3://mdk-neptune/opoceProd",
"runNumber" : 1,
"retryNumber" : 0,
"status" : "LOAD_COMPLETED",
"totalTimeSpent" : 11560,
"totalRecords" : 727959570,
"totalDuplicates" : 516592,
"parsingErrors" : 0,
"datatypeMismatchErrors" : 0,
"insertErrors" : 0
}
}

Maintenant que nous avons les données sur Neptune, nous allons initier quelques tests de requêtes (benchmark) dont nous disposons, venant de l’Office de Publication pour savoir si Neptune va confirmer cette première bonne impression dans le temps de chargement.

AWS Neptune avec ce résultat partiel nous donne une bonne impression, sachant que ce sont des tests plus approfondis en fonction des cas d’usage qui conforteront les choix en PROD par les potentiels éditeurs de données. Cependant, il faudra bien tenir compte des limites actuelles de Neptune, comme par exemple le manque de raisonneur embarqué.

Ghislain A.

1 Comment

Submit a Comment

Your email address will not be published. Required fields are marked *

Contact