Slide 1

Slide 1 text

ОПТИМИЗАЦИЯ СЕРВИСА А/Б ТЕСТИРОВАНИЯ. ИЛИ КАК УЙТИ ОТ DJANGO ORM К FASTAPI QUERY BUILDER.

Slide 2

Slide 2 text

О СЕБЕ Никита Дорофеев Fullstack разработчик Waterbase, KION Django, React 2

Slide 3

Slide 3 text

3 О ЧЕМ ПОГОВОРИМ Remote Config Django ORM A/B эксперименты FastAPI Query Builder Беcшовный переход Оптимизация ресурсов

Slide 4

Slide 4 text

User1 User2 ЧТО ТАКОЕ А/В ЭКСПЕРИМЕНТ? 4

Slide 5

Slide 5 text

• A/B эксперименты • Изменение конфигурации устройств в реальном времени • Независимые неймспейсы • Ролевая модель в рамках одного неймспейса • Система нотификации в Tелеграм • Наследование конфигов 5 ФИЧИ

Slide 6

Slide 6 text

• Поэтапная раскатка • Полное кеширование данных • Разделение параметров по продуктовым командам • Создание своих вариаций • Вариативность конфигов по версии, модели,ОС • Белые/черные списки 6 ФИЧИ

Slide 7

Slide 7 text

REMOTE CONFIG

Slide 8

Slide 8 text

"params": {}, "experiments": [], "parameters_hash": str Попадает ли клиент в контрольную группу? Client ID = 68398456 OS = AndroidTV Model = IP_TV Version = 1.45.19 Есть ли дефолтные параметры? Попадает ли клиент в покрытие эксперимента? В какой вариант эксперимента попал клиент? Есть ли специальные параметры для такого клиента? КАК СОБИРАЕТСЯ КОНФИГ? 8

Slide 9

Slide 9 text

CORE • Name • Description • Parameters • Configs CONFIG • Name • Parameters • Core • Experiments EXPERIMENT • Name • Description • Configs • Coverage • Filters SPEC_PARAM • Name • Description • Filters • Parameters 1 M M M M M M M M M PARAMETER • Value • Is_ison • Is_numeric • Description REMOTE CONFIG 9

Slide 10

Slide 10 text

SPECIAL PARAMETER Model = [Samsung, LG] OS = [SmartTV] Version = [1 : 4.5] ClientId = 123456 PARAMS EXPERIMENT Model = [Samsung, LG] OS = [SmartTV] Version = [1 : 4.5] ClientId = 123456 CORE CONFIG PARAMS CORE CONFIG PARAMS REMOTE CONFIG 10

Slide 11

Slide 11 text

{ "var_1": CRD_1, "var_2": CRD_2 } { "var_2": CND_1, "var_3": CND_2 } { "var_3": CRE_1, "var_4": CRE_2 } { "var_4": SP_1, "var_5": SP_2 } { "var_5": CNE_1, "var_6": CNE_2 } Core default Config default Core exp Special param Config exp { "var_1": CRD_1, "var_2": CND_1, "var_3": CRE_1, "var_4": SP_1, "var_5": SP_2 } = + + + + 11 КАК СОБИРАЕТСЯ КОНФИГ?

Slide 12

Slide 12 text

12

Slide 13

Slide 13 text

13 Всё-в-одном подход усложняет масштабирование Автоматическое создание фильтров «из коробки » Минимум кода для создания работающего веб-приложения «Путь Django» ограничивает архитектурную свободу DJANGO – «БАТАРЕЙКИ ВКЛЮЧЕНЫ» ФРЕЙМВОРК

Slide 14

Slide 14 text

14 Методы родительских классов Метаданные полей и дескрипторы Служебные атрибуты Django Вся бизнес-логика модели FAT MODEL, THIN VIEW

Slide 15

Slide 15 text

15 Method Binding Overhead CPU Cache Efficiency Garbage Collection Pressure QuerySet не очищает кеш MEMORY FRAGMENTATION

Slide 16

Slide 16 text

16 Django ORM VS FastAPI АНАЛИЗ СОЗДАНИЯ ОБЪЕКТОВ

Slide 17

Slide 17 text

17 Все эти проверки версий, массивов, blacklist происходили в Python циклах вместо SQL WHERE условий. PYTHON ФИЛЬТРАЦИЯ

Slide 18

Slide 18 text

18 Python интерпретируется во время выполнения Python GIL блокирует параллельное выполнение Python создает объекты в разных областях памяти PostgreSQL написан на C C код в 10-100 раз быстрее Python loops POSTGRESQL VS PYTHON PERFORMANCE

