ความแตกต่างที่ใหญ่ที่สุดของ Thrift vs Protocol Buffers คืออะไร?

อะไรคือข้อดีและข้อเสียที่ใหญ่ที่สุดของApache Thriftเทียบกับโปรโตคอลบัฟเฟอร์ของ Google ?

พวกเขาทั้งสองมีคุณสมบัติเดียวกันหลายอย่าง อย่างไรก็ตามมีความแตกต่าง:

• Thrift รองรับ 'ข้อยกเว้น'
• โปรโตคอลบัฟเฟอร์มีเอกสาร / ตัวอย่างที่ดีกว่ามาก
• เจริญเติบโตอย่างรวดเร็วมีSetชนิดในตัว
• โปรโตคอลบัฟเฟอร์อนุญาตให้ "ส่วนขยาย" - คุณสามารถขยายโปรโตภายนอกเพื่อเพิ่มฟิลด์พิเศษในขณะที่ยังคงอนุญาตให้โค้ดภายนอกทำงานบนค่าต่างๆ ไม่มีวิธีการทำเช่นนี้ใน Thrift
• ฉันพบว่าโปรโตคอลบัฟเฟอร์อ่านง่ายกว่ามาก

โดยพื้นฐานแล้วมันค่อนข้างเท่ากัน (กับ Protocol Buffers มีประสิทธิภาพมากกว่าเล็กน้อยจากสิ่งที่ฉันอ่าน)

ความแตกต่างที่สำคัญอีกประการหนึ่งคือภาษาที่รองรับโดยค่าเริ่มต้น

• โปรโตคอลบัฟเฟอร์: 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 และเซิร์ฟเวอร์ซึ่ง Protocol Buffers ดูเหมือนว่าส่วนใหญ่ออกแบบมาเป็นรูปแบบการแลกเปลี่ยนข้อมูลเพียงอย่างเดียว

• Protobuf วัตถุที่ต่อเนื่องนั้นมีขนาดเล็กกว่าของ Thrift ประมาณ 30%
• การกระทำส่วนใหญ่ที่คุณอาจต้องการทำกับวัตถุ protobuf (สร้าง, ซีเรียลไลซ์, ดีซีเรียลไลซ์) นั้นช้ากว่าความเจริญถ้าคุณเปิดoption optimize_for = SPEEDเครื่อง
• Thrift มีโครงสร้างข้อมูลที่สมบูรณ์ยิ่งขึ้น (แผนที่, Set)
• Protobuf API นั้นดูสะอาดกว่า แต่คลาสที่สร้างขึ้นทั้งหมดจะถูกบรรจุเป็นคลาสภายในซึ่งไม่ค่อยดีนัก
• Thrift enums ไม่ใช่ Java Enums ที่แท้จริงนั่นคือพวกเขาเป็นเพียง ints Protobuf มี enums Java จริง

เพื่อดูความแตกต่างอย่างใกล้ชิดตรวจสอบซอร์สโค้ดต่างกันในโครงการโอเพ่นซอร์สนี้

ขณะที่ผมได้กล่าวว่าเป็น"ทริฟท์ VS บัฟเฟอร์โปรโตคอล"หัวข้อ:

หมายถึงThrift เทียบกับ Protobuf vs JSON การเปรียบเทียบ :

