وقتی ایندکس جستجو روی S3 قرار می‌گیرد: معماری و بهینه‌سازی‌های موتور بازیابی Infino — What changes when your search index lives on S3?
خلاصه
مقاله فنی Infino بررسی می‌کند که چگونه انتقال ایندکس‌های جستجو به ذخیره‌سازی ابری مثل S3، مدل هزینه‌کرد و بهینه‌سازی را تغییر می‌دهد. چالش اصلی در این معماری کاهش تعداد رفت‌وبرگشت‌های شبکه (GET requests) است و راهکارهایی مانند استفاده از مانیفست‌ها، ایندکس اصطلاحات و کَش‌کردن محلی برای غلبه بر این تاخیرها ارائه شده است.
مقدمه و زمینه
بسیاری از موتورهای جستجوی سنتی مانند Lucene فرض را بر این می‌گذارند که ایندکس روی دیسک محلی و در کنار پردازنده قرار دارد؛ جایی که خواندن تصادفی داده‌ها (Random Read) بسیار ارزان است. اما وقتی ایندکس را به Object Storage مثل S3، GCS یا Azure Blob Storage منتقل می‌کنید، شرایط کاملاً تغییر می‌کند. در فضای ابری، هر خواندن تصادفی یک درخواست HTTP GET است که ده‌ها میلی‌ثانیه طول می‌کشد و صرف‌نظر از حجم بایت‌های دریافتی، هزینه دلاری به همراه دارد.
تیم Infino در حال ساخت یک موتور بازیابی مقیاس‌پذیر برای پاسخ به پرسش‌های ایجنت‌ها است که از SQL، جستجوی برداری و جستجوی تمام‌متن با BM25 پشتیبانی می‌کند. چون داده‌ها از پیش در Object Storage قرار دارند، آن‌ها تصمیم گرفتند ایندکس جستجو را نیز مستقیماً روی همین بستر بسازند. این مقاله نگاهی به چالش‌ها و تصمیمات معماری آن‌ها برای بهینه‌سازی این رویکرد دارد.
معماری و ساختار داده
برای کاهش تعداد درخواست‌های شبکه، Infino ساختار داده‌ای خود را به شکل متفاوتی سازمان‌دهی کرده است:
- سوپرفایل (Superfile): برخلاف Lucene که هر سگمنت از فایل‌های متعددی تشکیل شده است، هر واحد ایندکس در Infino یک فایل Parquet منفرد است. اسناد به صورت ردیف‌گروه ذخیره شده و ایندکس‌های تمام‌متن و برداری پیش از فوتر فایل قرار می‌گیرند. این یعنی هر بخش از فایل با یک درخواست
Range GETقابل دریافت است. - مانیفست (Manifest): هر جدول بزرگ یا Supertable دارای یک مانیفست است که لیست سوپرفایل‌ها، فوترها، هدرهای ایندکس و آمارهای ستونی را نگه می‌دارد. با کَش کردن مانیفست، باز کردن یک سوپرفایل نیازی به هیچ درخواست GET اولیه‌ای ندارد.
- ایندکس اصطلاحات (Term Index): برای جلوگیری از بررسی تک‌تک سوپرفایل‌ها، ایندکس اصطلاحات مشخص می‌کند که هر واژه در چه سوپرفایل‌هایی وجود دارد و حداکثر امتیاز BM25 آن چقدر است. این کار به موتور اجازه می‌دهد سوپرفایل‌های نامربوط را بدون باز کردن کنار بگذارد.
بهینه‌سازی و مدل هزینه
در این معماری، کمیاب‌ترین منبع نه CPU است و نه پهنای باند بایت‌ها، بلکه تعداد رفت‌وبرگشت‌ها (Round Trips) به فضای ابری است. ایده‌های کلیدی برای کنترل این هزینه شامل موارد زیر است:
- خواندن تنبل (Lazy Read): پرس‌وجوها فقط بایت‌های مورد نیاز (مثل لیست پستینگ یک واژه خاص) را به صورت بازهه‌ای دریافت می‌کنند و از خواندن کل فایل پرهیز می‌شود.
- دسته‌بندی درخواست‌ها: اگر چند واژه نزدیک به هم در فایل نیاز باشد، درخواست‌ها در صورتی که فاصله کمی داشته باشند (تا ۶۴ کیلوبایت) در یک درخواست واحد ترکیب می‌شوند.
- کَش دیسک و حافظه: پس از اولین مراجعه، سوپرفایل در پس‌زمینه روی دیسک محلی دانلود و Memory-Mapped می‌شود. پرس‌وجوهای بعدی بدون هیچ‌گونه درخواست GET به Object Storage و با سرعت بالا از حافظه خوانده می‌شوند.
دیدگاه جامعه مهندسی (Hacker News)
در بحث‌های کاربران Hacker News، این معماری با الگوهای مشابهی مانند Searchable Snapshots در Elasticsearch و ابزارهایی مثل turbopuffer مقایسه شد. برخی مهندسان اشاره کردند که جداسازی محاسبه و ذخیره‌سازی (Separation of Compute and Storage) یک الگوی قدرتمند و اقتصادی قدیمی است، هرچند عده‌ای نیز درباره ضرورت قرار دادن ایندکس جستجو روی فضای ابری با تاخیر بالا بحث داشتند. با این وجود، تلاش‌های مهندسی برای دور زدن محدودیت‌های تاخیر شبکه و ساخت یک موتور کارآمد روی چنین زیرساختی تحسین شد.
چرا برای مهندسان اهمیت دارد؟
برای طراحان سیستم و توسعه‌دهندگان بک‌اند، این مقاله نشان می‌دهد که چگونه می‌توان با تغییر مدل ذهنی از «دیسک محلی» به «فضای ابری»، سیستم‌هایی با معماری متکی بر حذف درخواست‌های اضافی شبکه ساخت. درک تکنیک‌هایی نظیر تعبیه متادیتای مانیفست، استفاده بهینه از فایل‌های Parquet و کَش‌سازی لایه‌ای می‌تواند الهام‌بخش ساخت سیستم‌های مقیاس‌پذیر مدرن باشد.
این مطلب به‌صورت کاملاً خودکار و با هوش مصنوعی از مقالهٔ اصلی و بحث هکرنیوز تهیه شده و ممکن است خطا داشته باشد. حقوق مطلب اصلی متعلق به نویسندهٔ آن است. قوانین و گزارش مشکل