Эй Хабр! Менин атым Максим Васильев, мен FINCHте аналитик жана долбоордун менеджери болуп иштейм. Бүгүн мен ElasticSearch аркылуу кантип 15 мүнөттүн ичинде 6 миллион суроону иштеп чыгып, кардарларыбыздын биринин сайтындагы күнүмдүк жүктөмдөрдү оптималдаштырганыбызды айткым келет. Тилекке каршы, биз аттары жок кылууга туура келет, анткени бизде NDA бар, макаланын мазмуну мындан жабыр тартпайт деп ишенебиз. Кеттик.
Долбоор кантип иштейт
Биздин артыбызда биз кардарыбыздын веб-сайттарынын жана мобилдик тиркемесинин иштешин камсыз кылган кызматтарды түзөбүз. Жалпы структурасын диаграммадан көрүүгө болот:
Иш процессинде биз көп сандагы транзакцияларды иштетебиз: сатып алуулар, төлөмдөр, колдонуучунун баланстары менен операциялар, алар үчүн биз көптөгөн журналдарды сактайбыз, ошондой эле бул маалыматтарды тышкы системаларга импорттоо жана экспорттоо.
Кардардан маалыматтарды алып, колдонуучуга өткөрүп бергенде тескери процесстер да бар. Мындан тышкары, төлөмдөр жана бонустук программалар менен иштөө процесстери дагы эле бар.
Кыскача фон
Башында биз PostgreSQLди жалгыз маалымат дүкөнү катары колдондук. МБС үчүн анын стандарттуу артыкчылыктары: транзакциялардын болушу, өнүккөн маалыматтарды тандап алуу тили, интеграциялоо үчүн инструменттердин кеңири спектри; жакшы аткаруу менен айкалышып, бир топ убакыт бою биздин муктаждыктарыбызды канааттандырды.
Биз Postgresте бардык маалыматтарды сактадык: транзакциялардан жаңылыктарга чейин. Бирок колдонуучулардын саны өсүп, аны менен бирге суроо-талаптардын саны өстү.
Түшүнүү үчүн, 2017-жылы бир гана десктоп сайтында сессиялардын жылдык саны 131 миллион. 2018-жылы - 125 миллион. 2019-жылы дагы 130 миллион. Сайттын мобилдик версиясынан жана мобилдик тиркемеден дагы 100-200 миллион кошуңуз, жана сиз көп суроо-талаптарды алат.
Долбоордун өсүшү менен Postgres жүктү көтөрө албай калды, бизде убакыт болгон жок - көп сандагы ар кандай сурамдар пайда болду, алар үчүн биз жетиштүү сандагы индекстерди түзө алган жокпуз.
Биз муктаждыктарыбызды камсыздай турган жана PostgreSQLдин жүгүн ала турган башка маалымат дүкөндөрүнүн зарылдыгы бар экенин түшүндүк. Мүмкүн болгон варианттар катары Elasticsearch жана MongoDB каралды. Акыркысы төмөнкү пункттар боюнча утулуп калды:
- Индекстердеги маалыматтардын көлөмү өскөн сайын индекстөө ылдамдыгы жай. Elastic менен ылдамдык маалыматтардын көлөмүнөн көз каранды эмес.
- Толук текст издөө жок
Ошентип, биз өзүбүз үчүн Elastic тандап жана өтүү үчүн даярдалган.
Эластикага өтүү
1. Биз өтүүнү сатуунун издөө кызматынан баштадык. Биздин кардарыбызда жалпысынан 70 000ге жакын соода түйүндөрү бар жана бул сайтта жана тиркемеде издөөнүн бир нече түрүн талап кылат:
- Шаардын аты боюнча текст издөө
- Кайсы бир чекиттен берилген радиуста геоиздөө. Мисалы, колдонуучу кайсы соода түйүндөрү анын үйүнө эң жакын экенин көргүсү келсе.
- Берилген квадрат боюнча издөө - колдонуучу картада квадрат тартат жана бул радиустагы бардык чекиттер ага көрсөтүлөт.
- Кошумча чыпкалар боюнча издөө. Соода точкалары бири-биринен ассортименти боюнча айырмаланат
Эгер уюм жөнүндө айта турган болсок, анда Postgresте бизде карта жана жаңылыктар үчүн маалымат булагы бар, ал эми Elastic Snapshots баштапкы маалыматтардан алынган. Негизи Postgres бардык критерийлер боюнча издөө менен күрөшө алган эмес. Индекстер көп эле эмес, алар бири-бирине дал келиши мүмкүн, ошондуктан Postgres пландоочусу адашып, кайсы индексти колдонууну түшүнгөн жок.
2. Кийинки кезекте жаңылыктар бөлүмү болду. Колдонуучу маалыматтын агымында адашып калбашы үчүн сайтта басылмалар күн сайын пайда болуп турат, маалымат берүүдөн мурун иргеп алуу керек. Бул издөө үчүн: сиз сайтты тексттин дал келүүсү боюнча издеп, ошол эле учурда кошумча чыпкаларды туташтыра аласыз, анткени алар да Elastic аркылуу жасалган.
3. Андан кийин биз транзакцияны иштетүүнү жылдырдык. Колдонуучулар сайттан белгилүү бир товарды сатып алып, утушка катыша алышат. Мындай сатып алуулардан кийин биз чоң көлөмдөгү маалыматтарды иштеп чыгабыз, айрыкча дем алыш жана майрам күндөрү. Салыштыруу үчүн, эгерде кадимки күндөрдө сатып алуулардын саны 1,5-2 миллиондун ортосунда болсо, майрам күндөрү бул көрсөткүч 53 миллионго жетиши мүмкүн.
Ошол эле учурда, маалыматтар мүмкүн болушунча кыска мөөнөттө иштелип чыгышы керек - колдонуучулар бир нече күн натыйжа күтүүнү жактырбайт. Postgres аркылуу мындай мөөнөткө жетүү мүмкүн эмес - биз көп учурда кулпуларды алып турчубуз жана биз бардык сурамдарды иштеп жаткан учурда, колдонуучулар сыйлыктарды алган-албаганын текшере алышкан эмес. Бул бизнес үчүн анча жагымдуу эмес, ошондуктан биз иштетүүнү Elasticsearch'ке жылдырдык.
мезгилдүүлүгү
Эми жаңыртуулар төмөнкү шарттарга ылайык окуяга негизделген конфигурацияланат:
- Сатуу пункттары. Сырткы булактан маалыматтарды алгандан кийин дароо жаңыртууну баштайбыз.
- Жаңылыктар. Сайтта кандайдыр бир жаңылык редакцияланганда, ал автоматтык түрдө Elasticке жөнөтүлөт.
Бул жерде дагы бир жолу Эластиктин артыкчылыктарын айта кетүү керек. Postgres'те суроо-талапты жөнөтүп жатканда, ал бардык жазууларды чынчылдык менен иштеткенге чейин күтүшүңүз керек. Сиз 10 XNUMX жазууну Elasticке жөнөтүп, жазуулардын бардык Shards боюнча таратылышын күтпөстөн, дароо иштей баштасаңыз болот. Албетте, кээ бир Shard же Replica маалыматтарды дароо көрбөй калышы мүмкүн, бирок баары жакында жеткиликтүү болот.
Интеграция ыкмалары
Elastic менен интеграциялоонун 2 жолу бар:
- TCP аркылуу жергиликтүү кардар аркылуу. Түпкү драйвер акырындык менен өлүп баратат: ал мындан ары колдоого алынбайт, ал абдан ыңгайсыз синтаксиске ээ. Ошондуктан, биз аны иш жүзүндө колдонбойбуз жана андан толук баш тартууга аракет кылабыз.
- JSON сурамдарын жана Lucene синтаксисин колдоно турган HTTP интерфейси аркылуу. Акыркысы - Elasticти колдонгон текст кыймылдаткычы. Бул версияда биз HTTP аркылуу JSON сурамдары аркылуу пакеттөө мүмкүнчүлүгүн алабыз. Бул биз колдонууга аракет кылып жаткан вариант.
HTTP интерфейсинин аркасында биз HTTP кардарын асинхрондук ишке ашырууну камсыз кылган китепканаларды колдоно алабыз. Биз Пакеттин жана асинхрондук API'нин артыкчылыктарын пайдалана алабыз, анын натыйжасында жогорку өндүрүмдүүлүк пайда болду, бул чоң жарнама күндөрүндө көп жардам берди (төмөндө бул тууралуу кененирээк)
Салыштыруу үчүн кээ бир сандар:
- Postgres сыйлыгынын колдонуучуларын 20 темада топтоосуз сактоо: 460713 секунданын ичинде 42 жазуу
- Эластик + 10 жип үчүн реактивдүү кардар + 1000 элемент үчүн партия: 596749 секунданын ичинде 11 жазуу
- Эластик + 10 жип үчүн реактивдүү кардар + 1000 элемент үчүн партия: 23801684 мүнөт ичинде 4 жазуу
Азыр биз HTTP сурам менеджерин жаздык, ал JSONди Пакет катары эмес, Пакет катары курат жана аны китепканага карабастан каалаган HTTP кардары аркылуу жөнөтөт. Сиз ошондой эле сурамдарды синхрондуу же асинхрондуу жөнөтүүнү тандай аласыз.
Кээ бир интеграцияларда биз дагы эле расмий транспорт кардарын колдонобуз, бирок бул кезектеги рефакторинг маселеси. Бул учурда, кайра иштетүү үчүн Spring WebClient негизинде курулган жеке кардар колдонулат.
чоң жарнама
Жылына бир жолу долбоор колдонуучулар үчүн чоң акция өткөрөт - бул ошол эле Highload, анткени азыркы учурда биз бир эле учурда он миллиондогон колдонуучулар менен иштейбиз.
Адатта жүктүн чокулары майрам учурунда болот, бирок бул жылдыруу таптакыр башка деңгээлде. Өткөн жылы, акция болгон күнү биз 27 580 890 даана товар сатканбыз. Маалыматтар жарым сааттан ашык иштетилип, колдонуучуларга ыңгайсыздык жараткан. Колдонуучулар катышуу үчүн сыйлыктарды алышты, бирок процессти тездетүү керек экени айкын болду.
2019-жылдын башында биз ElasticSearch керек деп чечтик. Бир жыл бою биз алынган маалыматтарды Elasticте иштетүүнү жана мобилдик тиркеменин жана веб-сайттын api аркылуу чыгарылышын уюштурдук. Натыйжада, кийинки жылы өнөктүк учурунда кайра иштеттик 15 мүнөт ичинде 131 783 6 жазуу.
Бизде товарларды сатып алып, акцияларга байге ойнотууга катышууну каалагандар көп болгондуктан, бул убактылуу чара. Азыр биз Elasticке акыркы маалыматты жөнөтүп жатабыз, бирок келечекте биз акыркы айлардагы архивделген маалыматты Postgresке туруктуу сактагыч катары өткөрүп берүүнү пландап жатабыз. Эластикалык индексти жаап албаш үчүн, анын да чектөөлөрү бар.
Корутунду/Корутундулар
Учурда биз каалаган кызматтардын баарын Elasticке өткөрүп бердик жана азырынча бул боюнча токтоп калдык. Азыр биз Postgresтеги негизги туруктуу сактагычтын үстүнө Эластикалык индексти куруп жатабыз, ал колдонуучунун жүгүн алат.
Келечекте, эгерде биз маалымат суроосу өтө ар түрдүү болуп, чексиз сандагы тилкелер үчүн изделсе, кызматтарды өткөрүп берүүнү пландаштырып жатабыз. Бул Postgres үчүн мындан ары милдет эмес.
Функционалдык жактан толук тексттик издөө керек болсо же бизде ар кандай издөө критерийлери көп болсо, анда биз муну Elastic тилине которуу керектигин билебиз.
⌘⌘⌘
окуганыңыз үчүн рахмат. Эгерде сиздин компанияңыз да ElasticSearch колдонсо жана өзүнүн ишке ашыруу учурлары болсо, анда бизге айтыңыз. Башкалардын кандай экенин билүү кызыктуу болот 🙂
Source: www.habr.com