Самые большие различия между Thrift и Protocol Buffers?

Question

Каковы основные плюсы и минусы Apache Thrift против буферов протокола Google?

Answer 1

Они оба предлагают много одинаковых функций; Однако есть некоторые различия:

• Thrift поддерживает "исключения"
• Протоколные буферы имеют намного лучшую документацию / примеры
• Thrift имеет встроенный Set тип
• Буферы протокола допускают "расширения" - вы можете расширять внешний протокол для добавления дополнительных полей, в то же время позволяя внешнему коду работать со значениями. В Thrift нет способа сделать это
• Я считаю, что протокол буфера гораздо проще читать

По сути, они довольно эквивалентны (с тем, что протоколные буферы немного более эффективны из того, что я прочитал).

Answer 2

Еще одним важным отличием являются языки, поддерживаемые по умолчанию.

• Буферы протокола: Java, Android Java, C++, Python, Ruby, C#, Go, Objective-C, Node.js
• Экономия: Java, C++, Python, Ruby, C#, Go, Objective-C, JavaScript, Node.js, Erlang, PHP, Perl, Haskell, Smalltalk, OCaml, Delphi, D, Haxe

Оба могут быть расширены для других платформ, но это привязки к языкам, доступные из коробки.

Answer 3

RPC - еще одно ключевое отличие. Thrift генерирует код для реализации клиентов и серверов RPC, где буферные протоколы, по-видимому, в основном предназначены только для обмена данными.

Answer 4

• Сериализированные объекты Protobuf примерно на 30% меньше, чем Thrift.
• Большинство действий, которые вы можете выполнять с объектами protobuf (создание, сериализация, десериализация), выполняются намного медленнее, чем экономия, если вы не включите их. option optimize_for = SPEED,
• Thrift имеет более богатые структуры данных (Карта, Набор)
• API Protobuf выглядит чище, хотя сгенерированные классы упакованы как внутренние классы, что не так уж и приятно.
• Перечисления Thrift не являются реальными перечислениями Java, то есть являются просто целыми числами. Protobuf имеет настоящие Java-перечисления.

Для более детального изучения различий ознакомьтесь с различиями исходного кода в этом проекте с открытым исходным кодом.

Answer 5

Как я уже сказал в теме "Базы протокола Thrift против протокола":

Ссылаясь на сравнение Thrift против Protobuf против JSON:

• Thrift поддерживает "из коробки" AS3, C++, C#, D, Delphi, Go, Graphviz, Haxe, Haskell, Java, Javascript, Node.js, OCaml, Smalltalk, Typescript, Perl, PHP, Python, Ruby,...
• C++, Python, Java - встроенная поддержка в Protobuf
• Поддержка Protobuf для других языков (включая Lua, Matlab, Ruby, Perl, R, Php, OCaml, Mercury, Erlang, Go, D, Lisp) доступна как сторонние дополнения (кстати, вот поддержка SWI-Prolog).
• Protobuf имеет гораздо лучшую документацию и множество примеров.
• Thrift поставляется с хорошим учебником
• Протобуф объекты меньше
• Protobuf работает быстрее, когда используется "optimize_for = SPEED"
• Thrift имеет встроенную реализацию RPC, в то время как для Protobuf решения RPC разделены, но доступны (как Zeroc ICE).
• Protobuf выпущен под лицензией в стиле BSD
• Thrift выпущен под лицензией Apache 2

Кроме того, существует множество интересных дополнительных инструментов, доступных для этих решений, которые могут решить. Вот примеры для Protobuf: Protobuf-wireshark, protobufeditor.

Answer 6

Протоколные буферы, кажется, имеют более компактное представление, но это только впечатление, которое я получаю, читая технический документ Thrift. Своими словами:

Мы решили не использовать крайнюю оптимизацию хранения (например, упаковывать маленькие целые числа в ASCII или использовать 7-битный формат продолжения) ради простоты и ясности в коде. Эти изменения могут быть легко сделаны, если и когда мы столкнемся с критичным к производительности случаем использования, который требует их.

