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.