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

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Autres SGBD Discussion :

Google migre AdWords de MySQL vers F1


Sujet :

Autres SGBD

  1. #1
    Responsable .NET

    Avatar de Hinault Romaric
    Homme Profil pro
    Consultant
    Inscrit en
    Janvier 2007
    Messages
    4 570
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Janvier 2007
    Messages : 4 570
    Points : 252 372
    Points
    252 372
    Billets dans le blog
    121
    Par défaut Google migre AdWords de MySQL vers F1
    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 ?
    Vous souhaitez participer aux rubriques .NET ? Contactez-moi

    Si déboguer est l’art de corriger les bugs, alors programmer est l’art d’en faire
    Mon blog, Mes articles, Me suivre sur Twitter
    En posant correctement votre problème, on trouve la moitié de la solution

  2. #2
    Membre expérimenté Avatar de nchal
    Homme Profil pro
    Étudiant
    Inscrit en
    Avril 2012
    Messages
    512
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2012
    Messages : 512
    Points : 1 654
    Points
    1 654
    Par défaut
    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.
    Si la réponse vous convient, un petit ça encourage.
    Avant tout nouveau post, pensez à : la FAQ, Google et la fonction Recherche
    Si vous devez poster, pensez à: Ecrire en français, la balise [CODE] (#) et surtout

  3. #3
    Membre éprouvé
    Profil pro
    Inscrit en
    Décembre 2004
    Messages
    585
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2004
    Messages : 585
    Points : 1 138
    Points
    1 138
    Par défaut
    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
    L'avis publié ci-dessus est mien et ne reflète pas obligatoirement celui de mon entreprise.

  4. #4
    Membre du Club
    Profil pro
    Inscrit en
    Octobre 2010
    Messages
    90
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2010
    Messages : 90
    Points : 43
    Points
    43
    Par défaut
    Si google decide de passer sous Oracle c'est un peu plus qu'une licence qu'ils devront acheter non ?

  5. #5
    Membre éprouvé

    Inscrit en
    Janvier 2009
    Messages
    467
    Détails du profil
    Informations forums :
    Inscription : Janvier 2009
    Messages : 467
    Points : 1 253
    Points
    1 253
    Billets dans le blog
    2
    Par défaut
    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...

  6. #6
    Membre émérite

    Homme Profil pro
    Software Developer
    Inscrit en
    Mars 2008
    Messages
    1 470
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Royaume-Uni

    Informations professionnelles :
    Activité : Software Developer

    Informations forums :
    Inscription : Mars 2008
    Messages : 1 470
    Points : 2 368
    Points
    2 368
    Par défaut
    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.

  7. #7
    Membre émérite

    Homme Profil pro
    Software Developer
    Inscrit en
    Mars 2008
    Messages
    1 470
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Royaume-Uni

    Informations professionnelles :
    Activité : Software Developer

    Informations forums :
    Inscription : Mars 2008
    Messages : 1 470
    Points : 2 368
    Points
    2 368
    Par défaut
    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.

  8. #8
    Modérateur
    Avatar de al1_24
    Homme Profil pro
    Retraité
    Inscrit en
    Mai 2002
    Messages
    9 080
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 63
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Retraité
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mai 2002
    Messages : 9 080
    Points : 30 778
    Points
    30 778
    Par défaut
    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
    Modérateur Langage SQL
    Règles du forum Langage SQL à lire par tous, N'hésitez pas à consulter les cours SQL
    N'oubliez pas le bouton et pensez aux balises
    [code]
    Si une réponse vous a aidé à résoudre votre problème, n'oubliez pas de voter pour elle en cliquant sur
    Aide-toi et le forum t'aidera : Un problème exposé sans mentionner les tentatives de résolution infructueuses peut laisser supposer que le posteur attend qu'on fasse son travail à sa place... et ne donne pas envie d'y répondre.

  9. #9
    Membre éprouvé

    Inscrit en
    Janvier 2006
    Messages
    969
    Détails du profil
    Informations forums :
    Inscription : Janvier 2006
    Messages : 969
    Points : 958
    Points
    958
    Par défaut
    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.

  10. #10
    Membre expérimenté Avatar de nchal
    Homme Profil pro
    Étudiant
    Inscrit en
    Avril 2012
    Messages
    512
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2012
    Messages : 512
    Points : 1 654
    Points
    1 654
    Par défaut
    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.
    Si la réponse vous convient, un petit ça encourage.
    Avant tout nouveau post, pensez à : la FAQ, Google et la fonction Recherche
    Si vous devez poster, pensez à: Ecrire en français, la balise [CODE] (#) et surtout

  11. #11
    Membre expérimenté

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Avril 2006
    Messages
    450
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Avril 2006
    Messages : 450
    Points : 1 630
    Points
    1 630
    Par défaut
    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 .
    Je ne réponds à aucune question par MP, posez vos questions sur le forum adéquat.
    Profils : G+ - LinkedIn

  12. #12
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    Décembre 2011
    Messages
    1 320
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Analyste Programmeur

    Informations forums :
    Inscription : Décembre 2011
    Messages : 1 320
    Points : 3 740
    Points
    3 740
    Billets dans le blog
    12
    Par défaut
    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.
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Ma page Developpez | Mon profil Linkedin | Vous souhaitez me contacter ? Contacter Gokan EKINCI

  13. #13
    Expert éminent
    Avatar de berceker united
    Profil pro
    SQL
    Inscrit en
    Février 2005
    Messages
    3 487
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : SQL
    Secteur : Finance

    Informations forums :
    Inscription : Février 2005
    Messages : 3 487
    Points : 6 030
    Points
    6 030
    Par défaut
    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é.
    Mon avatar ? Ce n'est rien, c'est juste la tête que je fais lorsque je vois un code complètement frappa dingue !...

  14. #14
    Candidat au Club
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Juin 2012
    Messages
    2
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juin 2012
    Messages : 2
    Points : 2
    Points
    2
    Par défaut
    "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

  15. #15
    Membre régulier
    Profil pro
    Administrateur de base de données
    Inscrit en
    Juillet 2003
    Messages
    94
    Détails du profil
    Informations personnelles :
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Juillet 2003
    Messages : 94
    Points : 116
    Points
    116
    Par défaut
    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

Discussions similaires

  1. Envoyer des données mysql vers Excel
    Par thierry198 dans le forum SQL Procédural
    Réponses: 4
    Dernier message: 09/11/2005, 20h59
  2. exportation de données de mysql vers Oracle
    Par illegalsene dans le forum Oracle
    Réponses: 5
    Dernier message: 26/10/2005, 13h52
  3. Migrations MySQL vers Interbase
    Par M.Dlb dans le forum Migration
    Réponses: 3
    Dernier message: 13/07/2005, 17h30
  4. conversion mysql vers postgresql
    Par backus dans le forum PostgreSQL
    Réponses: 3
    Dernier message: 04/07/2005, 19h42
  5. Migrer de MySQL vers PostgreSQL
    Par Acti dans le forum PostgreSQL
    Réponses: 9
    Dernier message: 25/02/2005, 15h20

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo