Каковы основные различия между Apache Thrift, буфером протокола Google, MessagePack, ASN.1 и Apache Avro? - PullRequest
120 голосов
/ 08 января 2011

Все они обеспечивают двоичную сериализацию, платформы RPC и IDL. Меня интересуют ключевые различия между ними и характеристиками (производительность, простота использования, поддержка языков программирования).

Если вам известны другие подобные технологии, укажите это в ответе.

Ответы [ 6 ]

95 голосов
/ 08 января 2011

ASN.1 - это стандарт ISO / ISE.Он имеет очень читаемый исходный язык и различные фоны, как бинарные, так и читабельные.Будучи международным стандартом (и в то же время старым!), Исходный язык немного кухонный (примерно так же, как Атлантический океан немного влажный), но он очень хорошо определен и имеет приличную поддержку,(Вероятно, вы можете найти библиотеку ASN.1 для любого языка, который вы называете, если вы достаточно усердно копаете, и если нет, то есть хорошие библиотеки языков C, которые вы можете использовать в FFI.) Это, будучи стандартизированным языком, одержимо документировано итакже есть несколько хороших учебных пособий.

Экономия не является стандартом.Он изначально из Facebook, позже был открыт с открытым исходным кодом и в настоящее время является проектом Apache высшего уровня.Это не очень хорошо документировано - особенно уровни обучения - и, на мой взгляд (по общему признанию, краткий), кажется, не добавляет ничего, что другие предыдущие усилия уже не делают (а в некоторых случаях лучше).Чтобы быть справедливым, у него есть довольно внушительное количество языков, которые он поддерживает из коробки, в том числе несколько высококлассных неосновных.IDL также имеет неопределенную C-образность.

