TL؛ DR: څلور کاله دمخه ما د نوي سرور څارنې وسیلې لپاره د نظر سره ګوګل پریښود. نظر دا و چې معمولا جلا شوي دندې په یو خدمت کې یوځای کړي ټولګه او د ننوتلو تحلیل، د میټریک راټولول، خبرتیاوې او ډشبورډونه. یو له اصولو څخه دا دی چې خدمت باید واقعیا وي چټک، د یو اسانه ، متقابل ، خوندورې تجربې سره ډیوپس چمتو کوي. دا اړتیا لري د څو ګیګابایټ ډیټا سیټونو پروسس کولو لپاره د یوې ثانیې په برخو کې پداسې حال کې چې په بودیجه کې پاتې کیږي. د لاګ مدیریت موجوده وسیلې اکثرا ورو او پیچلي وي ، نو موږ د یوې ښې ننګونې سره مخ یو: په هوښیار ډول د یوې وسیلې ډیزاین کول ترڅو کاروونکو ته نوې تجربه ورکړي.

دا مقاله تشریح کوي چې څنګه موږ په سکالر کې دا ستونزه د زاړه ښوونځي میتودونو پلي کولو سره حل کړه ، د ځواک ځواک چلند ، د غیر ضروري پرتونو له مینځه وړو او د پیچلو ډیټا جوړښتونو څخه مخنیوی. تاسو کولی شئ دا درسونه په خپلو انجینري ستونزو کې پلي کړئ.

د زاړه ښوونځي ځواک

د ننوتلو تحلیل معمولا د لټون سره پیل کیږي: ټول هغه پیغامونه ومومئ چې د یو ځانګړي نمونې سره سمون لري. په سکالر کې، دا د ډیری سرورونو څخه لسګونه یا سلګونه ګیګابایټ لاګونه دي. عصري طریقې، د یوې قاعدې په توګه، د ځینې پیچلي ډیټا جوړښت جوړول شامل دي چې د لټون لپاره غوره شوي. ما یقینا دا په ګوګل کې لیدلی، چیرې چې دوی په دې ډول شیانو کې خورا ښه دي. مګر موږ په خورا سخت چلند کې میشته شو: د لاګونو خطي سکین کول. او دا کار وکړ - موږ د لټون وړ انٹرفیس چمتو کوو چې زموږ د سیالانو په پرتله ګړندۍ حکمونه دي (په پای کې انیمیشن وګورئ).

کلیدي بصیرت دا و چې عصري پروسیسرونه واقعیا په ساده ، مستقیم عملیاتو کې خورا ګړندي دي. دا په پیچلي، څو پرتونو سیسټمونو کې له لاسه ورکول اسانه دي چې په I/O سرعت او د شبکې عملیاتو تکیه کوي، کوم چې نن ورځ خورا عام دي. نو موږ داسې ډیزاین رامینځته کړ چې پرتونه او اضافي کثافات کموي. په موازي ډول د ډیری پروسیسرونو او سرورونو سره، د لټون سرعت په یوه ثانیه کې 1 TB ته رسیږي.

د دې مقالې کلیدي ټکي:

• د وحشي ځواک لټون د حقیقي نړۍ، لوی پیمانه ستونزو د حل لپاره یو ګټور طریقه ده.
• وحشي ځواک د ډیزاین تخنیک دی، نه د کار وړ حل. د هر تخنیک په څیر، دا د نورو په پرتله د ځینو ستونزو لپاره غوره دی، او په کمزوري یا ښه توګه پلي کیدی شي.
• وحشي ځواک په ځانګړې توګه د لاسته راوړلو لپاره ښه دی باثباته فعالیت
• د وحشي ځواک مؤثره کارول د کوډ اصلاح کولو او په مناسب وخت کې د کافي سرچینو پلي کولو ته اړتیا لري. دا مناسب دی که ستاسو سرورونه د ډیر غیر کارونکي بار لاندې وي او د کارونکي عملیات لومړیتوب پاتې وي.
• فعالیت د ټول سیسټم په ډیزاین پورې اړه لري، نه یوازې د داخلي لوپ الګوریتم.

