Pendant longtemps, les bases de données relationnelles ont été l'unique solution pour enregistrer des données, ou en tout cas, la solution adoptée par défaut par beaucoup de monde sans plus de réflexion sur le sujet. Pourtant, certaines personnes considèrent que le problème de stockage de données est en fait multiple et qu'il convient de se poser de nombreuses questions :
- Est-ce que les données sont fortement structurées ou non ?
- Quel est le ratio entre les lectures et les écritures ?
- Est-il acceptable de perdre un enregistrement sur un million ? Sur un milliard ?
- Est-ce que les données sont réparties sur plusieurs data-centres ?
- Est-ce que la taille des données peut être multipliée par 10 en l'espace d'un mois ?
- Quelle indisponibilité du service peut-on se permettre ?
- Etc.
Les bases de données relationnelles proposent leurs réponses à ces questions ; elles peuvent paraître raisonnables dans bien des cas, mais pas toujours. Par exemple, les bases de données relationnelles sont très mal adaptées quand on veut privilégier les performances plutôt que la garantie d'écriture des données.
Aussi, pour répondre à ces problématiques différentes, un mouvement, NoSQL, a proposé d'adopter des outils différents, spécialisés pour certains cas d'usage. Certaines bases de données NoSQL sont destinées à traiter d'énormes volumes de données, d'autres sont conçues pour maximiser le nombre de requêtes par seconde qu'un serveur pourra traiter, etc. Notons en particulier que la plupart des plus gros sites web ont quitté le monde relationnel (Google, Facebook, Twitter, Amazon), ce qui tend à valider le besoin d'avoir d'autres outils que les bases de données relationnelles.
NdA : Merci à Christophe Turbout, Thomas Douillard, Buf, olivierweb, Spack, baud123, Bruno Michel, mike.simonson et rakoo pour leur aide lors de la rédaction de cette dépêche
