هی هابر! نام من ماکسیم واسیلیف است، من به عنوان یک تحلیلگر و مدیر پروژه در FINCH کار می کنم. امروز می خواهم به شما بگویم که چگونه با استفاده از ElasticSearch توانستیم 15 میلیون درخواست را در 6 دقیقه پردازش کنیم و بارهای روزانه را در سایت یکی از مشتریان خود بهینه کنیم. متأسفانه، ما مجبوریم بدون نام کار کنیم، زیرا ما NDA داریم، امیدواریم محتوای مقاله از این آسیب نبیند. بیا بریم.
پروژه چگونه کار می کند
در باطن خود، ما خدماتی را ایجاد می کنیم که عملکرد وب سایت ها و برنامه تلفن همراه مشتری ما را تضمین می کند. ساختار کلی را می توان در نمودار مشاهده کرد:
در فرآیند کار، تعداد زیادی تراکنش را پردازش می کنیم: خریدها، پرداخت ها، عملیات با موجودی کاربر، که برای آنها لاگ های زیادی ذخیره می کنیم، همچنین این داده ها را وارد و صادر می کنیم به سیستم های خارجی.
همچنین زمانی که داده ها را از مشتری دریافت می کنیم و به کاربر منتقل می کنیم، فرآیندهای معکوس وجود دارد. علاوه بر این، هنوز فرآیندهایی برای کار با پرداخت ها و برنامه های پاداش وجود دارد.
پیشینه مختصر
در ابتدا، ما از PostgreSQL به عنوان تنها ذخیره داده استفاده کردیم. مزایای استاندارد آن برای DBMS: وجود تراکنش ها، زبان نمونه گیری داده توسعه یافته، طیف وسیعی از ابزارها برای یکپارچه سازی. همراه با عملکرد خوب، نیازهای ما را برای مدت طولانی برآورده کرد.
ما کاملاً تمام داده ها را در Postgres ذخیره کردیم: از معاملات گرفته تا اخبار. اما تعداد کاربران و همراه با آن تعداد درخواست ها افزایش یافت.
برای درک، تعداد جلسات سالانه در سال 2017 فقط در سایت دسکتاپ 131 میلیون است. در سال 2018 - 125 میلیون. 2019 دوباره 130 میلیون. 100-200 میلیون دیگر از نسخه موبایل سایت و برنامه موبایل اضافه کنید و شما تعداد زیادی درخواست دریافت خواهد کرد.
با رشد پروژه، Postgres از مقابله با بار منصرف شد، ما وقت نداشتیم - تعداد زیادی پرس و جوهای مختلف ظاهر شد که برای آنها نتوانستیم تعداد کافی شاخص ایجاد کنیم.
ما متوجه شدیم که نیاز به ذخیره‌های داده دیگری وجود دارد که نیازهای ما را تامین کنند و بار PostgreSQL را بردارند. Elasticsearch و MongoDB به عنوان گزینه های ممکن در نظر گرفته شدند. دومی در امتیازهای زیر شکست خورد:
- با افزایش حجم داده ها در ایندکس ها، سرعت نمایه سازی کند است. با Elastic، سرعت به مقدار داده بستگی ندارد.
- بدون جستجوی متن کامل
بنابراین ما الاستیک را برای خود انتخاب کردیم و برای انتقال آماده شدیم.
انتقال به الاستیک
1. ما انتقال از خدمات جستجوی نقطه فروش را آغاز کردیم. مشتری ما در مجموع حدود 70 نقطه فروش دارد و این به چندین نوع جستجو در سایت و برنامه نیاز دارد:
- جستجوی متن بر اساس نام شهر
- جست و جوی جغرافیایی در یک شعاع معین از نقطه ای. به عنوان مثال، اگر کاربر بخواهد ببیند کدام مراکز فروش به خانه او نزدیکتر هستند.
- جستجو بر اساس مربع داده شده - کاربر مربعی را روی نقشه ترسیم می کند و تمام نقاط این شعاع به او نشان داده می شود.
- جستجو بر اساس فیلترهای اضافی نقاط فروش در دسته بندی با یکدیگر متفاوت هستند
اگر در مورد سازمان صحبت کنیم، در Postgres هم برای نقشه و هم برای اخبار یک منبع داده داریم و در Elastic Snapshot ها از داده های اصلی گرفته می شوند. واقعیت این است که در ابتدا Postgres نتوانست با همه معیارها با جستجو کنار بیاید. نه تنها فهرست های زیادی وجود داشت، بلکه می توانستند با هم همپوشانی داشته باشند، بنابراین زمان بندی Postgres گم شد و متوجه نشد از کدام شاخص استفاده کند.
2. ردیف بعدی بخش اخبار بود. انتشارات هر روز در سایت ظاهر می شوند تا کاربر در جریان اطلاعات گم نشود، داده ها باید قبل از صدور مرتب شوند. جستجو برای این است: شما می توانید سایت را با مطابقت متن جستجو کنید، و در عین حال فیلترهای اضافی را متصل کنید، زیرا آنها نیز از طریق Elastic ساخته می شوند.
3. سپس پردازش تراکنش را منتقل کردیم. کاربران می توانند محصول خاصی را در سایت خریداری کنند و در قرعه کشی جوایز شرکت کنند. پس از چنین خریدهایی، ما حجم زیادی از داده ها را پردازش می کنیم، به خصوص در تعطیلات آخر هفته و تعطیلات. برای مقایسه، اگر در روزهای عادی تعداد خریدها بین 1,5-2 میلیون باشد، در تعطیلات این رقم می تواند به 53 میلیون برسد.
در عین حال، داده ها باید در کوتاه ترین زمان ممکن پردازش شوند - کاربران دوست ندارند چندین روز منتظر نتیجه باشند. هیچ راهی برای دستیابی به چنین مهلت‌هایی از طریق Postgres وجود ندارد - ما اغلب قفل‌هایی دریافت می‌کردیم و در حالی که در حال پردازش همه درخواست‌ها بودیم، کاربران نمی‌توانستند بررسی کنند که آیا جوایزی را دریافت کرده‌اند یا خیر. این برای تجارت چندان خوشایند نیست، بنابراین پردازش را به Elasticsearch منتقل کردیم.
دوره ای
اکنون به‌روزرسانی‌ها براساس شرایط زیر پیکربندی می‌شوند:
- نقاط فروش. به محض دریافت اطلاعات از یک منبع خارجی، بلافاصله به روز رسانی را شروع می کنیم.
- اخبار. به محض ویرایش هر خبری در سایت، به صورت خودکار به الاستیک ارسال می شود.
در اینجا دوباره باید به مزایای الاستیک اشاره کرد. در Postgres هنگام ارسال درخواست باید منتظر بمانید تا صادقانه تمام رکوردها را پردازش کند. شما می توانید 10 رکورد را به الاستیک ارسال کنید و بلافاصله شروع به کار کنید، بدون اینکه منتظر بمانید تا رکوردها در همه Shards توزیع شوند. البته ممکن است برخی از Shard یا Replica بلافاصله داده ها را نبینند، اما همه چیز خیلی زود در دسترس خواهد بود.
روش های یکپارچه سازی
2 راه برای ادغام با Elastic وجود دارد:
- از طریق یک کلاینت بومی از طریق TCP. درایور بومی به تدریج در حال از بین رفتن است: دیگر پشتیبانی نمی شود، نحو بسیار ناخوشایندی دارد. بنابراین عملاً از آن استفاده نمی کنیم و سعی می کنیم کاملاً آن را کنار بگذاریم.
- از طریق یک رابط HTTP که می تواند از درخواست های JSON و نحو Lucene استفاده کند. آخرین مورد یک موتور متن است که از Elastic استفاده می کند. در این نسخه، ما توانایی Batch کردن از طریق درخواست‌های JSON از طریق HTTP را داریم. این گزینه ای است که ما سعی می کنیم از آن استفاده کنیم.
به لطف رابط HTTP، می‌توانیم از کتابخانه‌هایی استفاده کنیم که اجرای ناهمزمان مشتری HTTP را ارائه می‌دهند. ما می‌توانیم از مزیت Batch و API ناهمزمان بهره ببریم، که منجر به عملکرد بالا می‌شود، که در روزهای تبلیغات بزرگ کمک زیادی کرد (در ادامه در مورد آن بیشتر توضیح می‌دهیم)
چند عدد برای مقایسه:
- ذخیره کاربران Bounty Postgres در 20 رشته بدون گروه بندی: 460713 رکورد در 42 ثانیه
- کلاینت الاستیک + واکنشی برای 10 رشته + دسته برای 1000 عنصر: 596749 رکورد در 11 ثانیه
- کلاینت الاستیک + واکنشی برای 10 رشته + دسته برای 1000 عنصر: 23801684 ورودی در 4 دقیقه
اکنون یک مدیر درخواست HTTP نوشته‌ایم که JSON را به‌عنوان Batch/not Batch می‌سازد و آن را از طریق هر مشتری HTTP، بدون توجه به کتابخانه ارسال می‌کند. همچنین می توانید درخواست ها را به صورت همزمان یا ناهمزمان ارسال کنید.
در برخی از ادغام ها، ما هنوز از مشتری حمل و نقل رسمی استفاده می کنیم، اما این فقط به بازسازی بعدی مربوط می شود. در این مورد، یک کلاینت سفارشی که بر اساس Spring WebClient ساخته شده است برای پردازش استفاده می شود.
تبلیغ بزرگ
یک بار در سال، این پروژه میزبان یک تبلیغ بزرگ برای کاربران است - این همان Highload است، زیرا در این زمان ما با ده ها میلیون کاربر به طور همزمان کار می کنیم.
معمولاً اوج بار در تعطیلات رخ می دهد، اما این ارتقا در سطح کاملاً متفاوتی است. پارسال در روز تبلیغات، 27 واحد کالا فروختیم. داده ها بیش از نیم ساعت پردازش شد که باعث ناراحتی کاربران شد. کاربران برای شرکت جوایزی دریافت کردند، اما مشخص شد که این روند باید تسریع شود.
در ابتدای سال 2019، تصمیم گرفتیم که به ElasticSearch نیاز داریم. برای یک سال تمام، پردازش داده های دریافتی را در الاستیک و صدور آنها در api اپلیکیشن موبایل و وب سایت سازماندهی کردیم. در نتیجه، سال بعد در طول کمپین، ما پردازش کردیم 15 ورودی در 131 دقیقه.
از آنجایی که ما افراد زیادی داریم که می خواهند کالا بخرند و در قرعه کشی جوایز در تبلیغات شرکت کنند، این اقدام موقتی است. اکنون در حال ارسال اطلاعات به روز به الاستیک هستیم، اما در آینده قصد داریم اطلاعات بایگانی شده ماه های گذشته را به عنوان ذخیره دائمی به Postgres منتقل کنیم. برای اینکه شاخص الاستیک مسدود نشود که این نیز محدودیت هایی دارد.
نتیجه گیری / نتیجه گیری
در حال حاضر تمام سرویس هایی را که می خواستیم به الاستیک منتقل کرده ایم و فعلاً در این مورد مکث کرده ایم. اکنون ما در حال ایجاد یک فهرست در Elastic در بالای ذخیره‌سازی ثابت اصلی در Postgres هستیم که بار کاربر را به عهده می‌گیرد.
در آینده، اگر متوجه شویم که درخواست داده بسیار متنوع می شود و تعداد نامحدودی از ستون ها جستجو می شود، قصد داریم خدمات را انتقال دهیم. این دیگر وظیفه ای برای Postgres نیست.
اگر به جستجوی متن کامل در عملکرد نیاز داریم یا اگر معیارهای جستجوی زیادی داریم، از قبل می‌دانیم که این باید به Elastic ترجمه شود.
⌘⌘⌘
با تشکر برای خواندن. اگر شرکت شما نیز از ElasticSearch استفاده می کند و موارد پیاده سازی خاص خود را دارد، به ما بگویید. جالب خواهد بود که بدانید دیگران چگونه هستند 🙂
منبع: www.habr.com