(دا مقاله په حافظه کې د معلوماتو لټون تشریح کوي. په ډیری حاالتو کې، کله چې یو کاروونکي د لاګ لټون ترسره کوي، د سکیلر سرورونو دمخه دا زیرمه کړې ده. راتلونکې مقاله به د غیر محفوظ شوي لاګونو لټون په اړه بحث وکړي. ورته اصول پلي کیږي: اغیزمن کوډ، بریټ ځواک د لوی کمپیوټري سرچینو سره).

د وحشي ځواک طریقه

په دودیز ډول، د لوی ډیټا سیټ د کلیدي ټکي په کارولو سره پلټل کیږي. کله چې د سرور لاګونو کې پلي کیږي، دا پدې مانا ده چې په لاګ کې د هرې ځانګړې کلمې لټون کول. د هرې کلمې لپاره، تاسو اړتیا لرئ چې د ټولو شاملولو لیست جوړ کړئ. دا د دې کلمې سره د ټولو پیغامونو موندلو لپاره اسانه کوي، د بیلګې په توګه 'غلطۍ'، 'فایرفوکس' یا "transaction_16851951" - یوازې په شاخص کې وګورئ.

ما دا طریقه په ګوګل کې کارولې او دا ښه کار وکړ. مګر په سکالر کې موږ د بایټ په واسطه د لاګ بایټ لټون کوو.

ولې؟ د خلاصې الګوریتمیک نظر څخه، د کلیدي ټکي شاخصونه د وحشي ځواک لټونونو په پرتله خورا اغیزمن دي. په هرصورت، موږ الګوریتم نه پلورو، موږ فعالیت پلورو. او فعالیت نه یوازې د الګوریتمونو په اړه، بلکې د سیسټم انجنیري په اړه هم دی. موږ باید هرڅه په پام کې ونیسو: د معلوماتو حجم، د لټون ډول، موجود هارډویر او سافټویر شرایط. موږ پریکړه وکړه چې زموږ د ځانګړې ستونزې لپاره، د 'grep' په څیر یو څه د شاخص په پرتله غوره و.

شاخصونه خورا ښه دي، مګر دوی محدودیتونه لري. یوه کلمه موندل اسانه دي. مګر د ډیرو کلمو سره د پیغامونو لټون کول، لکه 'googlebot' او '404'، خورا ستونزمن دي. د یوې جملې لټون کول لکه 'نه موندل شوي استثنا' یو ډیر پیچلي شاخص ته اړتیا لري چې نه یوازې د دې کلمې سره ټول پیغامونه ثبتوي، بلکې د کلمې ځانګړي ځای هم ثبتوي.

اصلي مشکل هغه وخت راځي چې تاسو د کلمو په لټه کې نه یاست. راځئ چې ووایو تاسو غواړئ وګورئ چې څومره ټرافيک د بوټو څخه راځي. لومړی فکر د 'بوټ' کلمې لپاره د لاګونو لټون کول دي. دا څنګه تاسو به ځینې بوټونه ومومئ: Googlebot، Bingbot او ډیری نور. مګر دلته 'بوټ' یوه کلمه نه ده، مګر د هغې یوه برخه ده. که موږ په شاخص کې د 'بوټ' لټون وکړو، موږ به د 'Googlebot' کلمې سره هیڅ پوسټ ونه موندلو. که تاسو په شاخص کې هره کلمه وګورئ او بیا د موندلو کلیمو لپاره شاخص سکین کړئ، لټون به خورا ورو ورو. د پایلې په توګه، ځینې لاګ پروګرامونه د برخې کلمې لټونونو ته اجازه نه ورکوي یا (په غوره توګه) د ټیټ فعالیت سره ځانګړي ترکیب ته اجازه ورکوي. موږ غواړو له دې څخه مخنیوی وکړو.

