CobbleDB: কম লেটেন্সি এবং খরচের জন্য এআই সার্চ স্টোরেজ পুনর্নির্মাণ

এআই-নেটিভ সার্চ ওয়েব কন্টেন্ট কীভাবে প্রসেস, সংরক্ষণ এবং পরিবেশন করতে হবে তার ওপর বিভিন্ন প্রয়োজনীয়তা আরোপ করে। স্কেলে সেই চাহিদাগুলো পূরণ করতে, পারফরম্যান্স উন্নত করতে এবং খরচ কমাতে আমরা শুরু থেকে পুরো স্ট্যাক পুনর্নির্মাণ করছি।

দক্ষ প্রসেসিং এবং দ্রুত সার্ভিং শক্তিশালী করতে আমরা আমাদের নিজস্ব ক্রলিং, ইনডেক্সিং এবং র‍্যাঙ্কিং অবকাঠামো, এম্বেডিং মডেল এবং ইনফারেন্স ইঞ্জিন তৈরি করেছি। আমরা এখন স্টোরেজে সেই পদ্ধতিটি প্রসারিত করছি, যা হলো সংযোগকারী মাধ্যম যাতে প্রসেসিং লেখে এবং সার্ভিং যেখান থেকে রিড করে।

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

একটি নতুন অভ্যন্তরীণ কোডিং এজেন্ট স্বর্মের সাহায্যে, আমরা CobbleDB-কে কেন্দ্র করে এই লেয়ারটি পুনর্নির্মাণ করেছি, যা একটি কি-ভ্যালু হট স্টোর, যা টেকসই ডকুমেন্ট স্টেট এবং পাবলিশিংয়ের জন্য Pillar এবং ব্যাচড আপডেটের জন্য Lorry দ্বারা সমর্থিত। এই রিডিজাইনটি ডকুমেন্ট প্রসেসিংকে হট-স্টোর ইনজেশন থেকে আলাদা করে এবং আমাদের ওয়ার্কলোডে সার্ভিং টিউন করার সুযোগ দেয়। প্রোডাকশনে ব্যবহারের আগের ও পরের পরিমাপগুলোতে প্রায় ৫× কম ব্যাচ-রিড লেটেন্সি দেখা যায়, এবং আমাদের অভ্যন্তরীণ খরচ মডেল DynamoDB-এর তুলনায় অন্তত ২০% সাশ্রয়ের অনুমান করে।

এআই-নেটিভ সার্চের জন্য স্টোরেজ অবকাঠামো

একটি ক্লাসিক সার্চ স্ট্যাক একজন মানুষের পড়ার জন্য তৈরি করা হয়েছে, কোনো ভাষা মডেলের জন্য নয়। সেই পার্থক্যটি সেই দানাদারতাকে পরিবর্তন করে যে স্তরে সিস্টেমটিকে ওয়েব কন্টেন্ট প্রস্তুত, সংরক্ষণ এবং পরিবেশন করতে হয়।

র, আনপ্রসেসড HTML-কে মডেল-প্রস্তুত কন্টেন্টে রূপান্তর করতে, আমাদের প্রসেসিং পাইপলাইন প্রতিটি পেজ পরিষ্কার করে, সেগুলোকে শব্দার্থগতভাবে সুসংগত প্যাসেজে বিভক্ত করে, তাদের এম্বেডিং গণনা করে এবং ডাটাবেসে প্যাসেজ ও এম্বেডিংগুলো একসাথে সংরক্ষণ করে। কুয়েরির সময়, সার্ভিং পাইপলাইন কুয়েরির সাথে সবচেয়ে বেশি প্রাসঙ্গিক টেক্সট নির্বাচন করে এবং এটি মডেলে পাস করে।

দুটি স্বতন্ত্র ওয়ার্কফ্লো

তাই স্টোরেজ লেয়ারটিকে বিভিন্ন চাহিদাসম্পন্ন দুটি ওয়ার্কফ্লো সমর্থন করতে হবে: প্রসেসিং পাইপলাইন থেকে আপডেট ইনজেস্ট করা এবং কম লেটেন্সির রিড পরিবেশন করা।

