Google migre AdWords de MySQL vers F1

[Hinault Romaric]

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

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 ?

[nchal]

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.

[Thorna]

Envoyé par nchal

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

[Manu300886]

Si google decide de passer sous Oracle c'est un peu plus qu'une licence qu'ils devront acheter non ?

[jmini]

Envoyé par nchal

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...

[alex_vino]

Envoyé par Manu300886

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.

[alex_vino]

Envoyé par jmini

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.

[al1_24]

Envoyé par nchal

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

[guidav]

Envoyé par al1_24

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.

[nchal]

Pour moi, simple étudiant en informatique, je trouve que 10 bases de données avec certaine possédant plus de 500 tables et certaines tables possédant plus de 500 000 occurrences, c'est pas mal. Avec un accès permanent à ces basesn je trouve que MySQL s'en sort quand même bien.

[TanEk]

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 .

[Gugelhupf]

Envoyé par nchal

(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.

[berceker united]

Envoyé par Gugelhupf

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.

C'était peut être le faite que le schémas de la base de données n'était pas adapté.

[svaroqui]

"MySQL ne s'en sortiraient jamais avec ses quelques 1 à 10M de lignes."

La il y a un sérieux problèmes de configuration MySQL ou système

Avec l'apport de MariDB 5.5 l'intoduction de join par Hash et Block l'algorithmie n'a plus grand chose a envier aux SGBD commerciaux

Il existes pourtant en effet des problématiques de sharding bien plus compliquées que la répartition de charge en simple lectures/écritures ou par sharding applicatif .

Le cas de Google est un bonne exemple de "database abstraction layer at scale". Je leur souhaites de réussir et de rendre ainsi a la communauté ce qu'elle leur a donnée en open sourcant le code.

Un moteur de stockage F1 sur MySQL serait de toute beauté.

Le travail pour aboutir reste grand mais a commencé depuis longtemps , un proxy permettant la scalabilité du SQL en MAP REDUCE et un storage fault tolèrent.

Le proxy étant déjà bien avancé pourquoi utiliser encore un SGBD pour faire du full scan et du get/set.

La stabilité et la consistance :

OUI mais Google avec BIG DATA possède aussi un système durable

La performance en Get Set :
Possible aussi avec MariaDB/Handler_socket ou MySQL/memcahe/innodb


Réplication synchrone muti sites faute tolerent:

MariaDB et ses forks viennent juste de commencer l’intégration de Galera
NDB cluster possède un système réplication asynchrone CAP tolèrent

[selecta]

MYSQL et ses forks, MariaDB, Drizzle savent fort heureusement gérer des tables à plusieurs dizaines, voire centaines de millions de lignes.

Et quand on voit l'attrait que procurent les très grosses bases de données (taille supérieure au To), on se dit que le HandlerSocket, le MEMCACHED peuvent probablement tirer MySQL vers le haut et lui donner une pérennité à côté des solutions orientées NoSQL