Thrift와 프로토콜 버퍼의 가장 큰 차이점은 무엇입니까?


286

의 가장 큰 장점과 단점은 무엇입니까 아파치 드리프트 대이 Google의 프로토콜 버퍼 ?


4
참고로 Marc Gravell은 protobuf.net이라는 Google의 protobuf와 함께 작업하기위한 라이브러리를 유지 관리하며 code.google.com/p/protobuf-net
RCIX

5
이 질문과 다음 답변 중 일부는 약 6 살입니다. 아마도 그 이후로 많은 변화가 있었을 것입니다.
AlikElzin-kilaka

답변:


159

둘 다 동일한 기능을 많이 제공합니다. 그러나 몇 가지 차이점이 있습니다.

  • 중고품은 '예외'를 ​​지원합니다
  • 프로토콜 버퍼는 훨씬 더 나은 문서 / 예제를 가지고 있습니다
  • 중고품에는 내장 Set유형이 있습니다
  • 프로토콜 버퍼는 "확장"을 허용합니다. 외부 프로토 타입을 확장하여 추가 필드를 추가하는 동시에 외부 코드가 값에서 작동하도록 할 수 있습니다. Thrift에서는이를 수행 할 방법이 없습니다.
  • 프로토콜 버퍼를 훨씬 쉽게 읽을 수 있습니다.

기본적으로 그것들은 상당히 동등합니다 (프로토콜 버퍼는 내가 읽은 것보다 약간 더 효율적입니다).


16
이 프레젠테이션은 2013 년 슬라이드를
BAR

13
10 개 더 많은 언어와 같은 중고품 지원
엘리야 Saounkine

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-protobufcode.google.com/p/ruby-protobuf를 지원 합니다. 나는 C # (3.5)과 Ruby의 protobuf를 사용하고 있으며, C #은 데이터를 직렬화하고 필요한 경우 Ruby 직렬화 해제하고 작업을 수행합니다.
Bryan Bailliache

6
code.google.com/p/protobuf/wiki/ThirdPartyAddOns 는 PHP, Ruby, Erlang, Perl, Haskell, C #, OCaml plus Actiona Script, Common Lisp, Go, Lua, Mathlab, Visual Basic, Scala를 나열합니다. 이것들은 모두 타사 구현이라고 생각했습니다.
Igor Gatis

objective c에서 프로토 타입 C ++ 파일을 직접 사용할 수 있습니다 (iOS 및 OS X 모두). 이 qn을 확인하십시오
Tushar Koul

내가 볼 code.google.com/p/protobuf-net 종종 C #을위한 protobuf 포트로 언급되어 있지만, 그것은 완전히 사실이 아니다. Protobuf 및 Thrift의 중요한 기능 중 하나는 외부 구조 정의이므로 다른 언어에서도 동일한 정의를 사용할 수 있습니다. protobuf-net은 C # 코드에 구조 정의를 포함하므로이 기능을 지원하지 않습니다.
Andriy Tylychko 2016 년

@AndyT : 논쟁의 여지가 있습니다. 그것은 구조 정의가 지원하고자하는 모든 언어에 대해 외부 적이라는 것이 유리한지에 달려 있습니다. protobuf-net을 사용하면 C #에서 데이터 구조를 정의하고 .proto 파일을 생성하여 다른 언어로 지원을 작성하는 데 사용할 수 있습니다. 나는 C # 중심이며 매우 큰 기존 .Net 응용 프로그램과 Android / Java를 통합하는 과정에 있기 때문에 이것이 이점이라고 생각합니다. 따라서 C # 클래스를 결정적인 구조 정의로 계속 생각하고 싶습니다.
RenniePet

73

RPC는 또 다른 주요 차이점입니다. Thrift는 프로토콜 버퍼가 주로 데이터 교환 형식으로 만 설계된 것처럼 보이는 RPC 클라이언트 및 서버를 구현하는 코드를 생성합니다.


