IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Google migre AdWords de MySQL vers F1
Son nouveau SGBDR distribué, développé en interne qui combine le meilleur de NoSQL et SQL

Le , par Hinault Romaric

26PARTAGES

6  0 
Google a développé en catimini son propre gestionnaire de base de données relationnelle.

La société a déplacé récemment plusieurs de ses services de publicité de MySQL vers F1, un nouveau SGDBR « Fault-Tolerant Distributed » développé en interne.

Présenté lors du forum SIGMOD 2012 de Scottsdale en Arizona sur les bases de données, F1 combine les meilleures approches des SGBDR et des bases de données NoSQL, selon la division Google Research, à l’origine du projet.

F1 est essentiellement centré autour de l’évolutivité, la tolérance aux pannes, la fragmentation transparente et les avantages de coûts que fournissent les systèmes NoSQL, jumelés à la facilité d’utilisation et la prise en charge transactionnelle des SGBDR.

F1 fournit des fonctionnalités de bases de données relationnelles telles qu’un puissant moteur parallèle de requêtes SQL, des transactions, le suivi des modifications et l’indexation, sur un système de stockage hautement distribué et évolutif sur du matériel standard de ses centres de données.

Le magasin des données est dynamiquement fragmenté, supporte la réplication transactionnelle cohérente dans tous les data centers et est capable de gérer les pannes des centres de données sans perte des informations.

F1 a été développé avec un nouveau système de stockage de niveau inférieur baptisé Spanner, fondé sur Bigtable de Google. Spanner offre une réplication transversale synchrone basée sur un algorithme de tolérance aux pannes des systèmes distribués (Paxos).

Son moteur de requête SQL a été développé à partir de zéro pour masquer la latence de l’appel des procédures distantes (RPC) et permettre l’exécution des requêtes en parallèle et par lots.

Parce que F1 est distribué, les chercheurs de Google ont conclu qu’il peut s’adapter facilement et supporter un débit beaucoup plus élevé pour les charges de travail par lots que n’importe quel SGBD traditionnel.

Le service Google AdWords repose déjà sur F1.

Le pdf de présentation de F1

Source : Google Research

Et vous ?

Qu'en pensez-vous ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Thorna
Membre éprouvé https://www.developpez.com
Le 31/05/2012 à 17:59
Citation Envoyé par nchal Voir le message
J'ai remarqué quelque chose de vraiment curieux, c'est qu'il y a beaucoup de grosse BDD qui sont sous MySQL.
Attention :
La société a déplacé récemment plusieurs de ses services de publicité
Il est possible 1) qu'un "service de publicité" ne soit pas très gros, et 2) qu'un service = une base.
En fait, on n'en a aucune idée. Ca n'enlève rien à la remarque sur les grosses bases et MySQL, mais on ne peut pas trop conclure, ni dans un sens, ni dans l'autre.
Et peut-être aussi que si Google s'est donné le mal (énorme) de développer son propre SGBD, c'est que celui qu'il utilisait ne lui donnait pas toute satisfaction
2  0 
Avatar de jmini
Membre éprouvé https://www.developpez.com
Le 31/05/2012 à 22:43
Citation Envoyé par nchal Voir le message
Tout ça pour dire, pourquoi faire l'éloge d'Oracle pour gérer les grosses bases alors qu'apparement MySQL s'en sort très bien. (Je parle juste de gérer la base, par faire du PL/SQL ou du warehouse/datamining)
J'avais été marqué par cet article:
MySQL ? Un SGBDR poudre aux yeux !

J'en ai déduit que pour les cas complexes (jointure pointues, beaucoup de données dans beaucoup de tables...) MySQL n'était peut être pas l'idéal. Les exemples semblent vrai, mais il pas forcément représentatif de tous les cas d'utilisation.

Effectivement beaucoup des grands du Web utilisent pourtant des bases MySQL. Seulement pas forcément pour faire de la base complexe. Il s'agit plutôt d'employer plusieurs "petite" instance de MySQL et de les associer avec des techniques de sharding.

