Где живут Ваши объявления / Тюрин Михаил (Avito)Ontico
Авито с 2010 года — с момента запуска на широкую аудиторию — прошел уже немалый путь, успев собрать более 600 миллионов объявлений со всех уголков страны, и став при этом крупнейшим классифайдом в Европе.
В докладе будет дан обзор архитектуры ядра системы с ретроспективой, перечислены основные компоненты обработки объявлений, приведены оценки параметров функционирования от "продуктовых" "количество объявлений за единицу времени" до количества запросов на разные уровни стека (веб, базы, поиск, очереди) и степени утилизации железа.
Будут также продемонстрированы примеры реализаций классических паттернов веба: кэш, прокси, денормализация и репликация, шардинг, очереди и удаленный вызов процедур — подходы, уже более 5 лет лежащие в основе нашей архитектуры. При этом будут приведены неочевидные, на взгляд автора, особенности внедрения данных подходов.
Доклад должен заинтересовать соотнесением масштабов и ключевых слов.
Flashcache в mamba.ru / Яковлев Александр Юрьевич (ЗАО Мамба)Ontico
Некоторое время назад, когда в очередной раз встал вопрос о производительности большого парка mysql sharding серверов, мы не захотели покупать новые сервера и производить resharding. Мы обнаружили, что компания facebook выпустила в opensource большое количество своих разработок, в том числе и модуль ядра flashcache.
Flashcache — модуль для кэширования блоков блочного устройства, предоставляющий 4 разных режима кэширования.
В данном докладе я расскажу, как мы тестировали, поэтапно проверяя под нагрузкой, 3 из 4 режимов кэширования, сравнивая и выбирая оптимальный. Итогом данной работы стало внедрение данного модуля в нашу архитектуру (фотосервера, сервера БД).
Как устроена MySQL-репликация / Андрей Аксенов (Sphinx)Ontico
Какая вообще в природе бывает репликация (sync vs. async vs. semisync, master-master vs. master-slave), как оно устроено конкретно в MySQL, в каких версиях что добавили. Про binary/relay log, про SBR/RBR/mixed форматы, про глупости с позициями и про GTID, про то, как из-за всяких бед возникают дополнительные продукты типа Tungsten и Galera. Несколько занятных фактов и парочка фокусов, которые можно учинять конкретно с MySQL-репликацией.
Доклад вчистую про внутреннее устройство, по результатам должно появляться общее понимание того, как оно работает внутри и почему именно так. Конкретные SQL-операторы подробно рассматривать НЕ будем, эти скучные мелочи необходимо будет затем самостоятельно смотреть в документации (или не смотреть).
Современная операционная система: что надо знать разработчику / Александр Кри...Ontico
Мы проговорим про связь приложения и ОС, какие компоненты есть в современной ОС на примере Linux, как настройки этих компонент могут повлиять на приложение.
Я расскажу про планировщик процессов, дисковый и сетевой ввод-вывод и соответствующие планировщики, управление памятью - как это все в общих чертах работает и как его потюнить.
Веб-разработка без наркотиков с помощью PostgreSQL, Nginx и c2h5oh / Миша Кир...Ontico
Разговор в докладе пойдёт о веб-программировании.
При изготовлении веб-проектов то и дело пользуются широко распространёнными фреймворками на базе языков программирования — PHP, Python, Perl, Ruby, Go, Rust, Java и т.п.
Я предлагаю отказаться от употребления оных и использовать для разработки веб-приложений только c2h5oh — расширение для высокопроизводительного сервера nginx. Данное расширение позволяет эффективно использовать PostgreSQL в качестве сервера веб-приложений.
Хочу поделиться со слушателями своим личным опытом разработки с использованием подобной связки. Планирую рассказать о плюсах и минусах такого подхода.
Open Source SQL-базы данных вступили в эру миллионов запросов в секунду / Фед...Ontico
Широко распространено мнение, что SQL СУБД обречены быть медлительными и неповоротливыми, поскольку несут груз совместимости с предыдущими версиями. Это расхожее мнение широко эксплуатируется маркетингом NoSQL СУБД. Однако, это не всегда действительно так.
Разработка в Open Source сообществе позволяет продукту развиваться достаточно гибко, чтобы отвечать требованиям времени. В MySQL и PostgreSQL – самых популярных Open Source СУБД – недавно были проведены оптимизации для работы на больших серверах, что позволило им выполнять более миллиона SQL-запросов в секунду на одном экземпляре БД.
В данном докладе будут рассмотрены конкретные оптимизации, которые позволили добиться таких результатов, которые раньше могли бы показаться фантастическими. И можно сказать, что Open Source СУБД вошли в эру миллионов запросов в секунду.
MyRocks Табличный Движок для MySQL / Алексей Майков (Facebook) / Сергей Петру...Ontico
Facebook использует MySQL в качестве основного хранилища данных. MySQL работает на десятках тысяч серверов в нескольких ЦОДах. В качестве дисков используются Flash-накопители. Они дают большую производительность, но дорогой ценой — MySQL хранит данные на диске в структуре B-tree, которая использует flash-диск неоптимальным образом. В масштабах Facebook'a цена вопроса измеряется миллионами долларов.
Для оптимального использования Flash-дисков в Facebook была разработана библиотека RocksDB. Она основана на LSM-деревьях и оптимизирована для работы в условиях высокой загрузки. Чтобы использовать ее из MySQL, [совместно с MariaDB] был разработан табличный движок — MyRocks.
Данный доклад посвящен RocksDB и MyRocks. Мы расскажем о принципах их работы и преимуществах, как их настраивать, и какие возможны подводные камни.
Авторы доклада — ведущие разработчики MyRocks от Facebook и MariaDB.
RocksDB и MyRocks доступны на GitHub для свободного использования, участие в разработке также приветствуется.
Мониторинг ожиданий в PostgreSQL / Курбангалиев Ильдус (Postgres Professional)Ontico
В многоядерных высоконагруженных системах с высокой конкурентностью часто бывает сложно определить, чем занят отдельный процесс PostgreSQL. Он может находиться в ожидании локов высокого уровня, таких как локи таблиц, внутренних локов, используемых для синхронизации процессов, ввода-вывода и многих других.
В настоящий момент среди всех событий ожидания мониторить можно только локи высокого уровня с помощью представлений PostgreSQL. Другие типы ожиданий требуют использования низкоуровневых утилит типа perf, systemtap и других. Эти утилиты требуют специальных знаний и могут быть платформозависимыми. В то же время другие enterprise базы данных уже включают в себя инструменты для мониторинга ожиданий.
Мы разработали патч, который реализует мониторинг ожиданий в PostgreSQL. С минимальной настройкой (несколько конфигурационных параметров) этот патч показывает полную информацию о текущих ожиданиях в режиме реального времени и с небольшим оверхедом на всю систему. Этот патч уже работает на продакшен серверах Яндекса и показал свою полезность.
Что особенного в СУБД для данных в оперативной памяти / Константин Осипов (Ta...Ontico
Оперативная память становится всё более дешёвой и производительной, что позволяет использовать её для хранения рабочего набора данных всё большего числа приложений. Хранение всех данных в оперативной памяти позволяет сделать их высоко доступными, а алгоритмы для работы с данными либо существенно упростить, либо ускорить, а иногда — и то, и другое.
Тезисы - http://www.highload.ru/2015/abstracts/1964.html
Кластеры баз данных делаем сложные вещи просто / Андрей Тихонов (Avito)Ontico
Порой в процессе развития высоконагруженного проекта наступает момент, когда необходимо масштабирование. Возможно, ваш проект впервые упёрся в производительность железа (и таким образом перешёл в разряд высоконагруженных); возможно, это уже не первое масштабирование — не важно. Какие же проблемы могут возникнуть?
Во-первых, если вы увеличиваете количество бэкенд-серверов, и, соответственно, количество рабочих процессов, то с ростом количества одновременных клиентских подключений вырастают и накладные расходы на базах данных.
Во-вторых, достаточно быстро может кончиться ресурс in-memory баз данных. Потребуется создать (либо увеличить) кластер, а это каждый раз влечёт за собой необходимость модифицировать логику приложения.
В-третьих, чем больше серверов, тем больше вероятность, что один из них выйдет из строя. Поэтому неплохо задуматься о том, как обеспечить отказоустойчивость, а это, опять же, потребует модифицировать логику приложения.
В этом докладе я расскажу, как и какими инструментами можно легко решить все вышеперечисленные проблемы: уменьшить накладные расходы от большого количества подключений к базам данных, создать/модифицировать кластер БД прозрачно для приложения, а также прозрачно добавить устойчивость к падениям серверов БД.
План доклада:
- Введение. Методы масштабирования БД: репликация, шардирование.
- Создаём шардированные кластеры in-memory БД прозрачно для приложений: Twemproxy, Redis-proxy, Mcrouter.
- Уменьшаем накладные расходы от большого количества одновременных подключений на PostgreSQL с помощью PgBouncer.
- Создаём шардированный кластер PostgreSQL с помощью PL/Proxy.
- Добавляем прозрачную для приложения отказо�
OpenResty: превращаем NGINX в полноценный сервер приложений / Владимир Прота...Ontico
Все мы знаем, что NGINX – отличный прокси, который может качественно и эффективно распределять нагрузку между бэкендами и фильтровать запросы по определенным условиям. Но при этом часто на практике возникают задачи, которые не решаются его декларативной моделью описания конфигурации: иногда для принятия решения нам нужно сходить в базу данных (в Redis или даже в MySQL), другой сервис или произвести какую-то более сложную обработку запроса/ответа. Именно здесь к нам на помощь приходит мощь Lua и OpenResty.
Из доклада вы узнаете:
* зачем нам Lua внутри NGINX, и почему из седьмого айфона убрали разъем под наушники;
* в каких ситуациях NGINX в паре с Lua справятся с задачей лучше вашего любимого PHP/NodeJS/Ruby/Python/Visual Basic и о прелестях асинхронного ввода-вывода без callback'ов;
* как залезть к NGINX под капот, используя только высокоуровневый язык;
* при чем здесь Openresty, или как упростить себе жизнь;
* примеры бизнес-кейсов: от "умного" прокси до самостоятельного веб-приложения;
* как оно ведет себя в продакшне под большой нагрузкой.
Практика совместного использования Lua и C в opensource спам-фильтре Rspamd /...Ontico
В данном докладе я расскажу о том, как Lua помогает расширять функционал Rspamd, позволяя людям без особых знаний С писать эффективные правила фильтрации спама. Также будут рассмотрены особенности внедрения Lua в C код и основные приемы, применяемые при написании API для Lua приложений. Отдельное внимание будет уделено документации к Lua API, которая является одним из необходимых компонентов для opensource приложения.
Кроме этого, отдельная часть доклада посвящена анализу производительности Lua: использованию LuaJIT, сравнению вызовов C функций через FFI с традиционным вызовом, оптимизации строковых операций и таблиц в Lua.
В заключение будут рассмотрены некоторые открытые вопросы: будущее языка, наличие нескольких диалектов, статический анализ Lua стека, а также вопросы безопасности при JIT компиляции.
Реализация восстановления после аварий / Сергей Бурладян (Avito)Ontico
Базы данных PostgreSQL занимают одно из центральных мест в Авито. Они являются разделяемой платформой, вокруг которой построено множество дополнительных сервисов. Одной из основных задач при их администрировании является задача восстановления после аварий как самих баз, так и связанной с ними инфраструктуры.
В своём докладе я постараюсь рассказать про:
+ общую схему связей баз данных между собой и с другими компонентами;
+ точки отказа и виды аварий, затрагиваемые связи;
+ бинарную репликацию и архив;
+ логическую репликацию, pgq, londiste, UNDO (REDO), пересоздание репки;
+ скрипт и процедуру переключения при аварии;
+ планы: развитие «восстановлений» по всем связям, автоматика на основе системы zookeeper (etcd и т.п.).
Архитектура поиска в Avito / Андрей Смирнов (Avito)Ontico
Из доклада вы узнаете о том, как в Avito используется Sphinx search, почему было выбрано это решение, какие подводные камни встретились на пути, и как их преодолеть.
Андрей поделится практическим опытом настройки и оптимизации Sphinx search, который позволяет добиться стабильной работы кластера и высокой скорости индексации и поиска. В Avito Sphinx индексирует 35 млн. объявлений каждые 7 минут!
Мы в Avito не так давно начали использовать Golang, но он уже успел занять важное место в различных частях проекта. В докладе мы расскажем о том, какие задачи нам помогает решать Go, почему выбор пал именно на этот язык, с какими подводными камнями мы столкнулись, и как их обходили. В частности поговорим про:
• Сервисы. Как мы начали использовать Go для разработки микросервисов, как это сказалось на их поддержке, а также отдельно расскажем про “шаблон сервиса”, который мы используем.
• Поиск. Как мы с помощью Go мы реализовали RtIndexer для обновления Sphinx Rt индексов в кластере из множества машин (поиск по активным объявлениям), который устойчиво работает с отставанием не более 10 секунд при нагрузке до 1000 rps.
• Автоматизацию тестирования. Как мы пишем тестовые сервисы и API на Go. Подробней остановимся на использовании общих моделей тел запросов и ответов для отправки и получения, использовании горутин как воркеров для обработки очереди.
«Миллион открытых каналов с данными по сети» – Илья Биин (Zenhotels)AvitoTech
Поговорим о том, почему это далеко не самая простая задача, и как следует разбираться с возникающими трудностями. Рассмотрим и покритикуем существующие решения. Научимся создавать свой собственный велосипед.
Где живут Ваши объявления / Тюрин Михаил (Avito)Ontico
Авито с 2010 года — с момента запуска на широкую аудиторию — прошел уже немалый путь, успев собрать более 600 миллионов объявлений со всех уголков страны, и став при этом крупнейшим классифайдом в Европе.
В докладе будет дан обзор архитектуры ядра системы с ретроспективой, перечислены основные компоненты обработки объявлений, приведены оценки параметров функционирования от "продуктовых" "количество объявлений за единицу времени" до количества запросов на разные уровни стека (веб, базы, поиск, очереди) и степени утилизации железа.
Будут также продемонстрированы примеры реализаций классических паттернов веба: кэш, прокси, денормализация и репликация, шардинг, очереди и удаленный вызов процедур — подходы, уже более 5 лет лежащие в основе нашей архитектуры. При этом будут приведены неочевидные, на взгляд автора, особенности внедрения данных подходов.
Доклад должен заинтересовать соотнесением масштабов и ключевых слов.
Flashcache в mamba.ru / Яковлев Александр Юрьевич (ЗАО Мамба)Ontico
Некоторое время назад, когда в очередной раз встал вопрос о производительности большого парка mysql sharding серверов, мы не захотели покупать новые сервера и производить resharding. Мы обнаружили, что компания facebook выпустила в opensource большое количество своих разработок, в том числе и модуль ядра flashcache.
Flashcache — модуль для кэширования блоков блочного устройства, предоставляющий 4 разных режима кэширования.
В данном докладе я расскажу, как мы тестировали, поэтапно проверяя под нагрузкой, 3 из 4 режимов кэширования, сравнивая и выбирая оптимальный. Итогом данной работы стало внедрение данного модуля в нашу архитектуру (фотосервера, сервера БД).
Как устроена MySQL-репликация / Андрей Аксенов (Sphinx)Ontico
Какая вообще в природе бывает репликация (sync vs. async vs. semisync, master-master vs. master-slave), как оно устроено конкретно в MySQL, в каких версиях что добавили. Про binary/relay log, про SBR/RBR/mixed форматы, про глупости с позициями и про GTID, про то, как из-за всяких бед возникают дополнительные продукты типа Tungsten и Galera. Несколько занятных фактов и парочка фокусов, которые можно учинять конкретно с MySQL-репликацией.
Доклад вчистую про внутреннее устройство, по результатам должно появляться общее понимание того, как оно работает внутри и почему именно так. Конкретные SQL-операторы подробно рассматривать НЕ будем, эти скучные мелочи необходимо будет затем самостоятельно смотреть в документации (или не смотреть).
Современная операционная система: что надо знать разработчику / Александр Кри...Ontico
Мы проговорим про связь приложения и ОС, какие компоненты есть в современной ОС на примере Linux, как настройки этих компонент могут повлиять на приложение.
Я расскажу про планировщик процессов, дисковый и сетевой ввод-вывод и соответствующие планировщики, управление памятью - как это все в общих чертах работает и как его потюнить.
Веб-разработка без наркотиков с помощью PostgreSQL, Nginx и c2h5oh / Миша Кир...Ontico
Разговор в докладе пойдёт о веб-программировании.
При изготовлении веб-проектов то и дело пользуются широко распространёнными фреймворками на базе языков программирования — PHP, Python, Perl, Ruby, Go, Rust, Java и т.п.
Я предлагаю отказаться от употребления оных и использовать для разработки веб-приложений только c2h5oh — расширение для высокопроизводительного сервера nginx. Данное расширение позволяет эффективно использовать PostgreSQL в качестве сервера веб-приложений.
Хочу поделиться со слушателями своим личным опытом разработки с использованием подобной связки. Планирую рассказать о плюсах и минусах такого подхода.
Open Source SQL-базы данных вступили в эру миллионов запросов в секунду / Фед...Ontico
Широко распространено мнение, что SQL СУБД обречены быть медлительными и неповоротливыми, поскольку несут груз совместимости с предыдущими версиями. Это расхожее мнение широко эксплуатируется маркетингом NoSQL СУБД. Однако, это не всегда действительно так.
Разработка в Open Source сообществе позволяет продукту развиваться достаточно гибко, чтобы отвечать требованиям времени. В MySQL и PostgreSQL – самых популярных Open Source СУБД – недавно были проведены оптимизации для работы на больших серверах, что позволило им выполнять более миллиона SQL-запросов в секунду на одном экземпляре БД.
В данном докладе будут рассмотрены конкретные оптимизации, которые позволили добиться таких результатов, которые раньше могли бы показаться фантастическими. И можно сказать, что Open Source СУБД вошли в эру миллионов запросов в секунду.
MyRocks Табличный Движок для MySQL / Алексей Майков (Facebook) / Сергей Петру...Ontico
Facebook использует MySQL в качестве основного хранилища данных. MySQL работает на десятках тысяч серверов в нескольких ЦОДах. В качестве дисков используются Flash-накопители. Они дают большую производительность, но дорогой ценой — MySQL хранит данные на диске в структуре B-tree, которая использует flash-диск неоптимальным образом. В масштабах Facebook'a цена вопроса измеряется миллионами долларов.
Для оптимального использования Flash-дисков в Facebook была разработана библиотека RocksDB. Она основана на LSM-деревьях и оптимизирована для работы в условиях высокой загрузки. Чтобы использовать ее из MySQL, [совместно с MariaDB] был разработан табличный движок — MyRocks.
Данный доклад посвящен RocksDB и MyRocks. Мы расскажем о принципах их работы и преимуществах, как их настраивать, и какие возможны подводные камни.
Авторы доклада — ведущие разработчики MyRocks от Facebook и MariaDB.
RocksDB и MyRocks доступны на GitHub для свободного использования, участие в разработке также приветствуется.
Мониторинг ожиданий в PostgreSQL / Курбангалиев Ильдус (Postgres Professional)Ontico
В многоядерных высоконагруженных системах с высокой конкурентностью часто бывает сложно определить, чем занят отдельный процесс PostgreSQL. Он может находиться в ожидании локов высокого уровня, таких как локи таблиц, внутренних локов, используемых для синхронизации процессов, ввода-вывода и многих других.
В настоящий момент среди всех событий ожидания мониторить можно только локи высокого уровня с помощью представлений PostgreSQL. Другие типы ожиданий требуют использования низкоуровневых утилит типа perf, systemtap и других. Эти утилиты требуют специальных знаний и могут быть платформозависимыми. В то же время другие enterprise базы данных уже включают в себя инструменты для мониторинга ожиданий.
Мы разработали патч, который реализует мониторинг ожиданий в PostgreSQL. С минимальной настройкой (несколько конфигурационных параметров) этот патч показывает полную информацию о текущих ожиданиях в режиме реального времени и с небольшим оверхедом на всю систему. Этот патч уже работает на продакшен серверах Яндекса и показал свою полезность.
Что особенного в СУБД для данных в оперативной памяти / Константин Осипов (Ta...Ontico
Оперативная память становится всё более дешёвой и производительной, что позволяет использовать её для хранения рабочего набора данных всё большего числа приложений. Хранение всех данных в оперативной памяти позволяет сделать их высоко доступными, а алгоритмы для работы с данными либо существенно упростить, либо ускорить, а иногда — и то, и другое.
Тезисы - http://www.highload.ru/2015/abstracts/1964.html
Кластеры баз данных делаем сложные вещи просто / Андрей Тихонов (Avito)Ontico
Порой в процессе развития высоконагруженного проекта наступает момент, когда необходимо масштабирование. Возможно, ваш проект впервые упёрся в производительность железа (и таким образом перешёл в разряд высоконагруженных); возможно, это уже не первое масштабирование — не важно. Какие же проблемы могут возникнуть?
Во-первых, если вы увеличиваете количество бэкенд-серверов, и, соответственно, количество рабочих процессов, то с ростом количества одновременных клиентских подключений вырастают и накладные расходы на базах данных.
Во-вторых, достаточно быстро может кончиться ресурс in-memory баз данных. Потребуется создать (либо увеличить) кластер, а это каждый раз влечёт за собой необходимость модифицировать логику приложения.
В-третьих, чем больше серверов, тем больше вероятность, что один из них выйдет из строя. Поэтому неплохо задуматься о том, как обеспечить отказоустойчивость, а это, опять же, потребует модифицировать логику приложения.
В этом докладе я расскажу, как и какими инструментами можно легко решить все вышеперечисленные проблемы: уменьшить накладные расходы от большого количества подключений к базам данных, создать/модифицировать кластер БД прозрачно для приложения, а также прозрачно добавить устойчивость к падениям серверов БД.
План доклада:
- Введение. Методы масштабирования БД: репликация, шардирование.
- Создаём шардированные кластеры in-memory БД прозрачно для приложений: Twemproxy, Redis-proxy, Mcrouter.
- Уменьшаем накладные расходы от большого количества одновременных подключений на PostgreSQL с помощью PgBouncer.
- Создаём шардированный кластер PostgreSQL с помощью PL/Proxy.
- Добавляем прозрачную для приложения отказо�
OpenResty: превращаем NGINX в полноценный сервер приложений / Владимир Прота...Ontico
Все мы знаем, что NGINX – отличный прокси, который может качественно и эффективно распределять нагрузку между бэкендами и фильтровать запросы по определенным условиям. Но при этом часто на практике возникают задачи, которые не решаются его декларативной моделью описания конфигурации: иногда для принятия решения нам нужно сходить в базу данных (в Redis или даже в MySQL), другой сервис или произвести какую-то более сложную обработку запроса/ответа. Именно здесь к нам на помощь приходит мощь Lua и OpenResty.
Из доклада вы узнаете:
* зачем нам Lua внутри NGINX, и почему из седьмого айфона убрали разъем под наушники;
* в каких ситуациях NGINX в паре с Lua справятся с задачей лучше вашего любимого PHP/NodeJS/Ruby/Python/Visual Basic и о прелестях асинхронного ввода-вывода без callback'ов;
* как залезть к NGINX под капот, используя только высокоуровневый язык;
* при чем здесь Openresty, или как упростить себе жизнь;
* примеры бизнес-кейсов: от "умного" прокси до самостоятельного веб-приложения;
* как оно ведет себя в продакшне под большой нагрузкой.
Практика совместного использования Lua и C в opensource спам-фильтре Rspamd /...Ontico
В данном докладе я расскажу о том, как Lua помогает расширять функционал Rspamd, позволяя людям без особых знаний С писать эффективные правила фильтрации спама. Также будут рассмотрены особенности внедрения Lua в C код и основные приемы, применяемые при написании API для Lua приложений. Отдельное внимание будет уделено документации к Lua API, которая является одним из необходимых компонентов для opensource приложения.
Кроме этого, отдельная часть доклада посвящена анализу производительности Lua: использованию LuaJIT, сравнению вызовов C функций через FFI с традиционным вызовом, оптимизации строковых операций и таблиц в Lua.
В заключение будут рассмотрены некоторые открытые вопросы: будущее языка, наличие нескольких диалектов, статический анализ Lua стека, а также вопросы безопасности при JIT компиляции.
Реализация восстановления после аварий / Сергей Бурладян (Avito)Ontico
Базы данных PostgreSQL занимают одно из центральных мест в Авито. Они являются разделяемой платформой, вокруг которой построено множество дополнительных сервисов. Одной из основных задач при их администрировании является задача восстановления после аварий как самих баз, так и связанной с ними инфраструктуры.
В своём докладе я постараюсь рассказать про:
+ общую схему связей баз данных между собой и с другими компонентами;
+ точки отказа и виды аварий, затрагиваемые связи;
+ бинарную репликацию и архив;
+ логическую репликацию, pgq, londiste, UNDO (REDO), пересоздание репки;
+ скрипт и процедуру переключения при аварии;
+ планы: развитие «восстановлений» по всем связям, автоматика на основе системы zookeeper (etcd и т.п.).
Архитектура поиска в Avito / Андрей Смирнов (Avito)Ontico
Из доклада вы узнаете о том, как в Avito используется Sphinx search, почему было выбрано это решение, какие подводные камни встретились на пути, и как их преодолеть.
Андрей поделится практическим опытом настройки и оптимизации Sphinx search, который позволяет добиться стабильной работы кластера и высокой скорости индексации и поиска. В Avito Sphinx индексирует 35 млн. объявлений каждые 7 минут!
Мы в Avito не так давно начали использовать Golang, но он уже успел занять важное место в различных частях проекта. В докладе мы расскажем о том, какие задачи нам помогает решать Go, почему выбор пал именно на этот язык, с какими подводными камнями мы столкнулись, и как их обходили. В частности поговорим про:
• Сервисы. Как мы начали использовать Go для разработки микросервисов, как это сказалось на их поддержке, а также отдельно расскажем про “шаблон сервиса”, который мы используем.
• Поиск. Как мы с помощью Go мы реализовали RtIndexer для обновления Sphinx Rt индексов в кластере из множества машин (поиск по активным объявлениям), который устойчиво работает с отставанием не более 10 секунд при нагрузке до 1000 rps.
• Автоматизацию тестирования. Как мы пишем тестовые сервисы и API на Go. Подробней остановимся на использовании общих моделей тел запросов и ответов для отправки и получения, использовании горутин как воркеров для обработки очереди.
«Миллион открытых каналов с данными по сети» – Илья Биин (Zenhotels)AvitoTech
Поговорим о том, почему это далеко не самая простая задача, и как следует разбираться с возникающими трудностями. Рассмотрим и покритикуем существующие решения. Научимся создавать свой собственный велосипед.
Дизайн REST API для высокопроизводительных систем / Александр Лебедев (Новые ...Ontico
Доклад осветит вопросы устройства REST API для веб-приложений и мобильных клиентов, от которых требуется высокая производительность.
Проектирование высокопроизводительных REST API.
- Кто должен участвовать в проектировании.
- Как узнать, что оптимизировать.
- Как измерять производительность REST API.
Паттерны и антипаттерны.
- Почему pagination - это плохо, и на что лучше заменить.
- Проблема N+1 и как с ней бороться.
- Бесполезные данные - как обнаружить и уничтожить.
- Как не ломать кэширование на клиенте.
- Эффективная работа с интерфейсами "мастер-детали".
Кэширование.
- Три слоя кэширования.
- Самый быстрый запрос - тот, которого не было. Как увеличить их количество.
- Экономия трафика.
- Исключение ненужных вычислений.
- Подходы к инвалидации кэша.
Приемы оптимизации работы с API на клиенте.
- Параллельные запросы.
- Эффективный разбор данных.
- In-memory DB на клиенте.
- Стратегии кэширования на клиенте.
«Как 200 строк на Go помогли нам освободить 15 серверов» – Паша Мурзаков (Badoo)AvitoTech
В Badoo я работаю в команде, которая разрабатывает на PHP. Одна из фич, которой мы занимаемся, со временем начала отъедать всё больше и больше железячных ресурсов. В итоге мы едва успевали добавлять серверы под растущую нагрузку. При этом вечера, проведённые с Go дома, подсказывали, что можно сделать на порядки производительнее, не затратив на разработку много времени.
Я расскажу о том, почему наша фича так плохо ложится на PHP и хорошо – на Go, как уговорить всех всё переписать и не показаться сумасшедшим, ну и, конечно же, как из 19 серверов оставить только 4.
Чему мы научились, разрабатывая микросервисы / Вадим Мадисон (RuTube)Ontico
Начав разработку нового продукта через микросервисы, мы неожиданно для себя обнаружили, что микросервисы — это не просто "вместо одного большого приложения теперь пишем много маленьких". При разработке большой системы она сама собой через какое-то время становится набором отдельных сервисов, которые должны взаимодействовать между собой, поэтому стабильная работа сервисов и их взаимодействие не стало чем-то новым. Неожиданностью стало то, что система стала значительно более динамической, она стала постоянно изменяться отдельными небольшими частями, сервисы стали часто перезапускаться, а количество запущенных нод сервисов стало расти по экспоненте.
Очень быстро стал актуальным вопрос конфигурирования — если раньше, выкатив новую версию монолита с единым конфигом, мы применяли правки на всю систему сразу, то с микросервисами все сложнее — пара сотен работающих нод и всем нужно применить изменения. Требования к деплою также поменялись — он стал частью процесса разработки, а тестирование стало частью деплоя. Количество необходимого ПО для функционирования системы также стало некоторым сюрпризом.
В докладе я расскажу о том, как в итоге это работает у нас, как мы решили такие вопросы как:
- конфигурирование сервисов;
- интеграция между собой;
- тестирование;
- версионирование;
- масштабирование.
Расскажу, какие тулзы мы в итоге используем, а от каких отказались.
Платежная система за год / Филипп Дельгядо (Информационные технологии и системы)Ontico
По мотивам одного из последних проектов буду рассказывать об особенностях разработки систем с сложной бизнес-логикой, ощутимыми требованиями к производительности и высокими требованиями к надежности.
Расскажу об особенностях платежных систем, опишу причины выбора основных архитектурных решений (Java, PostgreSQL, сервисы) и особенности процесса разработки.
Основные интересные моменты, на которых остановлюсь подробнее:
1) как решать популярные проблемы с БД и что делать, если не хватает IOPS;
2) какую надежную очередь стоит использовать;
3) какие нестандартные практики были успешными: IDE driven development, JSON вместо ORM, Functional test вместо Unit test;
4) какие решения были неправильными: PyTest, Spring Security, docker, велосипеды, разработчики, магия;
5) зачем менять методологию разработки три раза за год — и почему во многих проектах это тоже стоит делать.
Надеюсь, часть из сказанного вызовет несогласие и дискуссию.
От больших к очень большим данным — зачем нужна нормализация в Big Data / Гол...Ontico
Спроектировать хранилище данных, казалось бы, не сложно.
Собрать требования -> построить модель данных -> реализовать ETL.
Но проходит год-два, и рост объема данных, и, главное, рост сложности данных приводит хранилище на грань работоспособности.
В докладе будет проиллюстрировано, как Big Data хранилище Авито экспоненциально увеличивалось в размерах данных и сложности их взаимосвязей вместе с ростом объема и сложности бизнеса компании, сохраняя скорость выполнения запросов.
Будет обосновано, почему следование ограничениям 6-й нормальной формы (Anchor Modeling) помогает не утонуть в новых данных и успешно масштабировать нагрузку в условиях MPP СУБД.
В качестве финального штриха будет рассказано, как высоконормализованная модель данных Anchor Modeling позволяет малыми усилиями сделать шаг за пределы СУБД к хранению части данных в виде (ORC) файлов в распределенной файловой системе (HDFS) к сохранению для пользователей возможности работать со всеми данными посредством (почти) обычного SQL (без Hive).
Building the Enterprise infrastructure with PostgreSQL as the basis for stori...PavelKonotopov
In my talk, I will tell how we built a geographically distributed system of personal data storage based on Open Source software and PostgreSQL. The concept of the inCountry business is to provide customers with a ready-to-use infrastructure for personal data storage. Our business customers are ensured that their customer’s personal data is securely stored within their country’s borders. We wrote an API and SDK and built a variety of services. Our system complies with generally accepted security standards (SOC Type 1, Type 2, PCI DSS, etc.). We built our infrastructure with Consul, Nomad, and Vault, used PostgreSQL, ElasticSearch as a storage system, Nginx, Jenkins, Artifactory, other tools to automate management and deployment. We have assembled our development and management teams - DevOps, Security, Monitoring, and DBA. We use both cloud providers and bare-metal servers located in different regions of the world. Development of the system architecture and ensuring the stability of the infrastructure, consistent and secure operation of all its components is the main task facing our teams.
Сейчас OpenStack на слуху, но детальных отзывов и описаний дизайна инфраструктуры все еще не много. Постараемся немного упростить задачу для тех, кто еще только планирует развертывание инфраструктуры виртуализации, и расскажем, как это делали мы в некоторых наших проектах:
погрузимся в нюансы реализации окружения OpenStack в боевой среде;
поговорим об отказоустойчивости;
рассмотрим варианты организации резервного копирования;
обратим внимание на конфигурацию «железок»: СХД и сети.
SQL-ник DevDay. Рубцов. Новое в Percona Server и MariaDB в сравнении с MySQL 5.5DevDay
Григорий Рубцов — руководитель проектов SQLinfo.ru (http://sqlinfo.ru/) и Webew.ru (http://webew.ru/), автор онлайн-курса по MySQL (http://sqlinfo.ru/classes/) и спикер конференции РИТ++.
Новое в Percona Server и MariaDB в сравнении с MySQL 5.5
Обзор возможностей:
— новое для разработчика;
— новое для администратора;
— улучшения производительности;
— миграция и вопросы совместимости.
Технические детали:
— хранилище XtraDB;
— Percona Tools;
— алгоритмы оптимизации подзапросов в MariaDB.
Андрей Федоренчик- «Высоконагруженная система с аналитикой на InfoBright»Tanya Denisyuk
Наша рекламная сеть прошла путь от 1М до 150M показов в сутки. На этом пути пришлось столкнуться с проблемами при логировании и анализе больших объемов данных. В итоге отказались от использования NonSQL базы данных и выбрали column-based InfoBright. В своем докладе я расскажу, как мы накапливаем, храним, обрабатываем и анализируем сотни гигабайт информации в день c использованием InfoBright.
О чем нам могут рассказать access логи вебсервера? Поиск аномалий и отклонений от нормы? Откуда наши пользователи? Город? Страна? Сайт? Сколько запросов генерируют роботы? Когда в последний раз к нам приходил поисковик для индексации? Какая динамика по ошибкам и страницам отсутствующим на сайте?
2. КОЛОНТИТУЛ:ТЕМАПРЕЗЕНТАЦИИ
2
Всем привет!
Михаил Тюрин, Avito.ru
– главный системный архитектор, базы данных
– с PostgreSQL с 2004-ого, с версий 7.4/8.0, региональный web-стартап!
– в Авито с 2009-ого:
● один из четырех первых разработчиков; DBA / sql / plpgsql / php / skytools / linux
● DBA и DB-team lead, развитие смежных компонент
● архитектура, хранение и обработка данных в целом
● работа с базами данных PostgreSQL – основное хранилище:
– директор по разработке и девопс-директор, отдел «аналитиков»
– DB-team: DBA и sql-девелоперы; – 7 человек // есть 2 (две) вакансии
– DevOps/SysAdm – 0.5 человека «на базе» // есть вакансии
– отдельные серверсайд разработчики
– отдельные DWH разработчики («аналитики»)
● отвечаю в том числе за то, чтобы данные «лежали» как надо и где надо
3. КОЛОНТИТУЛ:ТЕМАПРЕЗЕНТАЦИИ
3
Avito в цифрах
● Авито – доска N1 в России (Европе)
– «большой» и мобильный сайты; api – приложения и смежные проекты
– топ 10 сайт в России
● 250M просмотров и
● 7M посетителей в сутки
– 25M активных объявлений,
– 700K новых объявлений ежедневно
● ~ 500 человек штат (кто все эти люди?!)
– 80 человек «отдел» разработки
– DB-team: 7 человек, + несколько выделенных серверсайд девелоперов
4. КОЛОНТИТУЛ:ТЕМАПРЕЗЕНТАЦИИ
4
Еще цифры
● 200+ серверов на основной платформе
– ~ 100 web app серверов – основные клиенты баз
– ~ 30 серверов с pg
● ~ 10 одновременно под нагрузкой
● 4 – под высокой
● postgres под нагрузкой
– «мастер» база – db, «m1»
● 1.5TB; 3KTPS и 1.5K IUD/sec в среднем
– 8K iops (5–12К) (w/r 2/6К), w/r 25/80 MB/s – 60% utilization SSD raid
– 20-50 active pg connections (intel 20(40ht) CPU, 376GB DDR)
– «стендбай» – db-sb: 600TPS
– «мастер2» – db2, «m2»: HDD raid, 2.5TPS (amd 16CPU, 80GB DDR) // ! uptime: 500d
– «repca» – db-re: 7КTPS, «in-memory» pg (16 CPU)
web
pg1
pg2
pg3
etc
5. КОЛОНТИТУЛ:ТЕМАПРЕЗЕНТАЦИИ
5
Как мы к этому шли
● начало: php + memcached и postgres – PostgreSQL
● первые шаги: + pgpool – fail
● postgresql + tsearch – ok
● skype: pgbouncer – OK OK OK !!! *
6. КОЛОНТИТУЛ:ТЕМАПРЕЗЕНТАЦИИ
6
Продолжаем идти
● skytools: walmgr – fail
● частичный индекс WHERE ACTIVE – ok
● sphinx – OK
● skytools: php-deamon – OK
● upgrade на 9.0 – bug
https://wiki.postgresql.org/wiki/20110408pg_upgrade_fix
ERROR: could not access status of transaction ######
DETAIL: could not open file "pg_clog/####": No such file or directory=20
● split: m1/m2 – OK *
● mat-view на deffered triggers – OK *
● skytools: londiste – «repca» – PGQ – OK OK !! *
● pitr: pg_basebackup, pg_archivecleanup – OK *
● skytools: plproxy – хранилище «xdb» – OK *
● pgq consumer – «xrpc» – OK *
9. КОЛОНТИТУЛ:ТЕМАПРЕЗЕНТАЦИИ
9
PgBouncer
● pool коннектов
● мультиплексор: transaction pooling
● очередь запросов на одном процессе
– два пула: на клиенте и на сервере
● защита от «съедания» центрального ресурса одним клиентом
● распределение обработки очереди между двумя процессами
● дополнительный удобный прокси уровень
– nice -10 при нагрузке и высоксом la при cpu-bound
– поднятие более одного pgbouncer на сервере базы под высоким трафиком/нагрузкой
● connect query: select x_init()
● proxy
– маршрутизация трафика
– смена юзера: [ app --> pgbouncer ] == > [ pgbouncer – client_usr --> db ]
– смена параметров коннектов: x_init() / x_init('log = on')
● http://pgbouncer.projects.pgfoundry.org/doc/usage.html#_admin_console
10. КОЛОНТИТУЛ:ТЕМАПРЕЗЕНТАЦИИ
10
db split
← split start
1) init standby
2.1) promote standby
2.2) switch connections m2
to new host-m2
← split finish
3) drop database:
– m2 on host-m1
– m1 on host-m2
NO tx && NO joins
12. КОЛОНТИТУЛ:ТЕМАПРЕЗЕНТАЦИИ
12
repca! – londiste: trigger based logical replication
● «матвью» активных айтимов
select item_id as id, get_hstore_pararms(category_id, item_id) as params from items where active
http://www.pgcon.org/2008/schedule/attachments/63_BSDCan2008-MaterializedViews.pdf
http://www.pgcon.org/2008/schedule/attachments/64_BSDCan2008-MaterializedViews-paper.pdf
+ deffered trigger: refresh_function()
● hstore!!! // привет Олегу и Федору
– не правим «матвью» при изменении полей таблиц объявления
● pgq: londiste «матвью» => repca
● repca в шаред буфферах – 7 К TPS
● восстановление:
– резервирование — ! два коснумера на одну очередь (knowhow)
– UNDO log (супер knowhow) и REDO фича londiste
– !!! см. доклад Сергея Бурладяна «Восстановление и другие подходы к авариям»
18. КОЛОНТИТУЛ:ТЕМАПРЕЗЕНТАЦИИ
18
«xrpc»
● «базы» вызывают друг друга асинхронно и получают асинхронный коллбек
● FUNCTION xrpc._call( queue text, _dbconn text, _func text, args hstore ) RETURNS bigint
return pgq.insert_event( queue, -- queue_name
DEFAULT_CALL_TYPE, -- ev_type
'1.1', -- ev_data -- rpc version
_dbconn, -- ev_extra1
_func, -- ev_extra2
args::text, -- ev_extra3
now()::timestamp::text -- ev_extra4
) ; -- call_id: event_id;
● xrpcd – consumer, для каждой базы собирает свои вызовы xrpc.do_call( func, args )
execute 'select "' || replace(func, '.', '"."') || '"( $1 )' using args;
● xrpcd обрабатывает аварии через трекание batch_id // xrpc.set_batch_done
● примеры:
– «геокодер» – где-то по дороге ходит в Яндекс
– асинхронная «транзакционная» обработка больших групп объектов пачками
– очередь модерации
19. КОЛОНТИТУЛ:ТЕМАПРЕЗЕНТАЦИИ
19
PGQ
«+»
● ! транзакционность
● минималный оверхед на выборку событий
● отсутствие блокировок
● удобный maintenance очередей
«-»
● нет отложенных событий – by design // отправь письмо через 5 минут
● текстовый формат
● консумер переспрашивает источник по таймауту (1s), нет
подписки на событие на сокете