SolRDF (c’est-à-dire Solr + RDF) est un ensemble d’extensions de Solr pour gérer (indexer et rechercher) des données RDF. Dans un article précédent, j’ai décrit comment configurer une instance SolRDF autonome en deux minutes ; dans cet article, je vais décrire comment faire fonctionner SolRDF dans un cluster simple. Les étapes nécessaires sont similaires à celles que vous avez (espérons-le) déjà suivies pour l’instance autonome.
Ce dont vous avez besoin
- Un terminal (si vous êtes sur la face sombre de la lune, toutes les étapes peuvent être facilement effectuées dans Eclipse ou n’importe quel autre IDE)
- Java 7 ou supérieur
- Apache Maven (version 3.x)
- Apache Zookeeper (j’utilise la version 3.4.6)
- Git (facultatif, vous pouvez aussi télécharger le dépôt depuis GitHub sous forme de fichier compressé)
Étape 1 : Démarrer Zookeeper
Ouvrez un terminal et tapez la commande suivante :
> cd $ZOOKEPER_HOME/bin
> ./zkServer -start
Cela démarrera Zookeeper en arrière-plan (ou en mode premier plan avec start-foreground). Par défaut, il écoutera sur localhost:2181.
Étape #2 : Récupérer SolRDF
Si c’est la première fois que vous entendez parler de SolRDF, vous devez cloner le dépôt. Ouvrez un autre terminal et tapez la commande suivante :
> cd /tmp
> git clone https://github.com/agazzarini/SolRDF.git solrdf-download
Sinon, si vous avez déjà cloné le dépôt, vous devez récupérer la dernière version. Ou bien, si vous n’avez pas Git, vous pouvez télécharger l’ensemble du dépôt ici.
Étape 3 : Construire et exécuter les nœuds SolRDF
Pour cet exemple, nous allons configurer un cluster simple consistant en une collection avec deux shards.
> cd solrdf-download/solrdf
> mvn -DskipTests \
-Dlisten.port=$PORT \
-Dindex.data.dir=$DATA_DIR \
-DskipTests \
-Dulog.dir=ULOG_DIR \
-Dzk=ZOOKEEPER_HOST_PORT \
-Pcloud \
clean package cargo:run
Où :
- $PORT est le port d’écoute du moteur de servlet ;
- $DATA_DIR est le répertoire où Solr stockera ses fichiers de données (c’est-à-dire l’index) ;
- $ULOG_DIR est le répertoire où Solr stockera ses journaux de transactions ;
- $ZOOKEEPER_HOST_PORT est l’adresse d’écoute de Zookeeper (par exemple localhost:2181).
La première fois que vous exécutez cette commande, de nombreuses choses seront téléchargées, y compris Solr. À la fin, vous devriez voir quelque chose comme cela :
[INFO] Jetty 7.6.15.v20140411 Embedded started on port [8080]
[INFO] Press Ctrl-C to stop the container...
Le deuxième nœud peut être démarré en ouvrant un autre terminal et en réexécutant la dernière commande ci-dessus.
Étape 4 : Indexation distribuée
Ouvrez un autre terminal et tapez la commande suivante (en supposant qu’un nœud fonctionne sur localhost:8080) :
> cd solrdf-download/solrdf
> mvn -DskipTests \
-Dlisten.port=$PORT \
-Dindex.data.dir=$DATA_DIR \
-DskipTests \
-Dulog.dir=ULOG_DIR \
-Pcloud \
cargo:run
Patientez un instant… ok ! Vous venez d’ajouter 5007 triplets ! Ils ont été répartis dans le cluster : vous pouvez le vérifier en ouvrant la console d’administration Solr.
Étape 5 : Interrogation
Ouvrez un autre terminal et tapez la commande suivante :
> curl "http://127.0.0.1:8080/solr/store/sparql" \
--data-urlencode "q=SELECT * WHERE { ?s ?p ?o } LIMIT 10" \
-H "Accept: application/sparql-results+json"
...
Dans les exemples ci-dessus, j’utilise uniquement (pour l’indexation et l’interrogation) le nœud qui fonctionne sur localhost:8080, mais vous pouvez envoyer la requête à n’importe quel nœud du cluster. Par exemple, vous pouvez réexécuter la requête ci-dessus avec l’autre nœud (en supposant qu’il fonctionne sur localhost:8081)
> curl "http://127.0.0.1:8081/solr/store/sparql" \
--data-urlencode "q=SELECT * WHERE { ?s ?p ?o } LIMIT 10" \
-H "Accept: application/sparql-results+json"
...
Vous obtiendrez les mêmes résultats.
Est-ce prêt pour un scénario de production ?
Non, absolument pas. Je pense qu’il reste beaucoup à faire du côté de l’optimisation de l’indexation et des requêtes. Pour l’instant, seule la partie fonctionnelle a été couverte : la suite de tests d’intégration comprend environ 150 requêtes SPARQL (ASK, CONSTRUCT, SELECT et DESCRIBE) et des mises à jour (par exemple, INSERT, DELETE) tirées du livre LearningSPARQL [1], qui fonctionnent que le service cible soit en mode autonome ou en cluster.
Je ferai les premiers benchmarks dès que possible, mais honnêtement, je ne pense pas que je vais voir des débits élevés pour le moment.