بهترین روشها برای مدیریت شاخص های Elasticsearch

Elasticsearch یک موتور جستجوگر توزیع شده قدرتمند است که با گذشت سالها به یک ابزار ذخیره سازی و تجزیه و تحلیل NOSQL با هدف کلی تبدیل شده است. نسخه اخیر Elasticsearch 7 به پیشرفت های بسیاری در نحوه کار Elasticsearch اضافه کرد. همچنین این پشتیبانی از برنامه های مختلف از جمله یادگیری ماشین ، اطلاعات امنیتی و مدیریت رویداد (SIEM) و نقشه ها ، از جمله دیگر ، از طریق یک Kibana اصلاح شده رسمی رسمی کرد. یکی از زمینه هایی که سزاوار تمرکز ویژه است ، نمایه سازی Elasticsearch و مدیریت شاخص ها است.

نحوه سازماندهی داده ها در سراسر گره ها در یک خوشه Elasticsearch تأثیر زیادی بر عملکرد و قابلیت اطمینان دارد. برای کاربران ، این عنصر از Elasticsearch عملیاتی نیز یکی از چالش برانگیزترین عناصر است. پیکربندی غیر بهینه یا نادرست می تواند همه تفاوت را ایجاد کند. در حالی که بهترین شیوه های سنتی برای مدیریت شاخص های Elasticsearch هنوز هم اعمال می شود ، نسخه های اخیر Elasticsearch چندین ویژگی جدید اضافه کرده است که مدیریت شاخص را بیشتر بهینه و خودکار می کند. در این مقاله چندین روش برای استفاده بیشتر از شاخص های خود با ترکیب توصیه های سنتی با بررسی ویژگی های اخیراً منتشر شده ، مورد بررسی قرار می گیرد.

درک شاخص ها

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

Sharding یک شاخص مفید است ، اما ، حتی پس از انجام این کار ، هنوز یک نسخه واحد از هر سند در فهرست وجود دارد ، این بدان معنی است که هیچ گونه محافظت در برابر از دست دادن داده ها وجود ندارد. برای مقابله با این ، می توانیم تکثیر را تنظیم کنیم. هر قطعه ممکن است تعدادی از ماکت داشته باشد که پس از ایجاد شاخص پیکربندی شده و ممکن است بعداً تغییر یابد. قطعه اصلی ، اصلی اصلی است که نمایه سازی اسناد را کنترل می کند و همچنین می تواند پردازش نمایش داده ها را انجام دهد. نمایشگاه های ماکت را به صورت مستقیم انجام می دهند اما به طور مستقیم اسناد را فهرست نمی کنند. آنها همیشه به یک گره متفاوت از قسمت اصلی اختصاص می یابند ، و در صورت عدم موفقیت در قسمت اصلی ، می توان یک قطعه ماکت را برای گرفتن جای خود ارتقا داد.

در حالی که ماکت های بیشتر در صورت بروز خرابی سطح بالاتری از در دسترس بودن را ارائه می دهند ، همچنین مهم نیست که ماکت های زیادی نداشته باشید. هر شارد وضعیتی دارد که برای دسترسی سریع باید در حافظه نگه داشته شود. هرچه قسمتهای بیشتری استفاده کنید ، سربار بیشتر می تواند باعث ایجاد و تأثیر مصرف منابع شود.

بهینه سازی برای داده های سری زمانی

استفاده از Elasticsearch برای ذخیره سازی و تجزیه و تحلیل داده های سری زمانی ، مانند گزارش های برنامه یا رویدادهای اینترنت اشیاء (IOT) ، نیاز به مدیریت مقادیر عظیمی از داده ها در دوره های طولانی دارد.

Elasticsearch Rollover

