MarkLogic, base de données nouvelle génération

MarkLogic, qu’est-ce que c’est ?

MarkLogic est une solution de type base de données transactionnelle (ACID), mais il serait réducteur de parler de base de données. Il s’agit d’un outil tout-en-un permettant une grande flexibilité sur la manipulation de la donnée (intégration, stockage, transformation, visualisation).

Cet outil intègre notamment :

  • Une base de données documents (JSON/XML) hautement sécurisée, pouvant stocker également du binaire
  • Une base de données graphe (triplestore RDF)
  • Un moteur de recherche intégré
  • Un serveur d’application exposant une API REST native, et offrant la possibilité d’exposer sa propre API fonctionnelle

En plus de proposer une approche disruptive autour de la donnée, MarkLogic permet d’adresser de gros volumes.

En effet, la technologie est scalable horizontalement autour de clusters pouvant inclure des centaines de nœuds, et manipuler des pétaoctets de données et des milliards de documents, tout en traitant plusieurs milliers de transactions par seconde.

Enfin, il est important de signaler que MarkLogic ne propose pas d’IHM – il s’agit d’un outil middle-end / back-end orienté services.

Les IHM doivent être créées indépendamment en spécifique.

MarkLogic, pour quels usages ?

Vous l’avez compris, MarkLogic ne répond pas à un besoin spécifique, mais permet de traiter de nombreux cas d’utilisation.

Voici les plus fréquents :

  • Master Data Management
  • Gestion Electronique des Documents
  • Vision 360°
  • Data Hub
  • Lutte contre la fraude
  • Conformité RGPD
  • Recherche de type Google

MarkLogic, comment ça fonctionne ?

Un projet MarkLogic se déroule généralement sous forme de cycles découpés en quatre étapes :

  • Ingestion
  • Découverte & Recherche
  • Harmonisation
  • Visualisation

Ingestion (étape 1)

La première étape consiste à ingérer les données en l’état (« as is »).

L’outil MarkLogic permet d’ingérer tout type de donnée (CSV, PDF, documents Office, mails, …). Toute donnée ingérée est indexée – à noter que l’indexation est incluse dans la transaction.

MarkLogic intégrant son propre moteur de recherche, il est donc possible de rechercher en mode « full text » l’ensemble des données ingérées.

Cela présente également l’avantage de conserver l’état initial des données transmises, ce qui est intéressant en termes de preuve notamment, les données n’étant pas altérées.

Il existe deux moyens d’ingérer de la donnée :

  • Au travers de l’API REST  (service) – utilisé généralement pour du fil de l’eau
  • Au travers du module de masse Java MarkLogic Content Pump (batch) – utilisé principalement pour de la reprise de données d’un système existant avec du volume

MarkLogic ne va pas chercher la donnée sur un système tiers – la donnée doit être mise à disposition.

 

Découverte et Recherche (étape 2)

L’index universel MarkLogic permet de faire de la fouille de données sur les données ingérées.

Cela permet de vérifier efficacement les données fournies en appliquant des recherches assez poussées.

L’utilisation de « facets » permet de combiner des recherches croisées très efficaces. Il est ainsi possible d’inclure et d’exclure certaines données – ici des sources ou des tables ingérées – tout en les combinant à des recherches full text.

Cela permet de :

  • Faire une fouille données sur du volume, avec des temps de réponse impressionnants ;
  • Monter en compétences dans le cadre d’un système dont le client a perdu la connaissance – application vieillissante dont les spécifications fonctionnelles ne seraient plus à jour;
  • Les facets permettent d’identifier la provenance d’une donnée. Exemple : comment savoir où sont stockées les adresses sans aucune information sur mon système source ?

Harmonisation (étape 3)

L’harmonisation est l’étape qui consiste à mapper les données source ingérées vers un modèle cible défini.

Cela permet de passer de formats hétérogènes en entrée vers un format unique en sortie et ainsi, garantir la gouvernance des données et services fournis par la plateforme (fiabilité, sécurité, cohérence).

MarkLogic propose une modélisation propriétaire (« entity services ») mais notre conviction, chez Sopra Steria, est d’adopter un modèle cible de type ontologie (modélisation graphe « semantic web » du W3C).

Cette modélisation graphe permet d’avoir un modèle ingéré dans MarkLogic et requêtable directement (MarkLogic étant une base de données graphe).

L’harmonisation se décline en plusieurs étapes :

  • Mapping des données source vers le modèle cible;
  • Enrichissement de la donnée au travers des métadonnées avec une mise en qualité (scoring, règles de gestion) et transformation de la donnée (phonétique, règles de gestion diverses, …);
  • Dé-duplication de la donnée.

Une fois harmonisée, la donnée est directement disponible.

Les différentes entités harmonisées sont liées via des liens sémantiques (triples RDF graphe, norme W3C).

Visualisation (étape 4)

L’indexation de la donnée est incluse dans la transaction (ACID).

La donnée peut donc être consultée / recherchée immédiatement après son intégration dans MarkLogic.

Remarque sur l’indexation : comme indiqué précédemment, toute donnée est indexée dans MarkLogic au travers d’un index universel. Il est cependant possible de déclarer des indexes plus fins (par exemple sur un  xpath //instance/personnePhysique/NIR). Contrairement à un SGBD classique où l’on déclare les indexes a posteriori pour optimiser les performances, MarkLogic impose d’avoir un index préalablement déclaré pour exécuter certains types de requêtes. En cas d’absence d’index, une erreur explicite est générée à l’exécution (et donc visible lors du développement). Cela présente l’avantage de garantir la performance sur du volume.

Il existe de nombreux types de recherche dans MarkLogic, notamment :

  • Full text ;
  • Wildcard ;
  • Recherche avec possibilité d’affecter différentes poids sur des critères;
  • Lemmatisation;
  • Géospatiale ;
  • Recherche inversée;
  • Double métaphone;
  • Recherche au sein du graphe (SPARQL), avec possibilité d’inférence;;
  • Recherche temporelle : MarkLogic permet de requêter la base à un instant T, et de sortir les documents dans l’état de cet instant-là. Le principe est le même que le « Time Machine » d’Apple. Chaque document est versionné à chaque modification (si la fonctionnalité est activée). A noter, qu’il est possible d’ajouter à cette historisation technique, un axe temporel de validité fonctionnelle afin de faire des recherches bi-temporelles.

L’accès à la donnée est réalisée principalement via :

  • L’API REST native : MarkLogic expose une API technique permettant d’effectuer des opérations (CRUD) sur les documents et surtout d’effectuer l’ensemble des recherches possibles ;
  • L’API REST personnalisée : l’API native étant très technique, l’exposition d’une API fonctionnelle est souvent préconisée ;
  • Un accès ODBC pour connecter des outils BI.

Architecture

MarkLogic est un outil tout-en-un. Le cœur est développé en C++.

Le code spécifique des projets MarkLogic est développé de préférence en Javascript (ES6), ou en XQuery (langage fonctionnel autour de XML)

Le code spécifique est ingéré dans MarkLogic au déploiement, tout comme la création de la structure (forêts, bases de données, indexes, serveurs d’applications, sécurité, …).

Le composant ML-Gradle permet d’avoir une approche devops, et donc de garantir qu’un package déployé sur un environnement de développement sera similaire à celui déployé en production.

MarkLogic s’appuie sur des standards à tous les niveaux, cela favorise son intégration dans les systèmes d’information de nos clients.

En interne Sopra Steria, nous avons facilement intégré MarkLogic au sein de notre outil CDK (outil interne de continuous delivery / continuous integration).

L’architecture d’un projet MarkLogic se présente généralement ainsi :

  • La plateforme MarkLogic elle-même ;
  • Le composant MLCP Java de chargement en masse ;
  • Le composant DMSDK Java d’extraction en masse ;
  • Connexion à un composant tiers pour l’authentification (qui peut rester en interne MarkLogic) ;
  • Accès à la donnée par des applications externes via différents protocoles (ODBC, HTTPS).

Vue synthétique des fonctionnalités de MarkLogic :

Zoom sur l’architecture technique :

MarkLogic s’appuie sur une architecture distribuée « shared-nothing ».

MarkLogic est un système réparti : un cluster de plusieurs serveurs permet de gérer une à plusieurs bases de données et un à plusieurs serveurs applicatifs exposant les services.

L’espace de stockage sur le disque d’un serveur est appelé une forêt. Un serveur d’un cluster hébergeant une forêt est appelé « D-NODE ». Une base est composée d’une à plusieurs forêts, ce qui assure la répartition de la base sur plusieurs serveurs. La copie synchrone des forêts entre D-NODE assure la haute disponibilité du cluster (à noter qu’il faut un cluster de minimum trois serveurs pour avoir un quorum garantissant cette haute disponibilité).

Les services sont exposés au travers de serveurs applicatifs (HTTP/ODBC) configurés pour exposer les données d’une des base du cluster via un port du serveur. Un serveur du cluster hébergeant un serveur applicatif est appelé « E-NODE ». Le serveur applicatif peut être déployé sur plusieurs serveurs du cluster, ce qui assure la répartition de la charge des services via un load-balancer.

Afin d’avoir une scalabilité sur la donnée, il suffit d’ajouter un serveur « D-NODE » (et donc des forêts) au cluster. Afin d’avoir une scalabilité sur les services (pic de charge d’une activité saisonnière par exemple), il suffit d’ajouter un serveur « E-NODE » au cluster. A noter qu’un serveur du cluster peut être à la fois « D-NODE » et « E-NODE » (cette configuration est d’ailleurs la plus fréquente sur les petits clusters).

Le cluster MarkLogic peut être déployé sur une architecture on premise, cloud ou hybride.

En résumé

MarkLogic est un outil très technique, proposant une API complète et des fonctionnalités de recherche très poussées.
La technologie s’appuie sur des standards, cela facilite son intégration dans les SI de nos clients.
Le gros avantage de cette solution est qu’elle permet de répondre à de nombreuses problématiques autour de la donnée et de traiter de nombreux cas d’utilisation.
Sopra Steria travaille aujourd’hui avec MarkLogic sur des projets dans différents domaines tels que l’Assurance, la Protection Sociale et l’Aéronautique.

Comments

  • Merci pour cet article, François

    MarkLogic embarque plusieurs types moteurs de base de données (dont un triplestore RDF, ce qui est à noter) et fournit un modèle de scalabilité horizontal.

    Ce qui peut poser question, c’est comment ML assure une scalabilité quel que soit le moteur de base de données. En particulier, pour les bases graphe et relationnel. Est-ce possible d’avoir une précision à ce sujet ?

    Merci

Leave a Reply

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