بله ستونزه د ټکي نښه ده. ایا تاسو غواړئ چې له دې څخه ټولې غوښتنې ومومئ 50.168.29.7؟ د ډیبګ کولو لاګونو په اړه څه [error]؟ سبسکریپټونه معمولا ټکي پریږدي.

په نهایت کې ، انجینران قوي وسیلې خوښوي ، او ځینې وختونه ستونزه یوازې د منظم بیان سره حل کیدی شي. د کلیدي کلمې شاخص د دې لپاره خورا مناسب نه دی.

سربیره پردې، شاخصونه پیچلي. هر پیغام باید د څو کلیدي کلمو لیستونو کې اضافه شي. دا لیستونه باید هر وخت په اسانۍ سره د لټون وړ بڼه کې وساتل شي. د جملو، کلمو ټوټې، یا منظم بیانونو سره پوښتنې باید په څو لیست عملیاتو کې ژباړل شي، او پایلې سکین شوي او یوځای شوي ترڅو د پایلې سیټ تولید کړي. د لوی پیمانه، څو کرایه کونکي خدمت په شرایطو کې، دا پیچلتیا د فعالیت مسلې رامینځته کوي چې د الګوریتم تحلیل کولو په وخت کې نه لیدل کیږي.

د کلیدي ټکي شاخصونه هم ډیر ځای نیسي، او ذخیره کول د لاګ مدیریت سیسټم کې لوی لګښت دی.

له بلې خوا، هر لټون کولی شي د کمپیوټر ډیری ځواک مصرف کړي. زموږ کاروونکي د ځانګړو پوښتنو لپاره د لوړ سرعت لټونونو ستاینه کوي، مګر دا ډول پوښتنې نسبتا لږې کیږي. د عادي لټون پوښتنو لپاره، د بیلګې په توګه، د ډشبورډ لپاره، موږ ځانګړي تخنیکونه کاروو (موږ به یې په راتلونکې مقاله کې تشریح کړو). نورې غوښتنې دومره کمې دي چې تاسو په ندرت سره په یو وخت کې له یو څخه ډیر پروسس کوئ. مګر دا پدې معنی ندي چې زموږ سرورونه بوخت ندي: دوی د نوي پیغامونو ترلاسه کولو ، تحلیل کولو او کمپریس کولو ، د خبرتیاو ارزونه ، د زاړه ډیټا کمپریس کولو او داسې نورو کې بوخت دي. په دې توګه، موږ د پروسیسرونو کافي د پام وړ عرضه لرو چې د پوښتنو اجرا کولو لپاره کارول کیدی شي.

وحشي ځواک کار کوي که تاسو د وحشي ستونزه لرئ (او ډیر ځواک)

وحشي ځواک د کوچني داخلي لوپونو سره په ساده ستونزو کې غوره کار کوي. ډیری وختونه تاسو کولی شئ په خورا لوړ سرعت چلولو لپاره داخلي لوپ اصلاح کړئ. که کوډ پیچلی وي، نو د دې اصلاح کول خورا ستونزمن دي.

زموږ د لټون کوډ په اصل کې خورا لوی داخلي لوپ درلود. موږ په 4K پاڼو کې پیغامونه ذخیره کوو؛ هره پاڼه ځینې پیغامونه لري (په UTF-8 کې) او د هر پیغام لپاره میټاډاټا. میټاډاټا یو جوړښت دی چې د ارزښت اوږدوالی، د داخلي پیغام ID، او نورې ساحې کوډ کوي. د لټون دوره داسې ښکاري:

دا د اصلي کوډ ساده نسخه ده. مګر حتی دلته، د ډیری اعتراض ځای پرځای کول، د معلوماتو کاپي، او د فعالیت کال لیدل کیږي. JVM د فنکشن کالونو اصلاح کولو او د لنډمهاله شیانو تخصیص کولو کې خورا ښه دی ، نو دې کوډ زموږ د مستحق څخه ښه کار وکړ. د ازموینې په جریان کې، پیرودونکو دا په بریالیتوب سره کارولې. مګر په نهایت کې موږ دا بلې کچې ته ورسوو.

(تاسو کولی شئ پوښتنه وکړئ چې ولې موږ په دې فارمیټ کې پیغامونه د 4K پاڼو، متن او میټاډاټا سره ذخیره کوو، د دې پرځای چې په مستقیم ډول د لاګونو سره کار وکړو. ډیری دلیلونه شتون لري، کوم چې دا حقیقت ته رسوي چې په داخلي توګه د سکیلر انجن په پرتله د ویشل شوي ډیټابیس په څیر دی. د فایل سیسټم. د متن لټون اکثرا د لاګ پارس کولو وروسته په حاشیو کې د DBMS سټایل فلټرونو سره یوځای کیږي. موږ کولی شو په یوځل کې ډیری زرګونه لاګونه ولټوو ، او ساده متن فایلونه زموږ د لیږد ، نقل شوي ، توزیع شوي ډیټا مدیریت لپاره مناسب ندي).

په پیل کې، داسې بریښي چې دا کوډ د وحشي ځواک اصلاح کولو لپاره خورا مناسب نه و. په "حقیقي کار" کې String.indexOf() حتی د CPU پروفایل واکمن نه و. دا دی، یوازې د دې طریقې اصلاح کول به د پام وړ اغیزه ونه کړي.

دا داسې کیږي چې موږ د هرې پاڼې په پیل کې میټاډاټا ذخیره کوو، او په UTF-8 کې د ټولو پیغامونو متن په بل پای کې ډک شوی. د دې څخه په ګټې اخیستنې، موږ د ټول پاڼې د لټون کولو لپاره لوپ بیا ولیکل:

دا نسخه په مستقیم ډول په لید کې کار کوي raw byte[] او په ټول 4K پاڼه کې په یوځل کې ټول پیغامونه لټوي.

دا د وحشي ځواک میتود لپاره غوره کول خورا اسانه دي. د داخلي لټون لوپ د ټول 4K پاڼې لپاره په ورته وخت کې ویل کیږي، نه په جلا توګه په هر پوسټ کې. د معلوماتو کاپي نشته، د شیانو تخصیص نشته. او ډیر پیچلي میټاډاټا عملیات یوازې هغه وخت ویل کیږي کله چې پایله مثبته وي، نه په هر پیغام کې. پدې توګه موږ یو ټن سر له مینځه وړی دی، او پاتې بار په یو کوچني داخلي لټون لوپ کې متمرکز دی، کوم چې د نور اصلاح کولو لپاره مناسب دی.

زموږ د اصلي لټون الګوریتم پر بنسټ والړ دی د لیونید ولنیتسکي عالي نظر. دا د بویر - مور الګوریتم سره ورته دی، په هر ګام کې د لټون تار نږدې اوږدوالی پریږدي. اصلي توپیر دا دی چې دا په یو وخت کې دوه بایټونه ګوري ترڅو غلط میچونه کم کړي.

زموږ پلي کول د هرې لټون لپاره د 64K لید جدول رامینځته کولو ته اړتیا لري ، مګر دا د ګیګابایټ ډیټا په پرتله هیڅ ندي چې موږ یې لټوو. داخلي لوپ په یو واحد کور کې په هر ثانیه کې څو ګیګابایټ پروسس کوي. په عمل کې، ثابت فعالیت په هر کور کې په هر ثانیه کې شاوخوا 1,25 GB دی، او د پرمختګ لپاره ځای شتون لري. دا ممکنه ده چې د داخلي لوپ څخه بهر ځینې سرونه له منځه یوسو، او موږ پالن لرو چې د جاوا پر ځای په C کې د داخلي لوپ سره تجربه وکړو.

