Quels sont les principaux avantages et inconvénients d' Apache Thrift par rapport aux tampons de protocole de Google ?
Quels sont les principaux avantages et inconvénients d' Apache Thrift par rapport aux tampons de protocole de Google ?
Réponses:
Ils offrent tous deux les mêmes fonctionnalités; cependant, il existe quelques différences:
Set
type intégréFondamentalement, ils sont assez équivalents (avec des tampons de protocole légèrement plus efficaces que ce que j'ai lu).
map
également
Une autre différence importante réside dans les langues prises en charge par défaut.
Les deux pourraient être étendus à d'autres plates-formes, mais ce sont les liaisons de langues disponibles dès le départ.
RPC est une autre différence clé. Thrift génère du code pour implémenter les clients et serveurs RPC où les tampons de protocole semblent principalement conçus comme un format d'échange de données seul.
option optimize_for = SPEED
.Pour regarder de plus près les différences, consultez les différences de code source dans ce projet open source .
Comme je l'ai dit sous la rubrique "Thrift vs Protocol buffers" :
Se référant à la comparaison Thrift vs Protobuf vs JSON :
En outre, il existe de nombreux outils supplémentaires intéressants disponibles pour ces solutions, qui pourraient décider. Voici des exemples pour Protobuf: Protobuf-wirehark , protobufeditor .
Les tampons de protocole semblent avoir une représentation plus compacte, mais ce n'est qu'une impression que j'ai en lisant le livre blanc Thrift. Dans leurs propres mots:
Nous avons opté pour des optimisations de stockage extrêmes (c.-à-d. Empaqueter de petits entiers en ASCII ou utiliser un format de continuation 7 bits) pour des raisons de simplicité et de clarté dans le code. Ces modifications peuvent facilement être apportées si et quand nous rencontrons un cas d'utilisation critique en termes de performances qui les exige.
En outre, cela peut juste être mon impression, mais les tampons de protocole semblent avoir des abstractions plus épaisses autour du versionnement des structures. Thrift prend en charge la gestion des versions, mais il faut un peu d'effort pour y arriver.
J'ai pu obtenir de meilleures performances avec un protocole basé sur du texte par rapport à protobuff sur python. Cependant, aucune vérification de type ou autre conversion utf8 fantaisie, etc ... qu'offre protobuff.
Donc, si la sérialisation / désérialisation est tout ce dont vous avez besoin, vous pouvez probablement utiliser autre chose.
http://dhruvbird.blogspot.com/2010/05/protocol-buffers-vs-http.html
Une chose évidente non encore mentionnée est que ce peut être à la fois un avantage ou un inconvénient (et c'est la même chose pour les deux), ce sont des protocoles binaires. Cela permet une représentation plus compacte et peut-être plus de performances (pros), mais avec une lisibilité réduite (ou plutôt, un débogage), un con.
En outre, les deux ont un support d'outil un peu moins important que les formats standard comme xml (et peut-être même json).
(MODIFIER) Voici une comparaison intéressante qui aborde à la fois les différences de taille et de performances, et inclut également des chiffres pour certains autres formats (xml, json).
Et selon le wiki, le runtime Thrift ne fonctionne pas sur Windows.
ProtocolBuffers est PLUS RAPIDE.
Il y a une belle référence ici:
http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking
Vous pourriez également vouloir examiner Avro, car Avro est encore plus rapide.
Microsoft a un package ici:
http://www.nuget.org/packages/Microsoft.Hadoop.Avro
Soit dit en passant, le plus rapide que j'ai jamais vu est Cap'nProto ;
L'implémentation AC # se trouve dans le dépôt Github de Marc Gravell .
Je pense que la plupart de ces points ont manqué le fait fondamental que Thrift est un framework RPC, qui a la capacité de sérialiser des données en utilisant une variété de méthodes (binaire, XML, etc.).
Les tampons de protocole sont conçus uniquement pour la sérialisation, ce n'est pas un cadre comme Thrift.
D'une part, protobuf n'est pas une implémentation RPC complète. Il faut quelque chose comme gRPC pour l'accompagner.
gPRC est très lent par rapport à Thrift:
Il y a d'excellents points ici et je vais en ajouter un autre au cas où le chemin de quelqu'un se croiserait ici.
Thrift vous donne la possibilité de choisir entre le sérialiseur thrift-binary et thrift-compact (de), thrift-binary aura une excellente performance mais une plus grande taille de paquet, tandis que thrift-compact vous donnera une bonne compression mais a besoin de plus de puissance de traitement. C'est pratique car vous pouvez toujours basculer entre ces deux modes aussi facilement que de changer une ligne de code (diable, même la rendre configurable). Donc, si vous n'êtes pas sûr du niveau d'optimisation de votre application pour la taille des paquets ou la puissance de traitement, l'épargne peut être un choix intéressant.
PS: Voir cet excellent projet de référence thekvs
qui compare de nombreux sérialiseurs, y compris thrift-binary, thrift-compact et protobuf: https://github.com/thekvs/cpp-serializers
PS: Il existe un autre sérialiseur nommé YAS
qui donne également cette option mais il est sans schéma, voir le lien ci-dessus.
Il est également important de noter que toutes les langues prises en charge ne sont pas compatibles avec thrift ou protobuf. À ce stade, il s'agit de l'implémentation des modules en plus de la sérialisation sous-jacente. Prenez soin de vérifier les repères pour la langue que vous prévoyez d'utiliser.