Как быстро развивается сейчас PostgreSQL — общеизвестно. За несколько дней до РИТ++ заканчивается главный мировой форум разработчиков этой СУБД — конференция PGCon в Канаде. Большая команда разработчиков Postgres Professional принимает участие в этой конференции и готова рассказать все последние новости прямо с PGCon.

Параллельное исполнение запросов, новые стораджи, неутихающая тема Postgres vs key-value storage, распределенный Postgres, высокая доступность, многочисленные улучшения производительности, планы и интриги разработчиков — вот основные темы этой конференции.

Я остановлюсь подробнее на нашем вкладе в ожидаемый релиз 9.6 и планах на, возможно, релиз 10.0.

1. Задачи по объединению текстов в группы.
1.1 Что такое кластеризация текстов, где она полезна, какие задачи решает.
1.2 Что такое классификация применительно к текстам, примеры использования.

2. Тематическое моделирование.
2.1. Генеративные языковые модели.
2.2. Вероятностные латентно-семантические модели (pLSA).
2.3. Латентное размещение Дирихле (LDA).
2.4. Обзор инструментов для тематического моделирования.

3. Решение задач кластеризации и рубрикации на потоке новостных текстов.

Современные процессоры имеют на борту по нескольку вычислительных ядер, позволяющих запускать задачи на них параллельно. И, казалось бы, вот оно — счастье: бей большие задачи на куски, запускай эти куски параллельно на разных ядрах и радуйся.

Но не все так просто. Для того чтобы одновременный доступ к общим данным выполнялся корректно, современные системы используют разные примитивы синхронизации. В основе одних лежат блокировки (locks), в основе других — операции типа сравнение-с-обменом (compare-and-swap). Однако и у тех и у других есть свои слабые места. О них мы и поговорим.

Из доклада вы узнаете, чем блокирующие алгоритмы отличаются от неблокирующих, и какими достоинствами и недостатками обладает каждый из этих классов. Кроме того, будут показаны различные подводные камни тех и других решений: Deadlock, Livelock, Starvation, Mutable vs Immutable hype.

В современном мире многие разработчики перестали стараться писать высокопроизводительный код. Порой их можно понять: в наше время прекрасных облачных решений дешевле докупить дополнительных серверов, чем тратить время на оптимизацию кода. Но что, если у вас нет такой возможности? Что, если для текущей задачи вы ограничены одной машиной или даже одним потоком?

В этом докладе мы обсудим некоторые подходы, которые помогают выжимать максимум производительности из современного железа и позволяют разгонять программы, которые, казалось бы, разогнать нельзя. В числе прочего будем обсуждать следующие вещи: CPU cache, Instruction Level Parallelism, False sharing, Branch Prediction, SEE/AVX instructions и т.д.

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

В условиях, когда нет возможности протестировать все варианты, мы можем решать задачу моделирования и восстанавливать зависимости одних метрик от других. Но как организовать эксперимент так, чтобы при минимальных затратах ресурсов получать наиболее качественные модели?

На что смотреть при внедрении результатов? Ведь модель, построенная на части пользователей, может изменится, когда вы примените её на 100% своей аудитории.

В своём докладе затрону тему дизайна экспериментов и расскажу о подходах, которые мы используем на практике при оптимизации продаж рекламы через разные каналы в Авито. А также обращу внимание на проблемы, которые можно встретить при внедрении результатов.

Многие считают, что провести A/B эксперимент просто, тем более, что уже есть инструменты, которые позволяют автоматизировать этот процесс. При этом почти никто не задумывается о допущениях, на которых основана работа этих инструментов. По-настоящему случайное распределение пользователей, независимость измеряемых событий — либо всё это кажется само собой разумеющимся, либо об этом вовсе не задумываются.

Между тем систему проведения экспериментов на пользователях очень легко сломать, поставив её в неподходящие условия, и потом принимать по результатам экспериментов решения, не отличающиеся от случайных. В докладе мы рассмотрим несколько примеров из мировой индустрии и из практики Яндекса. Если вы делаете у себя A/B тестирование, то хотя бы одна из этих проблем у вас почти гарантированно есть.

Как одно из средств мониторинга здоровья системы экспериментов предлагается проведение постоянного A/A эксперимента, то есть такого, у которого контрольная и экспериментальная группы пользователей видят одно и то же. Есть довольно много классов проблем, которые можно выявить с помощью этого мониторинга. Единственно, делать его довольно накладно, если у вас мало пользователей, но и на этот случай есть пара лайфхаков, которые мы тоже рассмотрим.

