اپلیکیشن‌های وان پلتفرم
OpenSearch
OpenSearch چیست؟
OpenSearch یا اوپن سرچ، مجموعه‌ای متن‌باز برای جست‌وجو و تحلیل داده است. داده‌ها در ایندکس‌ها سازمان‌دهی می‌شوند تا بتوان روی آن‌ها جست‌وجو و تحلیل انجام داد. این ابزار برای نیازهایی مانند جست‌وجوی محتوای یک برنامه یا بررسی داده‌های عملیاتی قابل استفاده است.
قبل از انتخاب ابزار باید معلوم باشد چه چیزی جست‌وجو می‌شود و پاسخ مناسب چه شکلی دارد. نیاز جست‌وجوی عنوان محصولات با تحلیل پیام‌های خطای نرم‌افزار متفاوت است. تعریف درست فیلدها و شیوهٔ ورود داده بر کیفیت نتیجه و مصرف منابع اثر مستقیم دارد.
چه داده‌ای را وارد ایندکس کنیم؟
پیشنهاد می‌شود همهٔ اطلاعات را صرفاً به دلیل در دسترس بودن وارد نکنید. برای یک فهرست کالا، فیلدهای قابل جست‌وجو و فیلتر را بر اساس نیاز کاربر انتخاب کنید. ذخیرهٔ داده‌های اضافه هم هزینه ایجاد می‌کند و هم کنترل اطلاعات را دشوارتر می‌سازد.
در تحلیل لاگ، مدت نگهداری اهمیت زیادی دارد. اگر داده بدون برنامه انباشته شود، فضای دیسک به‌تدریج مصرف خواهد شد. باید مشخص باشد چه داده‌ای برای عیب‌یابی روزانه لازم است و چه چیزی به نگهداری طولانی‌تر نیاز دارد.
انتخاب منابع و معماری سرور
حافظه، توان دیسک و حجم پردازش جست‌وجو را هم‌زمان بررسی کنید. تعداد سند به‌تنهایی معیار کافی نیست؛ اندازهٔ هر سند، نرخ ورود و نوع پرس‌وجوها تفاوت ایجاد می‌کنند. منابع موردنیاز محیط آزمایش را نباید بدون اندازه‌گیری به محیط اصلی تعمیم داد.
برای پروژه‌ای با نیاز قابل توسعه، پلن‌های سرور ابری لینوکس را مقایسه کنید. در بارهای سنگین‌تر، مشخصات سرور اختصاصی نیز قابل بررسی است. انتخاب چند گره یا یک سرور باید با هدف دسترس‌پذیری و برنامهٔ نگهداری هماهنگ باشد.
از نمونهٔ آزمایشی تا استفادهٔ واقعی
پیشنهاد می‌شود ابتدا بخشی از دادهٔ واقعی و مجموعه‌ای از جست‌وجوهای متداول را وارد محیط آزمایش کنید. فقط زمان پاسخ اولین درخواست را نسنجید؛ کیفیت نتیجه، مصرف منابع و رفتار سیستم هنگام ورود دادهٔ تازه را هم بررسی کنید.
برای دسترسی برنامه به موتور جست‌وجو، مسیر مشخص و محدود تعریف کنید. همچنین معلوم باشد در صورت حذف یا خرابی ایندکس، داده چگونه بازسازی می‌شود. تکثیر داده میان اجزای سامانه و داشتن نسخهٔ پشتیبان مستقل، دو موضوع متفاوت‌اند.
جست‌وجوی محصول با جست‌وجوی لاگ چه تفاوتی دارد؟
در فروشگاه، کاربر انتظار دارد با نام، ویژگی یا بخشی از توضیح به کالای مناسب برسد. در تحلیل لاگ، تیم فنی معمولاً به دنبال رویدادهای یک بازهٔ زمانی یا خطاهای یک سرویس است. هر دو از جست‌وجو استفاده می‌کنند، اما فیلدها، اولویت نتایج و مدت نگهداری آن‌ها متفاوت است. بهتر است مدل داده را بر اساس همان مسئله طراحی کنید و از یک ساختار عمومی برای همهٔ کاربردها استفاده نکنید.
برای مثال، شناسهٔ سفارش باید به‌گونه‌ای قابل تطبیق باشد که نتیجهٔ اشتباه ندهد، در حالی که متن توضیح محصول به جست‌وجوی واژه‌ها نیاز دارد. پیشنهاد می‌شود نوع هر فیلد و کاربرد آن پیش از ورود انبوه داده مشخص شود. تغییر ساختار در پروژهٔ بزرگ ممکن است به بازسازی ایندکس و برنامهٔ انتقال نیاز داشته باشد؛ بنابراین یک نمونهٔ کوچک اما واقعی ارزش زیادی دارد.
کیفیت جست‌وجوی فارسی را چگونه ارزیابی کنیم؟
فهرستی از عبارت‌هایی تهیه کنید که کاربران واقعاً جست‌وجو می‌کنند. تفاوت نگارش حروف، فاصله و نیم‌فاصله، نام فارسی و انگلیسی و شکل رایج نام محصول را در نمونه‌ها بگنجانید. سپس بررسی کنید چه نتایجی در رتبه‌های اول ظاهر می‌شوند. سرعت بالا به‌تنهایی کافی نیست؛ اگر نتیجهٔ مرتبط پیدا نشود، تجربهٔ جست‌وجو همچنان ضعیف خواهد بود.
برای تنظیم پردازش متن و رتبه‌بندی، تغییرها را یکی‌یکی با همان مجموعهٔ پرسش آزمایش کنید. بهبود یک عبارت نباید باعث خراب شدن ده‌ها جست‌وجوی دیگر شود. ثبت پرسش‌های بی‌نتیجه، با رعایت محدودیت دادهٔ شخصی، می‌تواند به شناخت کمبود محتوا یا نیاز به اصلاح تنظیمات کمک کند. این بازبینی بهتر است پس از تغییر عمدهٔ فهرست محصولات هم انجام شود.
هماهنگی ایندکس با منبع اصلی داده
اگر اطلاعات اصلی در دیتابیس برنامه نگهداری می‌شود، باید مسیر به‌روزرسانی موتور جست‌وجو روشن باشد. اضافه شدن محصول، تغییر وضعیت و حذف آن همگی باید در نتیجهٔ جست‌وجو منعکس شوند. فقط وارد کردن اولیهٔ داده کافی نیست. تعیین کنید تأخیر قابل قبول چقدر است و چگونه اختلاف میان منبع اصلی و ایندکس شناسایی می‌شود.
برای بازسازی، یک مسیر قابل تکرار طراحی کنید. اگر لازم شد ایندکس دوباره ساخته شود، معلوم باشد داده از کجا خوانده می‌شود و برنامه در مدت انتقال چه رفتاری دارد. عملیات حجیم را پیش از اجرا روی محیط اصلی با نمونهٔ مناسب بسنجید. فرایندی که در آزمایش چندثانیه طول می‌کشد ممکن است روی دادهٔ کامل، زمان و فضای موقت زیادی لازم داشته باشد.
تقسیم ظرفیت، پشتیبان‌گیری و تحمل خرابی
تکثیر داده برای ادامهٔ سرویس و نسخهٔ پشتیبان برای بازیابی، هدف یکسانی ندارند. حذف اشتباه ممکن است در نسخه‌های فعال نیز منعکس شود. به همین دلیل، برای اطلاعاتی که بازسازی آن‌ها دشوار است باید برنامهٔ بکاپ و آزمون بازیابی جدا داشت. زمان قابل قبول بازیابی را پیش از انتخاب زیرساخت مشخص کنید، نه بعد از اولین اختلال.
برای لاگ‌ها، حجم ورود روزانه و مدت نگهداری را تخمین بزنید و برای رشد مصرف دیسک هشدار داشته باشید. در پروژهٔ جست‌وجوی محتوا، تعداد درخواست هم‌زمان و پیچیدگی فیلترها را نیز بسنجید. یک سرور آزمایشی می‌تواند شروع مناسبی باشد، اما تصمیم دربارهٔ استقرار چندگرهی باید بر اساس اهمیت سرویس، بار واقعی و توان نگهداری تیم گرفته شود.
سوالات متداول
آیا OpenSearch جای دیتابیس اصلی را می‌گیرد؟
در بسیاری از معماری‌ها، موتور جست‌وجو کنار منبع اصلی داده قرار می‌گیرد. نقش هر بخش باید بر اساس نیاز پروژه تعیین شود.
آیا افزایش رم به‌تنهایی مشکل سرعت را حل می‌کند؟
لزوماً خیر. مدل داده، نوع پرس‌وجو، توان دیسک و تنظیمات استقرار هم در عملکرد اثر دارند.
آیا از ابتدا باید چند سرور تهیه کنیم؟
به حجم کار و نیاز تحمل خرابی بستگی دارد. معماری را پس از بررسی بار واقعی و اهمیت سرویس انتخاب کنید.
زیرساخت مناسب برای راه‌اندازی را انتخاب کنید
پلن‌ها و منابع سرور را متناسب با نیاز نرم‌افزار و پروژهٔ خود مقایسه کنید.
