Este artigo lista os recursos de dois formatos de serialização populares que um arquiteto deve considerar ao escolher um deles.
Tamanho e velocidade
Na rede você pode encontrar testes comparativos de formatos de serialização. Você não deve atribuir importância a números específicos, pois a velocidade de serialização / desserialização, bem como o tamanho dos dados binários resultantes, depende do esquema de dados específico e da implementação do serializador. Notamos apenas que o avro e o protobuff ocupam as posições de liderança em tais testes.
A vantagem do auro é que os campos de registro são armazenados um após o outro, sem separadores. Mas ao lidar com um avro , você precisa armazenar o esquema dos dados gravados em algum lugar. Ele pode ser anexado aos dados serializados ou pode ser armazenado separadamente (então o identificador do esquema é adicionado aos dados no armazenamento externo).
O truque do protobuff é que, ao serializar inteiros, por padrão, o formato de comprimento variável ( varint ) é usado, o que ocupa menos espaço para pequenos números positivos. Protobuff adiciona o número e o tipo do campo ao fluxo binário, o que aumenta o tamanho total. Além disso, se a mensagem incluir campos do tipo de registro ( mensagem aninhada na terminologia de protobuff ), primeiro você precisa calcular o tamanho do registro final, o que complica o algoritmo de serialização e leva mais tempo.
UPD: Avro também usa um formato de comprimento variável para escrever inteiros, com alternância de valores positivos e negativos ( codificação em zigue-zague ). Int de Avrow corresponde a sint32 de Protobuff e long corresponde a sint64.
No geral, você pode dizer que ficará satisfeito com o tamanho e a velocidade de ambos os formatos. Na maioria dos casos, esse não é o fator que determinará sua escolha.
UPD: um sistema de alta carga ou processamento de dados em tempo real pode ser o caso quando vale a pena olhar para codecs mais especializados ( thread de discussão ).
Tipos de dados
, : bool, string, int32(int), int64(long), float, double, byte[]. uint32, uint64.
, -, varint, . , : sint32, sint64, fixed32, fixed64, sfixed32, sixed64.
(map). ( ).
(enumerations).
(records , message ) (union , oneof ).
, (nullable) , , union , null, - oneof .
UPD: nullable message . optional, , oneof. stackoverflow.
(logical types well known types ). (timestamp) (duration).
, decimal UUID. fixed - .
, decimal - , , .
(backward compatibility) -. , , , (0, , false). (aliases) (record, enum, fixed). , .
, ( int long, float double, ). , C++. bool , enum .
, , , , . (forward compatibility).
.
enum, -, , - .
(case) (union) unknown. , , .
. (ADT), , , , .
Json
, , Json. , , (, MongoDB).
, , ( , , json_name ). (aliases) .
, ( bytes, fixed) UTF16 . (, .), Json , UTF16. base64.
Json , , , , , UTF16.
, , . , (, ), (, Schema Registry). , (statefullness), “” .
(, python), , , . , , , “ ”, . , Any, , , .
RPC
.
(one-way). (handshake), .
, (streaming) .
RPC - gRPC. , gRPC, -, , , . , , , , , , gRPC , , , , .
, , RPC, .
Kafka
. .
Hadoop
gRPC. , Hadoop - , elephant-bird .
.
https://github.com/apache/avro (1.7K , 1.1 )
https://github.com/protocolbuffers/protobuf (45K , 12.1 )