Google maakt interne protocollen voor data-uitwisseling opensource

Google heeft enkele interne protocollen voor het uitwisselen van verschillende typen gestructureerde data opensource gemaakt. Het bedrijf hoopt dat anderen de technologie ook gaan gebruiken.

Google gebruikt intern duizenden verschillende soorten dataformats voor het uitwisselen van gegevens tussen onder andere servers, indexrecords in repositories en datasets die op verschillende geografische locaties zijn opgeslagen. De meeste van deze data wordt in gestructureerde vorm aangeboden en is dus geen platte tekst, aldus Kenton Varda, die als software-engineer bij Google werkt.

Xml zou als bestandsformaat een oplossing kunnen bieden, maar doet dat niet omdat deze bestanden te groot zouden zijn. Het verwerken kost daardoor te veel tijd en rekenkracht. Google heeft daarom een eigen interface description language ontwikkeld die de informatiegigant protocol buffers noemt.

Door protocol buffers te gebruiken hoeft slechts eenmaal te worden gedefinieerd hoe de data is gestructureerd. Met behulp van enkele meegeleverde classes kan de gecomprimeerde, gestructureerde data worden ingelezen en weggeschreven naar verschillende datastreams. Volgens Google zijn de nieuwe databestanden gemiddeld drie tot tien keer kleiner dan xml-bestanden en worden ze twintig tot honderd keer sneller verwerkt.

Google zegt de komende maanden meer van zijn interne software opensource te maken. Omdat nagenoeg al die software gebruik maakt van de protocol buffers heeft Google besloten deze als eerste vrij te geven. Welke software volgt en wanneer dat is, heeft het bedrijf niet bekendgemaakt. Wie met de nu reeds vrijgegeven software aan de slag wil kan zich uitleven op de betreffende projectpagina.

Reacties (32)

[Jeanpaul145]

Geweldig initiatief van google.

Ik ben bezig met een paar kleine prive projectjes die vroeg of laat networked gaan worden, en ik zie mezelf dit echt wel gebruiken i.p.v. iets als XML.

