https://virgool.io/feed/@emitis برنامه‌نویس وب، یه رویاپرداز حرفه‌ای، و بسیار علاقمند به #regex fa 2026-07-07 21:19:03 https://files.virgool.io/upload/users/36552/avatar/avatar.png?height=120&width=120 https://virgool.io/@emitis https://virgool.io/@emitis/%D8%A7%D9%84%D8%B3%D8%AA%DB%8C%DA%A9%D8%B3%D8%B1%DA%86-%D8%A7%D8%B2-%D8%AE%DB%8C%D9%84%DB%8C-%D8%A7%D9%88%D9%84-%D9%82%D8%B3%D9%85%D8%AA-%DB%B2-cgywwaiqjyt6 این بار، می‌خوام چیزایی که راجع به معماری الستیک‌سرچ یاد گرفتم با شما در میون بذارم. مسائلی که ندونستنشون باعث نمی‌شه که کار شما تو استفاده از الستیک‌سرچ گره بخوره، ولی دونستن این که پشت صحنه چه خبره می‌تونه خیلی به حل کردن مشکلات احتمالی سرعت بده.نود‌ها و کلاسترهادر معماری الستیک‌سرچ، نود‌ها (Nodes) و کلاسترها (Clusters) قسمت اصلی هستن. هر نود یک سِروِره که داده‌ها رو ذخیره می‌کنه و قسمتی از یک کلاستره.هر کدوم از نودها بخشی از داده‌ها رو ذخیره می‌کنن و همه‌ی اون‌ها در ذخیره و جست‌و‌جوی داده‌ها مشارکت دارن. یعنی برای هر کوئری جست‌وجو، هر نود با جست‌وجو در داده‌هایی که خودش ذخیره کرده با بقیه‌ی نودهای توی کلاستر همکاری می‌کنه.هر کدوم از نودها می‌تونن درخواست‌های HTTP رو بگیرن، پردازش کنن، و جواب بدن. یک نود مشخص در یک کلاستر راجع به همه‌ی نودهای دیگه در همون کلاستر می‌دونه و می‌تونه درخواست‌هایی که براش میاد رو به نودهای دیگه ارجاع بده. هر نود می‌تونه به عنوان رئیس بقیه‌ی نودها انتخاب بشه. به این رئیس می‌گن مستر نود (Master Node). این نود رئیس تغییرات رو توی همه‌ی نودهای یک کلاستر هماهنگ می‌کنه. مثل اضافه و حذف کردن یک نود یا اضافه و حذف کردن ایندکس‌ها. مستر نود وضعیت کلاستر رو به‌روزرسانی می‌کنه و تنها نودیه که می‌تونه این کار رو بکنه.کلاسترها و نودها اسم‌های یکتایی دارن. کلاسترها به صورت پیش‌فرض به نام «elasticsearch» نام‌گذاری می‌شن. نودها هم یک شناسه‌ی یکتای جهانی (Universally Unique Identifer) دارند که به اختصار بهش می‌گن UUID. ما می‌تونیم این پیش‌فرض‌ها رو تغییر بدیم. ولی باید حواسمون باشه که اسم نودها خیلی مهمه. چون با این اسم‌ها می‌تونیم بفهمیم که کدوم ماشین، فیزیکی یا مجازی، متعلق به کدوم نود الستیک‌سرچ هست. نودها به صورت پیش‌فرض به یک کلاستر به نام «elasticsearch» اضافه می‌شن ولی ما می‌تونیم این رفتار رو عوض کنیم. بهتره که اسم پیش‌فرض رو توی محیط پروداکشن عوض کنیم که مطمئن بشیم هیچ نودی تصادفن به کلاستر پروداکشن اضافه نمی‌شه. ایندکس‌ها و داکیومنت‌هاهر داده‌ای که روی یک کلاستر الستیک‌سرچ ذخیره می‌کنیم، هر واحد داده که می‌تونه ایندکس بشه، یک داکیومنت هست. هر داکیومنت یک JSON هست که می‌تونه یک سطر در یک پایگاه داده‌ی رابطه‌ای باشه. داکیومنت‌ها تو یه جایی ذخیره می‌شن که بهشون می‌گن ایندکس. هر ایندکس مجموعه‌ای از داکیومنت‌های مربوط به همه. به عنوان مثال، ما می‌تونیم برای کاربران، سفارش‌ها، یا محصولاتمون یک ایندکس داشته باشیم. هر داکیومنت یک ID یکتا داره که می‌تونه توسط ما یا توسط خود الستیک‌سرچ و به صورت اتوماتیک مقداردهی بشه. یک داکیومنت می‌تونه با استفاده از ایندکسش و ID یکتاش پیدا بشه. ایندکس‌ها با اسمشون شناخته می‌شن که متشکل از حروف کوچیک انگلیسیه. شاردینگهمونطور که گفتیم، الستیک‌سرچ خیلی مقیاس‌پذیر (Scalable) هست. یکی از دلایل این مقیاس‌پذیری رو می‌تونیم به ویژگی شاردینگ نسبت بدیم. با استفاده از شاردینگ‌، الستیک‌سرچ می‌تونه هر ایندکس رو به چند شارد تقسیم کنه. هر کدوم از این شاردها به تنهایی می‌تونن یک ایندکس محسوب بشن و تمام ویژگی‌های یک ایندکس رو داشته باشن. هر داکیومنت در یک ایندکس روی یکی از این شاردها ذخیره می‌شه. نکته‌ی جالب راجع به شاردها اینه که هر کدوم از اون‌ها می‌تونن روی یک نود از کلاستر قرار بگیرن. تعداد شاردها رو می‌تونیم زمان ساختن یک ایندکس مشخص کنیم. ولی اگه عددی رو براش مشخص نکنیم، به صورت پیش‌فرض، عدد ۵ در نظر گرفته می‌شه. بعدز از ساخته شدن یک ایندکس، دیگه نمی‌شه تعداد شاردهای اون رو تغییر داد. ولی اگه یه نفر با یک کلت روی شقیقه‌مون ازمون می‌خواست که تعداد شاردهای یک ایندکس رو تغییر بدیم، یه راه سخت برای این کار وجود داره. می‌تونیم یه ایندکس جدید با تعداد شاردهای مورد نظر بسازیم و دیتا رو از ایندکس قدیمی به اون منتقل کنیم. ریپلیکیشننرم‌افزار یا سخت‌افزار ما، با هر حد از توانایی، ممکنه گاهی برای لحظاتی دست از همکاری کردن با ما بکشن. برای همین همیشه لازمه که ما مکانیزم‌هایی برای مدیریت بحران در این شرایط در نظر گرفته باشیم. اینجاست که الستیک‌سرچ عزیز با ویژگی Replication یا تکثیر به کمک ما میاد. اینطوری که الستیک‌سرچ از شاردها کپی می‌گیره. شاردی که از اون کپی گرفته شده رو با اسم Primary Shard می‌شناسیم. شاردی که کپی یک شارد دیگه هست رو هم Replica Shard یا Replica صدا می‌کنیم. به یک پرایمری شارد و تمام رپلیکاهای اون هم می‌گیم Replication Group. دو دلیل وجود داره که باعث می‌شه ویژگی رپلیکیشن خیلی مفید باشه:در دسترس بودن: اگر یکی از نودها یا شاردها به هر دلیلی در دسترس نباشه، وجود داشتن رپلیکا باعث می‌شه که ما مجبور نشیم منتظر بمونیم. پس برای این که در صورت بروز مشکل رپلیکیشن بهتر کار کنه، رپلیکاها هیچ وقت روی نودی که پرایمری شارد اونجا ذخیره شده ذخیره نمی‌شن.بهبود پرفورمنس: این دلیل، یا شاید تاثیر رپلیکیشن، وقت اجرای کوئری‌های سرچ دیده می‌شه. وقتی که درخواست‌های هم‌زمان می‌تونن از نسخه‌های متفاوت یک شارد استفاده کنن.تعداد رپلیکاها هم مثل تعداد شاردها هم‌زمان با فرایند ساختن یک ایندکس تعیین می‌شن. به صورت پیش‌فرض، یک کلاستر الستیک‌سرچ که بیش از یک نود داره، برای هر شارد یک رپلیکا می‌سازه. تغییراتی که روی داکیومنت‌ها اعمال می‌ش باید روی همه‌ی شارد‌هایی که اون داکیومنت‌رو دارن اعمال بشن. وگرنه، داده‌هایی که در جواب کوئری‌ها برامون میان قابل اعتماد نیستن. تمام تغییرات، مثل اضافه کردن، حذف کردن، و تغییر دادن داکیومنت‌ها، در مرحله‌ی اول روی پرایمری شارد اجرا می‌شن. پرایمری شارد بعد از اجرا شدن تغییر روی خودش، همون تغییر رو به صورت هم‌زمان برای تمام رپلیکاهاش ارسال می‌کنه. روتینگبعد از این که فهمیدم داکیومنت‌ها چطوری روی اجزای مختلف یه کلاستر ذخیره می‌شن، برام سوال شد که الستیک‌سرچ از کجا می‌دونه که یه داکیومنت رو کجا باید ذخیره کنه؟ یا داکیومنتی که ذخیره شده کجاست؟از طرفی به نظر نمی‌اومد داکیومنت‌ها به صورت تصادفی بین نودها توضیع بشن. چون تصادفی بودن می‌تونه باعث بشه که تعداد داکیومنت‌های ذخیره شده روی نودها خیلی با هم فرق داشته باشن. تشخیص این که هر شارد کجا باید ذخیره بشه یا کجا ذخیره شده به عهده‌ی فرایندیه به اسم «Routing». هر درخواستی که برای یک داکیومنت به الستیک‌سرچ میاد، سیستم روتینگ با یک فرمول ساده تصمیم می‌گیره که باید سراغ کدوم یکی از شاردها بره. به صورت پیش‌فرض، مقدار روتینگ برابر با ID یک داکیومنته. این مقدار وارد یک Hashing Function و تبدیل به یک عدد می‌شه که می‌تونه برای تقسیم استفاده بشه. باقی‌مانده‌ی تقسیم اون عدد به تعداد پرایمری شاردهایی که تو ایندکس وجود دارن شماره‌ی شاردی که باید سراغش بریم رو بهمون می‌ده.shard = hash(routing) % total_primary_shardsبا توجه به این فرایند، معلوم شد که چرا تعداد شاردهای یک ایندکس نمی‌تونن بعد از ساخته شدن تغییر کنن. فرض کنید ما تعداد شاردهامون ۵ تا باشه و با این تعداد یه سری داکیومنت رو ذخیره کنیم. حالا اگه تعداد شاردها تغییر کنه، مقدار به دست اومده از فرمول روتینگ هم تغییر می‌کنه و داکیومنت‌های قدیمیمون دیگه در دسترس نیستن. دیوانه‌کننده‌س.چند خط بالاتر گفتم «به صورت پیش‌فرض». این یعنی این که فرایند روتینگ می‌تونه شخصی‌سازی بشه. که البته فرایند پیچیده‌ایه. شاید بعدن سراغ اون هم رفتیم.نکته‌ای که نباید فراموش کنیم اینه که فرایندی که ذکر شد برای زمانیه که ما با دقیقن یک داکیومنت کار داریم. ولی وقتی که داریم یه کوئری جست‌و‌جو رو اجرا می‌کنیم، کوئری بین تمام شاردها پخش، یا به عبارت دقیق‌تر Broadcast می‌شه. امی‌تیس یوسفی امی‌تیس یوسفی Sat, 25 Jan 2020 16:06:00 +0330 https://virgool.io/@emitis/elastic-search-from-the-very-first-1-qp30olimys44 روزی روزگاری، بعد از مدت‌ها که، بنا به نیازهام، هر بار یه قسمت از الستیک‌سرچ رو یاد گرفته بودم و کارم رو راه انداخته بودم، تصمیم گرفتم که به خودم بیام و از اول، خیلی اول،‌ شروع کنم به مطالعه راجع بهش.تو این مطلب و چندتا مطلب بعد قراره چیزایی که یاد گرفتم رو به اشتراک بذارم.در مرحله‌ی اول لازم بود که بفهمم الستیک‌سرچ چه دردهایی از ما دوا می‌کنه.الستیک‌سرچ یک ابزار تجزیه و تحلیل و یک موتور جست‌و‌جوی تمام‌متن و متن‌باز است.همونطور که از اسمش مشخصه، معروف‌ترین و مهم‌ترین کاربرد الستیک‌سرچ، جست‌و‌جو و هر چیزی مربوط به اونه. اما این تنها کاری نیست که الستیک‌سرچ می‌تونه برامون انجام بده.الستیک‌سرچ داده‌ها رو در قالب داکیومنت‌ها (Documents) ذخیره می‌کنه.برای مثال، اگر با پایگاه‌های داده‌ی رابطه‌ای (Relational Databases) آشنا باشید، هر داکیومنت در الستیک‌سرچ شبیه به یک سطر در پایگاه داده است.اطلاعات داکیومنت‌ها در فیلد‌ها (Fields) ذخیره می‌شن.هر فیلد در الستیک‌سرچ رو شاید بشه به عنوان هر ستون در پایگاه داده در نظر گرفت.این وسط به لیستی از کمپانی‌های معروفی که از الستیک‌سرچ برای جست‌و‌جوهاشون استفاده می‌کنن هم رسیدم:GithubFacebookNetflixSoundcloudAdobeFirefoxWikiMediaStackExchangeFourSquareاستک الستیک (Elastic Stack)استک الستیک از تکنولوژی‌هایی تشکیل می‌شه که توسط شرکت حامی الستیک‌سرچ (Elasticsarch BV) ارائه می‌شن.کیبانا (Kibana): کیبانا می‌تونه به عنوان داشبورد الستیک‌سرچ معرفی بشه. ابزاری که به ما کمک می‌کنه تا داده‌های الستیک‌سرچ رو تصویری کنیم و اونا رو آنالیز کنیم تا بتونیم درک بهتری ازشون داشته باشیم.لاگستش (Logstash): معروف‌ترین و قدیمی‌ترین کاربرد لاگستش دریافت لاگ‌ها از اپلیکیشن و ارسال اون‌ها به الستیک‌سرچ بوده و هست. ولی لاگستش کاربردهای دیگه‌ای هم داره. برای مثال، لاگس‌تش می‌تونه لاگ‌ها رو به عنوان «رویداد» از ورودی‌های متفاوت بگیره، اون‌ها رو پردازش کنه، و به خروجی‌های مختلف بفرسته.ایکس‌پک (X-Pack): ایکس‌پک، در واقع، یک پک از ویژگی‌هاست که کاربردهایی رو به استک الستیک اضافه می‌کنه. مهم‌ترین اون‌ها امنیت، مانیتورینگ، هشدار، گزارش‌گیری، ماشین لرنینگ، گراف، و ویژگی جالب Elasticsearch SQL هستن.بیتس (Beats): بر اساس چیزهایی که یاد گرفتم، بیتس مجموعه‌ای از حمل‌کننده‌های داده‌ست که با اون‌ها می‌شه داده‌ها رو به لاگستش یا خود الستیک‌سرچ فرستاد. انواع مختلفی از این حمل‌کننده‌ها برای انواع مختلف داده وجود داره.مطالب بعدی‌ای که یاد بگیرم رو تو قسمت‌های بعدی این پست باهاتون به اشتراک می‌ذارم.ممنون که منو می‌خونید. امی‌تیس یوسفی امی‌تیس یوسفی Sat, 16 Nov 2019 12:41:30 +0330 https://virgool.io/snappmarket/whitehouse-standrads-e3toksrmtsrv عنوان عجیبیه، ولی واقعیه. برای این که بتونیم این عنوان عجیب رو با هم درک کنیم می‌خوام از یه خاطره‌ی مشترک شروع کنم. من، و شاید خیلی از شما، توی تیم‌هایی کار کردیم که توسعه‌دهنده‌های قسمت‌های مختلفش با هم اختلافاتی در مورد نحوه‌ی پیاده‌سازی داشته‌ن. این اختلافات معمولن مسائل مرگ‌باری نیستن و به راحتی حل می‌شن. اما اگه یه کم توی روند حل شدن این اختلافات ریز بشیم متوجه می‌شیم جایی که این اختلافات شروع به حل شدن می‌کنن دقیقن همون جاییه که یه سری قرارداد نانوشته بین اعضا تصویب می‌شه. قراردادهایی که همه، یا لااقل بیشتر افراد، باهاش موافقن. این اتفاق می‌تونه دقیقن معنی تعریف شدن یک «استاندارد» در تیم باشه. خب. تا اینجا که همه چیز خیلی طبیعیه. اما یه زمانی سفر کردن با شتر هم طبیعی بوده. منظورم اینه که همه‌ی تغییراتی که بشر در طول تاریخ ایجاد کرده لزومن برای حل کردن مشکلات نبوده. خیلی از این تغییرات ایجاد شده‌ن که تا کاری که قبلن انجام می‌شده رو راحت‌تر کنن.استانداردهای عمومی (در مقابل استانداردهای درون‌سازمانی) یکی از همین تغییراته. من به عنوان یک توسعه‌دهنده خیلی خوشحال‌تر خواهم بود اگر با دونستن یک یا چند استاندارد بتونم با تیم‌های مختلف کار کنم. با همین استانداردها بعد از هر جا‌به‌جایی بتونم به زودی به تیم جدیدم اضافه بشم. با همین استانداردها بتونم آموزش‌های بهتری رو منتشر یا دریافت کنم. امیدوارم تا الان برای همه‌مون به اندازه‌ی کافی مشخص شده باشه که وجود داشتن استانداردها در عالم برنامه‌نویسی چقدر می‌تونه به راحت‌تر شدن روابط بین توسعه‌دهنده‌ها کمک کنه.استاندارد کاخ سفید مجوعه‌ای از پیشنهادهاست که برای API ها و بر پایه‌ی REST تعریف شده. این استاندارد تمام حالت‌هایی که من و هم‌تیمی‌هام تا الان باهاش برخورد داشتیم رو پوشش می‌ده. از طرفی تعریفش خیلی ساده‌ست و توی چند جمله می‌شه برای هر آدم جدیدی توضیحش داد.اما بعد از تجربه‌ی خوب اولین پروژه‌ای که با این استاندارد کار کردم، رقص‌کنان رفتم سراغ پیاده‌سازیش روی پروژه‌ی بعدی. اینجا بود که دیدم ای دل غافل. توی پروژه‌ی قبلی کلی کد نوشته بودم که پیاده‌سازی این استاندارد رو راحت کنم. حالا باید همه رو از اونجا کپی کنم و توی پروژه‌ی جدید استفاده کنم. اگر شما هم مثل من از کپی کردن کد متنفر باشید حتمن متوجه می‌شید که در اون لحظه چه غمی رو روی شونه‌هام حس کردم. طبیعتن سعی کردم بگردم ببینم آیا همکاران مهربونم در گوشه‌ای از این کره‌ی خاکی چرخی رو اختراع کرده‌ن که من روی دوچرخه‌م نصب کنم یا نه. بعد از کلی تلاش، لاقل برای ابزارهایی که خودم ازشون استفاده می‌کردم کتابخونه‌ای پیدا نکردم که پیاده‌سازی این استاندارد رو برام انجام بده. این شد که کمر همت رو بستم و دو تا کتابخونه برای این کار نوشتم. اولیش یه کتابخونه‌ برای پیاده‌سازی استاندارد کاخ سفید با زبان PHP بود. که اون رو از اینجا می‌تونید پیدا کنید. بعد هم یه کتابخونه‌ی دیگه برای همین کار روی فریم‌ورک لاراول که از اینجا در دسترسه. خودم و همکاران خوبم در اسنپ‌مارکت اولین استفاده‌کننده‌های این کتابخونه‌ها بودیم. برای استفاده از این کتابخونه‌ها چیزی بیشتر از راهنمای خودشون ندارم که اینجا بنویسم. ولی اگر هر کدوم از شما خواستید ازشون استفاده کنید و هر چیزی برای بهتر شدنشون به ذهنتون رسید، من خیلی خوشحال می‌شم که بهم بگید. امی‌تیس یوسفی امی‌تیس یوسفی Wed, 21 Aug 2019 17:05:44 +0430