রাইট সাইডে, নতুন পেজ ক্রমাগত আসতে থাকে, বিদ্যমান পেজগুলো পরিবর্তিত হয় এবং চাঙ্কিং পদ্ধতি বা এম্বেডিং মডেলে পরিবর্তনের জন্য কর্পাসের বড় অংশগুলো পুনরায় প্রসেস করার প্রয়োজন হতে পারে। স্টোরেজ লেয়ারটিকে এই আপডেটগুলোকে টেকসই ডকুমেন্ট স্টেটে অন্তর্ভুক্ত করতে হবে, বর্তমান সংস্করণগুলো ট্র্যাক করতে হবে, ডাউনস্ট্রিম সিস্টেমে সঠিক উপস্থাপনাগুলো প্রকাশ করতে হবে এবং র, ক্রল থেকে সম্পূর্ণ পাইপলাইন পুনরাবৃত্তি না করেই বড় ব্যাকফিল সমর্থন করতে হবে।

এর বিপরীতে, কুয়েরি-সময়ের রিড পেজ কি-এর ব্যাচের জন্য অনুরোধ করে এবং র‍্যাঙ্কিং ও প্যাসেজ নির্বাচনের জন্য সংশ্লিষ্ট প্যাসেজ টেক্সট ও এম্বেডিং রিট্রিভ করে। এই রিডগুলো চূড়ান্ত উত্তরের পথে অবস্থান করে, তাই সেগুলোকে দ্রুত সম্পন্ন করতে হবে।

এই ওয়ার্কলোডগুলোর জন্য বিভিন্ন ডিজাইনের প্রয়োজন হয়। প্রসেসিং টেকসই কিউ এবং আপডেটগুলো দক্ষতার সাথে সরবরাহ করার ক্ষমতা, ফেইলিওর রিট্রাই করা এবং বড় স্কেলে বিদ্যমান রেকর্ডগুলোকে আপ-টু-ডেট করার ক্ষমতা থেকে উপকৃত হয়। সার্ভিং প্রিকম্পিউট করা রেকর্ড, ওয়ার্ম ক্যাশ এবং ন্যূনতম কুয়েরি-সময়ের কাজ সহ দ্রুত ব্যাচড রিড থেকে উপকৃত হয়। দুটির মধ্যে নিবিড় সংযোগের কারণে রিকভারির কাজ এবং বড় আপডেটগুলো লেটেন্সি-সংবেদনশীল রিডের সাথে প্রতিযোগিতা করতে পারে।

যেখানে ম্যানেজড ডাটাবেস ব্যর্থ হয়

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

প্রথমত, ব্যবহার-ভিত্তিক মূল্য নির্ধারণ পড়া বা লেখা প্রতিটি বাইটের জন্য চার্জ করে। একটি একক সার্চ API অনুরোধে ১০০-১২০টি কি থাকে যা আমাদের ফেচ করতে হবে এমন পেজগুলোর সাথে সম্পর্কিত। ডেটা রিট্রিভাল প্রক্রিয়াটি একটি অনুরোধকে প্রায় ৫০ KB গড় আইটেম সাইজসহ ১০-২০টি পেজ কি-এর ছোট ব্যাচে বিভক্ত করে। বারবার সেই রেকর্ডগুলো পড়া উল্লেখযোগ্য ক্যাপাসিটি ব্যবহার করে, অন্যদিকে অবিচ্ছিন্ন ক্রল এবং চাঙ্কিং বা এম্বেডিং মডেলে পরিবর্তনগুলো আরও রাইট তৈরি করে। অর্থনীতি কেবল API কলের সংখ্যার ওপর নয়, বরং রেকর্ডের আকার এবং ফ্রিকোয়েন্সির ওপরও নির্ভর করে।

