HighLoad++

Заявки на доклады:
  • Когда Sports.ru превратился из новостного сайта в полноценную социальную сеть, месячная аудитория достигла 12 миллионов уников, а к сайту добавились несколько сотен групп в социальных сетях и клубных мобильных приложений, обычных инструментов веб-аналитики стало недостаточно. Нам нужно было научиться считать и визуализировать много новых метрик, специфичных для медиа и социальных сетей, и использовать полученную информацию для персонализации сайта. Тогда мы решились взяться за разработку собственной аналитической системы, которая позволила бы собрать в одном месте все нужные данные, быстро их обработать и понятно отобразить.

    Мы расскажем о том, как научились хранить данные о трафике на наших сайтах (около 400 млн хитов в месяц) в распределенной колоночной СУБД, выгружать из API социальных сетей и AppAnnie данные о подписках на наши потоки и установках мобильных приложений, а также импортировать из БД сайта информацию об активности зарегистрированных пользователей. Для работы с накопленными терабайтами данных мы научились делать удобные дашборды, которыми могут пользоваться не только аналитики, но и журналисты, маркетологи и продакт-менеджеры.

    При создании нашей аналитической системы мы использовали Amazon Redshift в качестве основного хранилища данных, PostgreSQL для получения информации из БД сайта, MongoDB для кеширования персонализированных рекомендаций и Chart.io для визуализации.

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

    Оптимизированные для записи структуры данных хорошо подходят для архитектуры шардинга, которая обеспечивает более высокую эффективность по сравнению с традиционными архитектурами шардинга. Цель настоящего доклада - описать данную архитектуру.

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

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

    - Какое железо и какие механизмы могут стоять между программным кодом и материальным объектом (например, бетонной плитой);
    - Какое место здесь имеет программное обеспечение;
    - Как взаимосвязанны между собой программирование, схемотехника, электрика, механика, и в чем состоит разработка таких систем на грани и за рамками программирования;
    - Использование Linux в ядре системы (мы же понимаем Linux - на нем и будем жить);
    - Как разрабатывать такое ПО в привычной и дружелюбной среде;
    - “Оригнинальные” вызовы и проблемы программирования реальной среды.

  • В докладе я хочу познакомить аудиторию с нашей разработкой - распределенным хранилищем структурированной информации. При разработке мы хотели объединить скорость и отказоустойчивость Key-Value+ хранилища с гибкостью структуры данных, как в SQL, и возможностью проводить произвольные запросы поиска.
    Текущая реализация: .Net, поддержка нескольких СУБД на узлах (SQLite и MS SQL Server).
    Столкнувшись с задачей хранения в БД таблиц с большим количеством строк (более 3 миллиардов) и поиска в этих таблицах по комбинациям более чем 5 условий, мы решили разработать свое хранилище. Для хранения мы использовали подход основанный на распределенных хеш-таблицах (применяемый, например, в Elliptics - DHT ) и разработали алгоритм для выполнения произвольных запросов поиска по распределенному хранилищу.

  • Клиент хотел хранить в MongoDB результаты тестов из своей системы непрерывной интеграции, чтобы сравнивать количество пройденных и не пройденных тестов для каждой сборки.

    Модель данных представляла собой 3D-матрицу: можно думать о каждой сборке как об электронной таблице с вкладками, строками и столбцами – всего 17 миллионов значений для каждой сборки. Цель состояла в том, чтобы показать разницу между любыми двумя сборками, а затем продемонстрировать, что добавление дополнительных шардов линейно уменьшает время отклика. Это позволило клиенту обеспечить соответствие сколь угодно высоким требованиям к времени отклика путём предоставления необходимого количества оборудования.

  • MongoDB имеет горизонтально масштабируемую архитектуру. Шардируя свой MongoDB-кластер, вы можете увеличить его вычислительные мощности, будь то дисковое пространство, ОЗУ или ЦП. Шардинг – встроенная функциональность, шардинг и решардинг для данных выполняется автоматически, и возможность подключения к клиенту совершенно прозрачна.

    Выбор ключа шардирования – ключевой архитектурный вопрос, который требует особенно тщательного обдумывания, поскольку в дальнейшем его нельзя будет изменить. Tag Aware Sharding (шардинг с учётом тэгов) – простой, но эффективный инструмент, который позволит учесть на стадии проектирования специфические потребности – например, убедиться, что главная нода для данных пользователя находится на том же континенте, что и пользователь, отделить текущие шарды от архивных и т.д.

  • Thorny path to the Large-Scale Graph Processing Зиновьев Алексей Викторович

    Основной материал тезисов и структура доклада представлены на английском языке в следующем GoogleDoc
    - https://docs.google.com/document/d/127gxD9__M_dm4hsXpA08eoqNWhiR3geIMEt_ME6HjZ0

    Однако, я хотел бы дать краткое описание основных идей

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

    Что делать, если объект вашего исследования это весь веб-граф Рунета, граф Твиттера, дорожная сеть Европейского союза или граф знаний Google? Как корректно и быстро вычислить диаметр графа, найти компоненты связности, найти кратчайшее расстояние между всеми вершинами или разрушить минимальное остовное дерево?

    Традиционная MapReduce парадигма не оправдывает себя при выполнении расчетов на больших графах. Большая часть современных фреймворков обработки графов построено на основе модели Bulk Synchronous Parallel, в том числе и знаменитые Pregel и Apache Giraph

    Дивный мир Graph Mining и Large-Scale Graph Processing приковывает к себе взгляды многих исследовательских компаний и увлеченных теорией графов программистов, вовлекая в процесс создания новых алгоритмов и открытых инструментов. Это увлекательная, но тернистая тропа. А дорогу, как известно, осилит идущий.

  • Множество IT проектов окончились в лучшем случае срывами сроков, а в худшем полными провалами, из-за того, что команды слепо следовали трендам, лучшим практикам и очередным "решит все ваши проблемы" технологиям. Я знаю это не понаслышке, т.к. сам был причиной ни одного такого провала. В условиях взрывного роста количества информации, которую разработчики должны поглощать, усложнения решаемых задач и обилия технологий, очень трудно не забыть о сути нашего ремесла - создании качественных решений для удовлетворения потребностей наших заказчиков, и не впасть в эйфорию, превратив работу в resume driven процесс. Я считаю, что эта проблема очень актуальна для нашей индустрии и очень важно обращать внимание сообщества не только на технологии, но и на психологические аспекты создания решений.

    Разрабатывая с нуля аналитическую систему безопасности для retail сектора в условиях ограниченных ресурсов и времени, мы были вынуждены пойти на множество компромиссов, чтобы сконцентрироваться на том, что действительно важно для нашей системы. Этот доклад делает акцент на процессе принятия решений и анализе влияния их последствий, нежели на подробном освещении деталей конкретных технологий, не минуя последних, впрочем. Система включает в себя near real-time мониторинг событий с касс, поиск патернов угроз в realtime потоке событий, корреляцию потока событий с устройств с видео потоком с камер наблюдений и инструменты для пост-анализа происшествий. Стек технологий, на котором в итоге был построен проект, включает в себя Ruby, EventMachine, Rails, RabbitMq, MySql, и немного неожиданно, ActiveX и .Net. Подробно рассмотрим почему мы остановились на EventMachine + Rails, а не написали все на Erlang, почему long-polling в нашем случае достаточен и почему не стали прикручивать WebSockets, как мы работаем с БД и почему мы не используем NoSQL базу, хотя модель данных позволяет, как мы интегрируем видео системы и почему не написали или не адаптировали видео сервер, и какого черта там делает .Net.

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

  • Первое условие успешного опыта взаимодействия пользователя с системой сейчас состоит в том, чтобы дать пользователям возможность начать её использовать как можно быстрее – до того, как они расстроятся и покинут сайт.

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

  • В рамках данного доклада мы подробно исследуем возможности MariaDB версии 10.0 - почему вы должны рассмотреть применение данной СУБД, какова она в сравнении с MySQL 5.6, и почему стоит задуматься о миграции на неё. В завершении доклада мы рассмотрим роадмап для MariaDB 10.1.

    Краткий обзор затрагиваемых тем:
    - улучшения репликации, в том числе репликации из нескольких источников, Global Transaction ID (GTID), и многое другое;
    - использование различных механизмов хранения для решения распространённых проблем;
    - расширения FusionIO;
    - улучшения для администраторов баз данных, связанные со статистикой использования памяти по потокам и т.д.;
    - enterprise-возможности MySQL, существующие в MariaDB: плагин PAM-аутентификации, пул потоков, плагин аудита;
    - доступность функций MariaDB 10.1.

    Примечание: бета-версия MariaDB 10.1 выйдет в октябре, как раз перед конференцией.

  • PostgreSQL: Ups, DevOps... Лесовский Алексей

    Когда админы были маленькими, а компьютеры большими, настройка нового
    сервера была сродни маленькому празднику. Сегодня настройка десятка
    серверов - рутина. Вручную уже лень, рано или поздно приходит мысль
    написать пару скриптов которые сделают всю работу сами. Через полдня
    появляется чудо скрипт. Начав, сложно остановится, через месяц
    скриптов уже двунадесять, через год уже никто точно не знает сколько и
    какие правильные. Автоматизация добралась до всех уголков
    инфраструктуры: настройка ОС, установка пакетов, развертывание
    app-серверов, деплой приложений, базы данных... Базы данных? Хм, базы
    данных, что-то здесь слишком много ручных операций, да и слишком
    критичная часть инфраструктуры, один неверный шаг и 15 лет растрела.

    Какие же задачи по обслуживанию баз данных все-таки можно и нужно
    автоматизировать, а какие нельзя ни в коем случае? Какие средства
    использовать, а от каких лучше держаться подальше? Где лучше взять
    готовое, а где написать свое? Все это, а также с каких практических
    шагов стоит начать автоматизацию вашей PostgreSQL-инфраструктуры, вы
    узнаете из доклада.

  • !sync: асинхронное взаимодействие Вячеслав Турчанинов

    Асинхронное взаимодействие. Выполняем только полезную работу, остальное - "не мое".

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

    Сопрограммы (coroutine). Вы все в монадку, а мы - в "корутинку".

    Странное поведение системы. Все встало колом? Вам кажется! Оно просто медленно работает.

    Я расскажу о том:

    - что общего у планировщика ОС, системных вызовов и асинхронного взаимодействия
    - как принципиально работает асинхронное взаимодействие
    - в каких условия асинхронное взаимодействие приносит пользу
    - какие условия являются достаточными для комфортной работы с асинхронным взаимодействием и в чем "профит" от сопрограмм (coroutine)
    - как можно "затупить" асинхронный сервер своими дополнениями или встраиваемыми сценариями (nginx, tarantool)
    - что делать, если "кусочек" кода не хочет быть асинхронным
    - что может пойти не так как казалось
    - как я работал с async на python и как сейчас

    В итоге должно немного "попустить" или "накрыть", но непременно в удовольствие.

  • Серверы вашей компании расположены по всему миру и вам необходимо обрабатывать данные в едином месте. Приложения с разными технологическими стеками генерируют данные в самых разных местах - от веб-серверов до датчиков. Как бы вы стали решать эту проблему? Врубайтесь в RabbitMQ!

    В ходе доклада мы покажем, как построить систему, которая может собирать данные, генерируемые в удаленных географических точках (вспоминайте AWS и кучу его регионов), и копировать их в центральный кластер, где они в дальнейшем будут обрабатываться и анализироваться.

    Мы представим пример построения подобной системы с использованием RabbitMQ Federation для копирования данных из регионов AWS и реализованной в RabbitMQ поддержки множества протоколов для производства и потребления данных.

    Будет показан интересный способ реализации шардированных очередей с применением RabbitMQ и Consistent Hash Exchange, которые помогут нам с масштабированием.

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

    Справка о RabbitMQ

    RabbitMQ - это совместимый с многими языками и протоколами сервер сообщений с клиентами для многих языков программирования, включая Ruby, node.js, Python, PHP, Erlang и многие другие.

    У брокера RabbitMQ очень активное Open Source сообщество с более чем 1000 связанных проектов на Github. Наименьшее среднемесячное число обращений в сообществе RabbitMQ превышает 700 сообщений в месяц, разработка происходит при непосредственном участии ключевых ​​разработчиков, что делает RabbitMQ брокером, который постоянно совершенствуется на основе обратной связи от пользователей.

    RabbitMQ помогает масштабироваться стартапам (Instagram), обеспечивает стабильную работу медийных компаний (The New York Times) и госучреждений (Национальная служба здравоохранения Великобритании) - и это лишь несколько примеров.

  • * Evolution: Business Intelligence, Big Data, Exploratory Data Analysis

    * Structured data analysis: logs, databases, tabular data

    * Unstructured data analysis: documents, web pages, email, resumes, chat sessions, and more
    * Language isn't important (English, Russian, Spanish - don't care)
    * Clustering
    * Applications

    * The tool box:
    * Python, R
    * Graph database (Neo4J, Titan, GraphX)
    * C
    * Minimum math

    * The Cosmify system:
    * Exploratory Data Analysis PaaS implementation
    * Servers: on-premises or cloud
    * Docker - simplifying deployment

    * Cosmify components:
    * Rover: document discovery (Python, AngularJS, Docker and native deployment onOS X, Linux, and Windows)
    * Orbiter: Web UI, API proxy, exploratory data analysis tools (Python, Tinker Pop, Docker)
    * Dark Matter: how we are able to move data to the cloud without encryption while maintaining confidentialy and meeting regulatory demands
    * Data exploration for others: Excel interface (C, ODBC interface)
    * Reactor:
    * Data exploration for programmers: IPython/Jupyter and RStudio integration (Python, R)
    * Data exploration for business analysts: drag-n-drop UI (AngularJS, D3.js) and proactive document generation (Dexy)

    * Nebula: a computational cloud
    * Nebula/cloud - Amazon Web Services, other cloud hosting
    * On premises: deploy your own cloud
    * Docker, Chef; computational logic: Python (NumPy, SciPy), R
    * GraphX - graph and column database
    * Build your own apps: leverage the Orbiter/Nebula RESTful API (Mule, RAML, Python/Jython, JSON)

    * Comparison against Databricks, Microsoft Azure Machine Learning, others

    * Q&A

    Presentation: 28 slides, approx. 45 minutes (Keynote, PDF)

  • В Circonus мы занимаемся сбором, хранением и анализом телеметрических данных. Измерения, измерения и ещё раз измерения. В рамках своего доклада я расскажу об эволюции нашей архитектуры данных и уроках, которые мы вынесли из практики масштабирования распределенного сбора и хранения телеметрии. Я буду говорить о переходе с PostgreSQL на собственное колоночное хранилище, а также о миграции с RabbitMQ на Fq. Во время доклада мы обсудим и некоторые неожиданные сценарии отказов.

  • Как мы считали трафик на Вертике Голов Николай Игоревич

    Компания Авито является одной из крупнейших интернет компаний РФ. Наш сайт регистрирует сотни млн. событий в сутки.
    Руководству необходима развернутая отчетность об интернет трафике, в том числе о количестве уникальных посетителей и сессий. Отчетность должна быть очень детализированной, точной, допускать разнообразный ad-hoc анализ.
    Главная проблема в расчете подобной аналитики - количество уникальных посетителей не аддитивно по иерархическим измерениям (география, продуктовый каталог и т.п.).
    Вертика отлично справляется с поддержкой аддитивных мер на десятках млрд. строк исходных данных, но когда возникла необходимость поддерживать не аддитивные меры, считающиеся по иерархическим измерениям, нам пришлось реализовать аналог алгоритма Map Reduce поверх SQL движка HP Vertica.
    HP Vertica самостоятельно справляется с горизонтальным партиционированием расчетов на узлы кластера, но для решения нашей задачи нам пришлось подсказать ей способ вертикального партиционирования на ядра серверов (многозадачность), а также - способ темпорального партиционирования . Только разбиение задачи по трем измерениям позволило добиться достаточной декомпозиции для эффективного и быстрого расчета.

  • Это вводный доклад про MongoDB: что такое документоориентированная БД, JSON, гибкая схема. Большую часть времени я отведу на привыкание к тому, что проектирование схемы с MongoDB отличается от старой доброй нормализованной реляционной схемы.

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

  • Данный доклад в формате мастер-класса охватывает следующие темы:

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

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

  • Система, на примере которой я хочу построить свой доклад, это система открутки контекстной рекламы. Она занимается ротацией объявлений рекламодателей, подсчетом показов и кликов по объявлениям. Входной поток данных - около 10 тысяч сообщений в секунду. Это клики, показы и прочие действия пользователей. На основании этого потока мы балансируем объявления рекламодателей, сообщаем об этом продуктам и считаем стоимость услуг.

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

    Реактивное программирование (http://www.reactivemanifesto.org/) это:
    — реакция на действия пользователей
    — реакция на отказы
    — реакция на нагрузку
    — событийность

    Мы взяли фреймворк Akka (http://akka.io/), которая реализует модель Акторов (http://en.wikipedia.org/wiki/Actor_model и привет из мира Erlang), который хорошо ложится на принципы реактивного программирования. Событийность реализуется за счёт сообщений. Акторы не знают друг о друге и могут находится на разных серверах (location transparency), это про нагрузки. У Актора есть супервизор, которые следит за актором и реагирует на его поломку.

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

    Сейчас на бою система работает на следующем стеке технологий: Scala, Akka, Spray, PostgreSQL, Nginx, Hadoop, Spark и Chef.

  • Впервые за последние четыре десятка лет в мире баз данных происходит что-то новое. Пять лет назад появилось множество так называемых NoSQL СУБД, которые были призваны справиться с Big Data.

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

    MongoDB является ведущей NoSQL СУБД. Сотни тысяч кластеров MongoDB используются в широком диапазоне организаций – от стартапов с JavaScript-архитектурами на стороне сервера до банковских и государственных структур с Java-стеками. В данном докладе будут исследованы 5 возможностей, которые позволяют MongoDB выделяться на фоне других NoSQL СУБД.

  • 100% HA. Да! Смирнов Дмитрий

    Как правильно построить HA на примере sdn.spb.ru - полный HA - от электропитания, резервной СКС до приложений. Это совершенно реально. Обсудим всё. Начнём с полов, размещения стоек, кабельной структуры, перейдём к bond, конфигурациям коммутации, потом обсудим балансировку ipvs, keepalived, спустимся ниже к real servers и плавно уйдём в backend. Обязательно рассмотрим сетевую файловую систему ceph, аналоги S3 и шифрование LibreS3, синхронизацию данных между дата центрами. А самое главное - в конце - как это всё можно масштабировать географически, ну на тот случай, когда в один из датацентров влетела бомба. Всё работает.

  • Как обслужить 60 миллионов абонентов? Руфанов Артем Владимирович

    ЦЕЛЬ.
    Реализация узла PCRF согласно 3GPP спецификации для обслуживания 60 миллионов абонентов оператора связи. Упрощенно PCRF – это приложение, которое принимает решение о скорости предоставления услуги абоненту. При принятии решения учитываются такие факторы, как тарифный план абонента с его опциями и турбо-кнопкой, его местоположение в сети, перегруженность сети и другие. К приложению предъявляются следующие требования: поддержка георезервирования, масштабирования, резервирования внутри одного дата-центра, а также работа в режиме 24/7, обеспечение скорости реакции близкой к real-time, обслуживание не менее 10k requests/sec на одном узле.

    РЕШЕНИЕ.
    Достижению цели способствовали архитектурные решения, которые обеспечили реализацию требований по масштабируемости и резервируемости, а также решения, связанные с проектированием (design), которые обеспечили реализацию требований производительности одного узла. Основные принятые архитектурные решения – это избыточность (redundancy) и поддержка ftlb-стратегий (fault tolerance & load balancing). Основные решения, связанные с проектированием (design), это парализация задач без единой точки синхронизации, создание кэша, разбитого на сегменты для отсутствия единой точки синхронизации, разнесение получения данных из сети и их декодирования по разным потокам, использование собственного менеджера памяти.

    Реализованное решение развернуто на 190 узлах в 14 дата центрах и успешно запущено с требуемой производительностью каждого узла. Более подробно о каждом решении и его влиянии на конечную систему будет рассказано на докладе.

  • Мы записываем и анализируем около 1 млрд событий в месяц, и эта цифра растет. Это данные с наших плееров, iOS приложения и сайта. С таким объемом любой сторонний сервис будет стоить очень дорого, при этом будет сильно ограничен по возможностям. Вот уже больше года как мы построили и успешно используем своё решение для анализа таких событий.

    Доклад про:
    – развитие архитектуры этой системы, как менялись и как будут меняться требования к такого рода системам
    – анализ подходящих под эту систему БД, с их проблемами, и опытом реальной эксплуатации
    – почему мы остановились на MongoDB, со всеми минусами и плюсами
    – немного про команду, трудозатраты и поддержку
    – как мы используем эту систему и как она помогает растить наши продукты

  • IT-структура для небольших компаний Юмашев Андрей Алексеевич

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

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

    Применив мультитенантность (multi-tenancy), можно спроектировать кластер MongoDB, более похожий на кластер Riak с хорошо распределенными операциями записи и некоторыми свойствами схем с несколькими участниками уровня master. Хотя это осуществимо в MongoDB, эту стратегию нельзя считать по-настоящему высокопроизводительной, поскольку экземпляры (instances), находящиеся на одной машине, будут бороться за системные ресурсы, и быстро появится «узкое место».

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

  • Postgres обладает уникальной способностью выступать эффективным агрегатором данных во многих центрах обработки данных. В данном докладе будет продемонстрировано, как расширяемость Postgres, доступ к иностранным источникам данных и способность обрабатывать NoSQL-подобные и связанные с хранением данных рабочие нагрузки дают PostgreSQL непревзойденные возможности для исполнения этой роли.

    Более подробно в презентации на английском: http://momjian.us/main/writings/pgsql/central.pdf

  • Если вы слышали о протоколе SPDY, то вас заинтересует опыт компании LinkedIn по внедрению SPDY на глобальном уровне.

    Протокол SPDY представляет собой улучшенную версию HTTP/1.1 (SPDY 3.1 принят за основу протокола HTTP/2.0). Протокол SPDY был разработан компанией Google и реализован в экспериментальной сборке браузера Chrome в 2011 году. За последние три года протокол был доведён до готовности, и в 2014 году компания LinkedIn начала внедрять SPDY в целях ускорения своих веб-приложений по всему миру. SPDY позволяет доставлять статический веб-контент значительно быстрее, чем протокол HTTP/1.1. Казалось бы, что переход на SPDY это только вопрос времени. Однако в реальности веб-контент кэшируется в сетях CDN, и для эффективного использования протоколу SPDY необходимо быть не только эффективнее HTTP/1.1, но и эффективнее сетей CDN. Таким образом, ответ на вопрос об эффективности SPDY оказывается совсем не простым.

    Из нашего доклада вы узнаете об архитектуре SPDY и типичных архитектурах CDN, а также о том, как мы интегрировали SPDY в LinkedIn, как мы оценивали эффективность нашего подхода, и какие сюрпризы нам преподнесла действительность.

  • С каждым годом веб-приложения становятся все сложнее и увеличиваются их возможности, с компьютеров они переходят на мобильные устройства, холодильники и даже часы. Уже нельзя просто полагаться на ручное(функциональное) тестирование чтобы проверить новый функционал и избежать неприятных багов. Даже юнит тестов на фронтэнд недостаточно, потому что часто ошибки возникают во время интеграции различных систем друг с другом. Ошибка недостаточной проверки совместимости может стоит огромных денег, достаточно вспомнить программу NASA "Mars Climate Orbiter"(https://ru.wikipedia.org/wiki/Mars_Climate_Orbiter), когда из за того что две команды разработчиков использовали разные единицы измерения была поставлена под вопрос вся программа изучения Марса. Конечно, мы не запускаем ракеты с помощью веба, но он прочно вошёл в нашу жизнь и мы часто зависим от того насколько стабильны те или иные приложения.

    Я расскажу зачем и почему нужно тестировать фронтэнд и что такое e2e тестирование. Покажу как это можно сделать при разработке на AngularJS (Karma& Protractor) и React (PhantomJS).

  • "Что там писать клиентское приложение - вот сервер, который выдерживает 10 тысяч запросов в секунду!"... "Да они там только API делают, вот бы хоть одно приложение под iOS написали!"

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

    * Как сделать так, чтобы клиент "не завалил" сервер?
    * Коммуникация ошибок от сервера к клиенту
    * Синхронизация, разрешение конфликтов
    * Работа в offline-режиме
    * Разработка эффективного и корректного API
    * Асинхронное взаимодействие
    * Почему клиент и сервер на самом деле очень похожи?

  • Sharding: patterns and antipatterns Константин Осипов (mail.ru, tarantool), Алексей Рыбак (badoo)

    Совместный доклад с Костей Осиповым. В черновом варианте: на примере опыта badoo и tarantool'а представим наиболее часто встречающиеся паттерны и анти-паттерны горизонтального масштабирования баз данных.

  • 1Hippeus - zerocopy messaging по законам Спарты Юрьев Леонид Валерьевич

    Миллиард в секунду – это к нам. Первая большая презентация проекта "волшебного транспорта".

    1Hippeus – инфраструктура обмена сообщениями, ориентированная на предельно эффективное zerocopy & lockfree взаимодействие через разделяемую память, RDMA, MPI, коммуникации с GPU, сетевыми адаптерами, SDN & NFV, гипервизоры.

    Грубо говоря, 1Hippeus позволяет вам сформировать и передать сообщение в соседний тред, в ядро или через гипервизор, в другой процесс или на другой сервер в кластере, с накладными расходами как при вызове функции. Это изменит парадигму взаимодействия, не так ли?

    1Hippeus is a AGPL/LGPL library, that act as framework and brings together:
    - zerocopy & lockfree message pump and streaming;
    - operation with shared memory in different address spaces;
    - 0mq, netmap, dpdk.org & Infiniband/MPI as non-local transports;
    - efficient representation for chains of memory blocks with C++ iterators;
    - buffers management and allocation;

    1Hippeus или One ippeuß – это всадник в войсках Спарты, подробнее http://www.biblestudytools.com/lexicons/greek/nas/hippeus.html
    Название выбрано с минимальным символизмом. Спарта – потому что все жестко. Один – как бы первый, чемпион и даже «один в поле воин». А еще саркастически можно называть «гипоконем», «гиппопотамом» или «конем в вакууме» ;)

    Цель 1Hippeus – предоставить предельно эффективную, но минималистскую инфраструктуру для обмена сообщениями в пределах физически единой RAM, а также в кластере посредством DMA/RDMA.

    Обмен в «физически единой RAM» включает варианты взаимодействия процессов в user-mode, модулей ядра, сопроцессоров (Tesla, Xeon-Phi), гостевых ОС в пределах одного гипервизора. А буквы DMA/RDMA подразумевают непосредственную стыковку с кольцом дескрипторов сетевой карты (NIC's DMA-RING) подобно Intel DPDK или Netmap.

    Может показаться, что подобные средства уже есть, но это не так. Картина сильно меняется если решать задачу действительно эффективно и рационально. Например:
    - MPI является ближайшим промышленным решением, однако даже в случае локального обмена производится копирование данных.
    - DPDK и Netmap просто дадут вам прямой доступ к очередям приема/передачи сетевых карт, но работать придется с сетевыми пакетами на самом низком уровне, включая (де)сериализацию данных.

    Со своей стороны 1Hippeus, ориентирован на предоставление интерфейса и механизма обмена сообщениями, плюс инфраструктуры их формирования. Причем так, чтобы объем накладных расходов при отправке сообщения был сопоставим с вызовом функции, вне зависимости от объема данных. Это делает 1Hippeus непохожим на другие решения.

    Но простой продуманный интерфейс позволяет получить больше. Например, под интерфейсный фасад 1Hippeus могут быть подведены другие средства обмена сообщениями, такие как MPI или 0MQ. Кроме этого, реализация транспорта может быть вынесена в отдельный процесс. При этом сохранится тот же минимум накладных расходов.

    B планах хотелось бы выделить обеспечение надежных соединений на основе собственных идей, реализованных когда-то в http://www.cronyx.ru/hardware/e1xl-ip.html. Суть в том, что вы задаете максимальную задержку в передаче данных, которую можете себе позволить, исходя из бизнес-логики. Со своей стороны, 1Hippeus либо поглотит все проблемы опорной сети без превышения заданного лимита, либо сообщит о проблеме. Другими словами, поведение транспортной подсистемы становится прозрачно-прогнозируемым и детерминированным, а вы можете балансировать между надежностью и скоростью «подкручивая» только один параметр.

    Остальная масса информации, включая как всё это устроено — на конференции.

    1) Зачем? Никто кроме нас?
    - суть идеи, кейсы применения и профит.
    - отличия от AMPQ/0MQ/MPI, наши рекорды в цифрах.
    - а еще...

    2) Почему? Концепт и его последствия.
    - сообщения как "просто" указатели.
    - интерфейс push/pull, очереди и транспортные помпы.
    - остальное за борт, ну почти.

    3) Как? Обзор дизайна и решений.
    - борьба между универсальной гибкостью и эффективностью.
    - итераторы, цепочки, разделяемые буфера, аллокаторы.
    - объекты в разделяемой памяти и проброс интерфейсов.

    4) Что дальше? Ближайшие шаги и планы развития.
    - интеграция с другими механизмами обмена сообщениями.
    - надежные соединения по мотивам http://www.cronyx.ru/hardware/e1xl-ip.html
    - больше контролируемого контроля, статистики и алертов.

    5) Присоединяйтесь!
    - почему AGPL?
    - открытие исходников на github.
    - обзор "правил" и процессов, gerrit, teamcity.

  • 1. перформанс - это вещь, фича или где?
    2. Что это - Load\Performance Testing, и какая в этом польза? А для меня?
    3. А причем тут девелоперы?!?
    3.1 Градусник - не лечит
    3.2 Как вы яхту назовете
    3.3 Быстро разрабатывать - мало
    3.5 Думайте шире
    4. троллинг со сторны зала

  • Не так давно перед нами возникла задача - мониторинг качества сетевых потоков от камер видео-наблюдения. Поскольку камер в Москве насчитывается уже больше 100 тысяч, объём анализируемого трафика составляет без малого десятки гигабит в секунду. Например, в одной из установок на нашу систему мониторинга заходит семь 10-гигабитных Ethernet линков, в сумме передающих около 45 гигабит в секунду видео-трафика.

    Как обеспечить объективный анализ такого количества информации?

    Предлагаю вниманию аудитории архитектурное решение на базе "традиционных" серверов и специализированных пробников, разработанных нашей командой в НТЦ Метротек.

    Пробники используют технологию ПЛИС (программируемые логические интегральные схемы), которая представляет интерес для разработчиков высоко-нагруженных систем, поскольку при правильном подходе позволяет гарантировать обработку всех данных (другими словами - 100% availability). Поэтому отдельное внимание будет уделено технологии использования ПЛИС в подобных системах.


  • Основная тема слайдов - аспекты разработки облачного решения на основе OpenSource компонент, со всеми проблемами, присущими такому подходу. Будут рассмотрены нюансы использования программного хранилища и программно-определяемой сети и упомянуты типичные, на наш взгляд, ошибки при проектировании системы подобного рода. Не в последнюю очередь будет рассказано о возможностях существующей инфраструктуры и о ее перспективах, а также о наиболее интересных направлениях самой индустрии - облачного хостинга, в приватном и в публичном сегментах.

    Нами был выбран путь, ведущий по пути масштабирования и разработки программной части облака, вместо обычного в подобных случаях использования ready-to-use решений, это же и позволило выстроить быструю, масштабируемую и отказоустойчивую систему на серверах commodity уровня (с использованием программного хранилища Ceph и программной сети на стандарте OpenFlow). Интеграция стеков подсистем виртуализации, хранения и управления трафиком позволяет заявить о себе, как о реализованной концепции software-defined datacenter.

    Построенная система обладает всеми достоинствами визионерских подходов к облаку - нулевой vendor lock-in во всех компонентах, начиная от виртуализации и заканчивая ОС агрегирующих свичей, централизованная схема управления трафиком, практически неограниченная линейная масштабируемость и минимальная стоимость владения при показателях производительности и отказоустойчивости на уровне промышленных проприетарных решений энтерпрайзного сегмента. При достижении этих целей мы встретили массу задач, как инженерного, так и архитектурного толка, наиболее интересным из них будет посвящена часть рассказа.

  • Хранимая кодогенерация в СУБД Oracle. Навроцкий Сергей Александрович

    В области ERP обновление железа увеличивает быстродействие в разы, обновление ПО — на
    порядок, обновление бизнес-процессов — на порядки.

    Рассмотрим второе — как писать высокоэффективный хранимый статический код, структуры
    хранения и представления, когда нам неизвестно, казалось бы, самое необходимое: все таблицы
    или представления окружающих систем, с которыми требуется взаимодействовать, и все атрибуты
    таблиц создаваемой системы. Как в угоду эффективности мы можем смешивать код с некоторыми
    данными, сохраняя «чистоту идеи», и как динамическому SQL придать полезные свойства
    статического.

    Мы поговорим о хранимой кодогенерации в СУБД Oracle на адаптированном шаблонном движке
    Freemarker.

  • Запуск MySQL на Linux Петр Зайцев

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

  • Я расскажу о нестандартном подходе к тестированию производительности систем. Что делать, если на вашу систему можно подавать только реальную нагрузку, которая имеет ярко выраженную сезонность, но мы должны уметь делать выводы о текущем запасе производительности, о том, как будет работать система на пределе возможностей и как проявится перегрузка? Как в таких условиях сравнить два релиза на одном стенде?
    Мы выделили входные и выходные метрики, наблюдаем за ними и сравниваем зависимости метрик друг от друга для каждого периода. Таким образом мы не только сравниваем релизы, но и обнаруживаем аномалии. В рассказе я упомяну полезные инструменты с открытым исходным кодом, которые мы используем в работе: ipython notebook, Graphite, Diamond, pandas и scikit-learn.

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

    До недавнего времени браузеры сами по себе были вполне конкретным приложением с поддержкой конечного и определенного производителем списка протоколов уровня приложения. Можно было HTTP(S) и иногда FTP. Кроме этого, были песочницы Java, Flash и прочего байткода, а также зоопарк браузерных расширений. Казалось бы, чего еще желать, но доставка браузерных расширений до конечного пользователя оказалось настолько колоссальной проблемой, что об нее разбивались целые компании.

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

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

    - Текстовый или бинарный протокол? Первичность данных.
    - Какая разница между схемой данных и IDL, какие они бывают и где могут жить? (Avro, Thrift, ProtoBufs, JSON, JsonSchema)
    - Немного о messages/events и streaming
    - Компрессия и оптимизация, что мы можем сжать, чем и когда. История упущенной мелочи.
    - Когда долетит серебряная пуля SCTP?
    - Как WebRTC распух в ожидании LLVM.

    Картинки, цифры и кейсы из нашего опыта идут в комплекте.

  • Правильная работа с индексами является ключевой составляющей производительности любой базы данных, и MySQL не исключение. Генеральный директор Percona Пётр Зайцев рассмотрит новые приёмы работы с индексами на базе улучшений оптимизатора MySQL 5.6.

    Вы узнаете:
    • как MySQL использует индексы для выполнения запроса;
    • как выработать оптимальную стратегию работы с индексами;
    • как понять, когда вам нужно добавить индекс;
    • как определить, какие индексы не нужны.

  • В течение многих лет классическая веб-архитектура включала серверы, рендерившие HTML посредством скриптов или языка приложений на стороне сервера. Однако сейчас веб во многом изменился: браузеры стали быстрее, интернет-соединения стали более стабильными и скоростными, кэширование улучшилось. Эти изменения подводят нас к сдвигу парадигмы - к рендерингу на стороне клиента. Эта новая архитектура позволяет серверам только поставлять данные, а разметка при этом кэшируется на клиенте или близко к нему, в результате чего достигается общее повышение производительности. Реальность Интернета такова, что не все пользователи обладают достаточно мощными компьютерами, устанавливают современные браузеры и используют достаточно быстрое интернет-соединение. Производительность страниц LinkedIn для этих пользователей требовалось как-то повысить.

    Из данного доклада вы узнаете, как мы интегрировали JS-движок в HTTP-прокси, какой опыт получили, добавив исполнение динамического языка на наш ключевой уровень прокси, как боролись с прекращением работы JavaScript и проблемами сборки мусора, и, наконец, как нам удалось ещё больше сократить время задержки.

  • Существует множество систем, решающих задачи по обработке структурированных Big Data. Но рынок диктует новые вызовы и сегодня актуальны нерешаемые раньше задачи класса OBD&A (Online Big Data &
    Analytics) для анализа неструктурированных данных в реальном времени.
    По версии Gartner одно из Топ-10 самых перспективных направлений в 2014г. - обработка в режиме реал-тайм данных социальных медиа.

    Последние сделки на рынке OBD&A выявили технологических лидеров и фактически оценили стоимости подобных разработок:
    - в декабре 2013г Apple купила американскую компанию TopSy, специализирующуюся на работе с Твиттером и близкий партнер Твиттера. По оценкам аналитиков, сумма сделки составила минимум $200 млн.;
    - в "отместку" в марте 2014г Twitter покупает другого лидера американского рынка - компанию Gnip. Точная сумма сделки остаётся неизвестной, но эксперты Wall Street Journal оценивают сделку в сумму не меньше $200 млн.

    Также на рынке присутствуют два «свободных» игрока - английская DataSift и разработка нашего "конгломерата" компаний – платформа iLook и система мониторинга и анализа соцмедиа Brand Analytics.

    HP Autonomy – мировой лидер рынка аналитических услуг, приобретена HP за $13 млрд. - заключило соглашение с обоими игроками: и DataSift и Brand Analytics.

    OBD&A - многомерная задача:
    • сбор: десятки-сотни миллионов документов в сутки, что предполагает тысячи документов в секунду;
    • хранение: десятки миллиардов разноформатных сообщений из всех видов соцмедиа;
    • полнотекстовая выборка с учетом лингвистики;
    • многопараметрическая реал-тайм обработка постов из Twitter, Facebook, ВКонтакте, YouTube, Instgram, тысяч сайтов, форумов и пр.

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

    - Распространение эпидемий: Анализ соцмедиа VS Анализ запросов Google Flu
    http://habrahabr.ru/company/palitrumlab/blog/200540/

    - Прогноз выборов в Венесуэле
    http://vox-populi.ru/venezuala.phtml

    - На языке футбола: Big Data + лингвистика для виджета по Чемпионату Мира
    http://habrahabr.ru/company/palitrumlab/blog/225985/

    - Прямая линия с Президентом РФ В.В.Путиным: Мониторинг динамики общественного мнения в социальных медиа
    http://vox-populi.ru/pl2013.phtml

    - Исследование эмоционального состояния пользователей социальных медиа:
    https://br-analytics.ru/blog/?p=1489

    В своем докладе мы расскажем, каким образом создавалась и модифицировалась архитектура нашей системы, как нам удалось разработать систему класса OBD&A для неструктурированных данных с использованием общедоступного ПО, и как мы решили масштабные задачи, имея в своем арсенале достаточно ограниченные ресурсы.

    Мы расскажем, как использовать MongoDB для управления огромным информационным массивом данных (более 10 млрд. документов), как «допилить» ElasticSearch, чтобы решить задачу полнотекстового поиска в высоконагруженных потоках данных и, возможно, удивим многих, рассказав, что основной язык программирования наших проектов – PHP.

  • Мы, веб-разработчики всегда ищем способы сокращения времени загрузки страницы. Но в один прекрасный день приходит продакт-менеджер и просит добавить новую функциональность, которая «точно принесёт много денег», но, разумеется, с её появлением сайт начнёт работать медленнее.

    Есть ли у вас необходимые данные, чтобы решить, стоит ли идти на такой компромисс? Достаточно ли будет тех пользователей, которые будут согласны ждать дольше при загрузке страницы, чтобы получить новую функциональность? Насколько терпеливы ваши пользователи сейчас, и сделают ли их новые возможности системы более или менее терпеливыми?

    В докладе будут освещены некоторые открытия, сделанные нами в ходе изучения поведения пользователей сайта Сочи 2014 во время Олимпийских Игр и других веб-сайтов.

  • Про SQL-инъекции все слышали и все знают как с ними бороться. Про noSQL-инъекции слышали почти все. Данный доклад посвящен совершенно новой теме - инъекциям в key-value хранилище memcached, про которые точно никто еще не слышал. Говорить о популярность memcached не приходится: twitter, wikipedia, youtube, livejournal и весь highload сегодня использует его.

    В докладе приводятся реальные уязвимости оберток (wrappers) для хранилища memcached, и практические примеры по исправлению таких уязвимостей на уровне кода приложения. Обнаружены уязвимости в 1 из 3 существующих оберток ("драйверов memcached", как их часто называют) для Ruby, 1/2 Python, 1/2 Java, 1/2 PHP, 1/1 Lua, 1/1 .NET, 0/1 Go. Уязвимости позволяют не только компрометировать данные в памяти, но и зачастую вызывать выполнение произвольного кода.

    Отдельная часть доклада затрагивает организацию безопасного хранения данных на основе ключей (namespaces, хеширование и проч.).

  • Git – это популярный и эффективный децентрализованный инструмент контроля версий (DVCS), по которому написано множество руководств и документов типа «лучшие практики» относительно рабочего процесса, которые помогают контролировать сложность, представлять историю и стимулируют командную работу в общем репозитории.

    В Tokutek мы разрабатываем продукты с множеством не связанных друг с другом компонентов, которые могут быть скомбинированы несколькими способами (TokuDB для MySQL и для MariaDB, TokuMX для приложений MongoDB, а также версии каждого продукта для сообщества и enterprise-версии с библиотекой экстренного горячего резервирования). Данный бинарный пакет может быть собран на основе независимых репозиториев git в количестве до 5, причём некоторые из них могут быть общими для нескольких продуктов. Мы разработали и опробовали методологии для управления сложностью, историей и командной работой, а также для поддержки надлежащего управления версиями и задач по построению релизов.

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

  • Tempesta FW: FrameWork и FireWall для WAF и DDoS mitigation Александр Крижановский

    Tempesta FW - это Open Source гибрид HTTP акселератора и фаервола, специально разработанный для предотвращения Application level DDoS и построения высокопроизводительных Web Application Firewalls (WAF). Проект работает на Synchronous Sockets - сокетном API, полностью встроенном в TCP/IP стек операционной системы, и использует самую быструю на данный момент реализацию конечного автомата разбора HTTP сообщений.

    Tempesta позволяет фильтровать трафик от 3го (IP) до 7го (HTTP) уровней, а для облегчения реализации кастомных модулей классификации трафика и реализации модулей типа ICAP предоставляет интерфейс Generic FSM, позволяющий переключать контексты разных машин состояний (например машины состояний для ICAP и для HTTP). В пакете уже есть простой DDoS mitigation фильтр.

    Проект прежде всего предназначен для построения сетей фильтрации, создания WAF и акселерации Web-приложений. Но функциональность принесена в жертву производительности. Так, например, Web кэш обязан помещаться в RAM.

  • Любой Web-сервис, занимающийся извлечением коммерческой прибыли, ведет
    учет заработанных денег в собственных хранилищах данных, которые
    зачастую создаются “с нуля”. Однако подавляющая часть программистов,
    занимающихся разработкой, не имеют понятия, как правильно работать с
    деньгами в базе. Взаимодействие с финансами - удел экономистов и
    бухгалтеров, а не инженеров, и основам бухучета никто “технарей” не
    обучает. Ни один здравомыслящий человек по собственной воле не возьмет
    в руки учебник по бухучету.

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


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

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

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

  • Чтобы разрабатывать быстро и качественно нужно иметь процесс разработки, который будет работать на достижение этих целей. Тема сама по себе избитая, однако в последнее время появилось много совершенно новых инструментов, которые позволяют работать ещё более эффективно. О том как в 2014 году разрабатывать проекты на ruby on rails я и расскажу в своём докладе.

    Подробно:
    В докладе будут раскрыты следующие темы:
    – процесс принятия нового кода;
    – управление задачами;
    – управление багами;
    – взаимодействие с переводчиками;
    – защита качества кода и управление техническим долгом;
    – превентивное обеспечение безопасности;
    – автоматизированное тестирование;
    – защита стиля кода;
    – управлениее стейджами и обеспечение простого тестирования фич перед релизом.

  • Software Defined Storage (SDS) – сейчас одно из самых модных направлений на рынке. В процессе работы над собственным хранилищем данных мы узнали много интересного (и ценного) об архитектурах SDS, чем и поделимся в докладе. Эти знания необходимы для правильного анализа производительности SDS, чтобы понимать, на каких уровнях работают кеши, почему “sync” – это очень дорогая операция, где могут быть ограничения, и что в действительности влияет на производительность. Подробно поговорим о самой методологии тестирования.
    Стоит еще отметить, что некоторые SDS решения в погоне за производительностью забывают о главном, ради чего они используются. SDS, в первую очередь, должны НАДЕЖНО ХРАНИТЬ данные. Поэтому мы обязательно затронем тему консистентности данных и надежности их хранения.

  • TokuDB - новый движок хранения данных для MySQL, Percona Server и MariaDB. TokuDB отличается использованием фрактальных деревьев вместо традиционных B-деревьев, что позволяет достичь очень высоких скоростей вставки и компресии.

    Данная презентация ориентирована на тех, у кого уже есть опыт использования MySQL и Innodb. Мы укажем на отличия в технологиях и объясним, в каких случаях TokuDB - хороший выбор, а в каких лучше остаться на Innodb. Что может показаться необычным и какие подводные камни стоит ожидать.

  • На сегодняшний день наиболее популярным алгоритмом сжатия отправляемых с веб-сервера данных является gzip. Но существует еще несколько новых направлений на которые стоит обратить внимание при отправке большого количества данных на нагруженных системах.

    Этот доклад будет посвящен новому протоколу сжатия данных SDCH (общий словарь сжатия для HTTP) http://groups.google.com/group/SDCH. Этот протокол мы экспериментально внедрили для статического англоязычного контента ( 7 тысяч javascript, 2 тысячи css файлов) в компании LinkedIn и результаты нас приятно удивили.

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

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

    Результаты:
    - В среднем на 30% уменьшился размер передаваемых данных по сравнению с Gzip.
    - Только файлы маленького размера проигрывают относительно Gzip.
    - Задержка для кодирования файла составила всего 400 микросекунд.
    - Уменьшилось время загрузки страниц, особенно при низкой пропускной способности сети и больших задержках.
    - Чем больше веб ресурс (чем больше файлов участвует в формировании словаря) тем лучше работает эта технология.

    Проблемы и как их решать:
    - генерация словаря может занимать продолжительное время (от нескольких часов до нескольких дней)
    - безопасность, какой контент стоит добавлять в словарь а какой нет
    - HTTPS vs HTTP
    - вопросы кэширования при использовании CDN
    - на данную минуту есть поддержка только в Chrome, Yandex Browser и в следующих версиях Safari.

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

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

    Вторую (более короткую) часть доклада я посвящу еще одной технологии для сжатия отправляемого трафика: библиотеке Google PageSpeed, расскажу как мы ее интегрировали в нашу среду высоконагруженную среду и какие результаты мы получили в итоге.

    PageSpeed ​​библиотеки представляют собой набор классов C++ для автоматической оптимизации веб-страниц и ресурсов. Библиотеки являются открытым исходным кодом.

    PageSpeed ​​ускоряет работу вашего сайта и уменьшает время загрузки страницы. Это модуль веб-сервера, который автоматически применяет передовой опыт для увеличения производительности на страницах и связанных с ними ресурсов (CSS, JavaScript, изображения), не требуя изменения существующего контента. Разница в этом подходе по сравнению с первой частью доклада в том, что для использования PageSpeed в большинстве случаев не нужно какойто большой имплементации и изменения кода на сервере.

    Результаты:
    - Этот подход мы использовали для удаления пробелов и минификации javascript на всех наших html страницах. Что позволило уменьшить обьем html данных в среднем на 20%.
    - задержка при обработке html страницы составляет в среднем 15-20 миллисекунд.

    Мы успешно используем оба этих подхода на наших серверах и хотим поделится нашим опытом с вами.

  • CREATE INDEX … USING VODKA. VODKA CONNECTING INDEXES. Олег Бартунов, Александр Коротков

    Встроенная поддержка json в PostgreSQL- это уже свершившийся факт, который каждый может осознать, установив версию 9.4. Новый тип данных jsonb имеет эффективное бинарное хранилище, что делает доступ к нему в десятки раз быстрее текстового типа json, а индексная поддержка поисковых операторов jsonb приводит к их тысячекратному ускорению, что делает PostgreSQL серьезным конкурентом MongoDB - признанному лидеру мира NoSQL баз данных. Действительно, несмотря на успех NoSQL (активно распиаренный использованием в некоторых популярных интернет-проектах), многие пользователи не готовы приносить в жертву целостность данных в угоду масштабируемости, но хотят иметь гибкость схемы данных в проверенных и надежных реляционных СУБД. Темпы роста компьютерной индустрии (процессоры, дисковые подсистемы и сетевые устройства) позволяют большому количеству проектов успешно функционировать на одном сервере и не требовать горизонтальной масштабируемости NoSQL. Более того, при правильном проектировании архитектуры приложения возможно добиться горизонтальной масштабируемости реляционной СУБД, что подтверждает пример Instagram с использованием открытой реляционной СУБД PostgreSQL.

    Однако, чтобы всерьез конкурировать с NoSQL, необходимо иметь богатый язык запросов к json данным, подкрепленный индексами. Мы расскажем про несколько новых проектов, которые ведутся нами в этом направлении. Первый проект - это язык запросов jsquery, который обладает выразительной мощью достаточной для конструирования сложных запросов и понятным синтаксисом. Надо сказать, что какого-то принятого стандарта на язык запросов для json нет, а существующий “зоопарк” языков не удовлетворил нашему представлению о целесообразном и прекрасном, так что мы разработали язык запросов самостоятельно.

    Вот так выглядит запрос на языке запросов MongoDB:

    db.reviews.fnd( { $and :[ {similar_product_ids: { $in ["B000089778"]}}, {product_sales_rank:{$gt:10000, $lt:20000}}] } ).count()

    А вот так этот же запрос можно записать на нашем jsquery:

    SELECT count(*) FROM jr WHERE jr @@ ' similar_product_ids &&
    ["B000089778"] & product_sales_rank( $ > 10000 & $ < 20000)'

    Операторы языка получили индексную поддержку на основе обобщенного обратного индекса (GIN). Примечательно, что язык запросов jsquery можно скачать и использовать с PostgreSQL 9.4, то есть, уже сейчас !

    Следующий проект носит исследовательский характер, но мы ожидаем от него серьезных результатов. В процессе работы над jsquery и индексами, мы поняли проблемы и ограничения существующих индексных методов доступа и поэтому придумали новый индекс – VODKA ! Рассмотрим один мотивирующий пример. Природа json такова, что пути в json-объекте могут быть достаточно длинными, особенно при большой вложенности. Использование B-tree для их индексации не подходит, так как получится очень большой индекс, сравнимый с размером данных. При индексировании этих путей с помощью GIN в проекте jsquery мы используем хеширование, блюм фильтры для компактного хранения ключей. Этот подход работает, но имеет целый ряд проблем и ограничений, связанный, например, с неточным (lossy) представлением ключей. Для компактного хранения ключей “как есть” можно использовать radix-tree (цифровое дерево), так как пути (ключи) имеют общие индексы. В то же время, GIN индекс очень компактно хранит дубликаты, поэтому появилась идея использования radix-tree вместо btree для хранения ключей, а если обобщить эту идею на подключение произвольного поискового дерева для хранение ключей, то мы получаем новый тип индекса VODKA. Эти произвольные поисковые деревья могут быть реализованы с помощью других типов индексов, например, radix-tree реализуется с помощью SP-GiST. В случае с индексированием json, с помощью VODKA удалось создать компактный индекс, поддерживающий при этом произвольные запросы по ключам json-объекта. VODKA также может быть полезна для индексирования пространственных объектов: один протяжённый объект можно апроксимировать несколькими прямоугольниками. Этим достигается большая точность апроксимации, а в конечном счёте и большая скорость поиска. Кроме этого с помощью VODKA можно строить специальные структуры данных, ускоряющие смешанные запросы: например, запрос сочетающий в себе полнотекстовое и пространственное условия. Пример: "найти ближайшие рестораны, в описании которых содержится VODKA". Еще одно ограничение PostgreSQL на композитные индексы может быть снято с помощью VODKA – это невозможность использования разных типов индексов для разных колонок. Более того, с помощью VODKA можно обеспечить построение композитных индексов для тех методов доступа, которые принципиально их не поддерживают, например, SP-GiST, hash.

    Надеемся, что теперь название доклада становится понятным: VODKA CONNECTING INDEXES !

  • In this presentation, Konstantin Gredeskoul will tell the story of how Wanelo grew their application to 3K requests/second in just a few months, while keeping latency low, and tackling each new growth challenge that came their way. Konstantin will break down the approach into a 12-step program for scaling applications atop PostgreSQL. The talk will cover topics ranging from traditional slow query optimization and vertical and horizontal sharding to serialized writes, or using services to abstract scalability concerns.

    With PostgreSQL 9.2 and 9.3 as the primary data store and Joyent Public Cloud as their hosting environment, the team at Wanelo optimized their application stack over and over again using an iterative approach.

  • Как PostgreSQL работает с диском? Илья Космодемьянский

    Диски, память, цена, процессор - в таком порядке смотрят на
    характеристики сервера админы, покупающие машину под базу данных. Как
    эти характеристики взаимосвязанны? Почему именно они?

    Для чего нужен диск базе данных вообще. Как с диском взаимодействует
    PostgreSQL и в чем его особенности по сравнению с другими базами.

    Железо, настройки операционной системы, файловой системы и PostgreSQL:
    как и почему выбрать хороший setup, что делать, если конфигурация
    железа не оптимальна и какие ошибки могут сделать бесполезным самый
    дорогой raid-контроллер. Увлекательное путешествие в мир батареек,
    грязных и чистых страниц, хороших и плохих SSD-дисков, покрасневших
    графиков мониторинга и ночных кошмаров системных администраторов.

  • В последние годы на рынке появилось много решений хранения данных на технологии Flash. Это разнообразие сложно и даже коварно - неверно выбрав решение, можно столкнуться с неожиданными проблемами производительности, а то и просто потерять базу данных.

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