Кроме того, это может быть просто моим впечатлением, но протоколные буферы, кажется, имеют более толстые абстракции вокруг структурирования версий. Thrift действительно имеет некоторую поддержку версий, но чтобы это произошло, нужно приложить немало усилий.

Answer 7

Я смог добиться лучшей производительности с текстовым протоколом по сравнению с protobuff на python. Однако, нет проверки типов или других необычных преобразований utf8 и т. Д., Которые предлагает protobuff.

Итак, если вам нужна сериализация / десериализация, то вы можете использовать что-то еще.

http://dhruvbird.blogspot.com/2010/05/protocol-buffers-vs-http.html

Answer 8

Я думаю, что большинство из этих моментов упущено из основного факта, что Thrift является платформой RPC, которая может сериализовать данные, используя различные методы (двоичные, XML и т. Д.).

Буферы протокола предназначены исключительно для сериализации, это не фреймворк, как Thrift.

Answer 9

ProtocolBuffers быстрее.
Здесь есть хороший тест:
http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking

Возможно, вы также захотите заглянуть в Avro, поскольку Avro еще быстрее.
У Microsoft есть пакет здесь:
http://www.nuget.org/packages/Microsoft.Hadoop.Avro

Кстати, самый быстрый, который я когда-либо видел, это Cap'nProto;
Реализацию A C# можно найти в Github-репозитории Marc Gravell.

Answer 10

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

Кроме того, оба имеют меньшую поддержку инструментов, чем стандартные форматы, такие как xml (и, возможно, даже json).

(РЕДАКТИРОВАТЬ) Вот интересное сравнение, которое учитывает различия в размерах и производительности, а также включает числа для некоторых других форматов (xml, json).

Answer 11

И, согласно вики, среда выполнения Thrift не работает в Windows.

Answer 12

Я думаю, что основная структура данных другая

1. В буфере протокола используется целое число переменной длины, которое относится к цифровому кодированию переменной длины, превращая число фиксированной длины в число переменной длины для экономии места.
2. Thrift предложил различные типы форматов сериализации (так называемые "протоколы"). Фактически, у Thrift есть две разные кодировки JSON и не менее трех разных методов двоичного кодирования.

В заключение ， эти две библиотеки совершенно разные. Thrift любит универсальный магазин, предоставляющий вам всю интегрированную структуру RPC и множество опций (с поддержкой кросс-языков), в то время как Protocol Buffers более склонен "делать одно и делать это хорошо".

Answer 13

С одной стороны, protobuf не является полной реализацией RPC. Для этого требуется что-то вроде gRPC.

gPRC очень медленный по сравнению с Thrift:

http://szelei.me/rpc-benchmark-part1/

Answer 14

Здесь есть несколько отличных моментов, и я собираюсь добавить еще один, если кто-то пересечет здесь путь.

Thrift дает вам возможность выбирать между Thrift-двоичным и Thrift-компактным (де) сериализатором, Thrift-двоичный файл будет иметь отличную производительность, но больший размер пакета, в то время как Thrift-Compact даст вам хорошее сжатие, но требует большей вычислительной мощности. Это удобно, потому что вы всегда можете переключаться между этими двумя режимами так же легко, как менять строку кода (черт, даже сделать ее настраиваемой). Так что, если вы не уверены, насколько ваше приложение должно быть оптимизировано для размера пакета или вычислительной мощности, экономия может быть интересным выбором.

PS: Посмотрите на этот отличный эталонный проект thekvs который сравнивает многие сериализаторы, включая thrift-binary, thrift-compact и protobuf: https://github.com/thekvs/cpp-serializers

PS: есть еще один сериализатор по имени YAS что также дает эту опцию, но это без схемы, см. ссылку выше.

Answer 15

Также важно отметить, что не все поддерживаемые языки совместимы с Thrift или Protobuf. На данный момент речь идет о реализации модулей в дополнение к базовой сериализации. Позаботьтесь о том, чтобы проверить контрольные показатели для любого языка, который вы планируете использовать.