backend

Stachka.Backend

Backend is the main component of a service or an application that the user does not work with directly. The Backend section will be useful for specific programmers who are interested in such topics as:

  • Databases
  • Highload
  • Architecture Design
  • Up-to-date programming practices
  • This year we have improved the education part of the section. The program’s got more balanced. At the Backend section specialists of all levels will gain knowledge that is practically applicable in real projects.


Мой доклад будет состоять из нескольких мини-докладов, в которых я постараюсь рассказать про новую функциональность/улучшение/исправление и добавлю немного бэкграунда для лучшего понимания. Например, в 12 версии ожидаются поддержка KNN для SP-GiST и B-tree, но все ли знают или помнят, что такое SP-GiST и что такое KNN и как им пользоваться ? К моменту конференции будет уже известно наверняка, что попадет в PG 12 и я очень надеюсь, что удастся закомитить долгожданный SQL/JSON (по-крайней мере, мы над этим усиленно работаем), но даже если что-то пойдет не так, я расскажу о проблемах, возникших у нас при реализации стандарта в постгресе.

В докладе я проведу обзор отдельных примеров мало кому известных систем управления базами данных. Некоторые из них устарели, некоторые прекратили своё развитие и заброшены. Мы попробуем найти интересные архитектурные решения в этих примерах и разобраться в их судьбе. Будут даны ответы на вопросы: - почему некоторые open-source продукты перестают развиваться; - что нужно для успешного open-source продукта.

Подробно разберем нехитрый (казалось бы) полусинтетический пример про обработку простенького CSV, и даже на нём традиционно вскроются бездны, а глаза задёргаются от грязных трюков, я гарантирую это. Узнаем, что "лучше", bash, PHP, Python, node.js, Go или С++ (спойлер: необязательно C++). Посмотрим, где работает алгоритмическая оптимизация, а когда уже перестает. Убедимся, что даже в самом простом случае есть несколько вариантов решения, и что вариант "строго по книжке" (даже Кнуту, ага) вовсе необязательно хорош. И, пожалуй, самое интересное: умеренно подробно (по бюджету времени, а то вечно не хватает) разберем на части топовое по скорости решение - и все дающие (или нет) в нём эффект оптимизационные фокусы. Звучит скучно и уныло, так как ты и так все это знаешь и умеешь, поэтому доклад заведомо неинтересен? Это отлично! Побей мой топчик по скорости (спойлер: ты не сможешь) и получи дикую уважуху плюс вкусный жидкий приз. ;)

Посмотрим вместе на современный PHP и фреймворки. Разберём что Yii за свою историю сделал хорошо и что плохо. Поговорим о будущем. О версии 3.0.

JIT (Just in Time) компиляция – неотъемлемая часть многих популярных платформ (JavaScript, Java). Задача компиляции в момент выполнения существенно отличается от классической AOT (Ahead of Time) компиляции. Эволюция технологий JIT и AOT компиляции во многом идут параллельными путями. В докладе будет рассказано о новейших достижениях JIT компиляторов для Java и JavaScript платформ, а так же о фундаментальных отличиях JIT и AOT компиляторов.

С ростом скорости мобильного интернета выросла и популярность видеозвонков. Сейчас трудно представить мессенджер или соцсеть без этого сервиса. Сегодня мы поговорим о том, как сделать свой сервис конференц-звонков на 100 участников своими руками. Попутно рассмотрим, как устроены звонки, как их запилить, и как сделать ваши – лучше звонков конкурентов. Нас ждет: - разбор технологий и сравнение конкурентов - внедрим звонки на WEB, iOS, Android - сделаем лучше за счет искусственного интеллекта и доработаем установку p2p соединения - сделаем конференции на 100 участников

Это вторая инкарнация моего доклада о том какие ошибки допускают разработчики при работе с Postrges'ом. Я с моими коллегами из Data Egret являемся Postgres-консалтерами и регулярно наблюдаем как команды разработки осознанно или нет, но допускают ошибки при работе с Postgres'ом. В этом докладе я постараюсь разобрать разные ситуации, которые допускают команды разработки, и даже иногда видят их как решение своих задач, но при этом DBA видят в них источник потенциальных проблем здесь и сейчас либо в обозримом будущем. В докладе я рассмотрю: - проблемы, связанные с планированием, мониторингом и дефолтными конфигурациями, которые встречаются практически везде и всегда; - антипаттерны, связанные с проектированием схем данных; - проблему длинных транзакций, которая часто становится сюрпризом; - еще будет про самописные системы очередей, HTAP workload, "бигдату", docker/kubernetes. По ходу доклада слушатели узнают про некоторые best и worst practices при работе с СУБД и, уже смотря на свои базы, смогут заранее спрогнозировать возникновение неприятных ситуаций и предпринять меры. Доклад будет полезен широкому кругу технических специалистов, вовлеченных в разработку ПО и обслуживание баз данных.

У нас в компании эксплуатируются тысячи микросервисов на .NET. Мы стараемся делать качественные продукты, поэтому особое внимание уделяем телеметрии: логам, метрикам и распределённым трассировкам. Проект Vostok - это инструменты и практики, зарекомендовавшие себя внутри Контура, которые мы делаем частью OpenSource. Сегодня поговорим о той части Востока, которая обеспечивает централизованную обработку телеметрии. Ключевые технологии:
 - Apache Kafka 
- Apache Cassandra 
- Apache ZooKeeper
 - Graphite 
- ELK

