Які ключові відмінності між Apache Thrift, буферами протоколів Google, MessagePack, ASN.1 та Apache Avro?


124

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

Якщо ви знаєте будь-які інші подібні технології, будь ласка, зазначте це у відповіді.



@Zenikoder: Це посилання не містить жодної інформації для 2 із 5 запитуваних форматів.
ДАЙТЕ МОЕ правильне ДУМКА

чи могло це допомогти: slideshare.net/IgorAnishchenko/pb-vs-thrift-vs-avro ?
торок

2
для тих, хто не знає RPC - Remote Prodecure Call, IDL - Мова визначення інтерфейсу
garg10may

Відповіді:


97

ASN.1 - стандарт ISO / ISE. Він має дуже читану мову джерела та різноманітні зворотні сторони, як бінарні, так і людські. Будучи міжнародним стандартом (і старим у цьому!), Мова-джерело трохи кухонний (приблизно так само, як Атлантичний океан трохи мокрий), але він надзвичайно чітко визначений і має гідну кількість підтримки . (Напевно, ви можете знайти бібліотеку ASN.1 для будь-якої мови, яку ви назвете, якщо викопати досить важко, а якщо ні, то є хороші бібліотеки мови С, які ви можете використовувати у FFI.) Це, будучи стандартизованою мовою, нав'язливо документовано та також є кілька хороших навчальних посібників.

Ощадливість - це не стандарт. Він родом з Facebook, пізніше був відкритим і зараз є проектом Apache вищого рівня. Це недостатньо задокументовано - особливо рівні навчальних посібників - і на мій (правда кажучи, короткий) погляд, здається, не додає нічого іншого, що попередні зусилля вже не роблять (а в деяких випадках і краще). Справедливості до цього, у нього є досить вражаюча кількість мов, які він підтримує нестандартно, включаючи декілька непрофільних мов. IDL також невиразно схожий на С.

