বাইনারি JSON: MessagePack, CBOR ও BSON-এর মধ্যে বাছাই

মূল কথা: বাহ্যিক বিনিময় ও মানুষের দেখতে হওয়া ডেটার জন্য টেক্সট JSON রাখুন, আর অভ্যন্তরীণ লিংকে MessagePack বা CBOR-এ তখনই যান যখন বাইনারি পেললোড, 2^53-এর বেশি ইন্টিজার বা নিখুঁত দশমিক কম্প্রেসড আকার বা টাইপ প্রকাশক্ষমতাকে সত্যিকারের সমস্যা বানায়; BSON MongoDB ইকোসিস্টেমের।

টেক্সট JSON হোয়াইটস্পেস বাঁচায়; বাইনারি ফরম্যাট বিরামচিহ্ন আর সংখ্যার টেক্সট রূপ বাঁচায়। ফিল্ড-নাম এখনও প্রতি রেকর্ডে একবার আসে, তাই বদলানোর আগে প্রকৃত সঞ্চয় হিসাব করুন।

১. বাইনারি JSON আসলে কী বাঁচায়

প্রথমে প্রত্যাশা ঠিক করুন। এই ফরম্যাটগুলোর কোনোটিই "আরেক JSON সিনট্যাক্স" নয়। তারা একই ডেটা মডেল বাইটে এনকোড করে: অবজেক্ট, অ্যারে, স্ট্রিং, সংখ্যা, বুলিয়ান ও null। তারা যা সরায় তা নির্দিষ্ট:

• কোট, কোলন, কমা ও ব্রেসের মতো কাঠামোগত অক্ষর;
• সংখ্যার দশমিক টেক্সট রূপ, ফলে 32 একটি একক বাইট হয়;
• স্ট্রিং সীমানার জন্য পুনরায় স্ক্যান, যা নির্দিষ্ট-দৈর্ঘ্য প্রিফিক্সে বদলায়;
• বাইনারি পেললোডের Base64 এনকোডিং, যা সরাসরি বাইট হিসেবে রাখা যায়।

তারা যা সরাতে পারে না তা সমান নির্দিষ্ট: ফিল্ড-নাম এখনও প্রতি রেকর্ডে স্ট্রিং হিসেবে আসে। MessagePack ম্যাপ, CBOR ম্যাপ ও BSON ডকুমেন্ট — সবই প্রতিটি এন্ট্রির জন্য কি পুনরাবৃত্তি করে। তাই আপনার JSON যদি একই আকৃতির দশ হাজার রেকর্ড হয়, টেক্সট ও বাইনারির কম্প্রেসড আকারের ব্যবধান সহজাত ধারণার চেয়ে অনেক ছোট, কারণ পুনরাবৃত্ত ফিল্ড-নাম দূর করতে gzip সবচেয়ে ভালো।

২. তিন ফরম্যাট কোথা থেকে এসেছে

CBOR সবচেয়ে বেশি প্রমিত: IANA-নিবন্ধিত application/cbor মিডিয়া টাইপ, নির্ধারক এনকোডিং নিয়ম, আর বর্ণনার জন্য CDDL। MessagePack সবচেয়ে হালকা, স্পেসিফিকেশন এক পৃষ্ঠায় ধরে। BSON সবচেয়ে ভারী: এটি ObjectId, Decimal128, তারিখ ও বাইনারি উপ-টাইপ তার টাইপ সিস্টেমে গেঁথে দেয়, এজন্যই এটি কেবল MongoDB ইকোসিস্টেমের ভেতরেই সত্যিকারভাবে জনপ্রিয়।

৩. একই ডেটা, চার এনকোডিং

{"name":"joe"} উদাহরণ নিন। বাইট খরচ সহজে তুলনা করা যায়:

MessagePack-এর নয়টি বাইট ভেঙে দেখুন:

• 81: উচ্চ নিবল 1000 মানে ম্যাপ, নিম্ন নিবল 0001 মানে এক কি-ভ্যালু জোড়া;
• a3: উচ্চ তিন বিট 101 মানে দৈর্ঘ্য ৩-এর নির্দিষ্ট-দৈর্ঘ্য স্ট্রিং;
• 6e 61 6d 65: name-এর ASCII;
• a3: দৈর্ঘ্য ৩-এর আরেকটি স্ট্রিং;
• 6a 6f 65: joe।

