Buffer di protocollo, dove usarli?

Question

Recentemente ho letto un articolo su protocol buffers,

buffer protocollo è un metodo di serializzazione dei dati strutturati. È utile nello sviluppo di programmi per comunicare tra loro su un filo o per la memorizzazione di dati. Il metodo prevede una descrizione dell'interfaccia linguaggio che descrive la struttura di alcuni dati e un programma che genera il codice sorgente da tale descrizione per la generazione o l'analisi un flusso di byte che rappresenta i dati strutturati

cosa voglio sai, dove usarli? Esistono esempi di vita reale piuttosto che semplici esempi di rubriche? È ad esempio utilizzato per pre-memorizzare i risultati delle query dai database?

Answer 1

I buffer di protocollo sono un formato di archiviazione e scambio dati, in particolare utilizzato per RPC - comunicazione tra programmi o computer.

alternative includono specifiche della lingua serializzazione (serializzazione Java, Python pickles, ecc), formati tabellari come CSV e TSV, formati di testo strutturati come XML e JSON, e altri formati binari, come Apache Thrift. Concettualmente questi sono solo modi diversi di rappresentare i dati strutturati, ma in pratica hanno diversi pro e contro.

buffer protocollo sono:

• spazio efficiente, potendo contare su un custom format per rappresentare i dati in modo compatto.
• Fornisce una sicurezza di tipo cross-language (in particolare in linguaggi fortemente tipizzati come Java, ma anche in Python è ancora abbastanza utile).
• Progettato per essere compatibile con le versioni precedenti e successive. È facile apportare modifiche strutturali ai buffer del protocollo (normalmente aggiungendo nuovi campi o deprecando quelli vecchi) senza la necessità di garantire che tutte le applicazioni che utilizzano il proto vengano aggiornate simultaneamente.
• Un po 'noioso lavorare con manualmente. Mentre c'è un formato di testo, è per lo più utile per ispezionare manualmente, non memorizzare, protos. JSON, ad esempio, è molto più facile per un essere umano scrivere e modificare. Pertanto i protos sono solitamente scritti e letti dai programmi.
• Dipende dal compilatore .proto. Separando la struttura dai buffer del protocollo dati può essere snella e media, ma significa senza un file .proto associato e uno strumento come protoc per generare codice per analizzarlo, dati arbitrari in formato proto sono inutilizzabili. Ciò rende Protos una scelta sbagliata per l'invio di dati ad altre persone che potrebbero non avere il file .proto a portata di mano.

di fare alcune generalizzazioni sui diversi formati:

• CSV/TSV/etc. sono utili per dati costruiti dall'uomo che non devono mai essere trasmessi tra persone o programmi. È facile da costruire e facile da analizzare, ma un incubo da mantenere sincronizzato e non può facilmente rappresentare strutture complesse.
• La serializzazione della lingua specifica come i sottaceti può essere utile per la serializzazione di breve durata, ma si verifica rapidamente problemi di compatibilità con le versioni precedenti e ovviamente limita a una lingua. Tranne che in alcuni casi molto specifici, i protobuf raggiungono tutti gli stessi obiettivi con maggiore sicurezza e migliore impermeabilità al futuro.
• JSON è ideale per l'invio di dati tra diverse parti (ad esempio API pubbliche). Poiché la struttura e il contenuto vengono trasmessi insieme, chiunque può capirlo ed è facile da analizzare in tutte le principali lingue. Al giorno d'oggi c'è poca ragione per usare altri formati strutturati come XML.
• I formati binari come i buffer di protocollo sono ideali per quasi tutti gli altri casi di utilizzo della serializzazione dei dati; archiviazione a lungo ea breve termine, comunicazione tra processi, caching intra-process e application-wide e altro ancora.

Google notoriamente uses protocol buffers for practically everything they do. Se riesci a immaginare un motivo per cui devi archiviare o trasmettere dati, Google probabilmente lo fa con i buffer del protocollo.

Answer 2

Li ho usati per creare un sistema di trading finanziario. Ecco i motivi:

• Esistono librerie per molte lingue. Alcune cose dovevano essere in C++, altre in C#. Ed era aperto ad estendere a Python o Java, ecc.
• Doveva essere veloce per serializzare/deserializzare e compattare. Ciò è dovuto al requisito di velocità nel sistema di trading finanziario. I messaggi erano molto più brevi rispetto ai messaggi di testo comparabili, il che significava che non avevi mai avuto problemi nel montarli in un pacchetto di rete.
• Non ha bisogno di essere leggibile dal filo. Precedentemente il sistema disponeva di XML che è utile per il debug, ma è possibile ottenere il debug degli output in altri modi e disattivarli in produzione.
• Fornisce al messaggio una struttura naturale e un'API per ottenere le parti necessarie. Scrivere qualcosa di personalizzato avrebbe richiesto di pensare a tutte le funzioni di aiuto per estrarre numeri dal binario, con casi d'angolo e tutto il resto.