Буферні протоколи - це не стандарт. Це продукт Google, який випускається для широкої спільноти. Він дещо обмежений з точки зору мов, які підтримуються поза коробкою (він підтримує лише C ++, Python та Java), але у нього є багато сторонньої підтримки для інших мов (дуже різної якості). Google виконує майже всю свою роботу, використовуючи буфери протоколів, тому це протокол, перевірений боєм, захищений від бою (хоч і не такий загартований у бою, як ASN.1. Він має набагато кращу документацію, ніж бережливість, але, будучи Продукт Google, він, ймовірно, нестабільний (у сенсі постійно змінюється, а не в сенсі ненадійного). ІДЛ також схожий на С.

Усі перераховані вище системи використовують схему, визначену в якомусь вигляді IDL, щоб генерувати код для цільової мови, який потім використовується при кодуванні та декодуванні. Авро ні. Типізація Avro є динамічною, і її схематичні дані використовуються під час виконання безпосередньо як для кодування, так і для декодування (що має деякі очевидні витрати на обробку, але також і деякі очевидні переваги щодо динамічних мов та відсутність потреби в маркуванні типів тощо). . Його схема використовує JSON, що робить підтримку Avro новою мовою трохи простішою в управлінні, якщо вже є бібліотека JSON. Знову ж таки, як і у більшості систем опису протоколів на винаході колеса, Avro також не стандартизований.

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


3
Дякую за детальне пояснення. А як щодо версій, я чув, що protobuf може впоратися з цим, а що стосується інших бібліотек і як це можна використовувати спільно? Крім того, здається, Avro тепер має IDL з C-подібним синтаксисом на додаток до JSON.
andreypopp

2
ASN.1 підтримує вручну версію через ...маркери розширень або автоматичну передачу EXTENSIBILITY IMPLIEDв заголовку модуля. Буфери протоколів, IIRC, підтримують ручну версію. Я не знаю, чи підтримує це щось на зразок мається на увазі розширюваність (і я лінивий, щоб це шукати). Thrift також підтримує деяку версію, але знову це вражає мене як ручний процес, не маючи на увазі розширення.
ДАЙТЕ МОЕ правильне ДУМКА

7
Для запису буфери протоколів завжди явно кодують поля за номерами, і це ніколи не є помилкою на рівні бібліотеки, якщо є додаткові поля, а відсутні місця не є помилкою, якщо вони позначені необов’язковими або явними. Таким чином, всі буфери протоколів мають EXTENSIBILITY IMPLIED.
Кевін Кеткарт

під МОК - ти маєш на увазі інверсію контролю? що б використовувати для стека RPC в PHP, щось на зразок розширення XML-RPC? чи треба було б щось написати самостійно?
Стенн

4
Avro є більш гнучким, оскільки дозволяє або динамічно працювати за визначеною схемою, або генерувати класи котлованних плит. З мого досвіду, він дуже потужний: його сила полягає в його багатому наборі функцій, включаючи генератор RPC (це спільна риса з Thrift).
Паоло Мареска

38

Ми щойно зробили внутрішнє дослідження серіалізаторів, ось деякі результати (для моєї подальшої довідки!)

Ощадливість = серіалізація + стек 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 роківпісля себе, свідченням добре розробленого дизайну. Він дуже компактний, менший за протоколи буфера та ощадливості, тільки побитий 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класи для IO. Зауважте, що певні реалізації (наприклад, бібліотека 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!)

3
ASN.1 також має BER (основні правила кодування), PER (правила упакованого кодування) та XER (правила кодування XML). DER - це варіант BER, який використовується в основному для криптографії, оскільки він гарантує унікальне кодування для кожної дати. І BER, і PER можуть бути ефективнішими, ніж DER. Більшість бібліотек обробляє DER. Деякі не працюють з усіма конструкціями BER правильно. Для тих, хто зацікавлений дізнатися більше: luca.ntop.org/Teaching/Appunti/asn1.html
Джо Стіл

Він також має JER - Правила кодування Notation Object Notation Notation. Ви також можете визначити власні правила кодування за допомогою ECN (Encoding Control Notation). Хороший список специфікацій із посиланнями для завантаження: oss.com/asn1/resources/standards-define-asn1.html
Дмитро

There are two variants, DER (binary) encoding and PEM (ascii) encoding. Майте на увазі, що PEM - це лише двійкові дані, кодовані базовою 64, всередині коментарів BEGIN END. Ці двійкові дані можуть бути створені за допомогою кодування DER, тому дивно порівнювати PEM і DER.
RafalS

14

Додаючи перспективу продуктивності, Uber нещодавно оцінив декілька таких бібліотек у своєму інженерному блозі:

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

Переможець для них? MessagePack + zlib для стиснення

Нашою метою було знайти комбінацію протоколу кодування та алгоритму стиснення з найбільш компактним результатом з максимальною швидкістю. Ми протестували комбінацію протоколів кодування та комбінацій алгоритмів стиснення на 2219 псевдовипадкових анонімізованих подорожах з міста Uber Нью-Йорк (поміщені в текстовий файл як JSON).

Урок полягає в тому, що ваші вимоги визначають, яка бібліотека підходить саме вам. Для Uber вони не могли використовувати протокол на основі IDL через безсхемовий характер передачі повідомлень. Це усунуло купу варіантів. Крім того, для них не тільки сирий час кодування / декодування, який вступає в гру, але і розмір даних у спокої.

Розмір результатів

Розмір результатів

Результати швидкості

введіть тут опис зображення


13

Одна велика річ про ASN.1 є, що IST призначений для специфікації НЕ реалізації. Тому дуже добре приховувати / ігнорувати деталі реалізації будь-якою "реальною" мовою програмування.

Завдання 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 (одну - від Лармута, другу - для Дубюссона).

IMHO більшість інших продуктів намагаються бути ще одним - ще одним RPC-генератором-заглушкою, закачуючи багато повітря в проблему серіалізації. Ну, якщо комусь це потрібно, можливо, все буде добре. Але для мене вони виглядають як винаходи Sun-RPC (з кінця 80-х), але, еге, і це спрацювало чудово.


7

Microsoft Bond ( https://github.com/Microsoft/bond ) дуже вражає продуктивністю, функціональними можливостями та документацією. Однак на сьогоднішній день він не підтримує багато цільових платформ (13 лютого 2015 р.). Я можу лише припустити, що це тому, що він дуже новий. В даний час він підтримує python, c # і c ++. Її використовують МС скрізь. Я спробував це, мені як розробнику ac # використання bond краще, ніж використання protobuf, однак я також використав ощадливість, єдиною проблемою, з якою я стикався, була документація, мені довелося спробувати багато речей, щоб зрозуміти, як це робиться.

Мало ресурсів на Bond є наступними ( https://news.ycombinator.com/item?id=8866694 , https://news.ycombinator.com/item?id=8866848 , https://microsoft.github.io/ bond / why_bond.html )


5

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

Велика різниця полягає в тому, чи потрібно використовувати схему (принаймні PB, ощадливість; Avro, це може бути необов’язково; ASN.1 Я також думаю; MsgPack, не обов'язково).

Також: на мою думку, добре використовувати вміст шаруватого модульного дизайну; тобто рівень RPC не повинен диктувати формат даних, серіалізацію. На жаль, більшість кандидатів це чітко поєднують.

Нарешті, вибираючи формат даних, на сьогоднішній день продуктивність не виключає використання текстових форматів. Є палаючі швидкі парсери JSON (і досить швидкі потокові xml-парсери); і, враховуючи взаємодію з мов скриптів та простоту використання, бінарні формати та протоколи можуть бути не найкращим вибором.


Дякую вам за обмін досвідом, але я думаю, що мені ще потрібен бінарний формат (у мене дійсно величезна кількість даних) і, ймовірно, буду дотримуватися Avro.
andreypopp

Так, може бути сенс тоді. Ви можете використовувати компресію в будь-якій швидкості, незалежно від формату для використання (LZF приємно, оскільки дуже швидко стискати / розтискати, порівняно з gzip / deflate).
StaxMan
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.