দ্বিতীয়ত, ম্যানেজড পরিষেবাটিতে পারফরম্যান্স টিউনিংয়ের জন্য আমাদের প্রয়োজনীয় নমনীয়তার অভাব রয়েছে। আমাদের প্রয়োজনীয় অপারেশনটি সংকীর্ণ ছিল: পেজ আইডেন্টিফায়ারের একটি ব্যাচ দেওয়া হলে, তাদের প্রস্তুত কন্টেন্ট দ্রুত ফেরত দিন। কোন মেশিনে পার্টিশন রয়েছে, এর ক্যাশের জন্য কত মেমরি বরাদ্দ করা হয়েছে এবং কোন রেপ্লিগা একটি অনুরোধ হ্যান্ডেল করেছে তার ওপর আমাদের নিয়ন্ত্রণ দরকার ছিল। সেই নিয়ন্ত্রণগুলো গুরুত্বপূর্ণ কারণ একটি আনক্যাশড রিড, একটি ক্রস-জোন হপ বা একটি ধীরগতির রেপ্লিগা পুরো ব্যাচকে দেরি করাতে পারে। DynamoDB API-এর পিছনে নিজস্ব স্টোরেজ এবং রেপ্লিগা আচরণ পরিচালনা করে। আমরা পরিষেবাটি কনফিগার করতে পেরেছিলাম, তবে আমরা আমাদের ওয়ার্কলোডের চারপাশে এর অভ্যন্তরীণ প্লেসমেন্ট, স্টোরেজ-ইঞ্জিন ক্যাশ বা রেপ্লিগা-নির্বাচন নীতি টিউন করতে পারিনি।

তৃতীয়ত, প্রসেসিং সরাসরি হট-স্টোর রাইটের সাথে যুক্ত ছিল। আমাদের পূর্ববর্তী প্রসেসিং পাইপলাইন প্রতিটি প্রস্তুত পেজ সরাসরি DynamoDB-তে লিখেছিল। তাই একটি বড় পুনঃপ্রসেসিং কাজ পৃথক হট-স্টোর আপডেটের তরঙ্গে পরিণত হয়েছিল, এবং প্রসেসিংকে হট স্টোরের থ্রুপুট সীমা এবং রিট্রাই আচরণের সাথে মানিয়ে নিতে হয়েছিল। নতুন চাঙ্কিং পদ্ধতি চেষ্টা করার, আমাদের এম্বেডিং মডেল পরিবর্তন করার বা একটি নতুন ফিল্ড যোগ করার জন্য আমরা ১-2 দিনের মধ্যে পুরো ডাটাবেস জুড়ে MapReduce চালাতে পারিনি। সংরক্ষিত পেজ আপডেটের কোনো স্বাধীন স্ট্রিম ছিল না যা একটি পৃথক পরিষেবা নিজস্ব গতিতে ব্যাচ করে হট স্টোরে পৌঁছে দিতে পারে।

এই সীমাবদ্ধতাগুলো সমাধান করার জন্য কেবল ডাটাবেস প্রতিস্থাপন করার চেয়ে বেশি কিছু প্রয়োজন ছিল। আমাদের টেকসই ডকুমেন্ট স্টেট এবং আপডেট ডেলিভারিকে কুয়েরি-সময়ের স্টোরেজ থেকে আলাদা করতে হয়েছিল, তারপরে দ্রুত ব্যাচ করা রিডের জন্য হট স্টোরকে বিশেষভাবে অপ্টিমাইজ করতে হয়েছিল।

আলাদা ডকুমেন্ট স্টেট, আপডেট ডেলিভারি এবং সার্ভিং

নতুন আর্কিটেকচার প্রতিটি দায়িত্ব একটি ভিন্ন উপাদানের কাছে অর্পণ করে। Pillar একটি টেকসই ডকুমেন্ট স্টেট বজায় রাখে এবং কী প্রকাশ করতে হবে তা নির্ধারণ করে। Lorry সেই এক্সপোর্টগুলোকে পার্টিশন করা ব্যাচে পরিণত করে। CobbleDB ব্যাচগুলো ইনজেস্ট করে এবং পেজ কি দ্বারা প্রিপেড রেকর্ড পরিবেশন করে।

বড় করুন

CobbleDB: টিউনযোগ্য রিড পাথ

CobbleDB হলো কুয়েরি করার সময় প্রস্তুত রেকর্ড পরিবেশন করার জন্য অপ্টিমাইজ করা আমাদের হট স্টোর। এটি একটি বিতরণ করা কি-ভ্যালু স্টোর: কি হলো পেজ আইডেন্টিফায়ার (হ্যাশ করা URL), এবং ভ্যালু হলো পেজের প্রসেস করা উপস্থাপনা (তাদের প্রি-চাঙ্ক করা প্যাসেজ এবং প্রতি-চাঙ্ক ভেক্টর এম্বেডিং)।

