온라인 사이트에서 광고 캠페인에 대한 데이터를 수집하는 방법(제품에 대한 까다로운 경로)

온라인 광고 분야는 기술적으로 최대한 발전하고 자동화되어야 하는 것 같습니다. 물론 Yandex, Mail.Ru, Google 및 Facebook과 같은 해당 분야의 거인과 전문가가 그곳에서 일하기 때문입니다. 그러나 알고 보니 완벽함에는 한계가 없으며 항상 자동화할 부분이 있습니다.

출처

커뮤니케이션 그룹 Dentsu Aegis 네트워크 러시아 디지털 광고 시장에서 가장 큰 기업이며 기술에 적극적으로 투자하고 비즈니스 프로세스를 최적화하고 자동화하려고 노력하고 있습니다. 온라인 광고 시장의 해결되지 않은 문제 중 하나는 다양한 인터넷 플랫폼의 광고 캠페인에 대한 통계를 수집하는 작업이 되었습니다. 이 문제를 해결한 결과, 결국 제품이 탄생하게 되었습니다. D1.디지털 (DiVan으로 읽음), 우리가 이야기하고 싶은 개발입니다.

이유는 무엇입니까?

1. 프로젝트 시작 당시 광고 캠페인 통계 수집 자동화 문제를 해결한 기성품은 시장에 단 하나도 없었습니다. 이는 우리 자신 외에는 어느 누구도 우리의 필요를 충족시키지 못한다는 것을 의미합니다.

Improvado, Roistat, Supermetrics, SegmentStream과 같은 서비스는 플랫폼, 소셜 네트워크 및 Google Analitycs와의 통합을 제공하고 광고 캠페인을 편리하게 분석하고 제어하기 위한 분석 대시보드를 구축할 수도 있습니다. 제품 개발을 시작하기 전에 우리는 이러한 시스템 중 일부를 사용하여 사이트에서 데이터를 수집하려고 시도했지만 불행히도 문제를 해결할 수 없었습니다.

가장 큰 문제는 테스트한 제품이 데이터 소스를 기반으로 사이트별 배치 통계를 표시하고 광고 캠페인에 대한 통계를 집계하는 기능을 제공하지 않았다는 것입니다. 이 접근 방식으로는 여러 사이트의 통계를 한 곳에서 확인하고 캠페인 상태를 전체적으로 분석할 수 없었습니다.

또 다른 요인은 초기 단계에서 제품이 서구 시장을 겨냥했고 러시아 사이트와의 통합을 지원하지 않았다는 것입니다. 그리고 통합이 구현된 사이트의 경우 필요한 모든 측정항목이 항상 충분히 자세하게 다운로드되지는 않았으며 통합이 항상 편리하고 투명한 것은 아니었습니다. 특히 시스템 인터페이스에 없는 항목을 가져와야 하는 경우에는 더욱 그렇습니다.
일반적으로 우리는 타사 제품에 적응하지 않기로 결정하고 자체 개발을 시작했습니다...

2. 온라인 광고 시장은 해마다 성장하고 있으며, 2018년에는 광고 예산 측면에서 전통적으로 가장 큰 TV 광고 시장을 추월했습니다. 그래서 규모가 있습니다.

3. 상업용 광고의 판매가 독점되는 TV광고 시장과 달리, 인터넷상에서는 자신의 광고 계정을 가지고 운영되는 다양한 규모의 광고 인벤토리를 개인 소유주들이 많이 운영하고 있습니다. 일반적으로 광고 캠페인은 여러 사이트에서 동시에 실행되므로 광고 캠페인의 상태를 이해하려면 모든 사이트에서 보고서를 수집하여 전체 그림을 표시하는 하나의 큰 보고서로 결합해야 합니다. 이는 최적화 가능성이 있음을 의미합니다.

4. 인터넷 광고 인벤토리 소유자는 이미 통계를 수집하고 이를 광고 계정에 표시할 수 있는 인프라를 갖추고 있으며 이 데이터에 대한 API를 제공할 수 있을 것으로 보입니다. 이는 기술적으로 구현이 가능하다는 것을 의미합니다. 그렇게 간단하지 않은 것으로 판명되었다고 즉시 가정 해 봅시다.

일반적으로 프로젝트 구현을 위한 모든 전제 조건은 우리에게 분명했고 우리는 프로젝트에 생명을 불어넣기 위해 달려갔습니다...

