Падаецца, што сфера інтэрнэт-рэкламы павінна быць максімальна тэхналагічнай і аўтаматызаванай. Яшчэ б, бо там працуюць такія гіганты і эксперты ў сваёй справе, як Яндэкс, Mail.Ru, Google і Facebook. Але, як аказалася, няма мяжы дасканаласці і заўсёды ёсць што аўтаматызаваць.
Камунікацыйная група Dentsu Aegis Network Belarus - Найбуйнейшы гулец на рэкламным digital рынку і актыўна інвесціруе ў тэхналогіі, спрабуючы ў аптымізаваць і аўтаматызаваць свае бізнес-працэсы. Адной з нявырашаных задач рынку інтэрнэт-рэкламы стала задача збору статыстыкі па рэкламных кампаніях з розных інтэрнэт-пляцовак. Рашэнне гэтай задачы ў выніку вылілася ў стварэнне прадукта D1.Digital (чытаць як ДиВан), аб распрацоўцы якога мы і жадаем распавесці.
Навошта?
1. На момант старту праекту на рынку не было ніводнага гатовага прадукта, вырашальнага задачу аўтаматызацыі збору статыстыкі па рэкламных кампаніях. Значыць, ніхто акрамя нас саміх не закрые нашы запатрабаванні.
Такія сэрвісы, як Improvado, Roistat, Supermetrics, SegmentStream, прапануюць інтэграцыю з пляцоўкамі, сацыяльнымі сеткамі і Google Analitycs, а таксама даюць магчымасць будаваць аналітычныя дашборды для зручнага аналізу і кантролю рэкламных кампаній. Перад тым, як пачаць развіваць свой прадукт, мы паспрабавалі выкарыстоўваць у працы некаторыя з гэтых сістэм для збору дадзеных з пляцовак, але, нажаль, яны не змаглі вырашыць нашых задач.
Галоўнай праблемай стала тое, што тэсціруемыя прадукты адштурхоўваліся ад крыніц дадзеных, адлюстроўваючы статыстыку месцаванняў у разрэзах па пляцоўках, і не давалі магчымасць агрэгаваць статыстыку па рэкламных кампаніях. Такі падыход не дазваляў убачыць статыстыку з розных пляцовак у адным месцы і прааналізаваць стан кампаніі цалкам.
Іншым фактарам стала тое, што на пачатковых этапах прадукты былі арыентаваны на заходні рынак і не падтрымліваў інтэграцыю з расейскімі пляцоўкамі. А па тых пляцоўках, з якімі была рэалізавана інтэграцыя, не заўсёды выгружаліся ўсе неабходныя метрыкі з дастатковай дэталізацыяй, а інтэграцыя не заўсёды была зручнай і празрыстай, асабліва калі трэба было атрымаць нешта, чаго няма ў інтэрфейсе сістэмы.
Увогуле, мы вырашылі не падладжвацца пад іншыя прадукты, а заняліся распрацоўкай свайго…
2. Рынак інтэрнэт-рэкламы расце з года ў год, і ў 2018 годзе па аб'ёме рэкламных бюджэтаў ён абагнаў традыцыйна найбуйнейшы рынак ТБ-рэкламы. Значыць, ёсць маштаб.
3. У адрозненне ад рынку ТБ-рэкламы, дзе продаж камерцыйнай рэкламы манапалізаваная, у Інтэрнэце працуе маса асобных уладальнікаў рэкламнага інвентара рознай велічыні са сваімі рэкламнымі кабінетамі. Так як рэкламная кампанія, як правіла, ідзе адразу на некалькіх пляцоўках, то для разумення стану рэкламнай кампаніі, трэба сабраць справаздачы з усіх пляцовак і звесці іх у адну вялікую справаздачу, якая пакажа карцінку цалкам. Значыць, ёсць патэнцыял для аптымізацыі.
4. Нам здавалася, што ў уладальнікаў рэкламнага інвентара ў інтэрнэце ўжо ёсць інфраструктура для збору статыстыкі і яе адлюстравання ў рэкламных кабінетах, і яны змогуць падаць API да гэтых дадзеных. Значыць, ёсць тэхнічная магчымасць рэалізацыі. Скажам адразу, што аказалася не ўсё так проста.
Увогуле, усе перадумовы для рэалізацыі праекту былі для нас відавочныя, і мы пабеглі ўвасабляць праект у жыццё…
Грандыёзны план
Для пачатку мы сфарміравалі бачанне ідэальнай сістэмы:
- У яе павінны аўтаматычна загружацца рэкламныя кампаніі з карпаратыўнай сістэмы 1С з іх назвамі, перыядамі, бюджэтамі і размяшчэннем па разнастайных пляцоўках.
- Для кожнага размяшчэння ўнутры рэкламнай кампаніі павінна аўтаматычна загружацца ўся магчымая статыстыка з пляцовак, на якіх ідзе размяшчэнне, такая як колькасць паказаў, клікаў, праглядаў і іншае.
- Некаторыя рэкламныя кампаніі адсочваюцца з дапамогай іншага маніторынгу так званымі adserving сістэмамі, такімі як Adriver, Weborama, DCM і т.д. Таксама ёсць індустрыяльны вымяральнік Інтэрнэту ў Расіі – кампанія Mediascope. Дадзеныя незалежнага і індустрыяльнага маніторынгаў па нашай задумцы таксама павінны аўтаматычна падгружацца да адпаведных рэкламных кампаній.
- Большасць рэкламных кампаній у Інтэрнэт накіраваны на пэўныя мэтавыя дзеянні (купля, званок, запіс на тэст-драйв і г.д.), якія адсочваюцца з дапамогай Google Analytics, і статыстыка па якіх таксама важная для разумення стану кампаніі і павінна загружацца ў наш інструмент .
Першы блін комам
Улічваючы нашу прыхільнасць да гнуткіх прынцыпаў распрацоўкі ПЗ (agile, усе справы), мы вырашылі спачатку распрацаваць MVP і далей рухацца да вызначанай мэты ітэратыўна.
MVP мы вырашылі будаваць на аснове нашага прадукта DANBo (Dentsu Aegis Network Board), які прадстаўляе з сябе web дадатак з агульнай інфармацыяй па рэкламных кампаніях нашых кліентаў.
Для MVP праект быў максімальна спрошчаны з пункту гледжання рэалізацыі. Мы выбралі абмежаваны спіс пляцовак для інтэграцыі. Гэта былі асноўныя пляцоўкі, такія як Яндэкс.Дырэкт, Яндэкс.Дысплей, RB.Mail, MyTarget, Adwords, DBM, VK, FB, і асноўныя adserving сістэмы Adriver і Weborama.
Для доступу да статыстыкі на пляцоўках праз API мы выкарыстоўвалі адзіны акаўнт. Мэнэджар кліенцкай групы, які хацеў выкарыстоўваць аўтаматычны збор статыстыкі па рэкламнай кампаніі, павінен быў спачатку дэлегаваць доступ да патрэбных рэкламных кампаній на пляцоўках на акаўнт платформы.
Далей карыстальнік сістэмы DANBo павінен быў загрузіць у сістэму Excel файл вызначанага фармату, у якім была прапісаная ўся інфармацыя аб размяшчэнні (рэкламная кампанія, пляцоўка, фармат, перыяд размяшчэння, планавыя паказчыкі, бюджэт і г.д.) і ідэнтыфікатары адпаведных рэкламных кампаній на пляцоўках і лічыльнікаў у adserving сістэмах.
Выглядала гэта, шчыра кажучы, жахліва:
Загружаныя дадзеныя захоўваліся ў базу дадзеных, а потым асобныя сервісы збіралі з іх ідэнтыфікатары кампаній на пляцоўках і загружалі па іх статыстыку.
Для кожнай пляцоўкі быў напісаны асобны windows сэрвіс, які раз у суткі хадзіў пад адным службовым акаўнтам у API пляцоўкі і выгружаў статыстыку па зададзеных ідэнтыфікатарах кампаній. Аналагічна адбывалася і з adserving сістэмамі.
Загружаныя дадзеныя адлюстроўваліся на інтэрфейсе ў выглядзе невялікага самапіснага дашборда:
Нечакана для нас саміх MVP зарабіў і пачаў загружаць актуальную статыстыку па рэкламных кампаніях у Інтэрнеце. Мы ўкаранілі сістэму на некалькіх кліентах, але пры спробе маштабавання натрапілі на сур'ёзныя праблемы:
- Галоўная праблема была ў працаёмкасці падрыхтоўкі даных для загрузкі ў сістэму. Таксама дадзеныя па размяшчэнні трэба было прыводзіць да строга фіксаванага фармату перад загрузкай. У файл для загрузкі трэба было прапісваць ідэнтыфікатары сутнасцяў з розных пляцовак. Мы сутыкнуліся з тым, што тэхнічна непадрыхтаваным карыстальнікам вельмі цяжка растлумачыць, дзе знайсці гэтыя ідэнтыфікатары на пляцоўцы і куды ў файле іх трэба праставіць. Улічваючы колькасць супрацоўнікаў у падраздзяленнях, якія вядуць кампаніі на пляцоўках, і цякучку, гэта вылілася ў вялізны аб'ём падтрымкі на нашым баку, што нас катэгарычна не задавальняла.
- Іншай праблемай было тое, што не на ўсіх рэкламных пляцоўках былі механізмы дэлегавання доступу да рэкламных кампаній на іншыя акаўнты. Але нават калі механізм дэлегавання быў даступны, не ўсе рэкламадаўцы былі гатовы прадастаўляць доступ да сваіх кампаній іншым акаўнтам.
- Немалаважным стаў фактар абурэння, якое ў карыстальнікаў выклікала тое, што ўсе планавыя паказчыкі і дэталі размяшчэння, якія яны ўжо ўносяць у нашу ўліковую 1С сістэму, яны павінны паўторна ўносіць і ў DANBo.
Гэта наштурхнула нас на думку, што першакрыніцай інфармацыі аб размяшчэнні павінна служыць наша 1С сістэма, у якую ўсе дадзеныя ўносяцца акуратна і ў тэрмін (тут справа ў тым, што на падставе дадзеных 1С фармуюцца рахункі, таму карэктнае ўнясенне дадзеных у 1С варта ва ўсіх у KPI). Так з'явілася новая канцэпцыя сістэмы…
Канцэпцыя
Першае, што мы вырашылі зрабіць, гэта вылучыць сістэму збору статыстыкі па рэкламных кампаніях у Інтэрнэт у асобны прадукт. D1.Digital.
У новай канцэпцыі мы вырашылі загружаць у D1.Digital інфармацыю па рэкламных кампаніях і месцах усярэдзіне іх з 1С, а потым падцягваць да гэтых месцаванняў статыстыку з пляцовак і з AdServing сістэм. Гэта павінна было значна спрасціць жыццё карыстальнікам (і, як водзіцца, дадаць працы распрацоўшчыкам) і зменшыць аб'ём падтрымкі.
Першая праблема, з якой мы сутыкнуліся, была арганізацыйнага характару і звязана з тым, што мы не змаглі знайсці ключ або прыкмету, па якой можна было б супаставіць сутнасці з розных сістэм з кампаніямі і размяшчэння з 1С. Справа ў тым, што працэс у нашай кампаніі ўладкованы так, што рэкламныя кампаніі ў розныя сістэмы заносяцца рознымі людзьмі (медыяпленеры, баінг і інш.).
Каб вырашыць гэтую праблему, нам прыйшлося вынайсці ўнікальны хэшаваны ключ, DANBoID, які б звязваў сутнасці ў розных сістэмах разам, і які можна было б даволі лёгка і адназначна ідэнтыфікаваць у загружаных наборах дадзеных. Гэты ідэнтыфікатар генеруецца ва ўнутранай 1С сістэме для кожнага асобнага размяшчэння і прачынаецца ў кампаніі, размяшчэння і лічыльнікі на ўсіх пляцоўках і ва ўсіх AdServing сістэмах. Укараненне практыкі прастаўлення DANBoID ва ўсе размяшчэнні заняло пэўны час, але мы з гэтым справіліся 🙂
Далей мы высветлілі, што далёка не ва ўсіх пляцовак ёсць API для аўтаматычнага збору статыстыкі, і нават у тых, у якіх API ёсць, ён вяртае не ўсе патрэбныя даныя.
На гэтым этапе мы вырашылі значна скараціць спіс пляцовак для інтэграцыі і засяродзіцца на асноўных пляцоўках, якія задзейнічаны ў пераважнай большасці рэкламных кампаній. У гэты спіс патрапілі ўсе найбуйныя гульцы рэкламнага рынка (Google, Яндэкс, Mail.ru), сацыяльныя сеткі (VK, Facebook, Twitter), асноўныя сістэмы AdServing і аналітыкі (DCM, Adriver, Weborama, Google Analytics) і іншыя пляцоўкі.
У асноўнай масы абраных намі пляцовак быў API, які аддаваў неабходныя нам метрыкі. У тых выпадках, калі API не было, альбо ў ім не было патрэбных дадзеных, для загрузкі дадзеных мы выкарыстоўвалі справаздачы, якія штодня прыходзяць на службовую пошту (у адных сістэмах ёсць магчымасць настройкі такіх справаздач, у іншых узгаднілі распрацоўку такіх справаздач для нас).
Пры аналізе дадзеных з розных пляцовак мы высветлілі, што іерархія сутнасцей не аднолькавая ў розных сістэмах. Больш за тое, з розных сістэм інфармацыю неабходна загружаць у рознай дэталізацыі.
Для вырашэння гэтай праблемы была распрацавана канцэпцыя SubDANBoID. Ідэя SubDANBoID даволі простая, мы адзначаем асноўную сутнасць кампаніі на пляцоўцы згенераваным DANBoID, а ўсе ўкладзеныя сутнасці мы выгружаем з унікальнымі ідэнтыфікатарамі пляцоўкі і фармуем SubDANBoID па прынцыпе DANBoID + ідэнтыфікатар укладзенай сутнасці ўзроўню + вязаць рэкламныя кампаніі ў розных сістэмах і выгрузіць дэталізаваную статыстыку па іх.
Таксама нам прыйшлося вырашаць праблему доступу да кампаній на розных пляцоўках. Як мы ўжо пісалі вышэй, механізм дэлегавання доступу да кампаніі на асобны тэхнічны рахунак не заўсёды прымяняльны. Таму нам прыйшлося распрацаваць інфраструктуру для аўтаматычнай аўтарызацыі праз OAuth з выкарыстаннем токенаў і механізмы абнаўлення гэтых токенаў.
Далей у артыкуле паспрабуем больш падрабязна апісаць архітэктуру рашэння і тэхнічныя дэталі рэалізацыі.
Архітэктура рашэння 1.0
Пачынаючы рэалізацыю новага прадукта, мы разумелі, што адразу трэба прадугледзець магчымасць падлучэння новых пляцовак, таму вырашылі пайсці па шляху мікрасэрвіснай архітэктуры.
Пры праектаванні архітэктуры мы вылучылі ў асобныя сэрвісы канектары да ўсіх вонкавых сістэм – 1С, рэкламным пляцоўкам і adserving сістэмам.
Асноўная ідэя складаецца ў тым, што ўсе канектары да пляцовак маюць аднолькавае API і ўяўляюць сабой адаптары, якія прыводзяць API пляцовак да зручнага нам інтэрфейсу.
У цэнтры нашага прадукта — вэб-дадатак, які ўяўляе сабой маналіт, які спраектаваны такім чынам, каб яго можна было лёгка разабраць на сэрвісы. Гэта дадатак адказвае за апрацоўку загружаных дадзеных, супастаўленне статыстыкі з розных сістэм і прадстаўленне яе карыстальнікам сістэмы.
Для зносін канектараў з вэб-дадаткам прыйшлося стварыць дадатковы сэрвіс, які мы назвалі Connector Proxy. Ён выконвае функцыі Service Discovery і Task Scheduler. Гэты сэрвіс кожную ноч запускае задачы збору дадзеных для кожнага канектара. Напісаць сэрвіс-праслойку было прасцей, чым падлучаць брокер паведамленняў, а для нас было важна атрымаць вынік як мага хутчэй.
Для прастаты і хуткасці распрацоўкі мы таксама вырашылі, што ўсе сервісы будуць уяўляць сабой Web API. Гэта дазволіла хутка сабраць proof-of-concept і праверыць, што ўся канструкцыя працуе.
Асобнай, дастаткова складанай, задачай аказалася настройка доступаў для збору даных з розных кабінетаў, якая, як мы вырашылі, павінна ажыццяўляцца карыстальнікамі праз вэб-інтэрфейс. Яна складаецца з двух асобных крокаў: спачатку карыстач праз OAuth дадае токен для доступу да акаўнта, а потым наладжвае збор дадзеных для кліента з вызначанага кабінета. Атрыманне токена праз OAuth неабходна, таму што, як мы ўжо пісалі, не заўсёды магчыма дэлегаваць доступ да патрэбнага кабінета на пляцоўцы.
Каб стварыць універсальны механізм выбару кабінета з пляцовак, нам прыйшлося дадаць у API канектараў метад, які аддае JSON Schema, якая рэндэрыцца ў форму пры дапамозе мадыфікаванага кампанента JSONEditor. Так карыстачы змаглі выбіраць акаўнты, з якіх неабходна загружаць дадзеныя.
Каб выконваць ліміты запытаў, якія існуюць на пляцоўках, мы аб'ядноўваем запыты па наладах у рамках аднаго токена, але розныя токены можам апрацоўваць раўналежна.
У якасці сховішча для загружаных дадзеных як для вэба-прыкладанні, так і для канектараў мы абралі MongoDB, што дазволіла не моцна затлумляцца з нагоды структуры дадзеных на пачатковых этапах распрацоўкі, калі аб'ектная мадэль прыкладання змяняецца праз дзень.
Хутка мы высветлілі, што не ўсе дадзеныя добра кладуцца ў MongoDB і, напрыклад, статыстыку па днях зручней захоўваць у рэляцыйнай базе. Таму для канектараў, структура дадзеных якіх больш падыходзіць пад рэляцыйную БД, у якасці сховішчы мы пачалі выкарыстоўваць PostgreSQL ці MS SQL Server.
Абраная архітэктура і тэхналогіі дазволілі нам адносна хутка пабудаваць і запусціць прадукт D1.Digital. За два гады развіцця прадукта мы распрацавалі 23 канектара да пляцовак, атрымалі бясцэнны досвед працы са іншымі API, навучыліся абыходзіць падводныя камяні розных пляцовак, якія ў кожнай апынуліся свае, спрыялі развіццю API як мінімум 3 пляцовак, аўтаматычна загрузілі інфармацыю па амаль 15 000 кампаній і па больш за 80 000 месцаванняў, сабралі шмат зваротнай сувязі ад карыстачоў па працы прадукта і паспелі некалькі разоў памяняць асноўны працэс працы прадукта, засноўваючыся на гэтай зваротнай сувязі.
Архітэктура рашэння 2.0
Прайшло два гады пасля старту распрацоўкі D1.Digital. Пастаянны рост нагрузкі на сістэму і з'яўленне ўсё новых крыніц дадзеных паступова выявілі праблемы ў існуючай архітэктуры рашэння.
Першая праблема звязана з аб'ёмам дадзеных, якія загружаюцца з пляцовак. Мы сутыкнуліся з тым, што збор і абнаўленне ўсіх неабходных даных з самых вялікіх пляцовак стала займаць занадта шмат часу. Напрыклад, збор дадзеных па adserving сістэме AdRiver, з дапамогай якой мы адсочваем статыстыку па большай частцы месцаванняў, займае каля 12 гадзін.
Каб вырашыць гэтую праблему, мы пачалі выкарыстоўваць разнастайныя справаздачы для загрузкі дадзеных з пляцовак, спрабуем развіваць разам з пляцоўкамі іх API, каб хуткасць яго працы задавальняла нашым патрэбам, і раўналежваць загрузку дадзеных, на колькі гэта магчыма.
Іншая праблема звязана з апрацоўкай загружаных дадзеных. Цяпер пры паступленні новай статыстыкі па размяшчэнні, запускаецца шматступенны працэс пераліку метрык, які ўключае ў сябе загрузку сырых дадзеных, пралік агрэгаваных метрык па кожнай пляцоўцы, супастаўленне дадзеных з розных крыніц паміж сабой і разлік зводных метрык па кампаніі. Гэта выклікае вялікую нагрузку на вэб-дадатак, якое вырабляе ўсе разлікі. Некалькі разоў прыкладанне падчас пералікаў з'ядала ўсю памяць на серверы, парадку 10-15 Гб, што самай згубнай выявай адбівалася на працы карыстачоў з сістэмай.
Пазначаныя праблемы і грандыёзныя планы на далейшае развіццё прадукта прывялі нас да неабходнасці перагледзець архітэктуру прыкладання.
Пачалі мы з канектараў.
Мы заўважылі, што ўсе канектары працуюць па адной мадэлі, таму пабудавалі фрэймворк-канвеер, у якім для стварэння канектара трэба было толькі запраграмаваць логіку крокаў, астатняе было ўніверсальным. Калі нейкі канектар патрабуе дапрацоўкі, то мы адначасова з дапрацоўкай канектара адразу перакладаем яго на новы фрэймворк.
Паралельна мы пачалі размяшчаць канектары ў докер і Kubernetes.
Пераезд у Kubernetes планавалі даволі доўга, эксперыментавалі з наладамі CI/CD, але пераязджаць пачалі толькі тады, калі адзін канектар з-за памылкі стаў ад'ядаць больш за 20 Гб памяці на серверы, практычна забіваючы астатнія працэсы. На час расследавання канектар перасялілі ў кластар Kubernetes, дзе ён у выніку і застаўся, нават калі памылка была выпраўлена.
Даволі хутка мы зразумелі, што Kubernetes гэта зручна, і за паўгода перанеслі ў кластар прадакшэна 7 канектараў і Connectors Proxy, якія спажываюць больш за ўсё рэсурсаў.
Услед за канектарамі мы вырашылі мяняць архітэктуру астатняга прыкладання.
Асноўнай праблемай было тое, што дадзеныя прыходзяць з канектараў у проксі вялікімі пачкамі, а потым б'юцца па DANBoID і аддаюцца ў цэнтральнае web прыкладанне для апрацоўкі. З-за вялікай колькасці пералікаў метрык узнікае вялікая нагрузка на дадатак.
Таксама аказалася даволі складана маніторыць статусы асобных заданняў на збор дадзеных і перадаваць памылкі, якія адбываюцца ўнутры канектараў, у цэнтральны web дадатак, каб карыстальнікі маглі бачыць, што адбываецца, і з-за чаго не збіраюцца дадзеныя.
Для вырашэння гэтых праблем мы распрацавалі архітэктуру 2.0.
Галоўнае адрозненне новай версіі архітэктуры складаецца ў тым, што замест Web API мы выкарыстаем RabbitMQ і бібліятэку MassTransit для абмену паведамленнямі паміж сэрвісамі. Для гэтага прыйшлося практычна цалкам перапісаць Connectors Proxy, зрабіўшы з яго Connectors Hub. Назва памянялі таму, што асноўная роля сэрвісу зараз не ў пракідзе запытаў у канектары і назад, а ў кіраванні зборам метрык з канектараў.
З цэнтральнага web прыкладання мы вылучылі ў асобныя сэрвісы інфармацыю аб месцаваннях і статыстыку з пляцовак, што дало магчымасць пазбавіцца ад лішніх пералікаў і на ўзроўні месцаванняў захоўваць толькі ўжо разлічаную і агрэгаваную статыстыку. Таксама мы перапісалі і аптымізавалі логіку разліку асноўных статыстык на аснове волкіх дадзеных.
Паралельна мы пераносім усе сэрвісы і прыкладанні ў докер і Kubernetes, каб рашэнне прасцей маштабавалася і ім было зручна кіраваць.
Дзе мы зараз
Proof-of-concept архітэктуры 2.0 прадукта D1.Digital гатовы і працуе ў тэставым асяроддзі з абмежаваным наборам канектараў. Справа за малым - перапісаць яшчэ 20 канектараў на новую платформу, пратэставаць, што дадзеныя карэктна загружаюцца, а ўсе метрыкі правільна лічацца, і выкаціць усю канструкцыю ў прадакшн.
Насамрэч, гэты працэс будзе адбывацца паступова і нам давядзецца пакінуць зваротную сумяшчальнасць са старымі API, каб усё працягвала працаваць.
У бліжэйшых нашых планах стаіць распрацоўка новых канектараў, інтэграцыя з новымі сістэмамі і даданне дадатковых метрык у набор дадзеных, якія выгружаюцца з падлучаных пляцовак і adserving сістэм.
Таксама плануем перанесці ўсе прыкладанні, у тым ліку і цэнтральнае web дадатак, у докер і Kubernetes. У спалучэнні з новай архітэктурай, гэта дазволіць прыкметна спрасціць разгортванне, маніторынг і кантроль спажываных рэсурсаў.
Яшчэ ёсць ідэя паэксперыментаваць з выбарам БД для захоўвання статыстыкі, якая зараз захоўваецца ў MongoDB. Некалькі новых канектараў мы ўжо перавялі на SQL-базы, але там розніца амаль незаўважная, а для агрэгаванай статыстыкі па днях, якую можна запытваць за адвольны перыяд, выйгрыш можа быць дастаткова сур'ёзным.
Увогуле, планы грандыёзныя, рухаемся далей 🙂
Аўтары артыкула R&D Dentsu Aegis Network Russia: Георгій Астапенка (), Міхаіл Коцік ()
Крыніца: habr.com