গুরুত্বপূর্ণ পরিবর্তন হলো স্টোরেজ কনফিগারেশনের উপর আমাদের নিয়ন্ত্রণ।

ডেটা পার্টিশন করা হয় এবং ডেটা নোড জুড়ে বিভক্ত করা হয়। এই বিতরণ করা ফরম্যাটটি নিশ্চিত করে যে প্রসেস করা পেজের একটি বিশাল কর্পাসকে মানিয়ে নিতে ডাটাবেসটি অনুভূমিকভাবে স্কেল করতে পারে। প্রতিটি পার্টিশনের তিনটি ভিন্ন নোডে তিনটি রেপ্লিগা থাকে; যদি একটি অনুলিপি অনুপলব্ধ হয়ে যায়, তবে অন্যগুলো রিড পরিবেশন করা চালিয়ে যেতে পারে।

প্রতিটি ডেটা নোডকে পার্টিশনগুলোর একটি সাবসেট বরাদ্দ করা হয়। নোডটি RocksDB ব্যবহার করে তার ডেটা সংরক্ষণ করে, যা ব্যাচ ইনজেশন দ্বারা চালিত রিড-হেভি ওয়ার্কলোডের জন্য অত্যন্ত উপযুক্ত একটি ওপেন-সোর্স এমবেডেড কি-ভ্যালু স্টোরেজ ইঞ্জিন।

ক্যাশ করা ডেটা মেমরি থেকে পরিবেশন করা যেতে পারে, অন্যদিকে আনক্যাশ করা রিডগুলো স্থানীয় NVMe স্টোরেজ ব্যবহার করে। এটি আমাদের একটি ম্যানেজড পরিষেবার অভ্যন্তরীণ ক্যাশ নীতি গ্রহণ করার পরিবর্তে পর্যবেক্ষিত ওয়ার্কলোডের জন্য মেমরি-টু-ডিস্ক ভারসাম্য টিউন করার একটি সরাসরি উপায় দেয়।

একটি স্টেটলেস কুয়েরি রাউটার কি-গুলোকে পার্টিশনে হ্যাশ করে এবং সমান্তরালভাবে নোডগুলোতে অনুরোধ রাউট করে। আর্কিটেকচারে একটি PostgreSQL-সমর্থিত মেটাডেটা পরিষেবা এবং টেকসই অবজেক্ট স্টোরেজও অন্তর্ভুক্ত রয়েছে।

এই ডিজাইনটি আমাদের ওয়ার্কলোডের রিড প্যাটার্নগুলোকে সমর্থন করে। প্রাসঙ্গিক পেজগুলোর একটি ক্যান্ডিডেট সেট পাওয়ার জন্য একটি কুয়েরি রিট্রিভাল এবং র‍্যাঙ্কিংয়ের মধ্য দিয়ে যাওয়ার পরে, হট স্টোরে সেই পেজগুলোর কন্টেন্টের জন্য বাল্ক কুয়েরি করা হয়। এই রিড অনুরোধগুলো রাউটারে পৌঁছায় এবং একটি সংশ্লিষ্ট ডেটা নোডে রাউট করা হয়। রাউটারটি ক্রস-জোন লেটেন্সি কমাতে সম্ভব হলে একই অ্যাভেইলবিলিটি জোনের একটি নোডে অনুরোধ পাঠানোর ক্ষেত্রে অগ্রাধিকার দেয়। প্রতিটি ডেটা নোড MultiGet ব্যবহার করে পেজ কন্টেন্ট ফেচ করতে পারে, যা কম লেটেন্সিতে একযোগে একাধিক কি ফেচ করার জন্য ডিজাইন করা একটি RocksDB ব্যাচ-রিড API। যদি কোনো নোডের প্রতিক্রিয়া জানাতে দেরি হয়, তবে সিস্টেমটি অন্য একটি নোডে থাকা অন্য পার্টিশন রেপ্লিগাতেও কুয়েরি করতে পারে, যা টেল লেটেন্সির উন্নতি করে।

