خوبی و بدی های Elasticsearch

خوبی و بدی های Elasticsearch

الستیک به عنوان یه nosql معروف، باید تو جعبه ابزار مهندسیمون باشه تا موقع حل یه مساله اگه دیدیم مناسب حال اون مساله است و تو اون موقعیت خوبی هاش به بدی هاش میچربه، ازش استفاده کنیم. خوبی و بدی هایی که من از الستیک سراغ دارم:یک nosql با طعم RESTهمه کارها تو الستیک از تعریف اندیس و اسکیما بگیر تا داده زدن و پرس و جو حتی کارهای مدیریتی با واسط rest قابل انجامه و همه هم به خوبی مستند شده. از این منظر الستیک خیلی خوش دست هست. الستیک برای خیلی از زبون ها کلاینت سطح بالاتری روی این rest هم داده که مدل داده مناسبتر و کارهایی مثل اینکه اگه به یه سرور درخواست زد جواب نداد به یه سرور دیگه درخواست بزن هم توش پیاده شده.نکته بد قضیه کاراییه که به جای یه پروتکل باینری از یه پروتکل متنی استفاده شده. اتفاقا به همین دلیل یه کلاینت جاوایی تا مدت ها بود که با همون دیتا مدل داخلی الستیک کار میکرد ولی بنا به بنچمارک هایی که گرفته شد نشون داده شد که کارایی در حالت متنی افت زیادی نکرده و بخاطر مشکلاتی مثل وابستگی زیاد به کد الستیک و نسخه جاوا و بحث امنیت کنار گذاشته شد.نصب و توزیع شدگی، شیک و مجلسینصب یه نود الستیک خیلی ساده است (برای ما که تو ایران خیلی as-service و کلود استفاده نمیکنیم فاکتور مهمیه). به صورت رسمی بسته deb و rpm, داکر، انسیبلی، و هلم (برای کوبرنتیز) هست. شاید مهمترین تنظیمات اولیه اش فقط هیپ جاوا و جاهایی که داده رو ذخیره میکنه باشه. در حالت توزیع شده هم با تنظیم seed، سرورها همدیگر رو کشف کرده و کلاستر الستیک خیلی راحت شکل میگیره. یکی از دلایل سادگی نصب اینه که در الستیک سعی شده به مولفه خارجی وابسته نباشه (مقایسه کنید با hbase) و تنوع مولفه نداشته باشه (مقایسه کنید با mongo توزیع شده). مثلا اوایل بحث بود که از زوکیپر استفاده بشه ولی به همین دلیل رفتن خودشون zen رو نوشتن (که تا مدت ها باگ داشت! و حتی الستیک مشکل brain split داشت)در مورد replication و partitioning داده ها هم تا حد زیادی بی دغدغه انجام میشن (هم مفهومی و هم عملیاتی) و به صورت خودکار مدیریت میشن. یه مشکل مهم اینه که تعداد پارتیشن ها (شاردها) موقع ساخت اندیس باید تنظیم بشه و قابل تغییر نیست. بغیر از reindexing روش معمول برای وقتی کلاستر اندازه اش تغییر کنه و بخواهید پارتیشن ها رو زیاد کنید اینه که یه اندیس جدید با تعداد شارد جدید بسازید و بعد یه اندیس مجازی که اجتماع اندیس قدیم و جدید هست بسازید و از اون اندیس مجازی استفاده کنید.جستجوی خرگوشی، نوشتن لاک پشتیدیگه تو اسمشم هست، کاربرد اصلی الستیک برای جستجو بوده که اینکارو با کتابخانه لوسین انجام میده. در واقع اصل کار یک موتور جستجو هست که محتوای فیلدهای سندها به صورت یکسری اندیس در میاد (یعنی برای هر مقدار از یک فیلد محاسبه میشه چه سندهایی آن مقدار را دارند، البته برای مقادیر پیوسته مثل اعداد یا مختصات جغرافیایی از مدل دیگری همچون kd-tree استفاده میشه). پرس و جو که زده میشه به ازای مقادیر فیلدهای مورد جستجو، لیست سندهایی که فیلد مربوطه این مقدار هست از روی اندیس مربوطه به سرعت بدست میاد و بسته به عملیاتی که در پرس و جو بر روی این فیلدها تعریف شده مثلا and، لیست نهایی سندها بدست میاد (البته این وسط از skip list ها و کلی ایده دیگه برای سرعت بخشیدن استفاده شده). امکان امتیازدهی و برگرداندن لیست مرتب شده بر اساس امتیاز و تحلیل متن هم مثل یک موتور جستجوی واقعی هست که در نتیجه برای جستجوی full text عالی است ولی جدا از این، برای وقتیکه روی چندین فیلد میخواهید جستجوی سریعی انجام دهید کارایی بالایی دارد.این سرعت بالا مجانی نیست. محاسبه اندیس هزینه بر است و افزایشی نیست. یعنی عملا باید یه مجموعه سند جمع بشود و بعد اندیس ها به ازا هر فیلد (یک سگمنت در هر سرور) ساخته شود. البته بتدریج در پس زمینه سگمنت های کوچک با هم ترکیب شده و سگمنت های بزرگتر ساخته می شود تا نیاز به جستجوی همزمان در سگمنت های کمتری باشد (خود این باعث میشه os cache ناکارآمد بشه). در نتیجه اولا نوشتن در الستیک بهره وری کمی دارد، ثانیا real time نیست یعنی از زمان نوشتن سند، تا اینکه بتواند در نتایج جستجو بیاید فاصله وجود دارد (حداقل یک ثانیه)، بعد به روزرسانی نداریم و عملا به صورت add+del پیاده شده که نتیجتا به روزرسانی پر هزینه است . خیلی دنبال تراکنش هم نباشید. به علت مدل جستجو هم pagination خیلی کارا نیست.اگه از فیلد _source استفاده کنید سند به صورت خام هم ذخیره میشه که حجم اندیس افزایش قابل ملاحظه پیدا میکنه و نوشتن کندتر هم میشود ولی یکسری جاها و خصوصا برای دیباگ مفیده. در مورد هر فیلد میتوانید مشخص کنید که میخواهید قابل جستجو باشد (برایش اندیس ساخته شود) یا قابل ذخیره سازی (به صورت ستونی مقادیرش ذخیره شود) یا هر دو. که با تنظیم این دو مشخصه میشود هزینه های نوشتن را کمتر کرد. یه خوبی الستیک اینه که ذخیره سازی به صورت ستونی (فیلد به فیلد) انجام میشه که در نتیجه فشردگی خوبی داره.راست و دروغ schemalessبر خلاف RDBMS ها که به ازای هر جدول باید ستون ها و نوعشون رو از پیش تعیین کرد، تو الستیک هر سند میتونه فیلدهای خودش رو داشته باشه که مثلا برای چیزی مثل ذخیره لاگ ها که هر لاگ ممکنه فیلدهای متنوعی داشته باشه و از قبل مشخص نباشه عالیه. در پشت صحنه البته در هر اندیس لیست فیلدها نگهداری میشه که به طور پیش فرض از یکسری قواعد پویا بر حسب اسم فیلد یا مقدار اون ساخته میشه. در استفاده های جدی ولی باید خواص هر فیلد (مثل اینکه ذخیره بشه، قابل جستجو باشه یا نه، چجوری آنالیز بشه) به دقت تنظیم بشه و در نتیجه معمولا احتیاج است که مشخصات فیلدها هنگام ساخت اندیس داده بشه و لذا قابلیت schemaless خیلی هم کارآمد نیست و فقط شروع سریعتری میدهد.زبان جستجوی مریخی، خداحافظ joinبا توجه به هزینه بر بودن join در حالت توزیع شده، این قابلیت تو الستیک نیست و برای رسیدن به اون از حالات خاصتری مثل parent-child (با محدودیت اینکه اسناد در یک شارد باشند) یا nested ها (با محدودیت اینکه اسناد همه با هم اضافه یا به روز شوند) باید استفاده شود. سینتکس aggregation هم که به این معجون اضافه بشه، به یک زبان پرس و جویی میرسیم که نامانوس و گیج کننده است و معمولا کلی فکر باید کرد که کویری به چه صورت باید بیان شود. حتی جستجوهای ساده تر هم با توجه به تنوع رفتاری اپراتورها نیاز به فکر و مطالعه دارند.با تمام این احوال وجود واسط کاربری قدرتمندی مثل kibana خیلی در پرس و جوی راحت تر از الستیک موثر است. کلا کیبانا به خاطر داشبوردهای خوبی هم که میشه باهاش ساخت، خیلی مفیده. رام ولی خوش اشتهااز نظر پشتیبانی و نگهداری الستیک اذیت کن نیست. ابزار برای پشتیبان گیری دارد و rest ها اطلاعات کاملی از وضعیت کلاستر میدهند که می توان در سیستم های مونیتورینگ استفاده کرد. نسبت به خرابی دیسک درست عمل میکند‌. replication هم به صورت consistent با مدل isr پیاده شده برای همین مشکلات inconsistency برخورد نمیکنید. دغدغه اصلی مصرف حافظه بالای این موجود است. هر اندیس باز میزان مشخصی حافظه میگیرد و لذا اگر اندیس ها در حال زیاد شدن باشند مصرف بالا میرود و لذا نسبت به مدیریت یا حذف دوره ای آن ها باید اقدام کرد. با توجه به اینکه فایل های سگمنت به صورت memory mapped باز میشوند، نقش کش سیستم عامل در کارایی نیز کاملا مشهوده و معمولا باید رم خالی برای این قضیه در نظر گرفت.برای از ما بهترانادامه رشد یک پروژه متن باز در حد الستیک بدون پشتیبانی شرکتی با مدل تجاری قوی ممکن نیست. شرکت الستیک خیلی فعال عمل کرده و حول این محصول پایه کلی محصولات متنوع تر و ارایه به صورت ابری رو پیش میبره (حتی جدیدا مدل لایسنس الستیک رو به گونه ای تغییر داده که اگر کسی بخواد الستیک رو به صورت ابری ارایه بده باید متن کل اون ارایه رو منتشر کنه). xpack هم مجموعه اضافات تجاری است که با نسخه متن باز نصب میشه ولی بعد از یکدوره ۳۰ روزه غیرفعال میشه. دو سه تا ویژگی بدرد بخور تو xpack (الستیک و کیبانا) هست که میگم که دلتون بسوزه: قابلیت احراز هویت و کنترل دسترسی، پرس و جوی sql، تعریف هشدار

Author: admin

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *