Buffer di protocollo rispetto a JSON o BSON [chiuso]

90

Qualcuno ha informazioni sulle caratteristiche delle prestazioni dei buffer di protocollo rispetto a BSON (JSON binario) o rispetto a JSON in generale?

  • Dimensioni del filo
  • Velocità di serializzazione
  • Velocità di deserializzazione

Questi sembrano buoni protocolli binari da usare su HTTP. Mi chiedo solo quale sarebbe la soluzione migliore a lungo termine per un ambiente C #.

Ecco alcune informazioni che stavo leggendo su BSON e sui buffer di protocollo .

c#  json  comparison  protocol-buffers  bson 
— Jeff Meatball Yang
fonte
Alcuni sostengono (penso che questo includa un ex autore di protobuf) che sia un'idea migliore usare un formato più grande ma più economico per serializzare il formato e quindi comprimere l'output con un compressore standard veloce.
— CodesInChaos
— laike9m
Non penso che questo dovrebbe essere riaperto fino a quando un certo metodo di confronto non viene proposto nella domanda stessa (altrimenti questo è per una discussione piuttosto supponente / troppo ampia)
— YakovL

Risposte:

64

La parsimonia è anche un'altra alternativa simile ai buffer di protocollo.

Ci sono buoni benchmark dalla comunità Java sulla serializzazione / deserializzazione e la dimensione del filo di queste tecnologie: https://github.com/eishay/jvm-serializers/wiki

In generale, JSON ha una dimensione del filo leggermente più grande e un DeSer leggermente peggiore, ma vince in termini di ubiquità e capacità di interpretarlo facilmente senza l'IDL di origine. L'ultimo punto è qualcosa che Apache Avro sta cercando di risolvere e batte entrambi in termini di prestazioni.

Microsoft ha rilasciato un pacchetto NuGet C # Microsoft.Hadoop.Avro .

— Michael Greene
fonte
1
Le dimensioni ridotte dei messaggi non si traducono automaticamente in prestazioni veloci, vedere questo articolo soa.sys-con.com/node/250512
— vtd-xml-author
1
Buon collegamento; l'unica cosa di cui non sono sicuro è un commento su Avro: sebbene possa funzionare in modo più efficiente per i suoi casi d'uso principali (tonnellate di voci di dati simili), non sembra funzionare molto velocemente in questo benchmark (che testa la gestione di un richiesta singola)
— StaxMan
CoDec, MoDem .... Mi piace di più "SeDes" :)
— nawfal
52

Di seguito sono riportati alcuni benchmark recenti che mostrano le prestazioni dei noti serializzatori .NET.

I benchmark Burning Monks mostrano le prestazioni della serializzazione di un semplice POCO mentre i benchmark completi Northwind mostrano i risultati combinati della serializzazione di una riga in ogni tabella del set di dati Northwind di Microsoft.

inserisci qui la descrizione dell'immagine

Fondamentalmente i buffer di protocollo ( protobuf-net ) sono circa 7 volte più veloci del Serializer della libreria di classi Base più veloce in .NET (XML DataContractSerializer). È anche più piccolo della concorrenza in quanto è anche 2,2 volte più piccolo del formato di serializzazione più compatto di Microsoft (JsonDataContractSerializer).

I serializzatori di testo di ServiceStack sono i più vicini alla corrispondenza con le prestazioni del protobuf-net binario, dove il suo serializzatore Json è solo 2,58 volte più lento di protobuf-net.

— mythz
fonte
1
Ottimo post, ma se possibile dovresti sempre inserire barre di errore sui grafici a barre quando mostri le medie.
— jtromans
Perché JIL non è incluso nei test? (hai idea del perché?)
— Royi Namir
22

buffer di protocollo è progettato per il filo:

  1. dimensione del messaggio molto piccola: un aspetto è una rappresentazione di interi di dimensioni variabili molto efficiente.
  2. Decodifica molto veloce: è un protocollo binario.
  3. protobuf genera un C ++ super efficiente per codificare e decodificare i messaggi - suggerimento: se codifichi tutti i var-interi o gli elementi di dimensioni statiche, codificherà e decodificherà a velocità deterministica.
  4. Offre un modello di dati MOLTO ricco - codifica in modo efficiente strutture di dati molto complesse.

JSON è solo testo e deve essere analizzato . suggerimento: codificare un "miliardo" int in esso richiederebbe un bel po 'di caratteri: miliardi = 12 caratteri (scala lunga), in binario si inserisce in un uint32_t Ora che ne dici di provare a codificare un doppio? sarebbe MOLTO MOLTO peggio.

— Hassan Syed
fonte
4
Tuttavia, ha lo svantaggio piuttosto sfortunato di non gestire l'ereditarietà e sebbene la composizione sia una valida alternativa, preferisco non essere costretto dal mio oggetto di trasferimento dei dati a utilizzare la composizione piuttosto che l'ereditarietà.
— Mark Green
4
Credo che le estensioni possano essere utilizzate in un modo molto simile all'ereditarietà ... developers.google.com/protocol-buffers/docs/reference/…
— kralyk
1
Sì, le estensioni sono un ottimo punto. Lo uso in pratica al lavoro tutti i giorni.
— Yngve Sneen Lindal,
"buffer di protocollo è progettato per il filo" Cos'è "il filo"?
— Marcos Pereira
@marcospgp the wiresignifica solo rete. Ora, quando usiamo così tante reti wireless, può sembrare strano.
— Victor Yarema
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.