HighLoad++

Заявки на доклады:
  • Как известно, что не измеряется, то нельзя улучшить. И если про замеры на бэкенде (сколько времени выполняются запросы к базе, как быстро генерируется страницы, сколько запросов в секунду может обрабатывать веб-сервер) знают и выполняют их почти все разработчики, то client side производительности незаслуженно уделяется значительно меньше внимания. Быстрый ли DNS, хороший ли канал у хостера, закэширована ли статика, не перегружен ли сайт javascript'ом - все это помогает оценить Navigation timing API.

    В докладе мы расскажем о том, как делали систему аналитики, основанную на Navigation timing API, для десятков тысяч сайтов:

    - Как сделать подобную систему за 1 месяц и $1000, используя в Amazon Web Services (AWS) Kinesis и DynamoDB.
    - Как быстро (очень быстро!) принимать миллионы хитов с помощью Nginx+Lua.
    - Как в реальном времени обрабатывать миллионы хитов, постоянно агрегируя данные (потоковая обработка BigData... без хранения BigData).

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

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

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

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

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

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

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

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

    Многие без оглядки бросаются в омут Neo4j и других графовых баз данных, кто-то изобретает свои способы компактного хранения графа в оперативной памяти, а некоторые прибегают к мощи парадигмы MapReduce.

    Традиционная 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.

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

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

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

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

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

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

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

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

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

  • Openstack - это система, в которой все работает, но ничто не работает хорошо. Объектное хранилище Swift - не исключение в этом вопросе. Установленный у провайдера, Swift должен верой и правдой служить разным высоким нагрузкам. Под вечер с него забирает десятки гигабит контента CDN, а глубокой ночью он принимает резервные копии, которые любят делаться по cron-у одновременно.

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

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

  • • Эволюция: бизнес-аналитика, Big Data, разведочный анализ данных.

    • Анализ структурированных данных: логов, баз данных, табличных данных.

    • Анализ неструктурированных данных: документов, веб-страниц, электронных писем, резюме, записей чатов, и т.д.
    o Язык не важен (английский, русский, испанский - безразлично)
    o Выделение кластеров с общими признаками.
    o Приложения.

    • Наш стек:
    o Python, R
    o графовая база данных (Neo4J, Titan, GraphX)
    o C
    o Наименьшее значение (минимальный элемент)

    • Система Cosmify:
    o PaaS-реализация разведочного анализа данных.
    o Серверы: локальные центр обработки данных или в облаке.
    o Docker для упрощения развертывания.

    • Компоненты Cosmify:
    o Rover/Проводник: обнаружение документов (Python, AngularJS, Docker и встроенное развертывание на OS X, Linux и Windows).
    o Orbiter/Спутник: веб-интерфейс, прикладной программный интерфейс (API) прокси-сервера, инструменты разведочного анализа данных (Python, Tinker Pop, Docker).
    o Dark Matter/Тёмная Материя: как мы перемещаем данные в облако без шифрования, сохраняя конфиденциальность и соблюдая закон о защите персональных данных.
    o Применение разведочного анализа данных для других целей: интерфейс Excel (C, интерфейс ODBC).

    • Reactor/Атомный Котел:
    o Разведочный анализ данных для программистов: интеграция IPython/Jupyter и RStudio (Python, R).
    o Разведочный анализ данных для бизнес-аналитиков: интерфейс пользователя с возможностью перетаскивания элементов (AngularJS, D3.js) и автоматическая генерация документов (Dexy).

    • Nebula/Туманность: облако для вычислений.
    o Nebula/облако – Amazon Web Services, другой облачный хостинг.
    o Локальное решение: разверните свое облако.
    o Docker, Chef; логика вычислений: Python (NumPy, SciPy), R
    o GraphX - графовая и колоночная база данных
    o Создаем свое собственное приложение: RESTful API для Orbiter/Nebula (Mule, RAML, Python/Jython, JSON).

    • Сравнение с Databricks, машинным обучением Microsoft Azure и т.д.

    • Вопросы и ответы.

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

  • Это вводный доклад про 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 СУБД.

  • Все реально существующие сети время от времени могут выходить из строя, тем более при высокой нагрузке. Выход из строя - явление достаточно распространенное, но устойчивость к партиционированию в распределенной системе обеспечивается не так часто. Несмотря на то, что устойчивость к партиционированию является неотъемлемой частью теоремы Брюера (или теоремы САР), распределенные системы, даже спроектированные с учётом реализации 'P' (Partition tolerance – устойчивость к партиционированию) в CAP, не обеспечивают её в достаточной степени и недостаточно детерминированы. К сожалению, это не исключительные случаи, а обычная практика, согласно последним исследованиям [1].

    Galera [2] дополняет MySQL/PXC (подсистему хранения данных Percona XtraDB Cluster)[3] синхронной репликацией благодаря API wsrep репликации. Синхронная репликация требует не только кворума, но и получения согласованного результата. В среде с помехами задержка получения согласованного результата может привести к замедлению фиксации транзакций, следовательно, и к значительной задержке или даже к разделению сети на многочисленные вторичные компоненты и единичный первичный компонент (при условии, что это возможно). Таким образом, обеспечение устойчивости к партиционированию является не просто желательным, а основным требованием.

    Данный доклад касается тестирования устойчивости системы Galera к партиционированию. Docker и Netem/tc (управление трафиком) играет значительную роль в данном случае. Модуль Netem важен для эмуляции случаев выхода из строя – потеря пакетов данных, задержка, повреждение, дублирование пакетов, изменение порядка и др., а также для моделирования таблиц распределения, отражающих задержки канала связи, таких как распределение Парето, paretonormal, uniform (равномерное распределение) и т.д. Docker и контейнеры в целом необходимы для моделирования многочисленных нод, которые могут создаваться в реальном времени (во время работы приложения), легко запускаться и отключаться, иметь сети и потоки, которые просты в настройке при необходимости, обеспечивать горизонтальное масштабирование; если производительность также учитывается в ситуации выбора между контейнерами и полной виртуализацией и др. Утилита Sysbench OLTP используется для эмулирования нагрузки, хотя в данном случае возможно использование RQG (генератора случайных запросов) для расширенного fuzz testing (фаззинга).

    Будут рассмотрены основные результаты исследований.
    * Применение коэффициентов потерь с распознаванием сегментов WAN для виртуальных сетевых интерфейсов.
    * Разные периоды синхронизации после устранения помех в сети.
    * Потеря многих нод с кратковременным всплеском помех против потери одной ноды и более длительных помех.
    * Полнодуплексная связь контейнеров с dnsmasq.
    * Влияние внесетевых факторов – таких, как скорость работы дисков, – на fsync.
    * Распределение запросов по нодам по алгоритму round-robin при наличии/без нод с отказами сети в цепи.
    * Горизонтальное масштабирование тестовых нод и проблемы с Docker/namespace.

    В заключительной части доклада будут обсуждаться все детали тестирования Galera на устойчивость к партиционированию с помощью Docker и Netem. Также будут охвачены схожие инструменты/фреймворки, такие как jespen [4]. Более того, будет приведено сравнение Galera/EVS (расширенная виртуальная синхронизация) с другими протоколами обеспечения согласованного результата – например, Paxos, Raft и др. В конце будут освещены результаты тестирования – дополнение auto_evict к Galera.

    [1] https://queue.acm.org/detail.cfm?id=2655736
    [2] http://galeracluster.com/products/
    [3] http://www.percona.com/software/percona-xtradb-cluster
    [4] https://github.com/aphyr/jepsen

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

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

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

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

  • Web scale бэкапы для MySQL Алексей Копытов

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

    - mysqldump, mylvmbackup, XtraBackup или коммерческие решения?
    - оптимизация бэкапов больших объёмов данных
    - проблемы блокировок сервера во время создания бэкапа
    - проблемы большого количества таблиц
    - эффективное создание инкрементальных бэкапов
    - эффективное создание частичных бэкапов и частичное восстановление
    - проверка целостности бэкапов на больших объёмах данных
    - хранение бэкапов в "облаках"

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

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

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

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

  • Цель моей презентации – анализ и решение сложных задач с применением Big Data, определение 6 технических характеристик (объем, разнородность, скорость, достоверность, визуализация и ценность), а также представление функций, аналитических приложений и практических принципов.
    В начале презентации я обозначу принципы классификации Big Data при помощи определений логической структуры уровней и компонентов решений Big Data, которые можно применять в повседневной работе. Далее я объясню, как освоить паттерны решений Big Data, а также расскажу о выборе и использовании решений Big Data в приложениях реального времени. Будут даны рекомендации относительно выбора подходящих языков и (или) технологий программирования для реализации Big Data Solutions, в зависимости от задач и типов данных. Пример: данные веб-страниц и данные страниц в социальных сетях, данные, генерируемые человеком, данные транзакций и т.д.
    В заключительной части доклада я объясню, как оценить данные и получить четкую картину на основании источника данных, используемых параметров, типа, частоты доступности, размера, методологии обработки и технических средств. Пример: анализ различных типов данных –анализируемые источники данных и аналитические выводы, полученные путем исследования документов, бизнес-транзакций, электронных писем, изображений, показаний датчиков и данных устройств, индексирования в поисковых системах, блогов, социальных сетей и т.д.

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

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

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

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

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

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

  • Мы в Mail.Ru Group используем
    таск-трекер JIRA,
    базу знаний Confluence,
    инструмент планирования и контроля работы Greenhopper,
    модуль тестирования Zephyr,
    инструменты слежения за изменениями и ревью кода Fisheye и Crucible,
    построение графиков и диаграмм Gliffy,
    систему непрерывной интеграции Bamboo.

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

    Вторая часть доклада будет посвещена расширяемости JIRA, рассказу о том, что можно сделать с помощью её системы плагинов. Представлю наш собственный плагин jira-agent - написанная нами система онлайн-оповещения о новых событиях (плагин бесплатно доступен через Atlassian Marketplace). Приведу примеры тех плагинов, которые решают наши уникальные задачи и не могут быть использованы кем-то ещё, но которые демонстрируют разнообразие возможностей системы.

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

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

    Справочно, служба поддержки Atlassian считает нашу инсталляцию JIRA самой сложной в мире по количеству плагинов. Количество настроенных проектов в данный момент более двухсот.

  • Легко и просто живётся проектам, у которых есть Заказчик. Он выступает в роли третейского судьи: "это удобно, это неудобно, а вот эту кнопочку надо подвинуть". В многопользовательских сервисах, рассчитанных на широкий рынок, всё значительно сложнее:
    * Один пользователь попросил что-то поменять, а второй сразу же пожаловался на изменение
    * Профиль целевой аудитории создать сложно, т.к. все посетители разные
    * Техподдержку отвлекают на проблемы, которые оказываются вызваны простым непониманием продукта.
    Как результат, вам начинает казаться, что ваш продукт НЕУДОБНЫЙ, и при попытке сделать удобно ВСЕМ, получилось лоскутное одеяло и не удобно НИКОМУ.

    В этом докладе я хочу рассказать о способах работы над юзабилити в многопользовательских сервисах, и о тестировании удобства с учётом разных пользовательских групп:
    * Как обеспечивать консистентность разрабатываемого интерфейса
    * Как проводить тестирование на разных целевых аудиториях
    * Как заполучить фанатов вашего продукта, которые будут им публично восхищаться?
    * Как стандартизировать и измерить юзабилити?
    * Как оценивать необходимость внедрения тех или иных решений?

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

  • Real-time bidding требует real-time аналитики. RuTarget обрабатывает миллиард запросов на показ баннеров в день. Как определить, например, сколько в этих запросах уникальных пользователей? На пальцах расскажем о рандомизированных алгоритмах потоковой обработки данных, вероятностных структурах данных и объясним, как быстро и вычислительно дешево получить нужный результат.

    Основные тезисы:
    1)Какие данные у нас есть, и почему их много?
    2) Tradeoff: точность vs нагрузка на инфраструктуру
    3) Вероятностные структуры данных для data mining - что такое?
    4) HyperLogLog - метод подсчета числа уникальных элементов в потоке данных
    5) Large scale, временное окно
    6) Примеры из реальной жизни
    7) Count-Min, Summary-Sketch, и т.д.

    Как вариант можем рассказать в формате блиц (5 минут):
    1) есть огромный поток данных о бидах
    2) нужно считать статистику
    3) как?
    4) расскажем на пальцах про HyperLogLog

  • 1) Как мы начали работать по системе "4 уровня контроля качества" (и почему это круто)
    2) Какие у нас были сомнения и как мы привыкли
    3) Как мы работаем без багов и QA
    4) Пример из реальной разработки
    5) Как мы приучаем к системе новых сотрудников

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

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

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

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

  • Реклама со скоростью света или Как научить DMP платформу обрабатывать 100% входящих запросов.
    Докладчик – Сергей Жемжицкий, CTO CleverDATA
    Тайминг – 60 мин.
    Вводная часть 5-7 мин.
    1. Коротко о компании CleverDATA (в составе ГК ЛАНИТ)
    - Как возникла компания;
    - Какие задачи и для кого решаем;
    - Цели компании.
    Теория 5 мин.
    2. О Real Time Bidding (RTB)
    - Краткий экскурс в мир RTB;
    - Чем RTB отличается от обычной продажи рекламных интернет-площадок;
    - Участники RTB;
    - Требования по производительности к RTB-участникам (десятки тысяч сообщений в секунду с latency < 10-20ms).
    3. Что такое Data Management Platform (DMP)
    - Что происходит внутри DMP;
    - Из каких компонентов состоит DMP;
    - Как происходит обработка данных внутри DMP.
    Описание реализованного проекта
    4. Бизнес задача
    - проблема клиента - на ~20% запросов на показ рекламы не успевали выставляться ставки;
    - необходимость снижения стоимости владения инфраструктурой (кол-во серверов снижено на 75%).
    5. Техническая задача
    - Обеспечить время отклика 20ms при 10K запросов в секунду
    - Отрабатывать 100% входящих запросов (выполнена)
    6. Трудность выбора NoSQL (приводим таблицы по производительности от Aerospike),
    - Aerospike vs Mongo (без учета производительности, только функиональные требования)
    - Aerospike vs Redis (без учета производительности, только функиональные требования)
    7. Архитектура и возможности Aerospike
    8. Архитектура и составляющие части DMP Front-End
    - Выбор компонент - принятые решения и результат их принятия
    - Архитектура приложения
    - Асинхронное I/O
    9. Производительность решения
    - Сравнение с Mongo
    - Сравнение с Redis
    - Официальные данные Aerospike
    10. Результаты
    - business & technical value;
    - что следует иметь ввиду при разработке высокопроизводительных решений (разбор полетов);
    - асинхронность;
    - Memory Pools.
    11. Вопросы&Ответы

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

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

  • Для нас CD — это когда менеджер или релиз-менеджер с помощью одной «кнопки» может выкатить весь продукт на бой. При высокой связности, распределённости продукта и всех проверках выполнить такую задачу не просто и не быстро.

    На примере Справочного API 2ГИС я расскажу как мы сделали для менеджеров эту «кнопку». Расскажу про workflow, как мы используем для сборки Jenkins, для администрирования релиза Rundeck, для нагрузок Яндек.Танк, Chef для конфигурирования серверов.

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

  • Юлмарт. История создания. Дмитрий Завалишин

    Дмитрий Завалишин (экс-начальник отдела разработки портала компании Яндекс, создатель Яндекс.Маркета, в настоящее время генеральный директор группы компаний DZ Systems) расскажет историю создания web-платформы крупнейшего в России электронного кибермаркета. Бизнес-задачи, методика управления проектом и взаимодействие с заказчиком, проблемы интеграции, архитектура, и другие детали этого проекта федерального масштаба.

  • Data mining in the Nutshell Андрей Синицын

    1. Нужна ли программисту математика?
    - Общий обзор науки о данных
    -- Что такое данные?
    -- Явные и скрытые закономерности
    - Нейробиология, Computer Science и Data Mining
    - Что такое Data Mining?
    2. Data Science
    - DS как наука
    - DS как часть модного тренда: BigData
    - Data mining как часть DS
    3. Алгоритмы Data Mining:
    - Обзор алгоритмов работы с данными
    - Кластеризация
    - Регрессия
    - Классификация
    - Ассоциативные правила
    - Деревья принятия решений
    4. Data mining & Machine learning
    - Формирование обучающих выборок
    - Пересечение машинного обучения и анализа данных
    -- Обучение с учителем
    -- Обучение без учителя
    5. Визуализация данных
    - Важность визуального представления данных
    - Типы визуализации
    6. Data Mining с технической стороны
    - MapReduce
    - Data warehousing and processing
    - Специальные БД: графовые, аналитические
    - HBase, Hadoop и другие страшные слова
    - Софт для работы: NumPy, Scikit-learn, PyBrain, Weka
    - Язык программирования R
    7. Практическое применение
    - Social media mining
    -- Работа с внешними пользователями в момент регистрации
    -- Получение информации о пользователях из "внешнего мира"
    - Text mining
    -- Выделение фактов из текста
    - Предиктивная аналитика
    - Рекомендательные системы
    - Business Intelligence
    -- OLAP

  • * Минимальные аппаратные требования
    * Схема L2 для соединения компонентов кластера
    * Схема L3 для обеспечения внешней доступности сервисов (HSRP, corosync)
    * Локальное дисковое хранилище высокой доступности (на основе проверенного drbd в режиме dual primary)
    * Кластерная файловая система OCFS2 (поверх DRBD)
    * Виртуальные машины в микрокластере
    * Базовые операции по обслуживанию виртуальных машин
    * Ограничения предлагаемого решения
    * Типовые проблемы и их решения

  • Проблема:
    1. Пользователю нужно отослать уведомление о том, что появились билеты соответствующие его параметрам
    2. У aviasales очередь с результатами поисков, каждый совершённый поиск авиабилетов добавляет в эту очередь json документ 200-800k размером, документ содержит тысячи билетов и довольно сложно структурирован
    3. В базе подписок миллионы записей, при этом одна подписка состоит из нескольких предикатов

    В итоге имеем поток огромных документов каждый из которых нужно проверять на соответствие миллионам предикатов. Предикаты бывают как простые вроде пункт_вылета = москва, так и сложные количество_пересадок < 2. Кроме того некоторые сочетания предикатов проверяют ответ не на полное а на частичное соответствие например цена < 100 && колво_пересадок < 2 в этом случае предикатам будут соответствовать только часть билетов в документе и именно о них надо уведомить пользователя.

    На github и остальном интернете не нашлось решения позволяющего за допустимо короткий промежуток времени (<50ms) сопоставлять большой сложноструктурированный документ с миллионами предикатов, поэтому мы в aviasales создали специфичную базу данных которая с этой задачей справляется.

    На данный момент это уникальное решение на рынке, у наших конкурентов вы можете подписаться на информирование с чёткими датами и без требований к времени в пути, цене и других более сложных условий. То есть у конкурентов просто берётся самый дешевый билет на направление, из базы выбираются соответствующие подписки строгим соответствием по 4м параметрам что-то вроде "select * from subscription where origin = 'MOW' and destination = 'LED' and depart_date = '2015-01-01' and return_date = '2015-02-01';". Да если очень постараться можно положить нужную нам логику на SQL и мы даже делали это перед тем как заниматься собственной разработкой, даже при полной загрузке данных в память поиск средствами SQL занимал секунды и реализовывался довольно адской генерацией серии SQL запросов, под такое решение для обработки нашего потока данных действительно требовался мозный кластер, при этом как вы понимаете ни о каком частичном соответствии речи не идёт.

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

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

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

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

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

  • Что такое Docker? Зачем он нужен? Если у него плюсы по сравнению со ставшими уже классическими решениями для виртуализации?

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

    Всё закончилось в течение трёх дней. Эти три я провёл в Сан-Франциско: на конференции Google IO 2014 и на кампусе Google в Маунтин Вью. Когда я увидел своими глазами что возможно сделать с Docker'ом и как эта технология используется в поисковом гиганте стало понятно что обратного пути нет.

    Я расскажу чем отличается контейнеризация от виртуализации, какие инструменты для Docker существуют и покажу как за несколько минут можно развернуть кластер Cassandra в облаке Microsoft Azure.

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

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

  • Виртуализация сетевых функций (NFV) - это одна из самых широко обсуждаемых тем в мире компьютерных сетей. Суть заключается в переносе сетевых сервисов, типа анализаторов трафика, файрволов, балансировщиков нагрузки, работающих сейчас на специализированном железе, в ЦОДы, работающих на традиционном серверном оборудовании. Теперь все сетевые сервисы реализуются программно и запускаются на виртуальных машинах, тем самым достигается гибкость развертывания и масштабирования в зависимости от нагрузки и требуемой производительности. В итоге стоимость конечного решения уменьшается на порядок.

    В докладе будет рассказано, чем это отличается от существующих программно-апаратных решений по обработке сетевого трафика, какие преимущества мы получаем, какие новые проблемы и задачи при этом появляются. Будут затронуты проблемы производительности таких виртуализированных сетевых сервисов, будет сделан обзор различных вариантов программного исполнения сетевых сервисов (userspace, kernelspace, VM, Intel DPDK/Netmap и т.п.), в каждом случае показана достигаемая производительность. Также будет рассказано о будущем NFV, программном стеке и платформах по централизованному управлению и оркестрации.

    В качестве практического примера рассказ об опыте разработки и тестирования прототипа виртуализованного сетевого сервиса для одного российского телеком оператора.

  • В течение многих лет классическая веб-архитектура включала серверы, рендерившие 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, хеширование и проч.).

  • HighLoad для начинающих Обухов Дмитрий Эдуардович

    Чисто обзорный/информационный доклад для начинающих HighLoader'ов :)

    Разберемся в вопросе что же такое HighLoad вообще, начнем с того
    что попытаемся определить его "в попугаях" (ц).

    Рассмотрим простой вебпроект на (скажем) PHP, определим границы его нагрузочной способности для одного сферического сервера. Далее разберем что надо сделать чтобы эти границы преодолеть.

    Далее перейдем к проблемам планировщиков OS, как их преодолевать: событийные
    системы, языки программирования. Коснемся немного in-memory базы данных
    tarantool.

    Ну и в качестве примера применения всего вышеописанного приведу
    свой проект - распределения заказов такси (один из крупных бакендов Яндекс.Такси).

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

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

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

  • MySQL - популярная СУБД используемая во многих проектах. Разработчик Percona-Server и инженер Mail.Ru Target расскажет про неудачные решения в репликации MySQL, её устройство, архитектурные проблемы, многопоточную репликацию в 5.7 и почему это провал, как репликацию нужно было сделать правильно, и почему PostgreSQL избежал этих проблем.

    Мы обсудим:
    - что такое асинхронная репликация
    - как устроена асинхронная репликация в MySQL
    - какие ошибки проектирования были допущены
    - как эти ошибки проявляются в использовании
    - чем эти ошибки мешают эксплуатации
    - почему параллельная репликация MySQL 5.7 не решает проблем, а лишь добавляет новые
    - как PostgreSQL избежал этих ловушек

  • 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. Что может показаться необычным и какие подводные камни стоит ожидать.

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

    Я расскажу про решение этой задачи через приватное облако Open Stack.
    В облаке мы разворачиваем:
    — Справочное API 2ГИС через Chef
    — 2ГИС-Онлайн через Ansible
    — BSS (система статистики) через deb-пакет
    — Виндовая шина интеграции
    — Тестовые окружения

    В итоге мы получили гибкий инструмент для разнопланового тестирования продуктовых сервисов.

  • На сегодняшний день наиболее популярным алгоритмом сжатия отправляемых с веб-сервера данных является 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-дисков, покрасневших
    графиков мониторинга и ночных кошмаров системных администраторов.

  • В условиях взрывного роста нишевых продуктов, наблюдаемого последние несколько лет на рынке баз данных, легко потеряться и еще сложнее понять кто является кем и на каких алгоритмах работает. Аналитики продолжают пытаться категоризовать рынок SQL и noSQL баз данных в виде квадрантов, часов и многомерных схем, но в большинстве случаев это вырождается в адские схемы в стиле карты токийского метро. Не пытаясь объять всю картину мы еще раз попытаемся разложить по разным полочкам наиболее ярких игроков текущего рынка баз данных, найти у них что-то общее (алгоритмы, структуры данных, используемые идиомы программирования), и, таки, найти место в данной классификации многомерным базам данных как intersystems Caché.

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

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

  • При разработке масштабируемых решений мы столкнулись с необходимостью обеспечения отказустойчивой работы виртуализированных серсивов, а значит - динамического перераспределения виртуальных машин между физическими серверами.
    К сожалению, человек не способен эффективно решать комбинаторные задачи сложнее трехмерных. На практике это означает что если требуется максимально эффективно распределить виртуальные машины между серверами, и параметров конфигурации больше трех (например - требуемое количество CPU, RAM, диска и пропускной способности сети), задача человеком решается неоптимально.
    Мы построили opensource распределенную систему, лишенную единственной точки отказа, позволяющую в автоматическом режиме динамически перераспределять виртуальные машины KVM меджу физическими серверами.
    Наш алгоритм решает общеизвестную задачу наполнения рюкзака (https://ru.wikipedia.org/wiki/Задача_о_ранце) с учетом набора конфигурируемых критериев. Это значит, что любой системный администратор может самостоятельно задать набор требуемых для виртуальной машины KVM ресурсов, доступных мощностей на каждом физическом сервере, общее количество серверов в кластере, и дальне не заботиться о доступности сервиса. В случае аварии или возникновения необходимости миграции виртуальная машина перезапускается автоматически.
    Кроме того, наш алгоритм в автоматическим режиме позволяет запретить запуск виртуальных машин с одной ролью на одном физическом сервере. Это означает, что два фронтэнда nginx или MySQL Master и MySQL Slave никогда не будут запущены на одном физическом сервере, таким образом, мы снижаем вероятность отказа сервиса при внезапном выключении сервера.
    На доклад требуется 1 час. Докладчики: Андрей Шетухин, Иван Повстен.

  • Любая компания, разрабатывающая современное кросс-платформенное приложение (как нативное, так и веб), сталкивается с рядом проблем:
    1) Фрагментация (огромное количество типов и версий устройств, операционных систем, браузеров, представлений, поддерживаемых языков).
    2) Регрессия (мелкое исправление в UI приводит к проблемам на других ОС, браузерах и состояниях).
    3) Контролируемость изменений (со временем становится все сложнее ревьюить изменения кода в UI).

    В настоящее время существует ряд инструментариев, помогающих решить данные проблемы:
    1) Средства автоматизации тестирования UI для нативных приложений (например, Sikuli). Основные недостатки данных решений – это работа с приложением внешним образом (как «black box») и неустойчивость к изменениям (при модификации UI приложения приходится переделывать большинство написанных автотестов).
    2) Библиотеки для Web, позволяющие снимать и сравнивать скриншоты HTML-страниц: PhantomCSS, Kaidan, Wraith. Обычно используют один браузер в качестве движка рендеринга (чаще всего PhantomJS), таким образом не решают проблему фрагментации, однако позволяют контролировать изменения кода и обнаруживать регрессионные проблемы. Также к плюсам можно отнести возможность запуска локально, без зависимости на внешние сервисы/инфраструктуру (тем самым достаточно несложно включить такие инструменты в Continuous Integration компании, однако не без дополнительных доработок).
    3) Облачные сервисы (BrowserStack.com, CrossBrowserTesting.com, SauceLabs.com). К достоинствам такого инструментария, без сомнения, стоит отнести большое количество поддерживаемых браузеров и платформ (включая мобильные), однако облачный характер сервисов создает ряд ограничений, таких как необходимость работы online и внешнего доступа к ресурсу, который требуется протестировать.

    Наша компания разрабатывает как нативные, так и веб-приложения под разные платформы, и описанные выше проблемы стали для нас актуальны еще несколько лет назад. Они заставили заняться созданием инструментария, позволяющего контролировать процесс работы над UI в наших проектах. В итоге мы пришли к следующему подходу:
    1) Разработчик помимо кода описывает набор различных состояний (представлений) приложения/страницы/элемента, которые считает целесообразным покрыть скриншотами. В этом подход очень похож на unit-тесты, в которых в каждом тесте система вводится в нужное состояние, однако без описания assert’ов: вместо этого приложение будет «заскриншочено» в каждом описанном состоянии на каждом поддерживаемом устройстве, операционной системе, браузере, разрешении, языке.
    2) Процедура снятия скриншотов включена в общую инфраструктуру Continuous Integration в нашей компании: прогоны осуществляются каждую ночь, по результатам этих прогонов рассылаются письма с отчетом о различиях по отношению к предыдущему прогону.
    3) «Незначительные» различия (сглаживания шрифтов, визуальные эффекты) игнорируются, в отчетах по различиям показывается что-то наподобие «тепловой карты» изменений, где красным показаны важные различия, а желтым – незначительные. Скриншоты, содержащие только незначительные изменения (или не имеющие их вовсе) не включаются в отчет.
    4) Удобная визуализация изменений позволяет просматривать такие отчеты, не тратя много времени и быстро отличая «правильные» изменения от «неправильных» (добавление нового элемента или смена компоновки страницы – это «правильное» изменение, вызванное модификацией приложения, а «поехавшая» в Safari верстка в связи с исправлениями под IE8 – это изменение «неправильное»).

    Немного про реализацию. Инструментарий включает себя реализацию на C++ (Qt + QtWebKit), Python, JavaScript, для взаимодействия с браузерами используются Selenium Web Drivers, запуск различных версий браузеров осуществляется в виртуальных машинах через VirtualBox API, для снятия скриншотов на мобильных платформах используются iOS/Android-эмуляторы. Скриншоты снимаются в 11 различных браузерах (IE8+, Firefox, Chrome, Opera, Safari, Android Browser, Mobile Chrome, Safari Mobile), 6 различных типах DPI, 6 версиях операционных систем, нескольких языках. На текущий момент всего снято 2000000+ скриншотов (224 ГБ).

  • Редактор Mail.Ru или скорочтение за полчаса Зиновкин Павел Васильевич

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

    Однако есть одна вещь, рушащая идилию: вам присылают Word/Excel/Powerpoint файл с просьбой что-то в нем поправить.
    На примере опыта построения Редактора Mail.Ru я расскажу как мы решаем эту проблему для пользователей наших сервисов.

    Я планирую рассказать о том как мы строили это сервис, с какими проблемами сталкивались и как их решали. Затрону такие аспекты как:
    - Чтение документов
    - Механизмы показа и редактирования
    - Построение тамбнейлов документов
    - Методики обеспечения качества

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

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

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

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

  • Если вы слышали о протоколе 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, как мы оценивали эффективность нашего подхода, и какие сюрпризы нам преподнесла действительность.

  • Архитектура АСУ КВО Подольный Вадим Павлович

    Архитектура автоматизированных систем управления критически важными объектами.

    В докладе будут раскрыты следующие тезисы:
    1. Архитектурные аспекты создания нагруженных АСУ КВО;
    2. Сравнение методов request/responce и multicast в задачах обмена данными в АСУ КВО;
    3. Сегментация данных, создание иерархических моделей данных для оптимизации транспорта данных;
    4. SQL + NoSQL, отказ от ORM;
    5. Особенность MapReduce в задачах АСУ КВО для повышения производительности системы;
    6. Балансировка нагрузки на АСУ КВО;
    7. Что делать, если поток данных всё же выше, чем система может обработать. Правила потери и ценность данных;
    8. Диагностика источников данных и узлов АСУ КВО;
    9. Внутренние механизмы защиты информации в АСУ КВО;
    10. Аппаратное обеспечение (сервера, маршрутизация, однонаправленные шлюзы);

    Могут быть приведены следующие примеры нагруженных систем, реально реализованных:
    * Система верхнего блочного уровня (СВБУ) АЭС (50k/sec изменений аналоговых значений, синхронизация 100 узлов в режиме РВ, централизованные надёжные источники данных) (Калининская и Волгодонская АЭС);
    * Система мониторинга транспорта (30k/sec изменений аналоговых значений, синхронизация с N узлов, децентрализованные, не надёжные источники данных);
    * Интеграционные шины (не ESB а скорее специализированные полевые шины / Field Bus ).

    Могу сделать доклад от 30 мин до 1 часа. Можно и больше, но не хотелось бы.

  • Необходимое вступление:
    Так получилось, что я стараюсь выступать на профильных конференциях про то, что сильно волнует меня в данный момент, про то что я и так мог бы говорить часами, и про то, чем хочется поделится со всеми.

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

    Но душа же просит отдушины :) Так получилось, что на иркутском хакатоне, изначально не желая участвовать, я в итоге выступил с довольно странным проектом, который и вырос в тему, о которой я хочу рассказать.

    Я хочу рассказать об аппаратных эмуляторах на JavaScript (а точнее остановиться на конкретном, PCE.js - http://jamesfriend.com.au/pce-js/ibmpc-games/), немного углубиться в тонкости внутренного устройства JavaScript эмулятора (и 80x86 компьютера как такового) и описать как сделать так, чтобы на фронтенде можно было писать на ассемблере. Что я сделал? Я взял эмулятор 80x86 ПК, на который дописал несколько прерываний, получая которые машина выходила из своего "мира" и пробрасывала в DOM-модель страницы на которой работала типичные javascript-действия (appendnode, innerHTML, getElementById итд).

    Зачем это надо?

    Прежде всего, честно признаться - это just for fun, я очень давно не залазил так глубоко в недра ПК, а если этим заниматься - то хоть со сколько-нибудь приближенной к действительности целью (а роботов программировать неинтересно).

    Во вторую очередь - это Proof of Concept кардинально новой технологии защиты фронт-энд кода.
    Код, написанный на ассемблере, скомпилированный в DOS-executable, который через пробрасывания машинных прерываний делает document.getElementById и сопутствующие операции - не то чтобы невозможно было бы разобрать, но 95% современных script kiddies понять не могут. Теоретически, проекты которые хотят защитить логику своего фронт-энд кода получат защиту близкую к той, которую получают разработчики десктоп-приложений.

    Фронт-энд код, который компилируется в exe, которая запускается в DOS-е, который запускается в эмуляторе на JavaScript-е? Понять логику стороннему человеку, решившему "проникнуть" в логику приложения будет довольно сложно.

    Тезисы:
    1. Эмуляторы на JavaScript, что это такое и как они работают?
    2. PCE.js, и его внутренности.
    3. Дорабатываем эмулятор новыми аппаратными прерываниями. Как, зачем, и как именно мы будем пробрасывать эмулятор в DOM-модель.
    4. Где деньги? Для чего это на самом деле может быть необходимо.

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

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

    На примере конкретного стартапа readymag.com я расскажу
    * как выглядела архитектура системы на момент старта "все работает на одном сервере и не масштабируется", в чем были основные проблемы;
    * последовательность рефакторинга системы до состояния "нам всеравно сколько трафика к нам идет”;
    * общий подход к эффективному использованию сервисов AWS, который позволит получить эффективно масштабируемый сервис без участия devops и сосредоточить усилия команды на развитии продукта.

  • На основе данных, накапливаемых и хранимых в инфраструктуре (HDFS) рекламной системы MAIL.RU, проводится машинное обучение классификаторов, позволяющих разделять различные группы пользователей интернета. Для представления признаков, характеризующих конкретный обучающий прецедент, используется модель bag-of-words, в рамках которой векторы признаков являются разреженными и большой размерности.
    Уменьшение размерности пространства признаков методом латентного размещения Дирихле (LDA) позволяет в ряде случаев проводить тематическое моделирование распределения признаков. Классификаторы, обучаемые как на разреженных (логистическая регрессия, Lasso, ElasticNet), так и на сжатых векторах признаков (SVM), демонстрируют приемлемое качество (ROC-AUC, Precision/Recall) на валидационных и тестовых выборках.

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

  • При разработке программных продуктов для крупных заказчиков, как правило, приходится интегрироваться с уже готовыми системами, решающими отдельные бизнес-задачи. Самый простой вариант интеграции – использование существующих систем в качестве источников информации. Более сложный – участие разрабатываемого продукта в сложной цепочке бизнес-процесса, получение данных от одних систем и передача их другим. Причем, чем крупнее заказчик, тем больше разнообразных систем может быть вовлечено в бизнес-процесс и тем больше используется различных прикладных протоколов взаимодействия, начиная от xml через http и заканчивая прямыми подключениями к интерфейсным схемам баз данных и soap-ом. Тем актуальнее становится задача контроля работы интерфейсов с точки зрения выполнения бизнес-задач, и, следовательно, необходимость собирать и обрабатывать статистические данные по таким взаимодействиям.
    Когда в нашей практике возникла необходимость собирать такие данные, сначала мы просто фиксировали данные в логи, в первую очередь, чтобы контролировать скорость ответа внешних систем. Потом по отдельным системам возникла необходимость собирать данные для отчетов, и практически для каждой системы мы писали небольшую утилиту для разбора логов. В один прекрасный момент, когда количество внешних систем стало чрезмерным, а требования к актуальности данных возросли, было решено разработать собственную систему функционального мониторинга. Было понятно, что система должна обладать следующими качествами:
    1. гибкостью настройки ключевых KPI и CSF,
    2. оперативностью, т. е. мгновенной реакцией на критические события,
    3. универсальностью: поддержкой различных сред и стеков разработки, поддержкой множества видов счётчиков,
    4. масштабируемостью.
    Существующие на рынке решения либо не устраивали нас по функциональности, либо пугали ценой. В результате родилась собственная система функционального мониторинга. Об интересных и показательных кейсах, которые возникали в процессе её создания, и будет идти речь в данном докладе.

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

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

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

  • В рамках данного доклада мы подробно исследуем возможности 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-инфраструктуры, вы
    узнаете из доклада.

  • Доклад разбит на 2 части:
    1) 30 минут. MS SQL. Опыт использования MS SQL в мире сайтов. Типичные проблемы MS SQL, плюсы этой БД, пути решения проблем, связка с другими продуктами Microsoft и сторонним ПО. Всё ради скорости и качественного сервиса. Как подготовить данные, чтобы без использования high-end оборудования скорость ответа была менее 1 мс, а количество транзакций на чтение составляло десятки тысяч в секунду и одновременно на запись несколько тысяч в секунду. Как перенести проект с террабайтными данными из одного конца мира в другой за 10 минут. Шардинг. Распределение нагрузки по БД на несколько серверов. Копии данных Master-Slave. Отказоустойчивость. HDD vs SSD. Работа 24/7-365…
    2) 10 минут. Прочая инфраструктура. Полный цикла разработки ПО для сайтов на продуктах Microsoft и не только. Что насчёт NoSQL, Redis, CDN, Kibana, Nginx, RabbitMQ, видеостриминг, виртуализации, мобильных приложений, мониторинга работы сайтов и т.д.

  • Серверы вашей компании расположены по всему миру и вам необходимо обрабатывать данные в едином месте. Приложения с разными технологическими стеками генерируют данные в самых разных местах - от веб-серверов до датчиков. Как бы вы стали решать эту проблему? Врубайтесь в 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) и госучреждений (Национальная служба здравоохранения Великобритании) - и это лишь несколько примеров.

  • Продукт Sentry изначально задумывался как простая и размещенная на собственном хостинге платформа логирования исключений с базой данных на бэкенде. Сейчас Sentry обрабатывает значительный объём данных через внешний сервис, но по-прежнему работает на очень простой архитектуре. В докладе мы рассмотрим ряд обобщённых подсистем, построенных поверх Postgres + Redis + Riak. Кроме того, в докладе будет рассказано о нескольких проблемах масштабирования, с которыми мы сталкивались в Disqus (инфраструктура) и Dropbox (построение системы).

  • Highway to Continuous Integration Денис Трифонов

    В своем докладе я поделюсь опытом внедрения Continuous Integration в наши процессы. Я расскажу как мы используем Jenkins в качестве CI-сервера и какие задачи решаем с помощью него и других инструментов:
    - разворачивание и конфигурирование приложений и тестов с помощью Open Stack и Chef;
    - запуск функциональных тестов с помощью PHPUnit и параллельное выполнение с помощью Paratest;
    - обновление окружения и тестирование задачи в ветке с последующим вливанием в мастер-ветку;
    - ежедневная регрессия на мастер-ветке и откат до состояния последнего релиза, а также тестирование разворачивания с нуля;
    - нагрузочное тестирование с помощью Яндекс.Танк и Graphite, подготовка логов с продакшена из Elastic Search и построение отчетов с текущими и предыдущими результатами нагрузки.

    Я затрону интеграцию с Jira для наших процессов и решения других задач для разработки и тестирования.

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

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

  • Elasticsearch – это гибкий и эффективный открытый поисковый движок на основе Apache Lucene. Изначально созданная специально для распределённых сред, система Elasticsearch является практичной, стремится к простоте в использовании, работает и масштабируется даже тогда, когда все остальные поисковые системы «падают». REST API и поддержка документов в формате JSON делают этот движок очень гибким и простым в использовании.
    Хотя движок Elasticsearch создавался для поиска, его структура запросов, фильтрация и фасетизация делают Elasticsearch одним из немногих простых решений для аналитики, близкой к real-time. Такие его возможности, как фреймворк агрегации (ранее – фасеты), могут использоваться для агрегации больших объёмов данных.
    Свой доклад я начну с рассказа об использовании Elasticsearch для аналитики, близкой к real-time, для стуктурированных и неструктурированных данных, а затем мы перейдём к более «продвинутым» возможностям – таким, как маппинг, фильтрация и агрегация для аналитики. Мы также поговорим об особенностях проектирования при необходимости обработки большого числа операций чтения, записи и поиска для аналитики. Мы также уделим некоторое время возможным оптимизациям для аналитической рабочей нагрузки, которая во многом полагается на агрегацию.
    Охватываемые темы
    1. Elasticsearch, очень краткое представление.
    2. Эффективный фреймворк агрегации.
    3. Маппинг для структурированных и неструктурированных данных.
    4. Особенности проектирования для обеспечения масштабируемости и высокой производительности (быстрые операции записи, чтения и поиска).
    5. Оптимизация Elasticsearch для аналитической рабочей нагрузки.
    6. Библиотеки Python для Elasticsearch – очень краткое обсуждение.
    7. Отсылка к внешним ресурсам после доклада.
    Очень кратко мы поговорим о том, как мы внутри VWO построили углублённое сегментирование для аналитики с использованием Elasticsearch и Python, конкретнее, о том, как мы взяли PoC для продакшна и о проблемах, с которыми мы столкнулись в процессе.

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

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

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

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

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

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

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

рост количества участников HighLoad++

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

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

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

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

главный зал

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

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

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

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

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

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

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

Новости

Олег Царёв об устройстве репликации в MySQL
Нам удалось уговорить Олега Царёва, отличного эксперта по базам данных, выступить на HighLoad++ с мега-докладом!
Лучшие видео HighLoad++ бесплатно в обмен на обратную связь
Заполняйте наш простой опрос и получайте ссылки на видео прошлых лет!
Международная конференция Lean Kanban Russia наконец в Москве!
Наши партнёры предоставили скидку на участие в этой конференции - 10% по промокоду highload!
Впервые в России о том, как устроен LinkedIn
Три доклада от разработчиков LinkedIn: Олег Шапиро, Дмитрий Маркович и Brian Geffon.
Результаты встречи докладчиков, Программного комитета и активистов
Все самые интересные темы профессионального сообщества в одном документе.
Memcached-инъекции: они существуют и работают
Иван Новиков (ONSec), выступавший на HighLoad++ 2013 с докладом "Завалить в один запрос: уязвимости веб-приложений, приводящие к DoS", в этом году расскажет о Memcached-инъекциях.
Как произвести анализ производительности систем?
Алексей Лавренюк из "Яндекса" готов рассказать об опыте применения статистических методов и инструментов.
Архитектура, способная обслужить 60 миллионов абонентов, на HighLoad++ 2014!
Доклад о приложении в инфраструктуре оператора связи, работающем близко к real-time и имеющем ряд спецтребований, от эксперта компании "Петер-Сервис" Артёма Руфанова.
Пётр Зайцев снова на HighLoad++: целых 5 докладов от ведущего эксперта по MySQL вам на выбор!
Наш постоянный докладчик Пётр Зайцев из года в год собирает полные залы заинтересованных слушателей. Посмотрите, какие темы он предложил нам в этом году, и вы сразу поймёте почему. Голосуйте за лучшие доклады - мы это учтём!
Открытая встреча докладчиков HighLoad++ 2014: мы хотим узнать, что вам интересно!
Ждём вас 7 августа в Москве! Не упустите свой шанс сделать конференцию HighLoad++ 2014 максимально интересной и полезной лично для вас - завтра в 19:00 в офисе компании Mail.Ru мы собираем Программный комитет, докладчиков и всех неравнодушных!

Спонсор

  • Nutanix

Спонсор

  • WarGaming

Спонсор

  • Webzilla

Спонсор

  • Badoo

Спонсор

  • Parallels

Спонсор

  • Филанко

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

  • SQLInfo.ru
  • Интернет Хостинг Центр
  • Sports.ru
  • Rusonyx
  • Adriver
  • SuperJob
  • REG.RU
  • ООО «Юмисофт»
  • Агава
  • PCWeek
  • PС Мagazine
По любым вопросам обращайтесь:
Программный комитет :
Олег Бунин , +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