موږ زور کاروو

موږ په دې اړه بحث کړی چې د لاګ لټون "نږدې" پلي کیدی شي، مګر موږ څومره "ځواک" لرو؟ ډیر څه.

1 کور: کله چې په سمه توګه وکارول شي، د عصري پروسیسر یو واحد کور په خپل حق کې خورا پیاوړی دی.

8 کورونه: موږ اوس مهال په ایمیزون hi1.4xlarge او i2.4xlarge SSD سرورونو کې روان یو، هر یو د 8 کور (16 تارونه) سره. لکه څنګه چې پورته یادونه وشوه، دا کورونه معمولا د شالید عملیاتو سره بوخت دي. کله چې کاروونکي لټون ترسره کوي، د شالید عملیات ځنډول کیږي، د لټون لپاره ټول 8 کورونه آزادوي. لټون معمولا په یوه ثانیه کې بشپړیږي، وروسته له دې چې د شالید کار بیا پیل کیږي (د تروتلینګ پروګرام ډاډ ورکوي چې د لټون پوښتنو بیرغ د مهم شالید کار کې مداخله نه کوي).

16 کورونه: د اعتبار لپاره، موږ سرورونه په ماسټر / غلام ګروپونو کې تنظیم کوو. هر ماسټر د هغه تر قوماندې لاندې یو SSD او یو EBS سرور لري. که اصلي سرور خراب شي، د SSD سرور سمدلاسه خپل ځای نیسي. نږدې ټول وخت، ماسټر او غلام ښه کار کوي، نو د هر ډیټا بلاک په دوه مختلف سرورونو کې د لټون وړ دی (د EBS غلام سرور ضعیف پروسیسر لري، نو موږ یې په پام کې نه نیسو). موږ د دوی تر مینځ دنده ویشو، نو موږ ټول 16 کورونه لرو.

ډیری کورونه: په نږدې راتلونکي کې، موږ به په سرورونو کې ډاټا په داسې ډول توزیع کړو چې دوی ټول د هرې غیر معمولي غوښتنې پروسس کولو کې برخه اخلي. هر کور به کار وکړي. [یادونه: موږ پلان پلي کړ او د لټون سرعت یې 1 TB/s ته لوړ کړ، د مقالې په پای کې یادونه وګورئ].

سادگي د اعتبار ډاډ ورکوي

د وحشی ځواک میتود بله ګټه د دې کافي دوامداره فعالیت دی. عموما، لټون د ستونزې او ډیټا سیټ توضیحاتو ته خورا حساس ندي (زه فکر کوم له همدې امله دا "موټی" ویل کیږي).

د کلیدي ټکي شاخص ځینې وختونه په زړه پورې ګړندۍ پایلې تولیدوي، او نور وختونه دا نه کوي. راځئ چې ووایو تاسو 50 GB لاګونه لرئ په کوم کې چې د 'پیرودونکي_5987235982' اصطلاح دقیقا درې ځله څرګندیږي. د دې اصطلاح لپاره لټون په مستقیم ډول د شاخص څخه درې ځایونه حسابوي او سمدستي به بشپړ شي. مګر پیچلي وائلډ کارډ لټونونه کولی شي په زرګونو کلیدي کلمې سکین کړي او ډیر وخت ونیسي.

له بلې خوا، د وحشي ځواک لټونونه د هرې پوښتنې لپاره لږ یا لږ ورته سرعت ترسره کوي. د اوږدو کلمو لټون کول غوره دي، مګر حتی د یو واحد کرکټر لټون خورا ګړندی دی.

