Quelle base pour stocker 100 million de ligne ? – part 1 : théorie

Expression du besoin fonctionnel

L’objectif est d’être capable de stocker 100 000 000 documents avec alfresco. On sait déjà que la base de donnée alfresco ne tiendra jamais la charge. Le but est donc de déléguer le stockage des méta-données à une base externe (laquelle ?) afin de décharger la base alfresco.

Il y a aussi un moteur d’indexation (solr) qui indexe tous les documents et qui effectue la recherche sur les méta-données. Ainsi le rôle de la base de donnée est de stoker la donnée et pas d’effectuer des recherches.

Une requête Solr renverra des ID de base de donnée mysql correspondant à cette recherche.

Pour soulager la base alfresco, il faudrait une seconde base de donnée qui fasse le mapping entre l’id de la base alfresco et les méta-donnée du document.

Théorie sur les bases de données

Théorème de CAP

Dans ce chapitre, nous allons faire un peu de théorie et étudier le théorème de CAP.

Consistency

C = Consistence = La donnée est fiable. Après un insert ou un update, quand on fait un read, on est certain que la donnée soit à jour.

Availability

A = Availability = Le fait que la base de donnée soit rapide à répondre (haute vitesse d’accès à la donnée).

Partitioning

P = Partitioning = Quand on a des grosses base de données, un seul serveur ne suffit plus pour tout stocker, il faut partitionner la donnée sur plusieurs serveurs.

Le théorème de CAP dit qu’il est possible d’avoir seulement 2 de ses trois choses.

Les bases de données relationnelles (postgresql, mysql) sont des bases de données CA (la donnée est rapide d’accès et toujours fiable) mais se scale très mal. Le partitioning n’est pas impossible, mais l’overhead de partitioning coute très cher.

A partir du moment il faut commencer à avoir un cluster, il faut songer à des bases de données AP ou CP.

Par exemple, mongoDB est une base de donnée CP : Elle est capable d’être clusterisée sans payer de gros overhead, et la donnée est toujours consistante. Après un update, la donnée est tout de suite mise à jour sur tous les clusters. Le coût a payer pour cela est une vitesse de lecture diminuée (availability).

D’un autre côté, il y a Cassandra : une basse de donnée AP. C’est à dire que Cassandra se clusterise très bien tout en gardant des vitesses d’accès comparables à des bases de données relationnelles. Le contre-coup à cela, c’est qu’un update peut mettre du temps à se propager aux clusters. Un appel read, juste après un update, peut ne pas renvoyer la donnée updatée mais l’ancienne valeur. L’ajout / modification / suppression de donnée devient asynchrone.

Pour les bases de données AP et CP, le fait d’être transactionnelle coute plus cher aussi. Garantir une transaction à travers tous les clusters est plus difficile que sur une seule machine.

Les différents modèles de base de données

Différents modèles de bases de données vont être étudier dans ce chapitre, pas seulement les bases SQL conventionnelles, mais aussi les bases noSql (not only sql)

Relationnel

Ce sont les plus connues, elles ont été évoquées plus haut. Les bases de données relationnelles fonctionnent avec des jointures. Le principe est d’éviter à tout prix de dupliquer la données. Pour cela, on va utiliser des jointures pour lier les données entre elles. On dit que les entités ont des relations entre elles (1 to n, n to 1, n to m, 1 to 1).

L’avantage de ce type de bases de données est que la donnée n’est pas dupliquée, elle prend moins de place sur disque. Le désavantage est que les relations entre les entités sont fortes, c’est pour cela que ce genre de base de données est difficile à scaller.

Clés / valeur

Ce genre de base de données est très adapté pour les technologies de caches. A partir d’une clé, on est capable de récupérer des données.

Le problème de ces bases de données est qu’on ne peut pas faire de requête avec critère de sélection, par exemple : « Donne moi toutes les clés qui contiennent un chat ». Ou alors si c’est possible, cela coute extrêmement cher en performance.

Document

Ce sont ces bases que je préfère. MongoDB est une base de données orientée document.

Avec ces bases de données, il faut penser complètement différemment des bases relationnelles. Par exemple, il ne faut pas avoir peur de dupliquer la donnée, et faire des relations entre les tables coute cher en performance car les notions de lazy loading n’existent pas (encore ?).

Ce type de base est très approprié si le produit n’est pas figé et que le modèle de donnée est amené à souvent évoluer.

L’approche est de faire des POJO en java, et les envoyer a la base de donnée qui les sérializera en json. On pourra faire des requêtes sur des propriétés json, etc …

Graph

Celles-ci, je les connais moins, j’ai un petit peu joué avec neo4J mais j’ai très vite été déçu du produit (par exemple il est difficile de stocker des HashMap). Il existe des domaines (notamment en statistique) où se représenter la donnée sous forme de graph permet une plus grande exploitation de la donnée, notamment en cherchant des voisins pas trop éloignés d’un nœud. C’est très utilisé pour les algorithmes de recommandation.