TL; DR: Төрт жыл мурун мен Google'дан жаңы серверди көзөмөлдөө куралы идеясы менен кеттим. Идея адатта обочолонгон функцияларды бир кызматка бириктирүү болгон жана журналды талдоо, көрсөткүчтөрдү чогултуу, жана башкаруу такталары. Принциптердин бири – бул кызмат чындап болушу керек тез, devops жеңил, интерактивдүү, жагымдуу тажрыйба менен камсыз кылуу. Бул бюджеттин чегинде калуу менен секунданын бөлчөктөрүндө көп гигабайттык маалымат топтомун иштетүүнү талап кылат. Учурдагы журналды башкаруу куралдары көбүнчө жай жана татаал болгондуктан, биз жакшы кыйынчылыкка туш болдук: колдонуучуларга жаңы тажрыйба берүү үчүн куралды акылдуу долбоорлоо.
Бул макалада биз Скалирде бул көйгөйдү кантип чечкенибиздин эски мектеп ыкмаларын, катаал күч ыкмасын колдонуу, керексиз катмарларды жок кылуу жана татаал маалымат структураларынан качуу аркылуу сүрөттөлөт. Сиз бул сабактарды өзүңүздүн инженердик көйгөйлөрүңүзгө колдоно аласыз.
Эски мектеп күчү
Журналды талдоо адатта издөө менен башталат: белгилүү бир үлгүгө дал келген бардык билдирүүлөрдү табыңыз. Скалирде булар көптөгөн серверлерден алынган ондогон же жүздөгөн гигабайт журналдар. Заманбап ыкмалар, эреже катары, издөө үчүн оптималдаштырылган кээ бир татаал маалымат структурасын курууну камтыйт. Мен муну Googleден көрдүм, ал жерде алар ушундай нерселерде абдан жакшы. Бирок биз бир топ одоно ыкмага токтолдук: журналдарды сызыктуу сканерлөө. Жана ал иштеди - биз атаандаштарыбызга караганда ылдамыраак издөө интерфейсин сунуштайбыз (аягында анимацияны караңыз).
Негизги түшүнүк заманбап процессорлор жөнөкөй, жөнөкөй операцияларда абдан тез экени болду. Киргизүү/чыгаруу ылдамдыгына жана тармактык операцияларга таянган татаал, көп катмарлуу системаларда бул оңой эле байкалбайт жана мындай системалар бүгүнкү күндө абдан кеңири таралган. Ошентип, биз катмарларды жана ашыкча таштандыларды азайткан дизайнды иштеп чыктык. Параллелдүү бир нече процессорлор жана серверлер менен издөө ылдамдыгы секундасына 1 ТБга жетет.
Бул макаладан негизги жыйынтыктар:
- Оор күч менен издөө реалдуу дүйнөдөгү масштабдуу маселелерди чечүү үчүн жарамдуу ыкма болуп саналат.
- Кара күч - бул долбоорлоо ыкмасы, жумушсуз чечим эмес. Ар кандай техника сыяктуу эле, ал башкаларга караганда кээ бир көйгөйлөргө ылайыктуу жана начар же жакшы ишке ашырылышы мүмкүн.
- Оор күч жетүү үчүн өзгөчө жакшы туруктуу өндүрүмдүүлүк.
- Оор күчтү эффективдүү колдонуу кодду оптималдаштырууну жана керектүү учурда жетиштүү ресурстарды колдонууну талап кылат. Бул сиздин серверлериңиз колдонуучу эмес жүктөм астында болсо жана колдонуучу операциялары артыкчылыктуу бойдон калса, ылайыктуу.
- Иштин майнаптуулугу ички цикл алгоритмине эле эмес, бүт системанын дизайнына жараша болот.
(Бул макалада эстутумда маалыматтарды издөө сүрөттөлөт. Көпчүлүк учурларда, колдонуучу журналда издөө жүргүзгөндө, Scalyr серверлери аны мурунтан кэштеп коюшкан. Кийинки макалада кэштелбеген журналдарды издөө талкууланат. Ошол эле принциптер колдонулат: эффективдүү код, катаал күч чоң эсептөө ресурстары менен).
Оор күч ыкмасы
Адаттагыдай эле, чоң маалымат топтому ачкыч сөз индексинин жардамы менен изделет. Сервер журналдарына колдонулганда, бул журналдагы ар бир уникалдуу сөздү издөө дегенди билдирет. Ар бир сөз үчүн сиз бардык кошулмалардын тизмесин түзүшүңүз керек. Бул бул сөз менен бардык билдирүүлөрдү оңой табууга мүмкүндүк берет, мисалы, "ката", "firefox" же "transaction_16851951" - жөн гана индексти караңыз.
Мен бул ыкманы Google'да колдондум жана ал жакшы иштеди. Бирок Scalyrде биз журналдарды байт боюнча издейбиз.
Неге? Абстракттуу алгоритмдик көз караштан алганда, ачкыч сөздөрдүн индекстери катаал күч менен издөөгө караганда алда канча натыйжалуу. Бирок, биз алгоритмдерди сатпайбыз, аткарууну сатабыз. Ал эми аткаруу алгоритмдер жөнүндө гана эмес, системалык инженерия жөнүндө да. Биз бардыгын карап чыгышыбыз керек: маалыматтардын көлөмү, издөө түрү, жеткиликтүү аппараттык жана программалык контекст. Биз өзгөчө көйгөйүбүз үчүн индекске караганда "grep" сыяктуу нерсе ылайыктуу деп чечтик.
Индекстер сонун, бирок алардын чектөөлөрү бар. Бир сөздү табуу оңой. Бирок "googlebot" жана "404" сыяктуу бир нече сөздөн турган билдирүүлөрдү издөө алда канча кыйыныраак. "Колдонулбаган өзгөчөлүк" сыяктуу сөз айкашын издөө ошол сөз менен болгон бардык билдирүүлөрдү гана эмес, ошондой эле сөздүн конкреттүү жайгашкан жерин да жаза турган бир кыйла татаал индексти талап кылат.
Чыныгы кыйынчылык сөз издебегенде келет. Сиз боттордон канча трафик келип жатканын көргүңүз келет дейли. Биринчи ой - журналдардан "бот" деген сөздү издөө. Кээ бир ботторду ушинтип таба аласыз: Googlebot, Bingbot жана башкалар. Бирок бул жерде «бот» сөз эмес, анын бир бөлүгү. Эгерде биз индекстен "бот" деп издесек, "Googlebot" деген сөз менен эч кандай пост таппайбыз. Эгерде сиз индекстеги ар бир сөздү текшерип, андан кийин табылган ачкыч сөздөр үчүн индексти сканерлесеңиз, издөө абдан жайлайт. Натыйжада, кээ бир журнал программалары жарым-жартылай издөөгө уруксат бербейт же (эң жакшысы) төмөн көрсөткүчтөргө ээ атайын синтаксиске жол бербейт. Биз мындан качкыбыз келет.
Дагы бир көйгөй - пунктуация. Бардык сурамдарды тапкыңыз келеби? 50.168.29.7? камтыган журналдарды оңдоо жөнүндө эмне айтууга болот [error]? Жазылуучу жазуулар, адатта, тыныш белгилерин өткөрүп жиберишет.
Акыр-аягы, инженерлер күчтүү куралдарды жакшы көрүшөт, кээде көйгөйдү туруктуу сөз айкашы менен гана чечсе болот. Ачкычтуу сүйлөм боюнча индекс бул үчүн абдан ылайыктуу эмес.
Мындан тышкары, индекстер комплекс. Ар бир билдирүү бир нече ачкыч тизмеге кошулушу керек. Бул тизмелер ар дайым оңой изделүүчү форматта сакталышы керек. Фразалар, сөз фрагменттери же туруктуу сөз айкаштары бар сурамдарды көп тизмедеги операцияларга которуу жана натыйжалар топтомун чыгаруу үчүн натыйжаларды сканерлөө жана бириктирүү керек. Кең масштабдуу, көп ижарачы кызматтын контекстинде бул татаалдык алгоритмдерди талдоодо көрүнбөгөн аткаруу маселелерин жаратат.
Ачкычтуу сүйлөм боюнча индекстер да көп орун ээлейт жана сактоо журналды башкаруу системасында негизги чыгым болуп саналат.
Башка жагынан алганда, ар бир издөө эсептөө күчү көп керектөө мүмкүн. Биздин колдонуучулар уникалдуу суроолор боюнча жогорку ылдамдыктагы издөөлөрдү баалайт, бирок мындай сурамдар салыштырмалуу сейрек жасалат. Кадимки издөө сурамдары үчүн, мисалы, такта үчүн, биз атайын ыкмаларды колдонобуз (кийинки макалада аларды сүрөттөп беребиз). Башка суроо-талаптар сейрек кездешет, андыктан бир эле учурда бирден көптү иштетүүгө туура келет. Бирок бул биздин серверлер бош эмес дегенди билдирбейт: алар жаңы билдирүүлөрдү кабыл алуу, талдоо жана кысуу, эскертүүлөрдү баалоо, эски маалыматтарды кысуу жана башкалар менен алек. Ошентип, бизде суроо-талаптарды аткаруу үчүн колдонула турган процессорлордун олуттуу запасы бар.
Эгерде сизде одоно көйгөй болсо (жана көп күч) катаал күч иштейт
Brute force кичинекей ички илмектери бар жөнөкөй маселелерде эң жакшы иштейт. Көп учурда сиз ички циклди өтө жогорку ылдамдыкта иштетүү үчүн оптималдаштыра аласыз. Эгер код татаал болсо, аны оптималдаштыруу алда канча кыйын.
Биздин издөө кодубуз башында бир кыйла чоң ички циклге ээ болгон. Биз 4K беттеринде билдирүүлөрдү сактайбыз; ар бир барак кээ бир билдирүүлөрдү (UTF-8де) жана ар бир билдирүү үчүн метаберилиштерди камтыйт. Метаберилиштер маанинин узундугун, ички билдирүү ID жана башка талааларды коддогон структура болуп саналат. Издөө цикли мындай көрүндү:
Бул чыныгы коддун жөнөкөйлөштүрүлгөн версиясы. Бирок бул жерде дагы бир нече объект жайгаштыруу, маалыматтардын көчүрмөлөрү жана функция чалуулары көрүнүп турат. JVM функциялык чакырууларды оптималдаштырууда жана эфемердик объекттерди бөлүштүрүүдө абдан жакшы, ошондуктан бул код биз татыктуу болгондон да жакшыраак иштеди. Сыноо учурунда кардарлар аны ийгиликтүү колдонушту. Бирок акыры биз аны кийинки деңгээлге көтөрдүк.
(Сиз эмне үчүн биз билдирүүлөрдү түздөн-түз журналдар менен иштебей, 4K барактары, тексти жана метадайындары менен ушул форматта сактайбыз деп сурасаңыз болот. Көптөгөн себептер бар, алардын ичинде Scalyr кыймылдаткычы бөлүштүрүлгөн маалымат базасына көбүрөөк окшош. файл системасы. Тексттик издөө көбүнчө журналды талдоодон кийин чектерде DBMS стилиндеги чыпкалар менен айкалышат. Биз бир эле учурда миңдеген журналдарды бир эле учурда издей алабыз жана жөнөкөй текст файлдары транзакциялык, репликацияланган, бөлүштүрүлгөн маалыматтарды башкаруубузга ылайыктуу эмес).
Башында, мындай код орой күч оптималдаштыруу үчүн абдан ылайыктуу эмес болуп көрүнгөн. «Чыныгы иш». String.indexOf() CPU профилинде да үстөмдүк кылган жок. Башкача айтканда, жалгыз бул ыкманы оптималдаштыруу олуттуу натыйжа алып келбейт.
Ошентип, биз метаберилиштерди ар бир беттин башында сактайбыз, ал эми UTF-8деги бардык билдирүүлөрдүн тексти экинчи четинде топтолот. Мындан пайдаланып, биз бир эле учурда бүт баракты издөө үчүн циклди кайра жаздык:
Бул версия түздөн-түз көз карашта иштейт raw byte[] жана бардык билдирүүлөрдү бир эле учурда бүт 4K барагынан издейт.
Бул катаал күч ыкмасы үчүн оптималдаштыруу бир топ жеңил. Ички издөө цикли ар бир постто өзүнчө эмес, бүтүндөй 4K барагы үчүн бир убакта чакырылат. Маалыматтарды көчүрүү, объекттерди бөлүштүрүү жок. Ал эми метадайындардын татаал операциялары ар бир билдирүүдө эмес, натыйжа оң болгондо гана чакырылат. Ушундай жол менен биз бир тонна ашыкча чыгымды жок кылдык, ал эми жүктүн калган бөлүгү андан ары оптималдаштыруу үчүн эң ылайыктуу кичинекей ички издөө циклинде топтолгон.
Биздин чыныгы издөө алгоритмибиз негизделген . Бул Бойер-Мур алгоритмине окшош, ар бир кадамда издөө сапынын болжолдуу узундугун өткөрүп жиберет. Негизги айырмасы, ал жалган дал келүүлөрдү азайтуу үчүн бир убакта эки байт текшерет.
Биздин ишке ашыруу ар бир издөө үчүн 64K издөө таблицасын түзүүнү талап кылат, бирок бул биз издеп жаткан гигабайт маалыматтарга салыштырмалуу эч нерсе эмес. Ички цикл бир ядродо секундасына бир нече гигабайтты иштетет. Иш жүзүндө, туруктуу аткаруу ар бир өзөктө секундасына 1,25 ГБ тегерегинде жана жакшыртуу үчүн орун бар. Ички циклден тышкары кошумча чыгымдардын бир бөлүгүн жок кылууга болот жана биз Javaнын ордуна C тилиндеги ички цикл менен эксперимент жүргүзүүнү пландаштырып жатабыз.
Биз күч колдонобуз
Биз журналда издөөнү "болжол менен" ишке ашырууга болорун талкууладык, бирок бизде канчалык "күч" бар? Абдан көп.
1 ядро: Туура колдонулганда, заманбап процессордун бир өзөгү өзүнчө эле күчтүү.
8 ядро: Учурда биз Amazon hi1.4xlarge жана i2.4xlarge SSD серверлеринде иштеп жатабыз, алардын ар бири 8 өзөктүү (16 жип). Жогоруда айтылгандай, бул өзөктөр адатта фондо операциялар менен алек. Колдонуучу издөө жүргүзгөндө, фондо иштөө убактылуу токтотулуп, издөө үчүн бардык 8 өзөк бошотот. Издөө, адатта, бир секунданын ичинде бүтөт, андан кийин фондук иш кайра башталат (басаңдатуучу программа издөө сурамдарынын тоскоолдугу маанилүү фондук ишке тоскоол болбошун камсыздайт).
16 ядро: ишенимдүүлүк үчүн биз серверлерди мастер/кул топторуна уюштурабыз. Ар бир мастердин буйругунда бир SSD жана бир EBS сервери бар. Эгерде негизги сервер бузулуп калса, SSD сервери дароо анын ордун ээлейт. Дээрлик ар дайым мастер жана кул жакшы иштешет, андыктан ар бир маалымат блогу эки башка серверден издөөгө болот (EBS кул серверинде алсыз процессор бар, ошондуктан биз аны эске албайбыз). Биз алардын ортосунда тапшырманы бөлүштүрөбүз, ошентип бизде бардыгы болуп 16 өзөк бар.
Көптөгөн өзөктөр: Жакынкы келечекте биз серверлер боюнча маалыматтарды таратабыз, алар баары ар бир майда-чүйдө эмес суроо-талаптарды иштетүүгө катышат. Ар бир өзөк иштейт. [Эскертүү: биз планды ишке ашырдык жана издөө ылдамдыгын 1 ТБ/сек чейин көбөйттүк, макаланын аягындагы эскертүүнү караңыз].
Жөнөкөйлүк ишенимдүүлүктү камсыздайт
Оор күч ыкмасынын дагы бир артыкчылыгы - анын жетишээрлик ырааттуу иштеши. Адатта, издөө маселенин жана маалымат топтомунун майда-чүйдөсүнө чейин сезгич эмес (менин оюмча, ал "орой" деп аталат).
Ачкыч сөздүн индекси кээде укмуштуудай тез натыйжаларды берет, ал эми башка учурларда андай болбойт. Сизде 50 ГБ журналдар бар дейли, анда 'customer_5987235982' термини так үч жолу кездешет. Бул терминди издөө индекстен түздөн-түз үч жерди эсептейт жана ошол замат аяктайт. Бирок татаал айкалыштуу издөөлөр миңдеген ачкыч сөздөрдү сканерлеп, көп убакытты талап кылышы мүмкүн.
Башка жагынан алганда, катаал издөөлөр каалаган суроо үчүн аздыр-көптүр бирдей ылдамдыкта аткарат. Узун сөздөрдү издөө жакшыраак, бирок бир тамганы издөө да абдан тез.
Оор күч ыкмасынын жөнөкөйлүгү анын аткарылышы теориялык максимумга жакын экенин билдирет. Күтүлбөгөн дискти ашыкча жүктөө, кулпулоо боюнча талаш-тартыштар, көрсөткүчтөрдү кууп чыгуу жана катачылыктын миңдеген башка себептери үчүн азыраак варианттар бар. Мен Scalyr колдонуучуларынын өткөн жумада эң көп иштеген серверибиздеги суроо-талаптарын карап чыктым. 14 миң кайрылуу түшкөн. Алардын так сегизи бир секунддан ашык убакытты алды; 000% 99 миллисекундда аткарылды (эгерде сиз журналды талдоо куралдарын колдонбосоңуз, мага ишениңиз: ал тез).
Туруктуу, ишенимдүү аткаруу кызматты колдонуунун жеңилдиги үчүн маанилүү. Ал мезгил-мезгили менен артта калса, колдонуучулар аны ишенимсиз деп кабылдап, аны колдонуудан баш тартышат.
Кирүү издөө аракетинде
Бул жерде Scalyr издөө аракетин көрсөткөн кыска анимация. Бизде демо каттоо эсеби бар, анда биз ар бир коомдук Github репозиторийиндеги ар бир окуяны импорттойбуз. Бул демонстрацияда мен бир жумалык маалыматтарды карап чыгам: болжол менен 600 МБ чийки журнал.
Видео түз эфирде, атайын даярдыксыз, менин иш столумда (серверден 5000 чакырымдай алыстыкта) жазылган. Сиз көрө турган аткаруу негизинен байланыштуу , ошондой эле тез жана ишенимдүү backend. "Жүктөө" көрсөткүчү жок тыныгуу болгондо, мен баса турган нерсени окуй аласыз.
Жыйынтык
Чоң көлөмдөгү маалыматтарды иштеп чыгууда, жакшы алгоритмди тандоо маанилүү, бирок "жакшы" дегенди билдирбейт. Сиздин кодуңуз иш жүзүндө кантип иштей турганы жөнүндө ойлонуп көрүңүз. Алгоритмдердин теориялык анализи реалдуу дүйнөдө чоң мааниге ээ боло турган кээ бир факторлорду калтырат. Жөнөкөй алгоритмдерди оптималдаштыруу оңой жана четки кырдаалдарда туруктуураак.
Ошондой эле код аткарыла турган контекст жөнүндө ойлонуп көрүңүз. Биздин учурда, фондо тапшырмаларды башкаруу үчүн жетиштүү күчтүү серверлер керек. Колдонуучулар издөөнү салыштырмалуу сейрек башташат, ошондуктан биз ар бир издөөнү аяктоо үчүн зарыл болгон кыска мөөнөткө серверлердин бүтүндөй тобун ала алабыз.
Оор күч ыкмасын колдонуп, биз журналдардын топтому боюнча тез, ишенимдүү, ийкемдүү издөөнү ишке ашырдык. Бул идеялар долбоорлоруңуз үчүн пайдалуу болот деп ишенебиз.
Түзөтүү: Аталышы жана тексти акыркы бир нече жылдагы өндүрүмдүүлүктүн жогорулашын чагылдыруу үчүн "Секундуна 20 ГБ издөө" дегенден "Секундуна 1 ТБ издөө" болуп өзгөрдү. Ылдамдыктын мындай өсүшү, биринчи кезекте, биздин кардарлар базасынын көбөйүшүнө кызмат кылуу үчүн биз бүгүн коюп жаткан EC2 серверлеринин түрүнүн жана санынын өзгөрүшүнө байланыштуу. Операциянын эффективдүүлүгүн дагы бир кескин жогорулата турган өзгөрүүлөр жакында болот жана биз аларды бөлүшүүнү күтө албайбыз.
Source: www.habr.com