CBOR-এর a1 হলো মেজর টাইপ ৫ (ম্যাপ) দৈর্ঘ্য ১ সহ, আর 64 মেজর টাইপ ৩ (টেক্সট স্ট্রিং) দৈর্ঘ্য ৪ সহ, তাই অর্থ প্রায় MessagePack-এর সমরূপ। BSON বড়: প্রতিটি ডকুমেন্ট ৪-বাইট মোট দৈর্ঘ্য বহন করে, প্রতিটি ফিল্ড একটি টাইপ বাইট ও তার নাম পুনরাবৃত্তি করে, আর প্রতিটি স্ট্রিং দৈর্ঘ্য প্লাস শেষে \0 পুনরাবৃত্তি করে। ছোট ডকুমেন্টে BSON সহজেই JSON টেক্সটের চেয়ে বড় হতে পারে।

ঐ বাইটগুলো হেক্স হিসেবে রেন্ডার করে প্রিফিক্স সরাসরি যাচাই করতে পারেন:

复制const messagePackBytes = [0x81, 0xa3, 0x6e, 0x61, 0x6d, 0x65, 0xa3, 0x6a, 0x6f, 0x65];
const hexText = messagePackBytes.map((byte) => byte.toString(16)).join(' ');
console.log(hexText); // 81 a3 6e 61 6d 65 a3 6a 6f 65

৩.১ আকার ও পার্স গতি: বিপণন সংখ্যা উপেক্ষা করুন

"বাইনারি ১০ গুণ দ্রুত" দাবিকে দুই প্রশ্নে ভাগ করা উচিত।

আকার। কম্প্রেসড না করে বাইনারি ছোট, কারণ বিরামচিহ্ন ও হোয়াইটস্পেস নেই। কিন্তু বাস্তব পাইপলাইন প্রায় সবসময় কম্প্রেস করে: gzip বা brotli-এর পর পুনরাবৃত্ত ফিল্ড-নাম কম্প্রেস হয়ে যায়, আর বাইনারির সুবিধা নাটকীয়ভাবে কমে। JSON মিনিফিকেশন বনাম gzip-এর পদ্ধতি অনুসরণ করুন: আগে কম্প্রেসড বাইট মাপুন, তারপর ঠিক করুন ফরম্যাট বদলানো লাভজনক কি না।

পার্স গতি। বাইনারি লেক্সিং (কোট, কমা ও সংখ্যার অক্ষর স্ক্যান) এড়িয়ে যায়, তাই তত্ত্বে দ্রুত হওয়া উচিত। তবে JavaScript-এ প্রধান খরচ অবজেক্ট ও মেমরি বরাদ্দ, যা কোনো ডিকোডার এড়াতে পারে না। ডেটার আকৃতি, ফিল্ড সংখ্যা ও বাস্তবায়নের গুণ — সবই গুরুত্বপূর্ণ, তাই একমাত্র নির্ভরযোগ্য সিদ্ধান্ত আসে নিজের পেললোড বেঞ্চমার্ক করে, বিক্রেতার গুণিতক উদ্ধৃত করে নয়। একক পেললোড একবারে মেমরিতে পড়তে খুব বড় হলে এনকোডিং লাভ মাপার আগে বড় JSON পার্সিং ও স্ট্রিমিং-এ বর্ণিত পদ্ধতিতে টুকরো করুন।

৪. int64 ও বাইনারি ফিল্ড: বদলানোর প্রকৃত কারণ

আকার প্রায়ই ফরম্যাট বদলানোর কারণ নয়। টাইপ প্রকাশক্ষমতাই কারণ।

৪.১ 2^53-এর বেশি ইন্টিজার

JavaScript-এ JSON সংখ্যা ডাবলে পড়ে, তাই 9007199254740993 হয়ে যায় 9007199254740992। তিন বাইনারি ফরম্যাট এটি ভিন্নভাবে সামলায়:

CBOR একমাত্র যার যেকোনো-প্রিসিশন ইন্টিজারের স্ট্যান্ডার্ড রূপ আছে: ৬৪ বিটের বেশি মান ট্যাগ ২ (অ-ঋণাত্মক) বা ট্যাগ ৩ (ঋণাত্মক) দিয়ে বাইট স্ট্রিংয়ের চারপাশে মোড়া হয়। MessagePack ও BSON স্ট্রিং বা নিজস্ব এক্সটেনশন প্রথায় ফিরে যায়।

৪.২ বাইনারি পেললোড

JSON-এ বাইনারি প্রকাশের ঠিক এক উপায়: Base64, যা পেললোড প্রায় এক-তৃতীয়াংশ বাড়ায় আর অতিরিক্ত ডিকোড কপি দরকার করে। MessagePack-এ bin টাইপ (0xc4–0xc6), CBOR-এ বাইট স্ট্রিং (মেজর টাইপ ২), আর BSON-এ বাইনারি উপ-টাইপ। ছবি, হ্যাশ, ভেক্টর বা কম্প্রেসড ব্লক পরিবহনে এই পার্থক্য কয়েকটি বিরামচিহ্ন বাইট বাঁচানোর চেয়ে অনেক বেশি গুরুত্বপূর্ণ।

৫. পাশাপাশি তুলনা

৬. ব্রাউজার ও Node সমর্থন

Node 24-এ এই কোডেকগুলোর কোনোটিই নেই, তাই লাইব্রেরি ইনস্টল করতে হয়। সাধারণ পছন্দ:

দুই পরিবারই Uint8Array-এ কাজ করে এবং Buffer দরকার করে না। সংস্করণের পার্থক্য লক্ষ্য করুন:

复制import { encode, decode } from '@msgpack/msgpack';

/**
 * Encodes an object to MessagePack bytes and decodes it immediately for verification.
 * @param payload Plain object to encode
 * @returns The decoded value and the encoded byte length
 */
function roundTrip(payload: Record<string, unknown>): { decoded: unknown; byteLength: number } {
  const bytes = encode(payload);
  return { decoded: decode(bytes), byteLength: bytes.byteLength };
}

বেশিরভাগ লাইব্রেরি ডিফল্টভাবে বড় ইন্টিজারকে number-এ ডিকোড করে এবং নিরাপদ সীমার বাইরে প্রিসিশন হারায়। নিখুঁত মান গুরুত্বপূর্ণ হলে BigInt অপশন স্পষ্টভাবে চালু করুন (@msgpack/msgpack-এ useBigInt64, cbor-x-এ সমতুল্য সুইচ), নাহলে আপনি কেবল JSON-এর পুরোনো সমস্যাকে নতুন ফরম্যাটে সরিয়েছেন।

৭. ডিবাগযোগ্যতা ও প্রোটোকল সামঞ্জস্য

৭.১ ডিবাগযোগ্যতা: সবচেয়ে বড় লুকানো খরচ

টেক্সট JSON-এর সবচেয়ে বড় সুবিধা আকার নয়; আপনি যেকোনো সময় খুলে দেখতে পারেন। বাইনারিতে যাওয়ার পর:

• grep, awk ও jq — সবই কাজ করা বন্ধ করে, আর লগ পাইপলাইনে অতিরিক্ত ডিকোড ধাপ লাগে;
• প্রোডাকশন ডিবাগে সঠিক সংস্করণের সঠিক ডিকোডার দরকার, নাহলে যে ফিল্ড-নাম দেখবেন তা ভুল;
• ক্যাপচার করা ট্রাফিক ব্রাউজার ডেভেলপার টুলে অপাঠ্য বাইট ব্লব হিসেবে দেখায়;
• কোড রিভিউ ডিফে হেক্সাডেসিমেলের স্ট্রিং দেখায়।

CBOR-এ ডায়াগনস্টিক নোটেশন আছে, যা বাইটকে JSON-এর কাছাকাছি পাঠযোগ্য টেক্সটে ফিরিয়ে দেয়, যেমন ম্যাপকে {1: 2} হিসেবে; MessagePack-ও কয়েকটি কমান্ড-লাইন ডিকোডার রাখে। কিন্তু সবগুলোরই অতিরিক্ত ইনস্টল লাগে আর সেগুলো স্ট্যান্ডার্ড অপারেশন পথের বাইরে।

