Programing

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

lottogame 2020. 3. 24. 08:00
반응형

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


Apache ThriftGoogle의 프로토콜 버퍼 의 가장 큰 장단점은 무엇입니까 ?


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

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

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


또 다른 중요한 차이점은 기본적으로 지원되는 언어입니다.

  • 프로토콜 버퍼 : 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

둘 다 다른 플랫폼으로 확장 될 수 있지만, 기본적으로 사용 가능한 언어 바인딩입니다.


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


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

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


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

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

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


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

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

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


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

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

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


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

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

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


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


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 리포지토리 에서 찾을 수 있습니다 .


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

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


하나, protobuf는 완전한 RPC 구현이 아닙니다. gRPC와 같은 것이 필요합니다.

gPRC는 Thrift에 비해 매우 느립니다 :

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


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

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

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

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


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

참고 URL : https://stackoverflow.com/questions/69316/biggest-differences-of-thrift-vs-protocol-buffers

반응형