Protokolbuffere

Protocol Buffers  er en struktureret dataserialiseringsprotokol ( overførsel ) foreslået af Google som et effektivt binært alternativ til XML -tekstformatet . Udviklerne rapporterer, at protokolbuffere er enklere, mindre og hurtigere end XML , da de overfører binære data, der er optimeret til den mindste beskedstørrelse [2] .

Generel information

Som udviklerne har udtænkt, skal datastrukturen først beskrives, som derefter kompileres i klasser. Sammen med klasserne kommer kode til at serialisere dem i et kompakt repræsentationsformat. Læsning og skrivning af data er tilgængelig i programmeringssprog på højt niveau som Java , C++ eller Python .

I 2010 skiftede Twitter -backend til Protocol Buffers. Ifølge udviklerne af Twitter ville en database med en billion tweets i XML fylde ti petabyte i stedet for én. [3]

Ifølge Google , protokolbuffere vs. XML : [2]

• lettere;
• 3 til 10 gange mindre;
• 20 til 100 gange hurtigere;
• mere entydig;
• giver dig mulighed for at oprette klasser, der er nemmere at bruge programmatisk senere.

Protokolbuffere er ikke beregnet til at blive læst af brugeren og er i binært format. For at deserialisere data skal du bruge en separat .proto -fil, der definerer meddelelsesformatet.

Protokolformat

Generelt er formatet en kodet sekvens af felter, der består af en nøgle og en værdi. Nøglen er det nummer, der er defineret for hvert meddelelsesfelt i protofilen. Hvert felt er indledt med et fælles kodet varintfeltnummer og felttype. Hvis typen er en streng ( string), en vedhæftet meddelelse, en gentagende meddelelse eller et sæt bytes ( bytes), så følger størrelsen af ​​dataene i varint-format. Dernæst kommer værdien svarende til feltet (data) [4] .

Et tal i varintformat ( int32og int64) er kodet til en sekvens af bytes, hvor alle undtagen de sidste bytes har den mest signifikante bit ( MSB ) sat til 1. Når den konverteres til standardrepræsentation, kasseres den mest signifikante bit af hver byte, og de resterende 7-bit komponenter er forbundet med hinanden, den anden i omvendt rækkefølge [4] . 8-bit varint-formatet blev valgt for at reducere pakkestørrelsen ved transmission af små tal. Så hvis tallet er mindre end 128, tager det kun 1 byte. Dog vil tal tæt på det maksimalt mulige fylde mere end i det almindelige format. For eksempel er den maksimale værdi, der kan gemmes i 8 bytes i varint-format, 10 bytes. Negative tal i varintformat har altid den største størrelse, afhængigt af typen, da den mest signifikante bit af det signerede tal er sat til 1.

Problemet med at indkode negative tal blev løst ved hjælp af ZigZag ( sint32og sint64) algoritmen, hvis essens er at overføre fortegnsbitten fra den høje orden til den lave. ZigZag-kodning antager, at positive og negative tal vil veksle med hinanden, når den kodede værdi stiger. I dette tilfælde vil lige tal være positive, og ulige tal vil være negative.

Lad value - den oprindelige værdi, og N - bitdybden af ​​datatypen for den oprindelige værdi, og encoded_value - værdien kodet af ZigZag-algoritmen, så kan kodningen skrives ved hjælp af udtrykket i C-sprog :