Стартуем HighLoad++ 2014

Сезон подготовки к восьмой профессиональной конференции разработчиков высоконагруженных систем HighLoad++ объявляем открытым!

Вот статистика роста количества участников HL++ за последние три года.

В этом году мы ставим планку в ДВЕ ТЫСЯЧИ участников! Попробуем сделать самую крупную не только в России, но и в Европе профессиональную IT-конференцию. Вы с нами? :)

Конференция пройдет в Москве, ориентировочные даты - 31 октября и 1 ноября. Количество потоков — 3 или 4, количество докладов, традиционно отобранных нашим самым жёстким Программным комитетом — около 80.

Тематика конференции остаётся той же — всё, что так или иначе входит в сферу интересов элиты программистов - разработчиков высоконагруженных, масштабных и сложных проектов: базы данных и системы хранения, масштабируемые архитектуры, видео, системное администрирование, поиск, тестирование, cмежные технологии.

Варианты участия

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

Заявки на доклады принимаются в личном кабинете. Чем раньше Вы подадите заявку, тем больше внимания от Программного комитета и активистов вы получите, тем лучше будет доклад, тем больше вероятность того, что он пройдёт в Программу. Что, кстати, вовсе не так очевидно — средний конкурс докладов у нас 4-5 заявок на место.

