Was sind die wichtigsten Unterschiede zwischen Apache Thrift, Google Protocol Buffers, Message, ASN.1 und Apache Avro?

Question

All diese bieten binäre Serialisierung, RPC-Frameworks und IDL. Ich habe Interesse an wichtigen Unterschieden zwischen ihnen und Eigenschaften (Leistung, einfacher Bedienung, Programmiersprachen-Unterstützung).

Wenn Sie irgendwelche anderen ähnlichen Technologien kennen, fügen Sie es in einer Antwort erwähnen.

Answer 1

ASN.1 ist ein ISO / ISE-Standard. Es hat eine sehr lesbare Quellsprache und eine Vielzahl von Back-Ends, sowohl binär und in lesbare Form. einen internationalen Standard zu sein (und ein altes an!) die Quellsprache ist ein bisschen Küchen sinkish (in etwa die gleiche Art und Weise, dass der Atlantik ein bisschen nass ist), aber es ist sehr gut angegeben und hat ordentliche Menge an Unterstützung . (Sie können sich wahrscheinlich eine ASN.1-Bibliothek für jede Sprache finden Sie nennen, wenn man hart genug graben, und wenn nicht, gibt es eine gute Sprache C-Bibliotheken zur Verfügung, die Sie in FFIs verwenden können.) Es ist eine standardisierte Sprache zu sein, obsessiv dokumentiert und hat ein paar gute Lektionen zur Verfügung.

Thrift ist kein Standard. Es ist ursprünglich von Facebook und war später als Open-Source und ist derzeit ein Top-Level-Apache-Projekt. Es ist nicht gut dokumentiert - insbesondere Tutorial-Level - und zu meinem (zugegebenermaßen kurzen) Blick scheint nichts hinzuzufügen, dass auch andere, nicht bisherige Bemühungen nicht bereits tun (und in einigen Fällen besser). Um fair zu sein, um es, hat es eine ziemlich beeindruckende Zahl von Sprachen der Box ein paar der höheren Profil Nicht-Mainstream diejenigen, einschließlich unterstützt werden. Die IDL ist auch vage C-like.