9
그건 사실이 아니야. 프로토콜 버퍼는 RPC 서비스 API를 정의하며 메시지 전달을 구현하는 데 사용할 수있는 라이브러리가 있습니다.
Stephen

7
나는 Protobuf에 RPC가 정의되어 있지 않다고 말하지 않았으며, 단지 모든 사람이 액세스 할 수있는 외부 릴리스가 아닌 RPC를 위해 설계된 것으로 보이지 않습니다. 이 Google 엔지니어의 의견을 읽으 십시오
saidimu apale

9
더 중요한 것은 Thrift에 RPC 지원 기능이 내장되어 있다는 것입니다. Protobuf는 현재 타사 라이브러리를 사용하고 있습니다. 즉, 시선이 적고 테스트가 적고 코드의 안정성이 떨어집니다.
Alec Thomas

2
저에게는 ProtoBuf에 대한 좋은 지적입니다. 직렬화 만 필요한 경우 쓸모없는 코드를 추가하지 않습니다. 그리고 나중에 RPC로 보내야하지만 문제없이 작동 할 수 있습니다. 네트워크에 Netty를 사용하고 있으며 Protobuf는 완벽하게 통합되어 있으므로 문제없이 테스트하거나 성능을 최대화 할 수 있습니다.
Kikiwa

14
실제로 프로토 타입은 RPC를 염두에두고 설계되었습니다. 구글은 최근 그 구성 요소를 오픈 소스 화했다 – grpc.io
andybons

57
  • 프로토 타입 직렬화 된 객체는 Thrift보다 약 30 % 작습니다.
  • protobuf 객체 (create, serialize, deserialize)로 수행하려는 대부분의 작업은 설정 하지 않으면 절약보다 훨씬 느립니다option optimize_for = SPEED .
  • Thrift는 풍부한 데이터 구조를 가지고 있습니다 (Map, Set)
  • Protobuf API는 깔끔해 보이지만 생성 된 클래스는 모두 내부 클래스로 압축되어있어 좋지 않습니다.
  • 중고품 열거 형은 실제 Java 열거 형이 아닙니다. 즉 정수입니다. Protobuf에는 실제 Java 열거 형이 있습니다.

차이점을 자세히 살펴 보려면 이 오픈 소스 프로젝트 에서 소스 코드 차이점을 확인하십시오 .


1
빠른 제안 : 기준선으로 사용되는 다른 비 이진 형식 (xml 또는 json?)이 있으면 깔끔합니다. 일반적인 추세를 보여주는 좋은 테스트는 없었습니다. PB와 Thrift가 더 효율적이라고 가정하지만, 그럴 경우 그 정도는 대부분 공개적인 질문입니다.
StaxMan

4
0.02 초?! 나는 그런 종류의 시간 여유가 없다
Chris S

1
Thrift에 여러 프로토콜 (TCompactProtocol 포함)이 있으므로 첫 번째 글 머리 기호는 더 이상 적용되지 않는다고 생각합니다.
야누스 트롤

13
속도 최적화 옵션이 이제 프로토콜 버퍼의 기본값 ( code.google.com/apis/protocolbuffers/docs/proto.html )
Willem

5
"optimize_for = speed"설정으로 30 % 더 작은 객체를 얻습니까? 아니면 타협 되었습니까?
Prashant Sharma

56

내가 "쓰 리프트 vs 프로토콜 버퍼" 주제 로 말했듯이 :

참조 JSON 비교 대 Protobuf 대 드리프트 :

또한 해당 솔루션에 사용할 수있는 흥미로운 추가 도구가 많이 있습니다. 다음은 Protobuf에 대한 예입니다 Protobuf-와이어 샤크 , protobufeditor는 .


10
이제 이것은 완전한 원입니다. 항상 또는에 연결되는 세 가지 (유사한) 질문에 대해 정확히 같은 답변을 게시했습니다. 나는 젤다를하고있는 것 같은 느낌이 들었다.
ChrisR