Там же, в личном кабинете, можно и заказать билеты. Текущая цена — 17 000 рублей.

Не откладывайте покупку, тем более, если у Вас большая группа участников :)

Итак, старт дан, начинаем подготовку.
Удачи и до встречи на Конференции!

Для участников

Рекомендации по размещению иногородних участников
Иногородние участники конференции разработчиков высоконагруженных систем HighLoad++ 2014 могут получить скидки на размещение в отеле Crowne Plaza Moscow WTC при переходе по данной ссылке.
Тематика конференции
Темы выступлений — все аспекты разработки и поддержки высоконагруженных систем: проектирование, алгоритмы, разработка, тестирование, архитектура, базы данных, системы хранения, поддержка, системное администрирование, железо, хостинг, управление. Все через призму больших проектов, высоких нагрузок: сотни тысяч пользователей, десятки миллионов хитов, десятки гигабайт данных, терабайты трафика.
Стоимость участия
Цена участия в конференции зависит от даты оплаты — она будет меняться от 13 000 до 24 000 рублей. В стоимость входит питание, раздаточный материал и право посещения двух дней конференции.
Место проведения конференции
В 2014 году конференция пройдет в Москве в "Центре Международной Торговли" на Красной Пресне 31 октября и 1 ноября. Продолжительность — два полных дня. Первый доклад начинается ежедневно в 10:00, а последний заканчивается в районе 18:00. Регистрация открывается в 9:00 утра.
Купить билет Подать доклад

