Оперативная память становится всё более дешёвой и производительной, что позволяет использовать её для хранения рабочего набора данных всё большего числа приложений. Хранение всех данных в оперативной памяти позволяет сделать их высоко доступными, а алгоритмы для работы с данными либо существенно упростить, либо ускорить, а иногда — и то, и другое.
Тезисы - http://www.highload.ru/2015/abstracts/1964.html
Современная операционная система: что надо знать разработчику / Александр Кри...Ontico
Мы проговорим про связь приложения и ОС, какие компоненты есть в современной ОС на примере Linux, как настройки этих компонент могут повлиять на приложение.
Я расскажу про планировщик процессов, дисковый и сетевой ввод-вывод и соответствующие планировщики, управление памятью - как это все в общих чертах работает и как его потюнить.
Chronicle Map — key-value хранилище для трейдинга на Java / Левентов Роман (C...Ontico
Сфера финансовых приложений и трейдинга выдвигает особые требования к системам обработки данных: ультракороткие задержки, конкурентные обновления (в т.ч. из разных процессов), репликация высокочастотных обновлений.
Существовавшие открытые key-value хранилища не справлялись, поэтому мы сделали свое — Chronicle Map.
В докладе я отвечу на вопросы:
+ Почему бывает эффективнее разбить систему, работающую с общим состоянием, на несколько отдельных процессов?
+ Зачем вам может захотеться распилить JVM на несколько частей?
+ Как добиться от key-value хранилища медианной latency меньше 1 микросекунды?
+ Как сделать репликацию, если она упирается в пропускную способность сети из-за слишком частых обновлений?
Развею миф о том, что Java — это медленно :)
Также, в докладе будет сравнение Chronicle Map с redis, one-nio и ConcurrentHashMap.
Защита данных и датацентров от катастроф. Подход Nutanix / Максим Шапошников ...Ontico
+ Защита данных — это не "одна кнопка", нет годного любому единого решения. Задача всегда диктует выбор средств и решений.
+ RTO — Recovery Time Objective — максимальное время, за которое все ваши бизнес-задачи должны полностью быть восстановлены в работоспособное состояние после полной катастрофы ДЦ.
+ RPO — Recovery Point Objective — максимально приемлемый для ваших задач промежуток времени, за который вы готовы потерять данные.
+ Защита на уровне приложений. Приложение лучше всех знает, как защищать и реплицировать свои данные.
+ Асинхронная репликация — наилучший выход с точки зрения производительности, единственно возможный вариант в случае значительного географического разнесения дата-центров (сотни и более километров). Работает на уровне виртуальных машин.
+ Метро / "растянутые" кластеры и синхронная репликация — нулевой RPO, минимальный RTO, большие потери производительности и множество ограничений. Но иногда — единственный выход, если уровень приложения не умеет реплицировать данные.
+ Лучший подход — комбинация из репликации на уровне приложений, асинхронной и синхронной репликации средствами хранилища.
+ Что есть у Nutanix для решения подобных задач: DR (Async replication), Metro availability cluster, Timestream Backup.
+ Реализация решения с использованием Nutanix на примере FBI: крупнейший VDI в США. Защищенная, mission-critical инфраструктура на 70 тысяч виртуальных десктопов. Асинхронная репликация дата-центров на 1500 миль, защита данных от катастроф.
Тюним память и сетевой стек в Linux: история перевода высоконагруженных серве...Ontico
В процессе обновления высоконагруженных серверов раздачи видео (40Gbit/s с каждого сервера) со старого OpenSuSE 10.2 на новый CentOS 7 (время между релизами — 7 лет) мы столкнулись с рядом проблем — необъяснимый свопинг и запуски OOM killer, неравномерное распределение нагрузки по ядрам, обрывы соединений, скачки системной нагрузки на CPU.
В докладе будет рассказано о том, как мы боролись с этими проблемами и какие технологии для этого использовали.
Реализация восстановления после аварий / Сергей Бурладян (Avito)Ontico
Базы данных PostgreSQL занимают одно из центральных мест в Авито. Они являются разделяемой платформой, вокруг которой построено множество дополнительных сервисов. Одной из основных задач при их администрировании является задача восстановления после аварий как самих баз, так и связанной с ними инфраструктуры.
В своём докладе я постараюсь рассказать про:
+ общую схему связей баз данных между собой и с другими компонентами;
+ точки отказа и виды аварий, затрагиваемые связи;
+ бинарную репликацию и архив;
+ логическую репликацию, pgq, londiste, UNDO (REDO), пересоздание репки;
+ скрипт и процедуру переключения при аварии;
+ планы: развитие «восстановлений» по всем связям, автоматика на основе системы zookeeper (etcd и т.п.).
Современная операционная система: что надо знать разработчику / Александр Кри...Ontico
Мы проговорим про связь приложения и ОС, какие компоненты есть в современной ОС на примере Linux, как настройки этих компонент могут повлиять на приложение.
Я расскажу про планировщик процессов, дисковый и сетевой ввод-вывод и соответствующие планировщики, управление памятью - как это все в общих чертах работает и как его потюнить.
Chronicle Map — key-value хранилище для трейдинга на Java / Левентов Роман (C...Ontico
Сфера финансовых приложений и трейдинга выдвигает особые требования к системам обработки данных: ультракороткие задержки, конкурентные обновления (в т.ч. из разных процессов), репликация высокочастотных обновлений.
Существовавшие открытые key-value хранилища не справлялись, поэтому мы сделали свое — Chronicle Map.
В докладе я отвечу на вопросы:
+ Почему бывает эффективнее разбить систему, работающую с общим состоянием, на несколько отдельных процессов?
+ Зачем вам может захотеться распилить JVM на несколько частей?
+ Как добиться от key-value хранилища медианной latency меньше 1 микросекунды?
+ Как сделать репликацию, если она упирается в пропускную способность сети из-за слишком частых обновлений?
Развею миф о том, что Java — это медленно :)
Также, в докладе будет сравнение Chronicle Map с redis, one-nio и ConcurrentHashMap.
Защита данных и датацентров от катастроф. Подход Nutanix / Максим Шапошников ...Ontico
+ Защита данных — это не "одна кнопка", нет годного любому единого решения. Задача всегда диктует выбор средств и решений.
+ RTO — Recovery Time Objective — максимальное время, за которое все ваши бизнес-задачи должны полностью быть восстановлены в работоспособное состояние после полной катастрофы ДЦ.
+ RPO — Recovery Point Objective — максимально приемлемый для ваших задач промежуток времени, за который вы готовы потерять данные.
+ Защита на уровне приложений. Приложение лучше всех знает, как защищать и реплицировать свои данные.
+ Асинхронная репликация — наилучший выход с точки зрения производительности, единственно возможный вариант в случае значительного географического разнесения дата-центров (сотни и более километров). Работает на уровне виртуальных машин.
+ Метро / "растянутые" кластеры и синхронная репликация — нулевой RPO, минимальный RTO, большие потери производительности и множество ограничений. Но иногда — единственный выход, если уровень приложения не умеет реплицировать данные.
+ Лучший подход — комбинация из репликации на уровне приложений, асинхронной и синхронной репликации средствами хранилища.
+ Что есть у Nutanix для решения подобных задач: DR (Async replication), Metro availability cluster, Timestream Backup.
+ Реализация решения с использованием Nutanix на примере FBI: крупнейший VDI в США. Защищенная, mission-critical инфраструктура на 70 тысяч виртуальных десктопов. Асинхронная репликация дата-центров на 1500 миль, защита данных от катастроф.
Тюним память и сетевой стек в Linux: история перевода высоконагруженных серве...Ontico
В процессе обновления высоконагруженных серверов раздачи видео (40Gbit/s с каждого сервера) со старого OpenSuSE 10.2 на новый CentOS 7 (время между релизами — 7 лет) мы столкнулись с рядом проблем — необъяснимый свопинг и запуски OOM killer, неравномерное распределение нагрузки по ядрам, обрывы соединений, скачки системной нагрузки на CPU.
В докладе будет рассказано о том, как мы боролись с этими проблемами и какие технологии для этого использовали.
Реализация восстановления после аварий / Сергей Бурладян (Avito)Ontico
Базы данных PostgreSQL занимают одно из центральных мест в Авито. Они являются разделяемой платформой, вокруг которой построено множество дополнительных сервисов. Одной из основных задач при их администрировании является задача восстановления после аварий как самих баз, так и связанной с ними инфраструктуры.
В своём докладе я постараюсь рассказать про:
+ общую схему связей баз данных между собой и с другими компонентами;
+ точки отказа и виды аварий, затрагиваемые связи;
+ бинарную репликацию и архив;
+ логическую репликацию, pgq, londiste, UNDO (REDO), пересоздание репки;
+ скрипт и процедуру переключения при аварии;
+ планы: развитие «восстановлений» по всем связям, автоматика на основе системы zookeeper (etcd и т.п.).
Flashcache в mamba.ru / Яковлев Александр Юрьевич (ЗАО Мамба)Ontico
Некоторое время назад, когда в очередной раз встал вопрос о производительности большого парка mysql sharding серверов, мы не захотели покупать новые сервера и производить resharding. Мы обнаружили, что компания facebook выпустила в opensource большое количество своих разработок, в том числе и модуль ядра flashcache.
Flashcache — модуль для кэширования блоков блочного устройства, предоставляющий 4 разных режима кэширования.
В данном докладе я расскажу, как мы тестировали, поэтапно проверяя под нагрузкой, 3 из 4 режимов кэширования, сравнивая и выбирая оптимальный. Итогом данной работы стало внедрение данного модуля в нашу архитектуру (фотосервера, сервера БД).
За счет чего Tarantool такой оптимальный / Денис Аникин (Mail.Ru)Ontico
Многие из вас, наверное, видели результаты тестов сравнения Tarantool с остальными СУБД, которые показывают, что Tarantool быстрее всех, оптимальней по памяти, обрабатывает наибольшее количество транзакций в секунду.
И, несмотря на то, что исходные коды всех тестов полностью открыты и хорошо откомментированы, позволяя всем желающим повторить тесты, все равно остаются вопросы - за счет чего Tarantool такой быстрый и оптимальный?
Я решил суммировать мои ответы на эти вопросы в докладе на Highload++.
Итак, почему Tarantool такой быстрый?
Краткий ответ: потому что он с самого начала разрабатывался и до сих пор разрабатывается во главе угла с производительностью/оптимальностью/минимальным потреблением всех ресурсов системы.
Более полный ответ я раскрою в своем выступлении. Приходите, будет интересно! :)
Кластеры баз данных делаем сложные вещи просто / Андрей Тихонов (Avito)Ontico
Порой в процессе развития высоконагруженного проекта наступает момент, когда необходимо масштабирование. Возможно, ваш проект впервые упёрся в производительность железа (и таким образом перешёл в разряд высоконагруженных); возможно, это уже не первое масштабирование — не важно. Какие же проблемы могут возникнуть?
Во-первых, если вы увеличиваете количество бэкенд-серверов, и, соответственно, количество рабочих процессов, то с ростом количества одновременных клиентских подключений вырастают и накладные расходы на базах данных.
Во-вторых, достаточно быстро может кончиться ресурс in-memory баз данных. Потребуется создать (либо увеличить) кластер, а это каждый раз влечёт за собой необходимость модифицировать логику приложения.
В-третьих, чем больше серверов, тем больше вероятность, что один из них выйдет из строя. Поэтому неплохо задуматься о том, как обеспечить отказоустойчивость, а это, опять же, потребует модифицировать логику приложения.
В этом докладе я расскажу, как и какими инструментами можно легко решить все вышеперечисленные проблемы: уменьшить накладные расходы от большого количества подключений к базам данных, создать/модифицировать кластер БД прозрачно для приложения, а также прозрачно добавить устойчивость к падениям серверов БД.
План доклада:
- Введение. Методы масштабирования БД: репликация, шардирование.
- Создаём шардированные кластеры in-memory БД прозрачно для приложений: Twemproxy, Redis-proxy, Mcrouter.
- Уменьшаем накладные расходы от большого количества одновременных подключений на PostgreSQL с помощью PgBouncer.
- Создаём шардированный кластер PostgreSQL с помощью PL/Proxy.
- Добавляем прозрачную для приложения отказо�
Tempesta FW: challenges, internals, use cases / Александр Крижановский (Tempe...Ontico
Tempesta FW — это Open Source гибрид Web-акселератора и файервола, специально разработанный для высокопроизводительной доставки контента вне зависимости от DDoS или наплыва посетителей.
В докладе будет рассказано про задачи, которые ставились при разработке проекта и пути их решения. Рассмотрим проблемы современных операционных систем в приложении к Web-стеку (система фильтрации, Web-сервер, application слой, БД), и как они решаются в Tempesta — некоторые уже решены, некоторые еще в процессе работы.
И самое главное — у нас появился рабочий прототип, и я расскажу про типовые примеры инсталляции, фичи и конфигурацию, а также покажу бенчмарки.
Путь от монолита на PHP к микросервисам на Scala / Денис Иванов (2GIS)Ontico
В своём проекте мы решали следующие задачи:
+ Скорость разработки задачи;
+ Стоимость поддержки задачи;
+ Возможность распараллеливать вычисления и задачи;
+ Возможность максимально просто масштабировать приложение;
+ CI/CD с минимальными усилиями.
Я расскажу о том, как мы решали эти задачи, на какие грабли мы наступали, что из этого всего получилось, и что делать дальше.
Что получили в итоге:
+ Мощь JVM под капотом Scala;
+ 15 минут от нажатия на кнопку "Merge request" до продакшена в 3 датацентра и 6 серверов с прохождением тестов (юнит + функциональные + интеграционные + нагрузочные);
+ 6 нод с приложениями вместо 18 (по 2 в каждом датацентре для отказоустойчивости) с запасом прочности в 60%;
+ Независимые пофичные релизы без даунтайма всех компонентов приложения;
+ Масштабирование только того функционала и в том количестве, которое необходимо данному сервису.
DPDK в виртуальном коммутаторе Open vSwitch / Александр Джуринский (Selectel)Ontico
Intel DPDK (Data Plane Development Kit) — набор драйверов и библиотек, позволяющих приложениям взаимодействовать с сетевым устройством напрямую, минуя сетевой стек Linux. Это значительно увеличивает скорость обработки пакетов. DPDK интегрируется с рядом популярных программных решений, например, c виртуальным коммутатором Open vSwitch.
Возможностям и перспективам использования связи Open vSwitch + DPDK в облачных проектах и будет посвящен наш доклад. Мы подробно остановимся на проведённых тестах производительности и интерпретируем их результаты. Отдельное внимание будет уделено анализу трудностей и ограничений, с которыми пришлось столкнуться в ходе экспериментов.
Хранение данных на виниле / Константин Осипов (tarantool.org)Ontico
В rfc1149 дан исчерпывающий обзор преимуществ голубиной почты для протокола IP: низкая пропускная способность, невысокая надёжность, простая топология сети. Для того чтобы дать адекватный ответ вызовам эпохи мемристоров и квантовых вычислений, Tarantool 1.7 содержит новый движок для хранения данных на классических жёстких дисках и флэш-накопителях: Vinyl. Tarantool известен своей скоростью, и мы постарались не ударить в грязь лицом и на этот раз.
В докладе я расскажу об устройстве нашего нового storage engine:
- как мы объединили in-memory технологию и LSM (log structured merge) деревья для достижения оптимальной производительности и утилизации ресурса накопителя,
- как работает multiversion concurrency control в Vinyl,
- основной компонент в промышленной реализации LSM дерева - merge scheduler, т.е. планировщик слияний и сборки мусора дерева. Я расскажу о подходе, который позволяет максимально снизить износ накопителя, при этом уложиться в заданные рамки производительности запросов.
Внутреннее устройство PostgreSQL: временные таблицы и фрагментация памяти / Г...Ontico
Всем известно о существовании временных таблиц в PostgreSQL, но как они устроены, и чем грозит их некорректное использование - не столь очевидно.
На примере одного известного приложения, активно и некорректно использующего временные таблицы, мы расскажем о создаваемой ими проблеме фрагментации памяти.
Что такое фрагментация памяти, по каким признакам можно определить ее наличие, чем она грозит, почему она возникает при активном использовании временных таблиц, и как мы пропатчили PostgreSQL, чтобы ее избежать - обо всем этом можно узнать из нашего доклада.
Осваиваем Tarantool 1.6 / Евгений Шадрин (Sberbank Digital Ventures)Ontico
Tarantool - отечественная Opensource NoSQL база данных.
В докладе мы обсудим:
- Какое место занимают NoSQL базы данных в highload проектах?
Почему и для чего вам стоит NoSQL решения?
Какие NoSQL решения вы можете использовать?
- Рассмотрим, что из себя представляет Tarantool 1.6 - база данных и сервер приложений в одном лице.
Какие основные особенности Tarantool как NoSQL базы данных?
Lua как встроенный язык сервера приложений.
- Посмотрим, как можно начать использовать Tarantool в своих проектах, и сделаем первые шаги.
Как установить Tarantool.
Первый запуск и основы конфигурирования.
Модель данных.
Как создавать и работать с хранилищем данных.
Как использовать пакеты tarantool.
- Узнаем об интересных модулях и фичах Tarantool
Чем полезен application server
Tarantool http
Tarantool queue
- Познакомимся с сообществом Tarantool opensource
Почему сообщество - это важно?
Чем полезны opensource проекты начинающему разработчику?
Строим сервисы на базе Nginx и Tarantool / Василий Сошников, Андрей Дроздов (...Ontico
Слушатели этого доклада получат представление о том, как построить отказоустойчивое, быстрое, простое и легко масштабируемое решение на базе Nginx и Tarantool.
Коротко о главном:
+ Обзор внутреннего устройства шардинга в Tarantool.
+ Обзор Tarantool upstream модуля для Nginx.
+ Результаты нагрузочного тестирования Tarantool шардинга в связке с Nginx модулем.
+ Live-demo: распределенное отображение графа категорий Wikipedia в СУБД Tarantool с единой точкой входа и возможностью реалтайм поиска по категориям.
Погружение в виртуальную память и большие страницы / Константин Новаковский (...Ontico
РИТ++ 2017, HighLoad Junior
Зал Сингапур, 5 июня, 12:00
Тезисы:
http://junior.highload.ru/2017/abstracts/2688.html
Современные приложения часто используют большое количество памяти, ещё чаще разработчики не задумываются, как именно приложение работает с памятью, и откуда она берётся. Просим ядро дать кусок памяти и начинаем с ним что-то делать... Но что за память нам выделяет ядро операционной системы? Память на самом деле виртуальная и делится на единицы, называемые страницами. Страницы бывают маленькими, бывают большими и очень большими.
...
Чему мы научились разрабатывая микросервисы?Vadim Madison
Доклад с конференции Backend Conf 2016
Начав разработку нового продукта через микросервисы, мы неожиданно для себя обнаружили, что микросервисы — это не просто "вместо одного большого приложения теперь пишем много маленьких". При разработке большой системы она сама собой через какое-то время становится набором отдельных сервисов, которые должны взаимодействовать между собой, поэтому стабильная работа сервисов и их взаимодействие не стало чем-то новым. Неожиданностью стало то, что система стала значительно более динамической, она стала постоянно изменяться отдельными небольшими частями, сервисы стали часто перезапускаться, а количество запущенных нод сервисов стало расти по экспоненте.
Очень быстро стал актуальным вопрос конфигурирования — если раньше, выкатив новую версию монолита с единым конфигом, мы применяли правки на всю систему сразу, то с микросервисами все сложнее — пара сотен работающих нод и всем нужно применить изменения. Требования к деплою также поменялись — он стал частью процесса разработки, а тестирование стало частью деплоя. Количество необходимого ПО для функционирования системы также стало некоторым сюрпризом.
В докладе я расскажу о том, как в итоге это работает у нас, как мы решили такие вопросы как:
- конфигурирование сервисов;
- интеграция между собой;
- тестирование;
- версионирование;
- масштабирование.
Расскажу, какие тулзы мы в итоге используем, а от каких отказались.
Мониторинг ожиданий в PostgreSQL / Курбангалиев Ильдус (Postgres Professional)Ontico
В многоядерных высоконагруженных системах с высокой конкурентностью часто бывает сложно определить, чем занят отдельный процесс PostgreSQL. Он может находиться в ожидании локов высокого уровня, таких как локи таблиц, внутренних локов, используемых для синхронизации процессов, ввода-вывода и многих других.
В настоящий момент среди всех событий ожидания мониторить можно только локи высокого уровня с помощью представлений PostgreSQL. Другие типы ожиданий требуют использования низкоуровневых утилит типа perf, systemtap и других. Эти утилиты требуют специальных знаний и могут быть платформозависимыми. В то же время другие enterprise базы данных уже включают в себя инструменты для мониторинга ожиданий.
Мы разработали патч, который реализует мониторинг ожиданий в PostgreSQL. С минимальной настройкой (несколько конфигурационных параметров) этот патч показывает полную информацию о текущих ожиданиях в режиме реального времени и с небольшим оверхедом на всю систему. Этот патч уже работает на продакшен серверах Яндекса и показал свою полезность.
В докладе было рассказано, зачем нужны сессии, где Badoo хранили их раньше, что придумали, почему решили использовать Tarantool, и к чему все это привело.
Open Source SQL-базы данных вступили в эру миллионов запросов в секунду / Фед...Ontico
Широко распространено мнение, что SQL СУБД обречены быть медлительными и неповоротливыми, поскольку несут груз совместимости с предыдущими версиями. Это расхожее мнение широко эксплуатируется маркетингом NoSQL СУБД. Однако, это не всегда действительно так.
Разработка в Open Source сообществе позволяет продукту развиваться достаточно гибко, чтобы отвечать требованиям времени. В MySQL и PostgreSQL – самых популярных Open Source СУБД – недавно были проведены оптимизации для работы на больших серверах, что позволило им выполнять более миллиона SQL-запросов в секунду на одном экземпляре БД.
В данном докладе будут рассмотрены конкретные оптимизации, которые позволили добиться таких результатов, которые раньше могли бы показаться фантастическими. И можно сказать, что Open Source СУБД вошли в эру миллионов запросов в секунду.
BigMemory - работа с сотнями миллионов бизнес-объектов / Дмитрий Хмаладзе (Ag...Ontico
РИТ++ 2017, HighLoad Junior
Зал Сингапур, 5 июня, 11:00
Тезисы:
http://junior.highload.ru/2017/abstracts/2683.html
Наш доклад описывает способ использования больших объемов памяти, которые стали доступны в последние годы. К сожалению, эта память обычно остается незадействованной в управляемых средах исполнения в связи с принудительной сборкой мусора. Разработчики прибегают к внешним хранилищам данных ( i.e Memcached), что несет дополнительные расходы.
...
сравнение производительности СУБД MySQL и PostgreSQL для "типичной задачи стартапа".
Презентация сопровождала тестовую online-сессию и потому не содержит результатов тестирования.
Оптимизации уровня CPU, Андрей Акиньшин (JetBrains)Ontico
В современном мире многие разработчики перестали стараться писать высокопроизводительный код. Порой их можно понять: в наше время прекрасных облачных решений дешевле докупить дополнительных серверов, чем тратить время на оптимизацию кода. Но что, если у вас нет такой возможности? Что, если для текущей задачи вы ограничены одной машиной или даже одним потоком?
В этом докладе мы обсудим некоторые подходы, которые помогают выжимать максимум производительности из современного железа и позволяют разгонять программы, которые, казалось бы, разогнать нельзя. В числе прочего будем обсуждать следующие вещи: CPU cache, Instruction Level Parallelism, False sharing, Branch Prediction, SEE/AVX instructions и т.д.
101 способ приготовления RabbitMQ и немного о pipeline архитектуре / Филонов ...Ontico
Архитектурный шаблон проектирования конвейер (pipeline) хорошо зарекомендовал себя при проектировании высоконагруженных (highload) систем. Использование шины сообщений (message bus) при реализации каналов взаимодействия позволяет достигать хороших показателей масштабируемости (scalability), но при этом появляются дополнительные накладные расходы, которые сказываются на показателях производительности (performance).
В докладе обсуждаются варианты использования системы обмена сообщениями RabbitMQ в качестве связующего программного обеспечения (middleware) для построения конвейерной архитектуры. Рассматриваются вопросы производительности и масштабирования как stateless так и statefull фильтров.
В качестве примера рассматривается реализация системы обработки сложных событий (complex event processing) применительно к управлению журналированием (log management).
Flashcache в mamba.ru / Яковлев Александр Юрьевич (ЗАО Мамба)Ontico
Некоторое время назад, когда в очередной раз встал вопрос о производительности большого парка mysql sharding серверов, мы не захотели покупать новые сервера и производить resharding. Мы обнаружили, что компания facebook выпустила в opensource большое количество своих разработок, в том числе и модуль ядра flashcache.
Flashcache — модуль для кэширования блоков блочного устройства, предоставляющий 4 разных режима кэширования.
В данном докладе я расскажу, как мы тестировали, поэтапно проверяя под нагрузкой, 3 из 4 режимов кэширования, сравнивая и выбирая оптимальный. Итогом данной работы стало внедрение данного модуля в нашу архитектуру (фотосервера, сервера БД).
За счет чего Tarantool такой оптимальный / Денис Аникин (Mail.Ru)Ontico
Многие из вас, наверное, видели результаты тестов сравнения Tarantool с остальными СУБД, которые показывают, что Tarantool быстрее всех, оптимальней по памяти, обрабатывает наибольшее количество транзакций в секунду.
И, несмотря на то, что исходные коды всех тестов полностью открыты и хорошо откомментированы, позволяя всем желающим повторить тесты, все равно остаются вопросы - за счет чего Tarantool такой быстрый и оптимальный?
Я решил суммировать мои ответы на эти вопросы в докладе на Highload++.
Итак, почему Tarantool такой быстрый?
Краткий ответ: потому что он с самого начала разрабатывался и до сих пор разрабатывается во главе угла с производительностью/оптимальностью/минимальным потреблением всех ресурсов системы.
Более полный ответ я раскрою в своем выступлении. Приходите, будет интересно! :)
Кластеры баз данных делаем сложные вещи просто / Андрей Тихонов (Avito)Ontico
Порой в процессе развития высоконагруженного проекта наступает момент, когда необходимо масштабирование. Возможно, ваш проект впервые упёрся в производительность железа (и таким образом перешёл в разряд высоконагруженных); возможно, это уже не первое масштабирование — не важно. Какие же проблемы могут возникнуть?
Во-первых, если вы увеличиваете количество бэкенд-серверов, и, соответственно, количество рабочих процессов, то с ростом количества одновременных клиентских подключений вырастают и накладные расходы на базах данных.
Во-вторых, достаточно быстро может кончиться ресурс in-memory баз данных. Потребуется создать (либо увеличить) кластер, а это каждый раз влечёт за собой необходимость модифицировать логику приложения.
В-третьих, чем больше серверов, тем больше вероятность, что один из них выйдет из строя. Поэтому неплохо задуматься о том, как обеспечить отказоустойчивость, а это, опять же, потребует модифицировать логику приложения.
В этом докладе я расскажу, как и какими инструментами можно легко решить все вышеперечисленные проблемы: уменьшить накладные расходы от большого количества подключений к базам данных, создать/модифицировать кластер БД прозрачно для приложения, а также прозрачно добавить устойчивость к падениям серверов БД.
План доклада:
- Введение. Методы масштабирования БД: репликация, шардирование.
- Создаём шардированные кластеры in-memory БД прозрачно для приложений: Twemproxy, Redis-proxy, Mcrouter.
- Уменьшаем накладные расходы от большого количества одновременных подключений на PostgreSQL с помощью PgBouncer.
- Создаём шардированный кластер PostgreSQL с помощью PL/Proxy.
- Добавляем прозрачную для приложения отказо�
Tempesta FW: challenges, internals, use cases / Александр Крижановский (Tempe...Ontico
Tempesta FW — это Open Source гибрид Web-акселератора и файервола, специально разработанный для высокопроизводительной доставки контента вне зависимости от DDoS или наплыва посетителей.
В докладе будет рассказано про задачи, которые ставились при разработке проекта и пути их решения. Рассмотрим проблемы современных операционных систем в приложении к Web-стеку (система фильтрации, Web-сервер, application слой, БД), и как они решаются в Tempesta — некоторые уже решены, некоторые еще в процессе работы.
И самое главное — у нас появился рабочий прототип, и я расскажу про типовые примеры инсталляции, фичи и конфигурацию, а также покажу бенчмарки.
Путь от монолита на PHP к микросервисам на Scala / Денис Иванов (2GIS)Ontico
В своём проекте мы решали следующие задачи:
+ Скорость разработки задачи;
+ Стоимость поддержки задачи;
+ Возможность распараллеливать вычисления и задачи;
+ Возможность максимально просто масштабировать приложение;
+ CI/CD с минимальными усилиями.
Я расскажу о том, как мы решали эти задачи, на какие грабли мы наступали, что из этого всего получилось, и что делать дальше.
Что получили в итоге:
+ Мощь JVM под капотом Scala;
+ 15 минут от нажатия на кнопку "Merge request" до продакшена в 3 датацентра и 6 серверов с прохождением тестов (юнит + функциональные + интеграционные + нагрузочные);
+ 6 нод с приложениями вместо 18 (по 2 в каждом датацентре для отказоустойчивости) с запасом прочности в 60%;
+ Независимые пофичные релизы без даунтайма всех компонентов приложения;
+ Масштабирование только того функционала и в том количестве, которое необходимо данному сервису.
DPDK в виртуальном коммутаторе Open vSwitch / Александр Джуринский (Selectel)Ontico
Intel DPDK (Data Plane Development Kit) — набор драйверов и библиотек, позволяющих приложениям взаимодействовать с сетевым устройством напрямую, минуя сетевой стек Linux. Это значительно увеличивает скорость обработки пакетов. DPDK интегрируется с рядом популярных программных решений, например, c виртуальным коммутатором Open vSwitch.
Возможностям и перспективам использования связи Open vSwitch + DPDK в облачных проектах и будет посвящен наш доклад. Мы подробно остановимся на проведённых тестах производительности и интерпретируем их результаты. Отдельное внимание будет уделено анализу трудностей и ограничений, с которыми пришлось столкнуться в ходе экспериментов.
Хранение данных на виниле / Константин Осипов (tarantool.org)Ontico
В rfc1149 дан исчерпывающий обзор преимуществ голубиной почты для протокола IP: низкая пропускная способность, невысокая надёжность, простая топология сети. Для того чтобы дать адекватный ответ вызовам эпохи мемристоров и квантовых вычислений, Tarantool 1.7 содержит новый движок для хранения данных на классических жёстких дисках и флэш-накопителях: Vinyl. Tarantool известен своей скоростью, и мы постарались не ударить в грязь лицом и на этот раз.
В докладе я расскажу об устройстве нашего нового storage engine:
- как мы объединили in-memory технологию и LSM (log structured merge) деревья для достижения оптимальной производительности и утилизации ресурса накопителя,
- как работает multiversion concurrency control в Vinyl,
- основной компонент в промышленной реализации LSM дерева - merge scheduler, т.е. планировщик слияний и сборки мусора дерева. Я расскажу о подходе, который позволяет максимально снизить износ накопителя, при этом уложиться в заданные рамки производительности запросов.
Внутреннее устройство PostgreSQL: временные таблицы и фрагментация памяти / Г...Ontico
Всем известно о существовании временных таблиц в PostgreSQL, но как они устроены, и чем грозит их некорректное использование - не столь очевидно.
На примере одного известного приложения, активно и некорректно использующего временные таблицы, мы расскажем о создаваемой ими проблеме фрагментации памяти.
Что такое фрагментация памяти, по каким признакам можно определить ее наличие, чем она грозит, почему она возникает при активном использовании временных таблиц, и как мы пропатчили PostgreSQL, чтобы ее избежать - обо всем этом можно узнать из нашего доклада.
Осваиваем Tarantool 1.6 / Евгений Шадрин (Sberbank Digital Ventures)Ontico
Tarantool - отечественная Opensource NoSQL база данных.
В докладе мы обсудим:
- Какое место занимают NoSQL базы данных в highload проектах?
Почему и для чего вам стоит NoSQL решения?
Какие NoSQL решения вы можете использовать?
- Рассмотрим, что из себя представляет Tarantool 1.6 - база данных и сервер приложений в одном лице.
Какие основные особенности Tarantool как NoSQL базы данных?
Lua как встроенный язык сервера приложений.
- Посмотрим, как можно начать использовать Tarantool в своих проектах, и сделаем первые шаги.
Как установить Tarantool.
Первый запуск и основы конфигурирования.
Модель данных.
Как создавать и работать с хранилищем данных.
Как использовать пакеты tarantool.
- Узнаем об интересных модулях и фичах Tarantool
Чем полезен application server
Tarantool http
Tarantool queue
- Познакомимся с сообществом Tarantool opensource
Почему сообщество - это важно?
Чем полезны opensource проекты начинающему разработчику?
Строим сервисы на базе Nginx и Tarantool / Василий Сошников, Андрей Дроздов (...Ontico
Слушатели этого доклада получат представление о том, как построить отказоустойчивое, быстрое, простое и легко масштабируемое решение на базе Nginx и Tarantool.
Коротко о главном:
+ Обзор внутреннего устройства шардинга в Tarantool.
+ Обзор Tarantool upstream модуля для Nginx.
+ Результаты нагрузочного тестирования Tarantool шардинга в связке с Nginx модулем.
+ Live-demo: распределенное отображение графа категорий Wikipedia в СУБД Tarantool с единой точкой входа и возможностью реалтайм поиска по категориям.
Погружение в виртуальную память и большие страницы / Константин Новаковский (...Ontico
РИТ++ 2017, HighLoad Junior
Зал Сингапур, 5 июня, 12:00
Тезисы:
http://junior.highload.ru/2017/abstracts/2688.html
Современные приложения часто используют большое количество памяти, ещё чаще разработчики не задумываются, как именно приложение работает с памятью, и откуда она берётся. Просим ядро дать кусок памяти и начинаем с ним что-то делать... Но что за память нам выделяет ядро операционной системы? Память на самом деле виртуальная и делится на единицы, называемые страницами. Страницы бывают маленькими, бывают большими и очень большими.
...
Чему мы научились разрабатывая микросервисы?Vadim Madison
Доклад с конференции Backend Conf 2016
Начав разработку нового продукта через микросервисы, мы неожиданно для себя обнаружили, что микросервисы — это не просто "вместо одного большого приложения теперь пишем много маленьких". При разработке большой системы она сама собой через какое-то время становится набором отдельных сервисов, которые должны взаимодействовать между собой, поэтому стабильная работа сервисов и их взаимодействие не стало чем-то новым. Неожиданностью стало то, что система стала значительно более динамической, она стала постоянно изменяться отдельными небольшими частями, сервисы стали часто перезапускаться, а количество запущенных нод сервисов стало расти по экспоненте.
Очень быстро стал актуальным вопрос конфигурирования — если раньше, выкатив новую версию монолита с единым конфигом, мы применяли правки на всю систему сразу, то с микросервисами все сложнее — пара сотен работающих нод и всем нужно применить изменения. Требования к деплою также поменялись — он стал частью процесса разработки, а тестирование стало частью деплоя. Количество необходимого ПО для функционирования системы также стало некоторым сюрпризом.
В докладе я расскажу о том, как в итоге это работает у нас, как мы решили такие вопросы как:
- конфигурирование сервисов;
- интеграция между собой;
- тестирование;
- версионирование;
- масштабирование.
Расскажу, какие тулзы мы в итоге используем, а от каких отказались.
Мониторинг ожиданий в PostgreSQL / Курбангалиев Ильдус (Postgres Professional)Ontico
В многоядерных высоконагруженных системах с высокой конкурентностью часто бывает сложно определить, чем занят отдельный процесс PostgreSQL. Он может находиться в ожидании локов высокого уровня, таких как локи таблиц, внутренних локов, используемых для синхронизации процессов, ввода-вывода и многих других.
В настоящий момент среди всех событий ожидания мониторить можно только локи высокого уровня с помощью представлений PostgreSQL. Другие типы ожиданий требуют использования низкоуровневых утилит типа perf, systemtap и других. Эти утилиты требуют специальных знаний и могут быть платформозависимыми. В то же время другие enterprise базы данных уже включают в себя инструменты для мониторинга ожиданий.
Мы разработали патч, который реализует мониторинг ожиданий в PostgreSQL. С минимальной настройкой (несколько конфигурационных параметров) этот патч показывает полную информацию о текущих ожиданиях в режиме реального времени и с небольшим оверхедом на всю систему. Этот патч уже работает на продакшен серверах Яндекса и показал свою полезность.
В докладе было рассказано, зачем нужны сессии, где Badoo хранили их раньше, что придумали, почему решили использовать Tarantool, и к чему все это привело.
Open Source SQL-базы данных вступили в эру миллионов запросов в секунду / Фед...Ontico
Широко распространено мнение, что SQL СУБД обречены быть медлительными и неповоротливыми, поскольку несут груз совместимости с предыдущими версиями. Это расхожее мнение широко эксплуатируется маркетингом NoSQL СУБД. Однако, это не всегда действительно так.
Разработка в Open Source сообществе позволяет продукту развиваться достаточно гибко, чтобы отвечать требованиям времени. В MySQL и PostgreSQL – самых популярных Open Source СУБД – недавно были проведены оптимизации для работы на больших серверах, что позволило им выполнять более миллиона SQL-запросов в секунду на одном экземпляре БД.
В данном докладе будут рассмотрены конкретные оптимизации, которые позволили добиться таких результатов, которые раньше могли бы показаться фантастическими. И можно сказать, что Open Source СУБД вошли в эру миллионов запросов в секунду.
BigMemory - работа с сотнями миллионов бизнес-объектов / Дмитрий Хмаладзе (Ag...Ontico
РИТ++ 2017, HighLoad Junior
Зал Сингапур, 5 июня, 11:00
Тезисы:
http://junior.highload.ru/2017/abstracts/2683.html
Наш доклад описывает способ использования больших объемов памяти, которые стали доступны в последние годы. К сожалению, эта память обычно остается незадействованной в управляемых средах исполнения в связи с принудительной сборкой мусора. Разработчики прибегают к внешним хранилищам данных ( i.e Memcached), что несет дополнительные расходы.
...
сравнение производительности СУБД MySQL и PostgreSQL для "типичной задачи стартапа".
Презентация сопровождала тестовую online-сессию и потому не содержит результатов тестирования.
Оптимизации уровня CPU, Андрей Акиньшин (JetBrains)Ontico
В современном мире многие разработчики перестали стараться писать высокопроизводительный код. Порой их можно понять: в наше время прекрасных облачных решений дешевле докупить дополнительных серверов, чем тратить время на оптимизацию кода. Но что, если у вас нет такой возможности? Что, если для текущей задачи вы ограничены одной машиной или даже одним потоком?
В этом докладе мы обсудим некоторые подходы, которые помогают выжимать максимум производительности из современного железа и позволяют разгонять программы, которые, казалось бы, разогнать нельзя. В числе прочего будем обсуждать следующие вещи: CPU cache, Instruction Level Parallelism, False sharing, Branch Prediction, SEE/AVX instructions и т.д.
101 способ приготовления RabbitMQ и немного о pipeline архитектуре / Филонов ...Ontico
Архитектурный шаблон проектирования конвейер (pipeline) хорошо зарекомендовал себя при проектировании высоконагруженных (highload) систем. Использование шины сообщений (message bus) при реализации каналов взаимодействия позволяет достигать хороших показателей масштабируемости (scalability), но при этом появляются дополнительные накладные расходы, которые сказываются на показателях производительности (performance).
В докладе обсуждаются варианты использования системы обмена сообщениями RabbitMQ в качестве связующего программного обеспечения (middleware) для построения конвейерной архитектуры. Рассматриваются вопросы производительности и масштабирования как stateless так и statefull фильтров.
В качестве примера рассматривается реализация системы обработки сложных событий (complex event processing) применительно к управлению журналированием (log management).
шишки, набитые за 15 лет использования акторов в c++ v.001.3corehard_by
Автор доклада давно и успешно использует Модель Акторов при разработке приложений на C++. В основном это был положительный опыт. Но есть некоторые неочевидные моменты, про которые было бы хорошо узнать заранее. О том, где использование Модели Акторов уместно, а где нет, на какие грабли довелось наступить, какие шишки были набиты, как можно упростить себе жизнь и пойдет речь в докладе.
Евгений Охотников
Системный архитектор @stiffstream
Подробнее...
модели акторов в с++ миф или реальностьcorehard_by
В настоящее время многие разрабатываемые решения носят характер сложных или распределенных систем. Для построения таких систем часто используются Erlang, Elixir или Akka + family language of JVM. Благодаря чему они так хороши? В Erlang, Elixir и Akkk применяется модель акторов на уровне языка или библиотеки как базовый подход. Почему же С++ разработчики должны быть обделены? Рассмотрим применение модели акторов на примере задачи из продакшена. Поговорим о сложностях, которые встречаются при применении модели акторов. В процессе обсудим "подводные камни", которые можно встретить в той или иной реализации модели акторов.
Как понять, что происходит на сервере? / Александр Крижановский (NatSys Lab.,...Ontico
Запускаем сервер (БД, Web-сервер или что-то свое собственное) и не получаем желаемый RPS. Запускаем top и видим, что 100% выедается CPU. Что дальше, на что расходуется процессорное время? Можно ли подкрутить какие-то ручки, чтобы улучшить производительность? А если параметр CPU не высокий, то куда смотреть дальше?
Мы рассмотрим несколько сценариев проблем производительности, рассмотрим доступные инструменты анализа производительности и разберемся в методологии оптимизации производительности Linux, ответим на вопрос за какие ручки и как крутить.
Основы индексирования и расширенные возможности EXPLAIN в MySQL / Василий Лук...Ontico
Индексы
- типы индексов;
- типы доступа к таблице;
- составные индексы (когда они работают);
- получение информации об индексе (show index; - описание формата);
- примеры с поиском по нескольким полям и сортировкой: какие индексы будут использоваться, а какие нет;
- что делать в случае нескольких условий по диапазону;
- как сервер выбирает индекс, который будет использован;
- директивы use/force/ignore index.
EXPLAIN
- как работает оптимизатор запросов;
- недостатки explain;
- explain extended;
- получение sql запроса, восстановленного из плана;
- формат выводимой explain информации:
-- что означает каждый столбец;
-- какие значения принимает (для extra только самые часто встречающиеся);
-- на что обратить внимание с точки зрения производительности;
-- как правильно читать план-разбор сложного примера с join-ами, подзапросами (обычными и from) и union-ами;
- новые возможности explain в последних версиях.
Практические примеры (исходный запрос, план, оптимизация, итоговый план) для разных случаев оптимизации:
1. добавление индексов;
2. эквивалентное изменение запроса: or --> union, подзапрос --> join;
3. разбиение запроса на несколько с сохранением промежуточных данных во временной таблице;
4. изменение структуры данных;
5. использование пользовательских переменных.
Принципы и приёмы обработки очередей / Константин Осипов (Mail.ru)Ontico
Насколько повысится среднее время обработки одного запроса если увеличить нагрузку вдвое? Почему производительность базы данных может снизиться при росте числа клиентов? Как добиться эффективного распределения большого числа задач на весь кластер? О практике и о теории обработки очередей на которой основана практика в моём докладе.
Горизонтальное масштабирование: что, зачем, когда и как /Александр Макаров (Y...Ontico
Масштабирование — способность наращивать систему для обработки большего количества трафика, не теряя при этом пользовательские качества: скорость и отзывчивость.
Масштабирование различают двух типов: вертикальное (больше памяти, диска, лучше процессор) и горизонтальное (больше серверов в кластере).
- Зачем оно нужно, если и так всё работает?
- Когда? Мониторинг, необдуманные решения, оптимизация и жизнь с одним сервером.
- Типичная схема.
- Балансировка нагрузки.
- Какие, вообще, проблемы на стороне приложения?
- Почему PHP так хорош для масштабирования.
- Сессии.
- База данных.
- Файлы.
- Как быть со статистикой?
Обзорный доклад про базовое внутреннее устройство любого современного поискового движка. Про сжатые списки документов и позиций, как затем с ними работает поиск совпадающих документов (и разные операторы), как устроено ранжирование найденных документов, как бывают устроены и работают с фильтрацией и агрегацией дополнительные (нетекстовые) атрибуты документов. По возможности, упоминание всех известных вариантов реализаций (как, вообще, можно, как сделано в Sphinx, как в Lucene).
Как балансировать на «сетевом» канате под куполом тяжелой нагрузки? / Сергей ...Ontico
Цель доклада – рассмотреть и систематизировать информацию о том, как балансировка нагрузки помогает делать миллионы людей счастливыми, сохраняя им нервные клетки, спасает беззащитные ПК и прочие девайсы от приступов ярости их владельцев во время бесконечных загрузок сайтов, а посетителям онлайн магазинов не дает побросать их виртуальные корзинки в бесконечных очередях на кассе.
Вашему вниманию будет представлен небольшой сравнительный анализ методов балансировки трафика, мы рассмотрим плюсы и минусы каждой схемы. Я расскажу, к каким хитростям можно прибегать, минуя большие затраты на покупку готовых решений и получая максимум профита от существующей инфраструктуры.
Доклад будет полезен всем, кто хочет знать, но боится спросить, благодаря чему HighLoad-проекты такие устойчивые и надежные. Тема наверняка заинтересует тех, кто только начинает свои шаги на пути к уверенному и высокопроизводительному сервису.
Тезисы доклада:
1. Что такое балансировка и зачем она вообще нужна? Когда хорошо бы об этом задуматься?
2. Реализация балансировки: виды, способы, практики.
3. Методы локальной балансировки
3.1. Балансировка на канальном уровне (L2-метод)
• Используем отдельным балансировщик
• Сократим расходы, избавимся от выделенного балансировщика
• Плюсы и минусы
3.2. Балансировка на сетевом уровне (L3-метод)
• Преимущества и недостатки
4. Методы глобальной балансировки
4.1. DNS балансировка.
• DNS Round Robin
• Сильные и слабые стороны подхода
4.2. HTTP Redirect
• Механизм балансировки на основе Redirect запросов
• Плюсы и минусы метода
4.3. Балансировка на базе Anycast
• Когда Anycast – это хорошо, а когда - не очень?
5. Некоторые не менее расп
LuaJIT как основа для сервера приложений - проблемы и решения / Игорь Эрлих (...Ontico
С того момента, как было принято решение использовать язык Lua в качестве языка описания бизнес-логики в нашей платформе, прошло уже больше восьми лет. Проекты росли, данных становилось больше, возрастала нагрузка на сервера приложений. Со временем у нас накопился солидный багаж знаний о том, как устроен LuaJIT, с какими проблемами можно столкнуться при его использовании и как эти проблемы можно решать.
Я расскажу про то...
* Почему при миграции с x86 на x64 доступной памяти в LuaJIT становится меньше, и как мы с этим боролись.
* Как загрузить в LuaJIT несколько миллионов объектов и не умереть в тормозах от сборщика мусора.
* Насколько ужасна встроенная функция хеширования строк и почему иногда надо жертвовать производительностью в пользу качества.
Эволюция процесса деплоя в проекте / Денис Яковлев (2ГИС)Ontico
Если наш проект — это не коробочный продукт, а, например, веб-сервис, на который постоянно ходят пользователи, их много и они сразу видят изменения, то в жизненном цикле разработки у нас возникает еще одна задача — задача деплоя готового кода в боевое окружение.
В самом начале, когда наш проект маленький и простой, на эту задачу никто может и не обращать внимания, так как все происходит быстро и просто. Процесс деплоя состоит из 2-3 общеизвестных шагов — git pull, yii migrate, etc..., которые легко запомнить и в них сложно ошибиться.
С развитием проекта его сложность возрастает — он уже крутится на нескольких серверах, появляются новые компоненты (утилиты, библиотеки и т.д.), новые сущности (балансеры, кэшы, и т.д.). Держать всю инфраструктуру в голове становится невозможным, ведение документации привносит больше проблем, нежели решений, люди ошибаются чаще и т.д.
В докладе:
— рассмотрим подробно вышеуказанные проблемы, с которыми неизбежно сталкиваются проекты;
— обсудим, какие решения существуют в индустрии (chef, ansible, etc), чем они отличаются, какой выбрать и в чем их задача;
— поговорим про административные вопросы, которые с этим связаны.
Как устроена 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-операторы подробно рассматривать НЕ будем, эти скучные мелочи необходимо будет затем самостоятельно смотреть в документации (или не смотреть).
Производительность запросов в PostgreSQL - шаг за шагом / Илья Космодемьянски...Ontico
Вы взяли ваш любимый фреймворк™ и быстро запустили крутой проект, который раскручивается, приносит деньги и требует быстрого развития, чтобы оставить конкурентов далеко позади.
В один далеко не прекрасный момент вы понимаете, что корень всех зол - медленное время ответа базы данных, а ваш админ зло смотрит на разработчиков красными от бессонницы глазами и ругается на безумные запросы, которые генерирует ORM. Тот самый ORM, который позволил вам так быстро запустить ваш замечательный проект.
Знакомо? Тогда вам будет интересно послушать, как заставить вашу базу данных работать прямо сейчас. А именно:
- какое место в общей производительности базы данных занимает оптимизация запросов?
- когда прекращать “крутить гайки” и заниматься медленными запросами?
- что такое медленный запрос и когда их надо начинать оптимизировать?
- как оптимизировать?
- EXPLAIN, EXPLAIN ANALYZE - как читать и на что обращать внимание?
- как работает оптимизатор запросов PostgreSQL и где могут быть узкие места?
- для чего нужны и для чего не нужны индексы, методики индексирования, и как быть уверенным, что ваш индекс правильно используется?
- какие запросы не будут работать быстро никогда, и как с этим жить?
- ошибается ли оптимизатор и, если да, то почему и как его в таком случае призвать к порядку?
Какие бывают провайдеры услуг дата-центров и как выбрать оптимальный? / Игорь...Ontico
Все знают поговорку "два переезда равны одному пожару" и все понимают, что значит "перенос highload проекта с одного провайдера хостинга на другого с обеспечением непрерывности функционирования сервисов для пользователей".
Выбор "правильного" провайдера услуг дата-центров очень важен, но есть две проблемы:
1) "Все лгут" - маркетинг провайдера и реальность далеко не всегда совпадают, все провайдеры рассказывают о своих сильных сторонах и умалчивают о слабых;
2) "когда у вас в руках молоток - все вокруг превращается в гвозди" - все провайдеры услуг имеют свою специализацию и любую задачу клиента они стремятся решить так, как умеют, а не так как надо клиенту.
В своем докладе я постараюсь рассмотреть все аспекты вопроса выбора провайдера/провайдеров услуг хостинга/дата-центров.
Данный доклад ориентирован на широкую аудиторию и будет полезен всем, кому надо выбирать провайдера услуг хостинга/дата-центров для внутренних и/или внешних проектов.
В рамках доклада будут рассмотрены следующие вопросы:
1) формализация ТЗ на оказание услуг провайдерами или "а что нам надо";
2) классификация провайдеров дата-центров по спектру оказываемых услуг;
3) SLA - что это? какие SLA бывают? что подразумевают провайдеры и чего ожидаете вы в документе под названием Service Level Agreement;
4) магическое слово compliance, или что хочет государство;
5) чем отличаются одни провайдеры от других;
6) как проверить провайдера - uptime/связанность/рейтинги/спектр услуг;
7) пишем RFP - как сформулировать потребности так, чтобы потом результат не разочаровал.
NoSQL - коротко о главном / Сергей Туленцев (TextMaster)Ontico
В последнее время сайты и веб-приложения растут всё быстрее, а задачи, стоящие перед БД, эволюционируют. Поэтому для (успешных) проектов традиционная реляционная СУБД часто не может удовлетворить все нужды. В ответ на эту проблему возникло большое количество разнообразных решений, очень различающихся по функциональности и характеристикам. При этом они все заносятся под один большой зонтик "NoSQL", что не способствует пониманию вещей. Запутанные веб-разработчики пытаются взять текущую модную и обсуждаемую NoSQL БД и приспособить её под свои нужды, не всегда понимая, нужную ли технологию они выбрали (референс к MongoDB is Web Scale http://www.youtube.com/watch?v=b2F-DItXtZs).
Целью доклада является упорядочение хаоса в головах разработчиков.
- Обзор популярных БД и их классификация (KV store, document store, columnar, etc).
- CAP-теорема и её применение к выбору БД (где-то параметры можно настроить, где-то подпереть сбоку костылем, где-то - увы).
- Типичные примеры применения.
- Антипаттерны применения (из личного опыта и тысяч прочитанных вопросов на stackoverflow :) ).
Presentation given at the Stockholm R useR Group (SRUG) meetup on Dec 6, 2016. Contains a general overview of deep learning, material on using Tensorflow in R etc.
Основные кейсы использования in-memory СУБД на примере Тарантула и проектов M...Ontico
Основные кейсы использования Тарантула:
1. Когда нужна OLTP-система, позволяющая обрабатывать транзакции в режиме почти реального времени (с милисекундными задержками) и/или с огромной пропускной способностью (сотни тысяч запросов в секунду). Примеры — система сессий, система антибрутфорса, система противодействия атакам, система очередей и пуш-уведомлений, роутинг запросов между серверами.
Далее - http://backendconf.ru/2016/abstracts/2096.html
Поддержка высоконагруженного проекта: мониторинг, резервирование, обслуживани...Ontico
1. Мониторинг высоконагруженного проекта.
1.1. Специфика мониторинга высоконагруженного проекта: гранулярность мониторинга, надежность системы мониторинга, система оповещений.
1.2. Мониторинг и контроль распределенных систем.
1.3. Специфика организации оповещений в высоконагруженном проекте. Превентивный мониторинг.
2. Резервирование и резервное копирование в высоконагруженном проекте.
2.1. Резервирование и резервное копирование - разные вещи.
2.2. Резервирование: на уровне сервера, дата-центра, географически распределенных площадок.
2.1. Организация резервного копирования. Сохранность часто обновляемых данных.
3. Обслуживание высоконагруженного проекта.
3.1. Организация поддержки высоконагруженного проекта: опыт, специфика работы.
3.2. Организация дежурств, эскалация оповещений.
3.3. Аварии в высоконагруженных проектах: примеры из жизни.
Евгений Лазин. Неизменяемая структура данных HAMT для создания БД в памятиFProg
В данном докладе рассматривается пример использования персистентной структуры данных - функциональной версии HAMT, для создания main memory базы данных. Данная реализация HAMT располагается в shared memory и используется для хранения индексов.
Рассматриваются задачи, которые были быстро и эффективно решены благодаря использованию неизменяемых структур данных (управление изменениями, поддержка ACID-свойств), а также проблемы, возникшие из-за этого. Также, рассмотрен метод реализации персистентного графа, использующий изменяемые данные и позволяющий достичь большей производительности, по сравнению с аналогичной, неизменяемой структурой данных.
Антон Потапов — С++ контейнеры и многопоточность: вместе или врозь?Yandex
Антон Потапов, Intel
Стандартная библиотека С++ содержит набор наиболее распространённых контейнеров для организации данных. С++11 предоставляет минимальные гарантии безопасности работы с контейнерами в многопоточной среде, но зачастую этого недостаточно для эффективного их использования в параллельных программах. В докладе речь пойдёт о современных подходах к реализации эффективных «конкурентных» контейнеров, а также основных возникающих при этом проблемах и способах их решения.
Доклад Сергея Аверина на CodeFest-2013. "MySQL+HandlerSocket=NoSQL".Badoo Development
Мы уже около 3-х лет используем HandlerSocket в нашей инфраструктуре сайта badoo.com. За это время мы накопили опыт решения характерных для Handlersocket проблем, появляющихся при использовании.
Несколько команд внутри Баду активно используют HS для решения разноплановых задач мобильных и настольных приложений Баду. Где-то мы используем HS как замену Memcached, где-то как простой поисковый механизм, где-то как хранилище типа ключ-значение. Наш HS-кластер содержит более 30 серверов, обрабатывая порядка 8000 запросов/сек.
Спикер также предоставляет написанный им код библиотеки-клиента для Handlersocket на PHP.
Про что доклад:
• что это вообще такое;
• чем является HS и чем не является;
• внутреннее устройство и работа HS;
• протокол;
• примеры использования в Баду, с цифрами и графиками;
• особенности: шардирование, Percona Server, постоянные соединения (бенефиты, проблемы и их решения), tips & tricks;
• полезные сслыки, ответы на FAQ.
Доклад рассчитан на highload-разработчиков, работающих с реляционными БД.
One-cloud — система управления дата-центром в Одноклассниках / Олег Анастасье...Ontico
HighLoad++ 2017
Зал «Калининград», 8 ноября, 15:00
Тезисы:
http://www.highload.ru/2017/abstracts/2964.html
Одноклассники состоят из более чем восьми тысяч железных серверов, расположенных в нескольких дата-центрах. Каждая из этих машин была специализированной под конкретную задачу - как для обеспечения изоляции отказов, так и для обеспечения автоматизированного управления инфраструктурой.
...
Масштабируя DNS / Артем Гавриченков (Qrator Labs)Ontico
HighLoad++ 2017
Зал «Калининград», 8 ноября, 16:00
Тезисы:
http://www.highload.ru/2017/abstracts/3032.html
Протокол DNS на семь лет старше, чем Всемирная паутина. Стандарты RFC 882 и 883, определяющие основную функциональность системы доменных имён, появились в конце 1983 года, а первая реализация последовала уже годом позже. Естественно, что у технологии столь старой и при этом по сей день активнейшим образом используемой просто не могли не накопиться особенности, неочевидные обыкновенным пользователям.
...
Создание BigData-платформы для ФГУП Почта России / Андрей Бащенко (Luxoft)Ontico
HighLoad++ 2017
Зал «Калининград», 8 ноября, 13:00
Тезисы:
http://www.highload.ru/2017/abstracts/3010.html
В этом докладе я расскажу, как BigData-платформа помогает трансформировать Почту России, как мы управляем построением и развитием платформы. Расскажу про найденные удачные решения, например, как разбиение на продукты с понятными SLA и интерфейсами между ними помогло нам сохранять управляемость с ростом масштабов проекта.
...
Готовим тестовое окружение, или сколько тестовых инстансов вам нужно / Алекса...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 10:00
Тезисы:
http://www.highload.ru/2017/abstracts/2914.html
Казалось бы, что нужно для организации тестового окружения? Тестовая железка и копия боевого окружения - и тестовый сервер готов. Но как быть, когда проект сложный? А когда большой? А если нужно тестировать одновременно много версий? А если все это вместе?
Организация тестирования большого развивающегося проекта, где одновременно в разработке и тестировании около полусотни фич - достаточно непростая задача. Ситуация обычно осложняется тем, что иногда есть желание потрогать еще не полностью готовый функционал. В таких ситуациях часто возникает вопрос: "А куда это можно накатить и где покликать?"
...
Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2854.html
Из этого доклада вы узнаете о возможностях репликации и автофейловера PostgreSQL, в том числе о возможностях, ставших доступных в PostgreSQL 10.
Среди прочих, будет затронуты следующие темы:
* Виды репликации и решаемые с ее помощью проблемы.
* Настройка потоковой репликации.
* Настройка логической репликации.
* Настройка автофейловера / HA средствами Stolon и Consul.
После прослушивания доклада вы сможете самостоятельно настраивать репликацию и автофейловер PostgreSQL.
PostgreSQL Configuration for Humans / Alvaro Hernandez (OnGres)Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 17:00
Тезисы:
http://www.highload.ru/2017/abstracts/3096.html
PostgreSQL is the world’s most advanced open source database. Indeed! With around 270 configuration parameters in postgresql.conf, plus all the knobs in pg_hba.conf, it is definitely ADVANCED!
How many parameters do you tune? 1? 8? 32? Anyone ever tuned more than 64?
No tuning means below par performance. But how to start? Which parameters to tune? What are the appropriate values? Is there a tool --not just an editor like vim or emacs-- to help users manage the 700-line postgresql.conf file?
Join this talk to understand the performance advantages of appropriately tuning your postgresql.conf file, showcase a new free tool to make PostgreSQL configuration possible for HUMANS, and learn the best practices for tuning several relevant postgresql.conf parameters.
Inexpensive Datamasking for MySQL with ProxySQL — Data Anonymization for Deve...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 16:00
Тезисы:
http://www.highload.ru/2017/abstracts/3115.html
During this session we will cover the last development in ProxySQL to support regular expressions (RE2 and PCRE) and how we can use this strong technique in correlation with ProxySQL's query rules to anonymize live data quickly and transparently. We will explain the mechanism and how to generate these rules quickly. We show live demo with all challenges we got from the Community and we finish the session by an interactive brainstorm testing queries from the audience.
Опыт разработки модуля межсетевого экранирования для MySQL / Олег Брославский...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 15:00
Тезисы:
http://www.highload.ru/2017/abstracts/2957.html
Расскажем о нашем опыте разработки модуля межсетевого экрана для MySQL с использованием генератора парсеров ANTLR и языка Kotlin.
Подробно рассмотрим следующие вопросы:
— когда и почему целесообразно использовать ANTLR;
— особенности разработки ANTLR-грамматики для MySQL;
— сравнение производительности рантаймов для ANTLR в рамках задачи синтаксического анализа MySQL (C#, Java, Kotlin, Go, Python, PyPy, C++);
— вспомогательные DSL;
— микросервисная архитектура модуля экранирования SQL;
— полученные результаты.
ProxySQL Use Case Scenarios / Alkin Tezuysal (Percona)Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 14:00
Тезисы:
http://www.highload.ru/2017/abstracts/3114.html
ProxySQL aims to be the most powerful proxy in the MySQL ecosystem. It is protocol-aware and able to provide high availability (HA) and high performance with no changes in the application, using several built-in features and integration with clustering software. During this session we will quickly introduce its main features, so to better understand how it works. We will then describe multiple use case scenarios in which ProxySQL empowers large MySQL installations to provide HA with zero downtime, read/write split, query rewrite, sharding, query caching, and multiplexing using SSL across data centers.
MySQL Replication — Advanced Features / Петр Зайцев (Percona)Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 13:00
Тезисы:
http://www.highload.ru/2017/abstracts/2954.html
MySQL Replication is powerful and has added a lot of advanced features through the years. In this presentation we will look into replication technology in MySQL 5.7 and variants focusing on advanced features, what do they mean, when to use them and when not, Including.
When should you use STATEMENT, ROW or MIXED binary log format?
What is GTID in MySQL and MariaDB and why do you want to use them?
What is semi-sync replication and how is it different from lossless semi-sync?
...
Внутренний open-source. Как разрабатывать мобильное приложение большим количе...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 12:00
Тезисы:
http://www.highload.ru/2017/abstracts/3120.html
Количество разработчиков мобильных приложений Сбербанк Онлайн с начала 2016 года выросло на порядок. Для того чтобы продолжать выпускать качественный продукт, мы кардинально перестраиваем процесс разработки.
Количество внутренних заказчиков тех или иных доработок в какой-то момент выросло настолько, что разработчики стали узким местом. Мы внедрили культуру разработки, которую можно условно назвать "внутренним open-source", сохранив за собой контроль над архитектурой и качеством проекта, но позволив разрабатывать новые фичи всем желающим.
...
Подробно о том, как Causal Consistency реализовано в MongoDB / Михаил Тюленев...Ontico
HighLoad++ 2017
Зал «Мумбай», 8 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2836.html
При использовании Eventually Consistent распределенных баз данных нет гарантий, что чтение возвращает результаты последних изменений данных, если чтение и запись производятся на разных узлах. Это ограничивает пропускную способность системы. Поддержка свойства Causal Consistency снимает это ограничение, что позволяет улучшить масштабируемость, не требуя изменений в коде приложения.
...
Балансировка на скорости проводов. Без ASIC, без ограничений. Решения NFWare ...Ontico
HighLoad++ 2017
Зал «Мумбай», 8 ноября, 16:00
Тезисы:
http://www.highload.ru/2017/abstracts/2858.html
Аудитория Одноклассников превышает 73 миллиона человек в России, СНГ и странах дальнего зарубежья. При этом ОК.ru - первая социальная сеть по просмотрам видео в рунете и крупнейшая сервисная платформа.
Качественный и количественный рост DDoS-атак за последние годы превращает их в одну из первоочередных проблем для крупнейших интернет-ресурсов. В зависимости от вектора атаки “узким” местом становится та или иная часть инфраструктуры. В частности, при SYN-flood первый удар приходится на систему балансировки трафика. От ее производительности зависит успех в противостоянии атаке.
...
Перехват трафика — мифы и реальность / Евгений Усков (Qrator Labs)Ontico
HighLoad++ 2017
Зал «Мумбай», 8 ноября, 15:00
Тезисы:
http://www.highload.ru/2017/abstracts/3008.html
Никогда не было и вот снова случилось! Компания Google в результате перенаправления трафика сделала недостпуными в Японии несколько тысяч различных сервисов, большинство из которых никак не связано с самой компанией Google. Однако, подобные инциденты происходят с завидной регулярностью, вот только не всегда попадают в большие СМИ. У таких инцидентов могут быть разные причины, начиная от ошибок сетевых инженеров и заканчивая государственным регулированием.
...
И тогда наверняка вдруг запляшут облака! / Алексей Сушков (ПЕТЕР-СЕРВИС)Ontico
HighLoad++ 2017
Зал «Мумбай», 8 ноября, 14:00
Тезисы:
http://www.highload.ru/2017/abstracts/2925.html
Облака и виртуализация – современные тренды развития IT-технологий. Операторы связи строят свои TelcoClouds на стандартах NFV (Network Functions Virtualization) и SDN (Software-Defined Networking). В докладе начнем с основ виртуализации, далее разберемся, для чего используются NFV и SDN, потом полетим к облакам и вернемся на землю для решения практических задач!
...
Как мы заставили Druid работать в Одноклассниках / Юрий Невиницин (OK.RU)Ontico
HighLoad++ 2017
Зал «Мумбай», 8 ноября, 10:00
Тезисы:
http://www.highload.ru/2017/abstracts/3045.html
Как мы заставили Druid работать в Одноклассниках.
«Druid is a high-performance, column-oriented, distributed data store» http://druid.io.
Мы расскажем о том, как, внедрив Druid, мы справились с ситуацией, когда MSSQL-based система статистики на 50 терабайт стала:
- медленной: средняя скорость ответа была в разы меньше требуемой (и увеличилась в 20 раз);
- нестабильной: в час пик статистика отставала до получаса (теперь ничего не отстает);
- дорогой: изменилась политика лицензирования Microsoft, расходы на лицензии могли составить миллионы долларов.
...
Разгоняем ASP.NET Core / Илья Вербицкий (WebStoating s.r.o.)Ontico
HighLoad++ 2017
Зал «Рио-де-Жанейро», 8 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2905.html
Прошло более года с того момента, как Microsoft выпустила первую версию своего нового фреймворка для разработки web-приложений ASP.NET Core, и с каждым днем он находит все больше поклонников. ASP.NET Core базируется на платформе .NET Core, кроссплатформенной версии платформы .NET c открытым исходным кодом. Теперь у С#-разработчиков появилась возможность использовать Mac в качестве среды разработки, и запускать приложения на Linux или внутри Docker-контейнеров.
...
100500 способов кэширования в Oracle Database или как достичь максимальной ск...Ontico
HighLoad++ 2017
Зал «Рио-де-Жанейро», 8 ноября, 14:00
Тезисы:
http://www.highload.ru/2017/abstracts/2913.html
Изначально будут раскрыты базовые причины, которые заставили появиться такой части механизма СУБД, как кэш результатов, и почему в ряде СУБД он есть или отсутствует.
Будут рассмотрены различные варианты кэширования результатов как sql-запросов, так и результатов хранимой в БД бизнес-логики. Произведено сравнение способов кэширования (программируемые вручную кэши, стандартный функционал) и даны рекомендации, когда и в каких случаях данные способы оптимальны, а порой опасны.
...
Apache Ignite Persistence: зачем Persistence для In-Memory, и как он работает...Ontico
HighLoad++ 2017
Зал «Рио-де-Жанейро», 8 ноября, 13:00
Тезисы:
http://www.highload.ru/2017/abstracts/2947.html
Apache Ignite — Open Source платформа для высокопроизводительной распределенной работы с большими данными с применением SQL или Java/.NET/C++ API. Ignite используют в самых разных отраслях. Сбербанк, ING, RingCentral, Microsoft, e-Therapeutics — все эти компании применяют решения на основе Ignite. Размеры кластеров разнятся от всего одного узла до нескольких сотен, узлы могут быть расположены в одном ЦОД-е или в нескольких геораспределенных.
...
HighLoad++ 2017
Зал «Рио-де-Жанейро», 8 ноября, 12:00
Тезисы:
http://www.highload.ru/2017/abstracts/3005.html
Когда мы говорим о нагруженных системах и базах данных с большим числом параллельных коннектов, особый интерес представляет практика эксплуатации и сопровождения таких проектов. В том числе инструменты и механизмы СУБД, которые могут быть использованы DBA и DevOps-инженерами для решения задач мониторинга жизнедеятельности базы данных и ранней диагностики возможных проблем.
...
Что особенного в СУБД для данных в оперативной памяти / Константин Осипов (Tarantool.org)
1. Алгоритмы и структуры
данных для СУБД в
оперативной памяти
Константин Осипов
kostja@tarantool.org
http://try.tarantool.org
2. Содержание
It's time for a complete
rewrite!..
или почему в 2015 г.
можно и нужно создавать
новые СУБД
Database people are
logicians..
или почему инженерия
ПО не менее важна чем
красивые теории
First time is the best time!..
смотрим на аллокаторы
памяти
Deep dive...
специализированные
структуры данных для
оперативной памяти.
4. Постановка задачи - ACID
● ATOMICITY – транзакции работают по принципу “всё или
ничего” - ошибка в середине приводит к откату всех
действий транзакции
● CONSISTENCY – транзакции при модификации данных
сохраняют их консистентность
● ISOLATION - выполнение параллельных транзакций имеет
тот же эффект что и их последовательное применение
● DURABILTY – эффекты завершённых транзакций не
теряются даже в случае программного сбоя или выхода из
строя оборудования
5. ● Isolation — выполнение параллельных транзакций имеет
тот же эффект что и их последовательное применение
Isolation
6. ● Isolation — выполнение параллельных транзакций имеет
тот же эффект что и их последовательное применение
● Consistency без isolation не достижим
Isolation
7. ● Isolation — выполнение параллельных транзакций имеет
тот же эффект что и их последовательное применение
● Consistency без isolation не достижим
● Пусть есть x, y, z – данные к которым осуществляется
совместный доступ
Isolation
8. ● Isolation — выполнение параллельных транзакций имеет
тот же эффект что и их последовательное применение
● Consistency без isolation не достижим
● Пусть есть x, y, z – данные к которым осуществляется
совместный доступ
● Расписание (schedule) — возможная история
выполнения транзакций, конкретный порядок операций
чтения и записи относительно друг друга
E = r1[x] w1[x] w2[y] r2[z]
Isolation
9. ● Если t1 транзакция использует X не допустить
модификацию X в других транзакциях до завершения t1
➔ Конкурентные транзакции работают с разными
поднаборами данных
➔ Порядок модификаций одних и тех же данных
фиксирован
● Блокировка (лок) — механизм обеспечения
эксклюзивного доступа
Isolation: классическое решение
10. ● Мы говорим, что история выполнения транзакций
последовательна, если их действия в истории не
пересекаются:
E = r1[x] w1[y] commit1 w2[y] r2[z] commit2
● Принцип two phase locking — локи захваченные
транзакцией не должны освобождаться до commit
● Насколько это строгое требование? Предположим
обратное:
E = r1[x] r2[y] w2[x] w1[y]
- не существует сериального выполнения t1 и t2 (их всего
два — t1 t2 или t2 t1) с тем же эффектом
Формализация: serial history
11. ● Таким образом, без 2PL история выполнения может
оказаться несериализуемой
● Достаточно ли 2PL? Да:
Two-Phase Locking Theorem: If all transactions in an
execution are two-phase locked, then the execution is
serializable.
2PL
12. ● Много пользователей = много потоков, требуется
latching, т.е. разграничение доступа к ресурсам
● Внешнее хранение = два представления данных, в
памяти и на диске
Другие проблемы
13. Другие проблемы (2)
page header
modification log
page trailer
page directory
compressed
data
BLOB pointers
empty space
page header
page trailer
row offset array
row rowrow
Row
row
row
row rowrow
trx id
field 1
roll pointer
field pointers
field 2 field n
15. Решение
● храним 100% данных в RAM
● транзакции выполняются строго последовательно в
одном потоке
● получаем настоящий serial execution
● полное отсутствие блокировок
● Шардировать всё равно придётся, поэтому бьём на
шарды сразу, с первой машины.
16. ● t1 записала X и завершилась
● выполняется успешно t2, которая читает X
● запись t1 в журнал привела к ошибке
→ нужно уметь делать откат при ошибке записи в
журнал
Работа с журналом
20. Concurrency – сойство систем, глобальное состояние
которых изменяется чередующимся выполнением
независимых или частично-независимых функций или
компонент
Parallelism – система конкурентна, но один или
несколько блоков могут выполняться параллельно
Concurrency vs. parallelism
21. With shared state:
- locking ← not composable
- wait-free algorithms – parallelism
- hardware transactional memory
Without shared state:
- functional programming
- actor model
Подходы к concurrency
22. + портабельны, просты в использовании
+ низкие издержки
- не интегрируются в poll() event loop
- могут стать hot spot
Locking
23. + ещё более низкие издержки
- сложно реализовать и тестировать
- не интегрируются в event loop
- могут стать hot spot
Wait-free algorithms
24. ● Дедлоки
● Конвоирование, хотспоты
● Лайвлоки
● Голодание
● Не универсальны – гранулярность статична, возможна
инверсия приоритетов
Locks are not composable!
26. ● нет глобального состояния
● main = f(x)
● порядок выполнения не задаётся явно, зависит от
данных
● функциональные зависимости просты для
распараллеливания
→ composable
- нет языков достаточно эффективных для системного
программирования
Functional programming
27. ● Actors
– Посылают сообщения
– Получают и обрабатывают сообщения
– Создают actors
● нет глобального состояния
● unbounded non-determinism :(
composable!
Actor model
33. ● не нужна синхронизация
● нужна поддержка квот
● нужна поддержка консистентных снимков памяти
→ специализированные аллокаторы памяти
Аллокация в одном потоке
34. Аллокаторы Tarantool
● http://github.com/tarantool/small
● quota, slab_arena – аллоцирует данные выровненными 4МБ
блоков, поддерживает квоты, multi-threaded
● slab_cache – buddy system для выровненных блоков от 4КБ
до 4МБ
● mempool - позволяет аллоцировать и освободждать
участки одинакового размера
● region_alloc – позволяет аллоцировать память, но не
позволяет её освобождать :)
● small – колллекция pool allocators для разных типоразмеров
● matras – аллокатор для выровненных блоков, работающий в
32 битном адресном пространстве
35. slab_arena – quotas and VSS
● глобальна, thread-safe
● MAP_SHARED или MAP_PRIVATE
● поддержка квот, несколько арен в одной квоте
● size-aligned, preallocated
prealloc
slab 4M
39. ibuf, obuf, region
● Аллокаторые это контейнеры, а контейнеры это
аллокаторы, различие только в наличии итерации по
объектам
● Аллокаторы это буфера, а буфера это аллокаторы,
различие лишь в возможности создания точки отката и
восстанвлении на точку в прошлом
44. Хэш-таблица Light
Bucket: 16 bytes: 8 – value, 4 – hash, 4 – next bucket ID in chain
Table: Buckets with ID: [0..M)
Hash → Bucket ID: B(Hash) =
Cover: C = M rounded up to the closest power of two; c = C / 2
Hash % C < M → Hash % C
Hash % C ≥ M → Hash % C
True bucket with ID holds a value with hash: B(hash) == ID
Chain bucket with ID holds a value with hash: B(hash) != ID, but the
another true bucket with ID = B(hash) starts a chain that contains this chain bucket
0x40 0x42 0x16 5 0xAB 0x44
value
hash next
0 1 2 3 4
0x32 1
5
M = 6
C = 8, c = 4
0x40 % 8 = 0 0x16 % 8 = 6
0x16 % 4 = 2
0xAB % 8 = 3 0x44 % 8 = 4 0x32 % 8 = 2
0x40 0x32 2 0xAB 0x44
0 1 2 3 4 5
M = 7
C = 8, c = 4
0x40 % 8 = 0 0xAB % 8 = 3 0x44 % 8 = 4
0x42 % 8 = 2
6
0x16 5
0x16 % 8 = 6
0x42
0x32 % 8 = 20x42 % 8 = 2
46. ● b-tree: compact and cache-oblivious
● b+-tree: cheap iteration
● b*-tree: more compact and more symmetric
● pointer compaction via matras
● MVCC via matras
bps_tree
47. Inner nodes
Leaf nodes
● K-ary (k-way) tree
● well balanced
● same size for leafs and
inner nodes (512 B)
● non-root nodes are filled
[2M/3..M]
● root may be filled [1..M]
bps_tree
48. Leaf node
Header Tuple[0] Tuple[1] Tuple[2] ...
Up to 62 pointers to tuples, sorted by key definition
Inner node
Header MaxTuple[0] MaxTuple[1] ... Id[0] Id[1] Id[2] ...
Matras IDs of subtrees
MaxTuple[i - 1] < {All tuples in subtree i} ≤ MaxTuple[i + 1]
Up to 42 subtrees with their maximal tuples (except last subtree)
Subtrees are sorted by their maximal tuples
Maximal tuple of maximal subtree is stored in upper node
Maximal tuple of maximal subtree in root is stored in special place of tree
Maximal tuple pointer in leaf node is copied exactly once somewhere in
upper nodes of the tree, except of last tuple, that stored in special place
bps_tree
49. Search / find insertion / deletion point
Binary search (lower bound) in node
42 4 6318 80
i = 2
Root, inner node
20 5245 60
i = 1
Searching
Inner node
23 3530 40 Leaf node42 43 45
!
About log(N) comparisons (N – number of tuples in tree)
About log(N)/log(M) block scans (M – average number of tuples in node)
bps_tree
50. 1) Find insertion point (path)
2) If leaf has space – insert into leaf; done (most common case)
3) If 2 closest siblings has space – rearrange and insert; done
4) Split the (full) node and 2 closest (full) siblings into 4 nodes and insert
5) Insert id of new node into parent – inner node; done
In every case update MaxTuple in parents if it's changed
7040 5010 7040 5010 42
5040 4535 55 65 706020 3010
5042 4540 7060 65553520 3010
5040 4535 55 7565 7060 802515 2010 30
4235 4030 6050 55452515 2010
Root has no siblings; if full it splits into 2 nodes and new root is created
8070 7565
bps_tree: вставка
51. 1) Find deletion point (path)
2) Delete tuple from node
3) If not less than 2*M/3 tuples left – done
70 4050 10 7040 5010 42
4) If 2 closest siblings have more than 2*M/3 tuples left – rearrange;
done 42 4540 7565 7060 802515 2010 30
6040 4530 8070 75652520 3010
4) Merge the node and 2 closest siblings into 2 nodes
5) Delete id of deleted node from parent – inner node; done
In every case update MaxTuple in parents if it's changed
42 4540 65 706020 3010
7060 65454015 2010
Root is handled specially
bps_tree: удаление
52. ● worst case about 12 bytes per tuple (4 bytes overhead)
● average case about 10 bytes per tuple (2 bytes overhead)
● worst case about 1.1 log(N) comparisons per search
(AVL-tree about 1.45 log(N), RB-tree about 2 log(N)
● great cache hit ratio
● MVCC over matras
bps_tree: итоги