بهینه‌سازی کوئری‌های COUNT و جستجو در پستگرس؛ نگاهی به تکنیک‌های ParadeDB — Solving Postgres' Count Problem
خلاصه
این مقاله بهینه‌سازی‌های فنی جدید ParadeDB را برای تسریع کوئری‌های COUNT و جستجوی متن کامل در پستگرس بررسی می‌کند. این تکنیک‌ها شامل پارتیشن‌بندی سگمنت‌ها، معکوس‌سازی نگاشت شناسه سند و استفاده از بیت‌مپ برای عبارات پرتکرار است که کارایی را به‌شدت افزایش می‌دهد.
تیم ParadeDB در ادامه تلاش‌های خود برای بهبود عملکرد جستجوی متن کامل و رتبه‌بندی BM25 در پستگرس (PostgreSQL)، این بار سراغ بهینه‌سازی کوئری‌های COUNT رفته است. هدف این پروژه ارائه یک جایگزین قدرتمند برای Elasticsearch درون خود دیتابیس پستگرس است.
پس‌زمینه و مشکل
در معماری‌های مشابه LSM-tree (مانند آنچه در TIN و خود ParadeDB استفاده می‌شود)، داده‌ها در سگمنت‌های تغییرناپذیر ذخیره می‌شوند. در کوئری‌های COUNT، بررسی اعتبار صفوف (Visibility Checking) سهم بزرگی از دسترسی به صفحات دیتابیس را به خود اختصاص می‌دهد؛ زیرا برای هر تطابق باید مقدار ctid (شناسه داخلی سطر در پستگرس) بازیابی شود. این فرآیند می‌تواند بسیار کند و هزینه‌بر باشد.
راهکارهای فنی و بهینه‌سازی‌ها
تیم توسعه برای حل این مشکل سه بهینه‌سازی کلیدی پیاده‌سازی کرده است:
- پارتیشن‌بندی سگمنت‌ها (Segment Partitioning): با استفاده از یک استراتژی جدید کامپکشن، سگمنت‌ها بر اساس مقادیر
ctidتفکیک می‌شوند تا محدوده‌های مجزایی از صفحات پستگرس را پوشش دهند. این کار به موتور جستجو اجازه می‌دهد اگر تمام صفحات یک محدوده به عنوانall-visibleعلامت‌گذاری شده باشند، به‌کل از بررسی اعتبار سطرها صرف‌نظر کند. - معکوس‌سازی نگاشت DocId به ctid: به جای نگاشت تک‌به‌تک شناسه‌های سند به
ctid، این نگاشت فشرده‌شده و شماره صفحات را به اولین شناسه سند موجود در آن صفحه مرتبط می‌کند. این رویکرد دسترسی به بافرها و هزینه‌های جستجو را به‌شدت کاهش می‌دهد. - استفاده از بیت‌مپ برای عبارات پرتکرار: ساختارهای رایج مانند BP128 برای عبارات نادر عالی هستند، اما در مواجهه با کلمات کلیدی بسیار پرتکرار (متراکم) دچار سربار می‌شوند. با تبدیل این لیست‌ها به بیت‌مپ برای اصطلاحاتی که بیش از ۱۰ درصد اسناد را پوشش می‌دهند، عملیات منطقی
ANDوORبسیار بهینه‌تر اجرا می‌شوند.
فراتر از یک کوئری ساده COUNT
اگرچه برخی موتورهای متنی روی کوئری‌های ساده و تک‌ستونی عملکرد فوق‌العاده‌ای دارند، اما برنامه‌های دنیای واقعی پیچیده‌تر هستند. بررسی‌ها نشان می‌دهد که وقتی کوئری‌ها شامل فیلترهای روی ستون‌های غیرمتنی (مانند امتیاز یا تاریخ) یا مرتب‌سازی‌های زمانی می‌شوند، تفکیک معماری اهمیت می‌یابد.
در حالی که برخی ابزارهای متنی صرفاً روی یک ستون تمرکز کرده و برای فیلترهای دیگر به B-treeهای خود پستگرس متکی هستند، ParadeDB قابلیت این را دارد که تمام این ستون‌ها را در یک اینکس واحد ترکیب کند. این یکپارچگی به بهبود چشمگیر سرعت در کوئری‌های ترکیبی منجر می‌شود.
چرا برای مهندسان اهمیت دارد؟
برای توسعه‌دهندگانی که با حجم عظیمی از داده‌های متنی و ساختاریافته در پستگرس کار می‌کنند و از کندی جستجوها، فیلترها یا کوئری‌های ترکیبی کلافه شده‌اند، درک این تکنیک‌ها دیدگاه ارزنده‌ای فراهم می‌کند. این مقاله نشان می‌دهد که چگونه می‌توان با بهینه‌سازی ساختارهای داده و کاهش دسترسی‌های غیرضروری به دیسک و حافظه، کارایی جستجو را در مقیاس تولید به شکل چشمگیری بهبود داد.
این مطلب به‌صورت کاملاً خودکار و با هوش مصنوعی از مقالهٔ اصلی و بحث هکرنیوز تهیه شده و ممکن است خطا داشته باشد. حقوق مطلب اصلی متعلق به نویسندهٔ آن است. قوانین و گزارش مشکل