Publicité
+ Répondre à la discussion Actualité déjà publiée
Affichage des résultats 1 à 15 sur 15
  1. #1
    Responsable Actualités

    Avatar de Hinault Romaric
    Homme Profil pro Hinault Romaric
    Consultant
    Inscrit en
    janvier 2007
    Messages
    3 923
    Détails du profil
    Informations personnelles :
    Nom : Homme Hinault Romaric
    Localisation : Cameroun

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

    Informations forums :
    Inscription : janvier 2007
    Messages : 3 923
    Points : 57 773
    Points
    57 773

    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 ?
    Si déboguer est l’art de corriger les bugs, alors programmer est l’art d’en faire
    Mon blog Mes articles
    En posant correctement votre problème, on trouve la moitié de la solution

  2. #2
    Membre chevronné Avatar de nchal
    Homme Profil pro Nicolas Challut
    Étudiant
    Inscrit en
    avril 2012
    Messages
    305
    Détails du profil
    Informations personnelles :
    Nom : Homme Nicolas Challut
    Âge : 21
    Localisation : France, Haute Savoie (Rhône Alpes)

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

    Informations forums :
    Inscription : avril 2012
    Messages : 305
    Points : 799
    Points
    799

    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 chevronné
    Inscrit en
    décembre 2004
    Messages
    431
    Détails du profil
    Informations forums :
    Inscription : décembre 2004
    Messages : 431
    Points : 607
    Points
    607

    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
    Candidat au titre de Membre du Club
    Profil pro manuel briot
    Inscrit en
    octobre 2010
    Messages
    90
    Détails du profil
    Informations personnelles :
    Nom : manuel briot

    Informations forums :
    Inscription : octobre 2010
    Messages : 90
    Points : 14
    Points
    14

    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 Expert

    Inscrit en
    janvier 2009
    Messages
    464
    Détails du profil
    Informations forums :
    Inscription : janvier 2009
    Messages : 464
    Points : 1 178
    Points
    1 178

    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 Expert

    Homme Profil pro Gilles Vino
    Software Developer
    Inscrit en
    mars 2008
    Messages
    1 474
    Détails du profil
    Informations personnelles :
    Nom : Homme Gilles Vino
    Localisation : Royaume-Uni

    Informations professionnelles :
    Activité : Software Developer

    Informations forums :
    Inscription : mars 2008
    Messages : 1 474
    Points : 2 372
    Points
    2 372

    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 Expert

    Homme Profil pro Gilles Vino
    Software Developer
    Inscrit en
    mars 2008
    Messages
    1 474
    Détails du profil
    Informations personnelles :
    Nom : Homme Gilles Vino
    Localisation : Royaume-Uni

    Informations professionnelles :
    Activité : Software Developer

    Informations forums :
    Inscription : mars 2008
    Messages : 1 474
    Points : 2 372
    Points
    2 372

    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 Alain
    Ingénieur d'études décisionnel
    Inscrit en
    mai 2002
    Messages
    5 631
    Détails du profil
    Informations personnelles :
    Nom : Homme Alain
    Âge : 53
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur d'études décisionnel
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 5 631
    Points : 13 759
    Points
    13 759

    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 émérite
    Inscrit en
    janvier 2006
    Messages
    967
    Détails du profil
    Informations forums :
    Inscription : janvier 2006
    Messages : 967
    Points : 890
    Points
    890

    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 chevronné Avatar de nchal
    Homme Profil pro Nicolas Challut
    Étudiant
    Inscrit en
    avril 2012
    Messages
    305
    Détails du profil
    Informations personnelles :
    Nom : Homme Nicolas Challut
    Âge : 21
    Localisation : France, Haute Savoie (Rhône Alpes)

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

    Informations forums :
    Inscription : avril 2012
    Messages : 305
    Points : 799
    Points
    799

    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 Expert

    Homme Profil pro Julian Ibarz
    Ingénieur développement logiciels
    Inscrit en
    avril 2006
    Messages
    450
    Détails du profil
    Informations personnelles :
    Nom : Homme Julian Ibarz
    Âge : 28
    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 588
    Points
    1 588

    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
    Membre Expert Avatar de Gugelhupf
    Homme Profil pro
    Développeur informatique
    Inscrit en
    décembre 2011
    Messages
    607
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : décembre 2011
    Messages : 607
    Points : 1 041
    Points
    1 041

    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.

  13. #13
    Expert Confirmé Sénior
    Avatar de berceker united
    Profil pro
    Développeur informatique
    Inscrit en
    février 2005
    Messages
    3 159
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : février 2005
    Messages : 3 159
    Points : 4 360
    Points
    4 360

    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
    Invité de passage
    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 habitué
    Inscrit en
    juillet 2003
    Messages
    93
    Détails du profil
    Informations forums :
    Inscription : juillet 2003
    Messages : 93
    Points : 113
    Points
    113

    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

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •