Największe różnice między buforami Thrift vs Protocol?

286

Jakie są największe zalety i wady Apache Thrift w porównaniu z buforami protokołów Google ?

serialization protocol-buffers thrift

— Jonas
źródło

4

Na marginesie, Marc Gravell utrzymuje bibliotekę do pracy z protobuf Googles o nazwie protobuf.net i jest na code.google.com/p/protobuf-net

— RCIX

5

To pytanie i niektóre z poniższych odpowiedzi mają około 6 lat. Od tego czasu prawdopodobnie wiele się zmieniło.

— AlikElzin-kilaka

159

Oba oferują wiele takich samych funkcji; istnieją jednak pewne różnice:

Thrift wspiera „wyjątki”
Bufory protokołów mają znacznie lepszą dokumentację / przykłady
Oszczędzanie ma wbudowany Settyp
Bufory protokołów pozwalają na „rozszerzenia” - możesz rozszerzyć zewnętrzny proto, aby dodać dodatkowe pola, jednocześnie pozwalając zewnętrznemu kodowi działać na wartościach. W Thrift nie ma takiej możliwości
Uważam, że bufory protokołów są znacznie łatwiejsze do odczytania

Zasadniczo są one dość równoważne (z buforami protokołów nieco bardziej wydajnymi od tego, co przeczytałem).

— Hazzen
źródło

16

Ta prezentacja wyjaśnia je dobrze z 2013 slideshare.net/IgorAnishchenko/pb-vs-thrift-vs-avro

— BAR

13

thrift obsługuje 10 kolejnych języków

— Elijah Saounkine,

1

W przypadku niektórych języków możesz dodać rozszerzenia. Na przykład Thrift generuje częściowe klasy dla C #, które są łatwe do rozszerzenia. Jednak to nie jest ogólna zasada, to prawda.

— JensG

grpc 1.0 (proto3) wsparcie maptakże

— KindDragon

85

Kolejną ważną różnicą są języki obsługiwane domyślnie.

Bufory protokołów: Java, Android Java, C ++, Python, Ruby, C #, Go, Objective-C, Node.js
Oszczędzanie: Java, C ++, Python, Ruby, C #, Go, Objective-C, JavaScript, Node.js, Erlang, PHP, Perl, Haskell, Smalltalk, OCaml, Delphi, D, Haxe

Oba mogą zostać rozszerzone na inne platformy, ale są to wiązania językowe dostępne od razu po wyjęciu z pudełka.

— Mike Gray
źródło

16

Protobuf ma doskonałą obsługę ruby github.com/macks/ruby-protobuf i code.google.com/p/ruby-protobuf . Używam protobuf z C # (3.5) i Ruby, C # szereguje dane, a gdy jest to wymagane, Ruby deserializuje i pracuje nad zadaniem.

— Bryan Bailliache

6

code.google.com/p/protobuf/wiki/ThirdPartyAddOns wymienia PHP, Ruby, Erlang, Perl, Haskell, C #, OCaml plus Actiona Script, Common Lisp, Go, Lua, Mathlab, Visual Basic, Scala. Pomyśleliśmy, że są to wdrożenia innych firm.

— Igor Gatis

możesz bezpośrednio użyć plików C ++ Protobuf w celu c (zarówno dla iOS, jak i OS X) sprawdź to qn

— Tushar Koul

Widzę, że code.google.com/p/protobuf-net jest często wymieniany jako port protobuf dla C #, ale nie jest to do końca prawda. Jedną z ważnych cech Protobuf i Thrift jest definicja struktury zewnętrznej, więc ta sama definicja może być używana w różnych językach. Protobuf-net nie obsługuje tej funkcji, ponieważ osadza definicję struktury w kodzie C #.

— Andriy Tylychko,

@AndyT: To jest dyskusyjne - zależy od tego, czy zaletą jest to, że definicja struktury jest ZEWNĘTRZNA dla wszystkich języków, które chcesz obsługiwać. Protobuf-net definiuje strukturę danych w języku C # i generuje z niej plik .proto, który można następnie wykorzystać do stworzenia obsługi w innych językach. Uważam to za zaletę, ponieważ jestem bardzo skoncentrowany na C # i jestem w trakcie integracji Androida / Java z dużą istniejącą aplikacją .Net. Dlatego chcę nadal uważać moje klasy C # za definitywne definicje struktur.