د وحشي ځواک میتود سادگي پدې معنی ده چې د هغې فعالیت خپل نظري اعظمي ته نږدې دی. د غیر متوقع ډیسک اوورلوډونو لپاره لږ اختیارونه شتون لري، د بند محتوا، د پوائنټر تعقیب، او د ناکامۍ لپاره زرګونه نور دلیلونه. ما یوازې زموږ په بوخت سرور کې تیره اونۍ د سکالر کاروونکو لخوا غوښتنې ته وکتل. 14 غوښتنې وې. په دقیقه توګه اتو یې له یوې ثانیې څخه ډیر وخت واخیست. 000٪ په 99 ملی ثانیو کې بشپړ شوی (که تاسو د لاګ تحلیلي وسیلې نه وي کارولې، په ما باور وکړئ: دا چټک دی).

باثباته، د باور وړ فعالیت د خدماتو کارولو اسانتیا لپاره مهم دی. که دا په دوره توګه وځنډول شي، کاروونکي به دا د باور وړ نه وي او د کارولو لپاره به زړه نازړه وي.

په عمل کې د لټون لټون

دلته یو لنډ حرکت دی چې د Scalyr لټون په عمل کې ښیي. موږ یو ډیمو حساب لرو چیرې چې موږ هره پیښه په هر عامه ګیتوب ذخیره کې واردوو. پدې ډیمو کې ، زه د یوې اونۍ ارزښت لرونکي ډیټا معاینه کوم: نږدې 600 MB خام لاګونه.

ویډیو زما په ډیسټاپ (د سرور څخه شاوخوا 5000 کیلومتره) کې پرته له ځانګړي چمتووالي څخه په ژوندۍ توګه ثبت شوې. هغه فعالیت چې تاسو به یې وګورئ په لویه کچه د دې له امله دی د ویب پیرودونکي اصلاح کول، په بیله بیا یو ګړندی او د اعتماد وړ پس منظر. هرکله چې د 'لوډ کولو' شاخص پرته وقفه وي، دا زه وقفه کوم نو تاسو کولی شئ هغه څه ولولئ چې زه یې فشار راوړم.

په پای کې

کله چې د ډیټا لوی مقدار پروسس کوئ، نو دا مهمه ده چې یو ښه الګوریتم غوره کړئ، مګر "ښه" د "فانسسي" معنی نلري. فکر وکړئ چې ستاسو کوډ به په عمل کې څنګه کار وکړي. د الګوریتم نظري تحلیل ځینې فکتورونه پریږدي چې په ریښتینې نړۍ کې خورا مهم کیدی شي. ساده الګوریتمونه د غوره کولو لپاره اسانه دي او په څنډه حالتونو کې ډیر باثباته دي.

د هغه شرایطو په اړه هم فکر وکړئ په کوم کې چې کوډ به اجرا شي. زموږ په قضیه کې، موږ د شالید دندو اداره کولو لپاره کافي ځواکمن سرورونو ته اړتیا لرو. کاروونکي په نسبي ډول لټونونه پیل کوي، نو موږ کولی شو د هرې لټون بشپړولو لپاره د لنډې مودې لپاره د سرورونو ټوله ډله په پور واخلو.

د وحشي ځواک طریقې په کارولو سره، موږ د لاګونو سیټ په اوږدو کې یو ګړندی، د اعتماد وړ، انعطاف وړ لټون پلي کړ. موږ هیله لرو چې دا نظرونه ستاسو د پروژو لپاره ګټور وي.

تدوین: سرلیک او متن د "په هره ثانیه کې د 20 GB لټون" څخه "په 1 TB فی ثانیه کې لټون" ته بدل شوي ترڅو په تیرو څو کلونو کې د فعالیت زیاتوالی منعکس کړي. په سرعت کې دا زیاتوالی اساسا د EC2 سرورونو ډول او شمیر کې د بدلونونو له امله دی چې موږ نن ورځ زموږ د پیرودونکي ډیری شوي اساس ته خدمت کوو. ډیر ژر داسې بدلونونه راځي چې په عملیاتي موثریت کې به یو بل ډراماتیک وده چمتو کړي، او موږ د دوی شریکولو ته انتظار نشو کولی.

سرچینه: www.habr.com