c++ गूगल प्रोटोकॉल बफर बनाम serialization बढ़ावा?




performance protocol-buffers (9)

मुझे बूस्ट क्रमबद्धता के साथ कोई अनुभव नहीं है, लेकिन मैंने प्रोटोकॉल बफर का उपयोग किया है। मुझे प्रोटोकॉल बफर पसंद है। निम्नलिखित को ध्यान में रखें (मैं इसे बढ़ावा देने के ज्ञान के साथ कहता हूं)।

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

उम्मीद है की यह मदद करेगा।

क्या इन पुस्तकालयों के साथ अनुभव रखने वाले किसी भी टिप्पणी पर कोई टिप्पणी है जिसे उन्होंने पसंद किया? क्या उपयोग में कोई प्रदर्शन अंतर या कठिनाइयां थीं?


Boost.serialization के साथ कुछ अतिरिक्त चिंताएं हैं जिन्हें मैं मिश्रण में जोड़ूंगा। चेतावनी: मेरे पास दस्तावेज़ों को छोड़ने से परे प्रोटोकॉल बफर के साथ कोई प्रत्यक्ष अनुभव नहीं है।

ध्यान दें कि जब मुझे लगता है कि बूस्ट, और boost.serialization, यह क्या करता है, यह बहुत अच्छा है, मैं इस निष्कर्ष पर पहुंचा हूं कि डिफ़ॉल्ट संग्रह प्रारूप यह एक तार प्रारूप के लिए एक अच्छा विकल्प नहीं है।

अपनी कक्षा के संस्करणों के बीच अंतर करना महत्वपूर्ण है (जैसा कि अन्य उत्तरों में उल्लिखित है, boost.serialization डेटा संस्करण के लिए कुछ समर्थन है) और क्रमबद्धता पुस्तकालय के विभिन्न संस्करणों के बीच संगतता।

Boost.serialization के नए संस्करण उन अभिलेखागार उत्पन्न नहीं कर सकते हैं जो पुराने संस्करण deserialize कर सकते हैं (रिवर्स सत्य नहीं है: नए संस्करण हमेशा पुराने संस्करणों द्वारा किए गए अभिलेखागार को deserialize करने के इरादे से हैं)। इससे हमारे लिए निम्नलिखित समस्याएं आई हैं:

  • हमारे क्लाइंट और सर्वर सॉफ़्टवेयर दोनों धारावाहिक ऑब्जेक्ट्स बनाते हैं जो अन्य उपभोग करते हैं, इसलिए हम लॉकस्टेप में क्लाइंट और सर्वर दोनों को अपग्रेड करते समय केवल नए बूस्ट.serialization पर जा सकते हैं। (यह ऐसे माहौल में काफी चुनौती है जहां आपके पास अपने ग्राहकों का पूर्ण नियंत्रण नहीं है)।
  • बूस्ट साझा भागों के साथ एक बड़ी लाइब्रेरी के रूप में बंडल किया जाता है, और दोनों धारावाहिक कोड और बूस्ट लाइब्रेरी के अन्य हिस्सों (जैसे shared_ptr) एक ही फ़ाइल में उपयोग में हो सकते हैं, मैं बूस्ट के किसी भी हिस्से को अपग्रेड नहीं कर सकता क्योंकि मैं ' boost.serialization अपग्रेड करें। मुझे यकीन नहीं है कि यह एक निष्पादन योग्य में बढ़ावा के कई संस्करणों को जोड़ने का प्रयास करने के लिए संभव / सुरक्षित / सौदा है, या यदि हमारे पास बिट्स को दोबारा बढ़ाने के लिए बजट / ऊर्जा है जो कि अलग-अलग में बूस्ट के पुराने संस्करण पर बने रहने की आवश्यकता है निष्पादन योग्य (हमारे मामले में डीएलएल)।
  • बूस्ट का पुराना संस्करण जिस पर हम फंस गए हैं, हम संकलक के नवीनतम संस्करण का समर्थन नहीं करते हैं, इसलिए हम कंपाइलर के पुराने संस्करण पर भी अटक गए हैं।