— RenniePet

73

RPC to kolejna kluczowa różnica. Thrift generuje kod do implementacji klientów i serwerów RPC, gdzie Bufory protokołów wydają się być zaprojektowane głównie jako sam format wymiany danych.

— saidimu apale
źródło

9

To nieprawda. Bufory protokołów definiują interfejs usługi RPC, a niektóre biblioteki są dostępne do implementacji przekazywania komunikatów.

— Stephen

7

Nie powiedziałem, że Protobuf nie ma zdefiniowanego RPC, po prostu wydaje się, że nie został do tego zaprojektowany, a przynajmniej nie zewnętrzne wydanie, do którego wszyscy mają dostęp. Przeczytaj komentarz inżyniera Google tutaj

— powiedział im apale

9

Co ważniejsze, Thrift ma wbudowaną obsługę RPC. Protobuf polega obecnie na bibliotekach stron trzecich, co oznacza mniej oczu, mniej testów, mniej niezawodny kod.

— Alec Thomas

2

Dla mnie to dobra uwaga na temat ProtoBuf. Jeśli potrzebujesz tylko serializować, nie dodajesz niepotrzebnego kodu. A jeśli w przyszłości musisz wysłać go przez RPC, nie ma problemu, może działać. Używam Netty do sieci, a Protobuf jest po prostu doskonale zintegrowany, więc nie ma problemu, nie testuje i maksymalizuje wydajność.

— Kikiwa

14

Protobufy zostały zaprojektowane z myślą o RPC. Google niedawno pozyskał ten komponent dość niedawno - grpc.io

— andybons

57

Serializowane obiekty Protobuf są około 30% mniejsze niż Thrift.
Większość działań, które możesz chcieć zrobić z obiektami protobuf (tworzenie, serializacja, deserializacja) jest dużo wolniejsza niż oszczędzanie, chyba że włączysz option optimize_for = SPEED.
Oszczędzanie ma bogatsze struktury danych (mapa, zestaw)
Protobuf API wygląda na czystszy, choć wszystkie wygenerowane klasy są spakowane jako klasy wewnętrzne, co nie jest takie miłe.
Wyliczenia oszczędności nie są prawdziwymi wyliczeniami Java, tzn. Są tylko liczbami całkowitymi. Protobuf ma prawdziwe wyliczenia Java.

Aby bliżej przyjrzeć się różnicom, sprawdź różnice w kodzie źródłowym w tym projekcie open source .

— eishay
źródło

1

Szybka sugestia: byłoby fajnie, gdyby jako podstawę zastosowano inny format niebinarny (xml lub json?). Nie było dobrych testów, które wykazywałyby ogólne trendy - zakłada się, że PB i Thrift są bardziej wydajne, ale czy i o ile, jeśli tak, to najczęściej pytanie otwarte.

— StaxMan

4

0,02 sekundy ?! Nie mam tyle wolnego czasu

— Chris S.

1

Teraz, gdy Thrift ma wiele protokołów (w tym TCompactProtocol), myślę, że pierwsza kula nie ma już zastosowania.

— Janus Troelsen

13

Opcja optymalizacji prędkości jest teraz domyślna dla buforów protokołów ( code.google.com/apis/protocolbuffers/docs/proto.html )

— Willem

5

Czy otrzymujemy 30% mniejszych obiektów z ustawionym „optimize_for = speed”? Czy to jest zagrożone?

— Prashant Sharma,

56

Jak powiedziałem w temacie „Thrift vs. Protocol Buffers” :

Odnosząc się do porównania Thrift vs Protobuf vs JSON :

Thrift obsługuje po wyjęciu z pudełka AS3, C ++, C #, D, Delphi, Go, Graphviz, Haxe, Haskell, Java, JavaScript, Node.js, OCaml, Smalltalk, Typescript, Perl, PHP, Python, Ruby, ...
C ++, Python, Java - obsługa In-Box w Protobuf
Wsparcie Protobuf dla innych języków (w tym Lua, Matlab, Ruby, Perl, R, Php, OCaml, Mercury, Erlang, Go, D, Lisp) jest dostępne jako dodatki osób trzecich (btw. Oto wsparcie SWI-Prolog ).
Protobuf ma znacznie lepszą dokumentację i mnóstwo przykładów.
Thrift jest wyposażony w dobry samouczek
Obiekty Protobuf są mniejsze
Protobuf jest szybszy przy użyciu konfiguracji „optimize_for = SPEED”
Thrift ma zintegrowaną implementację RPC, natomiast dla Protobuf rozwiązania RPC są oddzielone, ale dostępne (jak Zeroc ICE ).
Protobuf jest wydany na licencji w stylu BSD
Thrift jest wydany na licencji Apache 2

