اې حبره! زما نوم ماکسیم واسیلیف دی، زه په FINCH کې د شنونکي او پروژې مدیر په توګه کار کوم. نن زه غواړم تاسو ته ووایم چې څنګه د ElasticSearch په کارولو سره، موږ وکولی شو په 15 دقیقو کې 6 ملیون غوښتنې پروسس کړو او زموږ د یو پیرودونکي سایټ کې ورځني بارونه اصلاح کړو. له بده مرغه، موږ به د نومونو پرته کار وکړو، ځکه چې موږ NDA لرو، موږ هیله لرو چې د مقالې محتوا به له دې څخه رنځ نه وي. مخکې شه.
پروژه څنګه کار کوي
زموږ په پس منظر کې، موږ خدمتونه رامینځته کوو چې زموږ د پیرودونکي ویب پا andو او ګرځنده غوښتنلیک فعالیت تضمینوي. عمومي جوړښت په انځور کې لیدل کیدی شي:
د کار په جریان کې، موږ ډیری لیږدونه پروسس کوو: پیرود، تادیات، د کاروونکي بیلانس سره عملیات، د کوم لپاره چې موږ ډیری لاګونه ذخیره کوو، په بیله بیا دا ډاټا بهرنیو سیسټمونو ته وارد او صادروو.
برعکس پروسې هم شتون لري کله چې موږ د پیرودونکي څخه معلومات ترلاسه کوو او کارونکي ته یې لیږدوو. سربیره پردې ، لاهم د تادیاتو او بونس برنامو سره کار کولو پروسې شتون لري.
لنډ پس منظر
په پیل کې، موږ PostgreSQL یوازې د ډیټا ذخیره په توګه کاروو. د DBMS لپاره د دې معیاري ګټې: د معاملو شتون، د ډیټا نمونې کولو ژبه، د ادغام لپاره د وسایلو پراخه لړۍ؛ د ښه فعالیت سره یوځای د اوږدې مودې لپاره زموږ اړتیاوې پوره کړې.
موږ په بشپړ ډول ټول معلومات په پوسټګریس کې زیرمه کړل: له معاملو څخه خبرونو ته. مګر د کاروونکو شمیر وده وکړه، او د هغې سره د غوښتنو شمیر.
د پوهیدو لپاره، په 2017 کې د غونډو کلنۍ شمیر یوازې په ډیسټاپ سایټ کې 131 ملیون دی. په 2018 کې - 125 ملیون. په 2019 کې بیا 130 ملیون. د سایټ د ګرځنده نسخه او د ګرځنده اپلیکیشن څخه 100-200 ملیون نور اضافه کړئ، او تاسو ډیر شمیر غوښتنې به ترلاسه کړي.
د پروژې د ودې سره، پوسټګریس د بار سره مقابله بنده کړه، موږ وخت نه درلود - د مختلفو پوښتنو لوی شمیر څرګند شو، د کوم لپاره چې موږ نشو کولی د کافي شمیر شاخصونه رامینځته کړو.
موږ پوهیږو چې د نورو ډیټا پلورنځیو ته اړتیا وه چې زموږ اړتیاوې به چمتو کړي او د PostgreSQL څخه بار واخلي. Elasticsearch او MongoDB د ممکنه اختیارونو په توګه وګڼل شول. وروستی په لاندې ټکو کې له لاسه ورکړ:
- د شاخص کولو سرعت ورو کوي لکه څنګه چې په شاخصونو کې د معلوماتو مقدار وده کوي. د لچکدار سره، سرعت د معلوماتو مقدار پورې اړه نلري.
- د بشپړ متن لټون نشته
نو موږ د ځان لپاره لچک غوره کړ او د لیږد لپاره چمتو شو.
لچک ته لیږد
1. موږ د پلور د لټون خدمت څخه لیږد پیل کړ. زموږ پیرودونکی د پلور شاوخوا 70 ټکي لري، او دا په سایټ او غوښتنلیک کې څو ډوله لټونونو ته اړتیا لري:
- د ښار په نوم د متن لټون
- جیوسرچ د ځینې نقطې څخه د ورکړل شوي وړانګو دننه. د مثال په توګه، که کاروونکي غواړي وګوري چې د پلور کوم ټکي د هغه کور ته نږدې دي.
- د ورکړل شوي مربع لخوا لټون وکړئ - کارونکي په نقشه کې مربع راښکاره کوي، او په دې وړانګو کې ټول ټکي هغه ته ښودل شوي.
- د اضافي فلټرونو لخوا لټون وکړئ. د خرڅلاو ټکي له یو بل څخه په ترتیب کې توپیر لري
که موږ د سازمان په اړه وغږیږو، نو په پوسټګریس کې موږ د نقشې او خبرونو دواړو لپاره د معلوماتو سرچینه لرو، او په لچک لرونکي سنیپ شاټونو کې د اصلي معلوماتو څخه اخیستل شوي. حقیقت دا دی چې په پیل کې پوسټګریس نشي کولی د ټولو معیارونو لخوا د لټون سره مقابله وکړي. نه یوازې دلته ډیری شاخصونه شتون درلود ، دوی کولی شي ډیر شي ، نو د پوسټګریس مهالویش ورک شوی او نه پوهیږي چې کوم شاخص وکاروئ.
2. په بله کرښه کې د خبرونو برخه وه. خپرونې هره ورځ په سایټ کې څرګندیږي ترڅو کاروونکي د معلوماتو په جریان کې له لاسه ورنکړي ، معلومات باید د خپرولو دمخه ترتیب شي. دا هغه څه دي چې لټون د دې لپاره دی: تاسو کولی شئ سایټ د متن میچ له لارې وپلټئ، او په ورته وخت کې اضافي فلټرونه وصل کړئ، ځکه چې دوی د لچکدار له لارې هم جوړ شوي.
3. بیا موږ د لیږد پروسس کولو ته حرکت ورکړ. کاروونکي کولی شي په سایټ کې یو مشخص محصول واخلي او د جایزې په قرعه کې برخه واخلي. د داسې پیرودلو وروسته، موږ د ډیټا لوی مقدار پروسس کوو، په ځانګړې توګه د اونۍ په پای او رخصتیو کې. د پرتله کولو لپاره، که په عادي ورځو کې د پیرود شمیر د 1,5-2 ملیون ترمنځ وي، نو بیا په رخصتیو کې دا شمیره 53 ملیون ته رسیدلی شي.
په ورته وخت کې، ډاټا باید په لنډ ممکن وخت کې پروسس شي - کاروونکي نه خوښوي چې د څو ورځو لپاره پایلې ته انتظار وکړي. د پوسټګریس له لارې د ورته وخت نیټې ترلاسه کولو لپاره هیڅ لاره شتون نلري - موږ ډیری وختونه تالاشۍ ترلاسه کړې ، او پداسې حال کې چې موږ ټولې غوښتنې پروسس کوو ، کارونکي نشي کولی وګوري چې ایا دوی انعامونه ترلاسه کړي که نه. دا د سوداګرۍ لپاره خورا خوندور ندی ، نو موږ پروسس کولو ته ایلسټیسټیرک ته واړوو.
موده
اوس تازه معلومات د لاندې شرایطو سره سم د پیښې پراساس تنظیم شوي:
- د خرڅلاو ټکي. هرڅومره ژر چې موږ د بهرنۍ سرچینې څخه معلومات ترلاسه کړو، موږ سمدلاسه یو تازه پیل کوو.
- خبرونه. هرڅومره ژر چې په سایټ کې کوم خبر ایډیټ شي ، دا په اوتومات ډول لچک ته لیږل کیږي.
دلته یو ځل بیا د لچک وړ ګټو یادونه اړینه ده. په پوسټګریس کې، کله چې غوښتنه لیږل کیږي، تاسو باید انتظار وکړئ تر هغه چې دا په صادقانه توګه ټول ریکارډونه پروسس کړي. تاسو کولی شئ 10 ریکارډونه Elastic ته واستوئ او سمدلاسه کار پیل کړئ، پرته لدې چې ریکارډونو ته په ټولو شارډونو ویشل شي انتظار وکړئ. البته، ځینې شارډ یا ریپلیکا ممکن سمدلاسه معلومات ونه ګوري، مګر هرڅه به ډیر ژر شتون ولري.
د ادغام میتودونه
د لچکدار سره یوځای کولو لپاره 2 لارې شتون لري:
- د TCP په اړه د اصلي پیرودونکي له لارې. اصلي ډرایور په تدریج سره مړ کیږي: دا نور ملاتړ نه کوي، دا خورا ناامنه ترکیب لري. له همدې امله، موږ په عملي توګه دا نه کاروو او هڅه کوو چې دا په بشپړه توګه پریږدو.
- د HTTP انٹرفیس له لارې چې کولی شي د JSON غوښتنې او لوسین ترکیب دواړه وکاروي. وروستی یو د متن انجن دی چې لچکدار کاروي. پدې نسخه کې، موږ د HTTP په اړه د JSON غوښتنو له لارې د بیچ کولو وړتیا ترلاسه کوو. دا هغه اختیار دی چې موږ یې د کارولو هڅه کوو.
د HTTP انٹرفیس څخه مننه، موږ کولی شو هغه کتابتونونه وکاروو چې د HTTP مراجعینو غیر متناسب تطبیق چمتو کوي. موږ کولی شو د بیچ او غیر متمرکز API څخه ګټه واخلو، کوم چې د لوړ فعالیت پایله لري، کوم چې د لوی ترویج په ورځو کې ډیره مرسته کړې (لاندې نور یې)
د پرتله کولو لپاره ځینې شمیرې:
- د پوسټګریس فضل کاروونکي په 20 تارونو کې پرته له ګروپ کولو خوندي کول: په 460713 ثانیو کې 42 ریکارډونه
- د 10 تارونو لپاره لچک لرونکي + عکس العمل پیرودونکي + د 1000 عناصرو لپاره بیچ: په 596749 ثانیو کې 11 ریکارډونه
- د 10 تارونو لپاره لچک لرونکي + عکس العمل پیرودونکي + د 1000 عناصرو لپاره بیچ: په 23801684 دقیقو کې 4 ریکارډونه
اوس موږ د HTTP غوښتنې مدیر لیکلی چې JSON د بیچ / نه بیچ په توګه رامینځته کوي او د کتابتون په پام کې نیولو پرته د کوم HTTP پیرودونکي له لارې یې لیږي. تاسو کولی شئ په همغږي یا غیر متناسب ډول غوښتنې واستوئ.
په ځینو ادغامونو کې، موږ لاهم د رسمي ټرانسپورټ پیرودونکی کاروو، مګر دا یوازې د راتلونکي ریفکتور کولو مسله ده. په دې حالت کې، د پسرلي ویب کلینټ پر بنسټ جوړ شوی دودیز مراجع د پروسس لپاره کارول کیږي.
لوی ترویج
په کال کې یو ځل، پروژه د کاروونکو لپاره لوی ترویج کوربه کوي - دا ورته هایلوډ دی، ځکه چې پدې وخت کې موږ په ورته وخت کې د لسګونو ملیون کاروونکو سره کار کوو.
معمولا د بارونو لوړوالی د رخصتیو په جریان کې پیښیږي ، مګر دا ترویج په بشپړ ډول مختلف کچې کې دی. تیر کال، د ترویج په ورځ، موږ 27 واحدونه توکي پلورلي وو. معلومات د نیم ساعت څخه ډیر وخت لپاره پروسس شوي، کوم چې د کاروونکو لپاره ناامني رامنځته کړې. کاروونکو د ګډون لپاره جایزې ترلاسه کړې، مګر دا څرګنده شوه چې پروسه باید ګړندۍ شي.
د 2019 په پیل کې، موږ پریکړه وکړه چې موږ د ElasticSearch ته اړتیا لرو. د ټول کال لپاره، موږ د ترلاسه شویو معلوماتو پروسس په لچکدار کې تنظیم کړ او د ګرځنده غوښتنلیک او ویب پاڼې په api کې یې صادرول. د پایلې په توګه، راتلونکی کال د کمپاین په جریان کې، موږ پروسس کړ په 15 دقیقو کې 131 ننوتل.
څنګه چې موږ ډیری خلک لرو چې غواړي توکي واخلي او په ترویجونو کې د جایزو په رسم کولو کې برخه واخلي ، دا یو لنډمهاله اقدام دی. اوس موږ تازه معلومات Elastic ته لیږو، مګر په راتلونکي کې موږ پالن لرو چې د تیرو میاشتو آرشیف شوي معلومات د دایمي ذخیره په توګه پوسټګریس ته انتقال کړو. د دې لپاره چې د لچک شاخص بند نشي، کوم چې خپل محدودیتونه هم لري.
پایله/ پایله
په اوس وخت کې، موږ ټول هغه خدمتونه چې موږ یې غوښتل Elastic ته لیږدول شوي او د اوس لپاره یې ځنډولي دي. اوس موږ په پوسټګریس کې د اصلي دوامداره ذخیره کولو په سر کې په لچک کې یو شاخص رامینځته کوو ، کوم چې د کارونکي بار اخلي.
په راتلونکي کې، موږ پالن لرو چې خدمات انتقال کړو که چیرې موږ پوه شو چې د معلوماتو غوښتنه خورا متنوع کیږي او د لامحدود شمیر کالمونو لپاره لټون کیږي. دا نور د پوسټګریس لپاره دنده نه ده.
که موږ په فعالیت کې د بشپړ متن لټون ته اړتیا ولرو یا که موږ د لټون ډیری مختلف معیارونه ولرو، نو موږ دمخه پوهیږو چې دا اړتیا په لچک کې ژباړل کیږي.
⌘⌘⌘
د لوستلو لپاره مننه. که ستاسو شرکت هم ElasticSearch کاروي او ستاسو د پلي کولو قضیې لري، مهرباني وکړئ موږ ته ووایاست. دا به په زړه پورې وي چې پوه شئ چې نور څنګه کوي :)
سرچینه: www.habr.com