Protocol Buffers ist kein Standard. Es ist ein Google-Produkt, das auf die breitere Gemeinschaft freigegeben wird. Es ist ein wenig begrenzt in Bezug auf die Sprachen der Box unterstützt aus (es unterstützt nur C ++, Python und Java), aber es tut für andere Sprachen eine Menge von Drittanbietern Unterstützung haben (von sehr unterschiedlicher Qualität). Google tut so ziemlich alle ihre Arbeit Protocol Buffers verwenden, so ist es ein kampferprobt ist, kampferprobter Protokoll (wenn auch nicht als kampferprobter als ASN.1 ist. Es hat viel bessere Dokumentation als Thrift tut, aber, ist ein Google-Produkt, es ist sehr wahrscheinlich, instabil zu sein (im Sinne von sich ständig verändernden, nicht im Sinne unzuverlässig). die IDL ist auch C-like.

Alle oben genannten Systeme ein Schema in irgendeiner Art von IDL definiert verwenden Code für eine Zielsprache zu erzeugen, die dann in die Codierung und Decodierung verwendet wird. Avro nicht. Avro typing ist dynamisch und seine Schemadaten zur Laufzeit direkt sowohl zu kodieren und dekodieren verwendet (was einige offensichtlich Kosten bei der Verarbeitung, aber auch einige offensichtlichen Vorteile gegenüber dynamische Sprachen und fehlende Notwendigkeit für Tagging-Typen, etc.) . Sein Schema verwendet JSON, die in einer neuen Sprache Avro Unterstützung einfacher etwas macht, um zu verwalten, wenn es bereits eine JSON-Bibliothek. Auch hier, wie bei den meisten Rad-neu zu erfinden Protokollbeschreibung Systemen wird Avro auch nicht standardisiert.

Persönlich trotz meiner Liebe / Hass-Beziehung mit ihm, würde ich wahrscheinlich verwenden ASN.1 für die meisten RPC und Nachrichtenübertragungszwecke, obwohl sie nicht wirklich einen RPC-Stack (man müßte man machen, aber IOCs machen, die einfach genug).

Answer 2

Wir haben nur eine interne Studie über Serializer, hier sind einige Ergebnisse (für meine zukünftige Referenz auch!)

Thrift = Serialisierung + RPC-Stack

Der größte Unterschied ist, dass Thrift nicht nur ein Serialisierung-Protokoll ist, dann ist es ein Blas- RPC-Stack, der wie ein moderner SOAP-Stack ist. So nach der Serialisierung, die Objekte könnte (aber nicht vorgeschrieben) zwischen Maschinen über TCP / IP gesendet werden. In SOAP, begann man mit einem WSDL-Dokument, das die verfügbaren Dienste (Remote-Methoden) und die erwarteten Argumente / Objekte vollständig beschreibt. Diese Objekte wurden über XML gesendet. In Thrift, beschreibt die .thrift Datei vollständig die zur Verfügung stehenden Methoden, erwartete Parameterobjekte und die Objekte werden über eine des verfügbaren Serializer (mit Compact Protocol, einem effizienten Binärprotokolls, wobei beliebteste in der Produktion) serialisiert werden.

ASN.1 = Grand Daddy

ASN.1 von Telekom-Leute in den 80er Jahren entwickelt wurde und ist umständlich aufgrund der begrenzten Bibliotheksunterstützung zu verwenden, wie auf den letzten Serializer verglichen, die aus CompSci Leute entstanden. Es gibt zwei Varianten, DER (binär) kodiert und PEM (ascii) Codierung. Beide sind schnell, aber DER ist schneller und Größe effizient der beiden. In der Tat kann ASN.1 DER halten leicht (und manchmal schlagen) Serializer, die entworfen wurden 30 Jahre nach sich, ein Beweis für es ausgereiftes Design. Es ist sehr kompakt, kleiner als Protocol Buffers und Thrift, nur durch Avro geschlagen. Das Problem wird mit großen Bibliotheken zu Unterstützung und jetzt scheint Bouncy Castle die beste für C # / Java zu sein. ASN.1 ist König in Sicherheit und Kryptosystemen und wird nicht weggehen, also nicht besorgt sein über ‚Zukunftssicherheit‘. Nehmen Sie einfach eine gute Bibliothek ...

Message = Mitte der Packung

Es ist nicht schlecht, aber es ist weder die schnellste, noch die kleinste noch die besten unterstützt. Kein Produktions Grund, sie zu wählen.

Allgemein

Darüber hinaus sind sie ziemlich ähnlich. Die meisten sind Varianten des Grund TLV: Type-Length-Value Prinzip.

Protocol Buffers (Google stammt), Avro (Apache basiert, verwendet in Hadoop), Thrift (Facebook entstanden, jetzt Apache-Projekt) und ASN.1 (Telecom entstanden) alle ein gewisses Maß an Codegenerierung voraus, in dem Sie zuerst Ihre Daten ausdrücken in einem Serializer spezifischen Format, dann wird der Serializer „Compiler“ wird Quellcode für Ihre Sprache über die code-gen Phase erzeugen. Ihre App Quelle verwendet dann diese code-gen Klassen für IO. Beachten Sie, dass bestimmte Implementierungen (zB: Microsofts Avro Bibliothek oder Marc Hammer des ProtoBuf.NET) können Sie Ihre App-Ebene POCO / POJO Objekte direkt dekorieren und verwendet dann die Bibliothek direkt jene eingerichteten Klassen statt irgendwelchen Code-gen der Klassen. Wir haben dieses Angebot eine Steigerung der Leistung zu sehen, da es eine Objektkopie Stufe eliminiert (aus Anwendungsebene POCO / POJO Felder Code-gen Felder).

Einige Ergebnisse und ein Live-Projekt spielt mit

Dieses Projekt ( https://github.com/sidshetye/SerializersCompare ) vergleicht wichtigen Serializer in dem C # Welt. Die Java-Leute haben bereits etwas ähnliches .

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!)

Answer 3

Das Hinzufügen der Leistungsperspektive, Uber kürzlich mehrere dieser Bibliotheken auf ihrem Engineering-Blog ausgewertet:

https://eng.uber.com/trip-data-squeeze/

Der Gewinner für sie? Messagepack + zlib für die Komprimierung

Unser Ziel war es, die Kombination der Codierung Protokolls zu finden und Kompressionsalgorithmus mit dem kompakteste Ergebnis am höchsten Geschwindigkeit. Wir testeten kodiert Protokoll und Kompressionsalgorithmus Kombinationen auf 2219 Pseudo-Zufall anonymisierter Fahrten von Uber New York Stadt (put in einer Textdatei als JSON).

Die Lektion hier ist, dass Ihre Anforderungen treiben die Bibliothek ist das Richtige für Sie. Für Uber konnten sie nicht ein IDL-basiertes Protokoll aufgrund der schemaless Natur der Nachricht verwenden, vorbei sie haben. Dies beseitigt eine Reihe von Optionen. Auch für sie ist es nicht nur roh Codierung / Decodierung Zeit, die ins Spiel kommt, aber die Größe der Daten in Ruhe.

Größe Ergebnisse

Geschwindigkeits Ergebnisse

eingeben

Answer 4

Die eine große Sache über ASN.1 ist, ist, dass ist konzipiert für Beschreibung: nicht Umsetzung. Daher ist es sehr gut im Verstecken / Umsetzung Detail in jeder „echten“ Programmiersprache zu ignorieren.

Es ist die Aufgabe des ASN.1-Compiler zu Encoding Rules gelten für die asn1-Datei und erzeugen aus jedem von ihnen ausführbaren Code. Die Encoding Rules könnte in Codierung Notation (ECN) gegeben werden oder könnte einer der standardisierten diejenigen sein, wie BER / DER, PER, XER / Aufg. Das ist ASN.1 sind die Typen und Strukturen definiert die Encoding Rules die auf der Draht-Kodierung und nicht zuletzt die Compiler überträgt sie an Ihre Programmiersprache.

Die freien Compiler unterstützen C, C ++, C #, Java und Erlang meines Wissens. Die (viel zu teuer und Patent / Lizenzen geritten) kommerzielle Compiler sind sehr vielseitig, in der Regel absolut up-to-date und Unterstützung manchmal noch mehr Sprachen, sondern sehen ihre Websites (OSS Nokalva, Marben usw.).

Es ist überraschend einfach eine Schnittstelle zwischen den Parteien von völlig unterschiedlichen Programmier Kulturen angeben (zB „embedded“ Menschen und „Server Bauern“.) Unter Verwendung dieser Techniken: eine ASN.1-Datei, die Kodierung der Regel zum Beispiel BER und ein z.B. UML Interaktionsdiagramm. Keine Sorgen, wie sie umgesetzt wird, damit jeder Einsatz „ihr Ding“! Für mich hat es sehr gut funktioniert. Btw .: Bei OSS Nokalva Website Sie mindestens zwei Free-to-Download-Bücher über ASN.1 (ein von Larmouth der andere von Dubuisson) finden können.

IMHO die meisten anderen Produkte versuchen nur noch-ein anderes-RPC-Stub-Generatoren zu sein, viel Luft in die Serialisierung Problem zu pumpen. Nun, wenn man braucht, dass man könnte in Ordnung sein. Aber für mich, sie sehen aus wie Neuerfindungen von Sun-RPC (aus dem späten 80.), aber, hey, das gut funktioniert, auch.

Answer 5

Microsofts Bond ( https://github.com/Microsoft/bond ) ist sehr beeindruckend mit Leistung , Funktionalitäten und Dokumentation. Allerdings ist es nicht viele Zielplattformen ab sofort (13. Februar 2015) unterstützen. Ich kann nur annehmen, dass es ist, weil es sehr neu ist. Derzeit unterstützt es Python, C # und C ++. Sie wird von MS überall verwendet. Ich versuchte es, mir als ac # -Entwickler mit Bindung besser ist als protobuf verwenden, aber ich verwendet Sparsamkeit haben auch das einzige Problem, das ich konfrontiert mit der Dokumentation war, habe ich viele Dinge zu versuchen, hatte zu verstehen, wie die Dinge getan werden.

Nur wenig Ressourcen auf Bond sind wie folgt ( https://news.ycombinator.com/item? id = 8866694 , https://news.ycombinator.com/item?id=8866848 , https://microsoft.github.io/bond/why_bond.html)

Answer 6

Für Leistung, einen Datenpunkt ist jvm-Serializer Benchmark - es ist ganz spezifischer, kleine Nachrichten, aber könnte helfen, wenn Sie sind auf Java-Plattform. Ich denke, die Leistung in der Regel oft nicht der wichtigste Unterschied. Auch: Nehmen Sie NIEMALS Autoren Worte als Evangelium; viele beworbenen Ansprüche sind gefälschte (msgpack Website zum Beispiel hat einige zweifelhafte Ansprüche, es schnell sein kann, aber die Informationen sehr lückenhaft, Anwendungsfall nicht sehr realistisch).

Ein großer Unterschied ist, ob ein Schema verwendet werden muss (PB, Thrift zumindest, Avro es optional sein kann; ASN.1 Ich denke auch, MsgPack, die nicht unbedingt).

Auch: meiner Meinung nach ist es gut zu können, benutzen schichtete, modulares Design; das heißt, RPC-Ebene sollte nicht dictate Datenformat, Serialisierung. Leider diese die meisten Kandidaten haben eng bündeln.

Wenn schließlich Datenformat wählen, funktioniert heutzutage Leistung nicht aus, dass die Verwendung von Textformaten. Es gibt extrem schnellen JSON-Parser (und ziemlich schnell Streaming XML-Parser); und wenn die Interoperabilität von Skriptsprachen und Benutzerfreundlichkeit unter Berücksichtigung binäre Formate und Protokolle möglicherweise nicht die beste Wahl sein.