Posté par __o .
En réponse à la dépêche Petit état des lieux du NoSQL.
Évalué à 10.
Dernière modification le 07 mai 2012 à 15:26.
Les SGBD relationnels sont traditionnellement optimisés pour fonctionner dans un environnement où les données et même les indexes sont bien plus gros que la RAM. Ces SGBD font donc tout pour limiter le nombre d'I/O, essayer de lire les données séquentiellement, etc.
Beaucoup de bases NoSQL sont au contraire optimisées pour fonctionner en RAM (en particulier les BDD clé-valeur et documents), ou assument que les données sont cachées en RAM par le système. Ça peut poser de sérieux problèmes le jour où les performances s'écroulent d'un coup parce que les données sont devenues plus grosses que la RAM.
Au final les SGBD traditionnels sont plus performants qu'un certain nombre de bases NoSQL, lorsque les données doivent être lues sur le disque.
Il y en a qui en reviennent [1]
Notons en particulier que la plupart des plus gros sites web ont quitté le monde relationnel (Google, Facebook, Twitter, Amazon)
Les systèmes NoSQL utilisés par ceux là répondent plus à des problèmes de haute disponibilité, de scalabilité et de souplesse que de performances: Fragmentation (sharding) automatique, changement de schema à chaud, etc.
Twitter utilise encore MySQL comme stockage principal [2].
Youtube utilise MySQL également. D'ailleurs ils ont démarré un projet intéressant pour gérer automatiquement le sharding, etc [3].
Facebook aussi utilise MySQL pour beaucoup de choses [4].
# Budget RAM
Posté par __o . En réponse à la dépêche Petit état des lieux du NoSQL. Évalué à 10. Dernière modification le 07 mai 2012 à 15:26.
Les SGBD relationnels sont traditionnellement optimisés pour fonctionner dans un environnement où les données et même les indexes sont bien plus gros que la RAM. Ces SGBD font donc tout pour limiter le nombre d'I/O, essayer de lire les données séquentiellement, etc.
Beaucoup de bases NoSQL sont au contraire optimisées pour fonctionner en RAM (en particulier les BDD clé-valeur et documents), ou assument que les données sont cachées en RAM par le système. Ça peut poser de sérieux problèmes le jour où les performances s'écroulent d'un coup parce que les données sont devenues plus grosses que la RAM.
Au final les SGBD traditionnels sont plus performants qu'un certain nombre de bases NoSQL, lorsque les données doivent être lues sur le disque.
Il y en a qui en reviennent [1]
Les systèmes NoSQL utilisés par ceux là répondent plus à des problèmes de haute disponibilité, de scalabilité et de souplesse que de performances: Fragmentation (sharding) automatique, changement de schema à chaud, etc.
Twitter utilise encore MySQL comme stockage principal [2].
Youtube utilise MySQL également. D'ailleurs ils ont démarré un projet intéressant pour gérer automatiquement le sharding, etc [3].
Facebook aussi utilise MySQL pour beaucoup de choses [4].
Google utilise beaucoup MySQL également.
[1] http://blog.engineering.kiip.me/post/20988881092/a-year-with-mongodb
[2] http://engineering.twitter.com/2012/04/mysql-at-twitter.html MySQL is the persistent storage technology behind most Twitter data: the interest graph, timelines, user data and the Tweets themselves.
[3] https://code.google.com/p/vitess/wiki/ProjectGoals
[4] http://gigaom.com/cloud/facebook-shares-some-secrets-on-making-mysql-scale/ MySQL handles pretty much every user interaction: likes, shares, status updates, alerts, requests, etc.