আমাদের ওয়ার্কফ্লোর প্রয়োজন হয় না এমন সাধারণ বৈশিষ্ট্যগুলো প্রয়োগ করা থেকেও আমরা বিরত থাকতে পারি। উদাহরণস্বরূপ, বেশিরভাগ ডাটাবেস ধারাবাহিকতার নিশ্চয়তা এবং ট্রানজ্যাকশন সমর্থন অফার করে, কিন্তু আমাদের হট স্টোরের ট্রানজ্যাকশন বা সিঙ্ক্রোনাইজ করা রেপ্লিগার প্রয়োজন হয় না। একটি ডকুমেন্ট লেখার সময় এবং রিডের জন্য এটি উপলব্ধ হওয়ার সময়ের মধ্যে একটি সংক্ষিপ্ত ব্যবধান থাকা গ্রহণযোগ্য, এবং একটি রেপ্লিগা অন্যটির চেয়ে দ্রুত ডেটা ইনজেস্ট করাও ঠিক আছে। আমাদের প্রয়োজন নেই এমন বৈশিষ্ট্য বাদ দেওয়া আমাদের সিস্টেমের ওভারহেড এবং খরচ কমায়।

বড় করুন

পিলার এবং লরি: টেকসই রাইট পাথ

একটি পৃথক স্টোরেজ লেয়ার আমরা যা ক্রল এবং প্রসেস করি তার ট্র্যাক রাখে, আপডেটগুলোকে সংস্করণযুক্ত নথির স্টেটে একত্রিত করে এবং প্রয়োজনীয় উপস্থাপনাগুলো CobbleDB এবং সার্চ ইনডেক্সে প্রকাশ করে। আমরা এই উদ্দেশ্যে আমাদের ডকুমেন্ট স্টেট এবং পাবলিশিং লেয়ার পিলার (Pillar) তৈরি করেছি।

Pillar YTsaurus দ্বারা সমর্থিত। এটি পৃথক YTsaurus টেবিল ফ্যামিলিতে পেজ উপাদানগুলো (যেমন মেটাডেটা, চাঙ্ক এবং এম্বেডিং) সংরক্ষণ করে। এটি চাঙ্ক এবং এম্বেডিংয়ের সংস্করণগুলোও ট্র্যাক করে, যা একাধিক উপস্থাপনাকে একে অপরকে ওভাররাইট না করে সহাবস্থান করতে দেয় যাতে অন্তর্নিহিত মডেলগুলো পরিবর্তন হতে পারে। যেহেতু Pillar এবং YTsaurus সস্তা HDD স্টোরেজ ব্যবহার করে, তাই আমরা DynamoDB-তে পূর্বে সংরক্ষিত ডকুমেন্টের তুলনায় অনেক বেশি ডকুমেন্ট সংরক্ষণ করতে পারি।

Pillar সাবসেট ট্র্যাক করে, বা নীতি-সংজ্ঞায়িত পেজগুলোর গ্রুপ যেমন তাজা পেজ বা উচ্চ-মূল্যের পেজ। সাবসেটের সদস্যপদ নির্ধারণ করে কোন আপডেটগুলোকে CobbleDB-এর মতো ডাউনস্ট্রিম উপাদানগুলোতে পাস করতে হবে। CobbleDB আরও ব্যয়বহুল NVMe স্টোরেজ ব্যবহার করে, তাই আমরা শুধুমাত্র সেই ডকুমেন্টগুলো এক্সপোর্ট করি যা আমরা আসলে সার্চ ফলাফলে ব্যবহার করতে চাই। যখন কোনো পেজের কন্টেন্ট আপডেট করা হয়, বা যদি এটি কোনো সাবসেট থেকে যোগ বা সরানো হয়, তখন সংশ্লিষ্ট এক্সপোর্ট কাজ কিউ করার দায়িত্ব Pillar-এর।

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

CobbleDB প্রত্যাশা করে যে আপডেটগুলো পার্টিশন অনুযায়ী ব্যাচ করা হবে। Pillar এক্সপোর্টগুলোকে Lorry নামক একটি স্টেটলেস সার্ভিসের মাধ্যমে এই ফরম্যাটে রূপান্তরিত করা হয়। এর একমাত্র কাজ হলো একটি পার্সিস্টেন্ট পার্টিশন-অ্যালাইন্ড কিউ থেকে এক্সপোর্ট রেকর্ড পড়া, সেগুলোকে প্রতি-পার্টিশন ব্যাচ ফাইলে জমা করা এবং CobbleDB-তে হস্তান্তর করা।