Основы AB-тестирования, история вопроса. Что необходимо для построения инфраструктуры AB-тестирования? Технические и пользовательские сложности при проведении AB-тестирования. Анализ результатов.

Рассмотрим несколько важных моментов:
- На что обратить внимание при выборе контрольной группы?
- Множественная проверка гипотез.
- Сколько экспериментов может видеть пользователь?

Какие инструменты вам могут понадобиться для проведения и анализа экспериментов?
Разберем несколько поучительных примеров.

Набирает обороты мода на парадигму noBackend (см., например, http://nobackend.org/). Название не стоит понимать буквально: backend никуда не делся, просто фокус разработки — особенно на начальном этапе развития нового проекта — сильно смещается в сторону «клиентской части». Это очень понятно и закономерно в эпоху Mobile First и React Ecosystem с её новомодными GraphQL и React Native.

Появляется большой соблазн взять что-то понятное для хранения данных и уже «обвязанное» REST API, максимально отказаться от PHP/Python/Ruby/Java/etc, писать 80% кода «на стороне клиента», минимально заботясь о возне «на стороне сервера». У некоторых возникает и настоящая эйфория — чувство приятное, но очень опасное (прежде всего, если в команде нет сильного backend-опыта).

Этот доклад — компиляция опыта ряда проектов, написанных на React, React Native и Swift и переходящих на парадигму (или же сразу стартанувших с неё) noBackend за счёт PostgreSQL+PostgREST.

Мы обсудим важные вопросы, которые обязан задавать себе каждый, выбравший noBackend-подход (и не обязательно на связке Postgres+PostgREST): безопасность (аутентификация/авторизация; ограничение чтения и — особенно! — модификации «чужих» данных), производительность (нетривиальные запросы а-ля «свежий контент от тех, на кого я подписан»; компромисс между сетевой сложностью и CPU; защита от «домашнего» ddos — ситуации, когда свои же, родные «фронтендеры» кладут «бэкэнд»), масштабируемость и асинхронная обработка задач.

Задача-минимум (для всех): у каждого слушателя остаётся список must-check-вопросов для работы с noBackend-подходом.
Задача-максимум (для тех, кто с Postgres-опытом): разворачивание безопасного, высокопроизводительного и годного для быстрого развития REST API — сегодня же, в день доклада.

Из доклада вы узнаете о том, как в Avito используется Sphinx search, почему было выбрано это решение, какие подводные камни встретились на пути, и как их преодолеть.

Андрей поделится практическим опытом настройки и оптимизации Sphinx search, который позволяет добиться стабильной работы кластера и высокой скорости индексации и поиска. В Avito Sphinx индексирует 35 млн. объявлений каждые 7 минут!

C недавнего времени на Avito.ru появилась контекстная реклама. Миллионы объявлений, из которых нужно в режиме реального времени отобрать несколько релевантных для каждого отдельного пользователя.

Я расскажу о том, как и зачем мы используем миллионы коэффициентов при обработке каждого запроса, почему мы выбрали Sphinx и какие хитрости мы применили, чтобы уложиться в 100 миллисекунд.

Основные кейсы использования Тарантула:

1. Когда нужна OLTP-система, позволяющая обрабатывать транзакции в режиме почти реального времени (с милисекундными задержками) и/или с огромной пропускной способностью (сотни тысяч запросов в секунду). Примеры — система сессий, система антибрутфорса, система противодействия атакам, система очередей и пуш-уведомлений, роутинг запросов между серверами.

2. Когда нужна реал-тайм OLAP-система. Т.е. когда нужно супероперативно принимать решения (желательно в реал-тайме), собирая и анализируя информацию по многим источникам. Примеры: фича "уберись в ящике" в Почте@Mail.Ru, почтовый общий и персональный антиспам, система показа рекламы, любые системы, касающиеся классификации и кластеризации данных, которые должны работать в онлайне.

3. Когда текущая СУБД стоит слишком дорого по серверам или лицензиям, и есть желание заменить ее на нечто, что будет в десятки, если не сотню раз более экономное (за счет отсутствия лицензии и за счет радикального снижения количества железа). Можно эту СУБД заменить на Тарантул.

4. Когда текущая СУБД обложена большим зоопаркам NoSQL решений и кэшей с целью повысить ее производительность, но при этом хочется еще больше производительности и/или хочется решить проблему несогласованности данных. Можно эту СУБД и все обвязки вокруг нее заменить на Тарантул.

5. Когда хочется повысить надежность и/или скорость работы текущего кэширующего решения. Можно это решение заменить на Тарантул.

6. Когда текущая СУБД и/или кэш не позволяют в полном объеме реализовать необходимую логику внутри и использовать их как application server. Можно эту СУБД и/или кэш заменить на Тарантул или можно новые фичи разрабатывать Тарантул, не теряя старых решений (Тарантул умеет интегрироваться и реплицироваться в обе стороны с любыми решениями за счет полноценного алгоритмического языка внутри с мощным сетевым SDK).

Решение о разработке своей собственной DBMS (системы управления базами данных) общего назначения обычно зреет долго. Прежде чем броситься в эту нелегкую пучину, вы сначала ищете другие способы решения задач существующими инструментами, в том числе создавая поверх них или интегрируя их различные решения.

И только в тот момент, когда перед вами вырисовывается светлый образ идеальной базы данных, которая конкретно отличается от существующих инструментов и обладает всеми необходимыми вам фичами, вы бросаетесь во все тяжкие и начинаете творить.

Именно так и появился Тарантул — одна из самых быстрых баз данных в мире, которая широко применяется в Mail.Ru Group и за её пределами.

Поскольку Тарантул с самого начала разрабатывался отдельной командой в открытых исходных кодах и с прицелом на общее использование, в результате мы получили отличный продукт — DBMS общего назначения с уникальным набором фич.

Денис расскажет о типичных проблемах нагруженных проектов, стандартных способах их решения и причинах, почему они в какой-то момент перестают работать, и как в таких случаях помогает Тарантул.

Начав разработку нового продукта через микросервисы, мы неожиданно для себя обнаружили, что микросервисы — это не просто "вместо одного большого приложения теперь пишем много маленьких". При разработке большой системы она сама собой через какое-то время становится набором отдельных сервисов, которые должны взаимодействовать между собой, поэтому стабильная работа сервисов и их взаимодействие не стало чем-то новым. Неожиданностью стало то, что система стала значительно более динамической, она стала постоянно изменяться отдельными небольшими частями, сервисы стали часто перезапускаться, а количество запущенных нод сервисов стало расти по экспоненте.

Очень быстро стал актуальным вопрос конфигурирования — если раньше, выкатив новую версию монолита с единым конфигом, мы применяли правки на всю систему сразу, то с микросервисами все сложнее — пара сотен работающих нод и всем нужно применить изменения. Требования к деплою также поменялись — он стал частью процесса разработки, а тестирование стало частью деплоя. Количество необходимого ПО для функционирования системы также стало некоторым сюрпризом.

В докладе я расскажу о том, как в итоге это работает у нас, как мы решили такие вопросы как:
- конфигурирование сервисов;
- интеграция между собой;
- тестирование;
- версионирование;
- масштабирование.

Расскажу, какие тулзы мы в итоге используем, а от каких отказались.

«Одноклассники» состоят из тысяч серверов, большая часть которых участвует в онлайн-обработке запросов пользователей. Каждый из этих серверов владеет только частью данных или логики. Эти части в социальной сети изолировать друг от друга невозможно, поэтому между серверами происходит много сетевого взаимодействия — разнообразного и большого по объему. Таким образом, Одноклассники — это одна из самых больших, сложных и нагруженных распределенных систем в мире.

В этом докладе Олег расскажет об опыте построения отказоустойчивых распределенных систем на Java, основных ошибках и отказах, приемах их тестирования и диагностики. Также речь пойдет об авариях в распределенных системах и методах их предупреждения.

Кто пишет тезисы, тот и прав, а кто выступает на стороне PostgreSQL, тот прав вдвойне. Когда я (Александр Чистяков) в момент старта очередного нового проекта узнал, что мой старший коллега (Даниил Подольский) хочет использовать MySQL в продакшне, я встал и сказал себе: "Хватит это терпеть!". Вероятно, я сказал слишком громко, потому что Даниил услышал, и мы еще с час обсуждали вопросы применимости РСУБД в современных проектах в общем чате, пугая Заказчика.

Тем не менее, нам ничего не оставалось, кроме как договориться о публичном поединке. Мы представим на суд общественности результаты нагрузочного тестирования двух этих замечательных РСУБД, поставленных в одинаковые, но жесткие условия современного веб-проекта. Мы идентифицировали несколько распространенных профилей нагрузки, и написали генератор нагрузки на (не очень) любимом нами языке Golang. В остальном правила поединка просты: правил нет никаких, и я уже придумал пару сценариев использования, на которые MySQL просто не способен!

В эпоху распределённых архитектур и микросервисов как никогда актуальными становятся вопросы — как эффективно сериализовать и передать данные. Большинство решает данный вопрос просто — используют стандартный, универсальный и всем понятный формат JSON. Другие же, ориентируясь на производительность, ищут в интернете бенчмарки и выбирают protobuf или msgpack.

Мы протестировали разные реализации статически (thrift, protocol buffers) и динамически (json, msgpack) типизированных протоколов для python; сравнили их производительность в разных сценариях, возможности, внутреннее устройство, удобство разработки.

Я расскажу о результатах нашего исследования, особенностях "приготовления" библиотек и выявленных подводных камнях.

Я расскажу про еще один Open Source Web-акселератор — Tempesta FW. Уникальность проекта в том, что это гибрид Web-акселератора и файервола, разрабатываемый специально для обработки и фильтрации больших объемов HTTP трафика. Tempesta FW встроена в TCP/IP стек Linux и несет в себе легкую in-memory оптимизированную для NUMA-систем базу данных для хранения Web-кэша и правил фильтрации. Основные сценарии использования системы — это защита от DDoS прикладного уровня и просто доставка больших объемов HTTP трафика малыми затратами на оборудование.

В докладе я расскажу про:
- зачем нужен еще один Web-акселератор, и в чем его отличие от Nginx, Varnish, HAProxy и даже TUX и kHTTPd;
- типовые сценарии использования (CDN, cloud, фильтрующие сети и пр.);
- основные фичи (кэширование, балансировку нагрузки, фильтрацию);
- частые вопросы, связные с реализацией проекта в ядре ОС, производительностью и надежностью;
- системные требования, примеры конфигураций и, просто, как это все собрать и запустить.

Поговорим о неотъемлемой составляющей большого числа современных веб-проектов — о фреймворках.

Рассмотрим следующие темы и поищем ответы на вопросы:
1) Что такое фреймворк, и зачем их пишут.
2) Почему для некоторых языков их десятки, а для некоторых — единицы.
3) В чём плюсы и минусы применения.
4) Наиболее распространённые мифы.
5) Использовать или нет — примеры из жизни.
6) Как выбрать из множества доступных вариантов, на что стоит обратить внимание.

