Le maggiori differenze tra i buffer di protocollo e quelli usati?

286

Quali sono i maggiori pro e contro di Apache Thrift vs Buffer di protocollo di Google ?

serialization protocol-buffers thrift

— Jonas
fonte

4

Come nota a margine, Marc Gravell mantiene una libreria per lavorare con Google protobuf chiamata protobuf.net ed è su code.google.com/p/protobuf-net

— RCIX

5

Questa domanda e alcune delle seguenti risposte hanno circa 6 anni. Probabilmente sono cambiate molte cose da allora.

— AlikElzin-Kilaka

159

Entrambi offrono molte delle stesse funzionalità; tuttavia, ci sono alcune differenze:

La parsimonia supporta le "eccezioni"
I buffer di protocollo hanno una documentazione / esempi molto migliori
Il risparmio ha un Settipo incorporato
I buffer di protocollo consentono "estensioni": è possibile estendere un proto esterno per aggiungere campi aggiuntivi, consentendo comunque al codice esterno di operare sui valori. Non c'è modo di farlo in Thrift
Trovo che i buffer di protocollo siano molto più facili da leggere

Fondamentalmente, sono abbastanza equivalenti (con Protocol Buffers leggermente più efficiente da quello che ho letto).

— hazzen
fonte

16

Questa presentazione li spiega bene del 2013 slideshare.net/IgorAnishchenko/pb-vs-thrift-vs-avro

— BAR

13

la parsimonia supporta altre 10 lingue

— Elia Saounkine,

1

Per alcune lingue è possibile aggiungere estensioni. Ad esempio, Thrift genera classi parziali per C # che sono facili da estendere. Tuttavia, questa non è la regola generale, è vero.

— JensG,

grpc 1.0 (proto3) supporta mapanche

— KindDragon,

85

Un'altra differenza importante sono le lingue supportate per impostazione predefinita.

Buffer di protocollo: Java, Android Java, C ++, Python, Ruby, C #, Go, Objective-C, Node.js
Usato: Java, C ++, Python, Ruby, C #, Go, Objective-C, JavaScript, Node.js, Erlang, PHP, Perl, Haskell, Smalltalk, OCaml, Delphi, D, Haxe

Entrambi potrebbero essere estesi ad altre piattaforme, ma questi sono i binding di lingue disponibili immediatamente.

— Mike Gray
fonte

16

protobuf ha un eccellente supporto per rubini github.com/macks/ruby-protobuf e code.google.com/p/ruby-protobuf . Sto usando protobuf da C # (3.5) e Ruby, serializzando i dati in C # e, quando necessario, Ruby deserializzando e lavorando sull'attività.

— Bryan Bailliache,

6

code.google.com/p/protobuf/wiki/ThirdPartyAddOns elenca PHP, Ruby, Erlang, Perl, Haskell, C #, OCaml plus Actiona Script, Common Lisp, Go, Lua, Mathlab, Visual Basic, Scala. Pensato che queste siano tutte implementazioni di terze parti.

— Igor Gatis,

puoi usare direttamente i file protobuf C ++ nell'obiettivo c (sia per iOS che per OS X) controlla questo qn

— Tushar Koul

Vedo code.google.com/p/protobuf-net è spesso menzionato come una porta protobuf per C #, ma non è del tutto vero. Una delle caratteristiche importanti di Protobuf e Thrift è la definizione della struttura esterna, quindi la stessa definizione può essere utilizzata da lingue diverse. protobuf-net non supporta questa funzione perché incorpora la definizione della struttura all'interno del codice C #.

— Andriy Tylychko,

@AndyT: È discutibile - dipende dal fatto che sia un vantaggio il fatto che la definizione della struttura sia ESTERNA a tutte le lingue che si desidera supportare. Con protobuf-net definisci la struttura dei tuoi dati in C # e generi il file .proto da quello, che può quindi essere usato per creare il supporto nelle altre lingue. Considero questo un vantaggio, poiché sono molto centrato sul C # e sto integrando Android / Java con una grande applicazione .Net esistente. Quindi voglio continuare a considerare le mie classi C # come definizioni definitive della struttura.

