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 для свободного использования, участие в разработке также приветствуется.
Docker в работе: взгляд на использование в Badoo через годBadoo Development
Мы в Badoo используем Docker больше года и на нашем примере попробуем поговорить о возможных моделях его применения.
- 85% наших сервисов работают в контейнерах: для чего и почему мы перенесли свои сервисы в контейнеры.
- Как мы подходим к сборке образов? Базовый образ: используем слои, следим за системными обновлениями.
- Автоматизация процесса сборки образов с нашими сервисами: Jira flow, Teamcity и другие страшные для админа слова.
- Лучшее ли место для тестирования production? Путь образа от сборки до Production.
- baDocker: webUI своими руками: зачем и почему?
- Как дать возможность управлять запущенными сервисами и их версиями разработчику.
- Docker: мониторинг и анализ работающих контейнеров.
Доклад Антона Турецкого на Highload 2015.
https://youtu.be/UgUuF_qZmWc
Flashcache в mamba.ru / Яковлев Александр Юрьевич (ЗАО Мамба)Ontico
Некоторое время назад, когда в очередной раз встал вопрос о производительности большого парка mysql sharding серверов, мы не захотели покупать новые сервера и производить resharding. Мы обнаружили, что компания facebook выпустила в opensource большое количество своих разработок, в том числе и модуль ядра flashcache.
Flashcache — модуль для кэширования блоков блочного устройства, предоставляющий 4 разных режима кэширования.
В данном докладе я расскажу, как мы тестировали, поэтапно проверяя под нагрузкой, 3 из 4 режимов кэширования, сравнивая и выбирая оптимальный. Итогом данной работы стало внедрение данного модуля в нашу архитектуру (фотосервера, сервера БД).
За счет чего Tarantool такой оптимальный / Денис Аникин (Mail.Ru)Ontico
Многие из вас, наверное, видели результаты тестов сравнения Tarantool с остальными СУБД, которые показывают, что Tarantool быстрее всех, оптимальней по памяти, обрабатывает наибольшее количество транзакций в секунду.
И, несмотря на то, что исходные коды всех тестов полностью открыты и хорошо откомментированы, позволяя всем желающим повторить тесты, все равно остаются вопросы - за счет чего Tarantool такой быстрый и оптимальный?
Я решил суммировать мои ответы на эти вопросы в докладе на Highload++.
Итак, почему Tarantool такой быстрый?
Краткий ответ: потому что он с самого начала разрабатывался и до сих пор разрабатывается во главе угла с производительностью/оптимальностью/минимальным потреблением всех ресурсов системы.
Более полный ответ я раскрою в своем выступлении. Приходите, будет интересно! :)
Docker в работе: взгляд на его использование в Badoo через год / Турецкий Ант...Ontico
Мы в Badoo используем Docker больше года и на нашем примере попробуем поговорить о возможных моделях его применения.
+ 85% наших сервисов работают в контейнерах: для чего и почему мы перенесли свои сервисы в контейнеры.
+ Как мы подходим к сборке образов? Базовый образ: используем слои, следим за системными обновлениями.
+ Автоматизация процесса сборки образов с нашими сервисами: Jira flow, Teamcity и другие страшные для админа слова.
+ Лучшее ли место для тестирования production? Путь образа от сборки до Production.
+ baDocker: webUI своими руками: зачем и почему?
+ Как дать возможность управлять запущенными сервисами и их версиями разработчику.
+ Docker: мониторинг и анализ работающих контейнеров.
Docker в работе: взгляд на использование в Badoo через годBadoo Development
Мы в Badoo используем Docker больше года и на нашем примере попробуем поговорить о возможных моделях его применения.
- 85% наших сервисов работают в контейнерах: для чего и почему мы перенесли свои сервисы в контейнеры.
- Как мы подходим к сборке образов? Базовый образ: используем слои, следим за системными обновлениями.
- Автоматизация процесса сборки образов с нашими сервисами: Jira flow, Teamcity и другие страшные для админа слова.
- Лучшее ли место для тестирования production? Путь образа от сборки до Production.
- baDocker: webUI своими руками: зачем и почему?
- Как дать возможность управлять запущенными сервисами и их версиями разработчику.
- Docker: мониторинг и анализ работающих контейнеров.
Доклад Антона Турецкого на Highload 2015.
https://youtu.be/UgUuF_qZmWc
Flashcache в mamba.ru / Яковлев Александр Юрьевич (ЗАО Мамба)Ontico
Некоторое время назад, когда в очередной раз встал вопрос о производительности большого парка mysql sharding серверов, мы не захотели покупать новые сервера и производить resharding. Мы обнаружили, что компания facebook выпустила в opensource большое количество своих разработок, в том числе и модуль ядра flashcache.
Flashcache — модуль для кэширования блоков блочного устройства, предоставляющий 4 разных режима кэширования.
В данном докладе я расскажу, как мы тестировали, поэтапно проверяя под нагрузкой, 3 из 4 режимов кэширования, сравнивая и выбирая оптимальный. Итогом данной работы стало внедрение данного модуля в нашу архитектуру (фотосервера, сервера БД).
За счет чего Tarantool такой оптимальный / Денис Аникин (Mail.Ru)Ontico
Многие из вас, наверное, видели результаты тестов сравнения Tarantool с остальными СУБД, которые показывают, что Tarantool быстрее всех, оптимальней по памяти, обрабатывает наибольшее количество транзакций в секунду.
И, несмотря на то, что исходные коды всех тестов полностью открыты и хорошо откомментированы, позволяя всем желающим повторить тесты, все равно остаются вопросы - за счет чего Tarantool такой быстрый и оптимальный?
Я решил суммировать мои ответы на эти вопросы в докладе на Highload++.
Итак, почему Tarantool такой быстрый?
Краткий ответ: потому что он с самого начала разрабатывался и до сих пор разрабатывается во главе угла с производительностью/оптимальностью/минимальным потреблением всех ресурсов системы.
Более полный ответ я раскрою в своем выступлении. Приходите, будет интересно! :)
Docker в работе: взгляд на его использование в Badoo через год / Турецкий Ант...Ontico
Мы в Badoo используем Docker больше года и на нашем примере попробуем поговорить о возможных моделях его применения.
+ 85% наших сервисов работают в контейнерах: для чего и почему мы перенесли свои сервисы в контейнеры.
+ Как мы подходим к сборке образов? Базовый образ: используем слои, следим за системными обновлениями.
+ Автоматизация процесса сборки образов с нашими сервисами: Jira flow, Teamcity и другие страшные для админа слова.
+ Лучшее ли место для тестирования production? Путь образа от сборки до Production.
+ baDocker: webUI своими руками: зачем и почему?
+ Как дать возможность управлять запущенными сервисами и их версиями разработчику.
+ Docker: мониторинг и анализ работающих контейнеров.
MyRocks: табличный движок для MySQL на основе RocksDBSergey Petrunya
MyRocks: табличный движок для MySQL на основе RocksDB.
Презентация с HighLoad++ 2015.
Рассказывается о принципах работы LSM-Trees, их реализации в RocksDB, зачем и как был сделан MyRocks, с какими проблемами столкнулись и как их решили.
Где живут Ваши объявления / Тюрин Михаил (Avito)Ontico
Авито с 2010 года — с момента запуска на широкую аудиторию — прошел уже немалый путь, успев собрать более 600 миллионов объявлений со всех уголков страны, и став при этом крупнейшим классифайдом в Европе.
В докладе будет дан обзор архитектуры ядра системы с ретроспективой, перечислены основные компоненты обработки объявлений, приведены оценки параметров функционирования от "продуктовых" "количество объявлений за единицу времени" до количества запросов на разные уровни стека (веб, базы, поиск, очереди) и степени утилизации железа.
Будут также продемонстрированы примеры реализаций классических паттернов веба: кэш, прокси, денормализация и репликация, шардинг, очереди и удаленный вызов процедур — подходы, уже более 5 лет лежащие в основе нашей архитектуры. При этом будут приведены неочевидные, на взгляд автора, особенности внедрения данных подходов.
Доклад должен заинтересовать соотнесением масштабов и ключевых слов.
Кэширование данных в web приложениях. Использование memcached / Юрий Красноще...Ontico
Каждый разработчик web приложений рано или поздно сталкивается с довольно типичной проблемой: перед ним стоит задача построить фабрику по производству омнониевых торсиометров.
Фабрика производит омнониевые торсиометры очень быстро, но для калибровки прибора (как известно) необходим омноний, за которым приходится летать на Андромеду.
Пока корабль летит до Андромеды, фабрика простаивает.
Самый очевидный выход из ситуации - построить склад омнониума прямо рядом с фабрикой.
Терминология кэширования
Выбор места для кэширования в WEB
Выбор данных для кэширования
Кэширование на стороне бэкенда
Отдельный кэширующий сервис
Пара слов о memcached
Пара слов о Redis
Загрузка больших объемов данных для бизнес-аналитикиBadoo Development
В Badoo мы разрабатываем собственную систему Business intelligence (сокращённо BI). И прежде, чем приступать к анализу данных, их необходимо извлечь (Extract) из источников, преобразовать (Transform) и загрузить (Load) в аналитическую базу.
Я расскажу об этом процессе - ETL (Extract, Transform, Load). Какие бывают источники данных, какие методы сбора мы используем. И самое главное - об инструменте под названием ETLMaster, созданным в нашей компании для автоматизации управления процессом трансформации и загрузки данных.
Как устроена 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, как настройки этих компонент могут повлиять на приложение.
Я расскажу про планировщик процессов, дисковый и сетевой ввод-вывод и соответствующие планировщики, управление памятью - как это все в общих чертах работает и как его потюнить.
Эволюция программно-аппаратного обеспечения хранения фотографий в Badoo / Дми...Ontico
На примере нашей системы хранения фотографий мы хотим рассказать о проблемах, с которыми столкнулись в течение прошедших семи лет, связанных с ее программными и аппаратными компонентами, и о путях их решений.
В данном докладе речь пойдет о том, как сохранить независимость от поставщика и построить масштабируемую систему хранения с длительным сроком эксплуатации и способностью к оперативному внесению изменений в конфигурацию. Как сделать изменения на аппаратном уровне прозрачными для разработчиков, а также о том, как упростить развертывание и обслуживание.
В общих чертах изложен опыт и проблемы, которые мы получили в ходе эксплуатации классических мультиконтроллерных СХД. Основная тема - построение собственных хранилищ на базе общедоступных компонентов (полки, адаптеры, экспандеры, интерпозеры, диски, ЦПУ и т.д.) с потенциальной возможностью замены любого из выше перечисленного на другую модель. Дублирование критически важных узлов в рамках одной СХД. Обзор используемых транспортов - SRP, FC, iSCSI и описание того, каким образом можно быстро адаптировать такое хранилище под один или несколько транспортов, с минимальными вложениями. Обзор ПО для реализации СХД (SCST/LIO или проприетарные решения в области Software Defined Storage ). Автоматизация развертывания (инсталляция/управление с помощью Puppet). Тестирование перед вводом в эксплуатацию. Multipath I/O и упрощение именования экспортируемых блочных устройств. Политика составления наборов firmware для стабильной работы. Мониторинг. Расследование сбоев (Order of failure и т.п.).
В нашей большой компании мы столкнулись с задачей выкладывания релизов наших проектов на несколько групп серверов по нескольким сотням машин.
Мы решили разработать свой софт для удобного деплоя, поскольку задача, на мой взгляд, достаточно сложная, потому что каждая секунда при выкатке решает очень многое.
Почему именно разработать что-то свое, а не использовать что-то готовое, например, Fabric или Capistrano?
Все просто:
1. Система должна быть написана на языке, на котором принято разрабатывать в компании.
2. Все возникающие трудности и проблемы должны быть решены в кратчайшие сроки, нет времени ждать пока чья-то техподдержка прилетит на помощь на голубом вертолете :)
3. Система должна быть безопасна, полностью с открытыми кодами для безопасников.
4. Минимизированы зависимости от внешних модулей.
Вкратце расскажу о том, как мы раскладываем front-end для наших проектов в Mail.ru Group в продакшн и на тестовые сервера.
В частности, расскажу, как мы собираем версточный релиз.
Расскажу о том, как его запаковать и как аккуратно раздать на несколько сотен серверов.
Расскажу об архитектуре мониторинга системы обновлений, а также покажу, как выглядит наш дашборд, по которому мы понимаем, что все хорошо.
Отвечу на все интересующие вас вопросы и дам несколько рекомендаций, которые помогут вам обойти подводные грабли, на которые наступали мы.
Tempesta FW: challenges, internals, use cases / Александр Крижановский (Tempe...Ontico
Tempesta FW — это Open Source гибрид Web-акселератора и файервола, специально разработанный для высокопроизводительной доставки контента вне зависимости от DDoS или наплыва посетителей.
В докладе будет рассказано про задачи, которые ставились при разработке проекта и пути их решения. Рассмотрим проблемы современных операционных систем в приложении к Web-стеку (система фильтрации, Web-сервер, application слой, БД), и как они решаются в Tempesta — некоторые уже решены, некоторые еще в процессе работы.
И самое главное — у нас появился рабочий прототип, и я расскажу про типовые примеры инсталляции, фичи и конфигурацию, а также покажу бенчмарки.
В докладе мы поделимся опытом создания content-based рекомендательной системы для электронной коммерции, работающей на семантическом ядре рунета (десятки миллионов профилей). Расскажем, как организовали централизованный сбор и обработку информации о посещении пользователями более 100 000 сайтов различной направленности на основе Amazon Kinesis. Поделимся опытом многопоточной онлайн-индексации потоков данных в Lucene. Продемонстрируем используемые базовые алгоритмы ранжирования и формирования персональных рекомендаций для посетителей более 20 000 интернет-магазинов.
Поговорим о плюсах и минусах лямбда-архитектур и обоснуем выбранное нами архитектурное решение. Отдельно остановимся на тонкостях технической реализации многопоточных алгоритмов и особенностях обеспечения реального времени - поступившая информация о действиях посетителя практически мгновенно учитывается рекомендательным движком, обеспечивая максимальную конверсию.
Внутреннее устройство PostgreSQL: временные таблицы и фрагментация памяти / Г...Ontico
Всем известно о существовании временных таблиц в PostgreSQL, но как они устроены, и чем грозит их некорректное использование - не столь очевидно.
На примере одного известного приложения, активно и некорректно использующего временные таблицы, мы расскажем о создаваемой ими проблеме фрагментации памяти.
Что такое фрагментация памяти, по каким признакам можно определить ее наличие, чем она грозит, почему она возникает при активном использовании временных таблиц, и как мы пропатчили PostgreSQL, чтобы ее избежать - обо всем этом можно узнать из нашего доклада.
В этом докладе я в подробностях расскажу о том, как устроено хранение фотографий в нашей компании (всего около ~1 Пб).
Наша система была устроена достаточно просто — сами фотографии хранятся на SAN Storages, которые подключены через Fiber Channel к отдельной группе серверов, "*photos". На photos-серверах смонтированы разделы на соответствующих сетевых блочных устройствах, которые с точки зрения пользователя выглядят, как обычная файловая система.
Мы не используем никакие «хитрые» системы для хранения фотографий и не храним всё в одном файле — каждый размер каждой фотографии представляет из себя обычный файл на файловой системе ext3/4. Фотографии отдаются через nginx напрямую из файловой системы.
Такой способ хранения больших объемов данных весьма дешев, но приводил к проблемам, когда соответствующие SAN «падали», вплоть до повреждения файловой системы с потерей части данных пользователей.
Поэтому, для решения этой проблемы, а также проблем с производительностью, мы решили сделать «софтверную репликацию» фотографий с кешированием данных на SSD.
Также, в качестве эксперимента, мы решили попробовать ещё один способ — хранение на локальных дисках вместо использования SAN. По стоимости решение значительно дороже, но зато надежнее и проще в поддержке. Также, для обеспечения устойчивости к выходу из строя любой машины из такого кластера, мы решили сделать возможной балансировку всех поступающих запросов на весь кластер, то есть, в современных терминах, сделать «распределенное, отказоустойчивое, высокодоступное облачное хранилище».
Путь от монолита на PHP к микросервисам на Scala / Денис Иванов (2GIS)Ontico
В своём проекте мы решали следующие задачи:
+ Скорость разработки задачи;
+ Стоимость поддержки задачи;
+ Возможность распараллеливать вычисления и задачи;
+ Возможность максимально просто масштабировать приложение;
+ CI/CD с минимальными усилиями.
Я расскажу о том, как мы решали эти задачи, на какие грабли мы наступали, что из этого всего получилось, и что делать дальше.
Что получили в итоге:
+ Мощь JVM под капотом Scala;
+ 15 минут от нажатия на кнопку "Merge request" до продакшена в 3 датацентра и 6 серверов с прохождением тестов (юнит + функциональные + интеграционные + нагрузочные);
+ 6 нод с приложениями вместо 18 (по 2 в каждом датацентре для отказоустойчивости) с запасом прочности в 60%;
+ Независимые пофичные релизы без даунтайма всех компонентов приложения;
+ Масштабирование только того функционала и в том количестве, которое необходимо данному сервису.
Android Cloud... точнее Cloud из Android / Охрименко Алексей (Acronis)Ontico
Вы когда-нибудь плакали, открывая Amazon EC2 калькулятор? Мучились ли вы над тем, куда поставить сервер — на балкон или в кладовку? Готовились ли вы морально платить по 100-200 тысяч рублей за самый примитивный вариант сервера? Из этой ситуации есть выход и это — Android-планшеты :)
Как установить Linux на ваш Android-планшет, как развернуть LAMP, MEAN stack, сколько RPS могут выдать Android-планшеты, как хорошо они масштабируются, map/reduce, готовы ли Android-планшеты для production?
Все это и многое другое вы узнаете из этого доклада.
ToroDB: scaling PostgreSQL like MongoDB / Álvaro Hernández Tortosa (8Kdata)Ontico
NoSQL databases have emerged as a response to some perceived problems in the RDBMSs: agile/dynamic schemas; and transparent, horizontal scaling of the database. The former has been promptly targeted with the introduction of unstructured data types, but scaling a relational databases is still a very hard problem.
As a consequence, all NoSQL databases have been built from scratch: their storage engines, replication techniques, journaling, ACID support (if any). They haven't leveraged the previously existing state-of-the-art of RDBMSs, effectively re-inventing the wheel. Isn't this sub-optimal? Wouldn't it be possible to construct a NoSQL database by layering it on top of a relational database?
Enter ToroDB. ToroDB is an open source project that behaves as a NoSQL database but runs on top of PostgreSQL, one of the most respected and reliable relational databases. ToroDB offers a document (JSON-like) interface, and implements the MongoDB wire protocol, hence being compatible with existing MongoDB drivers and applications. Rather than using PostgreSQL's jsonb data type, ToroDB explored an innovative approach by transforming JSON documents to a fully relational representation, in an automated way. This brings to the table many advantages like lower disk footprint and automatic data-partitioning, leading to significantly faster queries.As ToroDB speaks the MongoDB protocol, it also implements MongoDB replication and sharding techniques, enabling it to scale and offer HA like Mongo. Being based on PostgreSQL, ToroDB is effectively scaling PostgreSQL much in the same way MongoDB scales.
MyRocks: табличный движок для MySQL на основе RocksDBSergey Petrunya
MyRocks: табличный движок для MySQL на основе RocksDB.
Презентация с HighLoad++ 2015.
Рассказывается о принципах работы LSM-Trees, их реализации в RocksDB, зачем и как был сделан MyRocks, с какими проблемами столкнулись и как их решили.
Где живут Ваши объявления / Тюрин Михаил (Avito)Ontico
Авито с 2010 года — с момента запуска на широкую аудиторию — прошел уже немалый путь, успев собрать более 600 миллионов объявлений со всех уголков страны, и став при этом крупнейшим классифайдом в Европе.
В докладе будет дан обзор архитектуры ядра системы с ретроспективой, перечислены основные компоненты обработки объявлений, приведены оценки параметров функционирования от "продуктовых" "количество объявлений за единицу времени" до количества запросов на разные уровни стека (веб, базы, поиск, очереди) и степени утилизации железа.
Будут также продемонстрированы примеры реализаций классических паттернов веба: кэш, прокси, денормализация и репликация, шардинг, очереди и удаленный вызов процедур — подходы, уже более 5 лет лежащие в основе нашей архитектуры. При этом будут приведены неочевидные, на взгляд автора, особенности внедрения данных подходов.
Доклад должен заинтересовать соотнесением масштабов и ключевых слов.
Кэширование данных в web приложениях. Использование memcached / Юрий Красноще...Ontico
Каждый разработчик web приложений рано или поздно сталкивается с довольно типичной проблемой: перед ним стоит задача построить фабрику по производству омнониевых торсиометров.
Фабрика производит омнониевые торсиометры очень быстро, но для калибровки прибора (как известно) необходим омноний, за которым приходится летать на Андромеду.
Пока корабль летит до Андромеды, фабрика простаивает.
Самый очевидный выход из ситуации - построить склад омнониума прямо рядом с фабрикой.
Терминология кэширования
Выбор места для кэширования в WEB
Выбор данных для кэширования
Кэширование на стороне бэкенда
Отдельный кэширующий сервис
Пара слов о memcached
Пара слов о Redis
Загрузка больших объемов данных для бизнес-аналитикиBadoo Development
В Badoo мы разрабатываем собственную систему Business intelligence (сокращённо BI). И прежде, чем приступать к анализу данных, их необходимо извлечь (Extract) из источников, преобразовать (Transform) и загрузить (Load) в аналитическую базу.
Я расскажу об этом процессе - ETL (Extract, Transform, Load). Какие бывают источники данных, какие методы сбора мы используем. И самое главное - об инструменте под названием ETLMaster, созданным в нашей компании для автоматизации управления процессом трансформации и загрузки данных.
Как устроена 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, как настройки этих компонент могут повлиять на приложение.
Я расскажу про планировщик процессов, дисковый и сетевой ввод-вывод и соответствующие планировщики, управление памятью - как это все в общих чертах работает и как его потюнить.
Эволюция программно-аппаратного обеспечения хранения фотографий в Badoo / Дми...Ontico
На примере нашей системы хранения фотографий мы хотим рассказать о проблемах, с которыми столкнулись в течение прошедших семи лет, связанных с ее программными и аппаратными компонентами, и о путях их решений.
В данном докладе речь пойдет о том, как сохранить независимость от поставщика и построить масштабируемую систему хранения с длительным сроком эксплуатации и способностью к оперативному внесению изменений в конфигурацию. Как сделать изменения на аппаратном уровне прозрачными для разработчиков, а также о том, как упростить развертывание и обслуживание.
В общих чертах изложен опыт и проблемы, которые мы получили в ходе эксплуатации классических мультиконтроллерных СХД. Основная тема - построение собственных хранилищ на базе общедоступных компонентов (полки, адаптеры, экспандеры, интерпозеры, диски, ЦПУ и т.д.) с потенциальной возможностью замены любого из выше перечисленного на другую модель. Дублирование критически важных узлов в рамках одной СХД. Обзор используемых транспортов - SRP, FC, iSCSI и описание того, каким образом можно быстро адаптировать такое хранилище под один или несколько транспортов, с минимальными вложениями. Обзор ПО для реализации СХД (SCST/LIO или проприетарные решения в области Software Defined Storage ). Автоматизация развертывания (инсталляция/управление с помощью Puppet). Тестирование перед вводом в эксплуатацию. Multipath I/O и упрощение именования экспортируемых блочных устройств. Политика составления наборов firmware для стабильной работы. Мониторинг. Расследование сбоев (Order of failure и т.п.).
В нашей большой компании мы столкнулись с задачей выкладывания релизов наших проектов на несколько групп серверов по нескольким сотням машин.
Мы решили разработать свой софт для удобного деплоя, поскольку задача, на мой взгляд, достаточно сложная, потому что каждая секунда при выкатке решает очень многое.
Почему именно разработать что-то свое, а не использовать что-то готовое, например, Fabric или Capistrano?
Все просто:
1. Система должна быть написана на языке, на котором принято разрабатывать в компании.
2. Все возникающие трудности и проблемы должны быть решены в кратчайшие сроки, нет времени ждать пока чья-то техподдержка прилетит на помощь на голубом вертолете :)
3. Система должна быть безопасна, полностью с открытыми кодами для безопасников.
4. Минимизированы зависимости от внешних модулей.
Вкратце расскажу о том, как мы раскладываем front-end для наших проектов в Mail.ru Group в продакшн и на тестовые сервера.
В частности, расскажу, как мы собираем версточный релиз.
Расскажу о том, как его запаковать и как аккуратно раздать на несколько сотен серверов.
Расскажу об архитектуре мониторинга системы обновлений, а также покажу, как выглядит наш дашборд, по которому мы понимаем, что все хорошо.
Отвечу на все интересующие вас вопросы и дам несколько рекомендаций, которые помогут вам обойти подводные грабли, на которые наступали мы.
Tempesta FW: challenges, internals, use cases / Александр Крижановский (Tempe...Ontico
Tempesta FW — это Open Source гибрид Web-акселератора и файервола, специально разработанный для высокопроизводительной доставки контента вне зависимости от DDoS или наплыва посетителей.
В докладе будет рассказано про задачи, которые ставились при разработке проекта и пути их решения. Рассмотрим проблемы современных операционных систем в приложении к Web-стеку (система фильтрации, Web-сервер, application слой, БД), и как они решаются в Tempesta — некоторые уже решены, некоторые еще в процессе работы.
И самое главное — у нас появился рабочий прототип, и я расскажу про типовые примеры инсталляции, фичи и конфигурацию, а также покажу бенчмарки.
В докладе мы поделимся опытом создания content-based рекомендательной системы для электронной коммерции, работающей на семантическом ядре рунета (десятки миллионов профилей). Расскажем, как организовали централизованный сбор и обработку информации о посещении пользователями более 100 000 сайтов различной направленности на основе Amazon Kinesis. Поделимся опытом многопоточной онлайн-индексации потоков данных в Lucene. Продемонстрируем используемые базовые алгоритмы ранжирования и формирования персональных рекомендаций для посетителей более 20 000 интернет-магазинов.
Поговорим о плюсах и минусах лямбда-архитектур и обоснуем выбранное нами архитектурное решение. Отдельно остановимся на тонкостях технической реализации многопоточных алгоритмов и особенностях обеспечения реального времени - поступившая информация о действиях посетителя практически мгновенно учитывается рекомендательным движком, обеспечивая максимальную конверсию.
Внутреннее устройство PostgreSQL: временные таблицы и фрагментация памяти / Г...Ontico
Всем известно о существовании временных таблиц в PostgreSQL, но как они устроены, и чем грозит их некорректное использование - не столь очевидно.
На примере одного известного приложения, активно и некорректно использующего временные таблицы, мы расскажем о создаваемой ими проблеме фрагментации памяти.
Что такое фрагментация памяти, по каким признакам можно определить ее наличие, чем она грозит, почему она возникает при активном использовании временных таблиц, и как мы пропатчили PostgreSQL, чтобы ее избежать - обо всем этом можно узнать из нашего доклада.
В этом докладе я в подробностях расскажу о том, как устроено хранение фотографий в нашей компании (всего около ~1 Пб).
Наша система была устроена достаточно просто — сами фотографии хранятся на SAN Storages, которые подключены через Fiber Channel к отдельной группе серверов, "*photos". На photos-серверах смонтированы разделы на соответствующих сетевых блочных устройствах, которые с точки зрения пользователя выглядят, как обычная файловая система.
Мы не используем никакие «хитрые» системы для хранения фотографий и не храним всё в одном файле — каждый размер каждой фотографии представляет из себя обычный файл на файловой системе ext3/4. Фотографии отдаются через nginx напрямую из файловой системы.
Такой способ хранения больших объемов данных весьма дешев, но приводил к проблемам, когда соответствующие SAN «падали», вплоть до повреждения файловой системы с потерей части данных пользователей.
Поэтому, для решения этой проблемы, а также проблем с производительностью, мы решили сделать «софтверную репликацию» фотографий с кешированием данных на SSD.
Также, в качестве эксперимента, мы решили попробовать ещё один способ — хранение на локальных дисках вместо использования SAN. По стоимости решение значительно дороже, но зато надежнее и проще в поддержке. Также, для обеспечения устойчивости к выходу из строя любой машины из такого кластера, мы решили сделать возможной балансировку всех поступающих запросов на весь кластер, то есть, в современных терминах, сделать «распределенное, отказоустойчивое, высокодоступное облачное хранилище».
Путь от монолита на PHP к микросервисам на Scala / Денис Иванов (2GIS)Ontico
В своём проекте мы решали следующие задачи:
+ Скорость разработки задачи;
+ Стоимость поддержки задачи;
+ Возможность распараллеливать вычисления и задачи;
+ Возможность максимально просто масштабировать приложение;
+ CI/CD с минимальными усилиями.
Я расскажу о том, как мы решали эти задачи, на какие грабли мы наступали, что из этого всего получилось, и что делать дальше.
Что получили в итоге:
+ Мощь JVM под капотом Scala;
+ 15 минут от нажатия на кнопку "Merge request" до продакшена в 3 датацентра и 6 серверов с прохождением тестов (юнит + функциональные + интеграционные + нагрузочные);
+ 6 нод с приложениями вместо 18 (по 2 в каждом датацентре для отказоустойчивости) с запасом прочности в 60%;
+ Независимые пофичные релизы без даунтайма всех компонентов приложения;
+ Масштабирование только того функционала и в том количестве, которое необходимо данному сервису.
Android Cloud... точнее Cloud из Android / Охрименко Алексей (Acronis)Ontico
Вы когда-нибудь плакали, открывая Amazon EC2 калькулятор? Мучились ли вы над тем, куда поставить сервер — на балкон или в кладовку? Готовились ли вы морально платить по 100-200 тысяч рублей за самый примитивный вариант сервера? Из этой ситуации есть выход и это — Android-планшеты :)
Как установить Linux на ваш Android-планшет, как развернуть LAMP, MEAN stack, сколько RPS могут выдать Android-планшеты, как хорошо они масштабируются, map/reduce, готовы ли Android-планшеты для production?
Все это и многое другое вы узнаете из этого доклада.
ToroDB: scaling PostgreSQL like MongoDB / Álvaro Hernández Tortosa (8Kdata)Ontico
NoSQL databases have emerged as a response to some perceived problems in the RDBMSs: agile/dynamic schemas; and transparent, horizontal scaling of the database. The former has been promptly targeted with the introduction of unstructured data types, but scaling a relational databases is still a very hard problem.
As a consequence, all NoSQL databases have been built from scratch: their storage engines, replication techniques, journaling, ACID support (if any). They haven't leveraged the previously existing state-of-the-art of RDBMSs, effectively re-inventing the wheel. Isn't this sub-optimal? Wouldn't it be possible to construct a NoSQL database by layering it on top of a relational database?
Enter ToroDB. ToroDB is an open source project that behaves as a NoSQL database but runs on top of PostgreSQL, one of the most respected and reliable relational databases. ToroDB offers a document (JSON-like) interface, and implements the MongoDB wire protocol, hence being compatible with existing MongoDB drivers and applications. Rather than using PostgreSQL's jsonb data type, ToroDB explored an innovative approach by transforming JSON documents to a fully relational representation, in an automated way. This brings to the table many advantages like lower disk footprint and automatic data-partitioning, leading to significantly faster queries.As ToroDB speaks the MongoDB protocol, it also implements MongoDB replication and sharding techniques, enabling it to scale and offer HA like Mongo. Being based on PostgreSQL, ToroDB is effectively scaling PostgreSQL much in the same way MongoDB scales.
Chronicle Map — key-value хранилище для трейдинга на Java / Левентов Роман (C...Ontico
Сфера финансовых приложений и трейдинга выдвигает особые требования к системам обработки данных: ультракороткие задержки, конкурентные обновления (в т.ч. из разных процессов), репликация высокочастотных обновлений.
Существовавшие открытые key-value хранилища не справлялись, поэтому мы сделали свое — Chronicle Map.
В докладе я отвечу на вопросы:
+ Почему бывает эффективнее разбить систему, работающую с общим состоянием, на несколько отдельных процессов?
+ Зачем вам может захотеться распилить JVM на несколько частей?
+ Как добиться от key-value хранилища медианной latency меньше 1 микросекунды?
+ Как сделать репликацию, если она упирается в пропускную способность сети из-за слишком частых обновлений?
Развею миф о том, что Java — это медленно :)
Также, в докладе будет сравнение Chronicle Map с redis, one-nio и ConcurrentHashMap.
Understanding and tuning WiredTiger, the new high performance database engine...Ontico
MongoDB 3.0 introduced the concept of different storage engine. The new engine known as WiredTiger introduces document level MVCC locking, compression and a choice between Btree or LSM indexes. In this talk you will learn about the storage engine architecture and specifically WiredTiger, and how to tune and monitor it for best performance.
MongoDB 3.0 представил новый концепт движков хранения. Новый движок известен как WiredTiger и предоставляет новый уровень документов MVCC фикс, компрессию и выбор между Btree или индексами LSM. В этом докладе вы поймете, как тюнить и мониторить архитектуры движка базы данных, а точнее WiredTiger для получения максимальной производительности.
Ужимай и властвуй алгоритмы компрессии в базах данных / Петр Зайцев (Percona)Ontico
Чем меньше размер данных, тем дешевле их хранить и часто быстрее обрабатывать. Разработчики баз данных издавна задумывались над тем, как обеспечить максимальную степень сжатия данных.
В данном докладе мы рассмотрим, почему интерес к компрессии информации в базах данных особенно высок в последние годы. Мы также рассмотрим различные подходы к уменьшению размера хранимых данных, включая:
+ дедубликацию данных;
+ префикс-компрессию индексов;
+ компрессию на уровне файловой системы;
+ поколоночное хранение данных;
+ постраничную компрессию (на примере хранилища Innodb);
+ компрессию во фрактальных и LSM деревьях;
+ компрессию путем "прокалывания дырок" в файлах;
+ компрессию данных на уровне пользователя.
Как мы сделали ровную балансировку нагрузки на фронтенд-кластере / Насретдино...Ontico
В докладе я расскажу о том, как мы добились идеально ровной балансировки нагрузки по кластеру из 200+ серверов, реализовали автоматический подбор весов и получили разброс CPU usage в 2,5% в пике трафика. Это позволило сэкономить нам около 40-50 серверов и улучшить время отклика мобильного сайта в пике нагрузки. Реализацию приведенного алгоритма мы выложим в open-sourсe.
Тезисы - http://www.highload.ru/2015/abstracts/1950.html
Как выбрать In-memory NoSQL базу данных с умом. Тестируем производительность ...Ontico
В настоящее время, когда рынок полон различных In-memory NoSQL решений, вопрос выбора особенно актуален. Часто приходится видеть ситуацию, когда базу данных выбирают по принципу "самая распиаренная", "друг посоветовал" и пр. Такой подход имеет мало общего с инженерным мышлением. Может ли оказаться так, что решение, которое на первый взгляд лежит на поверхности, оказывается вовсе не лучшим для поставленной задачи?
Я расскажу о своих муках выбора, в процессе которых был изучен существующий инструментарий (а также написан недостающий), позволяющий оценить применимость той или иной базы данных к текущей задаче. Также в докладе я покажу, к каким результатам привели тесты (да, будет очень много графиков) таких In-memory NoSQL решений как Memcached, Redis, Tarantool, CouchBase и др.
Непременным приложением к докладу будут все исходные коды и образы виртуальных машин, так что при желании вы сможете повторить все у себя :)
Tarantool: как сэкономить миллион долларов на базе данных на высоконагруженно...Ontico
Когда стоит дилемма, какое DBMS решение выбрать, то приходится принимать во внимание много факторов — latency, bandwidth, ACID-complience, наличие/отсутствие server-side-scripting, возможности репликации, удобство развертывания и администрирования, наличие известных багов или maintenance window и т.д.
Я хочу рассказать лишь об одном из факторов, который имеет особенное значение на проектах с многомиллионными аудиториями — это Total Cost of Ownership или, по-простому, цена. Чем больше аудитория у проекта, тем больше эта аудитория создает нагрузку на базы данных, тем больше должно быть серверов с базами данных, тем больше финансовых затрат это требует.
Можно экстенсивно наращивать количество серверов, но до определенного предела, когда становится понятным, что далее дешевле будет внедрить новое, более производительное решение, которое позволит радикально снизить цену и количество железа.
Мой рассказ будет посвящен тому, как мы в Почте@Mail.Ru перешли на Tarantool, и как его использование сэкономило нам миллион долларов.
5 способов деплоя PHP-кода в условиях хайлоада / Юрий Насретдинов (Badoo)Ontico
В дата-центрах нашей компании несколько тысяч серверов, и примерно на половине из них нужно выкладывать PHP-код 2 раза в день. Помимо раскладки на production также не стоит забывать о том, что код нужен на стейджинге, и в стейджинг-кластер у нас входит около 50 машин, код на которых обновляется раз в несколько минут. Также есть «хотфиксы» — небольшие (1-5) наборы файлов, которые выкладываются во внеочередном порядке на все или на выделенную часть серверов, чтобы устранить существующие проблемы на продакшне, не дожидаясь полной выкладки.
В этом докладе я расскажу о том, как мы деплоились в течение 10 лет, о том, какую новую систему для деплоя PHP-кода мы разработали и внедрили в production, а также проведу обзор решений для масштабного деплоя кода на PHP и анализ их производительности.
План доклада:
— Наша старая система деплоя, достоинства и недостатки.
— Существующие решения:
* "svn up" / "git pull".
* rsync.
* phar, hhbc (HHVM-specific), "loop".
* rsync + 2 директории + realpath_root (Rasmus-style).
— Требования для новой системы деплоя.
* быстрый деплой на стейджинг (5-10 секунд на 50 серверов).
* возможность атомарно патчить несколько файлов и быстро их выкладывать (10 секунд на весь кластер).
* совместимость с docker.
* поддержка «долгоиграющих» CLI-скриптов (несколько часов).
* низкое потребление ресурсов на принимающей стороне.
* отсутствие необходимости сбрасывать opcache.
* высокая скорость деплоя на продакшн (1-2 минуты на 1500 серверов).
— MDK — multiversion deployment kit.
— Анализ применимости и производительности способов деплоя.
— Выводы.
Talk for SCaLE13x. Video: https://www.youtube.com/watch?v=_Ik8oiQvWgo . Profiling can show what your Linux kernel and appliacations are doing in detail, across all software stack layers. This talk shows how we are using Linux perf_events (aka "perf") and flame graphs at Netflix to understand CPU usage in detail, to optimize our cloud usage, solve performance issues, and identify regressions. This will be more than just an intro: profiling difficult targets, including Java and Node.js, will be covered, which includes ways to resolve JITed symbols and broken stacks. Included are the easy examples, the hard, and the cutting edge.
Lightning Memory-Mapped Database (LMDB) - представляет собой интересный, во многом уникальный, движок базы данных класса Berkeley DB / Level DB. Будучи относительно малоизвестным, LMDB показывает чемпионскую производительность по чтению и предлагает ряд компромиссов для достижения невероятной производительности по записи.
LMDB был создан для использования внутри известного проекта OpenLDAP с открытым исходным кодом. Как разработчик и поставщик решений для «больших телекомов», компания «Петер-Сервис» решила задействовать связку OpenLDAP+LMDB в одном из своих проектов. Это был вход в кротовую нору, всё было как в сказке – чем дальше, тем страшнее...
В результате мы сделали клон/fork исходного проекта и создали высокопроизводительное стабильное решение промышленного масштаба с открытым исходным кодом. Расскажу о внутреннем устройстве LMDB, о выявленных недостатках и наших доработках для их устранения.
Микросервисы: опыт использования в нагруженном проекте / Вадим Мадисон (М-Тех)Ontico
Мы прошли довольно большой путь в разработке через микросервисы.
Начинали разработку, когда это за рубежом только входило в тренд. По сути, не было никакой информации о том, как это делать правильно и, вообще, стоит ли это делать. Не было понятно, имеем ли мы дело с очередной модной штукой, или парадигма действительно решает часть проблем, характерных для больших нагруженных проектов.
Мы прошли путь от того, когда 100 микросервисов казалось много ... Сейчас цифры в 1000, 2000 кажутся чем-то обыденным.
В ходе доклада я постараюсь сделать упор на эксплуатацию системы, работающей на микросервисах. Расскажу, какой инструментарий показал себя хорошо на больших объемах, а от какого пришлось отказаться. Покажу на примерах, как эволюционировала наша система управления конфигурацией системы в целом и отдельными сервисами. Расскажу, как корректно предоставлять API сервиса и правильно поставлять его клиентские библиотеки, чтобы избегать внутренних и искусственных зависимостей. Покажу, как мы работаем с распределенными сервисами и обеспечиваем отказоустойчивость.
Обзор перспективных баз данных для highload / Юрий НасретдиновOntico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 5 июня, 10:00
Тезисы:
http://backendconf.ru/2017/abstracts/2773.html
В этом докладе я рассмотрю несколько перспективных, на мой взгляд, баз данных, которые пока еще не очень популярны, но которые определенно ждет успех в будущем, особенно для highload-проектов. Я расскажу о Tarantool, ClickHouse и CockroachDB, о том, как они устроены, и почему я считаю, что они в будущем станут стандартом де-факто, как раньше был MySQL, а сейчас — MongoDB.
...
Раздатчик музыки непосредственно занимается отдачей байтов аудиопотока многочисленным пользователям https://ok.ru/music. В пике суммарный трафик достигает 100 Гб/с через сотни тысяч соединений, а время до первого байта составляет не больше 100 мс. Предыдущая версия раздатчика на основе файлов и Apache Tomcat не устраивала нас требуемым количеством оборудования и неспособностью утилизировать современное железо. При разработке новой версии мы поставили перед собой цель сохранить внешнюю функциональность сервиса неизменной, но обойтись существенно меньшим количеством машин, сохранив при этом масштабируемость и отказоустойчивость сервиса.
В докладе мы рассмотрим, как различные архитектурные решения помогли нам обеспечить масштабируемость и отказоустойчивость сервиса за счёт распределения и репликации музыкальных треков между нодами. Затем подробно поговорим про устройство отдельной ноды, включая отказоустойчивую подсистему хранения, сетевую подсистему, а также использование подхода reactive streams. Уделим особое внимание собранным граблям и трюкам, позволившим увеличить производительность системы, упростить отладку и эксплуатацию системы.
Доклад ориентирован на разработчиков, которые хотят расширить свой арсенал подходов и инструментов для создания распределённых и/или высоконагруженных систем с интенсивным I/O.
Оптимизация high-contention write в PostgreSQL / Александр Коротков, Олег Бар...Ontico
HighLoad++ 2017
Зал «Рио-де-Жанейро», 7 ноября, 11:00
Тезисы:
http://www.highload.ru/2017/abstracts/3030.html
Оптимизация производительности – дело тонкое. Улучшая производительность системы при одной нагрузке, можно запросто ухудшить её при другой нагрузке. Основным мерилом производительности PostgreSQL в среде его разработчиков является pgbench. Как следствие, PostgreSQL стал "pgbench-optimized DBMS" (СУБД, оптимизированная для pgbench).
...
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-инженерами для решения задач мониторинга жизнедеятельности базы данных и ранней диагностики возможных проблем.
...
19. Чтение данных в LSM
MemTable Чтение
Log SST SST
. . .
• Чтение = слияние данных
• Read amplification ↑↑
SST
20. Compaction – слияние SST
SST SST . . .Цели
• Уменьшение числа
SST-файлов
скорость чтения ↑
• Удаление старых версий
записей размер ↓
SST
SST
Метод
• Слияние сортированных файлов
– Пишем последовательно
– Пишем плотно
– Хорошее сжатие.
21. Как делать compaction
• Избегать крайностей
– Редко: слишком много SST
– Часто: большой write amplification
• Работать эффективно
– Сливать файлы похожих размеров
– Сливать файлы с разными версиями
одной записи
• Есть много алгоритмов
– Size-tiered
– Leveled
– Date-tiered
– FIFO
27. Leveled compaction - выводы
• read amp. <= #L0+5
• Новые изменения сливаются
друг с другом
• write amp. <= 5*level_fanout +1
• size amp. ~ 1.11
• И мигрируют в старые уровни.
28. Log-Structured Merge – выводы
• Уменьшает write amplification
меньше операций записи
• Уменьшает size amplification
размер БД на диске меньше
• Увеличивает read amplification
читаем из нескольких SST.
29. LevelDB – реализация LSM
+ Встраиваемая библиотека на С++
+ Key/value store на LSM
+ Level-ed compaction
+ Open Source
+ Разработана в Google для Chrome
– Не для серверных нагрузок.
30. • Форкнули LevelDB
• Добавили
– Multi-threaded Compaction
– Multi-threaded MemTable flush
– Throttling, если compaction не
успевает
– Prefix bloom filter для range scans
– Column Families
– И т д.
http://rocksdb.org
32. Ограничения RocksDB
• Это key/value store
– Put(key, value), Delete(key)
– Write(WriteBatch)
• Нет
– Отдельных таблиц
– Типов данных
– Вторичных индексов
– ...
33. create table tbl (
pk int primary key,
...
) engine=RocksDB;
MySQL* + MyRocks=
• Табличный движок для MySQL
• Данные хранятся в RocksDB
• Конфигурация и диагностика
RocksDB через MySQL.
34. MyRocks готов к тестам
• SQL-семантика
• Транзакционный
– REPEATABLE READ
– READ COMMITTED
• Поддержка всех типов данных
• Поддержка индексов
– PRIMARY/UNIQUE/Secondary
– Поиск по всем видам условий
– Статистика для оптимизатора
• Можно пробовать приложения
35. • Мотивация
• Тех. Показатели
• Устройство
• Как попробовать
• Особенности
36. Как попробовать
• https://github.com/facebook/mysql-5.6/
• В будущем - в MariaDB (?)
• Присылайте вопросы, баги,
отзывы, идеи, патчи
• Обсуждение
– https://github.com/facebook/mysql-
5.6/issues/
– http://facebook.com/groups/rocksdb-dev
38. Настройки MyRocks
set global rocksdb_default_cf_options
='write_buffer_size=12m;target_file_siz
e_base=1m;max_bytes_for_level_multiplie
r=10'
• Настройка default column family
• Другие column families
• > 84 rocksdb_* переменных
set global rocksdb_override_cf_options
39. • Мотивация
• Тех. Показатели
• Устройство
• Как попробовать
• Особенности
40. Особенности SQL на LSM
• myrockshotbackup
• Сканирование в обратную
сторону.
• Bloom filters для range
scans
• Tombstones после массового
DELETE
41. myrockshotbackup
• Local server:
set rocksdb_create_checkpoint=
'/data/mysql/backup'
myrockshotbackup | ssh "tar zxf-"
• Remote:
myrockshotbackup –-move_back
• Create checkpoint
42. Сканирование в обратную сторону
• Проблема
– Большой размер блока
– Компрессия
– Читать с конца нельзя
• Решение: Column Family c хранением данных в
обратном порядке
select *
from user_messages
where user_id=1234
order by date desc limit 10
create table user_messages (
...
KEY key1(user_id,date) comment 'rev:cf_name'
43. Bloom filters для range scans
• Читаем из многих источников
• tbl.key=c1
• Во многих SST
ключа с1 нет
• Bloom Filter в
каждой SST.
MemTable Чтение
SST SST SST
44. Bloom filters для range scans
MemTable Чтение
SST SST SST
INDEX ON t1(col1, col2, …)
index_nr col1 col2 …
• tbl.key>10 AND tbl.key<20
• Надо проверять
все SST
• И Bloom Filter
не применим
• Bloom filter на
префикс:
45. Tombstones после DELETE
• DELETE создает tombstones
delete from messages
where date='2015-11-01'
select * from messages
where date>='2015-11-01'
• Решение
– Детектировать это при записи в SST
– Немедленно назначать compaction.
• При чтении их пропускают
46. В MyRocks нет всех фич
• Ограничения
– PRIMARY KEY обязателен
– ‘index only’ не для всех типов данных
– ALTER TABLE медленный
– Размер транзакции ограничен
– Нет crash-safe master
(пользуемся semi-sync)
• Это временно
– Дайте нам знать, что нужно в первую
очередь.
47. Выводы
• Табличный движок MyRocks основан на
RocksDB
• Приносит LSM серверного уровня в MySQL
• Решает проблемы write-heavy загрузки
– Меньше места на диске
– Меньше операций записи (износ SSD)
– «В 2 раза меньше InnoDB по тому и другому, без
замедления чтения»
• Состояние
– Интенсивная разработка (не все сценарии
покрыты)
– Но пробовать уже можно
– Open Source: приглашаем к сотрудничеству.
48. Ссылки
• RocksDB Storage Engine for MySQL and MongoDB,
Igor Canadi
https://www.percona.com/live/europe-amsterdam-
2015/sessions/rocksdb-storage-engine-mysql-and-
mongodb
• MySQL on RocksDB (MyRocks), Herman Lee
https://www.percona.com/live/europe-amsterdam-
2015/sessions/mysql-rocksdb-myrocks
Spinning disks – проблема – ограничение числи операций чтения
Flash – отлично решает эту проблема . За те же деньги 80x.
В чем проигрывает – на TLC flash – 5x less, MLC - 25x less.
MLC – 10,000 write cycles
TLC – 1,000 write cycles
(zlib level1 compression)
Important for extending flash duration
Two equal instances of RocksDB
Slow query log to capture query times
Blue for InnoDB, Orange for MyRocks. Running at full storage capacity and using all available memory for buffer/cache pools.
InnoDB around 80% cpu idle.
2xRocksDB around 50% to 60%
Можно настроить практически все!
Размер мемсторе, количество таблиц, размер 0-ого уровня. Размер 1-ого уровня, размер каждого уровня, компрессиию на каждом уровне, размер файлов или количество файлов, количество нитей комрессии,
Если менять код – алгоритмы мемсторе, формат данных на диске, интерфейсы с ОС (pfile, mmap, HDFS, etc…), тип кеша
Рекомендуемые настройки – дефолтные настройки плохие
Цель настроек.
Компакция идет всегда. Нужно чтобы не было затыков.
Скорость компакции – компромис между read and write amplification
5-6 уровней, разница между уровнями 10-x
Включить компрессию на высоких уровнях, но не включать на низких
Использовать одну нить для флаш и столько нитей для compaction, сколько CPU