Elasticsearch مدیریت‌شده، جست‌وجوی تمام‌متن

Elasticsearch در جایی می‌درخشد که LIKE در دیتابیس رابطه‌ای کم می‌آورد: غلط تایپی، رتبه‌بندی نتایج، فیلترهای ترکیبی و شمارش نتایج بر اساس دسته. چند نمونه از کاربردهای رایج:

اگر جست‌وجوی شما ساده است و داده کم، شاید full-text search داخلی PostgreSQL مدیریت‌شده کافی باشد و به سرویس جدا نیاز نداشته باشید. برای تحلیل‌های عددی سنگین روی رویدادها هم ClickHouse گزینهٔ مناسب‌تری است.

بزرگ‌ترین مشکل جست‌وجوی فارسی، تفاوت نویسه‌هاست: کاربری «كتاب» را با کاف عربی تایپ می‌کند و متن شما «کتاب» با کاف فارسی است. Elasticsearch یک analyzer داخلی به نام persian دارد که نویسه‌های عربی ي و ك را به معادل فارسی تبدیل می‌کند، برخی نشانه‌ها را حذف و واژه‌های پرتکرار فارسی را کنار می‌گذارد. این analyzer جزو خود Elasticsearch است و ما چیزی به آن اضافه نکرده‌ایم.

analyzer در زمان تعریف mapping انتخاب می‌شود و بعداً روی index موجود قابل تغییر نیست؛ پس پیش از وارد کردن داده، برای فیلدهای متنی فارسی analyzer را persian تعیین کنید. اگر بعداً تغییرش دادید، باید index جدیدی بسازید و داده را دوباره وارد کنید.

نیم‌فاصله هم نکتهٔ مهمی است. «می‌خواهم» با نیم‌فاصله و «میخواهم» بدون آن دو توکن متفاوت‌اند. اگر داده‌هایتان یکدست نیست، یک char_filter سفارشی در تنظیمات index تعریف کنید که نیم‌فاصله را یکسان کند، یا متن را پیش از ارسال در اپلیکیشن نرمال کنید.

این‌ها تنظیماتی است که هنگام نصب اعمال می‌شود؛ بقیهٔ پیکربندی همان پیش‌فرض بستهٔ رسمی Elasticsearch 8 است.

هزینه ساعتی است و از کیف پول کسر می‌شود: قیمت سرور پشتیبان به‌اضافهٔ کارمزد مدیریت. اعداد جدول از همان منبع قیمت‌گذاری سامانهٔ صورت‌حساب خوانده می‌شوند و تعرفهٔ تعریف‌شده برای زمان راه‌اندازی هستند؛ تا روز باز شدن سفارش ممکن است تغییر کنند و مبلغ نهایی پیش از ساخت در پنل نمایش داده می‌شود.

اندازهٔ mini برای Elasticsearch قابل سفارش نیست. اولین ساعت هنگام ساخت کسر می‌شود و با حذف نمونه محاسبه متوقف می‌شود؛ تعهد ماهانه ندارد. معادل ماهانه بر مبنای ۷۳۰ ساعت است. برای مقایسه با سایر سرویس‌ها صفحهٔ قیمت‌گذاری و ماشین‌حساب هزینه را ببینید.

برای جست‌وجوی یک سایت محتوایی یا فروشگاه با چند ده هزار تا چند صد هزار سند، standard معمولاً کافی است. heap حدود یک گیگابایتی برای query‌های معمول جست‌وجو و فیلتر جا دارد و کش سیستم‌عامل بخش پرکاربرد index را در حافظه نگه می‌دارد.

اگر تجمیع‌های سنگین (aggregation) روی فیلدهای پرمقدار دارید، لاگ روزانه وارد می‌کنید یا حجم index از چند گیگابایت بیشتر است، plus با heap حدود دو گیگابایت و ۸۰ گیگابایت دیسک انتخاب امن‌تری است. به خاطر داشته باشید Elasticsearch وقتی دیسک از حدود ۸۵ درصد پر شود، دیگر shard جدید روی آن قرار نمی‌دهد و نزدیک ۹۵ درصد index‌ها را فقط‌خواندنی می‌کند.

تغییر اندازهٔ نمونهٔ موجود در فاز نخست پیش‌بینی نشده است؛ پس اندازه را بر اساس حجم داده و ترافیک جست‌وجوی چند ماه آینده انتخاب کنید.

