Où nous vous accueillons dans un parcours Loto Québec dédié aux bases de données NoSQL. Treize capsules pour plus de quatre heures de vidéo passionnantes, sur un sujet encore mal connu, que nous allons prendre soin de bien positionner en essayant de répondre aux vraies questions des usagers, bien loin des trompettes marketing des fournisseurs.

Pour bien comprendre le phénomène NoSQL, il est nécessaire de le replacer dans son contexte, une technologie qui répond à des besoins précis et vient après trois générations de bases de données, hiérarchique, réseau et relationnelle. L’erreur serait de croire que le NoSQL renvoie les autres modèles aux oubliettes, car le nouveau paradigme est un complément des autres pratiques, mieux adapté à certains besoins nouveaux : résilience, évolutivité, Big Data, capteurs et relations.

C’est ici qu’est rappelé la référence ACID et que sont introduits ses équivalents NoSQL : BASE et CAP.

Le mode NoSQL, plus encore que le relationnel, fait appel à un grand nombre de technologies, qu’il va nous falloir maîtriser pour être à l’aise : le format JSON, REST, l’extension Scale-Out, les clusters, le « sharding » et le « hashage » cohérent, les langages déclaratifs. Sans lesquels, les différentes formes NoSQL nous sembleront abstraites et vides de sens. Plus encore que pour le relationnel, la nouvelle mouvance nécessite un effort d’introspection, très technique, un « droit d’entrée à acquitter, en quelque sorte.

Nous vous proposons ici, une première approche des différentes solutions NoSQL, un rapide tableau général brossé sur les grands modèles : clés-valeurs, colonnes, documents, graphes et le « petit » dernier, les « time series », les séries temporelles. On va surtout tenter de répondre à la question de fond : « mais à quoi tout cela va-t-il pouvoir servir ». Mieux vaut se poser la question maintenant que lorsqu’il sera trop tard pour faire machine arrière.

Le paradigme de clés-valeurs est le plus simple de la galaxie NoSQL. Il s’apparente à une organisation de type tables d’index, particulièrement adapté à certains besoins techniques, tels qu’une gestion de caches ou de profils, tout ce qui n’induit pas de relations complexes entre les données et se traduit logiquement par un empilement de couples clés-valeurs. Outre sa simplicité, le modèle clés-valeurs est bien adapté aux structures fortement évolutives, mais présente l’inconvénient, sauf à ajouter des couches applicatives supplémentaires, de ne pas pouvoir « requêter » une valeur. Seule la clé étant accessibles aux langages d’interrogation.

Les bases documents, que symbolise MongoDB, est une extension du modèle clé-valeur, la valeur étant cette fois un document semi-structuré, un format JSON ou autre. Il permet de traiter des volumes considérables d’informations et de requêter le contenu des valeurs. Compte tenu de l’importance prise par MongoDB sur le marché et ses capacités transactionnelles, conformes au modèle ACID, nous vous en proposons une introspection fine, plus précisément sur les capacités de son langage de requête : Mongo Query Language.

Le mode colonnes répond à un besoin fort d’extensibilité, avec peu d’écritures, mais un très grand nombre de lectures. Ce modèle a de quoi stabiliser les usagers, habitués à des schémas rigides, puisque deux lignes consécutives d’une même base pourront ne pas avoir le même nombre de colonnes, la raison étant que l’on s’est débarrassé du concept « énervant » de valeurs « null ».

Une bonne compréhension du modèle colonnes nécessitera, plus encore que pour les autres paradigmes NoSQL, de bien comprendre l’architecture de fichiers mise en œuvre. C’est elle qui expliquera, pour l’essentiel, les performances étonnantes du mode « colonnes », le secret étant une historisation qui ne se fait plus en mode lignes, comme avec le modèle relationnel, mais en colonnes.

Big Table est l’implémentation du mode colonnes, de Google. Nous vous en proposons une présentation globale, avec son modèle de données, très représentatif du concept de colonnes, son architecture de fichiers avec un découpage en « tablets », elles-mêmes structurées en « chunks », le tout traduit par le système de fichiers GFS, en tables SSTables, mais aussi ses capacités d’interrogation, plus précisément via l’API HBase, adaptée à son contexte.

Big Table n’est accessible que sur le Cloud et concerne généralement les grosses infrastructures, ce qui n’empêchera pas que l’on puisse développer un POC, ne serait-ce que pour mieux comprendre la finalité du modèle.

Cassandra de la fondation Apache est le pendant de Big Table. Une sorte de compromis clé-valeurs/colonnes, avec l’avantage de pouvoir être mis en œuvre sur des serveurs locaux et pas exclusivement dans le Cloud.

Conforme au modèle colonne et à son mode d’historisation, Cassandra est particulièrement bien adapté à un déploiement en cluster. Ce que nous mettrons en évidence en insistant sur les mécanismes de réplication, mais surtout de « peuplement » des clusters, via une technique de hashage. Là encore, il est important de se familiariser avec l’infrastructure sous-jacente de Cassandra, de manière à l’implémenter de la manière la plus efficace.

Nous n’oublierons pas, enfin, de nous focaliser sur son langage de requête, CQL3 et ses spécificités : keyspace, tables, clés de partitions, clés de clusters, etc. Sans chercher à en faire un clone de SQL.

Ce mode NoSQL a pour vocation de traiter les problématiques de description logique et de stockage d’objets, reliés par une association dotée d’une signification sémantique. On n’est plus dans un contexte d’entités liées par des clés ou des jointures, mais dans celui de relations d’associations, comme peut l’être un annuaire.

Au-delà d’une modélisation très spécifique, le mode graphe fait appel à des langages de requête particuliers, tels que Cypher de Neo4J, la star du domaine.

Tout candidat à une approche exhaustive du mouvement NoSQL, ne saurait faire l’impasse sur ce système, qui tel Neo4J, rencontre un succès de plus en plus évident.

Les bases temporelles ou « time series » sont indispensables désormais pour traiter les besoins issus des capteurs et IoT, des séries de données dotées d’un « timestamp ». L’important n’étant pas seulement les valeurs, mais aussi la chronologie des événements mesurés. Ce type de base de données contribue au mouvement NoSQL avec des langages de requête spécifiques (InfluxDB…) et de nombreuses API, disponibles quel que soit le langage retenu.

Il est certain qu’avec le déploiement exponentiel des objets, nous aurons à revenir très souvent sur ce type de structure… alors autant s’y préparer tout de suite.

Sans vouloir adapter le mode NoSQL à tous les contextes, il est utile de se poser quelques questions sur son usage dans le monde du transactionnel, par exemple, comme le propose MongoDB. On n’est certes pas dans un environnement strictement respectueux du paradigme ACID, mais les chefs de projet vont cependant se trouver dans des situations où ils auront besoin de s’en rapprocher. Dans le même ordre d’idées, nous nous interrogerons sur la capacité des systèmes NoSQL à protéger leurs usagers des dérives sécuritaires. La réalité n’étant, à vrai dire, pas très rassurante.