그랜드 플랜

우선 우리는 이상적인 시스템에 대한 비전을 세웠습니다.

• 1C 기업 시스템의 광고 캠페인은 다양한 플랫폼의 이름, 기간, 예산 및 배치와 함께 자동으로 로드되어야 합니다.
• 광고 캠페인 내의 각 게재위치에 대해 노출수, 클릭수, 조회수 등과 같은 가능한 모든 통계가 게재위치가 이루어지는 사이트에서 자동으로 다운로드되어야 합니다.
• 일부 광고 캠페인은 Adriver, Weborama, DCM 등과 같은 소위 광고 시스템에 의한 제XNUMX자 모니터링을 사용하여 추적됩니다. 러시아에는 Mediascope 회사인 산업용 인터넷 측정기도 있습니다. 우리 계획에 따르면 독립 및 산업 모니터링의 데이터도 해당 광고 캠페인에 자동으로 로드되어야 합니다.
• 인터넷상의 대부분의 광고 캠페인은 Google Analytics를 사용하여 추적되는 특정 타겟 행동(구매, 전화, 시승 신청 등)을 목표로 하며, 이에 대한 통계는 캠페인 상태를 이해하는 데에도 중요합니다. 우리 도구에 로드되어야 합니다.

첫 번째 팬케이크는 울퉁불퉁하다.

소프트웨어 개발의 유연한 원칙(민첩성, 모든 것)에 대한 약속을 고려하여 먼저 MVP를 개발한 다음 의도한 목표를 향해 반복적으로 이동하기로 결정했습니다.
우리는 우리 제품을 기반으로 MVP를 구축하기로 결정했습니다. DANBo (Dentsu Aegis 네트워크 보드)는 고객의 광고 캠페인에 대한 일반 정보가 포함된 웹 애플리케이션입니다.

MVP의 경우 구현 측면에서 프로젝트를 최대한 단순화했습니다. 우리는 통합을 위해 제한된 플랫폼 목록을 선택했습니다. 이는 Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB 및 주요 광고 시스템인 Adriver 및 Weborama와 같은 주요 플랫폼이었습니다.

API를 통해 사이트 통계에 액세스하기 위해 우리는 단일 계정을 사용했습니다. 광고 캠페인에 대한 자동 통계 수집 기능을 사용하려는 클라이언트 그룹 관리자는 먼저 사이트에서 필요한 광고 캠페인에 대한 액세스 권한을 플랫폼 계정에 위임해야 했습니다.

다음은 시스템 사용자입니다. 단보 배치(광고 캠페인, 플랫폼, 형식, 배치 기간, 계획 지표, 예산 등)에 대한 모든 정보와 해당 광고 캠페인의 식별자가 포함된 특정 형식의 파일을 Excel 시스템에 업로드해야 했습니다. 광고 시스템의 사이트 및 카운터.

솔직히 말해서 끔찍해 보였습니다.

다운로드된 데이터는 데이터베이스에 저장된 후 별도의 서비스가 해당 사이트의 캠페인 식별자를 수집하고 이에 대한 통계를 다운로드했습니다.

각 사이트마다 별도의 Windows 서비스가 작성되었으며, 하루에 한 번 사이트 API의 하나의 서비스 계정으로 이동하여 지정된 캠페인 ID에 대한 통계를 다운로드했습니다. 광고 시스템에서도 같은 일이 일어났습니다.

다운로드된 데이터는 작은 사용자 정의 대시보드 형태로 인터페이스에 표시되었습니다.

예기치 않게 MVP가 작업을 시작하고 인터넷 광고 캠페인에 대한 최신 통계를 다운로드하기 시작했습니다. 우리는 여러 클라이언트에 시스템을 구현했지만 확장을 시도할 때 심각한 문제에 직면했습니다.