Sinon sur les nouveautés dans les bases de données je recommande la lecture de cet article:
Une base de données purement fonctionnelle. Il y a de bonnes réflexions...
1  0 
Avatar de al1_24
Modérateur https://www.developpez.com
Le 01/06/2012 à 13:21
Citation Envoyé par nchal Voir le message
Donc une armée de BDD plus grosses les unes que les autres pour tout gérer. (J'ai souvenir de 500 tables avec certaines tables contenant 200 000 à 500 000 occurrences) et ça tournait avec du MySQL.
Je n'appelle pas ça de grosses bases de données, ou alors c'est ce que MySQL considère comme gros
1  0 
Avatar de nchal
Membre expérimenté https://www.developpez.com
Le 31/05/2012 à 17:49
J'ai remarqué quelque chose de vraiment curieux, c'est qu'il y a beaucoup de grosse BDD qui sont sous MySQL alors qu'on nous rabache que Oracle sont les meilleurs dans ce domaine. Alors je sais MySQL, c'est maintenant Oracle et que en ce moment Oracle, on aime pas bien mais quand même, on peut admettre que leur SGBD tourne très bien. J'ai collaboré avec une SSII qui travaillait dans la protection du plagiat sur Internet. Donc une armé de BDD plus grosse les unes que les autres pour tout gérer. (J'ai souvenir de 500 tables avec certaines tables contenant 200 000 à 500 000 occurences) et sa tournait avec du MySQL.
Tout ça pour dire, pourquoi faire l'éloge d'Oracle pour gérer les grosses bases alors qu'apparement MySQL s'en sort très bien. (Je parle juste de gérer la base, par faire du PL/SQL ou du warehouse/datamining)
On remarque que même Google, qui ne va pas pleurer pour acheter une licence à 20 000€, utilise malgré tout MySQL.
1  1 
Avatar de Manu300886
Membre du Club https://www.developpez.com
Le 31/05/2012 à 18:04
Si google decide de passer sous Oracle c'est un peu plus qu'une licence qu'ils devront acheter non ?
0  0 
Avatar de alex_vino
Membre émérite https://www.developpez.com
Le 31/05/2012 à 23:49
Citation Envoyé par Manu300886 Voir le message
Si google decide de passer sous Oracle c'est un peu plus qu'une licence qu'ils devront acheter non ?
A mon avis les dernieres versions d'Oracle sont comme chez MS SQL Server, une license suivant le modele du SGBDR et en fonction du nombre de processeurs, donc plus ton serveur est petit et moins ca coute cher.

Comme dit ci-dessus on ne connait pas le nombres de tables, quantité de données... mais aussi la parallélisation (tous les services de Google fonctionnent en meme temps mais pas forcément sur meme serveur).

Et comme Thorna l'a dit, si Google développe sont SGBDR en prenant la base MySQL et en utilisant du NoSQL cela signifie que MySQL ne leur suffit pas. Ce n'est pas pour rien que les Twitter, Facebook et compagnie crées leurs propres outils, ils ont besoin de performance et d'un outil bien spécialisé (et non spécifique), ils connaissent mieux leur besoin plutot que Oracle qui est généraliste (meme si tres évolué et puissant).

Si on pousse le raissonement on pourrait aussi se dire pourquoi MacOS et tous les Linux ne forment pas qu'un seul OS fonctionnant sous Unix.

On peux aussi parler de l'Inde et de la Chine qui développent leur propre OS interne, n'ont pas parce que Windows & Co ne sont pas performants mais parce que c'est pays veulent maitriser leurs machines et surtout leur sécurité, et aussi ne pas dépendre entierement de d'autres.
0  0 
Avatar de alex_vino
Membre émérite https://www.developpez.com
Le 31/05/2012 à 23:58
Citation Envoyé par jmini Voir le message
J'avais été marqué par cet article:
MySQL ? Un SGBDR poudre aux yeux !

J'en ai déduit que pour les cas complexes (jointure pointues, beaucoup de données dans beaucoup de tables...) MySQL n'était peut être pas l'idéal. Les exemples semblent vrai, mais il pas forcément représentatif de tous les cas d'utilisation.

Effectivement beaucoup des grands du Web utilisent pourtant des bases MySQL. Seulement pas forcément pour faire de la base complexe. Il s'agit plutôt d'employer plusieurs "petite" instance de MySQL et de les associer avec des techniques de sharding.

Sinon sur les nouveautés dans les bases de données je recommande la lecture de cet article:
Une base de données purement fonctionnelle. Il y a de bonnes réflexions...
Merci pour ton commentaire je le trouve tres intéressant

Mais ton article sur MySQL date du 21/07/2010, soit un paquet de temps. Entre temps j'ai vu beaucoup de nouveautés concernant les nouvelles versions de MySQL, notamment des performances.

A titre d'information on est 60 000 personnes dans mon entreprise (donc autant de machines si ce n'est plus), on n'utilise que SQL Server 2008 R2 et Oracle 11g. Tous les sites web sont aussi sous SQL Server.
0  0 
Avatar de guidav
Membre éprouvé https://www.developpez.com
Le 01/06/2012 à 15:28
Citation Envoyé par al1_24 Voir le message
Je n'appelle pas ça de grosses bases de données, ou alors c'est ce que MySQL considère comme gros
+1 : j'ai développé des bases de 10M lignes sous MySQL, sans ralentissement notable (pas de transactionnel, peu d'écritures).
La "grosseur" d'une base dépend surtout de ce qu'on fait comme type d'opérations avec.
0  0 
Avatar de TanEk
Membre expérimenté https://www.developpez.com
Le 01/06/2012 à 19:31
La presentation dit que le MySQL etait utilise pour le systeme de pub de Google, notamment le stockage des informations des clients de Google, je doute que Google n'ait que 500k clients dans le monde, notamment ils disent qu'ils doivent scale la taille de la database a des dizaines de terabytes. Et ils disent explicitement que c'etait un systeme MySQL utilisant les techniques de shards et de replications pour pouvoir scale. Lire la source originale donne parfois plus d'informations que l'article le citant .
0  0 
Avatar de Gugelhupf
Modérateur https://www.developpez.com
Le 03/06/2012 à 10:11
Citation Envoyé par nchal Voir le message
(J'ai souvenir de 500 tables avec certaines tables contenant 200 000 à 500 000 occurences) et sa tournait avec du MySQL. Tout ça pour dire, pourquoi faire l'éloge d'Oracle pour gérer les grosses bases alors qu'apparement MySQL s'en sort très bien. (Je parle juste de gérer la base, par faire du PL/SQL ou du warehouse/datamining)
Et bien justement, si c'est pour faire du datawarehouse/datamining, MySQL ne s'en sortiraient jamais avec ses quelques 1 à 10M de lignes.

J'ai le souvenir du service informatique d'une entreprise dans la restauration qui utilisait MySQL pour gérer un grand nombre de données, ils n'avaient pas trouvé d'autre moyen que de créer plusieurs tables "réservation" (une table réservation pour chaque jour, pour les 70 jours à venir, soit 70 tables)...
Tout ça parce que MySQL n'est pas capable de gérer un grand nombre de donnée (et parce qu'ils ne voulaient pas payer une licence pour obtenir plus gros et/ou ne connaissaient pas PostgreSQL).
Tant que ça marche - plus ou moins bien - on garde.
0  0