• เจริญเติบโตอย่างรวดเร็วรองรับออกจากกล่องAS3, C ++, C #, D, Delphi, Go, Graphviz, Haxe, Haskell, Java, Javascript, Node.js, OCaml, Smalltalk, typescript, Perl, PHP, Python, Ruby, ...
• C ++, Python, Java - การสนับสนุนในกล่องใน Protobuf
• การสนับสนุน Protobuf สำหรับภาษาอื่น ๆ (รวมถึง Lua, Matlab, Ruby, Perl, R, Php, OCaml, Mercury, Erlang, Go, D, Lisp) มีให้บริการในกลุ่มบุคคลที่สาม (btw นี่คือการสนับสนุน SWI-Prolog )
• Protobuf มีเอกสารที่ดีกว่าและตัวอย่างมากมาย
• Thrift มาพร้อมกับบทช่วยสอนที่ดี
• วัตถุ Protobuf มีขนาดเล็กลง
• Protobuf เร็วขึ้นเมื่อใช้การกำหนดค่า "optimization_for = SPEED"
• Thrift ได้รวมการใช้งานของ RPC ในขณะที่สำหรับProtobuf RPC จะถูกแยกออกจากกัน แต่มีให้ใช้งาน (เช่นZeroc ICE )
• Protobuf เผยแพร่ภายใต้ลิขสิทธิ์แบบ BSD
• Thrift เปิดตัวภายใต้ลิขสิทธิ์ Apache 2

นอกจากนี้ยังมีเครื่องมือเพิ่มเติมที่น่าสนใจมากมายสำหรับโซลูชันเหล่านั้นซึ่งอาจเป็นตัวตัดสิน นี่คือตัวอย่างสำหรับ Protobuf: Protobuf-Wireshark , protobufeditor

Protocol Buffers ดูเหมือนจะมีขนาดกะทัดรัดกว่า แต่เป็นเพียงความประทับใจที่ฉันได้รับจากการอ่านกระดาษสีขาวของ Thrift ในคำพูดของตัวเอง:

เราตัดสินใจเปรียบเทียบการเพิ่มประสิทธิภาพการจัดเก็บข้อมูลที่รุนแรง (เช่นการบรรจุจำนวนเต็มขนาดเล็กลงใน ASCII หรือใช้รูปแบบความต่อเนื่อง 7 บิต) เพื่อความเรียบง่ายและชัดเจนในรหัส การปรับเปลี่ยนเหล่านี้สามารถทำได้อย่างง่ายดายหากและเมื่อเราพบกรณีการใช้งานที่มีความสำคัญต่อประสิทธิภาพที่ต้องการ

นอกจากนี้อาจเป็นเพียงความประทับใจของฉัน แต่ Protocol Buffers ดูเหมือนจะมี abstractions ที่หนากว่าในการกำหนดเวอร์ชันของ struct Thrift มีการสนับสนุนเวอร์ชันบางอย่าง แต่ใช้ความพยายามเล็กน้อยเพื่อให้เกิดขึ้น

ฉันสามารถรับประสิทธิภาพที่ดีขึ้นด้วยโปรโตคอลแบบข้อความเมื่อเทียบกับ protobuff บน python อย่างไรก็ตามไม่มีการตรวจสอบประเภทหรือการแปลง utf8 แฟนซีอื่น ๆ ... ที่ protobuff นำเสนอ

ดังนั้นถ้าซีเรียลไลซ์เซชั่น / ดีซีเรียลไลเซชันเป็นสิ่งที่คุณต้องการคุณก็อาจจะใช้อย่างอื่น

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

สิ่งหนึ่งที่เห็นได้ชัดที่ยังไม่ได้กล่าวถึงนั้นอาจเป็นได้ทั้งโปรหรือคอน (และเหมือนกันสำหรับทั้งคู่) คือมันเป็นโปรโตคอลไบนารี่ สิ่งนี้ยอมให้มีการแทนขนาดกะทัดรัดมากขึ้นและอาจมีประสิทธิภาพมากขึ้น (ข้อดี) แต่ด้วยความสามารถในการอ่านที่ลดลง (หรือมากกว่านั้นคือ debuggability)

นอกจากนี้ทั้งสองยังมีการสนับสนุนเครื่องมือน้อยกว่ารูปแบบมาตรฐานเช่น xml (และอาจเป็น json)

(EDIT) นี่คือการเปรียบเทียบที่น่าสนใจที่มีความแตกต่างทั้งด้านขนาดและประสิทธิภาพและมีตัวเลขสำหรับรูปแบบอื่น ๆ (xml, json) เช่นกัน

