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-protobuf 및 code.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 Gravell 의 Github 리포지토리 에서 찾을 수 있습니다 .


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.