Protocol Buffers : le format de données de Google est ouvert

Le par  |  13 commentaire(s) Source : Google OpenSource
Google Code

Google ouvre à nouveau un de ses outils utilisé en interne : Protocol Buffers. Sous ce nom se cache rien de moins que la langage mis au point et utilisé par Google pour l'échange et l'indexation d'Internet par le moteur de recherche. Un langage simple, compilé en classes Java, C++ et Python, avec des performances 20 à 100 supérieures au XML : voilà ce que propose Google avec PB.

Google CodeGoogle continue de tendre la main vers le Libre. Si récemment, nous vous parlions du Google Summer Of Code 2008, regroupant toujours plus de participants financés par la firme de Mountain View, nous avions également évoqué le cas de RatProxy, un outil développé en interne et publié sous la permissive licence Apache.

C'est à nouveau un outil interne qui est aujourd'hui publié par Google, et c'est toujours la licence Apache qui a été choisie. Troisième point commun avec RatProxy : il s'agit d'un outil destiné avant tout aux développeurs. Néanmoins, la portée est potentiellement très importante. Google propose son Protocol Buffers, un format de données présenté comme une alternative au standard XML. Ce dernier est aujourd'hui très utilisé et ce, dans presque tous les domaines (échange de données,  balisage, formats de documents comme OpenDocument, SVG, MathML et même langages dérivés...) et Google n'entend pas forcément le remplacer mais proposer une solution plus adaptée à l'échange de gros volumes de données.


Des données compilées pour des performances élevées
Le code est présenté comme simple à utiliser et à mettre en place. Google annonce une compacité de 3 à 10 fois supérieure à celle du XML, et surtout un langage de 20 à 100 plus rapide. La société fournit des outils pour compiler des données générées dans le format Protocol Buffers en classes Java, C++ et Python. Une bibliothèque est proposée pour les traitements les plus courants : parcours des données, transmission de messages... Notons également qu'il est possible de convertir du PB vers du XML ou du JSON et inversement.

L'outil semble mâture, puisqu'il est utilisé en interne par Google pour organiser ses données, notamment celles qu'il indexe. Des exemples et explications détaillées sont disponibles sur le site du projet. Si la solution est très alléchante, il est encore très tôt pour prédire ses possibles retombées.
Complément d'information

Vos commentaires Page 1 / 2

Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Le #275311
omg, it seems to be awsome !!
Le #275481
et comparé au JSON il est "combien" plus rapide?
Le #275501
Si j'en crois ce bon vieux Wikipedia ( http://fr.wikipedia.org/wiki/Json#Performances ), JSON serait aussi performant que XML en évaluation mais plus long en parsage.
Chose confirmée par ce petit test ( http://www.crossedconnections.org/w/index.php/samples/?p=112 ).

Donc Protocol Buffers devrait être beaucoup plus rapide que JSON.
Le #275561
Hein ?

Là, j'ais vraiment du mal à comprendre... Un format n'a pas une quelquonque "rapidité" en lui meme, c'est juste les différents "parseurs" ou generateurs qui sont plus ou moins rapide selon ce qu'on leur demande et leur différentes optimisations...

Si quelqu'un pouvais m'expliquais... Il y a sans doute une info que j'ais mal interprétée.
Le #275621
Je pense que tu as plus ou moins deviné Luchy : certains formats sont plus ou moins rapides (faciles) à parser pour une même information.
Le #275631
Oui mais il n'y a pas qu'un parseur / generateur dans le monde... Que ça soit pour du XML ou du JSON donc sur quoi on se base pour sortir ça ?
Le #275671
Tu prends les meilleurs parseurs pour ces formats et tu t'aperçois que tu obtiens de meilleures perfs avec l'un des 2 formats.
Mais derrière ça, ya une vrai raison. Je ne suis pas expert dans le domaine donc je rentre pas dans les détails volontairement pour éviter de dire des conneries. Mais si tu prends un format strict, un format sensible à la casse par exemple, tu vas gagner en perf (car t'as pas à traiter le cas majuscule/minuscule). Ce n'est qu'un exemple.
Le #275711
@Luchy:

En théorie, oui, un format n'est pas "rapide" ou pas, c'est le parseur qui l'est (ou pas.

Maintenant, suivant comment le format est pensé, ses fonctionnalités, ... certaines optimisations sont possibles, ou au conrtaire, certaines fonctionnalités ne pourrnot etre rapide de par la conception du format.

Au final, le format influe sur le fait que ça soit raipde ou pas à le lire, la programmation du parseur ne fait pas tout.

Même un parseur très optimisé, si le format est bencal ou très complexes, tu n'aurais pas d'aussi bonnes performances qu'avec un format très basique, même sans optimisation du parseur..


Le #276011
Oui mais un format peut servir à x choses et du fait qu'il soit optimisé plus pour une chose qu'une autre, ne fait de lui le "meilleur" que dans certains cas et le plus mauvais dans d'autres. Au plus je m'attarde sur le sujet, au plus j'ai l'impression que c'est de la com
Le #276961
@Luchy
+1
l'article mélange les langages et les formats d'échange donnée

donc les comparaison de vitesse entre les formats ca me fait bien rire

@Maxime81
un avi ca va plus vite qu'un doc ou qu'un zip ??

(je sais j'exagère mais c'est pour schématiser)

en général tu choisit un format selon ce que tu va faire et des APIs que tu a à disposition pour le traiter

par exemple je ne sais pas si il y a des APIs javascript pour le Protocol Buffer alors que ca existe pour JSON



Suivre les commentaires
Poster un commentaire
Anonyme
:) ;) :D ^^ 8) :| :lol: :p :-/ :o :w00t: :roll: :( :cry: :facepalm:
:andy: :annoyed: :bandit: :alien: :ninja: :agent: :doh: :@ :sick: :kiss: :love: :sleep: :whistle: =]