در این نوشته قصد دارم در مورد best practice های استفاده از ElasticSearch بنویسم. این روش‌ها توصیه‌های عمومی هستند و می‌توانند در هر مورد کاربردی اعمال شوند.
آشنایی با Bulk Requests
مفهوم API Bulk امکان انجام بسیاری از عملیات‌های index/delete را در یک فراخوانی API فراهم می‌کند. این می‌تواند سرعت index کردن را به طور قابل توجهی افزایش دهد. هر subrequest به صورت مستقل اجرا می‌شود، بنابراین failure یک subrequest تاثیری بر success دیگران نخواهد داشت. اگر هر یک از request ها faile شود، top-level error flag به true تنظیم می‌شود و جزئیات خطا گزارش خواهد شد.
آشنایی با Multithread clients to Index Data
یک single thread که request های bulk را ارسال می‌کند، احتمالاً قادر به استفاده کامل از ظرفیت indexing ElasticSearch cluster نخواهد بود. برای استفاده از تمام منابع cluster، شما باید داده‌ها را از چندین thread یا processe ارسال کنید. علاوه بر استفاده بهتر از منابع cluster، این باید کمک کند تا هزینه هر fsync را کاهش دهد. هر دو داده index و transaction log به طور دوره‌ای به دیسک flush می‌شوند. اگر داده‌های بیشتری با multithread وجود داشته باشند، داده‌های بیشتری به دیسک sync می‌شود تا I/O را برای بهبود performance کاهش دهد.
درباره index.refresh_interval
به طور پیش فرض، ElasticSearch به طور دوره‌ای هر ثانیه index ها را refresh می‌کند، اما درصورتی که تنها بر روی index هایی که در 30 ثانیه گذشته حداقل یک request از نوع جستجو دریافت کرده باشند. اگر شما ترافیک جستجوی کم یا اصلاً ندارید (به عنوان مثال، کمتر از یک request جستجو در هر 5 دقیقه) و می‌خواهید برای سرعت indexing بهینه‌سازی کنید، این config بهینه است. این رفتار در پیکربندی پیش فرض هنگامی که جستجویی انجام نمی‌شود، به بهینه‌سازی خودکار bulk indexing کمک می‌کند. برای انصراف از این رفتار، می توانید interval refresh را به صورت صریح تنظیم کنید. از طرف دیگر، اگر index شما request های جستجوی منظمی را تجربه کند، این رفتار پیش فرض به این معنی است که ElasticSearch هر 1 ثانیه index شما را refresh خواهد کرد. اگر بین زمانی که یک document ایندکس می‌شود و زمانی که قابل مشاهده می‌شود را افزایش دهید، افزایش index.refresh_interval به یک مقدار بزرگتر، به عنوان مثال 30s، ممکن است به بهبود سرعت indexing کمک کند.
آشنایی با Auto generated IDs
هنگام index کردن یک document که دارای یک id مشخص است، ElasticSearch نیاز دارد تا بررسی کند که آیا document ای با همان id در همان shard وجود دارد یا خیر، که این یک عملیات هزینه‌بر است و همین هزینه با رشد index بیشتر می‌شود. با استفاده از id های خودکار، ElasticSearch می‌تواند این بررسی را از بین ببرد، که باعث می‌شود index کردن سریع‌تر انجام شود.
آشنایی با index.translog.sync_interval
این پارامتر تعیین می‌کند که بدون توجه به عملیات write، چه مقداری translog به دیسک fsync شده و commit می‌شود. به طور پیش فرض برابر با 5 ثانیه است. مقادیر کمتر از 100 میلی‌ثانیه مجاز نیستند.
آشنایی با index.translog.flush_threshold_size
مفهوم translog تمام عملیات‌هایی را که هنوز به طور safe در Lucene ذخیره نشده‌اند را ذخیره می‌کند. اگرچه این عملیات‌ها برای خواندن در دسترس هستند، اما اگر shard متوقف شد و نیاز به recovery داشت، باید دوباره replay شوند. این تنظیمات maximum اندازه کلی این عملیات‌ها را کنترل می‌کند، تا از اینکه recovery ها زمان زیادی بگیرند جلوگیری شود. هنگامی که به maximum رسیده باشد، یک flush اتفاق خواهد افتاد، که یک Lucene commit point جدید تولید می‌کند. به طور پیش فرض برابر با 512 مگابایت است.
آشنایی با Large Documents
تمامی large document ها بر network، مموری و دیسک فشار و stress بیشتری می آورند. index کردن large document ها می تواند مقدار حافظه ای را استفاده کند که ضریبی از اندازه اصلی document است. همچنین Proximity search ها (به عنوان نمونه phrase query ها) و highlighting نیز گران تر می شود زیرا هزینه آنها به طور مستقیم به اندازه document اصلی بستگی دارد.
تنظیم Index Mapping Explicitly
دیتابیس ElasticSearch می تواند mapping را به صورت dynamic ایجاد کند، اما ممکن است برای تمام سناریوها مناسب نباشد. به عنوان مثال، فیلد های string پیش فرض در ElasticSearch هر دو از انواع "keyword" و "text" هستند. در بسیاری از سناریوها غیر ضروری است.
آشنایی با Index Mapping — Nested Types
همانطور که می دانید query در فیلدهای nested نسبت به فیلدهای parent document کندتر است. بازیابی فیلدهای match شده nested سرعت را کاهش می دهد. هرگاه شما فیلدی از یک document حاوی فیلدهای nested را به روز کنید، بستگی به اینکه آیا یک فیلد nested را به روز کردید یا خیر، تمام داكيومنت های Lucene باید به عنوان "حذف شده" علامت گذاری شوند و دوباره نوشته شوند.
علاوه بر کاهش سرعت به روزرسانی ها، چنین عملیاتی garbage ای ایجاد می کند که باید توسط segment merging بعداً پاک شود.
آشنایی با Index Mapping
با استفاده از فیلد _all، مقادیر تمام فیلدها به یک string تبدیل می شوند. این نسبت به سایر فیلدها نیاز به فضای بیشتر CPU و دیسک دارد. بیشتر use case ها نیازی به فیلد _all ندارند. شما می توانید چندین فیلد را با استفاده از پارامتر copy_to عمل concatenate را انجام دهید. فیلد _all به طور پیش فرض در نسخه های 6.0 و بالاتر ElasticSearch غیرفعال است.
آشنایی با Leverage Index Templates
با Index template ها تنظیماتی مانند تعداد shard ها، replica ها و mappings ها را تعریف می کنند که می توانید به صورت خودکار هنگام ایجاد index های جدید اعمال کنید. الستیک template ها را بر اساس pattern ایندکسی که با نام ایندکس مطابقت دارد به ایندکس های جدید اعمال می کند.
استفاده از replica ها به منظور مقیاس پذیری و انعطاف پذیری
الستیک سرچ به صورت available و scalable با نیازهای شما ساخته شده است. شما می توانید node ها را به cluster اضافه کنید تا ظرفیت آن را افزایش دهید و ElasticSearch به طور خودکار load داده ها و query شما را بین تمام node های موجود توزیع می کند. برای اینکه ElasticSearch همیشه در دسترس باشد، index های آن باید fault tolerance داشته باشند. این می تواند با استفاده از replica shard ها انجام شود.
یک replica shard کپی از یک primary shard است. replica ها نسخه های اضافی از داده های شما را برای محافظت در برابر خرابی سخت افزار و افزایش ظرفیت برای ارائه request های خواندن مانند جستجو یا بازیابی یک document فراهم می کنند.
آشنایی با مفهوم Shard Sizing
یک shard که در ایندکس Lucene است، از file handle ها، مموری و CPU cycle ها استفاده می کند. هدف از انتخاب تعداد shard ها توزیع یکنواخت index در سراسر تمام node های داده در cluster است. با این حال، این shard ها نباید خیلی بزرگ یا خیلی زیاد باشند. یک قاعده خوب این است که سعی کنید اندازه شارد را بین 10-50 گیگابایت نگه دارید. شاردهای بزرگ می توانند باعث سختی ElasticSearch در بازیابی از خرابی شوند، اما چون هر شارد مقداری از CPU و حافظه را استفاده می کند، داشتن shard های کوچک خیلی زیاد می تواند باعث خطا های performance و out of memory شود.
آشنایی با Index State Management
مفهوم ISM به شما اجازه می دهد تا policy های custom management را برای خودکار کردن task های روتین تعریف کنید و آنها را روی index ها و index pattern ها اعمال کنید. دیگر نیازی به راه اندازی و مدیریت فرآیندهای خارجی برای اجرای عملیات index نیست. یک policy شامل یک state پیش فرض و یک لیست از state ها برای انتقال بین index ها است. در هر state ای، شما می توانید یک لیست از action ها و شرایطی که این trigger را فعال می کنند تعریف کنید. یک use case معمول این است که به طور دوره ای index های قدیمی را پس از یک دوره معین حذف کنید.
باتشکر از
https://lazypro.medium.com/best-practices-of-using-elasticsearch-2a2485a289c7