Новости

Архитектура, способная обслужить 60 миллионов абонентов, на HighLoad++ 2014!
Доклад о приложении в инфраструктуре оператора связи, работающем близко к real-time и имеющем ряд спецтребований, от эксперта компании "Петер-Сервис" Артёма Руфанова.
Пётр Зайцев снова на HighLoad++: целых 5 докладов от ведущего эксперта по MySQL вам на выбор!
Наш постоянный докладчик Пётр Зайцев из года в год собирает полные залы заинтересованных слушателей. Посмотрите, какие темы он предложил нам в этом году, и вы сразу поймёте почему. Голосуйте за лучшие доклады - мы это учтём!
Открытая встреча докладчиков HighLoad++ 2014: мы хотим узнать, что вам интересно!
Ждём вас 7 августа в Москве! Не упустите свой шанс сделать конференцию HighLoad++ 2014 максимально интересной и полезной лично для вас - завтра в 19:00 в офисе компании Mail.Ru мы собираем Программный комитет, докладчиков и всех неравнодушных!
6 преимуществ HighLoad++ 2014: как мы собираемся собрать 2000 слушателей?
Бесплатные мастер-классы, консультации экспертов и не только: обещаем вам столько всего интересного и полезного, что вы едва сможете унести :)
Новая западная звезда на HighLoad++ и важная информация для докладчиков
Глава Circonus Тео Шлосснейгл (Theo Schlossnagle) снова обещал быть на HighLoad++, а ещё мы организуем открытую встречу докладчиков уже через неделю!
Паттерны и антипаттерны шардинга от экспертов на HighLoad++ 2014!
Алексей Рыбак и Константин Осипов расскажут о горизонтальном масштабировании буквально всё - секретов не останется!
Глубокое погружение в RabbitMQ на HighLoad++ 2014
Наш постоянный докладчик Альваро Видела (Alvaro Videla) готов рассказать, как правильно "готовить" всем знакомого "кролика", если нужна распределенная система сбора данных из разных географических точек. Ну, и ещё кое-что новое о формате HighLoad++ в этом году!
Производительность фронтенда или «Что вы знаете об антишквале?»
Вы можете подать доклад в новую секцию "Производительность фронтенда", как это уже сделал Филип Теллис (Philip Tellis), один из ведущих западных специалистов в этой области. Кстати, ему есть что рассказать о поведении пользователей сайта Сочи 2014! Интересно? Нам тоже!
Империя PostgreSQL наносит ответный удар
Доклады о MongoDB не остались незамеченными. У нас уже 5 заявок от Олега Бартунова, Александра Короткова, Ильи Космодемьянского и Брюса Момджяна (Bruce Momjian) - страсти накаляются! Но самое интересное будет на HighLoad++, разбирайте последние билеты по 13 000 рублей!
Погружение в MongoDB: о чём хотят рассказать Leif Walsh и Henrik Ingo?
Западные докладчики HL++ радуют нас: заявок столько, что придётся устраивать конкурсный отбор! Хотите поучаствовать? Голосуйте за самые интересные (и самые спорные!) доклады по MongoDB!

Информационная поддержка

  • SQLInfo.ru
  • Интернет Хостинг Центр
По любым вопросам обращайтесь:
Программный комитет :
Олег Бунин , +7 (916) 635-95-84
Бухгалтерия и вопросы оплаты :
, +7(495) 646-07-68
Организационный комитет :
, +7 (495) 646-07-68
Горячая линия :
+7 (495) 646-07-68, ежедневно с 10 до 22

Почтовый адрес:
119180, Москва, Бродников пер., д. 7 стр. 1, +7 (495) 646-07-68 ООО «Онтико»

Rambler's Top100
Рейтинг@Mail.ru