Andrey Varenyk "Neo4j for resolving graph-based problems"Fwdays
A real case of company Turisto (air ticket sale). How to find the best routes from millions of variants in a few seconds. Why neo4j good for this task compared to other approaches and of course about results in numbers.
The talk is intended for everyone who has experience or interested in graph databases.
«Дорожная сеть в графовой базе данных Neo4j» — Вадим Шашенко, 2ГИС2ГИС Технологии
В своем докладе я расскажу, почему мы выбрали графовую базу данных Neo4j для проверки дорожного графа городов России (все населенные пункты с населением больше 300 000 жителей). Основные задачи, которые мы решаем средствами Neo4j — это проверки на связность и доступность проезда.
Опорные пункты доклада:
— SQL против графовых баз данных;
— обзор графовой базы данных neo4j;
— архитектура решения, в котором используется графовая БД;
— выполнение алгоритмов на графе в условиях его частых изменений.
В основе доклада лежат результаты работы над проектом «Fiji». Это внутрикорпоративная система, которая позволяет штатным картографам 2ГИС создавать, хранить и экспортировать карту во внешние продукты: онлайн-, десктоп- и мобильную версии 2ГИС.
Эволюция клиентской разработки: от веба ко "всеобщей мобилизации” или mobile-...Pavel Dovbush
История развития проекта с точки зрения клиентских технологий - от веб-сайта к появлению мобильных клиентов и смещению фокуса к mobile-first разработке. Общие черты нашей архитектуры и их отличия от стандартных решений.
Единый протокол общения с приложениями iOS/Android/WindowsMobile/MobileWeb/Web и особенности реализации для JavaScript платформ (десктопные и мобильные браузеры).
Изменение процесса разработки и подходов к реализации нового функционала для переключения на mobile-first стратегию.
Мастер-класс по BigData Tools для HappyDev'15Alexey Zinoviev
Данила, BigData Tool Master,
собрал Hadoop - кластер,
Запустил Dataset
Он скрипты на Scala
Run'ил на Spark постоянно
И писал в HDFSssss
Если во время доклада "Когда все данные станут большими..." мы будем говорить о вопросах и ответах, то на этом мастер-классе мы уже потопчемся в вотчине BigData-разработчиков.
Начнем с классики на Hadoop, познаем боль MapReduce job, потыкаем Pig + Hive, затем плавно свальсируем в сторону Spark и попишем код в легком и удобном pipeline - стиле.
Для кого хорошо подходит данный мастер-класс: вы умеете читать и понимать код на Java на уровне хотя бы Junior, умеете писать SQL-запросы, в универе вы ходили хоть на одну пару по матану или терверу, вас либо недавно поставили, либо вскоре поставят на проект, где надо уметь ручками работать с вышеперечисленным зверинцем. Ну или вам просто интересно посмотреть на мощь даннодробилок, написанных на Java, и у вас в анамнезе неудачный опыт с NoSQL/SQL, как хранилищем, которое было ответственно за все, включая аналитику.
HappyDev'15 Keynote: Когда все данные станут большими...Alexey Zinoviev
Этот момент обязательно наступит, если ваш проект, ваш бизнес сделаны не для того, чтобы вспыхнуть Фениксом в пламени бюджетов. Его важно не пропустить и начать обряд масштабирования как можно раньше.
Однако, не для каждой ситуации может подойти простое натравливание Hadoop на ваши логи, перелив данных из PostgreSQL в Cassandra или беспощадный тюнинг nginx и JVM.
Всегда стоит идти от задач, от представления о системе аналитики или от определенного заранее уровня отзывчивости системы. В этом докладе я хотел бы сосредоточиться не на инструментарии, столь важном для разработчика, а, напротив, поговорить о различных типах вопросов и болей с которыми приходят к нам заказчики в реальном мире, где никому нет дела до ваших результатов на Kaggle (онлайн-олимпиада по анализу данных) и синтетических тестов производительности, а также о процессе поиска ответов на эти вопросы. В реальном мире конечная идея приложения может измениться до неузнаваемости в один момент.
Приходите, разберем как хорошие случаи, так и типичные ошибки в построении приложений.
Для кого хорошо подойдет данный доклад: для тех, кто не слишком знаком с концепцией BigData, либо хорошо знаком с инструментарием разработчика, но нет определенной ясности в том, а для чего все это нужно. Ну и если вы идете на мастер-класс, то заходите, лишним не будет.
Andrey Varenyk "Neo4j for resolving graph-based problems"Fwdays
A real case of company Turisto (air ticket sale). How to find the best routes from millions of variants in a few seconds. Why neo4j good for this task compared to other approaches and of course about results in numbers.
The talk is intended for everyone who has experience or interested in graph databases.
«Дорожная сеть в графовой базе данных Neo4j» — Вадим Шашенко, 2ГИС2ГИС Технологии
В своем докладе я расскажу, почему мы выбрали графовую базу данных Neo4j для проверки дорожного графа городов России (все населенные пункты с населением больше 300 000 жителей). Основные задачи, которые мы решаем средствами Neo4j — это проверки на связность и доступность проезда.
Опорные пункты доклада:
— SQL против графовых баз данных;
— обзор графовой базы данных neo4j;
— архитектура решения, в котором используется графовая БД;
— выполнение алгоритмов на графе в условиях его частых изменений.
В основе доклада лежат результаты работы над проектом «Fiji». Это внутрикорпоративная система, которая позволяет штатным картографам 2ГИС создавать, хранить и экспортировать карту во внешние продукты: онлайн-, десктоп- и мобильную версии 2ГИС.
Эволюция клиентской разработки: от веба ко "всеобщей мобилизации” или mobile-...Pavel Dovbush
История развития проекта с точки зрения клиентских технологий - от веб-сайта к появлению мобильных клиентов и смещению фокуса к mobile-first разработке. Общие черты нашей архитектуры и их отличия от стандартных решений.
Единый протокол общения с приложениями iOS/Android/WindowsMobile/MobileWeb/Web и особенности реализации для JavaScript платформ (десктопные и мобильные браузеры).
Изменение процесса разработки и подходов к реализации нового функционала для переключения на mobile-first стратегию.
Мастер-класс по BigData Tools для HappyDev'15Alexey Zinoviev
Данила, BigData Tool Master,
собрал Hadoop - кластер,
Запустил Dataset
Он скрипты на Scala
Run'ил на Spark постоянно
И писал в HDFSssss
Если во время доклада "Когда все данные станут большими..." мы будем говорить о вопросах и ответах, то на этом мастер-классе мы уже потопчемся в вотчине BigData-разработчиков.
Начнем с классики на Hadoop, познаем боль MapReduce job, потыкаем Pig + Hive, затем плавно свальсируем в сторону Spark и попишем код в легком и удобном pipeline - стиле.
Для кого хорошо подходит данный мастер-класс: вы умеете читать и понимать код на Java на уровне хотя бы Junior, умеете писать SQL-запросы, в универе вы ходили хоть на одну пару по матану или терверу, вас либо недавно поставили, либо вскоре поставят на проект, где надо уметь ручками работать с вышеперечисленным зверинцем. Ну или вам просто интересно посмотреть на мощь даннодробилок, написанных на Java, и у вас в анамнезе неудачный опыт с NoSQL/SQL, как хранилищем, которое было ответственно за все, включая аналитику.
HappyDev'15 Keynote: Когда все данные станут большими...Alexey Zinoviev
Этот момент обязательно наступит, если ваш проект, ваш бизнес сделаны не для того, чтобы вспыхнуть Фениксом в пламени бюджетов. Его важно не пропустить и начать обряд масштабирования как можно раньше.
Однако, не для каждой ситуации может подойти простое натравливание Hadoop на ваши логи, перелив данных из PostgreSQL в Cassandra или беспощадный тюнинг nginx и JVM.
Всегда стоит идти от задач, от представления о системе аналитики или от определенного заранее уровня отзывчивости системы. В этом докладе я хотел бы сосредоточиться не на инструментарии, столь важном для разработчика, а, напротив, поговорить о различных типах вопросов и болей с которыми приходят к нам заказчики в реальном мире, где никому нет дела до ваших результатов на Kaggle (онлайн-олимпиада по анализу данных) и синтетических тестов производительности, а также о процессе поиска ответов на эти вопросы. В реальном мире конечная идея приложения может измениться до неузнаваемости в один момент.
Приходите, разберем как хорошие случаи, так и типичные ошибки в построении приложений.
Для кого хорошо подойдет данный доклад: для тех, кто не слишком знаком с концепцией BigData, либо хорошо знаком с инструментарием разработчика, но нет определенной ясности в том, а для чего все это нужно. Ну и если вы идете на мастер-класс, то заходите, лишним не будет.
Всеволод Поляков "История одного мониторинга"Fwdays
«Мир изменился… Я чувствую это в воде… Я чувствую это в земле…»
Галадриэль
«Какой-то отсталый у неё мониторинг»
Сева Поляков
В этом докладе я хочу рассказать вам историю о современном мониторинге, на примере выбора для моего текущего проекта. Когда нужен prometheus, когда нужен SaaS и почему графит не умрёт. Также я постараюсь пройтись по всем новинкам и важным изменениям в современном мире мониторинга.
«Система развёртывания многокомпонентного сервиса» — Алексей Салов, YaC 20132ГИС Технологии
Нельзя, да и неправильно, проектировать веб-сервис как монолитное приложение. Рано или поздно это приведёт к его закостенелости или даже умиранию. С другой стороны, декомпозиция системы на несколько компонент приносит проблемы интеграционной зависимости, которые усложняют развёртывание или эксплуатацию приложения. В докладе я представлю систему, которая позволяет нам оперативно развёртывать многокомпонентное приложение 2ГИС API на три сервера в Новосибирске, Москве, Амстердаме. Особое внимание уделю гибкой архитектуре приложения, процессу развёртывания, версионированию кеша и индексов (Sphinx, C++-демоны), миграции схем БД (PostgreSQL), инструментам мониторинга и развёртывания (Zabbix, Chef, Phing, Yii).
Распределенные системы хранения данных, особенности реализации DHT в проекте ...yaevents
В этом докладе будет описана система хранения данных Elliptics network, основной задачей которой является предоставление пользователям доступа к данным, расположенным на физически распределенных серверах с плоской адресной моделью в децентрализованном окружении. Распределенная система хранения данных, предоставляющая доступ к объекту по ключу (key/value storage), и в частности распределенная хэш-таблица (distributed hash table), является весьма эффективным решением с незначительным набором ограничений. Для подтверждения работоспособности данной идеи и функционала в докладе будет представлена практическая реализация распределенной хэш-таблицы с модульной системой хранения данных и различными системами доступа: от POSIX файловой системы до доступа по протоколу HTTP. Также мы обсудим ограничения, накладываемые технологией распределенной хэш таблицы, и сравним особенности высоконагруженного и высоконадежного доступа в ненадежной среде с классическими моделями, использующими централизованные системы. Опираясь на полученные практические результаты и гибкость реализованной системы, будут предложены способы решения поставленных задач и расширения функционала.
- Как начать развивать систему аналитики в компании, не имея армию data-инженеров.
- Как перейти из состояния «я не понимаю какие квадратики на этой схеме нужны для моих задач» и при этом не уйти в R&D на несколько месяцев.
- Как реализовать потоковую обработку данных на PHP (~40К записей в минуту).
- Какие технические решения применяли в нашем решении и какие факторы учитывали в принятии решений.
Презентация с мероприятия https://habr.com/ru/company/tuturu/blog/426059/
Прогрессивный рендеринг и Catberry.js / Михаил Реенко (2GIS / Flamp)Ontico
РИТ++ 2017, Frontend Сonf
Зал Мумбаи, 6 июня, 14:00
Тезисы:
http://frontendconf.ru/2017/abstracts/2471.html
Знаете ли вы, что такое прогрессивный рендеринг?
Почему вам стоит его использовать?
Какие есть варианты сегодня?
Всеволод Поляков "История одного мониторинга"Fwdays
«Мир изменился… Я чувствую это в воде… Я чувствую это в земле…»
Галадриэль
«Какой-то отсталый у неё мониторинг»
Сева Поляков
В этом докладе я хочу рассказать вам историю о современном мониторинге, на примере выбора для моего текущего проекта. Когда нужен prometheus, когда нужен SaaS и почему графит не умрёт. Также я постараюсь пройтись по всем новинкам и важным изменениям в современном мире мониторинга.
«Система развёртывания многокомпонентного сервиса» — Алексей Салов, YaC 20132ГИС Технологии
Нельзя, да и неправильно, проектировать веб-сервис как монолитное приложение. Рано или поздно это приведёт к его закостенелости или даже умиранию. С другой стороны, декомпозиция системы на несколько компонент приносит проблемы интеграционной зависимости, которые усложняют развёртывание или эксплуатацию приложения. В докладе я представлю систему, которая позволяет нам оперативно развёртывать многокомпонентное приложение 2ГИС API на три сервера в Новосибирске, Москве, Амстердаме. Особое внимание уделю гибкой архитектуре приложения, процессу развёртывания, версионированию кеша и индексов (Sphinx, C++-демоны), миграции схем БД (PostgreSQL), инструментам мониторинга и развёртывания (Zabbix, Chef, Phing, Yii).
Распределенные системы хранения данных, особенности реализации DHT в проекте ...yaevents
В этом докладе будет описана система хранения данных Elliptics network, основной задачей которой является предоставление пользователям доступа к данным, расположенным на физически распределенных серверах с плоской адресной моделью в децентрализованном окружении. Распределенная система хранения данных, предоставляющая доступ к объекту по ключу (key/value storage), и в частности распределенная хэш-таблица (distributed hash table), является весьма эффективным решением с незначительным набором ограничений. Для подтверждения работоспособности данной идеи и функционала в докладе будет представлена практическая реализация распределенной хэш-таблицы с модульной системой хранения данных и различными системами доступа: от POSIX файловой системы до доступа по протоколу HTTP. Также мы обсудим ограничения, накладываемые технологией распределенной хэш таблицы, и сравним особенности высоконагруженного и высоконадежного доступа в ненадежной среде с классическими моделями, использующими централизованные системы. Опираясь на полученные практические результаты и гибкость реализованной системы, будут предложены способы решения поставленных задач и расширения функционала.
- Как начать развивать систему аналитики в компании, не имея армию data-инженеров.
- Как перейти из состояния «я не понимаю какие квадратики на этой схеме нужны для моих задач» и при этом не уйти в R&D на несколько месяцев.
- Как реализовать потоковую обработку данных на PHP (~40К записей в минуту).
- Какие технические решения применяли в нашем решении и какие факторы учитывали в принятии решений.
Презентация с мероприятия https://habr.com/ru/company/tuturu/blog/426059/
Прогрессивный рендеринг и Catberry.js / Михаил Реенко (2GIS / Flamp)Ontico
РИТ++ 2017, Frontend Сonf
Зал Мумбаи, 6 июня, 14:00
Тезисы:
http://frontendconf.ru/2017/abstracts/2471.html
Знаете ли вы, что такое прогрессивный рендеринг?
Почему вам стоит его использовать?
Какие есть варианты сегодня?
Обзор архитектуры и подсистем деплоя и мониторинга.
Как инженеры делают систему прозрачной для разработки.
1) Схема организации репозитория puppet.
Зачем мы сделали репозиторий публичным внутри компании?
Как мы "делим" puppet, и что делать, если все "пропало"?
Собственная реализация механизма puppet kick.
2) Как рассказать всем обо всем и никого не потерять.
"Черный мониторинг" (rbmon). Как мы собираем информацию о серверах и демонах.
Делимся логами с разработчиками. Почему написали "велосипед"?
3) Graphite - система сбора и визуализации данных.
Почему graphite?
1М метрик в минуту?
Какие метрики мы рисуем (nginx-graphite-module, rbmon plugins).
Визуализация работы проекта (Dashboard пульт).
Обзор архитектуры и подсистем деплоя и мониторинга. Как инженеры делают систе...Ontico
1) Схема организации репозитория puppet.
Зачем мы сделали репозиторий публичным внутри компании?
Как мы "делим" puppet, и что делать, если все "пропало"?
Собственная реализация механизма puppet kick.
2) Как рассказать всем обо всем и никого не потерять.
"Черный мониторинг" (rbmon). Как мы собираем информацию о серверах и демонах.
Делимся логами с разработчиками. Почему написали "велосипед"?
3) Graphite - система сбора и визуализации данных.
Почему graphite?
1М метрик в минуту?
Какие метрики мы рисуем (nginx-graphite-module, rbmon plugins).
Визуализация работы проекта (Dashboard пульт).
DevOps в Agile среде. Как, почему и когда инструменты помогают.Alexander Titov
Модное слово DevOps уже успело стать заезженным базвордом. Сотни компаний ищут DevOps инженеров, потому что искать системного администратора уже не модно. Я расскажу вам про свое понимание DevOps, как технические инструменты помогают делать Agile еще более гибким.
Мы разберем основные принципы DevOps через призму донесения смысла без потерь:
- Особая культура
- Автоматизация
- Изменения через измерения
- Распространение знаний и практик
Я поделюсь своим 5ти летним опытом в обеспечении повторяемости, мониторинге, логировании с примерами из реальной жизни.
Александр Титов - управляющий партнер в компании "Экспресс 42", мы внедряем DevOps практики и инструменты, помогаем эксплуатировать интернет-проекты.
В 2009, 2010 годах был техническим директором первого облачного хостинга в России Скалакси.
В 2010 - 2012 прошел увлекательный путь поглощений вместе с компанией Qik - путь из эксплуатации быстрорастущего стартапа к эксплуатации в крупной международной компании Microsoft.
Путь от монолита на PHP к микросервисам на Scala / Денис Иванов (2GIS)Ontico
В своём проекте мы решали следующие задачи:
+ Скорость разработки задачи;
+ Стоимость поддержки задачи;
+ Возможность распараллеливать вычисления и задачи;
+ Возможность максимально просто масштабировать приложение;
+ CI/CD с минимальными усилиями.
Я расскажу о том, как мы решали эти задачи, на какие грабли мы наступали, что из этого всего получилось, и что делать дальше.
Что получили в итоге:
+ Мощь JVM под капотом Scala;
+ 15 минут от нажатия на кнопку "Merge request" до продакшена в 3 датацентра и 6 серверов с прохождением тестов (юнит + функциональные + интеграционные + нагрузочные);
+ 6 нод с приложениями вместо 18 (по 2 в каждом датацентре для отказоустойчивости) с запасом прочности в 60%;
+ Независимые пофичные релизы без даунтайма всех компонентов приложения;
+ Масштабирование только того функционала и в том количестве, которое необходимо данному сервису.
Разгоняем ASP.NET Core / Илья Вербицкий (WebStoating s.r.o.)Ontico
HighLoad++ 2017
Зал «Рио-де-Жанейро», 8 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2905.html
Прошло более года с того момента, как Microsoft выпустила первую версию своего нового фреймворка для разработки web-приложений ASP.NET Core, и с каждым днем он находит все больше поклонников. ASP.NET Core базируется на платформе .NET Core, кроссплатформенной версии платформы .NET c открытым исходным кодом. Теперь у С#-разработчиков появилась возможность использовать Mac в качестве среды разработки, и запускать приложения на Linux или внутри Docker-контейнеров.
...
Чеклист по клиентской оптимизации / Николай Лавлинский (Метод Лаб)Ontico
РИТ++ 2017, HighLoad Junior
Зал Сингапур, 6 июня, 10:00
Тезисы:
http://junior.highload.ru/2017/abstracts/2475.html
Когда проект растёт, возникает множество проблем с масштабируемостью сервиса: БД, сервера приложений, хранилище. Однако, не менее важной становится клиентская часть веб-приложения.
Во-первых, грамотная клиентская оптимизация позволяет повысить скорость работы сервиса для пользователей и, следовательно, увеличить их лояльность, которая конвертируется в деньги.
...
2. Структура доклада
• Как устроен кластер генерации карт?
• Почему мы используем язык Go?
• Как мы тестируем нашу систему?
• Какие у нас планы на будущее?
16. Gopnik
• Ориентированность на файловую систему
• Плохая масштабируемость
• Гибкая модульная архитектура
• Пользователь получает результат генерации сразу
• Простая конфигурация
• Набор дополнительных утилит
29. Плюсы Go
• Очень простой
• Компилируемый
• Строгая типизация
• Сборка мусора
• Простая и понятная модель многопоточности
• Быстрая компиляция
• Хорошая стандартная библиотека
• Большой набор полезных утилит
34. Что уже сделано
• Гибкая модульная платформа
• Поддержка тайловых кэшей с eventual consistency
• Дополнительные утилиты
• Удобный кластерный рендеринг
• Простая конфигурация
35. Что еще хотим сделать
• Gossip
• SPDY
• QUIC
• Data-tiles