Après des années d'utilisation des SGBD (en fait, surtout MySQL et SQLite avec un peu de PostGreSQL), j'étais convaincu de leurs capacités, mais frustré de leurs limitations. Deux exemples simples :
On a une relation many2many ("Post"—"Tag") et on recherche les "posts" qui ont le tag "linux" mais pas celui "sql". On se retrouve vite avec des requêtes complexes à écrire et qui ne peuvent pas être lancées en temps réel.
On gère une liste ordonnée (de "Tag") que l'utilisateur peut réordonner à sa guise. En mode relationnel, cela implique de gérer une table relationnelle où chaque enregistrement a une position numérique qu'il faut recalculer globalement en cas de modification locale. C'est là aussi un calvaire.
Autre besoin fréquent, la recherche en texte entier. Les SGDBR sus-cités y ont fait de gros progrès, mais cela reste limité par rapport aux outils spécialisés. J'ai cherché du côté des bases NoSQL orientées documents qui permettent effectivement de résoudre les problèmes ci-dessus. Mais, en plus des problèmes de maturité et de confiance, la perte du modèle relationnel est parfois très pénible pour des données qui suivent bien ce modèle. Et (avant l'apparition d'Elasticsearch) aucune de ces bases NoSQL ne permettait la recherche en texte intégral.
Finalement, j'ai adopté une solution qui me satisfait (presque) totalement :
séparer la base de stockage (normalisée) de la base de recherche (dénormalisée),
sérialiser certaines données stockées.
Pour sérialiser, PostGres propose un type "array". On peut aussi utiliser un texte JSON qui est portable et plus simple à gérer en amont. C'est très pratique à manipuler dans le langage applicatif. On ne peut plus trop faire de recherche SQL dessus, mais ce n'est pas un problème puisque seules les recherches basiques restent en SQL.
Pour la base de recherche, on a le choix entre Lucene/Solr, Sphinx search, Xapian, etc.
La seule difficulté, c'est de gérer l'indexation, c'est-à-dire l'extraction des données stockées pour les indexer, et surtout la synchronisation des données.
# Séparer stockage (relationnel) et recherche
Posté par rogo . En réponse à la dépêche Petit état des lieux du NoSQL. Évalué à 9.
Après des années d'utilisation des SGBD (en fait, surtout MySQL et SQLite avec un peu de PostGreSQL), j'étais convaincu de leurs capacités, mais frustré de leurs limitations. Deux exemples simples :
Autre besoin fréquent, la recherche en texte entier. Les SGDBR sus-cités y ont fait de gros progrès, mais cela reste limité par rapport aux outils spécialisés. J'ai cherché du côté des bases NoSQL orientées documents qui permettent effectivement de résoudre les problèmes ci-dessus. Mais, en plus des problèmes de maturité et de confiance, la perte du modèle relationnel est parfois très pénible pour des données qui suivent bien ce modèle. Et (avant l'apparition d'Elasticsearch) aucune de ces bases NoSQL ne permettait la recherche en texte intégral.
Finalement, j'ai adopté une solution qui me satisfait (presque) totalement :
Pour sérialiser, PostGres propose un type "array". On peut aussi utiliser un texte JSON qui est portable et plus simple à gérer en amont. C'est très pratique à manipuler dans le langage applicatif. On ne peut plus trop faire de recherche SQL dessus, mais ce n'est pas un problème puisque seules les recherches basiques restent en SQL.
Pour la base de recherche, on a le choix entre Lucene/Solr, Sphinx search, Xapian, etc.
La seule difficulté, c'est de gérer l'indexation, c'est-à-dire l'extraction des données stockées pour les indexer, et surtout la synchronisation des données.