Acabamos de fazer um estudo interno sobre serializadores, aqui estão alguns resultados (para minha referência futura também!)
Thrift = serialização + pilha RPC
A maior diferença é que o Thrift não é apenas um protocolo de serialização, é uma pilha RPC completa que é como uma pilha SOAP moderna. Portanto, após a serialização, os objetos podem (mas não são obrigatórios) ser enviados entre máquinas por TCP / IP. No SOAP, você começou com um documento WSDL que descreve completamente os serviços disponíveis (métodos remotos) e os argumentos / objetos esperados. Esses objetos foram enviados via XML. No Thrift, o arquivo .thrift descreve completamente os métodos disponíveis, os objetos de parâmetros esperados e os objetos são serializados por meio de um dos serializadores disponíveis (com Compact Protocol
um protocolo binário eficiente, sendo o mais popular na produção).
ASN.1 = Grand Daddy
O ASN.1 foi projetado pelo pessoal de telecomunicações nos anos 80 e é difícil de usar devido ao suporte limitado à biblioteca, em comparação com os serializadores recentes que surgiram do pessoal do CompSci. Há duas variantes, codificação DER (binária) e codificação PEM (ascii). Ambos são rápidos, mas o DER é mais rápido e mais eficiente em tamanho dos dois. De fato, o ASN.1 DER pode facilmente acompanhar (e às vezes vencer) serializadores que foram projetados 30 anospor si só, um testemunho de seu design bem projetado. É muito compacto, menor que os Protocol Buffers e Thrift, vencidos apenas pela Avro. A questão é ter ótimas bibliotecas para oferecer suporte e, no momento, o Bouncy Castle parece ser o melhor para C # / Java. O ASN.1 é o rei em sistemas de segurança e criptografia e não vai desaparecer, portanto, não se preocupe com a 'prova futura'. Basta ter uma boa biblioteca ...
MessagePack = meio do pacote
Não é ruim, mas não é o mais rápido, nem o menor, nem o melhor suportado. Não há razão de produção para escolher.
Comum
Além disso, eles são bastante semelhantes. A maioria são variantes do TLV: Type-Length-Value
princípio básico .
Buffers de protocolo (origem do Google), Avro (baseado no Apache, usado no Hadoop), Thrift (origem do Facebook, agora projeto Apache) e ASN.1 (origem da Telecom) envolvem algum nível de geração de código onde você expressa seus dados pela primeira vez em um serializador -específico, o "compilador" do serializador gerará o código-fonte para o seu idioma através da code-gen
fase. A fonte do seu aplicativo usa essas code-gen
classes para E / S. Observe que certas implementações (por exemplo: biblioteca Avro da Microsoft ou ProtoBuf.NET de Marc Gavel) permitem decorar diretamente os objetos POCO / POJO no nível do aplicativo e, em seguida, a biblioteca usa diretamente essas classes decoradas em vez das classes de qualquer genitor de código. Vimos essa oferta melhorar o desempenho, pois elimina um estágio de cópia do objeto (dos campos POCO / POJO no nível do aplicativo aos campos de geração de código).
Alguns resultados e um projeto ao vivo para brincar
Este projeto ( https://github.com/sidshetye/SerializersCompare ) compara serializadores importantes no mundo C #. O pessoal do Java já tem algo parecido .
1000 iterations per serializer, average times listed
Sorting result by size
Name Bytes Time (ms)
------------------------------------
Avro (cheating) 133 0.0142
Avro 133 0.0568
Avro MSFT 141 0.0051
Thrift (cheating) 148 0.0069
Thrift 148 0.1470
ProtoBuf 155 0.0077
MessagePack 230 0.0296
ServiceStackJSV 258 0.0159
Json.NET BSON 286 0.0381
ServiceStackJson 290 0.0164
Json.NET 290 0.0333
XmlSerializer 571 0.1025
Binary Formatter 748 0.0344
Options: (T)est, (R)esults, s(O)rt order, (S)erializer output, (D)eserializer output (in JSON form), (E)xit
Serialized via ASN.1 DER encoding to 148 bytes in 0.0674ms (hacked experiment!)