Расписание

timestamp order id dateGroup sectionGroup tags 1 2
0 9999999900000 1 1152    База данных, системы хранения 

#аналитика

База данных, системы хранения
Когда Sports.ru превратился из новостного сайта в полноценную социальную сеть, месячная аудитория достигла 12 миллионов уникальных пользователей, а к сайту добавились несколько сотен групп в социальных сетях и клубных мобильных приложений, обычных инструментов веб-аналитики стало недостаточно. Нам нужно было научиться считать и визуализировать много новых метрик, специфичных для медиа и социальных сетей, и использовать полученную информацию для персонализации сайта. Мы решились взяться за разработку собственной аналитической системы, которая позволила бы собрать все нужные данные в одном месте, быстро их обработать и понятно отобразить.
Олег Новиков
Руководитель отдела аналитики в Sportsru
+ и ещё 1
Илья СалтановДиректор по развитию в Tribunacom
1 9999999900000 2 1153    Учебный трек 

#аналитика

Учебный трек
Как известно, что не измеряется, то нельзя улучшить. И если замеры на бэкенде (сколько времени выполняются запросы к базе, как быстро генерируются страницы, сколько запросов в секунду может обрабатывать веб-сервер) выполняют почти все разработчики, то ClientSide-производительности незаслуженно уделяется значительно меньше внимания. Быстрый ли DNS, хороший ли канал у хостера, закэширована ли статика, не перегружен ли сайт JavaScript'ом - все это помогает оценить Navigation timing API.В докладе мы расскажем о том, как делали систему аналитики, основанную на Navigation timing API, для десятков тысяч сайтов:- Как сделать подобную систему за 1 месяц и $1000, используя в Amazon Web Services (AWS) Kinesis и DynamoDB.- Как быстро (очень быстро!) принимать миллионы хитов с помощью Nginx+Lua.- Как в реальном времени обрабатывать миллионы хитов, постоянно агрегируя данные (потоковая обработка BigData... без хранения BigData).
Александр Сербул
Менеджер контроля качества интеграции и внедрений в 1С-Битрикс
+ и ещё 1
Сергей РыжиковДиректор в 1С-Битрикс
2 9999999900000 3 1154    Тестирование 

#безопасность

Тестирование
Про 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, хеширование и проч.).
Иван Новиков
Основатель, руководитель и ведущий эксперт в ONsec
3 9999999900000 4 1155    Архитектуры 

#веб-сервера

Архитектуры
Чем на самом деле занят backend (application server)? Чем обусловлены пределы нагрузки? Как увеличить производительность? Многозадачность: "нити" (threads), процессы, асинхронный ввод-вывод, event loop. Модели программирования: многопоточная, многопроцессная, корутины, явная асинхронность. Драйвер базы данных: управление соединениями, pipelining, шардирование и отказоустойчивость. Вычислительно сложные задачи: очереди, RPC, workers. Сервисно-ориентированная архитектура (SOA). Мы обсудим различные варианты архитектуры веб-сервисов, посмотрим на популярные веб-фреймворки на различных языках программирования (Ruby, Python, Go, Java), а также выясним, какие модели они предлагают и как эти модели реализованы.
Андрей Смирнов
Руководитель разработки в ex-Skype
4 9999999900000 5 1156    Системное администрирование 

#бизнес

#ит

#по

#разработка

