Je vais te donner le mot clé magique pour trouver les réponses à ce que tu cherches: newSQL.
En gros, historiquement on a des SGDB qui proposent une intégrité relationnel, sont ACID et offrent un support des transactions. Cela a plein de bonnes propriétés mais tu as d'un côté un problème d’impédance avec les langages objets (toujours la merde pour faire les bindings), et de l'autre ça devient souvent assez vite usine à gaz et surtout ça peut avoir du mal à scaler pour les besoins des grosses dotcom. Tu as des solutions maitres-esclaves, si tu as peu d'écritures. Et tu as des solutions reposant sur le sharding. Le problème c'est que tu arrives vite à perdre les propriétés ACID et/ou transaction en shardant, et tu vas très vite te retrouver à devoir gérer tout ça dans ton code métier (refaire tes jointures etc.).
De la est parti le noSQL qui regroupe vraiment beaucoup de choses n'ayant pas grand chose à voir ensemble si ne n'est que généralement tu perds le côté relationnel, l'ACID et les TX. C'est très cool pour certaines choses, ca répond au besoin de scalabilité pour certains mais tu te retrouves rapidement à devoir gérer plein de contraintes dans le code métier. Refaire des TX adhoc, gérer les jointures et pleins de trucs rigolos que les devs passent leur temps à foirer par ce que c'est compliqué.
Et maintenant on observe une vague de retour sur des bases qui scalent mais qui repassent sur le modèle SQL et proposent les TX ACID. Le constat est que pour un certain nombre de besoins filer une vue document, une table orientée ligne ce n'est pas suffisant et on passe son temps à tout refaire à la main. On case ça sous le nom newSQL et tu peux notamment lire le papier sur Google Spanner pour te faire une idée.
Après cette introduction grossière tu as tout les mots clés qu'il te faut pour trouver des articles beaucoup plus pertinents et intéressants sur le sujet. Encore une fois, il n'y a pas d'outil magique. Il faut bien comprendre ses besoins et sa partie métier pour choisir l'outil ou l'ensemble d'outils adaptés. Refaire du relationnel sur du noSQL est aussi merdique que l'inverse. Il faut pas non plus être prétentieux sur la scalabilité; il faut taper fort pour arriver aux limites et il vaut mieux partir sur des choses simples plutôt sur une pile hype "tout le monde utilise"; de toute façon tu auras du mal à prévoir ce qui sera limitant et faudra réécrire / ré-architecturer.
[^] # Re: C'est vrais du coup, quel intérêt ?
Posté par ckyl . En réponse au journal Témoignage d'expérience de nosql avec PHP et Mongodb. Évalué à 10.
Je vais te donner le mot clé magique pour trouver les réponses à ce que tu cherches: newSQL.
En gros, historiquement on a des SGDB qui proposent une intégrité relationnel, sont ACID et offrent un support des transactions. Cela a plein de bonnes propriétés mais tu as d'un côté un problème d’impédance avec les langages objets (toujours la merde pour faire les bindings), et de l'autre ça devient souvent assez vite usine à gaz et surtout ça peut avoir du mal à scaler pour les besoins des grosses dotcom. Tu as des solutions maitres-esclaves, si tu as peu d'écritures. Et tu as des solutions reposant sur le sharding. Le problème c'est que tu arrives vite à perdre les propriétés ACID et/ou transaction en shardant, et tu vas très vite te retrouver à devoir gérer tout ça dans ton code métier (refaire tes jointures etc.).
De la est parti le noSQL qui regroupe vraiment beaucoup de choses n'ayant pas grand chose à voir ensemble si ne n'est que généralement tu perds le côté relationnel, l'ACID et les TX. C'est très cool pour certaines choses, ca répond au besoin de scalabilité pour certains mais tu te retrouves rapidement à devoir gérer plein de contraintes dans le code métier. Refaire des TX adhoc, gérer les jointures et pleins de trucs rigolos que les devs passent leur temps à foirer par ce que c'est compliqué.
Et maintenant on observe une vague de retour sur des bases qui scalent mais qui repassent sur le modèle SQL et proposent les TX ACID. Le constat est que pour un certain nombre de besoins filer une vue document, une table orientée ligne ce n'est pas suffisant et on passe son temps à tout refaire à la main. On case ça sous le nom newSQL et tu peux notamment lire le papier sur Google Spanner pour te faire une idée.
Après cette introduction grossière tu as tout les mots clés qu'il te faut pour trouver des articles beaucoup plus pertinents et intéressants sur le sujet. Encore une fois, il n'y a pas d'outil magique. Il faut bien comprendre ses besoins et sa partie métier pour choisir l'outil ou l'ensemble d'outils adaptés. Refaire du relationnel sur du noSQL est aussi merdique que l'inverse. Il faut pas non plus être prétentieux sur la scalabilité; il faut taper fort pour arriver aux limites et il vaut mieux partir sur des choses simples plutôt sur une pile hype "tout le monde utilise"; de toute façon tu auras du mal à prévoir ce qui sera limitant et faudra réécrire / ré-architecturer.