Derrière tout ces produits tu as des objectifs un peu différents à chaque fois. Certains cherchent vraiment la performance sur des opération très simple et limités (exemple voldemort, tokyo cabinet). D'autre cherche un compromis entre structuration/fonctionnalités et performance (couchDB, HBase). De même la performance peut concerner le débit, la latence, le volume de donnée, la resistance aux lectures/écritures, la tolérance aux pannes etc.
Je pense que c'est pour cela qu'on voit apparaitre autant de solutions. Ce genre de techno n'est utile que pour des projets déjà gros et chaque fonctionnalité présente ou absente peu avoir un impact important sur le design de l'application et des performances. Pour le moment j'ai l'impression que tout le monde réécrit exactement ce dont il a besoin et que le consensus est plus difficile à trouver que pour un bête cache cle/valeur par exemple.
[^] # Re: RDBMS sucks
Posté par ckyl . En réponse à la dépêche Répartition de charge : axes de réflexion et quelques exemples de solutions libres. Évalué à 5.
Derrière tout ces produits tu as des objectifs un peu différents à chaque fois. Certains cherchent vraiment la performance sur des opération très simple et limités (exemple voldemort, tokyo cabinet). D'autre cherche un compromis entre structuration/fonctionnalités et performance (couchDB, HBase). De même la performance peut concerner le débit, la latence, le volume de donnée, la resistance aux lectures/écritures, la tolérance aux pannes etc.
Je pense que c'est pour cela qu'on voit apparaitre autant de solutions. Ce genre de techno n'est utile que pour des projets déjà gros et chaque fonctionnalité présente ou absente peu avoir un impact important sur le design de l'application et des performances. Pour le moment j'ai l'impression que tout le monde réécrit exactement ce dont il a besoin et que le consensus est plus difficile à trouver que pour un bête cache cle/valeur par exemple.