Trouwens, met xml is het geloof ik mogelijk om user interfaces te definieren (bijvoorbeeld bij google Android programma's, en MS heeft geloof ik ook wel wat gedaan met een XML afgeleide die XAML heet ofzo). Zijn deze protocol buffers eventueel ook zo te gebruiken, of zijn ze echt een gespecialiseerd stukje software voor dataoverdracht?

@CyBeRSPiN: Het is jouw soort manier van denken (die bij veels te veel app devvers aanwezig is trouwens) die ervoor zorgt dat hedendaagse computers nog last kunnen krijgen van 100% cpu gebruik wanneer dit niet nodig is (enkele inherent cpu-intensieve taken zoals audio encoding daargelaten, dan krijg je makkelijk je cpu aan t zweten).

Mijn projecten wil ik vroeg of laat open-source maken, wat inhoudt dat als ik wil dat het vaak gebruikt wordt door anderen, dat het van hoge kwaliteit moet zijn, Daarnaast, dit systeem ziet er niet echt moeilijker uit om te gebruiken dan de XML api's, dus is het niet alsof ik het mezelf onnodig moeilijk maak ofzo.

[Reactie gewijzigd door Jeanpaul145 op 25 juli 2024 09:18]

[Verwijderd]

Misschien wel, maar het is niet handig volgens dit stukje tekst:

(...) However, protocol buffers are not always a better solution than XML – for instance, protocol buffers would not be a good way to model a text-based document with markup (e.g. HTML), since you cannot easily interleave structure with text. In addition, XML is human-readable and human-editable; protocol buffers, at least in their native format, are not. XML is also – to some extent – self-describing. A protocol buffer is only meaningful if you have the message definition (the .proto file).

Daarnaast wordt, als ik het goed begrijp, gebruik gemaakt van een gecompileerde klasse, die de gebruikers van de data vervolgens kunnen aanspreken (ie, je hebt een stroom data, je maakt een instance van die klasse en leest data in die instantie en vervolgens haal je gegevens die je nodig hebt eruit).

Het is in ieder geval bedacht voor efficiente dataoverdracht (grote files lokaal zijn een stuk minder problematisch, zo ook die paar extra clock cycles, lijkt me).

[OddesE]

Trouwens, met xml is het geloof ik mogelijk om user interfaces te definieren (bijvoorbeeld bij google Android programma's, en MS heeft geloof ik ook wel wat gedaan met een XML afgeleide die XAML heeft ofzo)

Met XML is het mogelijk om *alles* te definiëren wat je maar kunt bedenken. XML, eXtensible Markup Language, is een meta-formaat. Een formaat om formaten te definiëren. Het mooie is dat, doordat het meta-formaat standaard is, standaard parsers gebruikt kunnen worden die dan het schema of de DTD lezen en gebruiken om het document te valideren. Bijvoorbeeld door te melden dat een verplichte tag niet aanwezig is. Maar XML zelf is eigenlijk een hele kleine standaard die verbazingwekkend weinig eisen stelt. Daarom is de vergelijking met JSON ook zo flauw, want als je het allersimpelste XML document bekijkt:

<a></a>

Dan kun je toch ook niet zeggen dat dat erg lang is of zo.
Het eerdere voorbeeld dat ik gaf in JSON zou er in XML zo uit kunnen zien:

<person name="Frank" age="35"></person>

is nou toch ook weer niet schokkend veel langer. Pas als je een DTD gaat toevoegen en het document gaat transformeren met XSLT e.d. wordt het veel ingewikkelder dan JSON, maar dan ben je ook features aan het gebruiken die JSON gewoon niet heeft.

[Cameleon73]

Voor interne data-uitwisseling is JSON ook een mooi alternatief (en een stuk lichter dan XML).

Voor grote hoeveelheden data-uitwisseling is de opzet van Google absoluut beter. Eenmalig de structuur bepalen, en dan uitwisselen maar. Deze pagina geeft een goed overzicht.

[OddesE]

Wat bedoel je met interne data uitwisseling? Voor zover ik het zie is JSON vooral handig als je data naar een web applicatie stuurt die op de client weer verwerkt moet worden. JSON is dan prachtig want het parsen is één statement:

// Create JSON document
var json = "{ "name" : "Frank", "age" : 35 }";
// Parse JSON document
var data = eval("(" + json + ")");
// Use data
alert(data.name + " is " + data.age + " years old!"); // alerts "Frank is 35 years old!"

Prachtig natuurlijk, maar wat je eraan hebt als je data naar iets anders als een webclient wil sturen ontgaat me... Ok het is korter, maar verder. Als je echt megabytes aan data moet versturen kan het wel flink schelen, maar dan is versturen als tekst waarschijnlijk sowieso een slechte keus. Je moet dan een mooi binary formaatje verzinnen / van de plank trekken lijkt me.

[Darkvater]

Dus Google stuurt een header met de structuur en daarna gewoon binaire data. Is dit nou zo spectaculair? Ik snapte het hele XML heisa zowiezo al niet...

[Tjeerd]

Op zich is het ook niet erg spectaculair. Eigenlijk hebben ze een stuk gereedschap geschreven om die zogenaamde .proto-bestanden om te zetten in C++/Java/Python structuren/klassen. Je zou het zelf ook prima i.p.v. in een .proto zetten, het in een XML-bestand zetten, de definities dan, en die dan laten "compileren" naar C++/Java/Python.

Het enige nuttige is dat het kleiner is en dus ook sneller te verwerken.

XML op zich is weer een heel ander verhaal en biedt een hele hoop andere voordelen, die dit .proto niet oplost. Zeker niet i.c.m. XSLT en/of complexere XML-mogelijkheden, die .proto volgens mij niet heeft. XML is ook maar "een" manier om te proberen data uitwisselbaar te maken tussen elk platform, alleen omdat het natuurlijk tekst is en redelijk leesbaar wordt het een stuk trager. Wil je grote hoeveelheden data overpompen, dan moet je gewoon verwijzingen binnen je XML-bestand hebben naar losse binaire bestanden bijvoorbeeld.

Verder wordt XML erg veel gebruikt in de ontologienwereld, waar het best mooi voor te gebruiken is.

[Reactie gewijzigd door Tjeerd op 25 juli 2024 09:18]

[engelbertus]

volgens mij sturen ze geen header, ze sturen de gevraagde data, in het gevraagde formaat. het is denk ik juist de structuur van het formaat dat is vastgekegd in de applicaties, die de google data structuren gebruiken... de data zelf kan volgens mij gewoon in een database staan, waarbij de structuur van die database niet uitmaakt.

stel je zoiets voor dat googlke een gigantische database heeft die alle gegevens over websites bijhoud. dan stuurt je applicatie bijvoorbeeld "ik wil de zoekresultaten voor deze termen" en dan krijg je ze vervolgens direct op zon manier toegestuurd dat je de data meteen in een tabel kunt zetten, zonder dat je bijvoorbeeld eerst de hele berg antwoorden hoeft binnen te hebben, om vervolgens weer de binnengekrgeen data weer te geven in een tabel, ofbijvoorbeeld gaan wachten op resultaat nummer 200 en die als enige weergeven.

je applicatie kan ook vragen om de statistieken van een domein, of statistieken van gebruikers. je hoeft dus niet op te geven dat je alle record wilt van een webiste, waarbij je weer moet opgeven welke velden je wilt. je applicatie kan dan (mogelijk) ook zonder verdere specificatie een tabel maken, zonder dat weer in elke pagina te moeten programeren ( het is dan een class oid. maar dan een class in de applicatie, gerelateerd aan het opgevraagde formaat.
automatisch zonder dat je zelf in je code hoeft op te geven welke tabel, welke gegevens en welke velden je op welke manier wilt combineren, daar heeft google dan zelf al enkele honderden combinaties van voorgedifinieerd, zowel aan de client als aan de server kant. zodat zeg maar ALLE overhead er uit is.dus ook geen headers die meer specificeren dan het streamtype dat gevraagd is.

ik denk dus dat dit ook ten dele de sql code vervangt die aangeeft welke data je in verschillede velden in ej tabel wilt hebben. dat is dus iets meer dan alleen een header die helemaal uitspecificeert welke data er gaat komen. het wordt dus echt een stream en geen heel bestand waar je op moet wachten.

de vergelijking met xml en het commentaar daarop vind ik niet echt ontopic, en ook niet op zijn plaats. xml is zonbeetje het tegenovergestelde van de google streams als je het mij vraagt. de streams ligt alles in vast behalve de inhoud, bij xml is dat gecombineerd, en ligt de inhoud niet vast, maar ook het type inhoud is eigenlijk vrij. xml bevat juist alle data, ook die die niet in een tabel zal worden getoond in je applicatie, en data die hij niet kent wordt genegeerd. voegt een nieuwe versie van een applicatie een type toe dan kan dat on the fly, geen enkele applicatie zal er van in de war raken. dat het "formaat" van het bestand opeens extra velden en tags kent.
bij een stream van google is dan meteen de stream corrupt. er zijn imemers geen tags, en de data is opeens te lang, tekort of wat dan ook, om afgehandeld te worden.

verder kun je xml wel compimeren, omdat de xml tags zich natuurlijk uitermate goed laten comprimeren, en omdat er in feite geen lege velden in voorkomen.

[Verwijderd]

tja ik zou ook geen XML willen gebruiken voor zoiets, als je echt performance wilt moet je geen xml gebruiken. Het feit dat het human readable moet zijn kost je zoveeel performance ten opzichte van andere formaten. Perfect als uitwisselingsformaat maar voor binnen je applicatie is het eigenlijk altijd teveel overhead.

[jealma]

XML is ook zwaar overrated imho. Met webdesign is het tegenwoordig allemaal XML dit en XML dat, maar feit blijft dat het een lomp formaat is, waarbij er 2/3 van de ruimte gebruikt wordt voor tags om de indeling te defineren. Dan nog liever csv.

[Milt]

Je hebt duidelijk nog niet voldoende XML gebruikt om de voordelen ervan te zien. Een groot voordeel van XML is dat iedereen het kan lezen. Bij CSV bestanden moet je afspraken maken of je fixed of variable length velden gebruikt, welk scheidingsteken, escaping, encoding, etc... Daar moet je bij iedere partij waarmee je data uitwisselt afspraken over maken. Bij XML niet want dit ligt vast in de definitie van XML.

Daarnaast, en dat vind ik persoonlijk een belangrijk plus punt, biedt XML de mogelijkheid om nieuwe gegevens toe te voegen aan bestanden zonder dat je daarmee oude applicaties in de weg zit. Die applicaties kennen de betekenis van deze nieuwe gegevens (tags) niet en negeren deze (als ze goed geschreven zijn). Ook een pluspunt van XML t.o.v. CSV is dat het in XML heel eenvoudig is om records van variabele lengte te maken. Of bijvoorbeeld records met 1 of meerdere child records.

De overhead kan je beperken door korte(re) tags te gebruiken. Dat is je eigen keuze. XML vind ik een perfect formaat voor platform onafhankelijke data uitwisseling. Voor grote hoeveelheden data opslag vind ik het minder geschikt.

[jj71]

Om je eigen woorden tegen je te gebruiken: En jij hebt duidelijk nog niet voldoende XML gebruikt om de nadelen ervan te zien.

In de wereld van software ontwikkeling (ik ben Java ontwikkelaar) werd tot een paar jaar geleden heel veel XML gebruikt. Kijk bijvoorbeeld naar het Spring framework, waarin je heel veel en ingewikkelde XML bestanden moest schrijven om onderdelen van je applicatie aan elkaar te knopen. De software werd daar absoluut niet overzichtelijker van.

In Java-land is de laatste twee jaar heel veel van die XML vervangen door andere, gemakkelijker te gebruiken en eenvoudigere mechanismen, zoals annotations (in de source code).

Ook in AJAX webapplicaties is JSON (JavaScript Object Notation) tegenwoordig veel populairder dan XML, omdat het veel makkelijker te lezen is voor mensen en omdat het in JavaScript gemakkelijk en snel te parsen is.

De voordelen die je boven noemt van XML hebben JSON en andere formaten ook.

[OddesE]

Ok, maar... Het Spring framework was een goed voorbeeld van *foutief* gebruik van XML. Er was een tijdje een XML-hype en toen moest ineens alles in XML. Dat ontwikkelaars toen helemaal los ermee gegaan zijn is vervelend, maar ligt niet per sé aan XML.

JSON is in feite gewoon de literal Javascript object notatie, die wat meer geformaliseerd is en zijn eigen naampje heeft gekregen. Net zoals Javascript zelf is JSON in feite helemaal dynamisch. Als ik zeg dat iets wordt aangeboden in JSON dan kun jij eigenlijk niet weten wat er in komt te staan, alleen dat er een open brace komt, gevolgd door wat name-value pairs en een close brace, waarbij elke value een untyped 'primitive' kan zijn, een array of een genest object. Daarmee lijkt JSOn meer op CSV dan op XML.

XML biedt toch heel wat meer dan dat. D.m.v. een DTD of schema kun je heel of iets minder precies specificeren welke informatie je kunt gaan verwachten. Verder kent XML bijvoorbeeld namespaces, zodat als wij allebei een XML formaat bedacht hebben met een tag 'person' er in, we die tags toch kunnen combineren in één enkel document. En dan heb je natuurlijk nog XSLT, waarmee je een XML document kunt transformeren naar een ander (evt. XML) document. Die zaken bestaan voor JSON niet. En als je ze erbij maakt, wat ben je dan eigenlijk aan het doen, anders dan XML nabouwen?

Verder is XML gewoon een goed uitgewerkte standaard (goed uitgewerkt as in compleet) met standaard parsers beschikbaar in zowat elke taal, met low-level support in bijvoorbeeld browsers en databases, met een complete expressietaal (XPath) om elementen te vinden etc. Zulke dingen bestaan voor JSON niet.

Als iemand een hamer gebruikt om soep te eten dan geef je toch ook niet de hamer de schuld? XML is een stuk gereedschap en elk stuk gereedschap kan verkeerd gebruikt worden.

Overigens hoor ik altijd dat XML te verbose is, maar er bestaan verscheidene dialecten van XML die structureel hetzelfde zijn maar syntactisch anders (korter). Die kun je dan echter wel van en naar XML converteren, zodat je weer met een standaard parser kunt inlezen.

Ook zijn er voor XML libraries waarmee je XML streams kunt verwerken (SAX), maar ook zoiets ken ik voor JSON niet. XML is een tool. Leer het gebruiken en pas het toe als dit het makkelijkst is op dat moment of in die situatie. Als iets anders makkelijker is, gebruik dat dan gewoon. Dat het springframework zelfs XML gebruikt om instanties van objecten aan te maken is hún schuld, niet die van XML.

* OddesE loves JSON, but doesn't hate XML

[CyBeRSPiN]

XML is er sowieso niet omdat het "human readable moet zijn", maar eerder omdat je XML documenten kunt valideren zonder de semantiek ervan te kennen.

[Voutloos]

Dan nog is veel van de overhead te danken aan het human readable zijn, ook al was dat laatste officieel niet het doel van xml.

[Verwijderd]

Is ook niet erg prettig te lezen. De meest treffende die ik ben tegengekomen: "XML is pleasing to the eye as a fork drenched in lemon juice"

[YopY]

Als dat waar was konden ze wel een veel kleiner formaat gebruiken, iets waar geen < en > tekens (maal 2) + een naam voor elk stukje gegevens voor nodig zou zijn. Het valt wel op dat veel XML documenten vaak meer ruimte innemen voor de tags dan voor de daadwerkelijke data.

[humbug]

Tsja, wat is echte "performance" Google zit op een iets ander niveau dan de meeste bedrijven maar wij handelen iets van 1500 soap requests per seconde af op 1 server. Lijkt me voor de meeste bedrijven meer dan genoeg.

Edit: ach, vrij standaard HP Blade server. De database die erachter hangt is wel redelijk zwaar maar de front end servers kosten in verhouding eigenlijk "niets".

[Reactie gewijzigd door humbug op 25 juli 2024 09:18]

[freaky]

Tsja, je had dat dus wellicht met heel wat goedkopere hardware voor elkaar kunnen krijgen

[arjankoole]

ik heb genoeg oplossingen gebouwd die een jaar later met heel wat goedkopere hardware opgelost hadden kunnen worden. Simpelweg omdat op dat moment de technische mogelijkheden er nog niet waren om het eenvoudiger te doen, of omdat de hardware prijzen in de tussentijd dalen.

een oplossing die nu gebouwd moet worden, moet nu gebouwd worden he?

[mr.zeno]

Wat voor technologieën worden hiervoor gebruikt? (J2EE, .NET?, .. ?)

[Rob Coops]

Toch best leuk dat google ons weer een beetje verder laat kijken in hun keuken. Het is opzich geen spectaculaire uitvinding van google om gewoon eerst wat format informatie over te sturen en vervolgens alle data alleen binnen die structuur te versturen het scheelt een hoop ruimte en ik denk dat ze ook vast wel wat compressie to passen voor ze de data ook echt over sturen.

Natuurlijk zullen ze geen XML gebruiken het is veel te omslachtig om te parsen en zelfs de opbouw kost vaak meer tijd dan noodzakelijk is.

Ik denk eigenlijk dat Google gewoon probeert meer talent aan hun projecten te laten werken maar nu zonder ze te moeten betalen. Het is natuurlijk veel goedkoper om de ontwikkeling van het bedrijf op deze manier voort te zetten. En als er nu iemand in de ontwikkel community rond deze software erg goed blijkt te zijn dan kan google hem/haar altijd nog een baan aanbieden.

[Verwijderd]

Geinig dat ze _code.google.com_ gebruiken om dit te managen. Logisch ook wel. Zou dit intern ook worden gebruikt voor ontwikkeling?

[Floor]

Goede zaak lijkt me. Gezien de massa aan data die Google moet verwerken is dit erg prettig voor de hele keten maar ook voor niet Google gerelateerde data uitwisseling kan dit positief zijn. Het is namelijk af en toe erg bizar wat voor bestanden je ongecomprimeerd moet klaar zetten, terwijl ze gecomprimeerd een fractie van de groote zijn.
Grote jongens zoals Google kunnen hier een voortrekkersrol in spelen.

[bulle bas]

Dit is net iets voor Haskell, en ja hoor, de eerste port is al weer gemaakt: http://hackage.haskell.or...ge/protocol-buffers-0.0.2

[PHiXioN]

Google heeft als bedrijf enorm goed begrepen dat de meerwaarde van het bedrijf niet moet zitten in 'verborgen' informatie en dat gesloten strategieën alleen maar belemmerend werken in een wereld waarin veel zaken te complex zijn geworden om het binnenshuis te managen én de kwaliteit hoog te houden.

[mocean]

Nou, volgens mij is Google een kei in informatie binnen houden! Heel het succes van hun zoekmachine-technologie bijvoorbeeld. Of PageRank. De uitwisselingsprotocollen zijn natuurlijk interessant. Maar ik denk dat ze hun zoekmachine-strategie/algoritmes toch echt geheim zullen houden.

[PHiXioN]

Het precieze recept van de kok zullen ze niet vrijgeven, maar al het keukengerei is beschikbaar ter inzage. Een bedrijf als Microsoft is net een gaarkeuken met de deur op slot. Dan is het maar afwachten wat je voorgeschoteld krijgt. Wellicht werken ze daar met verroeste pannen in een magnetron (lees: slordig programmeerwerk) in plaats van kwalitatief hoogstaand keukengerei. Een goede kok hoeft niet angstvallig zijn keuken dicht te houden om nog klanten binnen te blijven halen. Sterker nog, het doet je afvragen waarom de deur dicht is. Tevens staat het openbaarmaken van je keukengerei toe dat anderen er wellicht nieuwe toepassingen voor vinden.

[Wim-Bart]

Leuk dat ze dat doen, maar beetje raar dat ze dat nu pas doen, hadden ze zelf niet een snauw naar MS gegeven over dit soort eigen oplossingen.........

Maar dit principe bestond al heel lang, een niet erg nieuwe technologie. Wij noemden dit vroeger gewoon communicatie aan de hand van protocol description files. Gewoon binaire pakketjes waarin een protocol id staat en een bijbehorende description file die bepaalde hoe het er uit ziet. Verder een broker die weet waar een pakketje naar toe moest om het te verwerken. Is techologie wat we al gebruikten op systemen als PDP11, IBM PC en andere oude systemen, pure code geschreven in C, Pascal, Clipper etc. etc.

[Verwijderd]

Leuk dat ze dat doen, maar beetje raar dat ze dat nu pas doen, hadden ze zelf niet een snauw naar MS gegeven over dit soort eigen oplossingen.........

Dit commentaar gaat niet op: het wordt gebruikt om informatie tussen google's eigen servers uit te wisselen, daar heeft microsoft of een andere concurrent er niets mee te maken. Ze presenteren 'gewoon' een protocol dat ze zelf ontwikkeld hebben om de servers efficient met elkaar te laten praten.

[m_snel]

Geweldig dat ze duizendem formaten gebruiken om gegevens uit te wisselen, maar is het niet handiger om gewoon het aantal formaten te beperken en alleen gebruik te maken van efficiente formaten.

Ze ontwikkelen toch bijna alles zelf?

Wat ik niet begrijp is dat zoiets als html (en xml) een standaard is geworden om over het web te verspreiden, zo efficient is lijkt het me nou ook niet.

Volgens mij heeft heeft de hele internet gemeenschap iets gemist, ik kan me nog herinneren dat ik wel eens log files (ongeveer 4GB) van een Netscape server moest opslaan op een diskette. Als je deze bestanden comprimeerde paste het echt op een 1.44MB floppy en dat was nog in de tijd dat Netscape iets betekende)