Ponadto istnieje wiele interesujących dodatkowych narzędzi dostępnych dla tych rozwiązań, które mogą zadecydować. Oto przykłady Protobuf: Protobuf-wireshark , protobufeditor .

— Grzegorz Wierzowiecki
źródło

10

To jest pełne koło. Podałeś dokładnie tę samą odpowiedź na trzy (podobne) pytania, zawsze prowadząc do jednego lub dwóch. Mam wrażenie, że gram w Zeldę i nie trafiłem na żaden znak.

— ChrisR

+ ChrisR heh, nie pamiętam, jak to się stało. Chociaż było kilka podobnych pytań, może powinienem zrobić trzy podobne struktury zamiast cyklu. Pewnego dnia ... To bardzo stare pytanie, a teraz odpowiadam przez telefon. W każdym razie dzięki za złapanie!

— Grzegorz Wierzowiecki

6

„Thrift ma dobry samouczek” - jakie zabawne. To najbardziej niekompletny samouczek, jaki kiedykolwiek widziałem. Gdy tylko chcesz coś zrobić obok TSimpleServer, utkniesz tam

— Marian Klühspies

Thrift też ma wtyczkę Wireshark: github.com/andrewcox/wireshark-with-thrift-plugin

— CCoder

8

Bufory protokołów wydają się mieć bardziej zwartą reprezentację, ale to tylko wrażenie, które czerpię z lektury białej księgi Thrift. Innymi słowy:

Zdecydowaliśmy się na pewne ekstremalne optymalizacje pamięci (np. Pakowanie małych liczb całkowitych do ASCII lub stosowanie 7-bitowego formatu kontynuacji) ze względu na prostotę i przejrzystość kodu. Zmian tych można łatwo dokonać, jeśli napotkamy krytyczny dla wydajności przypadek użycia, który ich wymaga.

Może to po prostu moje wrażenie, ale bufory protokołów wydają się mieć grubsze abstrakcje wokół wersji struktury. Thrift ma pewne wsparcie dla wersji, ale do tego potrzeba trochę wysiłku.

— Daniel Spiewak
źródło

1

Dlaczego fakt, że Thrift przyznaje, że nie jest tak kompaktowy, jak to możliwe, prowadzi do przekonania, że bufory protokołów są?

— Michael Mior

1

Bufory protokołów używają kodowania liczb całkowitych o zmiennej długości, zarówno dla wartości, jak i dla identyfikatorów pól. Tak więc bardzo częstym przypadkiem wysyłania pola int o małej wartości będą dwa bajty, a nie int16 i int32.

— poolie

„Bufory protokołów używają kodowania liczb całkowitych o zmiennej długości” - podobnie TCompactProtocol

— JensG,

8

Byłem w stanie uzyskać lepszą wydajność dzięki protokołowi tekstowemu w porównaniu do protobuffu w Pythonie. Jednak bez sprawdzania typu lub innej fantazyjnej konwersji utf8 itp., Którą oferuje protobuff.

Jeśli więc potrzebujesz serializacji / deserializacji, prawdopodobnie możesz użyć czegoś innego.

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

— dhruvbird
źródło

7

Jedną oczywistą rzeczą, o której jeszcze nie wspomniano, że może być zarówno za, jak i przeciw (i to samo dla obu) jest to, że są to protokoły binarne. Pozwala to na bardziej zwartą reprezentację i być może większą wydajność (zalety), ale przy zmniejszonej czytelności (a raczej możliwości debuggowania), oszustwo.

Oba mają nieco mniej obsługi narzędzi niż standardowe formaty, takie jak xml (a może nawet json).

(EDYCJA) Oto interesujące porównanie, które zajmuje się zarówno różnicami wielkości, jak i wydajności oraz zawiera liczby dla niektórych innych formatów (xml, json).

— StaxMan
źródło

3

Wyjście bufora protokołu do reprezentacji tekstowej, która jest o wiele bardziej czytelna dla człowieka niż XML, jest banalne: my_proto.DebugString (). Na przykład zobacz code.google.com/apis/protocolbuffers/docs/overview.html

