برنامه نویسی

Json vs Protocol Buffers vs Flatbuffers: شیرجه عمیق

Json vs Protocol Buffers vs Flatbuffers: شیرجه عمیق

چرا من این سه مورد را کاوش کردم؟

در چشم انداز تکنولوژیکی سریع ، سریال سازی داده های کارآمد از همیشه بسیار مهم است. به عنوان توسعه دهندگان ، ما دائماً به دنبال راه هایی برای بهینه سازی برنامه های خود برای سرعت و عملکرد هستیم. به تازگی ، در حالی که روی پروژه ای کار می کردم که نیاز به رسیدگی به حجم زیادی از داده ها داشت ، من در خط لوله پردازش داده های ما با تنگنا روبرو شدم. این زمانی است که من شروع به کاوش در قالب های مختلف سریال سازی داده ها کردم و به JSON ، بافر پروتکل و Flatbuffers افتادم. این سه قالب رویکردهای منحصر به فردی برای سریال سازی داده ها ارائه می دهند که هر کدام مجموعه ای از نقاط قوت و ضعف خود را دارند. در این پست وبلاگ ، ما به دنیای JSON ، Buffers پروتکل و Flatbuffers می پردازیم و ویژگی های عملکرد آنها را مقایسه می کنیم و مناسب بودن آنها را برای موارد مختلف استفاده می کنیم. بنابراین ، اگر شما کنجکاو هستید که در مورد تجارت بین این قالب های سریال سازی داده های محبوب اطلاعات کسب کنید ، در این سفر به من بپیوندید زیرا ما اسرار آنها را کشف می کنیم و کشف می کنیم که کدام یک در قلمرو کارآمد داده ها حاکم است.

درک سه قالب سریال سازی

1. JSON (نماد شیء JavaScript)

JSON به دلیل سادگی ، خوانایی و نحو دوستانه انسان ، بسیار پرکاربردترین فرمت تبادل داده است. این متن مبتنی بر متن است و به طور گسترده در زبانهای برنامه نویسی پشتیبانی می شود.

جوانب مثبت:

  • خواندن و اشکال زدایی آسان است.

  • تقریباً در هر زبان برنامه نویسی پشتیبانی می شود.

  • بدون اجرای طرحواره ، آن را انعطاف پذیر می کند.

منفی ها:

  • اندازه بزرگتر به دلیل قالب بندی قابل خواندن انسان.

  • سرعت تجزیه آهسته در مقایسه با قالب های باینری.

  • بدون پشتیبانی داخلی برای تایپ قوی.

2. بافر پروتکل (Protobuf)

بافرهای پروتکل ، که توسط Google تهیه شده است ، یک قالب سریال سازی باینری جمع و جور و کارآمد است که برای تبادل داده با کارایی بالا طراحی شده است.

جوانب مثبت:

  • قالب باینری جمع و جور ، کاهش اندازه قابل توجهی در مقایسه با JSON.

  • سریال سازی سریعتر و deserialization.

  • به شدت با اجرای طرحواره تایپ شده است.

  • سازگاری به عقب و رو به جلو با نسخه.

منفی ها:

  • قبل از استفاده نیاز به تعریف یک طرحواره (پرونده .proto) دارد.

  • قابل خواندن انسانی نیست ، اشکال زدایی را سخت تر می کند.

  • برای تولید کد خاص زبان به یک کامپایلر نیاز دارد.

3. Flatbuffers

Flatbuffers ، همچنین توسط Google ، یک کتابخانه سریال سازی بسیار بهینه سازی شده است که برای سناریوهایی طراحی شده است که در آن نیاز به دفع کپی صفر است.

جوانب مثبت:

  • بسیار سریع که امکان دسترسی مستقیم به داده های سریالی را بدون تجزیه فراهم می کند.

  • استفاده از حافظه کارآمد ، جلوگیری از تخصیص اضافی.

  • به عقب و رو به جلو سازگار است.

  • از تکامل طرحواره اختیاری مانند ProtoBUF پشتیبانی می کند.

منفی ها:

  • API پیچیده تر در مقایسه با JSON و Protobuf.

  • به اندازه JSON به طور گسترده پشتیبانی نمی شود.

  • به دلیل ابرداده اضافی ، پرونده های باینری بزرگتر از ProToBUF تولید می کند.

محک در جاوا با استفاده از JMH

برای به دست آوردن مقایسه دقیق ، من از JMH ** (Java Microbenchmark Harness) ** استفاده کردم تا سریال سازی و زمان دفع کننده JSON ، بافر پروتکل و مسطح در جاوا را معیار کنم. JMH برای محک زدن کد جاوا با کنترل دقیق بر بهینه سازی JVM طراحی شده است.

تنظیم معیار:

داده های آزمایشی: یک شیء ساده با چندین زمینه (عدد صحیح ، رشته ها ، اشیاء تو در تو).

کتابخانه ها استفاده می شدند:

فرایند معیار:

  • شیء را به یک آرایه بایت سریال کنید.

  • آرایه بایت را به یک شیء بازگرداند.

  • زمان لازم برای هر دو عمل را اندازه گیری کنید.

  • معیارها را چندین بار اجرا کنید تا اثرات گرم شدن JVM را به حداقل برسانید.

  • برای آزمایش عملکرد در شرایط مختلف از اندازه های مختلف بار استفاده کنید.

نتایج

https%3A%2F%2Fdev to uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fj9kl5zzg5z65l1db8rld

https%3A%2F%2Fdev to

مشاهدات:

  • JSON به دلیل قالب متن مبتنی بر متن و تجزیه سربار ، کمترین عملکرد را داشت.

  • بافرهای پروتکل به طور قابل توجهی از JSON در هر دو سریال سازی و deserialization بهتر عمل کردند.

  • Flatbuffers به ​​دلیل مکانیسم دسترسی به کپی صفر ، بهترین عملکرد دفع را داشت.

  • Protobuf کوچکترین اندازه سریالی را داشت و آن را برای بهره وری شبکه ایده آل می کند.

موارد استفاده در دنیای واقعی

چه موقع از JSON استفاده کنیم؟

  • هنگامی که خوانایی و اشکال زدایی انسان مهم است (به عنوان مثال ، API های REST ، پرونده های پیکربندی).

  • در صورت نیاز به قابلیت همکاری با سیستم های متعدد.

  • هنگامی که اجرای طرحواره مهم نیست.

مثال: JSON به طور گسترده ای در API های وب مانند API OpenWeather استفاده می شود ، جایی که قابلیت خواندن و سهولت استفاده بیشتر از عملکرد است.

چه موقع از بافرهای پروتکل استفاده کنیم؟

  • هنگامی که تبادل داده باید فشرده و سریع باشد (به عنوان مثال ، خدمات GRPC ، انتقال داده IoT).

  • در صورت نیاز به اجرای طرحواره و تایپ قوی.

  • هنگامی که سازگاری به عقب و رو به جلو ضروری است.

مثال: میکروسرویسهای مبتنی بر GRPC در سیستم های توزیع شده در مقیاس بزرگ ، مانند برنامه های بانکی یا پیام رسانی ، اغلب از ProToBUF برای انتقال کارآمد داده استفاده می کنند.

چه موقع از Flatbuffers استفاده کنید؟

  • هنگامی که تأخیر فوق العاده کم مورد نیاز است (به عنوان مثال ، توسعه بازی ، برنامه های کاربردی در زمان واقعی ، سیستم های معاملاتی با فرکانس بالا).

  • هنگامی که deserialization Zero-Copy برای عملکرد لازم است.

  • هنگام برخورد با داده های ساختاری که نیاز به خواندن های مکرر دارند اما به ندرت می نویسد.

مثال: موتورهای بازی مانند وحدت از Flatbuffers برای فیزیک در زمان واقعی و به روزرسانی های هوش مصنوعی استفاده می کنند زیرا آنها بدون تجزیه سربار به دسترسی سریع به داده های بزرگ ساختار یافته نیاز دارند.

افکار نهایی

JSON ، بافرهای پروتکل و مسطح هر یک از آنها اهداف مشخصی را ارائه می دهند. JSON برای تبادل داده های قابل خواندن با انسان ایده آل است ، بافرهای پروتکل در ارتباطات شبکه کارآمد برتری دارند و مسطح در سناریوهای زمان واقعی که نیاز به دفع کپی صفر دارند می درخشند.

برای پروژه سرگرمی من ، فهمیدم که در حالی که JSON برای نمونه سازی سریع آسان بود ، تغییر به ProtoBUF به طور قابل توجهی عملکرد را بهبود بخشید. اگر سرعت شدید لازم بود ، مسطح کننده ها بهترین انتخاب خواهند بود. انتخاب فرمت سریال مناسب به مورد استفاده خاص و محدودیت های عملکرد بستگی دارد.

کد را می توان در این مخزن GitHub یافت.

کدام یک را در پروژه های خود ترجیح می دهید؟ بیایید در مورد LinkedIn بحث کنیم

نوشته های مشابه

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

دکمه بازگشت به بالا