Незаметно для самих себя мы в Ecwid доросли до 100Gb (и 200 миллионов строк) логов каждые сутки. Unix-утилиты, конечно, дают жару, но grep/sed/awk на таких объемах увы, не справляются. Мы запихнули все эти десятки терабайт за несколько месяцев в ClickHouse, написали свой простой язык запросов, подкрутили тут, там и получилась очень простая и быстрая система работы с логами. В докладе я объясню как за пару дней на коленке построить себе такое же счастье.


MariaDB давно переросла своего родителя MySQL за счёт функционала добавляемого в MDB. Одной из фичей стал engine для аналитической нагрузки - Columnstore AKA MariaDB AX, который отлично укладывается в парадигму MariaDB: каждой нагрузке свой движок. В рамках доклада я познакомлю аудиторию со строением и возможностями Columnstore.

Два года назад мы ввели в эксплуатацию новую платформу нашей платежной системы. Компонентно, наша платформа разделена на три больших подсистемы - платежная страница, подсистема связи с банками и МПС (мы ее называем PLUS) и непосредственно ядро платформы. В качестве шины данных для ядра мы используем Apache Kafka, а в качестве сервера очередей для подсистемы PLUS мы хотели использовать Tarantool. Почему мы выбрали эти инструменты, с какими проблемами мы столкнулись в процессе эксплуатации этих систем, как мы их решали, а также про то, что мы в итоге отказались от Tarantool - об этом и поговорим.

В докладе я сравню процессы перехода на Go в двух компаниях с совершенно разными технологическими стеками (PHP и .NET). Я постараюсь сделал доклад сбалансированным и в равной степени осветить техническую и организационную сторону этого вопроса. Чего в этом докладе не будет: рассказа о том какой Go замечательный язык, об этом уже достаточно сказано.

Развивать большое и нагруженное приложение без мониторинга — трудно и опасно так же, как и пилотировать самолёт без приборов. Почему важно следить за «полётом» приложения, на что нужно обращать внимание, как графики в мониторинге помогают быстро решать возникающие проблемы с производительностью и не допускать их вновь. На примере боевого опыта с очередями отложенных задач Sidekiq, системы мониторинга Prometheus и графиков в Grafana расскажу и покажу, как работает мониторинг «под капотом», как снимать показания с любого приложения (Ruby и не только), как их визуализировать, расскажу пару грустных историй со счастливым концом о том, как это помогает команде и проекту каждый день. Представлю набор новых Ruby-гемов для настройки стандартного мониторинга «в два счёта» и для лёгкого включения любых кастомных метрик в своё приложение и свою систему мониторинга.

PostgreSQL - одна из тех СУБД, для которой пока не существует встроенного решения для высокой доступности (HA). Однако имеется множество сторонних обвязок (corosync/pacemaker, repmgr, etc), а также встроенных решений в рамках отдельных форков (PostgresPro Enterprise multimaster, BDR), которые восполняют данный функционал. В своём докладе я расскажу о двух решениях stolon/patroni, которые приобрели особую популярность в облачных системах. В частности, затрону темы: - различные виды инсталляций (под управлением systemd и стороннего оркестратора контейнеров); - мониторинг кластера и интеграция с системами бэкапирования; - слабо описанные в документации возможности и ограничения этих систем.

Если тебе часто нужно создавать новые блоки большого приложения или сервисы в составе сложной архитектуры, то в конце концов встает вопрос, как сделать этот процесс проще, как не вдаваться в долгие и сложные объяснения новому разработчику, как у тебя тут все работает, и не впадать в ступор в тот момент, когда видишь абсолютно дикий и непонятный код твоего, вроде бы умного, коллеги. В докладе пойдет рассказ про варианты избавления от боли при интеграции, создании и сопровождении проектов с SOA с помощью стандартизации кода, строгих контрактах взаимодействия компонентов и грамотного выделения ресурсов.

Domain-driven design — набор подходов к разработке, который, с одной стороны, на слуху, а с другой, к нему очень сложно подступиться. Есть большие книги (Эванс, Вернон), но далеко не все их читают и еще меньше людей читают их до конца. А даже и дочитав, могут упустить суть за обилием деталей. Сотни статей в блогах и постов на StackExchange только усугубляют эту проблему. О чем жалеет Эванс спустя 15 лет после выхода его книги? Bounded context: имеет ли значение размер? Все ли паттерны одинаково полезны? И, наконец, в чем же суть domain-driven design? Обо всём этом расскажет Алексей в своем докладе. Отличный повод узнать DDD и разложить по полочкам.

Пять лет мы жили с самописной шиной для обмена данными — теряли сообщения и страдали от однопоточного импорта. Сегодня мы используем Apache Kafka и Golang для обмена данными между сервисами. Расскажу, как механизм «отложенных данных» помог нам организовать сбор информации от десятка команд. От десятка команд, чья очередность выгрузки непредсказуема. Поделюсь, как нам удалось построить зависимости и поставлять данные констистентно и в срок.

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

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

Operational Transformation (OT) в действии В докладе я постараюсь рассказать о технологии Operational Transformation (OT), используемая в таких известных продуктах как Google Docs, Google Wave. Отличительная особенность таких проектов - одновременный неблокирующий доступ к одним данным от многих пользователей. Подходы к разрешению конфликтов. Расскажу, на каких моделях данных может быть полезен и применим OT. Доклад будет полезен тем, кто хочет делать отзывчивый/неблокирующий сложный UI и избегать конфликтов доступа к данным.