Journal F1, la base de données de Google pour remplacer Mysql

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
12
11
juin
2012

Ave

J'ai trouvé un article annonçant que Google a développé un remplaçant pour sa base Shard Mysql.
(shard peut se traduire par tesson ou écharde, je ne sais pas si c'est pertinent dans ce contexte).
http://www.decideo.ca/Google-presente-F1-sa-base-de-donnees-qui-remplace-MySQL_a5243.html

Si vous aimez les architectures visant à une haute disponibilité, continuez à lire.

extrait du PDF
http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en//pubs/archive/38125.pdf

Limitations
● Availability
○ Master / slave replication -> downtime during failover
○ Schema changes -> downtime for table locking
● Scaling
○ Grow by adding shards
○ Rebalancing shards is extremely difficult and risky
○ Therefore, limit size and growth of data stored in database
● Functionality
○ Can't do cross-shard transactions or joins

J'ai bien aimé cet extrait

Five replicas needed for high availability
● Why not three?
○ Assume one datacenter down
○ Then one more machine crash => partial outage

Quand on s'appelle Google (ou une grosse boite avec des moyens, on peut faire ce qui suit)
A new database,
● built from scratch,
● designed to operate at Google scale,
● without compromising on RDBMS features.

par contre je n'ai rien vu sur la licence de ce développement.

  • # Pas disponible

    Posté par  (site web personnel) . Évalué à 7.

    par contre je n'ai rien vu sur la licence de ce développement.

    Je crois que cette base de données n'est tout simplement pas disponible en dehors de Google. Donc, intéressant techniquement, mais à part ça…

    • [^] # Re: Pas disponible

      Posté par  (site web personnel) . Évalué à 4.

      Vu que ça parle de s'appuyer sur les libs et softs internes de Google, je pense comme toi.

      A terme, je pense que ça doit nuire à Google, car le temps d'adaptation des gens est plus grands qu'en utilisant des technos plus standards, et ça coute à maintenir. Et c'est à mon sens pas super attirant d'aller bosser sur des trucs que tu pourras jamais reprendre ailleurs ( mais peut être que c'est un effet de bord positif pour Google, vu que ça incite les gens à rester chez eux ).

      • [^] # Re: Pas disponible

        Posté par  (site web personnel) . Évalué à 2.

        MapReduce est un parfait contre exemple de ce que tu écris. Ça a au contraire impulsé la création d'implémentations libres (Hadoop, etc.).

        • [^] # Re: Pas disponible

          Posté par  (site web personnel) . Évalué à 5.

          AU contraire, ça montre bien ce que je dit à savoir que garder les trucs pour eux nuit un peu à Google. Dans le cas de MapReduce, ils ont justement communiqué autour, et ça leur a bénéficié via la reprise et l'amélioration de l'idée. Mais le retour aurait pu être plus grand en ayant directement fourni le code pour tous, ils auraient plus facilement pu embaucher du monde ou des gens déjà au courant d'une partie des spécificités.

          Mise à part le nombre de gens ( qui n'est pas non plus trivial, je précise ), Google a les mêmes problématiques que d'autres boites classiques du secteur, faire rentrer les gens qu'il faut et ne pas faire rentrer les gens qu'il ne faut pas. Quand tu cherches à embaucher un dev sur un projet particulier, si il est libre, il suffit de piocher dans la communauté ( ce qui entraine d'autres soucis, mais on va mettre ça aussi de coté ). Quand le projet est pas libre, il y a déja plus d'incertitude.

          L'idée ne viens pas de moi, mais d'un ancien employé ( http://rethrick.com/#waving-goodbye ).

          Ensuite, je sais aussi que Google a des problématiques autres, avec un impact sur le télétravail, sur la taille des locaux et la répartition des gens, etc, et je suppose que le choix de garder tout en interne est mesuré.

      • [^] # Re: Pas disponible

        Posté par  . Évalué à 2.

        Vu que ça parle de s'appuyer sur les libs et softs internes de Google, je pense comme toi.

        Oui le problème c'est que si il faut releaser GFS, et Bigtable, et Chubby, etc. ça comment à faire beaucoup…

        http://research.google.com/archive/bigtable.html
        http://research.google.com/archive/gfs.html
        http://research.google.com/archive/chubby.html

        C'est déjà pas mal que ce soit publié, au moins ça permet de savoir ce qui marche.

  • # Shard

    Posté par  (site web personnel) . Évalué à 3.

    (shard peut se traduire par tesson ou écharde, je ne sais pas si c'est pertinent dans ce contexte).

    A database shard is a horizontal partition in a database or search engine. Each individual partition is referred to as a shard or database shard.
    (source http://en.wikipedia.org/wiki/Sharding )

    Je dirais un morceau, une brisure, une partie du tout que l'on a « cassé ».

    • [^] # Re: Shard

      Posté par  . Évalué à 5.

      Un « éclat » peut-être ?

  • # Faille\W Fonctionnalité Mot de Passe Perdu

    Posté par  . Évalué à 7.

    Dommage,
    Dans MySQL il y a une super fonctionnalité permettant de retrouver son mdp root quand on l'a perdu : http://thehackernews.com/2012/06/cve-2012-2122-serious-mysql.html

    • [^] # Re: Faille\W Fonctionnalité Mot de Passe Perdu

      Posté par  (site web personnel, Mastodon) . Évalué à 1.

      Bien tenté mais en pratique le bug n'est pas exploitable avec la glibc normale ni avec la libc de BSD. La seule possibilité d'exploit est avec la glibc compilée pour SSE.

      « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

      • [^] # Re: Faille\W Fonctionnalité Mot de Passe Perdu

        Posté par  . Évalué à 2. Dernière modification le 12 juin 2012 à 09:55.

        J'arrive à reproduire le bug sur plusieurs de mes machines et certains de mes clients arrivent également à le reproduire sur des serveurs en prod.

        Le bug est également exploitable en PHP, y compris avec phpMyAdmin ou nous avons pu rentrer en root sur certains serveurs de cette manière. (Serveurs à base de Debian, installation de base x64, ou custo OVH, principalement).

        Donc si il est clairement exploitable. (Bien entendu je ne donnerais pas les noms de mes clients …)

      • [^] # Re: Faille\W Fonctionnalité Mot de Passe Perdu

        Posté par  . Évalué à 5.

        Ce n'est pas la norme de fait les glibc compilée pour SSE ?

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.