• 가장 큰 문제는 시스템에 로드할 데이터를 준비하는 과정이 복잡하다는 점이었습니다. 또한 배치 데이터는 로드하기 전에 엄격하게 고정된 형식으로 변환되어야 했습니다. 다운로드 파일에는 다양한 사이트의 엔터티 식별자를 포함해야 했습니다. 우리는 기술적으로 훈련받지 않은 사용자가 사이트에서 이러한 식별자를 찾을 수 있는 위치와 파일에서 입력해야 하는 위치를 설명하는 것이 매우 어렵다는 사실에 직면했습니다. 현장에서 캠페인을 진행하는 부서의 직원 수와 매출액을 고려하면 이는 우리 측에서 엄청난 지원을 제공하는 결과를 가져왔고 우리는 전혀 만족하지 못했습니다.
• 또 다른 문제는 모든 광고 플랫폼에 광고 캠페인에 대한 액세스 권한을 다른 계정에 위임하는 메커니즘이 없다는 것입니다. 그러나 위임 메커니즘을 사용할 수 있더라도 모든 광고주가 제XNUMX자 계정에 캠페인에 대한 액세스 권한을 부여할 의향이 있는 것은 아닙니다.
• 중요한 요소는 이미 1C 회계 시스템에 입력한 모든 계획 지표 및 배치 세부 사항을 다시 입력해야 한다는 사실로 인해 사용자들 사이에서 불러일으킨 분노였습니다. 단보.

이를 통해 배치에 대한 정보의 주요 소스는 모든 데이터가 정확하고 제 시간에 입력되는 1C 시스템이어야 한다는 아이디어를 얻었습니다. 여기서 요점은 송장이 1C 데이터를 기반으로 생성되므로 1C에 데이터를 올바르게 입력한다는 것입니다. 모든 KPI의 우선순위입니다). 이것이 시스템의 새로운 개념이 등장한 방법입니다.

개념

우리가 가장 먼저 결정한 것은 인터넷 광고 캠페인에 대한 통계 수집 시스템을 별도의 제품으로 분리하는 것이었습니다. D1.디지털.

새로운 컨셉으로 우리는 D1.디지털 1C에서 광고 캠페인 및 그 안의 게재위치에 대한 정보를 가져온 다음 사이트 및 AdServing 시스템에서 이러한 게재위치로 통계를 가져옵니다. 이는 사용자의 삶을 크게 단순화하고(평소와 마찬가지로 개발자에게 더 많은 작업을 추가) 지원 금액을 줄이는 것으로 예상되었습니다.

우리가 직면한 첫 번째 문제는 조직적 성격이었으며 1C의 캠페인 및 배치와 다른 시스템의 엔터티를 비교할 수 있는 키나 기호를 찾을 수 없다는 사실과 관련이 있었습니다. 사실 우리 회사의 프로세스는 광고 캠페인이 다양한 사람(미디어 기획자, 구매 등)에 의해 다양한 시스템에 입력되는 방식으로 설계되었습니다.

이 문제를 해결하기 위해 우리는 서로 다른 시스템의 엔터티를 함께 연결하고 다운로드한 데이터 세트에서 상당히 쉽고 고유하게 식별할 수 있는 고유한 해시 키인 DANBoID를 개발해야 했습니다. 이 식별자는 각 개별 게재위치에 대한 내부 1C 시스템에서 생성되며 모든 사이트와 모든 AdServing 시스템의 캠페인, 게재위치 및 카운터로 전송됩니다. 모든 배치에 DANBoID를 넣는 연습을 구현하는 데는 시간이 좀 걸렸지만 성공적으로 수행했습니다 :)

그런 다음 모든 사이트에 자동으로 통계를 수집하는 API가 있는 것은 아니며 API가 있는 사이트라도 필요한 모든 데이터를 반환하지 않는다는 사실을 발견했습니다.

이 단계에서 우리는 통합할 플랫폼 목록을 크게 줄이고 대부분의 광고 캠페인과 관련된 주요 플랫폼에 집중하기로 결정했습니다. 이 목록에는 광고 시장(Google, Yandex, Mail.ru), 소셜 네트워크(VK, Facebook, Twitter), 주요 AdServing 및 분석 시스템(DCM, Adriver, Weborama, Google Analytics) 및 기타 플랫폼의 모든 최대 플레이어가 포함됩니다.

우리가 선택한 대부분의 사이트에는 우리가 필요로 하는 측정항목을 제공하는 API가 있었습니다. API가 없거나 필요한 데이터가 포함되지 않은 경우 매일 사무실 이메일로 전송되는 보고서를 사용하여 데이터를 로드했습니다(일부 시스템에서는 이러한 보고서를 구성할 수 있고 다른 시스템에서는 해당 보고서 개발에 동의함) 우리를 위해).

여러 사이트의 데이터를 분석할 때 엔터티의 계층 구조가 서로 다른 시스템에서 동일하지 않다는 사실을 발견했습니다. 더욱이 정보는 다양한 시스템에서 다양한 세부정보를 다운로드해야 합니다.

