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

Les rubriques (actu, forums, tutos) de Développez
Tags
Réseaux sociaux




Sur le même sujet
Le , par Hinault Romaric, Responsable Actualités
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 ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de jmini jmini
http://www.developpez.com
Membre Expert
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...
Avatar de alex_vino alex_vino
http://www.developpez.com
Membre Expert
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.
Avatar de alex_vino alex_vino
http://www.developpez.com
Membre Expert
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.
Avatar de al1_24 al1_24
http://www.developpez.com
Modérateur
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
Avatar de guidav guidav
http://www.developpez.com
Membre émérite
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.
Avatar de nchal nchal
http://www.developpez.com
Membre émérite
le 01/06/2012 16:10
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.
Avatar de TanEk TanEk
http://www.developpez.com
Membre Expert
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 .
Avatar de Gugelhupf Gugelhupf
http://www.developpez.com
Membre Expert
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.
Avatar de berceker united berceker united
http://www.developpez.com
Expert Confirmé Sénior
le 04/06/2012 9:49
Citation Envoyé par Gugelhupf  Voir le message
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é.
Avatar de svaroqui svaroqui
http://www.developpez.com
Invité de passage
le 04/06/2012 14:22
"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
Avatar de selecta selecta
http://www.developpez.com
Membre habitué
le 14/06/2012 11:54
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
Offres d'emploi IT
UX designer - anglais courant h/f
CDI
Dassault Systèmes SA - Ile de France - DS Campus Vélizy
Parue le 05/12/2014
Ingénieur d’étude et développement .net c# h/f
CDI
Akka technologies - Aquitaine - Bordeaux (33000)
Parue le 27/11/2014
Ingénieur .NET (H/F)
CDI
Technology & Strategy - Lorraine - Nancy (54100)
Parue le 10/12/2014

Voir plus d'offres Voir la carte des offres IT
 
 
 
 
Partenaires

PlanetHoster
Ikoula