هر دو مسیر درست‌اند و به نیاز شما به کنترل و چند نود بستگی دارد. این جدول تفاوت‌های عملی را نشان می‌دهد:

وقتی سفارش Elasticsearch باز شود، مراحل کار این‌طور است:

Elasticsearch 8 با امنیت فعال نصب می‌شود: درخواست بدون نام کاربری و رمز پذیرفته نمی‌شود و ارتباط روی پورت ۹۲۰۰ فقط از طریق HTTPS است. رمز کاربر مدیر هنگام نصب با ابزار رسمی بازنشانی رمز Elasticsearch به یک مقدار تصادفی تغییر می‌کند، رمزنگاری‌شده در پنل نگه‌داری می‌شود و از طریق فایل اطلاعات اتصال در دسترس شماست.

گواهی HTTPS را خود Elasticsearch هنگام نصب می‌سازد و از مرجع عمومی صادر نشده است. در محیط تولید، گواهی را یک‌بار از سرور بگیرید و در کلاینت به‌عنوان گواهی مورد اعتماد معرفی کنید؛ غیرفعال کردن کامل بررسی گواهی را فقط برای آزمایش استفاده کنید.

برای اپلیکیشن از کاربر مدیر استفاده نکنید. با Security API می‌توانید نقشی با دسترسی فقط به index‌های همان اپلیکیشن بسازید یا یک API key محدود صادر کنید. برای بررسی باز بودن پورت از شبکهٔ خودتان از ابزار بررسی پورت و برای بررسی گواهی از تست SSL کمک بگیرید.

برای پایگاه‌های دادهٔ تحلیلی، از جمله Elasticsearch، بکاپ خودکار ارائه نمی‌شود. ثبت مخزن snapshot هم به تنظیمات سطح سرور نیاز دارد که در این سرویس در دسترس شما نیست؛ پس باید از ابتدا برای بازسازی داده برنامه داشته باشید.

بهترین الگو این است که Elasticsearch منبع اصلی داده نباشد. محصولات، مقالات یا کاربران در دیتابیس اصلی مثل MySQL یا PostgreSQL می‌مانند و یک اسکریپت یا worker آن‌ها را در Elasticsearch index می‌کند. در این حالت اگر index از دست برود، با اجرای دوبارهٔ همان اسکریپت ساخته می‌شود.

اگر دادهٔ منحصربه‌فردی در Elasticsearch دارید، مثل لاگ‌هایی که جای دیگری نیست، با ابزارهایی مثل elasticdump یا ترکیب scroll و Bulk API به‌صورت دوره‌ای خروجی JSON بگیرید و آن را در فضای ذخیره‌سازی ابری نگه دارید.

ساده‌ترین روش انتقال، بازسازی index از منبع اصلی داده است: mapping را روی نمونهٔ جدید بسازید و اسکریپت indexسازی اپلیکیشن را این بار به آدرس جدید اشاره دهید. این روش به نسخهٔ Elasticsearch مبدأ وابسته نیست و فرصت خوبی برای اصلاح mapping و analyzer فارسی هم هست.

اگر منبع جداگانه‌ای ندارید، با elasticdump ابتدا mapping و سپس داده را از مبدأ بخوانید و در مقصد بنویسید. reindex از راه دور به تنظیم سطح سرور نیاز دارد و در این سرویس در دسترس نیست. اگر مبدأ نسخهٔ ۶ یا ۷ است، نوع‌های حذف‌شده و تغییرات mapping را پیش از انتقال بررسی کنید.

نمونهٔ Elasticsearch تک‌نودی است؛ replica روی نود دیگر، تحمل خرابی و توزیع shard بین چند نود ارائه نمی‌شود. اگر سرور میزبان برای نگه‌داری یا خرابی از دسترس خارج شود، جست‌وجو هم تا بازگشت آن کار نمی‌کند؛ اپلیکیشن را طوری بنویسید که در این حالت به جست‌وجوی ساده‌تر در دیتابیس اصلی برگردد.

Kibana‏، snapshot، نصب افزونه و دسترسی به فایل‌های پیکربندی در این سرویس وجود ندارد و بکاپ خودکار ارائه نمی‌شود. اندازهٔ mini قابل سفارش نیست و heap حداکثر دو گیگابایت است. اگر به چند نود یا تنظیمات خاص نیاز دارید، Elasticsearch را روی سرور ابری خودتان نصب کنید.