이 문제를 해결하기 위해 SubDANBoID 개념이 개발되었습니다. SubDANBoID의 아이디어는 매우 간단합니다. 생성된 DANBoID로 사이트에서 캠페인의 주요 엔터티를 표시하고 고유한 사이트 식별자로 모든 중첩 엔터티를 업로드하고 DANBoID 원칙 + 첫 번째 수준의 식별자에 따라 SubDANBoID를 형성합니다. 중첩 엔터티 + 두 번째 수준 중첩 엔터티의 식별자 +... 이 접근 방식을 통해 우리는 다양한 시스템의 광고 캠페인을 연결하고 이에 대한 자세한 통계를 다운로드할 수 있었습니다.

또한 다양한 플랫폼에서 캠페인에 접근하는 문제도 해결해야 했습니다. 위에서 쓴 것처럼 캠페인에 대한 액세스 권한을 별도의 기술 계정에 위임하는 메커니즘이 항상 적용되는 것은 아닙니다. 따라서 우리는 토큰과 이러한 토큰을 업데이트하는 메커니즘을 사용하여 OAuth를 통한 자동 인증을 위한 인프라를 개발해야 했습니다.

이 기사의 뒷부분에서는 솔루션의 아키텍처와 구현의 기술적 세부 사항을 더 자세히 설명하려고 합니다.

솔루션 아키텍처 1.0

새로운 제품의 구현을 시작할 때 새로운 사이트 연결 가능성을 즉시 제공해야 한다는 것을 이해하고 마이크로서비스 아키텍처의 길을 따르기로 결정했습니다.

아키텍처를 설계할 때 모든 외부 시스템(1C, 광고 플랫폼 및 광고 시스템)에 대한 커넥터를 별도의 서비스로 분리했습니다.
주요 아이디어는 사이트에 대한 모든 커넥터가 동일한 API를 가지며 사이트 API를 우리에게 편리한 인터페이스로 가져오는 어댑터라는 것입니다.

우리 제품의 중심에는 서비스로 쉽게 분해될 수 있도록 설계된 단일체인 웹 애플리케이션이 있습니다. 이 애플리케이션은 다운로드한 데이터를 처리하고, 다양한 시스템의 통계를 수집하고, 이를 시스템 사용자에게 제공하는 역할을 합니다.

커넥터와 웹 애플리케이션 간에 통신하려면 커넥터 프록시라는 추가 서비스를 만들어야 했습니다. 서비스 검색 및 작업 스케줄러 기능을 수행합니다. 이 서비스는 매일 밤 각 커넥터에 대한 데이터 수집 작업을 실행합니다. 서비스 계층을 작성하는 것은 메시지 브로커를 연결하는 것보다 쉬웠고, 우리에게는 가능한 한 빨리 결과를 얻는 것이 중요했습니다.

개발의 단순성과 속도를 위해 우리는 모든 서비스가 웹 API가 되도록 결정했습니다. 이를 통해 개념 증명을 빠르게 구성하고 전체 설계가 작동하는지 확인할 수 있었습니다.

별도의 다소 복잡한 작업은 다양한 계정에서 데이터를 수집하기 위한 액세스를 설정하는 것이었습니다. 우리가 결정한 대로 이 작업은 사용자가 웹 인터페이스를 통해 수행해야 합니다. 이는 두 가지 개별 단계로 구성됩니다. 먼저 사용자가 OAuth를 통해 계정에 액세스하기 위해 토큰을 추가한 다음 특정 계정에서 클라이언트에 대한 데이터 수집을 구성합니다. 이미 작성한 것처럼 사이트에서 원하는 계정에 대한 액세스 권한을 위임하는 것이 항상 가능한 것은 아니기 때문에 OAuth를 통해 토큰을 얻는 것이 필요합니다.

사이트에서 계정을 선택하기 위한 범용 메커니즘을 만들려면 수정된 JSONEditor 구성 요소를 사용하여 양식으로 렌더링되는 JSON 스키마를 반환하는 커넥터 API에 메서드를 추가해야 했습니다. 이런 방식으로 사용자는 데이터를 다운로드할 계정을 선택할 수 있었습니다.

사이트에 존재하는 요청 제한을 준수하기 위해 당사는 하나의 토큰 내에서 설정 요청을 결합하지만 다른 토큰을 병렬로 처리할 수도 있습니다.