— RenniePet,

73

RPC è un'altra differenza fondamentale. Thrift genera codice per implementare client e server RPC laddove i buffer di protocollo sembrano principalmente progettati come un solo formato di scambio dati.

— saidimu apale
fonte

9

Non è vero. I buffer di protocollo definiscono un'API di servizio RPC e sono disponibili alcune librerie per implementare il passaggio dei messaggi.

— Stephen,

7

Non ho detto che Protobuf non ha RPC definito, solo che non sembra essere stato progettato per questo, almeno non la versione esterna a cui tutti hanno accesso. Leggi il commento di questo ingegnere Google qui

— saidimu apale

9

Ancora più importante, Thrift ha il supporto RPC integrato. Protobuf si basa attualmente su librerie di terze parti, il che significa meno occhi, meno test, codice meno affidabile.

— Alec Thomas,

2

Per me, è un buon punto su ProtoBuf. Se devi solo serializzare, non aggiungi codice inutile. E se in futuro, è necessario inviarlo tramite RPC, nessun problema, può funzionare. Uso Netty per la rete e Protobuf è perfettamente integrato, quindi nessun problema, nessun test e massimizza le prestazioni.

— Kikiwa,

14

I protobuf sono stati, infatti, progettati pensando a RPC. Google ha appena aperto tale componente abbastanza recentemente - grpc.io

— andybons il

57

Gli oggetti serializzati Protobuf sono circa il 30% più piccoli di quelli usati.
La maggior parte delle azioni che potresti voler fare con gli oggetti protobuf (creare, serializzare, deserializzare) sono molto più lente della parsimonia a meno che non si attivi option optimize_for = SPEED.
Thrift ha strutture dati più ricche (Mappa, Set)
L'API di Protobuf sembra più pulita, sebbene le classi generate siano tutte impacchettate come classi interne che non sono così belle.
Gli enum di risparmio non sono veri e propri enum di Java, ovvero sono solo ints. Protobuf ha veri enumerati Java.

Per uno sguardo più attento alle differenze, controlla le differenze del codice sorgente in questo progetto open source .

— eishay
fonte

1

Suggerimento veloce: sarebbe bello se ci fosse un altro formato non binario (xml o json?) Usato come base. Non ci sono stati buoni test che mostrino tendenze generali: supponiamo che PB e Thrift siano più efficienti, ma se e in che misura, è per lo più una domanda aperta.

— StaxMan

4

0,02 secondi ?! Non ho quel tipo di tempo libero

— Chris S

1

Ora che Thrift ha più protocolli (incluso un TCompactProtocol), penso che il primo proiettile non si applichi più.

— Janus Troelsen,

13

L'opzione di ottimizzazione per la velocità è ora l'impostazione predefinita per i buffer di protocollo ( code.google.com/apis/protocolbuffers/docs/proto.html )

— Willem

5

Otteniamo oggetti più piccoli del 30% con "optim_for = speed" impostato? O questo è compromesso?

— Prashant Sharma,

56

Come ho detto come argomento "Buffer di parsimonia contro protocollo" :

Facendo riferimento al confronto Thrift vs Protobuf vs JSON :

Thrift supporta AS3, C ++, C #, D, Delphi, Go, Graphviz, Haxe, Haskell, Java, Javascript, Node.js, OCaml, Smalltalk, Typescript, Perl, PHP, Python, Ruby ...
C ++, Python, Java - supporto integrato in Protobuf
Il supporto di Protobuf per altre lingue (tra cui Lua, Matlab, Ruby, Perl, R, Php, OCaml, Mercury, Erlang, Go, D, Lisp) è disponibile come Addon di terze parti (a parte. Ecco il supporto SWI-Prolog ).
Protobuf ha una documentazione molto migliore e molti esempi.
L'usato viene fornito con un buon tutorial
Gli oggetti Protobuf sono più piccoli
Protobuf è più veloce quando si utilizza la configurazione "optim_for = SPEED"
Thrift ha integrato l'implementazione RPC, mentre per Protobuf le soluzioni RPC sono separate, ma disponibili (come Zeroc ICE ).
Protobuf è rilasciato sotto licenza in stile BSD
Thrift è rilasciato sotto licenza Apache 2

