Эй Хабр! Менің атым Максим Васильев, мен 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-ке жіберіледі.
Бұл жерде тағы да Elastic артықшылықтарын атап өткен жөн. Postgres-те сұрау жіберген кезде, ол барлық жазбаларды адал өңдегенше күту керек. Жазбалардың барлық Shards бойынша таратылуын күтпей-ақ, 10 XNUMX жазбаны Elastic бағдарламасына жіберіп, дереу жұмыс істей бастай аласыз. Әрине, кейбір Shard немесе Replica деректерді бірден көрмеуі мүмкін, бірақ бәрі жақын арада қолжетімді болады.
Интеграция әдістері
Elastic-пен біріктірудің 2 жолы бар:
- TCP арқылы жергілікті клиент арқылы. Жергілікті драйвер бірте-бірте өледі: оған енді қолдау көрсетілмейді, оның өте ыңғайсыз синтаксисі бар. Сондықтан біз оны іс жүзінде қолданбаймыз және одан толығымен бас тартуға тырысамыз.
- JSON сұрауларын да, Lucene синтаксисін де пайдалана алатын HTTP интерфейсі арқылы. Соңғысы - Elastic қолданатын мәтіндік қозғалтқыш. Бұл нұсқада HTTP арқылы JSON сұраулары арқылы Пакет жасау мүмкіндігін аламыз. Бұл біз қолдануға тырысатын опция.
HTTP интерфейсінің арқасында біз HTTP клиентінің асинхронды жүзеге асырылуын қамтамасыз ететін кітапханаларды пайдалана аламыз. Біз Batch және асинхронды API артықшылықтарын пайдалана аламыз, бұл жоғары өнімділікке әкеледі, бұл үлкен жарнама күндерінде көп көмектесті (төменде бұл туралы толығырақ)
Салыстыру үшін кейбір сандар:
- Postgres сыйақы пайдаланушыларын топтастырусыз 20 ағында сақтау: 460713 секундта 42 жазба
- Серпімді + 10 ағынға арналған реактивті клиент + 1000 элементке арналған пакет: 596749 секундта 11 жазба
- 10 ағынға арналған серпімді + реактивті клиент + 1000 элементке арналған топтама: 23801684 минутта 4 жазба
Енді біз JSON-ды пакеттік емес/бума ретінде құрастыратын және кітапханаға қарамастан кез келген HTTP клиенті арқылы жіберетін HTTP сұрау реттеушісін жаздық. Сұрауларды синхронды немесе асинхронды түрде жіберуді де таңдауға болады.
Кейбір интеграцияларда біз әлі де ресми көлік клиентін пайдаланамыз, бірақ бұл тек келесі рефакторинг мәселесі. Бұл жағдайда өңдеу үшін Spring WebClient негізінде құрылған пайдаланушы клиенті пайдаланылады.
үлкен жарнама
Жылына бір рет жоба пайдаланушылар үшін үлкен науқанды өткізеді - бұл бірдей Highload, өйткені қазір біз бір уақытта ондаған миллион пайдаланушылармен жұмыс істейміз.
Әдетте жүктемелердің шыңы мереке күндері болады, бірақ бұл науқан мүлдем басқа деңгейде. Өткен жылдың алдындағы акция күні біз 27 580 890 тауар бірлігін саттық. Деректер жарты сағаттан астам өңделді, бұл пайдаланушыларға қолайсыздық тудырды. Пайдаланушылар қатысқаны үшін сыйлықтар алды, бірақ процесті жеделдету қажет екені белгілі болды.
2019 жылдың басында біз ElasticSearch қажет деп шештік. Бір жыл бойы біз алынған деректерді Elastic бағдарламасында өңдеуді және оларды мобильді қосымша мен веб-сайттың api жүйесінде шығаруды ұйымдастырдық. Нәтижесінде келесі жылы науқан кезінде біз өңдедік 15 минутта 131 783 6 жазба.
Бізде тауар сатып алып, акциялардағы ұтыс ойынына қатысқысы келетіндер көп болғандықтан, бұл уақытша шара. Қазір біз Elastic-ке жаңартылған ақпаратты жіберіп жатырмыз, бірақ болашақта біз соңғы айлардағы мұрағатталған ақпаратты Postgres-ке тұрақты сақтау орны ретінде тасымалдауды жоспарлап отырмыз. Серпімділік индексін бітеп алмау үшін, оның да шектеулері бар.
Қорытынды/Қорытындылар
Қазіргі уақытта біз қалаған барлық қызметтерді Elastic-ке ауыстырдық және оны әзірге тоқтаттық. Енді біз Postgres-тегі негізгі тұрақты сақтаудың үстіне пайдаланушы жүктемесін қабылдайтын Эластикалық индексті құрастырамыз.
Болашақта деректер сұрауы тым әртүрлі болатынын және бағандардың шектеусіз санын іздейтінін түсінсек, қызметтерді тасымалдауды жоспарлап отырмыз. Бұл Postgres үшін енді тапсырма емес.
Функционалды түрде толық мәтінді іздеу қажет болса немесе бізде әртүрлі іздеу критерийлері көп болса, біз оны Elastic тіліне аудару керек екенін білеміз.
⌘⌘⌘
Оқығаныңыз үшін рахмет. Егер сіздің компанияңыз да ElasticSearch қолданбасын пайдаланса және өзінің іске асыру жағдайлары болса, бізге айтыңыз. Басқалардың қалай екенін білу қызықты болады 🙂
Ақпарат көзі: www.habr.com