우리는 웹 애플리케이션과 커넥터 모두에 로드된 데이터를 위한 스토리지로 MongoDB를 선택했습니다. 이를 통해 애플리케이션의 개체 모델이 매일 변경되는 개발 초기 단계에서 데이터 구조에 대해 너무 많이 걱정할 필요가 없었습니다.

우리는 모든 데이터가 MongoDB에 적합하지 않다는 사실을 곧 알게 되었습니다. 예를 들어 일일 통계를 관계형 데이터베이스에 저장하는 것이 더 편리합니다. 따라서 데이터 구조가 관계형 데이터베이스에 더 적합한 커넥터를 위해 PostgreSQL 또는 MS SQL Server를 스토리지로 사용하기 시작했습니다.

선택한 아키텍처와 기술을 통해 우리는 D1.Digital 제품을 비교적 빠르게 구축하고 출시할 수 있었습니다. 23년에 걸친 제품 개발을 통해 우리는 사이트에 대한 3개의 커넥터를 개발했고, 제15자 API를 사용하여 작업하면서 귀중한 경험을 얻었으며, 각기 다른 사이트의 함정을 피하는 방법을 배웠고, 최소 000개의 API 개발에 기여했습니다. 거의 80개에 달하는 캠페인과 000개가 넘는 게재 위치에 대한 정보를 자동으로 다운로드한 사이트에서는 제품 작동에 대한 사용자로부터 많은 피드백을 수집하고 이 피드백을 기반으로 제품의 주요 프로세스를 여러 번 변경했습니다.

솔루션 아키텍처 2.0

개발을 시작한 지 XNUMX년이 지났습니다. D1.디지털. 시스템 부하가 지속적으로 증가하고 점점 더 많은 새로운 데이터 소스가 등장하면서 기존 솔루션 아키텍처의 문제점이 점차 드러났습니다.

첫 번째 문제는 사이트에서 다운로드되는 데이터의 양과 관련이 있습니다. 우리는 대규모 사이트에서 필요한 모든 데이터를 수집하고 업데이트하는 데 너무 많은 시간이 걸린다는 사실에 직면했습니다. 예를 들어, 대부분의 게재위치에 대한 통계를 추적하는 AdRiver 광고 시스템에서 데이터를 수집하는 데 약 12시간이 걸립니다.

이 문제를 해결하기 위해 우리는 모든 종류의 보고서를 사용하여 사이트에서 데이터를 다운로드하기 시작했으며, 작업 속도가 우리의 요구 사항을 충족하도록 사이트와 함께 API를 개발하고 가능한 한 데이터 다운로드를 병렬화하려고 노력하고 있습니다.

또 다른 문제는 다운로드한 데이터의 처리와 관련이 있습니다. 이제 새로운 게재위치 통계가 도착하면 원시 데이터 로드, 각 사이트에 대해 집계된 측정항목 계산, 서로 다른 소스의 데이터 비교, 캠페인에 대한 요약 측정항목 계산 등 측정항목을 다시 계산하는 다단계 프로세스가 시작됩니다. 이로 인해 모든 계산을 수행하는 웹 애플리케이션에 많은 부하가 발생합니다. 재계산 프로세스 중에 애플리케이션이 서버의 모든 메모리(약 10-15GB)를 여러 번 소비했는데, 이는 사용자의 시스템 작업에 가장 해로운 영향을 미쳤습니다.

제품의 추가 개발을 위한 확인된 문제와 야심찬 계획으로 인해 우리는 애플리케이션 아키텍처를 재고해야 했습니다.

우리는 커넥터로 시작했습니다.
우리는 모든 커넥터가 동일한 모델에 따라 작동한다는 것을 알았으므로 커넥터를 생성하려면 단계의 논리만 프로그래밍하면 되고 나머지는 보편적인 파이프라인 프레임워크를 구축했습니다. 일부 커넥터에 개선이 필요한 경우 커넥터가 개선되는 동시에 이를 새로운 프레임워크로 즉시 이전합니다.

동시에 우리는 Docker와 Kubernetes에 커넥터를 배포하기 시작했습니다.
우리는 꽤 오랫동안 Kubernetes로의 이전을 계획하고 CI/CD 설정을 실험했지만 오류로 인해 하나의 커넥터가 서버의 메모리를 20GB 이상 소모하여 사실상 다른 프로세스를 종료할 때만 이전을 시작했습니다. . 조사 중에 커넥터는 Kubernetes 클러스터로 이동되었으며 오류가 수정된 후에도 최종적으로 남아 있었습니다.