Системное администрирование
Игорь Сысоев, Nginx: Масштабируемая конфигурация nginx* Как создавать конфигурацию, которую легко сопровождать в течение многих лет.* Правильные и неправильные способы конфигурации, типичные ошибки.* Где следует использовать регулярные выражения.* Почему подход "copy-paste" лучше, чем DRY (Don't Repeat Yourself).
Игорь Сысоев
Создатель в Nginx
5 9999999900000 6 1157    Учебный трек 

#веб-сервера

Учебный трек
Большая часть интернет-контента сегодня динамическая, и в основном (более чем на 90% по последним оценкам) это PHP. LiteSpeed Web Server (LSWS) помогает ускорять сайты, обслуживая PHP быстрее других веб-серверов. Он также прост в использовании, поскольку запускается с использованием настроечных файлов Apache.LSWS предлагает 3 различных режима работы PHP для разных ситуаций. В своём докладе я расскажу о преимуществах и недостатках различных режимов LSWS для PHP – включая более эффективное использование памяти, более высокую скорость, общее кэширование кодов операций suEXEC и т.д. Я также представлю результаты benchmark-тестов и исследую кейсы со сравнением режимов LSWS и различных реализаций NGINX и Apache. Согласно нашим тестам, LSWS обслуживает небольшие файлы PHP до 2х раз быстрее по сравнению с NGINX и до 40 раз быстрее, чем Apache 2.4 с помощью suPHP. В завершении доклада я расскажу об установке LSWS в Apache-окружении менее чем за 10 минут.
Michael Armstrong
Marketing Director в LiteSpeed Technologies
6 9999999900000 7 1158    Видео 

#видео

Видео
Александр Тоболь, Одноклассники: Кадры решают все, или стриминг видео Я расскажу, как нам удалось более чем в 10 раз ускорить старт просмотра кино и сериалов с использованием технологий адаптивного стриминга MPEG-DASH и HLS. Вы узнаете, какие технологии попали в поле зрения команды, как инфраструктурные особенности, размер аудитории и специфика потребления на разных пользовательских устройствах повлияли на принятие решения о выборе технологии. Естественно, будет дан и подробный отчет о результатах внедрения решения и полученном эффекте.
Александр Тоболь
Разработчик в Одноклассники
7 9999999900000 8 1159    Архитектуры 

#виртуализация

Архитектуры
При разработке масштабируемых решений мы столкнулись с необходимостью обеспечения отказустойчивой работы виртуализированных сервисов, а значит и динамического перераспределения виртуальных машин между физическими серверами. Мы построили Open Source распределенную систему, лишенную единственной точки отказа, позволяющую в автоматическом режиме динамически перераспределять виртуальные машины KVM между физическими серверами.Наш алгоритм решает общеизвестную задачу наполнения рюкзака (https://ru.wikipedia.org/wiki/Задача_о_ранце) с учетом набора конфигурируемых критериев. Это значит, что любой системный администратор может самостоятельно задать набор требуемых для виртуальной машины KVM ресурсов, доступных мощностей на каждом физическом сервере, общее количество серверов в кластере, и далее не заботиться о доступности сервиса. В случае аварии или возникновения необходимости миграции виртуальная машина перезапускается автоматически.
Андрей Шетухин
Руководитель почтовой службы в Rambler
8 9999999900000 9 1160    Без секции 

#виртуализация

Без секции
Я кратко повторю содержимое предыдущего доклада, где была описана архитектура «облака» и его основные компоненты, после чего оставшаяся часть будет посвящена граблям, на которые мы наступили и планам на будущее.Главные демоны нашего «облака» всё ещё работают на немного модифицированном прототипе, который был написан в первые недели разработки, при этом за год суммарный простой составил 3 часа, что дает uptime 99,97%. Тем не менее, у нас есть много идей для улучшения:- перевод управляющей логики с PHP на Go;- перевод phproxyd с Си на PHP (!), для экономии на запуске интерпретатора;- возможный переход на Tarantool для хранения текущего состояния скриптов;- длительное хранение логов, индексирование .gz-файлов для просмотра информации даже по очень старым запускам;- улучшения в балансировщике (итеративное «уточнение» весов вместо использования «попугаев»).
Юрий Насретдинов
Ведущий разработчик в Badoo
9 9999999900000 10 1161    База данных, системы хранения 

#графы

База данных, системы хранения
Сейчас наша компания занимается разработкой решения, позволяющего анализировать большой социальный граф: такой, в котором >100 млн. вершин и >1 млрд. ребер. На нем могут ставиться различные задачи: от простого обхода всех ближайших соседей вершины до поиска всех подграфов, удовлетворяющих определенным условиям. Кроме того, дополнительная сложность заключается в том, что все время добавляются новые данные, а потому их прогрузка должна идти параллельно с анализом.Я расскажу о том, как мы решали эту задачу с помощью графовых баз данных DEX и Neo4j, о том, как в каждой из них можно настроить быстрый импорт графа и как ускорить обходы с помощью кэширования. Также я объясню, почему в конечном итоге мы перешли к созданию собственного хранилища, "заточенного" непосредственно под решение наших задач.
Максим Бартенев
Разработчик в Норси-транс
10 9999999900000 11 1162    Смежные области 

#графы

Смежные области
Сети вокруг нас. Любой объект окружающего нас мира можно представить в виде совокупности объектов и связей между ними. Если объектов становится слишком много, а связи между ними слишком сложны, поневоле приходится задуматься о том, как эффективно хранить и обрабатывать такую сеть. Классические алгоритмы и структуры данных "пасуют" уже на сравнительно небольших графах.Что делать, если объект вашего исследования - это весь веб-граф Рунета, граф Твиттера, дорожная сеть Европейского союза или граф знаний Google? Как корректно и быстро вычислить диаметр графа, найти компоненты связности, кратчайшее расстояние между всеми парами вершин или разрушить минимальное остовное дерево?
Алексей Зиновьев
Java-разработчик в Тамтэк
11 9999999900000 12 1163    База данных, системы хранения 

#датацентр

База данных, системы хранения
Postgres обладает уникальной способностью выступать эффективным агрегатором данных во многих центрах обработки данных. В данном докладе будет продемонстрировано, как расширяемость Postgres, доступ к иностранным источникам данных и способность обрабатывать NoSQL-подобные и связанные с хранением данных рабочие нагрузки дают PostgreSQL непревзойденные возможности для исполнения этой роли.Более подробно в презентации на английском: http://momjian.us/main/writings/pgsql/central.pdf
Bruce Momjian
Senior Database Architect в EnterpriseDB
12 9999999900000 13 1164    База данных, системы хранения 

#деньги

База данных, системы хранения
Любой веб-сервис, занимающийся извлечением коммерческой прибыли, ведет учет заработанных денег в собственных хранилищах данных, которые зачастую создаются "с нуля". Однако подавляющее большинство программистов, занимающихся разработкой, не имеют понятия о том, как правильно работать с деньгами в базе. Работа с финансами - удел экономистов и бухгалтеров, а не инженеров, и основам бухучета "технарей" никто не обучает. Ни один здравомыслящий человек по собственной воле не возьмет в руки учебник по бухучету.В рамках данного доклада я поделюсь с вами уникальным опытом работы с большим количеством разнообразных биллингов и систем учета денег. Этот опыт я получил в проектах нашей компании, участие в которых я принимал или продолжаю принимать. Проекты самые разные - начиная от классических партнерских программ и заканчивая соцсетями и собственной in-house системой учета финансов - разнообразие представленных видов крайне широко, и один не похож на другой.
Роман Друзягин
Технический директор в 404 Group
13 9999999900000 14 1165    Архитектуры 

#деньги

Архитектуры
Высоконагруженный проект должен не только предоставлять быстрый и качественный сервис, но и окупать себя. Нам приходится бороться не только за проценты, увеличивающие производительность и надежность, но и за процент проведенных транзакций. При большом объеме платежей разница в 1% может быть внушительной и окупать все затраты. Я расскажу о том, как устроен биллинг в таком большом международном проекте, как Badoo, расскажу про возникавшие по мере роста проблемы, продемонстрирую архитектуру, к которой мы в итоге пришли, и объясню, почему она получилась именно такой. Отдельная подтема - то, как мы «готовим» процессинг кредитных карт и как он устроен. Также я расскажу про рекуррентные платежи, процессе разработки и мониторинге.
Анатолий Панов
Ведущий разработчик в Badoo
14 9999999900000 15 1166    База данных, системы хранения 

#индексы

База данных, системы хранения
Я дам вводную информацию о B-деревьях и LSM-деревьях, в общих чертах объясню, как работают фрактальные деревья, чем они отличаются от B-деревьев и LSM-деревьев, и как мы используем их преимущества в плане производительности – как в достаточно очевидных ситуациях, так и в довольно нетривиальных, для поддержки новых возможностей MySQL и MongoDB в TokuDB и TokuMX.
Leif Walsh
Senior Software Engineer в Tokutek
15 9999999900000 16 1167    База данных, системы хранения 

#индексы

База данных, системы хранения
Правильная работа с индексами является ключевой составляющей производительности любой базы данных, и MySQL не исключение. Генеральный директор Percona Пётр Зайцев рассмотрит новые приёмы работы с индексами на базе улучшений оптимизатора MySQL 5.6. Вы узнаете: • как MySQL использует индексы для выполнения запроса;• как выработать оптимальную стратегию работы с индексами;• как понять, когда вам нужно добавить индекс; • как определить, какие индексы не нужны.
Петр Зайцев
CEO в Percona
16 9999999900000 17 1168    Архитектуры 

#карты

Архитектуры
Мы в Спутнике делаем карты на основе данных OpenStreetMap. Для отображения карты мы разработали распределенный горизонтально масштабируемый бэкенд, который из исходных данных формирует растровую карту.Я расскажу- о том, как устроен кластер генерации карт;- почему мы используем язык Go;- как мы тестируем нашу систему;- о нашем вкладе в Open Source.
Максим Дементьев
Ведущий разработчик в Картах в Sputnik.ru
17 9999999900000 18 1169    Смежные области 

#клиентсайд

Смежные области
"Что там писать клиентское приложение - вот сервер, который выдерживает 10 тысяч запросов в секунду!"... "Да они там только API делают, вот бы хоть одно приложение под iOS написали!"Подобный обмен претензиями частенько можно услышать в спорах клиентских и серверных разработчиков. В этом докладе я попробую примирить обе стороны. Только от успешного взаимодействия клиентского приложения и серверной части зависит успех высоконагруженного проекта в целом.* Как сделать так, чтобы клиент не "завалил" сервер?* Коммуникация ошибок от сервера к клиенту.* Синхронизация, разрешение конфликтов.* Работа в offline-режиме.* Разработка эффективного и корректного API.* Асинхронное взаимодействие.* Почему клиент и сервер на самом деле очень похожи?
Андрей Смирнов
Руководитель разработки в ex-Skype
18 9999999900000 19 1170    Фронтенд 

#клиентсайд

Фронтенд
Контроль над протоколом уровня приложения может помочь эффективно утилизировать нагрузку на канал с учетом характера передаваемых данных, обеспечить произвольное шифрование, контролировать состояние сессии, ввести полезные ограничения на формат передаваемых данных, дать независимость от недостатков существующих протоколов. Возможны и другие варианты получения пользы от такого контроля.Доклад будет полезен, если вас интересуют вопросы:- медиа-стриминга;- создания веб-приложений с высокой скоростью отклика;- создания веб-приложений с высоким потреблением полосы пропускания;- сетевого стека для онлайн-игр или других приложений с высокой плотностью событий;- обеспечения дополнительной безопасности канала;- DRM.Картинки, цифры и кейсы из нашего опыта идут в комплекте.
Илья Кутуков
Разработчик в Parallels
19 9999999900000 20 1171    Фронтенд 

#клиентсайд

Фронтенд
- Постановка проблемы: в чем сложность работы с большими объемами географических данных.- Отображение большого количества меток на клиенте - недостатки стандартных решений.- ObjectManager: рисуем много точек на клиенте.- Передача большого количества данных с сервера на клиент.- Организация хранения данных на сервере - пространственные базы данных и quad-ключи.- Организация серверной grid-кластеризации географических объектов.- Проблемы кэширования и версионирования данных.
Марина Степанова
Яндекс в Руководитель группы разработки API Яндекс.Карт.
20 9999999900000 21 1172    Смежные области 

#бизнес

#ит

#по

#разработка

Смежные области
На основе данных, накапливаемых и хранимых в инфраструктуре рекламной системы MAIL.RU (HDFS, поток данных ~100K записей в секунду), проводится машинное обучение классификаторов, позволяющих разделять различные группы пользователей Интернета. Для представления признаков, характеризующих конкретный обучающий прецедент, используется модель bag-of-words, в рамках которой векторы признаков имеют большую размерность и являются разреженными. Уменьшение размерности пространства признаков методом латентного размещения Дирихле (LDA) позволяет в ряде случаев также проводить тематическое моделирование распределения признаков. Рассматриваются две практические задачи: (1) разделение пользователей на два класса в соответствии с требованиями таргетированной рекламной кампании; и (2) предсказание месячного дохода пользователя.
Игорь Кретинин
Программист-исследователь в Mail.Ru Group
21 9999999900000 22 1173    Менеджмент 

#менеджмент

Менеджмент
Мы в Mail.Ru Group используем:- таск-трекер JIRA,- базу знаний Confluence,- инструмент планирования и контроля работы Greenhopper,- модуль тестирования Zephyr,- инструменты слежения за изменениями и просмотра кода Fisheye и Crucible,- средство построения графиков и диаграмм Gliffy,- систему непрерывной интеграции Bamboo.Цель доклада - показать, что многие задачи, которые традиционно делались вручную, можно относительно недорого автоматизировать, и JIRA с её экосистемой - подходящий для этого инструмент.
Александр Горный
CIO в Mail.Ru Group
22 9999999900000 23 1174    Тестирование 

#менеджмент

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

#менеджмент

Менеджмент
Для нас CD — это когда менеджер или релиз-менеджер с помощью одной «кнопки» может выкатить весь продукт «в бой». При высокой связности, распределённости продукта и всех проверках выполнить такую задачу непросто, и делается это небыстро.На примере Справочного API 2ГИС я расскажу, как мы сделали для менеджеров эту «кнопку». Расскажу про workflow, о том, как мы используем Jenkins для сборки, Rundeck для администрирования релиза, Яндек.Танк для нагрузок, Chef для конфигурирования серверов.
Денис Яковлев
Ведущий разработчик в 2ГИС
24 9999999900000 25 1176    Тестирование 

#менеджмент

Тестирование
В своем докладе я поделюсь опытом внедрения Continuous Integration в наши процессы. Я расскажу, как мы используем Jenkins в качестве CI-сервера, какие задачи мы решаем с его помощью и с помощью других инструментов. Вот основные из них:- развертывание и конфигурирование приложений и тестов с помощью Open Stack и Chef;- запуск функциональных тестов с помощью PHPUnit и параллельное выполнение с помощью Paratest;- обновление окружения и тестирование задачи в ветке с последующим вливанием в master-ветку;- ежедневная регрессия на master-ветке и откат до состояния последнего релиза, а также тестирование развертывания с нуля.Я затрону интеграцию с JIRA для наших процессов и решения других задач для разработки и тестирования.
Денис Трифонов
QA Engineer в 2GIS
25 9999999900000 26 1177    Архитектуры 

#общее

Архитектуры
Я расскажу...- о том, что общего у планировщика ОС, системных вызовов и асинхронного взаимодействия.- о том, как принципиально работает асинхронное взаимодействие.- о том, в условиях асинхронное взаимодействие приносит пользу.- о том, какие условия являются достаточными для комфортной работы с асинхронным взаимодействием и в чем "профит" от сопрограмм (coroutines).- о том, как можно "затупить" асинхронный сервер своими дополнениями или встраиваемыми сценариями (nginx, Tarantool).- о том, что делать, если "кусочек" кода "не хочет" быть асинхронным.- о том, что может пойти не так, как казалось.- о том, как я работал с async на Python и как работаю с ним сейчас.В итоге должно немного "попустить" или "накрыть", но непременно в удовольствие.
Вячеслав Турчанинов
Team Lead в Ratengoods.com
26 9999999900000 27 1178    База данных, системы хранения 

#общее

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

#общее

Учебный трек
a) Основные понятия и принципы работы брокера сообщений RabbitMQ.b) Описание работы обменников с типами Direct / Fanout / Topic.с) Практическое использование брокера RabbitMQ для отложенной обработки трудоемких операций.
Вячеслав Москаленко
Ведущий программист в Ленвендо
28 9999999900000 29 1180    Без секции 

#бизнес

#ит

#по

#разработка

Без секции
Круглый стол с Программным комитетом HighLoad++ о выборе технологий для проекта
Леонид Юрьев
Ведущий системный архитектор в ПЕТЕР-СЕРВИС
29 9999999900000 30 1181    Архитектуры 

#бизнес

#ит

#по

#разработка

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

#бизнес

#ит

#по

#разработка

Архитектуры
Я планирую рассказать о том, как мы строили этот сервис, с какими проблемами сталкивались и как их решали. Основные аспекты, которые будут затронуты в докладе:- чтение документов;- механизмы показа и редактирования;- построение document thumbnails;- методики обеспечения качества.Отдельно я разберу вопросы оптимизации, расскажу как найти 7% прироста производительности на пустом месте и как свести уровень ошибок чтения менее чем к 0.5%. Главные вопросы: как читать нечитаемое, как деградировать функционал и когда правильно ломаться и выдавать ошибку. Также я объясню, как контролировать систему и почему дублирование кода в некоторых ситуациях помогает.
Павел Зиновкин
Руководитель группы разработки в Mail.Ru Group
31 9999999900000 32 1183    Без секции 

#бизнес

#ит

#по

#разработка

Без секции
Обухов Дмитрий, Mail.RU: HighLoad для начинающих
Дмитрий Обухов
Программист в проекте Tarantool в Mail.ru Group
32 9999999900000 33 1184    Архитектуры 

#бизнес

#ит

#по

#разработка

Архитектуры
1Hippeus – инфраструктура обмена сообщениями, ориентированная на предельно эффективное zero-copy & lockfree-взаимодействие через разделяемую память, RDMA, MPI, коммуникации с GPU, сетевыми адаптерами, SDN & NFV, гипервизоры. Это инфраструктурный проект, который станет Open Source уже в первом релизе.Грубо говоря, 1Hippeus позволяет вам сформировать и передать сообщение в соседний поток (thread), в ядро или через гипервизор, в другой процесс или на другой сервер в кластере, с накладными расходами как при вызове функции.
Леонид Юрьев
Ведущий системный архитектор в ПЕТЕР-СЕРВИС
33 9999999900000 34 1185    Архитектуры 

