Cet article répertorie les fonctionnalités de deux formats de sérialisation populaires qu'un architecte doit prendre en compte lors du choix de l'un d'entre eux.
Taille et vitesse
Sur le net, vous pouvez trouver des tests comparatifs des formats de sérialisation. Vous ne devez pas attacher d'importance à des numéros spécifiques, car la vitesse de sérialisation / désérialisation, ainsi que la taille des données binaires résultantes, dépendent du schéma de données spécifique et de l'implémentation du sérialiseur. On note seulement que l' Auro et le Protobuff occupent les premières places dans de tels tests.
L'avantage de l' Euro est que les champs d'enregistrement sont sauvegardés les uns après les autres, sans séparateurs. Mais lorsque vous traitez avec un avro , vous devez stocker le schéma des données enregistrées quelque part. Il peut être attaché aux données sérialisées, ou il peut être stocké séparément (puis l'identifiant de schéma est ajouté aux données dans le stockage externe).
L'astuce du protobuff est que lors de la sérialisation des entiers, par défaut, le format de longueur variable ( varint ) est utilisé, ce qui prend moins de place pour les petits nombres positifs. Protobuff ajoute le numéro et le type de champ au flux binaire, ce qui augmente la taille totale. De plus, si le message comprend des champs du type d'enregistrement ( message imbriqué dans la terminologie protobuff ), vous devez d'abord calculer la taille finale de l'enregistrement, ce qui complique l'algorithme de sérialisation et prend plus de temps.
UPD: Avro utilise également un format de longueur variable pour écrire des entiers, avec des valeurs positives et négatives en alternance ( codage en zigzag ). Le int d'Avro correspond au sint32 de Protobuff et à long correspond au sint64.
Dans l'ensemble, vous pouvez dire que vous serez satisfait de la taille et de la vitesse des deux formats. Dans la plupart des cas, ce n'est pas le facteur qui déterminera votre choix.
UPD: Un système à forte charge ou un traitement de données en temps réel peut être le cas lorsqu'il vaut la peine de regarder des codecs plus spécialisés ( fil de discussion ).
Types de données
, : 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 )