J’ai un modèle relationel très complexe avec des règles métier des plus biscornues quand on souhaite relire quelque chose. Par exemple, pour récupérer le libellé d’un item il faut que je concatène plusieurs champs et que je fasse une ou deux conditions pour gérer des cas spécifiques.
J’ai peur que ça devienne difficile à gérer et que ça facilite énormément les erreurs de traitement à l’avenir.
J’ai envisagé les trois solutions classiques :
- dénormaliser le modèle en stockant à plat certaines données précalulées dans le SGBDR, mais il y a pas mal de choses où c’est vraiment délicat, par exemple quand un item contient une collection de données
- coder des vues complexes et des procédures stockées pour automatiser certaines actions, mais j’ai l’impression de déporter mon métier là où ça sera le plus difficile à maintenir et à développer
- ou utiliser un bête stockage orienté document et laisser tomber le relationnel, qui de toutes façons me sert assez peu sur ces données
À priori je suis plutôt parti sur la troisième solution et j’ai besoin de vos lumières pour choisir le datastore le plus adapté.
Voici mes contraintes :
- Performant (c’est pour utiliser en permanence au cœur de l’infra)
- Accessible facilement en PHP
- Stocke des données structurées (type json) avec de la hiérarchie (un document peut contenir une collection par exemple)
- Le modèle de chaque document doit être libre ou en tout cas très souple
- Sait manipuler une collection de plusieurs millions de documents (d’où la nécessité des index au point précédent)
- Sur ces millions de doc je peux faire des requêtes de type « par date de mise à jour inverse, uniquement ceux qui ont un attribut ‘toto’ à 145 et un attribut ‘tata’ à 567 » sans avoir à faire un scan de tous les documents à la requête (ce qui implique probablement des index)
- Sait gérer de la haute disponibilité (par exemple deux serveurs synchronisés en master-master)
- Simple à utiliser et administrer
- Stockage disque (donnée pérenne en cas de plantage)
- Accès réseau (la base et l’applicatif sont sur des serveurs différents)
J’ai aussi des non contraintes :
- Les écritures sont faites en batch, je n’ai pas besoin de transaction ou de lock d’écriture
- Je n’ai pas besoin de validation, typage, ou contrainte d’intégrité
- Je n’ai pas besoin de transactions
- En cas de plantage, j’accepte de perdre quelques minutes de données non écrites (mais pas de planter les anciennes données)
- J’accepte des latences jusqu’à quelques minutes entre les différents serveurs synchronisés
- Je peux prévoir à l’avance les requêtes que je vais faire (et donc construire des index dédiés)
Les bonus :
- Consommation mémoire pas trop délirante
- Outil pour faire des dump/restore
Cassandra, Voldemort, MongoDB et autres joyeusetés, je suis preneur de vos recommandations avec explications, ou simplement des liens vers des billets qui peuvent m’éclairer.
Merci à vous cher public (j’ai toujours rêvé de dire ça ;)
Laisser un commentaire