#очереди

Архитектуры
Серверы вашей компании расположены по всему миру, и вам необходимо обрабатывать данные в едином месте. Приложения с разными технологическими стеками генерируют данные в самых разных местах - от веб-серверов до датчиков. Как бы вы стали решать эту проблему? Врубайтесь в RabbitMQ! В ходе доклада мы покажем, как построить систему, которая может собирать данные, генерируемые в удаленных географических точках, и копировать их в центральный кластер, где они в дальнейшем будут обрабатываться и анализироваться.Мы представим пример построения подобной системы с использованием RabbitMQ Federation для копирования данных из регионов AWS и реализованной в RabbitMQ поддержки множества протоколов для производства и потребления данных.Будет показан интересный способ реализации шардированных очередей с применением RabbitMQ и Consistent Hash Exchange, которые помогут нам с масштабированием.
Alvaro Videla
Developer Advocate в Pivotal Inc
34 9999999900000 35 1186    База данных, системы хранения 

#паттерны

База данных, системы хранения
MySQL - популярная СУБД, используемая во многих проектах. Разработчик Percona Server и инженер Mail.Ru Target расскажет про неудачные решения в репликации MySQL, объяснит её устройство, рассмотрит архитектурные проблемы, многопоточную репликацию в версии 5.7. После этого доклада слушатели поймут, почему это провал, как репликацию нужно было сделать правильно, и почему проект PostgreSQL избежал этих проблем.Мы обсудим:- что такое асинхронная репликация;- как устроена асинхронная репликация в MySQL;- какие ошибки проектирования были допущены;- как эти ошибки проявляются при использовании;- чем эти ошибки мешают эксплуатации;- почему параллельная репликация MySQL 5.7 не решает проблем, а лишь добавляет новые;- как проект PostgreSQL избежал этих ловушек.
Олег Царев
Ведущий разработчик Mail.Ru Target в Mail.Ru Group
35 9999999900000 36 1187    База данных, системы хранения 

#паттерны

База данных, системы хранения
Какая вообще в природе бывает репликация (sync vs. async vs. semisync, master-master vs. master-slave), как оно устроено конкретно в MySQL, в каких версиях что добавили. Про binary/relay log, про SBR/RBR/mixed форматы, про глупости с позициями и про GTID, про то, как из-за всяких бед возникают дополнительные продукты типа Tungsten и Galera. Несколько занятных фактов и парочка фокусов, которые можно учинять конкретно с MySQL-репликацией.Доклад вчистую про внутреннее устройство, по результатам должно появляться общее понимание того, как оно работает внутри и почему именно так. Конкретные SQL-операторы подробно рассматривать НЕ будем, эти скучные мелочи необходимо будет затем самостоятельно смотреть в документации (или не смотреть).
Андрей Аксенов
Основатель в Sphinx
36 9999999900000 37 1188    Архитектуры 

#паттерны

Архитектуры
Шардинг (метод распределения данных по разным узлам в горизонтально-машстабируемых архитектурах) является центральной темой для любого крупного проекта. Однако принципы и методы шардинга не зависят от стека технологий, поэтому формализация этих принципов в виде базовых "рецептов" (архитектурных паттернов) должна быть интересна максимально широкому кругу разработчиков. В докладе мы рассмотрим наиболее распространённые приемы шардинга и роутинга клиентов и покажем их основные "плюсы" и "минусы".
Константин Осипов
Open source developer, Tarantool.org в Mail.Ru
+ и ещё 1
Алексей РыбакDirector of technology в Badoo
37 9999999900000 38 1189    Системное администрирование 

#платформы

Системное администрирование
В рамках доклада будут рассмотрены:- кейс проекта ИМХОнет (www.imhonet.ru) с миграцией на гетерогенную инфраструктуру (общедоступное облако + выделенные серверы + облачное хранилище + CDN);- кейс проекта 4talk.im;- ряд других кейсов.Кроме того, будут даны практические рекомендации по выбору - "физика" или "облако", покупка или аренда, использование либо не использование CDN.
Игорь Мызгин
Работа с ключевыми клиентами и партнерами в Webzilla
38 9999999900000 39 1190    Системное администрирование 

#платформы

Системное администрирование
В тот момент, когда производительность и отказоустойчивость приложения становятся критически важной задачей, необходимо так же иметь возможность оценить надежность инфраструктуры, от которой в итоге зависит локальная и глобальная доступность вашего приложения. Для большинства эта задача сводится к выбору надежного хостинг-провайдера, имеющего хорошую связность в Рунете. У тех, кто уже не может позволить себе зависеть от хостинга, появляется задача регистрации и построения собственной автономной системы, имеющей хорошую связность. В рамках своего доклада я постараюсь рассказать о том, как можно оценить связность на уровне автономных систем и какие существуют архитектурные решения для повышения отказоустойчивости на сетевом уровне.
Александр Азимов
Ведущий инженер по эксплуатации сети Qrator в Qrator Labs
39 9999999900000 40 1191    Архитектуры 

#платформы

Архитектуры
Гипервизор сегодня превращается в commodity ("ширпотреб"), фактически производитель уже становится неважен. KVM становится одним из лучших выборов - надежный, функциональный, бесплатный, Open Source.Существенная проблема - для реальных применений (много серверов, виртуальных машин) требуется централизованное отказоустойчивое управление и "разделяемая" СХД, а также мониторинг, логирование,авторизация и прочее. Существующие на сегодня решения фрагментированы и решают только часть вопросов (или управление, или СХД), причем крайне неоптимально.Мы создали гибридное решение типа "все в одном".Nutanix - это программная платформа, изначально спроектированная для создания безлимитно масштабируемых "облаков".Отсутствуют практически все типичные узкие места.
Максим Шапошников
Technical Director EE and CIS в Nutanix
40 9999999900000 41 1192    Учебный трек 

#поиск

Учебный трек
Как построить примитивный самописный поиск за 1 час, как - за 1 вечер, что можно сделать за 1 неделю и когда это оправдано? Что еще, по идее, должен бы уметь Идеальный Поиск и когда лучше взять уже готовое, чем продолжать "пилить" свое? Чем внутри похожи, а чем-таки фундаментально отличаются Sphinx, Lucene и, как следствие, построенные поверх второго Solr, Elastic? Чем Sphinx и Lucene не менее фундаментально отличаются от движков, встроенных в СУБД? Как просто, быстро и абсолютно неправильно "забенчмаркать" разные решения при сравнении? Концепция marketing-driven defaults. Прочие большие (но нефундаментальные) текущие отличия движков, возможна спонтанная пятиминутка ненависти к Java-стеку в целом и саморекламы Sphinx. На сладкое - многогранный ответ на заглавный вопрос: так по каким же критериям выбирать поисковую технологию (очевидно, не техническим)?
Андрей Аксенов
Основатель в Sphinx
41 9999999900000 42 1193    Системное администрирование 

#процессы

Системное администрирование
Компания Intel недавно представила процессоры линейки Intel Xeon E5 v3. Новые процессоры отличаются надежной микроархитектурой, более быстрой памятью, более широкими шинами, большим количеством ядер, более высокой тактовой частотой. Благодаря нововведениям удалось добиться существенно повышения производительности.В нашем докладе мы подробно рассмотрим технологические новации от Intel, опишем преимущества новых процессоров по сравнению с предыдущими поколениями. Мы также продемонстируем, как благодаря этим новациям можно улучшить работу серверных приложений.
Дмитрий Радожицкий
Системный инженер в Selectel
42 9999999900000 43 1194    Системное администрирование 

#процессоры

Системное администрирование
- Немного истории: как появилась компания МЦСТ - основные вехи.- Что сделано на сегодня: линейки процессоров, особенности архитектуры Эльбрус, оценка производительности.- Планы на ближайшее будущее, новые модели процессоров.- Когда можно ожидать появления массовых и дешёвых машин на основе процессоров Эльбрус.
Константин Трушкин
Помощник генерального директора в МЦСТ
43 9999999900000 44 1195    Учебный трек 

#процессоры

Учебный трек
* Выравнивание данных и оптимизация работы кэшей процессора, оптимизация для NUMA.* CPU-binding (привязка потоков/процессов и прерываний к процессорам).* Lock-free структуры данных (атомарные операции, барьеры памяти).* Векторные операции.* Cache-concious и cache-oblivious структуры данных.* Транзакционная память (Intel TSX).
Александр Крижановский
Основатель и системный архитектор в NatSys Lab
44 9999999900000 83 1452    Архитектуры 

#инновации

#ит

#облако

#сети

Архитектуры
Виртуализация сетевых функций (NFV) - это одна из самых широко обсуждаемых тем в мире компьютерных сетей. Суть NFV заключается в переносе сетевых сервисов типа анализаторов трафика, файерволов, балансировщиков нагрузки, работающих сейчас на специализированном железе, в центры обработки данных, работающие на традиционном серверном оборудовании. Теперь все сетевые сервисы реализуются программно и запускаются на виртуальных машинах, тем самым достигается гибкость развертывания и масштабирования в зависимости от нагрузки и требуемой производительности. В итоге стоимость конечного решения уменьшается на порядок.
Александр Шалимов
Ведущий программист-разработчик в ЦПИКС
45 9999999900000 45 1196    Смежные области 

#бизнес

#ит

#по

#разработка

Смежные области
Большинство проектов с активной email-рассылкой рано или поздно сталкивается с тем, что почтовые сервисы начинают помещать их письма в "Спам" из-за низкого отклика на рассылку. В таких случаях необходимо заметно повысить CTR (кликабельность) рассылки.Как это сделать так, чтобы при этом не пострадала общая активность пользователей на сайте? Какие данные и как хранить о пользователях, чтобы это было возможно?О чем я расскажу в данном докладе?1. О традиционных подходах и попытках их применения в Badoo.2. О новом подходе, давшем ошеломительный эффект, - выборе частоты рассылки на основании прошлой активности пользователя.3. Техническом устройстве системы, обеспечивающей хранение данных об активности пользователей с email-рассылкой.
Андрей Сас
Email Product Manager в Badoo
46 9999999900000 46 1197    База данных, системы хранения 

#бизнес

#ит

#по

#разработка

База данных, системы хранения
Я расскажу о том как создать базу данных под задачу не решающуюся средствами SQL и как не влипнуть в велосипедостроение и долгострой :) Решение о котором я расскажу было разработано и вышло в продакшн за пару месяцев и окупилось ещё за пару месяцев. Описание проблемы1. Нужно отослать пользователю уведомление о том, что появились билеты, соответствующие его параметрам. 2. У Aviasales очередь с результатами поисков, и каждый совершённый поиск авиабилетов добавляет в эту очередь json-документ размером 200-800 Кб, который содержит тысячи билетов и довольно сложно структурирован.3. В базе подписок - миллионы записей, при этом одна подписка состоит из нескольких предикатов.В итоге мы имеем поток огромных документов, каждый из которых нужно проверять на соответствие миллионам предикатов.
Борис Каплуновский
Веб-разработчик в Aviasales
47 9999999900000 47 1198    Архитектуры 

#рост

Архитектуры
PostgreSQL играет важнейшую роль в инфраструктуре Zalando: там хранится всё – от информации о клиентах и до данных статей, а также PostgreSQL обеспечивает надёжное резервирование нашим системам управления складами, работающим в реальном времени. Начиная с версии 9.0 мы используем каждый релиз PostgreSQL в продакшне, и с каждым следующим релизом PostgreSQL нравится нам всё больше и больше.Я хочу рассказать о том, как мы развёртываем, настраиваем, мониторим и используем базы данных PostgreSQL для обеспечения работы наиболее быстро растущей и самой крупной в Европе платформы электронной коммерции в области моды.Список вопросов, освещаемых в докладе:• доступ к шардированным и распределённым данным;• как мы управляем сотнями изменений в базе данных, вносимых сотнями разработчиков каждую неделю;• запуск наших баз данных с минимальным временем простоя;• настройка, контролирование и мониторинг более 100 master-экземпляров базы данных и сотен реплик в нескольких дата-центрах.
Valentine Gogichashvili
Lead Database Engineer в Zalando GmbH
48 9999999900000 48 1199    Архитектуры 

#рост

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

#рост

Архитектуры
Мы записываем и анализируем около 1 млрд. событий в месяц, и эта цифра растет. Это данные с наших плееров, iOS-приложения и сайта. С таким объемом любой сторонний сервис будет стоить очень дорого и при этом будет сильно ограничен по возможностям. Прошло уже больше года с тех пор, как мы построили и успешно используем своё решение для анализа таких событий.Доклад про: – развитие архитектуры этой системы: как менялись и как будут меняться требования к такого рода системам;– анализ подходящих под эту систему СУБД - с их проблемами и опытом реальной эксплуатации;– почему мы остановились на MongoDB, со всеми минусами её и плюсами;– немного про команду, трудозатраты и поддержку;– рассказ о том, как мы используем эту систему и как она помогает растить наши продукты.
Михаил Табунов
CTO & Founder в coub.com
50 9999999900000 50 1201    Архитектуры 

#скорость

Архитектуры
ЦЕЛЬРеализация узла PCRF согласно спецификации 3GPP для обслуживания 60 миллионов абонентов оператора связи. Упрощенно PCRF – это приложение, которое принимает решение о скорости предоставления услуги абоненту. При принятии решения учитываются такие факторы, как тарифный план абонента с его опциями и турбо-кнопкой, его местоположение в сети, перегруженность сети и другие. К приложению предъявляются следующие требования: поддержка георезервирования, масштабирования, резервирования внутри одного дата-центра, а также работа в режиме 24/7, обеспечение скорости реакции, близкой к real-time, обслуживание не менее 10К запросов в секунду на одном узле.Реализованное решение развернуто на 190 узлах в 14 дата центрах и успешно запущено с требуемой производительностью каждого узла. Более подробно о каждом решении и его влиянии на конечную систему будет рассказано на докладе.
Артем Руфанов
Технический специалист в ПЕТЕР-СЕРВИС
51 9999999900000 51 1202    Смежные области 

#скорость