সিদ্ধান্ত: যখনই মানুষকে ঘন ঘন ডেটা পরিদর্শন করতে হয়, বাইনারি ফরম্যাটের লুকানো খরচ তার বাঁচানো ব্যান্ডউইথকে ছাড়িয়ে যায়।

৭.২ প্রোটোকল সামঞ্জস্য ও এক্সটেনশন

• CBOR-এ সবচেয়ে সম্পূর্ণ ট্যাগ ব্যবস্থা: তারিখ-সময় স্ট্রিংয়ের জন্য ট্যাগ 0, Unix টাইমস্ট্যাম্পের জন্য ট্যাগ 1, বিগনামের জন্য ট্যাগ 2 ও 3, এবং এমবেডেড CBOR-এর জন্য ট্যাগ 24। নির্ধারক এনকোডিংয়ের সঙ্গে মিলিয়ে এটি স্বাক্ষর ও ক্রস-বাস্তবায়ন সামঞ্জস্য দরকার এমন প্রোটোকলে ব্যবহৃত হয়, যেমন COSE, WebAuthn ও CWT।
• MessagePack এক্সটেনশন টাইপ বাস্তবায়নকারীর হাতে ছাড়ে। বাস্তবে একমাত্র প্রচলিতটি টাইমস্ট্যাম্প (এক্সটেনশন টাইপ -1)। দল ছাড়িয়ে প্রতিটি এক্সটেনশন টাইপ প্রোটোকল ডকুমেন্টে লিখতে হবে, নাহলে অন্য প্রান্ত ডিকোড করতে পারবে না।
• BSON-এ নির্দিষ্ট টাইপ কোড, আর ObjectId, Decimal128, MinKey ও MaxKey MongoDB-নির্দিষ্ট অর্থ। BSON-কে সাধারণ বিনিময় ফরম্যাট ধরলে অগণিত অব্যবহৃত টাইপ ও অব্যবহৃত দৈর্ঘ্য প্রিফিক্স সঙ্গে আসে।

প্রোটোকল "একই ডেটা একই বাইট উৎপন্ন করবে" দাবি করলে কেবল CBOR স্ট্যান্ডার্ড উত্তর দেয়; MessagePack ও BSON-এ ফিল্ড ক্রম ও এনকোডিং বিস্তারিত অতিরিক্ত চুক্তি দরকার।

৮. কখন বদলানো লাভজনক

বদলানোর পক্ষে সংকেত:

• পেললোড বড়, দুই প্রান্তই বদলানো যায়, আর কম্প্রেসড আকার এখনও অর্থবহভাবে আলাদা;
• আপনি বাইনারি কন্টেন্ট পরিবহন করেন আর Base64-এর স্ফীতি ও ডিকোড খরচ মাপযোগ্য;
• আপনার ৬৪-বিট ইন্টিজার বা নিখুঁত দশমিক দরকার যা JSON ডাবল প্রকাশ করতে পারে না;
• লিংকটি সার্ভার-থেকে-সার্ভার আর ডায়াগনস্টিক টুলিং প্রমিত করা যায়।

বিরুদ্ধে সংকেত:

• gzip বা brotli ইতিমধ্যে আছে এবং লাভ একক-অঙ্কের শতাংশ;
• API পাবলিক এবং তৃতীয়-পক্ষের কাছে কেবল সাধারণ-উদ্দেশ্যের HTTP ক্লায়েন্ট আছে;
• ডেটা লগ বা কনফিগারেশন যা মানুষ হাতে পড়ে;
• ডিকোডার ও সংস্করণ সামঞ্জস্য রক্ষণাবেক্ষণের বাজেট দলে নেই।

একটি মধ্যবর্তী পথও কাজ করে: বাইরে JSON রাখুন আর অভ্যন্তরীণ ক্যাশের জন্য MessagePack ব্যবহার করুন। ক্যাশে মান কেবল আপনার নিজের সার্ভিস পড়ে, তাই আকার ও পার্স খরচ দুটোই উন্নত হয়, আর ক্যাশে ক্লিয়ার করলে চুক্তি না ছুঁয়ে যেকোনো সমস্যা মিটে যায়।

৯. চেকলিস্ট