우리는 Kubernetes가 편리하다는 것을 아주 빨리 깨달았고, 7개월 이내에 가장 많은 리소스를 소비하는 XNUMX개의 커넥터와 커넥터 프록시를 프로덕션 클러스터로 이전했습니다.

커넥터에 이어 나머지 애플리케이션의 아키텍처를 변경하기로 결정했습니다.
가장 큰 문제는 데이터가 대규모 배치로 커넥터에서 프록시로 들어온 다음 DANBoID에 도달하고 처리를 위해 중앙 웹 애플리케이션으로 전송된다는 것입니다. 지표 재계산 횟수가 많아 애플리케이션에 큰 부하가 걸립니다.

또한 사용자가 무슨 일이 일어나고 있고 데이터가 수집되지 않는 이유를 확인할 수 있도록 개별 데이터 수집 작업의 상태를 모니터링하고 커넥터 내에서 발생하는 오류를 중앙 웹 애플리케이션에 보고하는 것도 상당히 어려웠습니다.

이러한 문제를 해결하기 위해 우리는 아키텍처 2.0을 개발했습니다.

새 버전의 아키텍처 간의 주요 차이점은 웹 API 대신 RabbitMQ와 MassTransit 라이브러리를 사용하여 서비스 간에 메시지를 교환한다는 것입니다. 이를 위해 우리는 커넥터 프록시를 거의 완전히 다시 작성하여 커넥터 허브로 만들어야 했습니다. 서비스의 주요 역할이 더 이상 요청을 커넥터로 전달하고 반대로 전달하는 것이 아니라 커넥터에서 메트릭 수집을 관리하는 것이기 때문에 이름이 변경되었습니다.

중앙 웹 애플리케이션에서 사이트의 게재위치 및 통계에 대한 정보를 별도의 서비스로 분리하여 불필요한 재계산을 없애고 게재위치 수준에서 이미 계산 및 집계된 통계만 저장할 수 있게 되었습니다. 또한 원시 데이터를 기반으로 기본 통계를 계산하는 로직을 다시 작성하고 최적화했습니다.

동시에 우리는 솔루션을 더 쉽게 확장하고 더 편리하게 관리할 수 있도록 모든 서비스와 애플리케이션을 Docker 및 Kubernetes로 마이그레이션하고 있습니다.

우리는 지금 어디에

개념 증명 아키텍처 2.0 제품 D1.디지털 제한된 커넥터 세트를 사용하여 테스트 환경에서 준비 및 작업 중입니다. 남은 일은 새로운 플랫폼에 20개의 커넥터를 다시 작성하고, 데이터가 올바르게 로드되고 모든 측정항목이 올바르게 계산되는지 테스트하고, 전체 설계를 프로덕션에 적용하는 것입니다.

실제로 이 프로세스는 점진적으로 진행될 것이며 모든 것이 계속 작동하려면 이전 API와의 호환성을 유지해야 합니다.

우리의 즉각적인 계획에는 새로운 커넥터 개발, 새로운 시스템과의 통합, 연결된 사이트 및 광고 시스템에서 다운로드한 데이터 세트에 추가 측정항목 추가가 포함됩니다.

또한 중앙 웹 애플리케이션을 포함한 모든 애플리케이션을 Docker 및 Kubernetes로 이전할 계획입니다. 새로운 아키텍처와 결합하면 소비된 리소스의 배포, 모니터링 및 제어가 크게 단순화됩니다.

또 다른 아이디어는 현재 MongoDB에 저장되어 있는 통계 저장용 데이터베이스를 선택하여 실험하는 것입니다. 우리는 이미 몇 가지 새로운 커넥터를 SQL 데이터베이스로 이전했지만 그 차이는 거의 눈에 띄지 않으며 임의의 기간 동안 요청할 수 있는 일별 집계 통계의 경우 이득이 상당히 심각할 수 있습니다.

일반적으로 계획은 거창합니다. 계속 진행하겠습니다 :)

R&D Dentsu Aegis Network Russia 기사 작성자: Georgy Ostapenko(쉬미가아), 미하일 코식(하이텍스)

출처 : habr.com