Lorry এবং Cobble-এর মধ্যে, একটি অতিরিক্ত প্রোটোকল ডেটা প্লেনকে (S3) কন্ট্রোল প্লেন থেকে আলাদা করে। Lorry একটি অনন্য শনাক্তন্দkar-এর অধীনে S3-এ ব্যাচ লেখে এবং Cobble-এর মধ্যে ব্যাচ রেজিস্টার করে। Cobble পার্টিশন রেপ্লিগাগুলো ইনজেস্ট করার জন্য পরবর্তী S3 ব্যাচ স্বাধীনভাবে ব্যাচ বা কন্ট্রোল প্লেন API-তে কুয়েরি করে এবং কালানুক্রমিক ক্রমে অসমক্রোনাসভাবে ব্যাচ আপডেট প্রয়োগ করে। এর অর্থ হলো একটি ধীরগতির বা রিকভার হতে থাকা নোড পুরো সিস্টেমকে ধীর করে না দিয়ে নিজস্ব গতিতে ক্যাচ আপ করতে পারে।

বড় করুন

নতুন পাথ তাৎক্ষণিক প্রসেসিং ট্রানজ্যাকশনকে হট-স্টোর ইনজেশন থেকে আলাদা করে এবং ক্রমবর্ধমান আপডেট ও বাল্ক রিবিল্ডের জন্য একটি রিপ্লেযোগ্য পাথ প্রদান করে। এই শ্রম বিভাজন নিশ্চিত করে যে টেকসই ডকুমেন্ট স্টেটের আপডেটগুলো রিড পথ লেটেন্সিতে ব্যাঘাত ঘটায় না।

ভ্যালিডেশন

৫গুণ দ্রুত

হট স্টোর মাইগ্রেট করার পরে, মাঝারি ব্যাচ-রিড লেটেন্সি ৩১.৪ মিলিসেকেন্ড থেকে কমে ৫.৬০ মিলিসেকেন্ড হয়েছে। p90 ৫৬.৭ মিলিসেকেন্ড থেকে কমে ৯.৭৭ মিলিসেকেন্ড হয়েছে, এবং p99 ১২৩ মিলিসেকেন্ড থেকে কমে ২৪.২ মিলিসেকেন্ড হয়েছে। অনুপাতগুলো ৫.০৮× থেকে ৫.৮০× পর্যন্ত হয়ে থাকে, যেখানে সাধারণ অনুরোধ এবং টেল উভয় ক্ষেত্রেই উন্নতি দেখা গেছে।

বড় করুন

এই নম্বরগুলো ব্যাচড রিড থেকে উদ্ভূত, যেখানে প্রতিটি কুয়েরি প্রায় ১০-১৫টি কি অনুরোধ করে। গড় পেলোড আইটেমের আকার হলো 50KB। প্রায় 200k rps-এ উভয় সিস্টেমে কুয়েরি করা হয়েছিল, যদিও আমরা কোনো ডিগ্রেডেশন ছাড়াই 500k rps পর্যন্ত লোড টেস্ট চালিয়েছি।

CobbleDB-এর অবদানকে আলাদা করার জন্য, সেটআপের অন্যান্য সমস্ত দিক অপরিবর্তিত রাখা হয়েছিল। যাইহোক, এটি এখনও একটি পর্যবেক্ষণমূলক তুলনামূলক বিশ্লেষণ; সিস্টেমগুলো নিয়ন্ত্রিত অবস্থার অধীনে একই অনুরোধের পরিবর্তে বিভিন্ন সময়ে লাইভ প্রোডাকশন ট্রাফিক পরিবেশন করেছে। তাই আমরা একটি সিন্থেটিক বেঞ্চমার্কেও উভয় সিস্টেমের কার্যক্ষমতা পরিমাপ করেছি। প্রোডাকশনে দেখা অনুরোধগুলোর সাথে মিল রাখতে, আমরা ১০-১৫টি কি (key) এবং ১০০B থেকে ১০০ KiB পর্যন্ত ভ্যালুর ব্যাচ দিয়ে উভয় সিস্টেমে কুয়েরি করেছি।

বড় করুন

