LanceDB, pgvector-এর তুলনায় ২২ গুণ দ্রুত ১০০k OpenAI এমবেডিং লোড করেছে, অন্যদিকে আটটি সমান্তরাল ক্লায়েন্টের একই ওয়ার্কলোড হ্যান্ডেল করার ক্ষেত্রে pgvector ১.৮ গুণ দ্রুততর ছিল। সিঙ্গেল-থ্রেড ল্যাটেন্সি এবং স্টোরেজ দক্ষতার ক্ষেত্রেও ব্যবধানটি LanceDB-এর পক্ষে ছিল, যা ডেভেলপারদের একটি ডেটা-চালিত উপায়ে ভেক্টর স্টোর বেছে নেওয়ার সুযোগ করে দেয়।
কেন এখন একটি বেঞ্চমার্ক গুরুত্বপূর্ণ
ভেক্টর সার্চ এখন রিসার্চ ল্যাব থেকে রেকমেন্ডেশন ইঞ্জিন এবং রিট্রিভাল-অগমেন্টেড জেনারেশন (RAG)-এর মতো প্রোডাকশন সার্ভিসে চলে এসেছে। বেশিরভাগ টিম ইতিমধ্যেই PostgreSQL ব্যবহার করছে, তাই pgvector এক্সটেনশনটি নতুন কোনো ইনফ্রাস্ট্রাকচার ছাড়াই সিমিলারিটি সার্চের সুবিধা দেয়। তবে, LanceDB-এর মতো ডেডিকেটেড স্টোরগুলো কম ল্যাটেন্সি এবং সস্তা স্টোরেজের দাবি করে। ডেটাসেট বড় হওয়ার সাথে সাথে এবং রিকোয়েস্ট রেট বাড়ার সাথে সাথে খরচ ও পারফরম্যান্সের ওপর প্রভাব ফেলে এমন একটি সিদ্ধান্ত নিতে টিমগুলোকে "আমাদের যা আছে তার সাথে এটি যোগ করা" এবং "একটি নির্দিষ্ট কাজের জন্য তৈরি ইঞ্জিন চালানো"-র মধ্যে একটি বেছে নিতে হয়।
পরীক্ষাটি কীভাবে সাজানো হয়েছিল
উভয় সিস্টেমই OpenAI-এর এমবেডিং মডেল দ্বারা তৈরি প্রতিটি ১৫৩৬ ডাইমেনশনের একই ১০০k ভেক্টর ইনডেক্স করেছে। আমরা ইনজেশন স্পিড, ডিস্ক ব্যবহার, সিঙ্গেল-থ্রেড কুয়েরি ল্যাটেন্সি এবং আটটি কনকারেন্ট ক্লায়েন্টের থ্রুপুট পরিমাপ করেছি।
মুখোমুখি ফলাফল
- Ingestion speed – LanceDB ২২ গুণ সুবিধা দেখিয়েছে।
- Disk footprint – LanceDB ভেক্টরগুলোকে pgvector-এর ব্যবহৃত জায়গার প্রায় এক-তৃতীয়াংশ স্থানে সংরক্ষণ করেছে।
- Single-thread latency – LanceDB-তে কুয়েরি প্রায় দ্বিগুণ দ্রুত চলেছে।
- Concurrency scaling – আটটি প্যারালাল ক্লায়েন্টের সাথে, pgvector LanceDB-এর তুলনায় ১.৮ গুণ বেশি থ্রুপুট প্রদান করেছে।
পার্থক্যের স্থাপত্যগত কারণসমূহ
LanceDB হলো একটি এমবেডেড লাইব্রেরি যা অ্যাপ্লিকেশন হোস্ট করা Python প্রসেসের ভেতরে চলে। সমস্ত অপারেশন ইন-প্রসেস থাকে, তাই ডেটা কখনোই নেটওয়ার্ক বাউন্ডারি অতিক্রম করে না এবং ন্যূনতম ওভারহেড সহ ইনডেক্স আপডেট হয়। এই ডিজাইনটি সিঙ্গেল-টাস্ক ওয়ার্কলোডের জন্য চমৎকার, কিন্তু যখন একাধিক Python থ্রেড Global Interpreter Lock (GIL)-এর জন্য প্রতিযোগিতা করে, তখন এটি একটি সীমাবদ্ধতায় পড়ে, যা Python বাইটকোডের প্রকৃত প্যারালাল এক্সিকিউশনকে বাধা দেয়।
pgvector সার্ভার সাইডে PostgreSQL-কে বর্ধিত করে। প্রতিটি ক্লায়েন্ট কানেকশন একটি আলাদা সার্ভার প্রসেস চালু করে, যা সম্পূর্ণভাবে GIL-কে এড়িয়ে যায়। PostgreSQL প্ল্যানার সিদ্ধান্ত নেয় কীভাবে একটি সিমিলারিটি সার্চ সম্পন্ন করতে হবে, এবং সার্ভার কনকারেন্ট রিকোয়েস্টগুলি পরিষেবা দেওয়ার জন্য অনেকগুলো প্রসেস চালু করতে পারে। এই আইসোলেশন বা বিচ্ছিন্নতাই লোডের অধীনে উন্নত স্কেলিং নিশ্চিত করে।
ফিল্টারিং এবং কুয়েরি প্ল্যানিংয়ের বিশেষত্ব
বাস্তব জগতের RAG পাইপলাইনগুলো প্রায়শই ভেক্টর সিমিলারিটির সাথে প্রথাগত ফিল্টার (যেমন, WHERE user_id = 42) কম্বাইন করে। LanceDB একটি প্রি-ফিল্টার প্রয়োগ করে যা প্রতিটি রান-এ একইভাবে কাজ করে। pgvector PostgreSQL-এর কুয়েরি প্ল্যানারের ওপর নির্ভর করে, যা পরিসংখ্যানের (statistics) ওপর ভিত্তি করে একটি দ্রুত ইনডেক্স স্ক্যান বা একটি ধীরগতির এক্স্যাক্ট স্ক্যান বেছে নিতে পারে। একটি pgvector টেবিল বাল্ক লোড করার পরে ANALYZE চালানো সেই পরিসংখ্যানগুলোকে রিফ্রেশ করে; এটি না করলে রিকল (recall) প্রায় শূন্যে নেমে আসতে পারে, যা কার্যকরভাবে সার্চকে অকেজো করে দেয়।
কখন কোন বিকল্পটি বেছে নেবেন
pgvector বেছে নিন যদি
- আপনার স্ট্যাকে ইতিমধ্যেই PostgreSQL অন্তর্ভুক্ত থাকে এবং আপনি অন্য কোনো সার্ভিস যোগ করা এড়াতে চান।
- আপনি অনেক সমান্তরাল ব্যবহারকারী বা API কল আশা করেন।
- ACID গ্যারান্টি এবং পরিচিত DBA টুলস গুরুত্বপূর্ণ হয়।
LanceDB বেছে নিন যদি
- আপনার ওয়ার্কফ্লো একটি ML পাইপলাইন হয় যা ঘন ঘন নতুন এমবেডিং ইনজেস্ট করে।
- আপনার সিঙ্গেল-রিকোয়েস্ট এজেন্টের (যেমন, চ্যাট বট) জন্য দ্রুততম রাইট পাথ এবং কম ল্যাটেন্সি প্রয়োজন হয়।
- ডিস্ক খরচ একটি উদ্বেগের বিষয় হয় এবং আপনি সিঙ্গেল-থ্রেড পারফরম্যান্সের সীমাবদ্ধতা মেনে নিতে পারেন।
সারকথা: যদি ইনজেশন স্পিড, ন্যূনতম স্টোরেজ এবং সিঙ্গেল-রিকোয়েস্ট ল্যাটেন্সি সবচেয়ে বেশি গুরুত্বপূর্ণ হয়, তবে LanceDB বিজয়ী। আর যদি আপনাকে একসাথে অনেক ব্যবহারকারীকে পরিষেবা দিতে হয় এবং বিদ্যমান PostgreSQL ডিপ্লয়মেন্টের ওপর নির্ভর করতে হয়, তবে pgvector-এর কনকারেন্সি সুবিধা এটিকে একটি নিরাপদ পছন্দ করে তোলে। আপনার পণ্যের সবচেয়ে গুরুত্বপূর্ণ মেট্রিকের সাথে স্টোরটিকে সামঞ্জস্য করতে এই বেঞ্চমার্কের সংখ্যাগুলো ব্যবহার করুন।