Масштабирование системы баннерной рекламы с централизованной базой данных Сергей Нековаль Компания «Грамант» Сергей Нековаль Компания «Грамант»

Что масштабируем? Японская система баннерной рекламы более 450 млн. показов в сутки более 50 млн. показов в сутки Система на базе DART Enterprise

Что рассказываем? Эволюционное развитие архитектуры системы или Как мы докатились до такой жизни Выгоды и проблемы централизации данных Capacity Planning и риски

Бизнес-модель

Начало пути СУБД Oracle Веб-сервер

Проблемы баннер-сервер ПорталНагрузка на баннер-сервер многократно превышает нагрузку на Портал баннер-серверЧто будет, если баннер-сервер сломается? теряем деньги!

Вариант 2

Преимущества Балансировка загрузки баннер-серверовОтказоустойчивость баннер-серверов Возможность независимого обновления баннер-серверов Проблемы Мы балансируем загрузку CPU!? BLOBs

События Impression (Показ)450 млн. ClickThrough (Клик)1,5 млн. Sale (Продажа)35 тыс. за сутки

Исходящие данные Генерируем «свернутое» представление баннеров (BCG_*) Создаем файловую структуру

Игнорируем... Задержку данных (20 мин) Случайную рассогласованность данных между серверами

Альтернативы Проксирование баннеров Content Delivery Networks (Akamai и т.п.)

Входящие данные CT не агрегируются Используем SQL*Loader

Цикл загрузки Сколько PV суммировать? Загрузку CT задерживать нельзя! Late Arrivals

Вариант 3

Проблемы объема Размер БД растет Оперативные данные составляют не более 10%

Решения Разделение на несколько БД Partitioning Архивирование

Одна база / много баз? Связанность данных Объем данных для репликации Сложность схемы

Разделение данных

Capacity Planning Оценка загрузки СУБД Оценка загрузки баннер-серверов

Последний вариант

Сравним с DART Enterprise Построен на базе Oracle Подсчет уникальных событий Нет поддержки Sales (хотя есть возможность модифицировать DART) Четкое разделение функций между серверами

Компоненты DART

Обработка запроса в DART

Вопросы? Сергей Нековаль Компания «Грамант» Сергей Нековаль Компания «Грамант»