HighLoad++

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 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, в первую очередь, должны НАДЕЖНО ХРАНИТЬ данные. Поэтому мы обязательно затронем тему консистентности данных и надежности их хранения.

  • Система, на примере которой я хочу построить свой доклад, это система открутки контекстной рекламы. Она занимается ротацией объявлений рекламодателей, подсчетом показов и кликов по объявлениям. Входной поток данных - около 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 СУБД.

  • 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.

  • Server Side JavaScript Engine Dzmitry Markovich


    Server Side JS Execution at Scale - What Could Possibly Go Wrong With That?


    Scaling Architecture

    For many years, the classic web architecture comprised servers rendering HTML via a server-side scripting or application language. However, the web is changing in many ways, including: faster browsers, improved internet connections and better caching. These changes have lead to a paradigm shift, resulting in client-side rendering. This new architecture frees up your servers to deliver only data allowing markup to be cached at, or close to, the client, resulting in overall performance improvements.

    The reality of the Internet is that not all of our users switched to powerful computers, modern browsers and faster internet connections. Performance of LinkedIn pages for these users had to be improved somehow.

    In this presentation you will learn on how we integrated JS engine into HTTP proxy, the operational and engineering experience we gained while adding dynamic language execution into our key proxy tier, how we fought JavaScript termination and garbage collection issues, and, finally, how we decreased latency even further.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    ЦЕЛИ
    1) Предоставить предельно эффективную библиотеку для обмена сообщениями в пределах физически единой RAM, но с различными адресными пространствами. Подразумевается возможность обмена между разными процессами, между процессом (user-mode) и ядром (kernel-mode), между основным процессором (CPU) и сопроцессором (Tesla, Xeon-Phi), между процессами в пределах одного гипервизора. Подобных средств существует уже масса, но картина полностью меняется если решать задачу действительно предельно оптимально. Например, MPI является ближайшим промышленным решением, но в случае локального обмена производится копирование данных. Соответственно 1Hippeus, напротив, ориентирован на поддержку zero-copy, т.е. на обмен через разделяемую память. Это внешне небольшое отличие кардинально влияет на дизайн, делая 1Hippeus непохожим на другие решения.
    2) Получаемый набор примитивов и рецептов также позволяет выстроить обмен непосредственно с DMA-дескрипторами сетевых адаптеров и интегрироваться с другими механизмами/библиотеками передачи сообщений. Предоставляется интерфейс и средства для такой интеграции, что позволяет рассматривать 1Hippeus как высокопроизводительный механизм обмена сообщениями в многопроцессорном кластере (NUMA, RDMA, Tilera).
    3) Надежность, во всех смыслах. Библиотека должна быть надежной и стабильной.
    Поэтому строенные средства контроля, мониторинга и отладки. Поэтому CI и автоматизированное тестирование. Поэтому политика релизов и OpenSource.

    КАК?
    При ответе на вопрос «как» проясняются трудности и цена, которую приходиться платить за эффективность.
    Нет смысла в решении, требующем сериализации объектов или копирования данных в памяти. Бесполезны также сообщения в виде простых типов данных. Требуется что-то более гибкое и «резиновое» размещаемое в разделяемой памяти.
    Нельзя не сказать о трудностях, из которых можно выделить две главные:
    1) Взаимодействие из разных адресных пространств заставляет не использовать прямые указатели и требует прозрачности/подконтрольности всего кода. Соответственно нельзя использовать стандартные/готовые библиотеки или системные сервисы, включая примитивы синхронизации. Всё это приходится делать с чистого листа.
    2) При взаимодействии через разделяемую память ошибка одного из участников может легко сломать весь «оркестр». Соответственно требуется встроенные средства контроля целостности и выявления подобных ошибок, а также предоставление «безопасного режима» для отладки клиентского кода.

  • 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. троллинг со сторны зала

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Новости

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

По любым вопросам обращайтесь:
Программный комитет :
Олег Бунин , +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