Este artículo enumera las características de dos formatos de serialización populares que un arquitecto debe considerar al elegir uno de ellos.
Tamaño y velocidad
En la red puede encontrar pruebas comparativas de formatos de serialización. No debe dar importancia a números específicos, ya que la velocidad de serialización / deserialización, así como el tamaño de los datos binarios resultantes, dependen del esquema de datos específico y de la implementación del serializador. Solo notamos que avro y protobuff ocupan las posiciones de liderazgo en tales pruebas.
La ventaja de auro es que los campos de registro se almacenan uno tras otro, sin separadores. Pero cuando se trata de un avro , debe almacenar el esquema de los datos registrados en algún lugar. Se puede adjuntar a los datos serializados o se puede almacenar por separado (luego, el identificador de esquema se agrega a los datos en el almacenamiento externo).
El truco del protobuff es que al serializar enteros, por defecto, se utiliza el formato de longitud variable ( varint ), que ocupa menos espacio para números positivos pequeños. Protobuff agrega el número de campo y el tipo a la secuencia binaria, lo que aumenta el tamaño total. Además, si el mensaje incluye campos del tipo de registro ( mensaje anidado en terminología de protobuff ), primero debe calcular el tamaño del registro final, lo que complica el algoritmo de serialización y lleva más tiempo.
UPD: Avro también usa un formato de longitud variable para escribir números enteros, con valores positivos y negativos alternos ( codificación en zigzag ). Int de Avro coincide con sint32 de Protobuff y long coincide con sint64.
En general, puede decir que estará satisfecho con el tamaño y la velocidad de ambos formatos. En la mayoría de los casos, este no es el factor que determinará su elección.
UPD: el procesamiento de datos en tiempo real o un sistema muy cargado puede ser el caso cuando vale la pena buscar códecs más especializados ( hilo de discusión ).
Tipos de datos
, : 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 )