In diesem Artikel werden die Funktionen von zwei gängigen Serialisierungsformaten aufgeführt, die ein Architekt bei der Auswahl eines dieser Formate berücksichtigen sollte.
Größe und Geschwindigkeit
Im Internet finden Sie Vergleichstests von Serialisierungsformaten. Sie sollten bestimmten Zahlen keine Bedeutung beimessen, da die Geschwindigkeit der Serialisierung / Deserialisierung sowie die Größe der resultierenden Binärdaten vom spezifischen Datenschema und von der Implementierung des Serializers abhängt. Wir stellen nur fest, dass Avro und Protobuff bei solchen Tests die führenden Positionen einnehmen.
Der Vorteil von auro ist, dass die Datensatzfelder nacheinander ohne Trennzeichen gespeichert werden. Wenn Sie jedoch mit einem Avro arbeiten , müssen Sie das Schema der aufgezeichneten Daten irgendwo speichern. Es kann an die serialisierten Daten angehängt oder separat gespeichert werden (dann wird die Schemakennung zu den Daten im externen Speicher hinzugefügt).
Der Trick des Protobuffs besteht darin, dass beim Serialisieren von Ganzzahlen standardmäßig das Format variabler Länge ( varint ) verwendet wird, das weniger Platz für kleine positive Zahlen beansprucht . Protobuff fügt dem Binärstrom die Feldnummer und den Typ hinzu, wodurch sich die Gesamtgröße erhöht. Wenn die Nachricht Felder des Datensatztyps enthält ( verschachtelte Nachricht in der Protobuff- Terminologie ), müssen Sie zuerst die Gesamtgröße des Datensatzes berechnen, was den Serialisierungsalgorithmus kompliziert und zusätzliche Zeit in Anspruch nimmt.
UPD: Avro verwendet auch ein Format variabler Länge zum Schreiben von Ganzzahlen mit abwechselnden positiven und negativen Werten ( Zick-Zack-Codierung ). Avro's int stimmt mit Protobuffs sint32 überein und long stimmt mit sint64 überein.
Insgesamt können Sie sagen, dass Sie mit der Größe und Geschwindigkeit beider Formate zufrieden sind. In den meisten Fällen ist dies nicht der Faktor, der Ihre Wahl bestimmt.
UPD: Eine hoch ausgelastete System- oder Echtzeitdatenverarbeitung kann der Fall sein, wenn es sich lohnt, sich speziellere Codecs anzusehen ( Diskussionsthread ).
Datentypen
, : 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 )