جستجوی فروشگاهی فقط پیدا کردن کلمه در نام محصول نیست. کاربر ممکن است املای دقیق را نداند، فارسی و انگلیسی را ترکیب کند یا بعد از جستجو چند فیلتر همزمان بخواهد. Elasticsearch در Laravel زمانی ارزشمند است که این تجربه از توان query ساده دیتابیس فراتر رفته باشد.
قبل از انتخاب ابزار، نیاز جستجو را بنویسید
ده query واقعی کاربران، فیلترهای مهم و معیار کیفیت را جمع کنید. آیا typo باید تحمل شود؟ برند مهمتر از توضیحات است؟ محصول ناموجود نمایش داده شود؟ مرتبسازی بر اساس محبوبیت چگونه محاسبه میشود؟ بدون این پاسخها، نصب cluster فقط زیرساختی بدون تعریف موفقیت است.
دیتابیس منبع حقیقت میماند
قیمت، موجودی و سفارش در دیتابیس تراکنشی ذخیره میشوند. index جستجو یک مدل خواندن قابل بازسازی است. برای هر سند فقط فیلد لازم برای جستجو و نمایش نتیجه را نگه دارید و امکان rebuild کامل از دیتابیس را از روز اول داشته باشید.
شناسه نسخه یا updated_at کمک میکند event قدیمیتر داده جدید را overwrite نکند. همگامسازی باید اجرای دوباره را تحمل کند.
Mapping را پیش از ورود داده طراحی کنید
text برای تحلیل و جستجوی آزاد است؛ keyword برای فیلتر، aggregation و sort. قیمت numeric و تاریخ date باشد. dynamic mapping میتواند یک فیلد را در اولین سند با نوع اشتباه تثبیت کند. template صریح، خطا را زودتر نشان میدهد.
چالش جستجوی فارسی
ی و ک عربی، نیمفاصله، فاصله، جمعها و ترکیب نام لاتین چالش واقعیاند. normalization را هم در index و هم query یکسان انجام دهید. synonym را محدود و بر اساس log جستجو بسازید؛ فهرست بزرگ synonym دستی خیلی زود نتیجه نامرتبط تولید میکند.
برای نام برند و کد کالا، subfield دقیق نگه دارید. autocomplete را با edge n-gram حسابشده یا completion suggester بسازید؛ n-gram بیش از حد index را متورم میکند.
Ranking را با وزن تجاری ترکیب کنید
عنوان معمولاً از توضیح مهمتر است. exact match نام یا SKU باید boost بگیرد. محبوبیت و موجودی میتوانند امتیاز را تنظیم کنند، اما نباید ارتباط متنی را کاملاً کنار بزنند. چند query دستی کافی نیست؛ یک مجموعه ارزیابی با query و نتایج قابل قبول بسازید.
Filter و aggregation را جدا از متن ببینید
فیلتر برند، دسته و بازه قیمت روی keyword و numeric اجرا میشود و معمولاً در score دخالت ندارد. تعداد هر facet باید با فیلترهای فعال سازگار باشد. nested data مانند تنوع رنگ و سایز اگر غلط مدل شود، ممکن است رنگ یک variant را با موجودی variant دیگر ترکیب کند.
همگامسازی با Queue
بعد از transaction موفق، تغییرات را به queue بفرستید. batch و bulk API برای حجم زیاد ضروریاند. failed job، نرخ عقبماندگی و اختلاف index با دیتابیس باید قابل مشاهده باشند. هنگام rebuild از alias استفاده کنید: index جدید کامل میشود و سپس alias اتمیک جابهجا میشود.
عملیات و هزینه را دستکم نگیرید
heap، disk، shard، refresh و query کند نیاز مانیتورینگ دارند. shard بیشتر همیشه سریعتر نیست. برای کاتالوگ متوسط، تعداد کم shard با replica مناسب اغلب بهتر از تقسیم افراطی است. backup snapshot را همراه با تست بازیابی برنامهریزی کنید.
از سادهترین راهحل کافی شروع کنید
اگر فقط چند هزار محصول و جستجوی ساده دارید، full-text دیتابیس یا سرویس مدیریتشده سبکتر ممکن است کافی باشد. Elasticsearch زمانی انتخاب درستی است که کیفیت جستجو و فیلتر پیچیده ارزش هزینه عملیاتی را داشته باشد.
برای طراحی این مرز و جریان sync، صفحه معماری API و بکاند توضیح بیشتری دارد. کارهای index نیز باید مطابق اصول Queue و Horizon قابل retry و مشاهده باشند.
پرسشهای متداول
چه زمانی Elasticsearch لازم است؟
وقتی ranking، typo tolerance، فیلترهای ترکیبی، تحلیل زبانی یا حجم جستجو از توان راهکار ساده دیتابیس فراتر میرود.
Elasticsearch منبع اصلی داده است؟
معمولاً نه. دیتابیس تراکنشی منبع حقیقت میماند و index جستجو باید بتواند دوباره از آن ساخته شود.