Буферы протокола не является стандартом.Это продукт Google, который выпускается для более широкого сообщества.Он немного ограничен с точки зрения языков, поддерживаемых «из коробки» (он поддерживает только C ++, Python и Java), но имеет много сторонней поддержки для других языков (с очень изменчивым качеством).Google выполняет почти всю свою работу с использованием буферов протоколов, поэтому это проверенный в бою, закаленный в боях протокол (хотя и не такой закаленный в боях, как ASN.1. Он имеет гораздо лучшую документацию, чем Thrift, но, будучиПродукт Google, он, скорее всего, будет нестабильным (в смысле постоянно меняющегося, а не ненадежного). IDL также является C-подобным.

Все вышеперечисленные системы используют схему, определеннуюв некотором виде IDL для генерации кода для целевого языка, который затем используется при кодировании и декодировании. Avro нет. Типизация Avro является динамической, и ее данные схемы используются во время выполнения непосредственно как для кодирования, так и для декодирования (что имеет некоторые очевидные затраты вобработки, но также есть некоторые очевидные преимущества для динамических языков и отсутствие необходимости в типах тегов и т. д.) В его схеме используется JSON, что делает управление Avro на новом языке немного проще, если уже есть библиотека JSON.Опять же, как и в большинстве систем описания протоколов колесных изобретений, Avro также нестандартизированный.

Лично, несмотря на мои отношения любви / ненависти с ним, я бы, вероятно, использовал ASN.1 для большинства RPC и целей передачи сообщений, хотя на самом деле у него нет стека RPC (вы бы имеличтобы сделать один, но МОК сделать это достаточно просто).

37 голосов
/ 27 декабря 2013

Мы только что провели внутреннее исследование по сериализаторам, вот некоторые результаты (для моего будущего ознакомления!)

Экономия = сериализация + стек RPC

Самым большим отличием является то, что Thrift - это не просто протокол сериализации, это полноценный стек RPC, похожий на современный SOAP-стек. Таким образом, после сериализации объекты могут (но не обязательно) передаваться между машинами по TCP / IP. В SOAP вы начали с документа WSDL, который полностью описывает доступные службы (удаленные методы) и ожидаемые аргументы / объекты. Эти объекты были отправлены через XML. В Thrift файл .thrift полностью описывает доступные методы, ожидаемые объекты параметров и объекты сериализуются через один из доступных сериализаторов (с Compact Protocol, эффективным двоичным протоколом, наиболее популярным в производстве).

ASN.1 = Великий папа

ASN.1 был разработан телекоммуникационными специалистами в 80-х годах и является неудобным для использования из-за ограниченной поддержки библиотек по сравнению с недавними сериализаторами, появившимися у людей из CompSci. Существует два варианта: DER (двоичное) кодирование и PEM (ascii) кодирование. Оба быстры, но DER быстрее и эффективнее по размерам. Фактически, ASN.1 DER может легко поддерживать (и иногда побеждать) сериализаторы, которые были спроектированы 30 лет , что является свидетельством его хорошо спроектированной конструкции. Он очень компактен, меньше, чем Protocol Buffers and Thrift, только побежденный Avro. Проблема в том, что есть отличные библиотеки для поддержки, и сейчас Bouncy Castle кажется лучшим для C # / Java. ASN.1 является королем систем безопасности и криптографии и не собирается уходить, так что не беспокойтесь о «проверке будущего». Просто возьми хорошую библиотеку ...

MessagePack = середина пакета

Это не плохо, но не самый быстрый, не самый маленький и не самый лучший поддерживаемый. Нет производственных причин, чтобы выбрать его.

Общее

Кроме того, они довольно похожи. Большинство из них являются вариантами базового принципа TLV: Type-Length-Value.

Протокольные буферы (созданный Google), Avro (на основе Apache, используемый в Hadoop), Thrift (созданный на Facebook, в настоящее время проект Apache) и ASN.1 (созданный для Telecom) - все они включают некоторый уровень генерации кода, когда вы впервые выражаете свои данные в формате, специфичном для сериализатора, «компилятор» сериализатора сгенерирует исходный код для вашего языка через фазу code-gen. Ваш источник приложения затем использует эти code-gen классы для ввода-вывода. Обратите внимание, что некоторые реализации (например, библиотека Avro от Microsoft или ProtoBuf.NET от Marc Gavel) позволяют напрямую декорировать объекты POCO / POJO уровня приложения, а затем библиотека напрямую использует эти декорированные классы вместо классов любого кода-поколения. Мы видели, как это предложение повышает производительность, поскольку устраняет этап копирования объекта (от полей POCO / POJO уровня приложения до полей кода).

Некоторые результаты и живой проект для игры с

Этот проект (https://github.com/sidshetye/SerializersCompare) сравнивает важные сериализаторы в мире C #. У Java-людей уже есть нечто похожее .

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!)
11 голосов
/ 09 апреля 2016

Помимо оценки производительности, Uber недавно проверил несколько из этих библиотек в своем инженерном блоге:

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

Победитель для них? MessagePack + zlib для сжатия

Нашей целью было найти комбинацию протокола кодирования и алгоритм сжатия с самым компактным результатом на самом высоком скорость. Мы проверили протокол кодирования и алгоритм сжатия комбинаций в 2219 псевдослучайных анонимных поездках из Uber New York Город (укажите в текстовом файле как JSON).

Урок здесь заключается в том, что ваши требования определяют, какая библиотека вам подходит. Для Uber они не могли использовать протокол, основанный на IDL, из-за отсутствия схемы передачи сообщений, которую они имеют. Это исключило кучу вариантов. Также для них в игру вступает не только время сырого кодирования / декодирования, но и размер данных в состоянии покоя.

Размер Результаты

Size Results

Результаты скорости

enter image description here

11 голосов
/ 04 ноября 2012

Единственная важная особенность ASN.1 заключается в том, что она предназначена для реализации спецификации , а не .Поэтому он очень хорошо скрывает / игнорирует детали реализации на любом «реальном» языке программирования.

Задача компилятора ASN.1 - применять правила кодирования к файлу asn1 и генерировать их обаисполняемый кодПравила кодирования могут быть приведены в нотации кодирования (ECN) или могут быть одним из стандартизированных, таких как BER / DER, PER, XER / EXER.То есть ASN.1 - это Типы и Структуры, Правила кодирования определяют кодировку на проводе, и, наконец, Компилятор переносит ее на ваш язык программирования.

Бесплатные компиляторы поддерживают C, C ++, C #, Java и Erlang, насколько мне известно.Коммерческие компиляторы (очень дорогие и на основе патентов / лицензий) очень универсальны, обычно абсолютно современны и поддерживают иногда даже больше языков, но видят их сайты (OSS Nokalva, Marben и др.).

Удивительно легко определить интерфейс между участниками совершенно разных культур программирования (например, «внедренные» люди и «фермеры-серверы»), используя эти методы: файл asn.1, правило кодирования, например, BER и, например, диаграмму взаимодействия UML,Не беспокойтесь, как это реализовано, пусть каждый использует "свое дело"!Для меня это сработало очень хорошо.Кстати: на сайте OSS Nokalva вы можете найти как минимум две бесплатные книги об ASN.1 (одну от Larmouth, другую от Dubuisson).

ИМХО, большинство других продуктов стараются только пока-прочие-RPC-заглушки-генераторы, накачивающие много воздуха в проблему сериализации.Ну, если кому-то это нужно, все будет в порядке.Но для меня они выглядят как переизобретения Sun-RPC (с конца 80-х), но, эй, это тоже сработало.

6 голосов
/ 13 февраля 2015

Облигация Microsoft (https://github.com/Microsoft/bond) очень впечатляет производительностью, функциональностью и документацией. Однако на данный момент она не поддерживает много целевых платформ (13 февраля 2015 г.). Я могу только предположить, что это потому, что она очень новаяВ настоящее время он поддерживает Python, C # и C ++. Он используется MS повсеместно. Я попробовал это, для меня, как AC # разработчик, использование Bond лучше, чем использование protobuf, однако я также использовал Thrift, единственная проблема, с которой я столкнулся, был сДокументация, мне пришлось попробовать много вещей, чтобы понять, как это делается.

Несколько ресурсов на Бонд следующие (https://news.ycombinator.com/item?id=8866694, https://news.ycombinator.com/item?id=8866848, https://microsoft.github.io/bond/why_bond.html)

5 голосов
/ 12 января 2011

Для производительности одной точкой данных является jvm-serializer benchmark - это довольно конкретные небольшие сообщения, но они могут помочь, если вы работаете на платформе Java.Я думаю, что производительность в целом часто не будет самым важным отличием.Также: НИКОГДА не воспринимайте слова авторов как Евангелие;многие рекламируемые утверждения являются поддельными (например, на сайте msgpack есть некоторые сомнительные утверждения; это может быть быстро, но информация очень схематична, случай использования не очень реалистичен).

Одно большое различие заключается в том, должна ли использоваться схема (PB, по крайней мере, Thrift; Avro может быть необязательным; я также думаю, что ASN.1; MsgPack, не обязательно).

Также: по моему мнению, хорошо иметь возможность использовать многоуровневую модульную конструкцию;то есть уровень RPC не должен диктовать формат данных, сериализацию.К сожалению, большинство кандидатов тесно связывают их.

Наконец, при выборе формата данных, производительность в наше время не исключает использования текстовых форматов.Есть невероятно быстрые парсеры JSON (и довольно быстрые потоковые парсеры xml);и, учитывая совместимость языков сценариев и простоту использования, двоичные форматы и протоколы могут оказаться не лучшим выбором.

...