Apache Thrift, Google Protocol Buffers, MessagePack, ASN.1 और Apache Avro के बीच मुख्य अंतर क्या हैं?

Question

ये सभी बाइनरी क्रमांकन, आरपीसी फ्रेमवर्क और आईडीएल प्रदान करते हैं। मैं उनके और विशेषताओं (प्रदर्शन, उपयोग में आसानी, प्रोग्रामिंग भाषाओं का समर्थन) के बीच महत्वपूर्ण अंतरों में दिलचस्पी रखता हूं।

यदि आप किसी अन्य समान तकनीक को जानते हैं, तो कृपया एक उत्तर में इसका उल्लेख करें।

Comments

en.wikipedia.org/wiki/Comparison_of_data_serialization_formats

@ ज़ेनिकोडर: उस लिंक में 5 में से 2 के लिए कोई जानकारी नहीं है।

— JUST MY सही ओपिनियन

क्या वह मदद कर सकता है: स्लाइडशेयर । net / IgorAnishchenko / pb-vs-thrift-vs-avro ?

— व्रोक

उन लोगों के लिए जो RPC नहीं जानते हैं - रिमोट प्रोडक्योर कॉल, IDL - इंटरफ़ेस परिभाषा भाषा

— garg10may

Answer 1

ASN.1 एक ISO / ISE मानक है। इसमें बहुत पठनीय स्रोत भाषा और विभिन्न प्रकार के बैक-एंड्स हैं, जो बाइनरी और मानव-पठनीय दोनों हैं। एक अंतरराष्ट्रीय मानक होने के नाते (और उस पर एक पुराना!) स्रोत भाषा एक बिट किचन-सिंकिश है (उसी तरह से कि अटलांटिक महासागर थोड़ा गीला है) लेकिन यह बहुत अच्छी तरह से निर्दिष्ट है और इसमें अच्छी मात्रा में समर्थन है । (आप किसी भी भाषा के लिए ASN.1 लाइब्रेरी खोज सकते हैं, जिसका नाम यदि आप पर्याप्त रूप से खोदते हैं, और यदि नहीं तो अच्छी सी भाषा लाइब्रेरी उपलब्ध हैं जिसे आप एफएफआई में उपयोग कर सकते हैं।) यह एक मानकीकृत भाषा है, जुनूनी रूप से प्रलेखित है। कुछ अच्छे ट्यूटोरियल भी उपलब्ध हैं।