Google वास्तव में प्रोटोकॉल बफर वायर प्रारूप को प्रकाशित करता प्रतीत होता है, और विकिपीडिया उन्हें आगे-संगत, पीछे-संगत के रूप में वर्णित करता है (हालांकि मुझे लगता है कि विकिपीडिया प्रोटोकॉल बफर लाइब्रेरी संस्करण के बजाय डेटा संस्करण का जिक्र कर रहा है)। जबकि इनमें से कोई भी आगे की संगतता की गारंटी नहीं है, यह मेरे लिए एक मजबूत संकेत की तरह लगता है।

संक्षेप में, मैं लॉकस्टेप में क्लाइंट और सर्वर को अपग्रेड करने की क्षमता रखने पर प्रोटोकॉल बफर जैसे एक प्रसिद्ध, प्रकाशित तार प्रारूप को प्राथमिकता दूंगा।

फुटनोट: मेरे द्वारा संबंधित उत्तर के लिए लापरवाही प्लग।


मैं लंबे समय तक बूस्ट सीरियलाइजेशन का उपयोग कर रहा हूं और बस प्रोटोकॉल बफर में खोला गया हूं, और मुझे लगता है कि उनके पास बिल्कुल वही उद्देश्य नहीं है। बीएस (यह नहीं देख रहा था) आपके सी ++ ऑब्जेक्ट्स को स्ट्रीम में सहेजता है, जबकि पीबी एक इंटरचेंज प्रारूप है जिसे आप पढ़ते हैं।

पीबी का डाटामैडल रास्ता आसान है: आपको सभी प्रकार की स्याही और फ्लोट, तार, सरणी, मूल संरचना मिलती है और यह काफी अधिक है। बीएस आपको एक ही चरण में अपनी सभी वस्तुओं को सीधे सहेजने की अनुमति देता है।

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

तो आपके लिए और क्या महत्वपूर्ण है: गति / अंतरिक्ष दक्षता या साफ कोड?


boost.serialization को केवल C ++ कंपाइलर की आवश्यकता है और आपको कुछ वाक्यविन्यास चीनी देता है

serialize_obj >> archive;
// ...
unserialize_obj << archive;

बचत और लोड करने के लिए। यदि सी ++ एकमात्र भाषा है जिसका आप उपयोग करते हैं तो आपको boost.serialization को एक गंभीर शॉट देना चाहिए।

मैंने Google प्रोटोकॉल बफर पर एक तेज नज़र डाली। जो मैं देखता हूं उससे मैं कहूंगा कि यह boost.serialization के लिए सीधे तुलनीय नहीं है। आपको अपने टूलचेन में .proto फ़ाइलों के लिए एक कंपाइलर जोड़ना होगा और .proto फ़ाइलों को स्वयं बनाए रखना होगा। एपीआई को c ++ में एकीकृत नहीं करता है क्योंकि boost.serialization करता है।

boost.serialization यह काम बहुत अच्छी तरह से डिज़ाइन किया गया है: सी ++ ऑब्जेक्ट्स को क्रमबद्ध करने के लिए :) ओटीओएच एक क्वेरी-एपीआई जैसे Google प्रोटोकॉल बफर आपको अधिक लचीलापन देता है।

चूंकि मैंने केवल boost.serialization का उपयोग किया है, इसलिए मैं प्रदर्शन तुलना पर टिप्पणी नहीं कर सकता।


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

प्रोटोबफ के साथ मेरी एक कठिनाई थी, उन्होंने अपने जेनरेट कोड GetMessage () में एक बहुत ही सामान्य रूप से प्रयुक्त फ़ंक्शन का नाम दिया, जो निश्चित रूप से Win32 GetMessage मैक्रो के साथ संघर्ष करता है।

मैं अभी भी protobufs की अत्यधिक सिफारिश करेंगे। वे बहुत उपयोगी हैं।


सीरियलाइजेशन को बढ़ावा दें

  • एक स्ट्रीम में डेटा लिखने के लिए एक पुस्तकालय है।
  • डेटा संपीड़ित नहीं करता है।
  • डेटा संस्करण स्वचालित रूप से समर्थन नहीं करता है।
  • एसटीएल कंटेनर का समर्थन करता है।
  • लिखे गए डेटा के गुण चुने गए धाराओं पर निर्भर करते हैं (जैसे एंडियन, संपीड़ित)।