DynamoDB এই পরিস্থিতিতে সংগ্রাম করে কারণ এর ম্যানেজড রিড পাথ এই আকারের ব্যাচড রিডের জন্য টিউন করা যায় না। বিপরীতে, CobbleDB ঠিক এই সেটিংটির জন্য অপ্টিমাইজ করা হয়েছে, যেহেতু আমরা প্লেসমেন্ট, ক্যাশিং এবং রেপ্লিগা নিয়ন্ত্রণগুলো পরিচালনা করি। এটি পার্টিশন দ্বারা কি-গুলোকে গ্রুপ করে, পার্টিশন রেপ্লিগার বিরুদ্ধে সমান্তরালভাবে রিড এক্সিকিউট করে এবং অন্যান্য রেপ্লিগার বিরুদ্ধে ধীরগতির রিডগুলোকে হেজ করতে পারে। আমাদের ফলাফলগুলো প্রদর্শন করে যে এই ডিজাইন পছন্দগুলো প্রোডাকশন পরিবেশে দ্রুত রিডে রূপান্তরিত হয়।

২০% সস্তা

CobbleDB ও DynamoDB-এর তুলনায় উল্লেখযোগ্যভাবে সস্তা। স্টোরেজ ছাড়াও, DynamoDB পড়া বা লেখা প্রতিটি বাইটের জন্যও চার্জ করে। আমাদের কর্পাস এবং সার্ভিং ট্রাফিকের স্কেলে, এই ব্যবহার-ভিত্তিক চার্জগুলো মোট খরচের একটি উল্লেখযোগ্য অংশ হয়ে দাঁড়ায়। ক্রমাগত আপডেটগুলো রাইট ক্যাপাসিটি ব্যবহার করে, অন্যদিকে কুয়েরির জন্য ফেচ করা প্রিপেড পেজের প্রতিটি ব্যাচ রিড ক্যাপাসিটি ব্যবহার করে।

আমরা স্টোরেজ সাইজ, রাইট ক্যাপাসিটি ইউনিট এবং রিড ক্যাপাসিটি ইউনিটের অভ্যন্তরীণ অনুমানের ভিত্তিতে খরচ সাশ্রয় গণনা করেছি। প্রতিটি কমিটমেন্ট টিয়ারে, CobbleDB DynamoDB-এর তুলনায় অন্তত ২০% সস্তা। প্রকৃত সাশ্রয় সম্ভবত আরও বেশি, কারণ এই ফলাফলগুলো কম্প্রেশন থেকে সম্ভাব্য ব্যাকআপ সাশ্রয়কে বিবেচনায় নেয় না।

এআই এজেন্টদের একটি দল কীভাবে এটি তৈরি করতে আমাদের সাহায্য করেছিল

CobbleDB এবং এর চারপাশের অবকাঠামো তৈরি করা সহজ ছিল না। শুধুমাত্র CobbleDB-এর মূল ডাটাবেসই প্রায় ৪০,০০০ লাইন Rust কোডের, এবং প্রোডাকশন স্কেলে সঠিকতা এবং ফেইলিওর আচরণ যাচাই করার জন্য, প্রসেসিং এবং সার্ভিং উভয় পাথের সাথেই CobbleDB সংহত করার জন্য, এবং নিরাপদে লাইভ ট্রাফিক রূপান্তর করার জন্য মাইগ্রেশনের ক্ষেত্রেও প্রচুর কাজের প্রয়োজন হয়েছিল।

কোডিং এজেন্টদের একটি স্বর্ম পরিচালনা করে এমন একটি অভ্যন্তরীণ সিস্টেম ব্যবহার করে আমরা এই প্রচেষ্টাকে ত্বরান্বিত করেছি। সিস্টেমটি অত্যন্ত টেকসই হওয়ার জন্য ডিজাইন করা হয়েছে; এটি সেশন জুড়ে প্রজেক্টের লক্ষ্য, সক্রিয় ঝুঁকি, রিপোজিটরি ইতিহাস এবং পূর্ববর্তী সিদ্ধান্তগুলো ধরে রাখে।