+ 크리스 어, 어떻게 된 일인지 기억이 나지 않습니다. 비슷한 질문이 몇 가지 있었지만 순환 대신 세 가지 구조를 만들어야합니다. 어느 날 ... 아주 오래된 질문인데 지금 전화로 답장을하고 있습니다. 어쨌든 캐치 주셔서 감사합니다!
Grzegorz Wierzowiecki

6
"Srift는 좋은 튜토리얼을 제공합니다"-얼마나 웃겨요. 내가 본 것 중 가장 불완전한 튜토리얼입니다. TSimpleServer 이외의 작업을 수행하자마자 거기에 갇히게됩니다
Marian Klühspies

중고품 역시 Wireshark 플러그인이 있습니다 : github.com/andrewcox/wireshark-with-thrift-plugin
CCoder

8

프로토콜 버퍼는보다 간결하게 표현 된 것으로 보이지만 Thrift 백서를 읽으면 얻을 수있는 인상입니다. 그들 자신의 말로 :

우리는 코드의 단순성과 명확성을 위해 몇 가지 극단적 인 스토리지 최적화 (즉, 작은 정수를 ASCII로 패킹하거나 7 비트 연속 형식 사용)를 사용하지 않기로 결정했습니다. 성능이 중요한 사용 사례가 필요한 경우 이러한 변경은 쉽게 수행 할 수 있습니다.

또한 내 인상 일 수도 있지만 프로토콜 버퍼는 구조체 버전 관리와 관련하여 더 두꺼운 추상화가있는 것 같습니다. Thrift는 버전 관리를 지원하지만 약간의 노력이 필요합니다.


1
Thrift가 가능한 한 컴팩트하지 않다는 사실이 프로토콜 버퍼가 있다고 믿게 만드는 이유는 무엇입니까?
Michael Mior

1
프로토콜 버퍼는 값과 필드 식별자 모두에 가변 길이 정수 코딩을 사용합니다. 따라서 작은 값으로 int 필드를 보내는 가장 일반적인 경우는 int16과 int32가 아닌 2 바이트입니다.
poolie

"프로토콜 버퍼는 가변 길이 정수 코딩을 사용합니다"– TCompactProtocol
JensG

8

파이썬의 프로토 버프와 비교할 때 텍스트 기반 프로토콜로 더 나은 성능을 얻을 수있었습니다. 그러나 프로토 버프가 제공하는 형식 검사 또는 기타 멋진 utf8 변환 등은 없습니다.

따라서 직렬화 / 직렬화가 필요한 모든 것이라면 다른 것을 사용할 수 있습니다.

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


7

아직 언급되지 않은 한 가지 분명한 점은 찬반 양론 일 수 있으며 둘 다 동일 할 수 있다는 것입니다. 이진 프로토콜입니다. 이를 통해보다 간결한 표현과 더 많은 성능 (프로)이 가능하지만 가독성 (또는 디버깅 가능성)이 줄어 듭니다.

또한 둘 다 xml (및 아마도 json)과 같은 표준 형식보다 도구 지원이 약간 적습니다.

(편집) 다음 은 크기 및 성능 차이를 모두 다루고 다른 형식 (xml, json)의 숫자도 포함 하는 흥미로운 비교 입니다.


3
XML보다 훨씬 읽기 쉬운 텍스트 표현으로 프로토콜 버퍼를 출력하는 것은 쉽지 않습니다 : my_proto.DebugString (). 예를 들어 code.google.com/apis/protocolbuffers/docs/overview.html
SuperElectric

물론 모든 이진 형식에 대한 ditto는 그대로 읽을 수있는 것은 아닙니다 (전선의 디버그). 더 나쁜 것은 protobuf의 경우 필드 이름을 알기 위해서는 실제로 스키마 정의가 필요합니다.
StaxMan