प्रोटोकॉल बफर

  • अंतरफलक विवरण से कोड उत्पन्न करता है (डिफ़ॉल्ट रूप से सी ++, पायथन और जावा का समर्थन करता है। सी, सी # और अन्य तृतीय पक्ष द्वारा)।
  • वैकल्पिक रूप से डेटा संपीड़ित करता है।
  • डेटा संस्करण स्वचालित रूप से संभालती है।
  • प्लेटफॉर्म के बीच एंडियन स्वैपिंग को संभालता है।
  • एसटीएल कंटेनर का समर्थन नहीं करता है।

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

संपादित करें: 24-11-10: बीएस संस्करण में "स्वचालित रूप से" जोड़ा गया।


मैंने दोनों प्रणालियों के साथ थोड़ा सा खेला है, कुछ भी गंभीर नहीं, बस कुछ साधारण हैकिश सामान, लेकिन मुझे लगा कि पुस्तकालयों का उपयोग करने के तरीके में आपको एक वास्तविक अंतर है।

बूस्ट :: क्रमबद्धता के साथ, आप पहले अपने स्वयं के structs / कक्षाएं लिखते हैं, और फिर संग्रह विधियां जोड़ते हैं, लेकिन आप अभी भी कुछ सुंदर "पतली" कक्षाओं के साथ छोड़ चुके हैं, जिन्हें डेटा सदस्यों के रूप में उपयोग किया जा सकता है, विरासत में, जो भी हो।

प्रोटोकॉल बफर के साथ, एक साधारण संरचना के लिए उत्पन्न कोड की मात्रा काफी महत्वपूर्ण है, और उत्पन्न होने वाले structs और कोड का संचालन करने के लिए अधिक मतलब है, और आप प्रोटोकॉल बफर की कार्यक्षमता का उपयोग अपने स्वयं के आंतरिक संरचनाओं से डेटा परिवहन के लिए करते हैं ।


आप अपने "असली" डोमेन ऑब्जेक्ट्स के साथ कड़े संयोजन में बूस्ट क्रमबद्धता का उपयोग कर सकते हैं, और पूर्ण ऑब्जेक्ट पदानुक्रम (विरासत) को क्रमबद्ध कर सकते हैं। प्रोटोबफ विरासत का समर्थन नहीं करता है, इसलिए आपको एकत्रीकरण का उपयोग करना होगा। लोग तर्क देते हैं कि प्रोटोबफ का उपयोग डीटीओ (डेटा ट्रांसफर ऑब्जेक्ट्स) के लिए किया जाना चाहिए, न कि कोर डोमेन ऑब्जेक्ट्स के लिए। मैंने बूस्ट :: सीरियलाइजेशन और प्रोटोबफ दोनों का उपयोग किया है। बूस्ट का प्रदर्शन :: क्रमबद्धता को ध्यान में रखा जाना चाहिए, cereal एक विकल्प हो सकता है।


इंजीनियरिंग में लगभग हर चीज के साथ, मेरा जवाब है ... "यह निर्भर करता है।"

दोनों अच्छी तरह से परीक्षण, vetted प्रौद्योगिकियों हैं। दोनों आपके डेटा ले लेंगे और इसे किसी जगह भेजने के लिए किसी मित्रवत में बदल देंगे। दोनों शायद पर्याप्त तेज़ होंगे, और यदि आप वास्तव में यहां या वहां बाइट की गिनती कर रहे हैं, तो संभवत: आप या तो खुश होने वाले नहीं हैं (चलिए इसका सामना करते हैं दोनों बनाए गए पैकेट एक्सएमएल या जेएसओएन का एक छोटा सा अंश होंगे)।

मेरे लिए, यह वास्तव में वर्कफ़्लो पर आता है और दूसरी तरफ आपको सी ++ के अलावा कुछ और चाहिए या नहीं।

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

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







boost-serialization