আমরা CobbleDB প্রজেক্টে এই ধরনের সক্রিয়, সর্বদা সচল এজেন্টদের একটি দল নিয়োজিত করেছি। তাদের প্রথম কাজ ছিল ইতিমধ্যেই চলমান কাজের একটি সঠিক মডেল তৈরি করা। তারা প্রজেক্টের চ্যানেল এবং সক্রিয় থ্রেডগুলো অডিট করেছে, বকেয়া আইটেমগুলোকে তাদের pull request এবং ওনারদের সাথে যুক্ত করেছে, এবং সিস্টেমের স্বাস্থ্য ও পরবর্তী পদক্ষেপগুলোর একটি বর্তমান রিডআউট তৈরি করেছে। সেখান থেকে, তারা ইঞ্জিনিয়ারিং লুপের বেশ কয়েকটি অংশে কাজ করেছে:

• কোড এবং অবকাঠামোর পরিবর্তনগুলো পর্যালোচনা করা হয়েছে।
• যে সমস্যাগুলো সহজে চোখ এড়িয়ে যেত সেগুলোকে চিহ্নিত করা হয়েছে, যার মধ্যে রয়েছে অনিরাপদ রিস্টোর অনুমান, পুরোনো বিল্ড রেফারেন্স এবং এমন কনফিগারেশন যা রানটাইমে ব্যর্থ হতো।
• নির্ধারিত ফোকাসড ফিক্স, টেস্ট, মনিটরিং পরিবর্তন এবং অপারেশনাল ডকুমেন্টেশন প্রস্তুত করা হয়েছে।
• প্রোডাকশন অ্যাকশনগুলোকে স্পষ্টভাবে মানব-নিয়ন্ত্রিত রেখে CI, রিভিউ এবং অবকাঠামো গেটগুলো ট্র্যাক করা হয়েছে।
• মনিটরিং করা রোলআউট এবং ব্যাকআপ বা রিস্টোর এক্সারসাইজগুলো করা হয়েছে, এরপর রোলআউটের সফলতার মানদণ্ডের সাথে পর্যবেক্ষিত সিস্টেম স্টেট তুলনা করা হয়েছে।
• প্রজেক্টের রিডআউটগুলো মেইনটেইন করা হয়েছে যাতে ইঞ্জিনিয়াররা দেখতে পারেন কী শিপ করা হয়েছে, কী ব্লকড রয়েছে এবং কোথায় মানুষের বিচারবুদ্ধি এখনও প্রয়োজন।

ইঞ্জিনিয়াররা এখনও আর্কিটেকচার সেট করেন, তাৎপর্যপূর্ণ পরিবর্তনগুলো পর্যালোচনা করেন এবং প্রোডাকশন অপারেশন অনুমোদন করেন। এজেন্টরা সেই সিদ্ধান্তগুলোর মধ্যে অবিচ্ছিন্ন পরিদর্শন এবং ফলো-থ্রু-এর বেশিরভাগ অংশ পরিচালনা করে। এটি একটি ছোট টিমকে দক্ষতার সাথে প্রজেক্টটি পরিচালনা করতে সাহায্য করেছে—মূল CobbleDB অবকাঠামোটি দুই মাসের মধ্যে দুই জন মানব ইঞ্জিনিয়ার এবং শত শত এআই এজেন্ট দ্বারা তৈরি করা হয়েছিল।

উপসংহার

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

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

আমরা শীঘ্রই CobbleDB ওপেন-সোর্স করার পরিকল্পনা করছি, যাতে এআই-নেটিভ সার্চ সিস্টেম তৈরি করা অন্যান্য টিমগুলো আমাদের পণ্যের অভ্যন্তরে সার্চকে দ্রুততর এবং সাশ্রয়ী করে তোলে এমন একই স্টোরেজ লেয়ার থেকে উপকৃত হতে পারে।

উদ্ধৃতি

@online{perplexity2026Cobbledb,
  author = {{Perplexity} and Alexandr Yarats and Marco Montagna and Aleksei Bykov and Alexey Gusev and Ali Abdullaev and Amir Mokhammed-Ali and Andrey Zosimov and Denis Kremko and Gleb Vishnevsky and Micah Zirn and Phi Hoang and Claire Beamer and Jeremy Yang and Jerry Ma and Denis Yarats},
  title = {{CobbleDB: Rebuilding AI search storage for lower latency and cost}},
  date = {2026-09-14},
  url = {https://www.perplexity.ai/hub/blog/cobbledb}
}