داده های سری زمانی به طور معمول در بسیاری از شاخص ها پخش می شود. یک روش ساده برای انجام این کار ، داشتن یک شاخص متفاوت برای دوره های دلخواه ، به عنوان مثال ، یک شاخص در روز است. رویکرد دیگر استفاده از API Rollover است که می تواند به طور خودکار یک شاخص جدید ایجاد کند وقتی اصلی ترین قدیمی ، خیلی بزرگ باشد یا اسناد زیادی داشته باشد.

Elasticsearch کوچک شد

با توجه به سن شاخص ها و داده های آنها کمتر مورد توجه قرار می گیرد ، چندین کار وجود دارد که می توانید برای استفاده از منابع کمتری از آنها استفاده کنید تا شاخص های فعال تر منابع بیشتری در دسترس داشته باشند. یکی از این موارد استفاده از API کوچک برای صاف کردن شاخص به یک قسمت اصلی است. داشتن چندین تکه معمولاً چیز خوبی است اما می تواند به عنوان سربار برای شاخص های قدیمی تر که فقط درخواست های گاه به گاه دریافت می کنند ، باشد. این البته تا حد زیادی به ساختار داده های شما بستگی دارد.

شاخص های یخ زده

برای شاخص های بسیار قدیمی که به ندرت قابل دسترسی هستند ، منطقی است که حافظه مورد استفاده خود را به طور کامل آزاد کنیم. Elasticsearch 6. 6 به بعد API Freeze را فراهم می کند که به شما امکان می دهد دقیقاً همین کار را انجام دهید. هنگامی که یک شاخص منجمد می شود ، فقط خواندنی می شود و منابع آن دیگر فعال نمی شوند.

تجارت این است که شاخص های یخ زده برای جستجو کندتر هستند ، زیرا این منابع اکنون باید به تقاضا اختصاص داده و پس از آن دوباره از بین بروند. برای جلوگیری از کندی پرس و جو تصادفی که در نتیجه ممکن است رخ دهد ، پارامتر پرس و جو IGNORE_THROTTLED = FALSE باید به صراحت استفاده شود تا نشان دهد که شاخص های یخ زده هنگام پردازش یک پرس و جو جستجو باید درج شوند.

مدیریت چرخه عمر شاخص

دو بخش فوق توضیح داده اند که چگونه مدیریت بلند مدت شاخص ها می تواند تعدادی از مراحل را بین زمانی طی کند که آنها به طور فعال داده های جدید را می پذیرند تا فهرست شوند تا جایی که دیگر نیازی به آنها نیست.

ویژگی Management Management Lifecycle (ILM) که در Elasticsearch 6. 7 منتشر شده است ، همه این موارد را در کنار هم قرار می دهد و به شما امکان می دهد این انتقال ها را به صورت خودکار انجام دهید که در نسخه های قبلی پشته E ، باید به صورت دستی یا با استفاده از فرآیندهای خارجی انجام شود. ILM ، که تحت مجوز اصلی Elastic موجود است و نه مجوز Apache 2. 0 ، به کاربران این امکان را می دهد تا خط مشی هایی را تعیین کنند که هنگام انجام این انتقال ها و همچنین اقداماتی که در هر مرحله انجام می شود ، تعریف می کنند.

ما می توانیم از ILM برای تنظیم یک معماری سرد گرمی استفاده کنیم ، که در آن مراحل و همچنین اقدامات اختیاری هستند و در صورت نیاز و در صورت نیاز می توانند پیکربندی شوند:

• شاخص های داغ به طور فعال داده ها را برای فهرست بندی دریافت می کنند و اغلب در حال ارائه نمایش داده ها هستند. اقدامات معمولی برای این مرحله شامل موارد زیر است:
  • تعیین اولویت بالا برای بهبودی.
  • مشخص کردن خط مشی Rollover برای ایجاد یک شاخص جدید هنگامی که فعلی بیش از حد بزرگ ، خیلی قدیمی شود یا اسناد زیادی داشته باشد.
  • تعیین اولویت متوسط برای بازیابی.
  • بهینه سازی شاخص ها با کوچک کردن آنها ، نیرو دادن به آنها یا تنظیم آنها فقط خواندنی.
  • اختصاص شاخص ها به سخت افزار کمتر عملکرد.

  اقدامات معمولی برای این مرحله شامل موارد زیر است:

  • • تعیین اولویت پایین برای بهبودی.
    • یخ زدن شاخص ها.
    • اختصاص شاخص ها به سخت افزار حتی کمتر اجرا.

    خط مشی های ILM ممکن است با استفاده از API REST Elasticsearch یا حتی به طور مستقیم در Kibana تنظیم شود ، همانطور که در تصویر زیر نشان داده شده است:

    

    سازماندهی داده ها در شاخص های Elasticsearch

    هنگام مدیریت شاخص Elasticsearch ، بیشتر توجه شما به سمت اطمینان از ثبات و عملکرد است. با این حال ، ساختار داده هایی که در واقع به این شاخص ها می روند نیز عامل بسیار مهمی در سودمندی سیستم کلی است. این ساختار بر صحت و انعطاف پذیری نمایش داده های جستجو بر روی داده هایی که ممکن است به طور بالقوه از منابع داده های مختلف حاصل شود ، تأثیر می گذارد و در نتیجه همچنین بر نحوه تجزیه و تحلیل و تجسم داده های خود تأثیر می گذارد.

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

    حتی با نگاشت ، به دست آوردن بینش از حجم داده های ذخیره شده در یک خوشه Elasticsearch هنوز هم می تواند یک کار دشوار باشد. داده های دریافت شده از منابع مختلف که ممکن است ساختار مشابهی داشته باشند (به عنوان مثال ، یک آدرس IP که از IIS ، NGINX و سیاهههای مربوط به برنامه استفاده می شود) ممکن است در قسمت هایی با نام های کاملاً متفاوت یا انواع داده ها فهرست بندی شوند.

    طرح مشترک الاستیک ، که با Elasticsearch 7. x منتشر شده است ، یک پیشرفت جدید در این زمینه است. با تنظیم استانداردی برای ادغام نام فیلد و انواع داده ها ، ناگهان جستجو و تجسم داده های حاصل از منابع مختلف داده بسیار ساده تر می شود. این کار کاربران را قادر می سازد تا از Kibana استفاده کنند تا یک دیدگاه واحد از سیستم های مختلف مختلف را که حفظ می کنند ، بدست آورند.

    خلاصه

    تنظیم صحیح Sharding و Replication به طور مستقیم بر ثبات و عملکرد خوشه Elasticsearch شما تأثیر می گذارد. ویژگی های ذکر شده همه ابزارهای مفیدی هستند که به شما در مدیریت شاخص های Elasticsearch کمک می کنند. با این وجود ، این کار یکی از چالش برانگیزترین عناصر برای عملیاتی کردن Elasticsearch است و نیاز به درک هر دو مدل داده Elasticsearch و مجموعه داده های خاص در حال فهرست بندی دارد.

    برای داده های سری زمانی ، API های Rollover و Shrink به شما امکان می دهند با سرریز اصلی شاخص و بهینه سازی شاخص ها مقابله کنید. توانایی اضافه شده به تازگی برای یخ زدن شاخص ها به شما امکان می دهد با دسته دیگری از شاخص های پیری برخورد کنید.

    ویژگی ILM ، همچنین علاوه بر این ، امکان اتوماسیون کامل انتقال چرخه عمر شاخص را فراهم می کند. با افزایش شاخص ها ، آنها می توانند اصلاح و مجدداً مورد استفاده قرار گیرند تا منابع کمتری کسب کنند و منابع بیشتری را برای شاخص های فعال تر در دسترس قرار دهند.

    سرانجام ، ایجاد نقشه برداری برای داده های فهرست بندی شده و زمینه های نقشه برداری به طرح مشترک الاستیک می تواند بیشترین ارزش را از داده ها در یک خوشه Elasticsearch به دست آورد.