— SuperElectric

Oczywiście to samo dotyczy wszystkich formatów binarnych - ale to nie czyni ich możliwymi do odczytania (debugowanie w sieci). Co gorsza, w przypadku protobufa naprawdę potrzebujesz schematu def, aby znać nazwy pól.

— StaxMan,

Thrift obsługuje różne, nawet zdefiniowane przez użytkownika, protokoły. Możesz użyć binarnego, kompaktowego, json lub czegoś, co wynalazłeś w zeszłym tygodniu.

— JensG

6

Według wiki środowisko wykonawcze Thrift nie działa w systemie Windows.

5

Z powodzeniem uruchamiam Thrift w systemie Windows. Użyj Windows Fork

— Sergey Podobry

20

Oficjalna gałąź główna obsługuje teraz także system Windows.

— Janus Troelsen,

5

@dalle - Alex P dodał obsługę wątku Boost w Thrift. Jest teraz domyślnym wątkiem dla systemu Windows. * Domyślnie NIX to pthreads. Aby potwierdzić Janus T, Thrift teraz w pełni obsługuje system Windows.

— pmont

21

To jest nieaktualna informacja. Thrift działa doskonale w systemie Windows już od dłuższego czasu.

— JensG

6

ProtocolBuffers jest SZYBSZY.
Tutaj znajduje się niezły benchmark:
http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking

Możesz także zajrzeć do Avro, ponieważ Avro jest jeszcze szybszy.
Microsoft ma tutaj pakiet:
http://www.nuget.org/packages/Microsoft.Hadoop.Avro

Nawiasem mówiąc, najszybszy, jaki kiedykolwiek widziałem, to Cap'nProto ;
Implementację AC # można znaleźć w repozytorium Github Marc Gravell .

— Stefan Steiger
źródło

4

Myślę, że większość z tych punktów pominęła podstawowy fakt, że Thrift jest frameworkiem RPC, który ma możliwość szeregowania danych przy użyciu różnych metod (binarny, XML itp.).

Bufory protokołów są przeznaczone wyłącznie do serializacji, nie są to ramy takie jak Thrift.

— Babra Cunningham
źródło

3

Co masz na myśli mówiąc o frameworku RPC i czym różni się on od gRPC protobuf ?

— marcelocra

gRPC nie jest pakowany razem z protobuf. Został opracowany 10 lat później. Thrift jest dostarczany z pełną platformą RPC. Zostało zrobione razem.

— trylogia

3

Po pierwsze, protobuf nie jest pełną implementacją RPC. Do tego wymaga czegoś takiego jak gRPC.

gPRC jest bardzo wolny w porównaniu do Thrift:

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

— trylogia
źródło

0

Jest tu kilka doskonałych punktów i dodam jeszcze jeden na wypadek, gdyby ktoś się tu przeciął.

Thrift daje ci możliwość wyboru pomiędzy serializatorem oszczędnościowym a kompaktowym (de) serializatorem oszczędności, oszczędnościowy plik binarny będzie miał doskonałą wydajność, ale większy rozmiar pakietu, podczas gdy kompaktowy zapewnia dobrą kompresję, ale wymaga większej mocy obliczeniowej. Jest to przydatne, ponieważ zawsze możesz przełączać się między tymi dwoma trybami tak łatwo, jak zmieniając wiersz kodu (do diabła, nawet skonfiguruj go). Jeśli więc nie masz pewności, jak bardzo Twoja aplikacja powinna być zoptymalizowana pod kątem wielkości pakietu lub mocy przetwarzania, oszczędzanie może być ciekawym wyborem.

PS: Zobacz ten znakomity projekt porównawczy, w thekvsktórym porównuje wiele serializatorów, w tym thrift-binary, thrift-compact i protobuf: https://github.com/thekvs/cpp-serializers

PS: Istnieje inny serializator o nazwie, YASktóry daje tę opcję, ale nie ma schematu, patrz powyższy link.

— Sinapse
źródło

0

Ważne jest również, aby pamiętać, że nie wszystkie obsługiwane języki są zgodne z oszczędzaniem lub protobufem. W tym momencie jest to kwestia implementacji modułów oprócz podstawowej serializacji. Sprawdzaj testy porównawcze dla dowolnego języka, którego zamierzasz używać.

— JSON
źródło