Смежные области
Real-time bidding требует real-time аналитики. RuTarget обрабатывает миллиард запросов на показ баннеров в день. Как определить, например, сколько в этих запросах уникальных пользователей? Доступно расскажем о рандомизированных алгоритмах потоковой обработки данных, вероятностных структурах данных и объясним, как быстро и с вычислительной точки зрения дешево получить нужный результат. Основные тезисы1) Какие данные у нас есть, и почему их много?2) Trade-off: точность vs. нагрузка на инфраструктуру.3) Вероятностные структуры данных для data mining - что это такое?4) HyperLogLog - метод подсчета числа уникальных элементов в потоке данных.5) Large scale, временное окно.6) Примеры из реальной жизни.7) Count-Min, Summary-Sketch и т.д.
Павел Калайдин
Data Scientist в RuTarget
52 9999999900000 52 1203    Архитектуры 

#скорость

Архитектуры
При построении современных RTB-решений предъявляются особые требования к производительности компонентов, которые обслуживают поступающие запросы на показ рекламы. Каждая из систем в цепочке обработки входящего запроса должна обслуживать десятки и сотни тысяч запросов в секунду c временем отклика, не превышающим 20 мс.Мы расскажем о том, как построили сервис обогащения пользовательских профилей в режиме реального времени, о том, какие технологии мы при этом использовали, и о том, как выбрали Аerospike в качестве NoSQL-хранилища для решения данной задачи. В рамках доклада будут продемонстрированы таблицы со сравнением функциональных возможностей Aerospike, CouchDB, MongoDB, Redis, а также графики производительности Аerospike по сравнению с другими NoSQL-решениями.
Сергей Жемжицкий
Технический директор в CleverDATA
53 9999999900000 53 1204    База данных, системы хранения 

#хранилище

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

#хранилище

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

#хранилище

База данных, системы хранения
Когда количество пользовательского статического контента на проекте начало превышать возможности используемых нами серверов, мы задумались о будущем и решили масштабироваться не вертикально, а горизонтально. Обычный в современном мире способ горизонтального масштабирования подобного рода хранилища - использование так называемого Object Storage, распределенной системы хранения, строящейся на базе относительно дешевых узлов, имеющей S3 или REST-интерфейс.Все современные объектные хранилища устроены почти одинаково - они состоят из сервера метаинформации (выделенного сервера может и не быть, поскольку он является единой точкой отказа, и его нужно обязательно резервировать), маршрутизатора запросов к серверам хранения и серверов хранения с локальными хранилищами. Далее начинаются отличия, по сумме результатов анализа которых нами и была выбрана LeoFS (кстати, сейчас она уже работает у нас в продакшне и хранит несколько терабайт пользовательских данных).
Александр Чистяков
Главный инженер в Git in Sky
56 9999999900000 56 1207    Архитектуры 

#bigdata

Архитектуры
ТезисыМы используем Hadoop для сохранения всего click stream с сайта и серверов мобильных приложений - это порядка 1 миллиарда событий в день. А еще мы собираем и анализируем действия пользователей с северной и клиентской стороны - это еще порядка миллиарда событий в день.Как все это организовать, запустить и использовать, что можно и что нельзя сделать с помощью Hadoop - об этом будет мой доклад.ОписаниеВ Badoo мы собираем и анализируем большое количество статистической информации. Настолько большое, что сейчас мы просто обязаны думать о масштабировании и параллелизации систем сбора, хранения и отчетов (reporting). Именно для хранения более полной информации, облегчения масштабирования и ускорения получения отчетов мы стали применять Hadoop. Каких результатов мы смогли добиться, какие задачи еще стоят перед нами и какие ограничения мы выявили для себя - обо всем этом я и расскажу в докладе.
Валерий Старынин
PHP Developer в Badoo
57 9999999900000 57 1208    Архитектуры 

#bigdata

Архитектуры
В своем докладе я расскажу о такой непростой задаче, как обсчет и анализ трафика многих клиентов под очень высокими нагрузками и при практически полном отсутствии расходов на дополнительные серверы под статику. Задача усложняется тем, что все клиенты отдаются со всех серверов, а статистика ведется по отдельным субдоменам. Сбор статистики многоуровневый - скорость отдачи, коды ошибок HTTP, количество отданных байтов и ряд других параметров с 5-минутными интервалами. Основные подтемы доклада- В чем проблема подхода, включающего парсинг логов?- Чем хороши, а чем не очень инструменты работы с логами?- Что получается, если объем собираемых в день логов составляет около 70 Тб?- Плюсы и минусы универсальных решений типа Hadoop для такой задачи.- Наш подход к интеграции MapReduce в nginx.- Почему одного сервера достаточно, чтобы считать 50 гигабит трафика в секунду и более 7 миллиардов хитов в день?
Станислав Николов
ИТ-Специалист в UCDN.com
58 9999999900000 58 1209    Смежные области 

#bigdata

Смежные области
На основе модели вычислений MapReduce производится обработка логов дарения подарков ОК, хранящихся на Hadoop-кластере для фильтрации и расчета меры схожести подарков. Подготовленные данные кластеризуются на суперкомпьютере с использованием библиотеки MCL.
Артур Кадурин
Data Scientist в Mailru Group
59 9999999900000 59 1210    Смежные области 

#ddos

Смежные области
Что делать, когда атака началась?Какие шаги необходимо предпринять для фиксации доказательной базы?Как можно рассчитать ущерб и облегчить работу правоохранительным органам?Кейсы расследований реальных DDoS-атак разного типа.
Дмитрий Волков
Руководитель направления Anti-Piracy в Group-IB
60 9999999900000 60 1211    Смежные области 

#ddos

Смежные области
В докладе мы расскажем о современных методах DoS- и DDoS-атак и о способах защиты от них с точки зрения системных администраторов и специалистов по ИБ. Мы продемонстрируем на стенде модель enterprise-сети и в ходе презентации будем осуществлять реальные атаки на инфраструктуру и приложения с помощью продуктов Ixia. Рассмотрим различные виды атак и продемонстрируем, как "отбивают" эти атаки те или иные продукты (межсетевые экраны, системы предотвращения вторжений, средства защиты от DDoS, Web Application Firewall). Также мы затронем способы защиты приложений от Zero-day уязвимостей с помощью этих продуктов.
Александр Власов
Системный инженер в Treatface
61 9999999900000 61 1212    Системное администрирование 

#ddos

Системное администрирование
Как обычно, подведем итоги года с аналитикой за 10 прошедших месяцев 2014 года. Расскажем про текущие тренды DDoS-атак и объясним, как это соотносилось с внешнеполитическими событиями и экономикой.Проведем разбор типовых ошибок, которые стали причиной самых громких #tangodown этого года.Расскажем о том, почему UDP Amplification медленно, но верно подходит к своему логическому завершению. Обсудим самые перспективные вектора угроз 2015 года и представим BCOP (best common practices) для безопасного функционирования ваших приложений с учетом новых угроз.
Александр Лямин
Генеральный директор в Qrator Labs
62 9999999900000 62 1213    Системное администрирование 

#ddos

