Highload++ 2017 завершён!

Профессиональная конференция разработчиков высоконагруженных систем

СКОЛКОВО, Москва 7 и 8 ноября

11-я ежегодная конференция для разработчиков highload-систем, которая соберет   2 700 участников из разных регионов России и мира. Мероприятие направлено на обмен знаниями о технологиях, позволяющих одновременно обслуживать многие тысячи и миллионы пользователей.

Программа охватывает такие аспекты веб-разработок, как архитектуры крупных проектов, базы данных и системы хранения, системное администрирование, нагрузочное тестирование, эксплуатация крупных проектов и другие направления, связанные с высоконагруженными системами.

The Proxy Wars на HighLoad++: MySQL Router, ProxySQL, MariaDB MaxScale и другие

Кстати, у нас full house :)

В программе доклады от Alibaba, Яндекс, Badoo, Facebook, Mail.RU, Dropbox, Atlassian, Avito, Google, YouTube, Agoda, Одноклассники, Сбербанк-технологии, Rambler&Co, Booking.com, Циан, Nginx, Дойче Банк, Альфа-банк, Тинькофф-банк, Сбербанк, 2ГИС, JetBrains, Qiwi и другие.

Методология «Database First!» в растущем проекте

Николай Самохвалов продолжает топить за то, что всеми вопросами работы с данными — выборками, сортировками, поиском, хранением, вычислениями и обработкой — должна заниматься база данных. В высоконагруженных проектах зачастую наблюдается обратная ситуация — база используется исключительно как место, где вы храните сырые данные, а вся обработка происходит на бекендах. Так вот — это неверно, утверждает Николай.

"СУБД — сердце и мозги вашего проекта. Это не просто место, куда можно складывать данные и забирать их оттуда. Современные СУБД (ну, к примеру, Postgres) позволяют хранить огромное количество данных, хранить надёжно и эффективно. А современный стандартный SQL и его расширения — быстро находить иголки в стогах сена, эффективно менять большие куски данных, проводить нетривиальные вычисления и использовать различные модели машинного обучения без лишних усилий."

Это продолжение доклада "Database First! О распространённых ошибках использования РСУБД", прозвучавшего на РИТ++ 2017.

Ну, посмотрите, это же очевидно! - как бы говорит нам Николай :)

Зачем нужны MySQL-прокси? Прокси работают между сервером MySQL и клиентом, перенаправляя запросы от клиента к серверу. В двух словах, это failover, балансировка нагрузки, фильтрация (и даже модификация) запросов и предобработка результатов.

Но какой прокси-сервер выбрать?

Об этом в докладе Сolin Charles из компании Percona.

As proxies (and database routers) go, the first one I ever used was the now deprecated MySQL Proxy. Since then, I've managed to use MariaDB MaxScale quite a bit (including its fork AirBnB MaxScale), played around with ProxySQL in recent time, and also started taking a look at MySQL Router. In this quick 20-minute overview, we'll discuss why these three exist, a feature comparison, and reasons when to use the right tool for the job.

Продолжим копать вглубь MySQL.

Гибкая схема хранения данных в MySQL (JSON) для интернета вещей

Александр Рубин (Percona) в своем докладе обсуждает возможность хранения данных в формате JSON в MySQL.

Хранение данных с датчиков Интернета Вещей (Internet of Things) может быть сложным во многих отношениях, в частности, из-за меняющегося характера данных. Например, если у вас есть фиксированная структура таблицы, а датчику необходимо будет сохранить новое свойство в этой таблице, потребуется изменение структуры таблицы.

JSON позволяет хранить данные в гибком формате. В этом докладе обсуждаются различные варианты реализации гибких схем хранения данных в MySQL 5.7 и MySQL 8.0 с использованием JSON.


Что мы всё про MySQL, да PostgreSQL? Исправляемся!

100500 способов кэширования в Oracle Database, или как достичь максимальной скорости обработки запросов минимальной ценой

Александр Токарев (DataArt) раскроет базовые причины, которые заставили появиться такой части механизма СУБД, как кэш результатов, и почему в ряде СУБД он есть или отсутствует.

Будут рассмотрены различные варианты кэширования результатов как sql-запросов, так и результатов хранимой в БД бизнес-логики. Произведено сравнение способов кэширования (программируемые вручную кэши, стандартный функционал) и даны рекомендации, когда и в каких случаях данные способы оптимальны, а порой опасны. В рамках рекомендаций будет сделана попытка вывода формул по расчёту параметров кэширования: время хранения результата, размер кэша и т.д.

Также будут рассмотрены их "подводные камни" и способы их устранения.

Ну и на вкусное...

Логическая репликация и Avito

Константин Евтеев и Михаил Тюрин раскроют в данном докладе:

  • Необходимость логической репликации вообще и кейсы Avito;
  • Эволюция и принцип работы триггерных решений с версии Postgres 7.0: RServ Вадима Михеева (Vadim Mikheev, автор MVCC), Слоны (Slony), Слоник "Londiste" (PgQ) от Skype;
  • Архитектура логической репликации "из коробки": Logical Replication in PostgreSQL 10 & PGLogical;
  • Примеры использования репликации и её расширений в Avito;
  • Вопросы и пожелания, адресуемые комьюнити!

И это далеко не всё! В программе более сотни докладов!

До встречи на конференции!

Подключайтесь!

Rambler's Top100