• [ ] বাস্তব ডেটার কম্প্রেসড বাইট সংখ্যা তুলনা করুন, কম্প্রেসড না করা সংখ্যা নয়;
• [ ] বড়-ইন্টিজার নীতি ঠিক করুন: BigInt অপশন, স্ট্রিং পরিবহন, বা CBOR বিগনাম;
• [ ] বাইনারি ফিল্ড Base64-এ মুড়ে না দিয়ে bin বা বাইট স্ট্রিং হিসেবে পাঠান;
• [ ] এক্সটেনশন টাইপ ও ট্যাগ প্রোটোকল ডকুমেন্টে লিখুন এবং ডিকোডার সংস্করণ পিন করুন;
• [ ] প্রোডাকশন ইনসিডেন্টে চালু করা যায় এমন একটি টেক্সট-JSON ডিবাগ পথ রাখুন;
• [ ] বেঞ্চমার্ক চালিয়ে পুনরুৎপাদনযোগ্য সংখ্যা রেকর্ড করুন, মৌখিক দাবি নয়।

MessagePack ও CBOR-এর পার্থক্য কী?

তাদের এনকোডিং খুব কাছাকাছি: ম্যাপ, অ্যারে ও স্ট্রিং — সবই কম্প্যাক্ট টাইপ-প্লাস-দৈর্ঘ্য প্রিফিক্স ব্যবহার করে। মূল পার্থক্য প্রমিতকরণ। CBOR একটি IETF RFC, যার IANA মিডিয়া টাইপ, ট্যাগ ব্যবস্থা ও নির্ধারক এনকোডিং নিয়ম আছে; MessagePack কমিউনিটি স্পেসিফিকেশন যার এক্সটেনশন টাইপ ব্যক্তিগত চুক্তির উপর নির্ভর করে। স্বাক্ষর, ক্রস-বাস্তবায়ন সামঞ্জস্য বা সীমিত-ডিভাইস প্রোটোকল দরকার হলে CBOR বাছুন।

BSON কি সাধারণ ফরম্যাট হিসেবে JSON-কে প্রতিস্থাপন করতে পারে?

সুপারিশ করা হয় না। BSON ডেটাবেস ডকুমেন্টের জন্য নকশা করা: প্রতিটি ডকুমেন্ট ৪-বাইট মোট দৈর্ঘ্য বহন করে, প্রতিটি ফিল্ড তার টাইপ ও নাম পুনরাবৃত্তি করে, আর ছোট ডকুমেন্ট JSON টেক্সটের চেয়ে বড় হয়ে যায়। এতে ObjectId ও MinKey-এর মতো MongoDB-নির্দিষ্ট টাইপও আছে। MongoDB-এর বাইরে এর টাইপ সিস্টেমের বেশিরভাগ অব্যবহৃত, অথচ আকারের জরিমানা থেকে যায়।

বাইনারি ফরম্যাট আমার পেললোড কতটা ছোট করে?

এটি ডেটার আকৃতির উপর নির্ভর করে। ফিল্ড-নাম ভারীভাবে পুনরাবৃত্ত হলে কম্প্রেসড টেক্সট JSON ও বাইনারি ফরম্যাট কাছাকাছি দাঁড়ায়; নাম ছোট আর ডেটা কাঠামোগত অক্ষর ও সংখ্যায় ভরা হলে বাইনারির সুবিধা স্পষ্ট। সাধারণ গুণিতক দিয়ে অনুমান না করে বাস্তব নমুনা কম্প্রেসড ও অকম্প্রেসড দুইভাবেই মাপুন, তারপর সিদ্ধান্ত নিন।

বাইনারি ডেটা কি এখনও jq দিয়ে ডিবাগ করা যায়?

না। jq কেবল টেক্সট JSON প্রসেস করে আর MessagePack বা CBOR বাইটে সঙ্গে সঙ্গে ব্যর্থ হবে। প্রথমে মিলে যাওয়া লাইব্রেরি দিয়ে JSON-এ ডিকোড করে তারপর jq-তে পাঠাতে হবে; CBOR ডায়াগনস্টিক-নোটেশন টুলের মাধ্যমেও পাঠযোগ্য টেক্সট হয়ে যেতে পারে। প্রয়োজনের সময় টুলিং ইনস্টল করার চেয়ে টেক্সট ডিবাগ পথ রাখা সস্তা।