Системное администрирование
Tempesta FW - это Open Source гибрид HTTP-акселератора и файервола, специально разработанный для предотвращения DDoS уровня приложения и построения высокопроизводительных Web Application Firewalls (WAF). Проект работает на Synchronous Sockets - сокетном API, полностью встроенном в TCP/IP стек операционной системы, и использует самую быструю на данный момент реализацию конечного автомата разбора HTTP-сообщений.Tempesta позволяет фильтровать трафик от 3-го (IP) до 7-го (HTTP) уровней, а для облегчения реализации кастомных модулей классификации трафика и реализации модулей типа ICAP предоставляет интерфейс Generic FSM, позволяющий переключать контексты разных машин состояний (например машины состояний для ICAP и для HTTP). В пакете уже есть простой фильтр смягчения последствий DDoS (DDoS mitigation filter).
Александр Крижановский
Основатель и системный архитектор в NatSys Lab
63 9999999900000 63 1214    Системное администрирование 

#docker

Системное администрирование
Описание основных аспектов доклада:- краткая справка: Docker, Puppet;- зачем мы начали использовать еще одну технологию;- как сделать перезапуск сервиса без downtime;- забота об окружающей среде: используй всю мощность сервера;- etcd & confd: если уже слышали, поговорим об этом вместе;- почему Puppet все еще важен и нужен;- чего не хватает для счастья в Docker.
Антон Турецкий
System engineer в Badoo
64 9999999900000 64 1215    База данных, системы хранения 

#galera

База данных, системы хранения
Данный доклад касается тестирования устойчивости системы Galera к партиционированию. Docker и Netem/tc (управление трафиком) играет значительную роль в данном случае. Будут рассмотрены основные результаты исследований.* Применение коэффициентов потерь с распознаванием сегментов WAN для виртуальных сетевых интерфейсов.* Разные периоды синхронизации после устранения помех в сети.* Потеря многих нод с кратковременным всплеском помех против потери одной ноды и более длительных помех. * Полнодуплексная связь контейнеров с dnsmasq.* Влияние внесетевых факторов – таких, как скорость работы дисков, – на fsync.* Распределение запросов по нодам по алгоритму round-robin при наличии/без нод с отказами сети в цепи.* Горизонтальное масштабирование тестовых нод и проблемы с Docker/namespace.
Raghavendra Prabhu
Product Lead в Percona
65 9999999900000 65 1216    Архитектуры 

#go

Архитектуры
Поскольку рост проекта Hailo обеспечил ему глобальное присутствие, нам пришлось пересмотреть наш подход к технологиям. Мы решили уйти от монолитного приложения на PHP и Java и внедрить нативную поддержку «облаков», и проект Hailo перешёл на новую платформу микросервисов, работающую на трех континентах и почти полностью построенную на Go. В данном докладе я расскажу, как мы разработали архитектуру микросервисов и впоследствии перешли на неё, перечислю распространенные ошибки и объясню, как их избежать, и поделюсь уроками, которые мы извлекли из разработки на Go распределенных приложений, рассчитанных на обработку больших объёмов данных с минимальной задержкой.
Matt Heath
Distributed Systems Engineer в Hailo
66 9999999900000 66 1217    Смежные области 

#js

Смежные области
Тезисы1. Эмуляторы на JavaScript - что это такое? Как они работают?1.1 Принципы работы.1.2. PCE.JS - общая информация.1.3. Пути практического применения.2. PCE.JS и интеграция с DOM-моделью.2.1. Структура PCE.JS и эмуляции.2.2. Модифицируем аппаратные прерывания.2.3. "Среда разработки".3. Возможные пути практического применения.3.1. Защита и обфускация front-end-связанной логики - насколько это возможно на самом деле?3.2. Benchmarks.3.3. Другие пути применения.
Евгений Потапов
Генеральный директор в ITSumma
67 9999999900000 67 1218    Архитектуры 

#js

Архитектуры
Из данного доклада вы узнаете, как мы интегрировали JS-движок в HTTP-прокси, какой опыт получили, добавив исполнение динамического языка на наш ключевой уровень прокси, как боролись с прекращением работы JavaScript и проблемами сборки мусора, и, наконец, как нам удалось ещё больше сократить время задержки.
Brian Geffon
Staff Software Engineer в LinkedIn
68 9999999900000 68 1219    Учебный трек 

#mongodb

Учебный трек
MongoDB имеет горизонтально масштабируемую архитектуру. Шардируя свой MongoDB-кластер, вы можете увеличить его вычислительные мощности, будь то дисковое пространство, ОЗУ или ЦП. Шардинг – встроенная функциональность, шардинг и решардинг для данных выполняется автоматически, и возможность подключения к клиенту совершенно прозрачна.Выбор ключа шардирования – ключевой архитектурный вопрос, который требует особенно тщательного обдумывания, поскольку в дальнейшем его нельзя будет изменить. Tag Aware Sharding (шардинг с учётом тэгов) – простой, но эффективный инструмент, который позволит учесть на стадии проектирования специфические потребности – например, убедиться, что главная нода для данных пользователя находится на том же континенте, что и пользователь, отделить текущие шарды от архивных и т.д.
Henrik Ingo
Solution Architect в MongoDB
69 9999999900000 69 1220    База данных, системы хранения 

#mongodb

База данных, системы хранения
Системы шардинга и репликации MongoDB являются в некотором смысле противоположностями: одна повышает надёжность и помогает масштабировать рабочие нагрузки по чтению путём копирования данных на большее количество машин, а другая вводит больше точек на отказ и помогает масштабировать рабочие нагрузки по записи и вычислительные мощности путем деления поступающих данных между отдельными машинами. В большинстве реализаций пользователи MongoDB, применяющие шардинг, используют и репликацию, что приводит к увеличению количества необходимого аппаратного обеспечения в разы. По этой причине системы с сотнями и тысячами машин не так уж редки.
Leif Walsh
Senior Software Engineer в Tokutek
70 9999999900000 70 1221    Учебный трек 

#mongodb

Учебный трек
MongoDB имеет горизонтально масштабируемую архитектуру. Шардируя свой MongoDB-кластер, вы можете увеличить его вычислительные мощности, будь то дисковое пространство, ОЗУ или ЦП. Шардинг – встроенная функциональность, шардинг и решардинг для данных выполняется автоматически, и возможность подключения к клиенту совершенно прозрачна.Выбор ключа шардирования – ключевой архитектурный вопрос, который требует особенно тщательного обдумывания, поскольку в дальнейшем его нельзя будет изменить. Tag Aware Sharding (шардинг с учётом тэгов) – простой, но эффективный инструмент, который позволит учесть на стадии проектирования специфические потребности – например, убедиться, что главная нода для данных пользователя находится на том же континенте, что и пользователь, отделить текущие шарды от архивных и т.д.
Henrik Ingo
Solution Architect в MongoDB
71 9999999900000 71 1222    Учебный трек 

#mysql

Учебный трек
Данный доклад в формате мастер-класса охватывает следующие темы:- ваши вопросы о производительности, высокой доступности, безопасности и масштабируемости ваших приложений;- инструменты и практики, о которых вам необходимо знать - такие, как репликация, кластеризация, кэширование и буферизация;- наиболее часто используемые программные пакеты, которые позволяют внедрить данные архитектурные паттерны в ваших приложениях.По окончании данного мастер-класса вы будете в курсе того, какому процессу следовать и какие инструменты вы должны иметь в своём стеке, чтобы эффективно проектировать или перепроектировать ваши приложения с использованием MySQL.
Петр Зайцев
CEO в Percona
72 9999999900000 72 1223    Без секции 

#бизнес

#ит

#по

#разработка

Без секции
Алексей Копытов, Percona: Проблемы эффективного использования MySQL на современном оборудовании
Алексей Копытов
Ведущий разработчик в Percona
73 9999999900000 73 1224    База данных, системы хранения 