Slide 19

Slide 19 text

19 Instagram*: Полный отказ от Django ORM — история эволюции (2010-2013) МЫ НЕ ОДИНОКИ В ЭТИХ ПРОБЛЕМАХ 2010 Решение: Разделение по моделям: отдельные БД для пользователей, медиа, лайков, комментариев. Проблема: один PostgreSQL не справлялся с нагрузкой 5M пользователей. 2011 Решение: параллельно отправить асинхронные запросы, получить результаты, собрать их все в один результирующий набор. Только лайки перешли на SQL. Проблема: лайки росли экспоненциально — одна база больше не могла их хранить 2013 Все пользовательские данные мигрировали на SQL Django ORM остался только для внутренних админ- инструментов Django: URL routing, views, sessions, auth — всё кроме ORM Постепенная миграция

Slide 20

Slide 20 text

20 Гибридный подход — «Use the right tool for the job » 1. Административные панели • Внутренние инструменты управления • Биллинговые операции • User management и права доступа 2. Низконагруженные операции • CRUD операции для метаданных • Конфигурационные данные • Внутренняя отчетность DJANGO ORM ИСПОЛЬЗУЕТСЯ ДЛЯ: 1. File synchronization API — критически важные операции 2. Metadata operations — высокочастотные запросы 3. High-throughput endpoints — массовые операции 4. Real-time collaboration features — низкая задержка RAW SQL ИСПОЛЬЗУЕТСЯ ДЛЯ: МЫ НЕ ОДИНОКИ В ЭТИХ ПРОБЛЕМАХ

Slide 21

Slide 21 text

21 Instagram*: 2 года миграции Pinterest: Поэтапный переход компонентов Dropbox: Гибридный подход без полной миграции ПОСТЕПЕННАЯ МИГРАЦИЯ, А НЕ «BIG BANG» Django admin URL routing Authentication/authorization Migrations Template system СОХРАНЕНИЕ DJANGO ЭКОСИСТЕМЫ Raw SQL: для высоконагруженных API, сложной аналитики, real-time операций RAW SQL ДЛЯ PERFORMANCE- CRITICAL PATHS ОБЩИЕ ПАТТЕРНЫ МИГРАЦИИ ОТ DJANGO ORM

Slide 22

Slide 22 text

22 Генерирует чистый SQL который мы можем видеть и оптимизировать Условно добавляет JOIN'ы только когда они нужны Использует PostgreSQL- специфичные возможности без ограничений Поддерживает асинхронные запросы к нескольким базам данных ОТКАЗ ОТ ORM В ПОЛЬЗУ QUERY BUILDER 1 2 3 4

Slide 23

Slide 23 text

23 Возможности фильтрации сложных JSON для вложенной фильтрации НОВЫЕ ВОЗМОЖНОСТИ СЛОЖНОЙ ФИЛЬТРАЦИИ

Slide 24

Slide 24 text

24 ПРОБЛЕМЫ, КОТОРЫЕ ВОЗНИКЛИ Наше решение - функция compareversions(): Проблема: PostgreSQL не умеет сравнивать версии приложений типа "1.2.3" с "1.10.0". Выбрали оставить на питоне Проблема CityHash: Различия между Python и PostgreSQL

Slide 25

Slide 25 text

25 Django остался для задач, в которых он силен. Следит за миграциями, работает с вебом, админка. FastAPI взял высокопроизводительные задачи FastAPI — простота масштабирования РАЗДЕЛЕНИЕ ОТВЕТСТВЕННОСТИ Стратегическое разделение по типу нагрузки

Slide 26

Slide 26 text

26 Тестирование и постепенный rollout: обеспечение идентичности ответов Canary deployment — 10% production трафика и постепенное увеличение Адаптация тестов: от unit к integration тестам. Переиспользование существующей логики ПРОБЛЕМЫ И ВЫЗОВЫ ПРИ МИГРАЦИИ Интеграционные тесты

Slide 27

Slide 27 text

27 ИТОГОВОЕ СРАВНЕНИЕ Django Response Time FastAPI Response Time Django RPS FastAPI RPS

Slide 28

Slide 28 text

28 ИТОГОВОЕ СРАВНЕНИЕ Убрали pgBouncer

Slide 29

Slide 29 text

29 ПРОСТОЕ МАСШТАБИРОВАНИЕ

Slide 30

Slide 30 text

30 ВОПРОСЫ