थ्रिफ्ट एक मानक नहीं है। यह मूल रूप से फेसबुक से है और बाद में इसे ओपन-सोर्स किया गया था और वर्तमान में यह एक शीर्ष स्तर की अपाचे परियोजना है। यह अच्छी तरह से प्रलेखित नहीं है - विशेष रूप से ट्यूटोरियल का स्तर - और मेरे ((संक्षेप में संक्षिप्त) झलक में ऐसा कुछ भी नहीं दिखता है जो अन्य, पिछले प्रयास पहले से ही नहीं करते हैं (और कुछ मामलों में बेहतर)। इसके निष्पक्ष होने के लिए, इसमें कई प्रभावशाली भाषाएं हैं जो बॉक्स से बाहर का समर्थन करती हैं, जिनमें कुछ उच्च-प्रोफ़ाइल गैर-मुख्यधारा वाले भी शामिल हैं। आईडीएल भी अस्पष्ट सी-लाइक है।

प्रोटोकॉल बफर एक मानक नहीं है। यह एक Google उत्पाद है जो व्यापक समुदाय के लिए जारी किया जा रहा है। यह बॉक्स से समर्थित भाषाओं के संदर्भ में थोड़ा सीमित है (यह केवल C ++, पायथन और जावा का समर्थन करता है) लेकिन इसमें अन्य भाषाओं (अत्यधिक परिवर्तनीय गुणवत्ता) के लिए बहुत अधिक तृतीय-पक्ष का समर्थन है। Google अपने सभी कार्य प्रोटोकॉल बफ़र्स का उपयोग करके बहुत करता है, इसलिए यह एक युद्ध-परीक्षण, युद्ध-कठोर प्रोटोकॉल (यद्यपि ASN.1 के रूप में युद्ध-कठोर नहीं है। यह थ्रिफ़्ट की तुलना में बहुत बेहतर प्रलेखन है, लेकिन, Google उत्पाद, यह अस्थिर होने की संभावना है (कभी-बदलते के अर्थ में, अविश्वसनीय के अर्थ में नहीं)। आईडीएल भी सी-लाइक है।

उपरोक्त सभी प्रणालियाँ किसी लक्ष्य भाषा के लिए कोड उत्पन्न करने के लिए किसी प्रकार की IDL में परिभाषित स्कीमा का उपयोग करती हैं जो तब एन्कोडिंग और डिकोडिंग में उपयोग की जाती है। एवरो नहीं करता है। एवरो का टाइपिंग गतिशील है और इसके स्कीमा डेटा का उपयोग रनटाइम पर सीधे सांकेतिक शब्दों में बदलना और डिकोड करने के लिए किया जाता है (जिसकी प्रोसेसिंग में कुछ स्पष्ट लागतें होती हैं, लेकिन कुछ स्पष्ट लाभ विज़ुअल डायनामिक भाषाओं और टैगिंग प्रकारों की आवश्यकता की कमी आदि) । इसके स्कीमा में JSON का उपयोग किया गया है जो एक नई भाषा में एवरो को सपोर्ट करना आसान बना देता है अगर वहां पहले से ही JSON लाइब्रेरी मौजूद है। फिर, जैसा कि ज्यादातर व्हील-रीइन्वेंटिंग प्रोटोकॉल डिस्क्रिप्शन सिस्टम के साथ है, एवरो को भी मानकीकृत नहीं किया गया है।

व्यक्तिगत रूप से, इसके साथ मेरे प्यार / नफरत के रिश्ते के बावजूद, मैं शायद सबसे अधिक RPC और संदेश प्रसारण उद्देश्यों के लिए ASN.1 का उपयोग करूंगा, हालांकि इसमें वास्तव में RPC स्टैक नहीं है (आपको एक बनाना होगा, लेकिन IOCs काफी सरल)।

Comments

विस्तृत विवरण के लिए धन्यवाद। लेकिन संस्करण के बारे में क्या, मैंने सुना है कि प्रोटोबॉफ़ इसे संभाल सकता है, अन्य पुस्तकालयों के बारे में क्या है और यह आम में कैसे उपयोग करने योग्य है? इसके अलावा, ऐसा लगता है कि एवरो के पास अब JSON एक के अलावा C-जैसे सिंटैक्स के साथ IDL है।

— andreypopp

ASN.1 ...विस्तार मार्कर के माध्यम से या EXTENSIBILITY IMPLIEDमॉड्यूल हेडर में स्वचालित के माध्यम से मैन्युअल संस्करण का समर्थन करता है । प्रोटोकॉल बफ़र्स, IIRC, मैन्युअल संस्करण का समर्थन करता है। मुझे नहीं पता कि क्या यह निहित विस्तार जैसी किसी भी चीज़ का समर्थन करता है (और इसे देखने के लिए बहुत आलसी हूँ)। थ्रिफ्ट कुछ वर्जनिंग का भी समर्थन करता है, लेकिन फिर से यह मुझे निहित प्रक्रिया के बिना एक मैनुअल प्रक्रिया के रूप में प्रभावित करता है।

— JUST MY सही OPINION

रिकॉर्ड के लिए, प्रोटोकॉल बफ़र हमेशा संख्याओं के आधार पर फ़ील्ड्स को स्पष्ट रूप से एनकोड करता है, और यदि अतिरिक्त फ़ील्ड हैं, तो लाइब्रेरी स्तर पर यह कभी भी त्रुटि नहीं होती है और यदि वे वैकल्पिक या स्पष्ट रूप से चिह्नित नहीं हैं, तो गायब फ़ील्ड त्रुटि नहीं है। इस प्रकार सभी प्रोटोकॉल बफ़र्स संदेश है EXTENSIBILITY IMPLIED।

— केविन कैथार्ट

IOCs द्वारा - क्या आप नियंत्रण के उलट मतलब है? PHP में RPC स्टैक के लिए कोई क्या उपयोग करेगा, XML-RPC एक्सटेंशन जैसी कोई चीज़? या किसी को खुद पर कुछ लिखना होगा?

— स्टैन

एवरो अधिक लचीला है क्योंकि यह या तो परिभाषित स्कीमा पर गतिशील रूप से काम करने की अनुमति देता है, या बॉयलरप्लेट कक्षाएं उत्पन्न करने के लिए। मेरे अनुभव से, यह बहुत शक्तिशाली है: इसकी ताकत सुविधाओं के अपने समृद्ध सेट में रहती है, जिसमें आरपीसी जनरेटर (यह थ्रिफ्ट के साथ एक सामान्य विशेषता है) शामिल है।

— पाओलो मार्स्का

Answer 2

हमने सिर्फ धारावाहिकों पर एक आंतरिक अध्ययन किया, यहां कुछ परिणाम हैं (मेरे भविष्य के संदर्भ के लिए भी!)

थ्रिफ्ट = क्रमांकन + आरपीसी स्टैक

सबसे बड़ा अंतर यह है कि थ्रिफ्ट केवल एक क्रमिक प्रोटोकॉल नहीं है, यह एक पूर्ण विकसित आरपीसी स्टैक है जो आधुनिक दिन SOAP स्टैक की तरह है। तो क्रमबद्धता के बाद, वस्तुओं सकता है (लेकिन अनिवार्य) मशीनों के बीच टीसीपी / आईपी पर भेजा जाए। SOAP में, आपने एक WSDL दस्तावेज़ के साथ शुरुआत की, जो उपलब्ध सेवाओं (दूरस्थ तरीकों) और अपेक्षित तर्कों / वस्तुओं का पूरी तरह से वर्णन करता है। उन वस्तुओं को XML के माध्यम से भेजा गया था। थ्रिफ़्ट में, .thrift फ़ाइल पूरी तरह से उपलब्ध तरीकों, अपेक्षित पैरामीटर ऑब्जेक्ट्स का वर्णन करती है और वस्तुओं को उपलब्ध सीरियलाइज़र ( Compact Protocolएक कुशल बाइनरी प्रोटोकॉल, उत्पादन में सबसे लोकप्रिय होने के साथ) के माध्यम से क्रमबद्ध किया जाता है ।

ASN.1 = ग्रैंड डैडी

ASN.1 को 80 के दशक में टेलीकॉम लोगों द्वारा डिजाइन किया गया था और हाल ही में धारावाहिकों की तुलना में सीमित पुस्तकालय समर्थन के कारण इसका उपयोग करने के लिए अजीब है जो कि CompSci लोगों से उभरा। दो वेरिएंट हैं, डीईआर (बाइनरी) एन्कोडिंग और पीईएम (एससीआईआई) एन्कोडिंग। दोनों तेज हैं, लेकिन डीईआर तेज और दो के आकार का अधिक कुशल है। वास्तव में ASN.1 डीईआर आसानी से (और कभी-कभी हरा) धारावाहिकों को रख सकता है जो 30 साल डिजाइन किए गए थेखुद के बाद, यह करने के लिए एक वसीयतनामा अच्छी तरह से इंजीनियर डिजाइन है। यह बहुत कॉम्पैक्ट है, प्रोटोकॉल बफ़र्स और थ्रिफ्ट से छोटा है, केवल एवरो द्वारा पीटा गया है। इस मुद्दे का समर्थन करने के लिए महान पुस्तकालय हैं और अभी बाउंसी कैसल सी # / जावा के लिए सबसे अच्छा लगता है। ASN.1 सुरक्षा और क्रिप्टो सिस्टम में राजा है और वह दूर नहीं जा रहा है, इसलिए 'भविष्य के प्रमाण' के बारे में चिंतित न हों। बस एक अच्छा पुस्तकालय प्राप्त करें ...

संदेशपैक = पैक के बीच में

यह बुरा नहीं है, लेकिन यह न तो सबसे तेज़ है, न ही सबसे छोटा और न ही सबसे अच्छा समर्थित है। इसे चुनने का कोई उत्पादन कारण नहीं।

सामान्य

इसके अलावा, वे काफी हद तक समान हैं। अधिकांश मूल TLV: Type-Length-Valueसिद्धांत के भिन्न रूप हैं।

प्रोटोकॉल बफ़र्स (Google उत्पन्न), एवरो (Apado आधारित, Hadoop में प्रयुक्त), थ्रिफ़्ट (फेसबुक की उत्पत्ति, अब Apache प्रोजेक्ट) और ASN.1 (टेलीकॉम की उत्पत्ति) सभी कोड पीढ़ी के कुछ स्तर को शामिल करते हैं जहाँ आप पहली बार किसी धारावाहिक में अपना डेटा व्यक्त करते हैं - विशिष्ट प्रारूप, फिर धारावाहिक "कंपाइलर" code-genचरण के माध्यम से आपकी भाषा के लिए स्रोत कोड उत्पन्न करेगा । आपका एप्लिकेशन स्रोत तब code-genIO के लिए इन कक्षाओं का उपयोग करता है । ध्यान दें कि कुछ कार्यान्वयन (जैसे: Microsoft की एवो लाइब्रेरी या मार्क गेल के प्रोटोब्यूफ़नेट) आपको सीधे अपने ऐप स्तर POCO / POJO ऑब्जेक्ट को सजाने देते हैं और फिर लाइब्रेरी सीधे किसी भी कोड-जीन की कक्षाओं के बजाय उन सजाए गए वर्गों का उपयोग करती है। हमने इस प्रस्ताव को बढ़ावा देने वाला प्रदर्शन देखा है क्योंकि यह ऑब्जेक्ट कॉपी स्टेज (एप्लिकेशन स्तर POCO / POJO फ़ील्ड से कोड-जीन फ़ील्ड तक) को समाप्त करता है।

कुछ परिणाम और एक जीवित परियोजना के साथ खेलने के लिए

यह प्रोजेक्ट ( https://github.com/sidshetye/SerializersCompare ) C # दुनिया में महत्वपूर्ण धारावाहिकों की तुलना करता है। जावा लोगों के पास पहले से ही कुछ समान है ।

1000 iterations per serializer, average times listed
Sorting result by size
Name                Bytes  Time (ms)
------------------------------------
Avro (cheating)       133     0.0142
Avro                  133     0.0568
Avro MSFT             141     0.0051
Thrift (cheating)     148     0.0069
Thrift                148     0.1470
ProtoBuf              155     0.0077
MessagePack           230     0.0296
ServiceStackJSV       258     0.0159
Json.NET BSON         286     0.0381
ServiceStackJson      290     0.0164
Json.NET              290     0.0333
XmlSerializer         571     0.1025
Binary Formatter      748     0.0344

Options: (T)est, (R)esults, s(O)rt order, (S)erializer output, (D)eserializer output (in JSON form), (E)xit

Serialized via ASN.1 DER encoding to 148 bytes in 0.0674ms (hacked experiment!)

Comments

ASN.1 में BER (मूल एन्कोडिंग नियम), PER (पैक्ड एनकोडिंग नियम) और XER (XML एन्कोडिंग नियम) भी हैं। डीईआर बीईआर की एक भिन्नता है जो मुख्य रूप से क्रिप्टोग्राफी के लिए उपयोग की जाती है क्योंकि यह प्रत्येक डेटाम के लिए एक अद्वितीय एन्कोडिंग की गारंटी देता है। बीईआर और प्रति दोनों डीईआर से अधिक कुशल हो सकते हैं। अधिकांश पुस्तकालय डीईआर की प्रक्रिया करते हैं। कुछ सभी BER कंस्ट्रक्शन को सही तरीके से हैंडल नहीं करते हैं। जो लोग अधिक जानने में रुचि रखते हैं: luca.ntop.org/Teaching/Appunti/asn1.html

— जो स्टील 21

इसमें JER - जावास्क्रिप्ट ऑब्जेक्ट नोटेशन एन्कोडिंग नियम भी हैं। आप ECN (एन्कोडिंग कंट्रोल नोटेशन) के साथ अपने स्वयं के एन्कोडिंग नियमों को भी परिभाषित कर सकते हैं। डाउनलोड लिंक के साथ ऐनक की अच्छी सूची: oss.com/asn1/resources/standards-define-asn1.html

— दिमित्री

There are two variants, DER (binary) encoding and PEM (ascii) encoding। ध्यान रखें कि पीईएम BEGIN END टिप्पणियों के अंदर केवल एक आधार -64 एन्कोडेड बाइनरी डेटा है। यह बाइनरी डेटा डीईआर एन्कोडिंग का उपयोग करके उत्पन्न किया गया हो सकता है, इसलिए पीईएम और डीईआर की तुलना करना अजीब है।

— राफल्स 12

Answer 3

प्रदर्शन के परिप्रेक्ष्य में जोड़ते हुए, Uber ने हाल ही में अपने इंजीनियरिंग ब्लॉग पर इनमें से कई पुस्तकालयों का मूल्यांकन किया:

https://eng.uber.com/trip-data-squeeze/

उनके लिए विजेता? MessagePack + संपीड़न के लिए zlib

हमारा लक्ष्य उच्चतम गति पर सबसे कॉम्पैक्ट परिणाम के साथ एन्कोडिंग प्रोटोकॉल और संपीड़न एल्गोरिथ्म के संयोजन को खोजना था। हमने उबेर न्यूयॉर्क सिटी से 2,219 छद्म आयामी अनाम यात्राओं पर एन्कोडिंग प्रोटोकॉल और संपीड़न एल्गोरिथ्म संयोजनों का परीक्षण किया (जेसन के रूप में एक पाठ फ़ाइल में डाला गया)।

यहां सबक यह है कि आपकी आवश्यकताएं ड्राइव करती हैं कि कौन सी लाइब्रेरी आपके लिए सही है। उबेर के लिए वे आईडीएल आधारित प्रोटोकॉल का उपयोग नहीं कर सकते हैं क्योंकि उनके पास होने वाले संदेश की योजनाबद्ध प्रकृति के कारण। इससे विकल्पों का एक गुच्छा समाप्त हो गया। इसके अलावा, यह न केवल कच्चे एन्कोडिंग / डिकोडिंग का समय है जो खेलने में आता है, बल्कि बाकी पर डेटा का आकार है।

आकार परिणाम

गति के परिणाम

Answer 4

ASN.1 के बारे में एक बड़ी बात यह है कि ist को विनिर्देशन के लिए डिज़ाइन किया गया है न कि कार्यान्वयन के लिए। इसलिए किसी भी "वास्तविक" प्रोग्रामिंग भाषा में कार्यान्वयन के विवरण को छिपाना / अनदेखा करना बहुत अच्छा है।

ASN.1- कंपाइलर का काम asn1- फाइल को एन्कोडिंग नियम लागू करना और उन दोनों के निष्पादन योग्य कोड से उत्पन्न करना है। एन्कोडिंग नियम एनकोडिंग संकेतन (ECN) में दिए जा सकते हैं या BER / DER, PER, XER / EXER जैसे मानकीकृत में से एक हो सकते हैं। वह ASN.1 प्रकार और संरचनाएं है, एन्कोडिंग नियम वायर एन्कोडिंग पर परिभाषित करते हैं, और अंतिम लेकिन कम से कम कंपाइलर इसे आपकी प्रोग्रामिंग भाषा में स्थानांतरित नहीं करता है।

मुफ्त संकलक मेरे ज्ञान के लिए C, C ++, C #, Java और Erlang का समर्थन करते हैं। (बहुत महंगा और पेटेंट / लाइसेंस राइडेड) वाणिज्यिक संकलक बहुत बहुमुखी हैं, आमतौर पर बिल्कुल अप-टू-डेट और कभी-कभी अधिक भाषाओं का समर्थन करते हैं, लेकिन उनकी साइटें (ओएसएस नोकलवा, मारबेन आदि) देखें।

इस तकनीक का उपयोग करके पूरी तरह से अलग प्रोग्रामिंग संस्कृतियों (जैसे। "एम्बेडेड" लोगों और "सर्वर किसानों") के दलों के बीच एक इंटरफ़ेस निर्दिष्ट करना आश्चर्यजनक रूप से आसान है: एक asn.1-file, एन्कोडिंग नियम उदा BER और उदाहरण के लिए UML इंटरेक्शन आरेख । कोई चिंता नहीं है कि इसे कैसे लागू किया जाए, सभी को "अपनी चीज" का उपयोग करने दें! मेरे लिए इसने बहुत अच्छा काम किया है। Btw: ओएसएस नोक्लावा की साइट पर आपको ASN.1 के बारे में कम से कम दो मुफ्त-डाउनलोड किताबें मिल सकती हैं (एक Larmouth द्वारा दूसरा डब्यूसन द्वारा)।

IMHO अधिकांश अन्य उत्पाद केवल अभी तक दूसरे-आरपीसी-स्टब-जनरेटर बनाने की कोशिश करते हैं, जो धारावाहिकता मुद्दे में बहुत अधिक हवा को पंप करते हैं। ठीक है, अगर एक की जरूरत है कि, एक ठीक हो सकता है। लेकिन मेरे लिए, वे सन-आरपीसी (80 के दशक के अंत से) के पुनर्निवेश की तरह दिखते हैं, लेकिन, अरे, यह ठीक काम किया।

Answer 5

Microsoft का बॉन्ड ( https://github.com/Microsoft/bond ) प्रदर्शन, कार्यक्षमता और प्रलेखन के साथ बहुत प्रभावशाली है। हालाँकि यह अभी (13 वें फेब 2015) के रूप में कई लक्ष्य प्लेटफार्मों का समर्थन नहीं करता है। मैं केवल इसे मान सकता हूं क्योंकि यह बहुत नया है। वर्तमान में यह अजगर, सी # और सी ++ का समर्थन करता है। इसका उपयोग एमएस द्वारा हर जगह किया जा रहा है। मैंने इसे आज़माया, बॉन्ड का उपयोग करने वाले एसी # डेवलपर के रूप में, प्रोटोबुफ़ का उपयोग करने की तुलना में बेहतर है, हालांकि मैंने थ्रिफ्ट का भी उपयोग किया है, एकमात्र समस्या जिसका मुझे सामना करना पड़ा था, मैं प्रलेखन के साथ था, मुझे यह समझने की कई कोशिशें करनी थीं कि चीजें कैसे होती हैं।

बॉन्ड पर कुछ संसाधन इस प्रकार हैं ( https://news.ycombinator.com/item?id=8866694 , https://news.ycombinator.com/item?id=8866848 , https://microsoft.github.io/ बंधन / Why_bond.html )

Answer 6

प्रदर्शन के लिए, एक डेटा बिंदु jvm-serializers बेंचमार्क है - यह काफी विशिष्ट, छोटे संदेश है, लेकिन यदि आप जावा प्लेटफॉर्म पर हैं तो यह मदद कर सकता है। मुझे लगता है कि सामान्य तौर पर प्रदर्शन सबसे महत्वपूर्ण अंतर नहीं होगा। इसके अलावा: सुसमाचार के रूप में लेखकों के शब्दों को कभी न लें; कई विज्ञापित दावे फर्जी हैं (उदाहरण के लिए मेसकप साइट में कुछ संदिग्ध दावे हैं; यह तेज़ हो सकता है, लेकिन जानकारी बहुत ही अस्पष्ट है, उपयोग का मामला बहुत यथार्थवादी नहीं है)।

एक बड़ा अंतर यह है कि क्या एक स्कीमा का उपयोग किया जाना चाहिए (पीबी, थ्रिफ्ट कम से कम; एवरो यह वैकल्पिक हो सकता है; ASN मुझे लगता है कि मैं भी। MsgPack, जरूरी नहीं)।

इसके अलावा: मेरी राय में यह स्तरित, मॉड्यूलर डिजाइन का उपयोग करने में सक्षम होना अच्छा है; अर्थात्, RPC परत को डेटा प्रारूप, क्रमांकन को निर्देशित नहीं करना चाहिए। दुर्भाग्यवश अधिकांश उम्मीदवार इन पर सख्ती करते हैं।

अंत में, जब डेटा प्रारूप का चयन करते हैं, तो आजकल का प्रदर्शन पाठ प्रारूप का उपयोग नहीं करता है। धधकते हुए JSON पार्सर्स (और बहुत तेज़ स्ट्रीमिंग xml पार्सर) हैं; और जब स्क्रिप्टिंग भाषाओं और उपयोग में आसानी से इंटरऑपरेबिलिटी पर विचार करते हैं, तो बाइनरी प्रारूप और प्रोटोकॉल सबसे अच्छा विकल्प नहीं हो सकता है।

Comments

अनुभव साझा करने के लिए धन्यवाद, लेकिन मुझे लगता है कि मुझे अभी भी द्विआधारी प्रारूप की आवश्यकता है (मेरे पास वास्तव में बहुत बड़ी मात्रा में डेटा है) और शायद एवरो के साथ चिपके रहेंगे।

— andreypopp

हाँ समझ में आ सकता है। आप किसी भी दर पर संपीड़न का उपयोग करना चाह सकते हैं, भले ही प्रारूप का उपयोग करने के लिए (LZF अच्छा है क्योंकि यह gzip / deflate की तुलना में संपीड़ित / असंपीड़ित करने के लिए बहुत तेज़ है)।

— स्टैक्मैन मैन