#mysql

База данных, системы хранения
Хотя MySQL и является рекордсменом по числу доступных утилит резервного копирования, выбор той или иной утилиты является нетривиальной задачей. В данном докладе мы поговорим о создании резервных копий высоконагруженных MySQL-серверов - в частности, о следующих вопросах:- что выбрать: mysqldump, mydumper, mylvmbackup, XtraBackup или коммерческие решения?- оптимизация резервного копирования больших объёмов данных;- проблемы блокировок сервера во время создания резервных копий;- проблемы, связанные с большим количеством таблиц;- эффективное создание инкрементальных резервных копий;- эффективное создание частичных резервных копий и частичное восстановление;- проверка целостности резервных копий на больших объёмах данных;- хранение резервных копий в "облаках".
Алексей Копытов
Ведущий разработчик в Percona
74 9999999900000 74 1225    База данных, системы хранения 

#postgresql

База данных, системы хранения
Диски, память, цена, процессор - в таком порядке смотрят на характеристики сервера админы, покупающие машину под базу данных. Как эти характеристики взаимосвязаны? Почему именно они?В докладе будет объяснено, для чего нужен диск базе данных вообще, как PostgreSQL взаимодействует с ним и в чем заключаются особенности PostgreSQL по сравнению с другими базами."Железо", настройки операционной системы, файловой системы и PostgreSQL: как и для чего выбирать хороший setup, что делать, если конфигурация "железа" не оптимальна, и какие ошибки могут сделать бесполезным самый дорогой RAID-контроллер. Увлекательное путешествие в мир батареек, "грязных" и "чистых" страниц, хороших и плохих SSD-дисков, покрасневших графиков мониторинга и ночных кошмаров системных администраторов.
Илья Космодемьянский
Генеральный директор в PostgreSQL-Consulting
75 9999999900000 75 1226    База данных, системы хранения 

#postgresql

База данных, системы хранения
Встроенная поддержка json в PostgreSQL - это уже свершившийся факт, который каждый может осознать, установив версию 9.4. Новый тип данных jsonb имеет эффективное бинарное хранилище, что делает доступ к нему в десятки раз быстрее текстового типа json, а индексная поддержка поисковых операторов jsonb приводит к их тысячекратному ускорению, что делает PostgreSQL серьезным конкурентом MongoDB - признанному лидеру мира NoSQL баз данных. Следующий проект носит исследовательский характер, но мы ожидаем от него серьезных результатов. В процессе работы над jsquery и индексами, мы поняли проблемы и ограничения существующих индексных методов доступа и поэтому придумали новый индекс – VODKA! Рассмотрим один мотивирующий пример.
Олег Бартунов
Научный сотрудник в ГАИШ МГУ
+ и ещё 1
Александр КоротковВедущий разработчик в Интаро
76 9999999900000 76 1227    База данных, системы хранения 

#postgresql

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

#spdy

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

#бизнес

#ит

#по

#разработка

Архитектуры
На сегодняшний день наиболее популярным алгоритмом сжатия отправляемых с веб-сервера данных является gzip. Но существует еще несколько новых направлений, на которые стоит обратить внимание при отправке большого количества данных в нагруженных системах. Этот доклад будет посвящен новому протоколу сжатия данных SDCH (общий словарь сжатия для HTTP) http://groups.google.com/group/SDCH. Этот протокол мы экспериментально внедрили для статического англоязычного контента (7 тысяч JavaScript-файлов, 2 тысячи CSS-файлов) в компании LinkedIn, и результаты нас приятно удивили.Почему это интересно: - это абсолютно новый способ сжатия передаваемых данных;- практически никто еще не использует этот способ, кроме Google Search;- мы хотим уменьшить время загрузки ресурсов веб-приложения; - в мире все еще много людей, которые не имеют доступа к сетям с быстрым Интернетом.
Дмитрий Маркович
Разработчик в LinkedIn
79 9999999900000 79 1230    Архитектуры 

#ssd

Архитектуры
В своем докладе я поделюсь опытом разработки и внедрения модуля для прозрачного SSD-кэширования в nginx. Такой модуль через добавление одного или нескольких SSD позволяет поднять производительность I/O операций на перегруженном веб-сервере, не внося изменений в application layer.В докладе будет рассказано- о том, что кэшируемо, а что нет;- о том, какие алгоритмы кэширования применимы для файлов;- почему важно кэшировать прозрачно для application layer;- о том, как мы реализовали алгоритм кэширования в модуле SSD Cache;- о том, что мы дописали в nginx для работы этого модуля;- результаты практического использования в production;- планы на дальнейшее развитие и возможное открытие кода (если будет достаточно интереса).
Станислав Николов
ИТ-Специалист в UCDN.com
80 9999999900000 80 1231    База данных, системы хранения 

#ssd

База данных, системы хранения
В последние годы на рынке появилось много решений хранения данных на технологии Flash. Это разнообразие сложно и даже коварно - неверно выбрав решение, можно столкнуться с неожиданными проблемами производительности, а то и просто потерять базу данных.В данной презентации мы рассмотрим критерии, по которым разумно выбирать Flash-накопители для баз данных, основные варианты технологий Flash, которые сейчас доступны на рынке, их преимущества и недостатки. Мы также рассмотрим разумные варианты конфигурации как самих накопителей, так и файловой системы, и отдельно остановимся на использовании Flash вместе с обычными дисками для построения наиболее эффективных систем.
Петр Зайцев
CEO в Percona
81 9999999900000 81 1232    База данных, системы хранения 

#бизнес

#ит

#по

#разработка

База данных, системы хранения
"Авито" является одной из крупнейших интернет-компаний РФ. Наш сайт регистрирует сотни миллионов событий в сутки. Руководству необходима развернутая отчетность об интернет-трафике, в том числе о количестве уникальных посетителей и сессий. Отчетность должна быть очень детализированной, точной, допускать разнообразный ad-hoc анализ. Главная проблема в расчете подобной аналитики - количество уникальных посетителей не аддитивно по иерархическим измерениям (география, продуктовый каталог и т.п.).Вертика отлично справляется с поддержкой аддитивных мер на десятках миллиардов строк исходных данных, но когда возникла необходимость поддерживать не аддитивные меры, считающиеся по иерархическим измерениям, нам пришлось реализовать аналог алгоритма MapReduce поверх SQL-движка HP Vertica.
Николай Голов
Архитектор хранилища данных в Avito
82 9999999900000 82 1233    Смежные области 

#бизнес

#ит

#по

#разработка

Смежные области
Построение беспроводных сетей для массовых мероприятий, стадионов, выставок предполагает наличие особых требований к инфраструктуре. Классические enterprise-решения с централизованным контроллером и множеством относительно маломощных точек доступа тяжело масштабируются для большого числа пользователей. В нашем докладе мы расскажем о создании сети беспроводного доступа на выставке Highload++ и о тонкостях реализации подобных решений. Часть доклада будет посвящения трудностям развертывания таких решений для массовых мероприятий - включая миграцию пользователей, переменную плотность, всплески активности в ходе презентаций и выступлений. Расскажем про интересные технологии современных Wi-Fi сетей - формирование лучей, geofencing, подавление Rogue AP, равномерную балансировку пользователей по частотным каналам.
Александр Павлов
Системный инженер в Treatface