LanceDB نے 100k OpenAI embeddings کو pgvector کے مقابلے میں 22 گنا تیزی سے لوڈ کیا، جبکہ pgvector نے آٹھ بیک وقت (simultaneous) کلائنٹس کے ایک ہی ورک لوڈ کا جواب 1.8 گنا زیادہ تیزی سے دیا۔ سنگل تھریڈ لیٹنسی (single-thread latency) اور اسٹوریج کی کارکردگی میں فرق بھی LanceDB کے حق میں رہا، جس سے ڈویلپرز کو ویکٹر اسٹور کے انتخاب کے لیے ڈیٹا پر مبنی طریقہ کار ملا۔
اب بینچ مارک کیوں اہم ہے
ویکٹر سرچ اب ریسرچ لیبز سے نکل کر پروڈکشن سروسز جیسے کہ ریکمنڈیشن انجن اور ریٹریول آگمینٹڈ جنریشن (RAG) تک پہنچ چکی ہے۔ زیادہ تر ٹیمیں پہلے ہی PostgreSQL استعمال کر رہی ہیں، اس لیے pgvector ایکسٹینشن نئی انفراسٹرکچر کے بغیر مماثلت سرچ (similarity search) کا وعدہ کرتی ہے۔ تاہم، LanceDB جیسے مخصوص اسٹورز کم لیٹنسی اور سستی اسٹوریج کا دعویٰ کرتے ہیں۔ ٹیموں کو "جو ہمارے پاس ہے اس میں اضافہ کریں" اور "ایک مقصد کے لیے بنایا گیا انجن چلائیں" کے درمیان انتخاب کرنا ہوتا ہے، یہ ایک ایسا فیصلہ ہے جو ڈیٹا سیٹس کے بڑھنے اور درخواستوں (requests) کی شرح میں اضافے کے ساتھ لاگت اور کارکردگی پر اثر انداز ہوتا ہے۔
ٹیسٹ کیسے ترتیب دیا گیا
دونوں سسٹمز نے OpenAI کے ایمبیڈنگ ماڈل کے ذریعے تیار کردہ ایک ہی 100k ویکٹرز کو انڈیکس کیا، جن میں سے ہر ایک کے 1536 ڈائمینشنز (dimensions) تھے۔ ہم نے انجیٹشن اسپیڈ (ingestion speed)، ڈسک کا استعمال، سنگل تھریڈ کوئری لیٹنسی اور آٹھ بیک وقت (concurrent) کلائنٹس کے ساتھ تھرو پٹ (throughput) کی پیمائش کی۔
آمنے سامنے کے نتائج
- Ingestion speed – LanceDB نے 22× برتری دکھائی۔
- Disk footprint – LanceDB نے ویکٹرز کو pgvector کے استعمال کردہ حصے کے تقریباً ایک تہائی حصے میں اسٹور کیا۔
- Single-thread latency – LanceDB پر کوئریز تقریباً دو گنا زیادہ تیزی سے چلیں۔
- Concurrency scaling – آٹھ متوازی (parallel) کلائنٹس کے ساتھ، pgvector نے LanceDB کے مقابلے میں 1.8× زیادہ تھرو پٹ فراہم کی۔
فرق کی بنیادی تعمیراتی وجوہات
LanceDB ایک ایمبیڈڈ لائبریری ہے جو اس Python پروسیس کے اندر چلتی ہے جو ایپلی کیشن کو ہوسٹ کرتا ہے۔ تمام آپریشنز ان-پروسیس (in-process) رہتے ہیں، اس لیے ڈیٹا کبھی بھی نیٹ ورک کی حد عبور نہیں کرتا اور انڈیکس کم سے کم اوور ہیڈ (overhead) کے ساتھ اپ ڈیٹ ہوتا ہے۔ یہ ڈیزائن سنگل ٹاسک ورک لوڈز کے لیے بہترین ہے لیکن اس وقت ایک حد (ceiling) تک پہنچ جاتا ہے جب متعدد Python تھریڈز Global Interpreter Lock (GIL) کے لیے مقابلہ کرتے ہیں، جو Python بائٹ کوڈ کے حقیقی متوازی (parallel) عمل کو روک دیتا ہے۔
pgvector سرور سائیڈ پر PostgreSQL کی توسیع کرتا ہے۔ ہر کلائنٹ کنکشن ایک الگ سرور پروسیس شروع کرتا ہے، جس سے GIL مکمل طور پر نظر انداز ہو جاتا ہے۔ PostgreSQL پلانر یہ فیصلہ کرتا ہے کہ مماثلت سرچ (similarity search) کو کیسے پورا کیا جائے، اور سرور بیک وقت درخواستوں کو پورا کرنے کے لیے کئی پروسیس شروع کر سکتا ہے۔ یہی علیحدگی (isolation) لوڈ کے تحت بہتر اسکیلنگ کی وضاحت کرتی ہے۔
فلٹرنگ اور کوئری پلاننگ کی پیچیدگیاں
حقیقی دنیا کے RAG پائپ لائنز اکثر ویکٹر مماثلت کو روایتی فلٹرز (مثلاً WHERE user_id = 42) کے ساتھ جوڑتے ہیں۔ LanceDB ایک پری فلٹر (prefilter) کا استعمال کرتا ہے جو تمام بار چلانے پر قابلِ پیش گوئی (predictable) رویہ رکھتا ہے۔ pgvector PostgreSQL کے کوئری پلانر پر انحصار کرتا ہے، جو اعداد و شمار (statistics) کی بنیاد پر یا تو تیز انڈیکس اسکین کا انتخاب کرتا ہے یا پھر سست ایکسیکٹ اسکین (exact scan) پر منتقل ہو جاتا ہے۔ pgvector ٹیبل میں بلک لوڈنگ کے بعد ANALYZE چلانے سے وہ اعداد و شمار تازہ ہو جاتے ہیں؛ اس کے بغیر، ریکال (recall) تقریباً صفر تک گر سکتا ہے، جو عملی طور پر سرچ کو ناکام بنا دیتا ہے۔
ہر آپشن کب موزوں ہے
pgvector کا انتخاب کریں اگر
- آپ کے اسٹیک میں پہلے سے ہی PostgreSQL شامل ہے اور آپ مزید کوئی سروس شامل کرنے سے بچنا چاہتے ہیں۔
- آپ بہت سے بیک وقت صارفین یا API کالز کی توقع رکھتے ہیں۔
- ACID گارنٹی اور جانی پہچانی DBA ٹولز اہمیت رکھتے ہوں۔
LanceDB کا انتخاب کریں اگر
- آپ کا ورک فلو ایک ML پائپ لائن ہے جو کثرت سے نئی ایمبیڈنگز کو انجیٹ (ingest) کرتی ہے۔
- آپ کو سنگل ریکوسٹ ایجنٹس (مثلاً چیٹ بوٹس) کے لیے تیز ترین رائٹ پاتھ اور کم لیٹنسی کی ضرورت ہے۔
- ڈسک کی لاگت ایک مسئلہ ہے اور آپ سنگل تھریڈ کارکردگی کی حد کو برداشت کر سکتے ہیں۔
خلاصہ: اگر خام انجیٹشن اسپیڈ، کم سے کم اسٹوریج، اور سنگل ریکوسٹ لیٹنسی سب سے زیادہ اہم ہے، تو LanceDB جیت جاتا ہے۔ اگر آپ کو ایک ہی وقت میں بہت سے صارفین کو سروس دینی ہے اور آپ موجودہ PostgreSQL ڈیپلائمنٹ پر انحصار کرتے ہیں، تو pgvector کا کنکرنسی (concurrency) کا فائدہ اسے ایک محفوظ انتخاب بناتا ہے۔ اپنے پروڈکٹ کے سب سے اہم میٹرک کے مطابق اسٹور کا انتخاب کرنے کے لیے اس بینچ مارک کے اعداد و شمار کا استعمال کریں۔
