Найбільші відмінності буфера від протоколу до протоколу?

286

Які найбільші плюси і мінуси Apache Thrift vs протокольних буферів Google ?

serialization protocol-buffers thrift

— Йонас
джерело

4

У якості додаткової примітки, Марк Гравелл підтримує бібліотеку для роботи з протобуфом Googles під назвою protobuf.net, і це за адресою code.google.com/p/protobuf-net

— RCIX,

5

На це запитання та деякі наступні відповіді приблизно 6 років. Напевно, багато чого змінилося з тих пір.

— АлікЕльзін-кілака

159

Вони обидва пропонують багато однакових можливостей; однак, є деякі відмінності:

Ощадливість підтримує "винятки"
Буфери протоколів мають набагато кращу документацію / приклади
Ощадливість має вбудований Setтип
Буфери протоколів дозволяють "розширення" - ви можете розширити зовнішній протокол, щоб додати додаткові поля, при цьому все ще дозволяючи зовнішньому коду працювати над значеннями. У Thrift немає можливості зробити це
Я вважаю, що буфери протоколів набагато простіше читати

В основному вони досить рівноцінні (буфери протоколів трохи ефективніші від того, що я прочитав).

— туман
джерело

16

Ця презентація роз'яснює їх, а також слайд-сайт

— BAR

13

бережливість підтримує як ще 10 мов

— Ілля Саункін

1

Для деяких мов можна додати розширення. Наприклад, Thrift генерує часткові класи для C #, які легко розширити. Однак це не загальне правило, це правда.

— JensG

підтримка grpc 1.0 (proto3) mapтакож

— KindDragon

85

Ще одна важлива відмінність - це мови, які підтримуються за замовчуванням.

Буфери протоколів: 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

Обидва можуть бути розширені на інші платформи, але це мовні прив’язки, доступні поза коробкою.

— Майк Грей
джерело

16

protobuf має чудову підтримку рубіну github.com/macks/ruby-protobuf та code.google.com/p/ruby-protobuf . Я використовую протобуф із C # (3.5) та Ruby, C # серіалізує дані, а коли потрібно, Ruby десеріалізує та працюю над завданням.

— Брайан Бейліаш

6

code.google.com/p/protobuf/wiki/ThirdPartyAddOns перелічує PHP, Ruby, Erlang, Perl, Haskell, C #, OCaml плюс Actiona Script, Common Lisp, Go, Lua, Mathlab, Visual Basic, Scala. Думаю, що це все сторонні реалізації.

— Ігор Гатіс

ви можете безпосередньо використовувати файли протобуфа C ++ в цілі c (і для iOS, і для OS X), перевірити цей qn

— Tushar Koul

Я бачу code.google.com/p/protobuf-net часто згадується як порт протобуфа для C #, але це не зовсім вірно. Однією з важливих особливостей Protobuf і Thrift є визначення зовнішньої структури, тому одне і те ж визначення може використовуватися різними мовами. protobuf-net не підтримує цю функцію, оскільки вбудовує визначення структури всередині коду C #.

— Андрій Тиличко

@AndyT: Це дискусійно - це залежить від того, чи є перевагою те, що визначення структури є ВНУТРІШНІМ для всіх мов, які ви хочете підтримувати. За допомогою протобуф-мережі ви визначаєте свою структуру даних у C # та генеруєте з цього файл .proto, який потім може бути використаний для створення підтримки іншими мовами. Я вважаю це перевагою, оскільки я дуже C # -центричний і перебуваю в процесі інтеграції Android / Java з великим існуючим додатком .Net. Тому я хочу продовжувати розглядати мої класи C # як остаточні визначення структури.

— RenniePet

73

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

— сайдіму апале
джерело

9

Це не правда. Буфери протоколів визначають api служби RPC і є деякі бібліотеки, доступні для здійснення передачі повідомлення.

— Стефан

7

Я не сказав, що у Protobuf не визначено RPC, просто, здається, він не був призначений для цього, принаймні, не до зовнішнього випуску, до якого всі мають доступ. Прочитайте цей коментар інженера Google тут

— saidimu apale

9

Що ще важливіше, Thrift має вбудовану підтримку RPC. Protobuf в даний час покладається на сторонні бібліотеки, тобто менше очей, менше тестування, менш надійний код.

— Алек Томас

2

Для мене це хороший момент про ProtoBuf. Якщо вам потрібно лише серіалізувати, ви не додаєте марний код. І якщо в майбутньому вам потрібно буде надіслати його за допомогою RPC, не проблема, це може працювати. Я використовую Netty для мережі, а Protobuf просто ідеально інтегрований, тому немає проблем, не тестуйте, а максимізуйте продуктивність.

— Кіківа

14

Фактично, протобуфи були розроблені з урахуванням RPC. Google лише нещодавно відкрив цей компонент - grpc.io

— andybons

57

Протобуфні серіалізовані об'єкти приблизно на 30% менше, ніж ощадливість.
Більшість дій, які ви хочете зробити з об’єктами протобуфа (створювати, серіалізувати, десеріалізувати), набагато повільніше, ніж ощадливість, якщо не вмикати option optimize_for = SPEED.
Ощадливість має більш багаті структури даних (карта, набір)
API протобуфа виглядає чистіше, хоча генеровані класи запаковані як внутрішні класи, що не так приємно.
Ощадливі перерахунки не є справжніми Java Enums, тобто вони просто ints. У Protobuf є справжні переліки Java.

Щоб детальніше ознайомитись з відмінностями, перевірте, чи не відрізняється вихідний код у цьому проекті з відкритим кодом .

— ейшай
джерело

1

Швидка пропозиція: було б акуратно, якби в якості базової лінії використовувався інший небінарний формат (xml або json?). Не було хороших тестів, які б показували загальні тенденції - припущення полягає в тому, що PB і Thrift є більш ефективними, але якщо і на скільки, якщо так, це питання в основному є відкритим.

— StaxMan

4

0,02 секунди ?! У мене немає такого запасного часу

— Кріс С

1

Тепер, коли у Thrift є кілька протоколів (включаючи TCompactProtocol), я думаю, що перша куля більше не застосовується.

— Янус Трольсен

13

Опція оптимізації для швидкості тепер за замовчуванням для буферів протоколів ( code.google.com/apis/protocolbuffers/docs/proto.html )

— Віллем

5

Чи отримуємо ми на 30% менше об’єктів із набором "optimize_for = speed"? Або це компрометовано?

— Прашант Шарма

56

Як я вже говорив як тема "Ощадливість проти протоколів" :

Посилаючись на порівняння Thrift vs Protobuf vs 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
Підтримка протобуфа для інших мов (включаючи Lua, Matlab, Ruby, Perl, R, Php, OCaml, Mercury, Erlang, Go, D, Lisp) доступна як додатки сторонніх розробників (btw. Ось підтримка SWI-Prolog ).
Протобуф має набагато кращу документацію та безліч прикладів.
Ощадливість поставляється з хорошим навчальним посібником
Об'єктів протобуфа менше
Protobuf швидший при використанні конфігурації "optimize_for = SPEED"
Thrift має інтегровану реалізацію RPC, тоді як для протобуфа RPC рішення розділені, але доступні (як Zeroc ICE ).
Protobuf випускається під ліцензією BSD-стилю
Thrift випускається за ліцензією Apache 2

Крім того, існує безліч цікавих додаткових інструментів для тих рішень, які можуть вирішити. Ось приклади для Protobuf: Protobuf-wireshark , protobufeditor .

— Grzegorz Wierzowiecki
джерело

10

Зараз це повне коло. Ви опублікували таку саму відповідь на три (подібні) питання, які завжди посилаються на те чи інше. Я відчуваю, що граю в Зельду і пропустив знак.

— Кріс

+ Кріс Хе, я не можу пригадати, як це сталося. Хоча було кілька подібних питань, можливо, я повинен зробити три схожі структури замість циклу. Одного разу ... Це дуже старе питання, і тепер я відповідаю по телефону. У будь-якому випадку, дякую за улов!

— Grzegorz Wierzowiecki

6

«Ощадливість приходить з хорошим підручником» - як смішно. Це найповніший підручник, який я коли-небудь бачив. Як тільки ви захочете зробити щось поруч із TSimpleServer, ви застрягнете там

— Marian Klühspies

У Thrift також є плагін Wireshark: github.com/andrewcox/wireshark-with-thrift-plugin

— CCoder

8

Буфери протоколів, здається, мають більш компактне представлення, але це лише враження, яке я отримую від прочитання довідки про ощадливість. Своїми словами:

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

Крім того, це може бути саме моє враження, але, здається, буфери протоколів мають дещо товстіші абстракції навколо версій структури. У Thrift є деяка підтримка версій, але для цього потрібно докласти трохи зусиль.

— Даніель Шпієк
джерело

1

Чому той факт, що Thrift визнає, що він не є максимально компактним, змушує вас повірити в буфери протоколів?

— Майкл Міор

1

Буфери протоколів використовують цілочисельне кодування змінної довжини як для значень, так і для ідентифікаторів поля. Тож дуже поширеним випадком надсилання поля int з невеликим значенням буде два байти, а не int16 та int32.

— poolie

"Буфери протоколів використовують цільне ціле кодування змінної довжини" - так робить TCompactProtocol

— JensG,

8

Мені вдалося покращити продуктивність за допомогою текстового протоколу порівняно з протобуффом на python. Однак, ніякої перевірки типу чи іншої фантазії utf8 перетворення тощо ..., що пропонує протобуф.

Отже, якщо серіалізація / десеріалізація - це все, що вам потрібно, то, ймовірно, ви можете використовувати щось інше.

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

— dhruvbird
джерело

7

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

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

(EDIT) Ось цікаве порівняння, яке вирішує як різниці розмірів, так і показників продуктивності, а також включає числа для інших форматів (xml, json).

— StaxMan
джерело

3

Тривіально виводити буфер протоколу до текстового подання, яке читається набагато людині, ніж XML: my_proto.DebugString (). Для прикладу, див code.google.com/apis/protocolbuffers/docs/overview.html

— SuperElectric

Звичайно, ditto для всіх бінарних форматів - але це не робить їх читабельними, як є (налагодження на дроті). Гірше, що для протобуфа вам дійсно потрібна схема схем, щоб знати назви полів.

— StaxMan

Thrift підтримує різні, навіть визначені користувачем протоколи. Ви можете використовувати двійковий, компактний, json або щось, що вигадали лише минулого тижня.

— JensG

6

Згідно з wiki, час роботи Thrift не працює в Windows.

5

Я запускаю Thrift в Windows успішно. Використовуйте Windows fork на github.com/aubonbeurre/thrift

— Сергій Подобрий

20

Офіційна філія тепер також підтримує Windows.

— Янус Трольсен

5

@dalle - Алекс P додав підтримку потокової підтримки у програмі Thrift. Зараз це система за замовчуванням для Windows. * NIX за замовчуванням до pthreads. А для підтвердження Януса Т, Thrift тепер повністю підтримує Windows.

— пмонт

21

Це застаріла інформація. Thrift ідеально працює в Windows протягом тривалого часу.

— JensG

6

ProtocolBuffers - Швидше.
Тут є хороший орієнтир:
http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking

Ви також можете заглянути в Авро, оскільки Авро ще швидший.
Microsoft має тут пакет:
http://www.nuget.org/packages/Microsoft.Hadoop.Avro

До речі, найшвидший, що я коли-небудь бачив - це Cap'nProto ;
Реалізацію AC # можна знайти в Github-сховищі Marc Gravell .

— Стефан Штайгер
джерело

4

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

Буфери протоколів розроблені виключно для серіалізації, це не така структура, як Thrift.

— Бабра Каннінгем
джерело

3

Що ви маєте на увазі під рамкою RPC і чим вона відрізняється від gRPC протобуфа ?

— marcelocra

gRPC не пакується разом з протобуфом. Він був розроблений як через 10 років після. Ощадливість поставляється в комплекті з повною рамкою RPC. Це було зроблено разом.

— трилогія

3

Для одного протобуф - це не повна реалізація RPC. Для цього потрібно щось на зразок gRPC.

gPRC дуже повільний порівняно з Thrift:

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

— трилогія
джерело

0

Тут є кілька чудових моментів, і я збираюся додати ще один випадок, якщо сюди перетинає хтось шлях.

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

PS: Дивіться цей чудовий тестовий проект, за допомогою thekvsякого порівнюється багато серіалізаторів, включаючи ощадливість-бінарний, ощадливий компактний та протобуф: https://github.com/thekvs/cpp-serializers

PS: Існує ще один названий серіалізатор, YASякий також дає цю опцію, але це без схем, див. Посилання вище.

— Синапс
джерело

0

Важливо також зазначити, що не всі підтримувані мови порівнюються з ощадливістю або протобуфами. На даний момент справа в реалізації модулів на додаток до основної серіалізації. Не забудьте перевірити орієнтири для того, якою мовою ви плануєте користуватися.

— JSON
джерело