Выпуск коробочного продукта — это всегда компромисс между количеством новых фичей, их качеством и длиной релиз цикла. И всегда есть фичи для ограниченной аудитории или просто эксперименты. Популярное решение в такой ситуации — возможность написания плагинов к продукту. Но для написания плагинов нужно иметь мощное SDK у самого продукта. В Plesk мы назвали такие плагины расширениями (extension), реализовали SDK и создали свой каталог.

В докладе я расскажу:
- как мы разрабатывали свой SDK и каталог расширений;
- через что мы прошли, чтобы выйти на рынок;
- как мы публикуем расширения наших партнёров и вендоров, и какие расширения никогда не попадают в каталог;
- какими были наши первые расширения, и каким каталог стал после 2 лет от официального запуска;
- каким мы видим будущее нашего каталога расширений.

При разработке каждого backend приложения рано или поздно встает вопрос об измерении производительности системы и поиска «узких» мест. Для этой цели мы используем Pinba.

Для тех, кто не знаком с этим инструментом, я коротко расскажу о возможностях Pinba и о том, какие задачи мы решаем с её помощью. Основной акцент доклада будет сделан не на внутреннем устройстве Pinba, процессе установки и настройки — всё это есть в документации. Гораздо полезнее на реальных примерах показать, что и как мы измеряем и как агрегируем данные для построения отчетов в режиме реального времени.

Основные аспекты доклада:
- измерение производительности php скриптов;
- измерение времени обращений к внешним сервисам;
- измерение «хитрейта» кэша;
- измерение производительности обработки очередей;
- построение распределений и использование перцентилей.

Я расскажу о том, как использовать Pinba в связке с Nginx и делать различные агрегации в зависимости от параметров URI.

Большинство примеров будет основано на взаимодействии Pinba с PHP. Но сейчас есть плагины, позволяющие отправлять данные в Pinba из программ на различных языках, методология при этом практически не меняется.

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

Расскажу об особенностях платежных систем, опишу причины выбора основных архитектурных решений (Java, PostgreSQL, сервисы) и особенности процесса разработки.

Основные интересные моменты, на которых остановлюсь подробнее:
1) как решать популярные проблемы с БД и что делать, если не хватает IOPS;
2) какую надежную очередь стоит использовать;
3) какие нестандартные практики были успешными: IDE driven development, JSON вместо ORM, Functional test вместо Unit test;
4) какие решения были неправильными: PyTest, Spring Security, docker, велосипеды, разработчики, магия;
5) зачем менять методологию разработки три раза за год — и почему во многих проектах это тоже стоит делать.

Надеюсь, часть из сказанного вызовет несогласие и дискуссию.