Thrift는 서로 다른 사용자 정의 프로토콜을 지원합니다. 바이너리, 컴팩트, json 또는 지난 주에 발명 한 것을 사용할 수 있습니다.
JensG

6

그리고에 따라 위키 중고품 런타임은 Windows에서 실행되지 않습니다.


5
Windows에서 Thrift를 성공적으로 실행합니다. 사용 창에서 포크 github.com/aubonbeurre/thrift
세르게이 Podobry

20
공식 메인 라인 지점은 이제 Windows도 지원합니다.
야누스 트롤 슨

5
@dalle-Alex P는 Thrift에서 Boost 스레드 지원을 추가했습니다. 이제 Windows의 기본 스레딩입니다. * NIX는 기본적으로 pthreads입니다. Janus T를 확인하기 위해 Thrift는 이제 Windows를 완벽하게 지원합니다.
pmont

21
오래된 정보입니다. Thrift는 이제 Windows에서 긴 시간 동안 완벽하게 실행됩니다.
JensG

6

ProtocolBuffers는 FASTER입니다.
여기 좋은 벤치 마크가 있습니다 :
http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking

Avro가 더 빠르기 때문에 Avro를 살펴볼 수도 있습니다.
Microsoft는 다음과 같은 패키지를 제공합니다.
http://www.nuget.org/packages/Microsoft.Hadoop.Avro

그건 그렇고, 내가 본 가장 빠른 것은 Cap'nProto입니다 .
AC # 구현 은 Marc GravellGithub 리포지토리 에서 찾을 수 있습니다 .


4

필자는 이러한 점들 대부분이 Thrift가 RPC 프레임 워크라는 기본 사실을 놓쳤다 고 생각합니다.이 프레임 워크는 다양한 방법 (이진, XML 등)을 사용하여 데이터를 직렬화 할 수 있습니다.

프로토콜 버퍼는 순차 직렬화를 위해 설계되었으며 Thrift와 같은 프레임 워크는 아닙니다.


3
RPC 프레임 워크의 의미는 무엇이며 protobuf의 gRPC 와 다른 점은 무엇 입니까?
marcelocra

gRPC는 protobuf와 함께 패키지되지 않습니다. 10 년 후에 개발되었습니다. Thrift는 전체 RPC 프레임 워크와 함께 제공됩니다. 함께 만들어졌습니다.
trilogy


0

여기에 몇 가지 훌륭한 점이 있으며 누군가의 경로가 여기를 지나갈 경우를 대비하여 다른 점을 추가하겠습니다.

Thrift는 Thrift-Binary와 Thrift-Compact (De) 시리얼 라이저 중에서 선택할 수있는 옵션을 제공하며, Thrift-Binary는 성능은 우수하지만 패킷 크기는 크지 만 Thrift-Compact는 압축률은 높지만 처리 능력은 더 필요합니다. 코드 줄을 변경하는 것만 큼 쉽게이 두 모드 사이를 전환 할 수 있기 때문에 편리합니다 (허크, 구성 가능). 따라서 응용 프로그램이 패킷 크기 나 처리 능력에 얼마나 최적화되어야하는지 잘 모르는 경우, 절약은 흥미로운 선택이 될 수 있습니다.

PS : thekvsThrift-binary, Thrift-Compact 및 Protobuf를 포함한 많은 시리얼 라이저를 비교하는 이 우수한 벤치 마크 프로젝트를 참조하십시오 : https://github.com/thekvs/cpp-serializers

추신 : YAS이 옵션도 제공하는 다른 직렬 변환기가 있지만 스키마가 없습니다. 위의 링크를 참조하십시오.


0

또한 지원되는 모든 언어가 중고품 또는 원형과 일치하지는 않습니다. 이 시점에서 기본적인 직렬화 외에도 모듈 구현이 중요합니다. 사용하려는 언어에 대한 벤치 마크를 확인하십시오.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.