Inoltre, ci sono molti strumenti aggiuntivi interessanti disponibili per quelle soluzioni, che potrebbero decidere. Ecco alcuni esempi di Protobuf: Protobuf- WireShark , Protobufeditor .

— Grzegorz Wierzowiecki
fonte

10

Ora questo è un cerchio completo. Hai inviato la stessa identica risposta a tre domande (simili) rimandando sempre a o. Mi sento come se stessi giocando a Zelda e ho perso un segno.

— Chris,

+ ChrisR heh, non ricordo come sia successo. Sebbene ci fossero un paio di domande simili, forse dovrei fare tre strutture simili invece di ciclo. Un giorno ... È una domanda molto vecchia e ora sto rispondendo dal telefono. Comunque, grazie per la cattura!

— Grzegorz Wierzowiecki,

6

"L'usato viene fornito con un buon tutorial" - che divertente. È il tutorial più incompleto che abbia mai visto. Non appena vuoi fare qualcosa accanto a TSimpleServer, rimani bloccato lì

— Marian Klühspies

Anche Thrift ha il plugin Wireshark: github.com/andrewcox/wireshark-with-thrift-plugin

— CCoder

8

Protocol Buffers sembra avere una rappresentazione più compatta, ma questa è solo un'impressione che ottengo leggendo il white paper di Thrift. Con le loro stesse parole:

Abbiamo deciso di evitare alcune ottimizzazioni di archiviazione estreme (ovvero l'imballaggio di piccoli numeri interi in ASCII o l'utilizzo di un formato di continuazione a 7 bit) per motivi di semplicità e chiarezza nel codice. Queste modifiche possono essere facilmente apportate se e quando incontriamo un caso d'uso critico per le prestazioni che li richiede.

Inoltre, potrebbe essere solo la mia impressione, ma Protocol Buffers sembra avere alcune astrazioni più spesse riguardo il versioning di struct. Thrift ha un po 'di supporto per il controllo delle versioni, ma ci vuole un po' di sforzo per realizzarlo.

— Daniel Spiewak
fonte

1

Perché il fatto che Thrift ammetta di non essere il più compatto possibile porta a credere che i buffer di protocollo lo siano?

— Michael Mior,

1

I buffer di protocollo utilizzano la codifica di numeri interi di lunghezza variabile, sia per i valori che per gli identificatori di campo. Quindi il caso molto comune di invio di un campo int con un valore piccolo sarà di due byte, non di un int16 e un int32.

— poolie,

"I buffer di protocollo usano la codifica di numeri interi di lunghezza variabile", così fa TCompactProtocol

— JensG

8

Sono stato in grado di ottenere prestazioni migliori con un protocollo testuale rispetto a protobuff su Python. Tuttavia, nessun controllo del tipo o altra conversione utf8 di fantasia, ecc ... che offre protobuff.

Quindi, se la serializzazione / deserializzazione è tutto ciò di cui hai bisogno, allora probabilmente puoi usare qualcos'altro.

http://dhruvbird.blogspot.com/2010/05/protocol-buffers-vs-http.html

— dhruvbird
fonte

7

Una cosa ovvia non ancora menzionata è che possono essere sia pro che contro (ed è uguale per entrambi) è che sono protocolli binari. Ciò consente una rappresentazione più compatta e possibilmente più prestazioni (pro), ma con una leggibilità ridotta (o meglio, debuggabilità), un contro.

Inoltre, entrambi hanno un supporto degli strumenti leggermente inferiore rispetto ai formati standard come xml (e forse anche json).

(EDIT) Ecco un confronto interessante che affronta sia le dimensioni che le differenze di prestazioni e include numeri anche per alcuni altri formati (xml, json).

— StaxMan
fonte

3

È banale generare un buffer di protocollo in una rappresentazione testuale molto più leggibile dall'uomo rispetto a XML: my_proto.DebugString (). Per un esempio, vedi code.google.com/apis/protocolbuffers/docs/overview.html