และตามวิกินั้นรันไทม์ของ Thrift ไม่ได้ทำงานบน Windows

ProtocolBuffers เร็วกว่า
มีเกณฑ์มาตรฐานที่ดีอยู่ที่นี่:
http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking

คุณอาจต้องการดูเป็น Avro เนื่องจาก Avro นั้นเร็วกว่า
Microsoft มีแพ็คเกจที่นี่:
http://www.nuget.org/packages/Microsoft.Hadoop.Avro

โดยเร็วที่สุดที่ฉันเคยเห็นคือCap'nProto ;
AC # การดำเนินงานที่สามารถพบได้ที่Github-พื้นที่เก็บข้อมูลของ Marc Gravell

ฉันคิดว่าประเด็นเหล่านี้ส่วนใหญ่พลาดความจริงพื้นฐานไปแล้วว่า Thrift เป็นเฟรมเวิร์ก RPC ซึ่งมีความสามารถในการจัดลำดับข้อมูลโดยใช้วิธีการที่หลากหลาย (ไบนารี, XML, ฯลฯ )

Protocol Buffers ได้รับการออกแบบมาเพื่อการซีเรียลไลซ์เซชั่นโดยแท้ แต่ไม่ใช่กรอบอย่างเช่น Thrift

สำหรับโปรโตบูฟไม่ใช่การใช้งาน RPC อย่างสมบูรณ์ มันต้องการบางสิ่งบางอย่างเช่น gRPC เพื่อไปกับมัน

gPRC ช้ามากเมื่อเทียบกับ Thrift:

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

มีบางจุดที่ยอดเยี่ยมที่นี่และฉันจะเพิ่มอีกหนึ่งในกรณีที่เส้นทางของคนข้าม

Thrift มีตัวเลือกให้คุณเลือกระหว่าง serializer แบบประหยัด - ฐานสองและรุ่นประหยัดขนาดกะทัดรัด thrift-binary จะมีประสิทธิภาพที่ยอดเยี่ยม แต่ขนาดแพ็กเก็ตที่ใหญ่กว่าในขณะที่ขนาดกะทัดรัดกะทัดรัดจะให้การบีบอัดที่ดี แต่ต้องการพลังการประมวลผลที่มากขึ้น สิ่งนี้มีประโยชน์เพราะคุณสามารถสลับไปมาระหว่างสองโหมดนี้ได้อย่างง่ายดายเหมือนกับการเปลี่ยนบรรทัดของโค้ด (heck หรือแม้กระทั่งทำให้สามารถกำหนดค่าได้) ดังนั้นหากคุณไม่แน่ใจว่าควรปรับใช้แอปพลิเคชั่นของคุณให้เหมาะสมกับขนาดแพ็คเก็ตหรือกำลังการประมวลผลมากเพียงใดการประหยัดพลังงานอาจเป็นทางเลือกที่น่าสนใจ

PS: ดูโครงการมาตรฐานที่ยอดเยี่ยมthekvsซึ่งเปรียบเทียบ serializers มากมายรวมถึง thrift-binary, thrift-compact, และ protobuf: https://github.com/thekvs/cpp-serializers

PS: มี serializer อื่นชื่อYASซึ่งให้ตัวเลือกนี้ด้วย แต่มันเป็น schema- น้อยดูลิงค์ด้านบน

สิ่งสำคัญคือต้องทราบว่าไม่ใช่ทุกภาษาที่รองรับจะต้องมีการเจริญเติบโตอย่างรวดเร็วหรือมีโปรโตฟูฟ ณ จุดนี้มันเป็นเรื่องของการใช้งานโมดูลที่นอกเหนือไปจากการทำให้เป็นอันดับพื้นฐาน ระมัดระวังตรวจสอบมาตรฐานสำหรับภาษาที่คุณวางแผนจะใช้