— SuperElectric

Ovviamente, idem per tutti i formati binari, ma ciò non li rende leggibili come sono (debug sul filo). Peggio ancora, per protobuf, hai davvero bisogno dello schema def per conoscere i nomi dei campi.

— StaxMan

Thrift supporta protocolli diversi, anche definiti dall'utente. Puoi usare binario, compatto, json o qualcosa che hai inventato proprio la scorsa settimana.

— JensG,

6

E secondo la wiki il runtime di Thrift non funziona su Windows.

5

Ho eseguito Thrift su Windows con successo. Usa Windows

— Fork

20

La filiale ufficiale della linea principale ora ha anche il supporto di Windows.

— Janus Troelsen,

5

@dalle - Alex P ha aggiunto il supporto per il thread Boost in Thrift. Ora è il threading predefinito per Windows. * L'impostazione predefinita di NIX è pthreads. E per confermare Janus T, Thrift ora supporta completamente Windows.

— pmont,

21

Si tratta di informazioni obsolete. La parsimonia funziona perfettamente su Windows per un po 'di tempo ormai.

— JensG,

6

ProtocolBuffers è più veloce.
C'è un bel benchmark qui:
http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking

Potresti anche voler esaminare Avro, poiché Avro è ancora più veloce.
Microsoft ha un pacchetto qui:
http://www.nuget.org/packages/Microsoft.Hadoop.Avro

A proposito, il più veloce che abbia mai visto è Cap'nProto ;
L'implementazione di AC # è disponibile nel repository Github di Marc Gravell .

— Stefan Steiger
fonte

4

Penso che la maggior parte di questi punti abbia perso il fatto fondamentale che Thrift è un framework RPC, che ha la capacità di serializzare i dati utilizzando una varietà di metodi (binario, XML, ecc.).

I buffer di protocollo sono progettati esclusivamente per la serializzazione, non è un framework come Thrift.

— Babra Cunningham
fonte

3

Cosa intendi per framework RPC e in cosa differisce dal gRPC di protobuf ?

— marcelocra,

gRPC non è impacchettato insieme a protobuf. È stato sviluppato come 10 anni dopo. Thrift viene fornito con il framework RPC completo. È stato realizzato insieme.

— trilogia

3

Per uno, protobuf non è un'implementazione RPC completa. Richiede qualcosa come gRPC per andare con esso.

gPRC è molto lento rispetto a parsimonia:

http://szelei.me/rpc-benchmark-part1/

— trilogia
fonte

0

Ci sono alcuni punti eccellenti qui e ne aggiungerò un altro nel caso in cui il percorso di qualcuno attraversi qui.

Thrift ti dà la possibilità di scegliere tra serializzatore binario-parsimonioso e compatto (de) parsimonioso, binario-parsimonioso avrà prestazioni eccellenti ma dimensioni del pacchetto maggiori, mentre compatto-parsimonioso ti darà una buona compressione ma ha bisogno di più potenza di elaborazione. Questo è utile perché puoi sempre passare tra queste due modalità con la stessa facilità con cui si modifica una riga di codice (diamine, anche renderlo configurabile). Quindi, se non sei sicuro di quanto la tua applicazione debba essere ottimizzata per la dimensione del pacchetto o in termini di potenza di elaborazione, la parsimonia può essere una scelta interessante.

PS: vedi questo eccellente progetto di benchmark con thekvscui confronta molti serializzatori tra cui binario di risparmio, compasso di risparmio e protobuf: https://github.com/thekvs/cpp-serializers

PS: Esiste un altro serializzatore YASche dà anche questa opzione, ma è senza schema vedere il link sopra.

— SINAPSE
fonte

0

È anche importante notare che non tutte le lingue supportate si confrontano in modo coerente con la parsimonia o il protobuf. A questo punto si tratta dell'implementazione dei moduli oltre alla serializzazione sottostante. Assicurati di controllare i benchmark per qualsiasi lingua tu preveda di utilizzare.

— JSON
fonte