архитектурные приемы онлайн игры

Архитектурные приемы : онлайн-игры Павел Кудинов

О чём? ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]

SQL 10000 hp Завулон name 666 id «старый мельник» 666 мел судьбы item 666 player_id

Скрипт «старый мельник» мел судьбы 2 1 items 10000 hp Завулон 666 name id

Применяем memcached u_666 => «старый мельник» мел судьбы 2 1 items 10000 hp Завулон 666 name id

Зачем теперь SQL ? ,[object Object],[object Object]

Всё уже украдено до нас ,[object Object],[object Object],[object Object],[object Object]

Эволюция Apache ,[object Object],[object Object],[object Object]

Маленький prefork ,[object Object],[object Object],[object Object],[object Object],[object Object]

Как сделать multiplex демон ? pavel-kudinov.livejournal.com/47420.html см. доклад HighLoad-2007 « Сетевая многозадачность: событийные машины » Как собрать всё воедино?

Проблемы realtime проекта ,[object Object]

Проблемы realtime проекта ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]

KISS: Keep it simple, Stupid! Перфекционизм – это патология … (с) WikiPedia

Упало : Frontend (nginx) ,[object Object],[object Object],[object Object],[object Object],[object Object]

Зомби нельзя убить! ,[object Object],[object Object],[object Object],[object Object]

Хотим внести изменения ,[object Object],[object Object],[object Object]

Статистика и логи ,[object Object],[object Object],[object Object]

Спасибо за внимание! ,[object Object],[object Object],Павел Кудинов [email_address] pavel-kudinov pavel-kudinov

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

Highload на GPU, опыт Vinci / Олег Илларионов (ВКонтакте)

Vinci - это второе по популярности приложение в мире для обработки фотографий с помощью нейронных сетей. Расскажу, как менее чем за месяц с нуля разработать и развернуть приложение, обработать 3 миллиона фотографий на GPU в день запуска и не упасть. Доклад будет разделен на 3 части: 1) Менеджинг задач при работе с GPU, как найти компромисс между надежностью и максимальной производительностью. 2) Обзор инструментов, подводных камней и софта. 3) Что можно и нужно оптимизировать, какие есть дальнейшие перспективы. Цель доклада – развеять миф, что нейросети это сложно.

За счет чего Tarantool такой оптимальный / Денис Аникин (Mail.Ru)

Многие из вас, наверное, видели результаты тестов сравнения Tarantool с остальными СУБД, которые показывают, что Tarantool быстрее всех, оптимальней по памяти, обрабатывает наибольшее количество транзакций в секунду. И, несмотря на то, что исходные коды всех тестов полностью открыты и хорошо откомментированы, позволяя всем желающим повторить тесты, все равно остаются вопросы - за счет чего Tarantool такой быстрый и оптимальный? Я решил суммировать мои ответы на эти вопросы в докладе на Highload++. Итак, почему Tarantool такой быстрый? Краткий ответ: потому что он с самого начала разрабатывался и до сих пор разрабатывается во главе угла с производительностью/оптимальностью/минимальным потреблением всех ресурсов системы. Более полный ответ я раскрою в своем выступлении. Приходите, будет интересно! :)

Виртуальный ЦОД для корпоративных клиентов на базе Virtuozzo: стабильность, п...

Услуга виртуального дата-центра предъявляет жесткие требования к платформе виртуализации - клиенты хотят высокую производительность и стабильность, а провайдерам нужна возможность максимально плотно размещать нагрузки клиентов. Мы расскажем: 1. как мы работали с Virtuozzo, чтобы сделать его более производительным и стабильным и, вместе с тем, добиться максимальной плотности размещения виртуальных машин; 2. контейнеры Virtuozzo прекрасно решают эту задачу, но не подходят для размещения некоторых типов приложений, например, Windows; 3. как мы будем переходить на Virtuozzo с KVM, каких целей мы хотим добиться.

Где живут Ваши объявления / Тюрин Михаил (Avito)

Авито с 2010 года — с момента запуска на широкую аудиторию — прошел уже немалый путь, успев собрать более 600 миллионов объявлений со всех уголков страны, и став при этом крупнейшим классифайдом в Европе. В докладе будет дан обзор архитектуры ядра системы с ретроспективой, перечислены основные компоненты обработки объявлений, приведены оценки параметров функционирования от "продуктовых" "количество объявлений за единицу времени" до количества запросов на разные уровни стека (веб, базы, поиск, очереди) и степени утилизации железа. Будут также продемонстрированы примеры реализаций классических паттернов веба: кэш, прокси, денормализация и репликация, шардинг, очереди и удаленный вызов процедур — подходы, уже более 5 лет лежащие в основе нашей архитектуры. При этом будут приведены неочевидные, на взгляд автора, особенности внедрения данных подходов. Доклад должен заинтересовать соотнесением масштабов и ключевых слов.

HDD, SSD, RAM, RAID, и кого на ком кэшировать / Михаил Конюхов (Perfect Solut...

Рассуждение, опыт, практика и примеры на тему производительности ввода-вывода. Мы будем сравнивать "дефолтное" поведение SSD и HDD, сравним "недефолтное" поведение после тюнинга HDD. Я расскажу о плюсах и минусах в надежности HDD и SSD, о проблемах восстановления SSD и HDD после сбоев. Многие моменты будут посвящены кэшированию ввода-вывода, что очень помогает в реальных проектах. Отдельная тема - оптимизация ФС и сервера для снижения количества операций ввода-вывода (IOPS), попробую оценить, что можно сделать с каким-нибудь проектом-примером. Будут показаны и рассказаны реальные примеры из моего опыта оптимизации IO, я даже нарисую "карту принятия решения" для выбора накопителей для Вашего проекта.

Архитектура поиска в Booking.com / Иван Круглов (Booking.com)

Booking.com - популярный сервис по онлайн-бронированию отелей. Поиск отеля, отвечающего заданным характеристикам - это неотъемлемая часть бизнес-модели и основной инструмент для клиента. При постоянном росте компании вопросу производительности и масштабируемости поиска уделяется много внимания. В результате за время своего существования архитектура поиска претерпела несколько глобальных переделок, начиная от простой базы в MySQL до многокомпонентного распределенного сервиса. В своей текущей реинкарнации поиск в Booking.com состоит их трех подсистем: 1) сервис auto-complete и устранения неоднозначности (disambiguation) в геопозиции; 2) сервис поиска по отелям и проверки их доступности (availability); 3) система предрасчета цен. Первые две системы - это высокопроизводительные приложения, написанные на Java. Сервис поиска хранит свои индексы в in-memory хранилище, а данные - во встраиваемой базе данных RocksDB. Логика системы предрасчета цен написана на Perl, а в качестве хранилища используется MySQL. Приходите на мой доклад, и я расскажу вам, как эволюционировал поиск вместе с ростом компании. Мы подробно рассмотрим текущую архитектуру, и почему мы решили ее сделать именно такой. Ну и, конечно, с какими проблемами нам пришлось бороться и как мы это делали.

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

OpenResty: превращаем NGINX в полноценный сервер приложений / Владимир Прота...

Все мы знаем, что NGINX – отличный прокси, который может качественно и эффективно распределять нагрузку между бэкендами и фильтровать запросы по определенным условиям. Но при этом часто на практике возникают задачи, которые не решаются его декларативной моделью описания конфигурации: иногда для принятия решения нам нужно сходить в базу данных (в Redis или даже в MySQL), другой сервис или произвести какую-то более сложную обработку запроса/ответа. Именно здесь к нам на помощь приходит мощь Lua и OpenResty. Из доклада вы узнаете: * зачем нам Lua внутри NGINX, и почему из седьмого айфона убрали разъем под наушники; * в каких ситуациях NGINX в паре с Lua справятся с задачей лучше вашего любимого PHP/NodeJS/Ruby/Python/Visual Basic и о прелестях асинхронного ввода-вывода без callback'ов; * как залезть к NGINX под капот, используя только высокоуровневый язык; * при чем здесь Openresty, или как упростить себе жизнь; * примеры бизнес-кейсов: от "умного" прокси до самостоятельного веб-приложения; * как оно ведет себя в продакшне под большой нагрузкой.

10 способов достижения HighLoad'а и BigData на ровном месте / Илья Космодемья...

Веб-сайт нужно делать так, чтобы о перипетиях его разработки и поддержки бессонными ночами через пару лет можно было рассказать на конференции Highload++, а тамошнюю аудиторию сложно удивить велосипедом с треугольными каменными колесами. Большинство разработчиков свято следуют этому принципу то ли в силу природной любознательности и трудолюбия, то ли по причине отсутствия конференции LowLoad--. Примерно такие мысли приходят в голову практически любому специалисту по хранилищам данных, когда он видит успешный веб-проект, испытывающий стандартные проблемы с базой данных. В этом докладе я расскажу о 10-ти очень распространенных ошибках проектирования и эксплуатации хранилища в веб-проекте — от преждевременного шардирования базы и непродуманной системы архивации ненужных данных до особенностей работы всеми любимых фреймворков. Про каждую из них я расскажу подробно и поделюсь рецептами, как такие ошибки исправлять.

Внутреннее устройство PostgreSQL: временные таблицы и фрагментация памяти / Г...

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

Как устроена MySQL-репликация / Андрей Аксенов (Sphinx)

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

Консольные приложения на Go

Flashcache в mamba.ru / Яковлев Александр Юрьевич (ЗАО Мамба)

Некоторое время назад, когда в очередной раз встал вопрос о производительности большого парка mysql sharding серверов, мы не захотели покупать новые сервера и производить resharding. Мы обнаружили, что компания facebook выпустила в opensource большое количество своих разработок, в том числе и модуль ядра flashcache. Flashcache — модуль для кэширования блоков блочного устройства, предоставляющий 4 разных режима кэширования. В данном докладе я расскажу, как мы тестировали, поэтапно проверяя под нагрузкой, 3 из 4 режимов кэширования, сравнивая и выбирая оптимальный. Итогом данной работы стало внедрение данного модуля в нашу архитектуру (фотосервера, сервера БД).

Twisted Framework - фреймворк для написания сетевых приложений на Python (Анд...Ontico

Twisted Framework - сетевые приложения в Python

Анатомия веб сервиса (HighLoad-2014)Andrey Smirnov

Кластеры баз данных делаем сложные вещи просто / Андрей Тихонов (Avito)

Порой в процессе развития высоконагруженного проекта наступает момент, когда необходимо масштабирование. Возможно, ваш проект впервые упёрся в производительность железа (и таким образом перешёл в разряд высоконагруженных); возможно, это уже не первое масштабирование — не важно. Какие же проблемы могут возникнуть? Во-первых, если вы увеличиваете количество бэкенд-серверов, и, соответственно, количество рабочих процессов, то с ростом количества одновременных клиентских подключений вырастают и накладные расходы на базах данных. Во-вторых, достаточно быстро может кончиться ресурс in-memory баз данных. Потребуется создать (либо увеличить) кластер, а это каждый раз влечёт за собой необходимость модифицировать логику приложения. В-третьих, чем больше серверов, тем больше вероятность, что один из них выйдет из строя. Поэтому неплохо задуматься о том, как обеспечить отказоустойчивость, а это, опять же, потребует модифицировать логику приложения. В этом докладе я расскажу, как и какими инструментами можно легко решить все вышеперечисленные проблемы: уменьшить накладные расходы от большого количества подключений к базам данных, создать/модифицировать кластер БД прозрачно для приложения, а также прозрачно добавить устойчивость к падениям серверов БД. План доклада: - Введение. Методы масштабирования БД: репликация, шардирование. - Создаём шардированные кластеры in-memory БД прозрачно для приложений: Twemproxy, Redis-proxy, Mcrouter. - Уменьшаем накладные расходы от большого количества одновременных подключений на PostgreSQL с помощью PgBouncer. - Создаём шардированный кластер PostgreSQL с помощью PL/Proxy. - Добавляем прозрачную для приложения отказо�

Опыт миграции между дата-центрами / Михаил Тюрин, Сергей Бурладян (Avito)

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

101 способ приготовления RabbitMQ и немного о pipeline архитектуре / Филонов ...

Архитектурный шаблон проектирования конвейер (pipeline) хорошо зарекомендовал себя при проектировании высоконагруженных (highload) систем. Использование шины сообщений (message bus) при реализации каналов взаимодействия позволяет достигать хороших показателей масштабируемости (scalability), но при этом появляются дополнительные накладные расходы, которые сказываются на показателях производительности (performance). В докладе обсуждаются варианты использования системы обмена сообщениями RabbitMQ в качестве связующего программного обеспечения (middleware) для построения конвейерной архитектуры. Рассматриваются вопросы производительности и масштабирования как stateless так и statefull фильтров. В качестве примера рассматривается реализация системы обработки сложных событий (complex event processing) применительно к управлению журналированием (log management).

Балансировка нагрузки и отказоустойчивость в Одноклассниках

Главная → Тезисы и презентации Балансировка нагрузки и отказоустойчивость в Одноклассниках Системное администрирование Доклад принят в Программу конференции Никита Духовный Одноклассники Ведущий системный администратор в Одноклассниках. Начинал IT-карьеру разработчиком, занимался релиз инженерией, выбрал системное администрирование. Возглавляет одну из команд. Занимается задачами, обеспечивающими работу портала - автоматизацией, запуском новых решений, поддержкой инфраструктуры. Ведёт несколько хардкорных проектов, в том числе - по повышению отказоустойчивости портала. Тезисы Проект Одноклассники начинал свою жизнь в одном датацентре. С ростом популярности растёт и нагрузка. С ростом нагрузки открываются проблемы: - Ни один, даже самый мощный, сервер больше не справляется в одиночку. - Нагрузка растёт, а в датацентре нет места для нового оборудования. - Падение датацентра безоговорочно приводит к даунтайму. - Сетевой сбой выводит портал из строя. - Пользователи в удалённых регионах страдают от низкой скорости. Я без прикрас расскажу вам, как мы в Одноклассниках решаем эти проблемы. Поговорим о следующем: - CDN - каким пользователям важен, его архитектура, устройство наших CDN-приложений, что происходит при авариях. - Датацентры - почему мы используем три основных датацентра, где они расположены (и почему именно там), распределение пользовательского трафика между ними. - Сеть - как и до чего мы балансируем трафик. - Балансировщики - как мы используем LVS, почему (и в каких случаях) используем и другие решения. Что делаем с приложениями, которые нельзя ставить за балансировщик. - Модули портала - о балансировке в нашем RPC протоколе, о том, что происходит с Одноклассниками при падении датацентра.

Архитектура хранения фотографий в Badoo

Badoo Development

В этом докладе я в подробностях расскажу о том, как устроено хранение фотографий в нашей компании (всего около ~1 Пб). Наша система была устроена достаточно просто — сами фотографии хранятся на SAN Storages, которые подключены через Fiber Channel к отдельной группе серверов, "*photos". На photos-серверах смонтированы разделы на соответствующих сетевых блочных устройствах, которые с точки зрения пользователя выглядят, как обычная файловая система. Мы не используем никакие «хитрые» системы для хранения фотографий и не храним всё в одном файле — каждый размер каждой фотографии представляет из себя обычный файл на файловой системе ext3/4. Фотографии отдаются через nginx напрямую из файловой системы. Такой способ хранения больших объемов данных весьма дешев, но приводил к проблемам, когда соответствующие SAN «падали», вплоть до повреждения файловой системы с потерей части данных пользователей. Поэтому, для решения этой проблемы, а также проблем с производительностью, мы решили сделать «софтверную репликацию» фотографий с кешированием данных на SSD. Также, в качестве эксперимента, мы решили попробовать ещё один способ — хранение на локальных дисках вместо использования SAN. По стоимости решение значительно дороже, но зато надежнее и проще в поддержке. Также, для обеспечения устойчивости к выходу из строя любой машины из такого кластера, мы решили сделать возможной балансировку всех поступающих запросов на весь кластер, то есть, в современных терминах, сделать «распределенное, отказоустойчивое, высокодоступное облачное хранилище».

Юрий Насретдинов, Badoo

Эволюция программно-аппаратного обеспечения хранения фотографий в Badoo / Дми...

На примере нашей системы хранения фотографий мы хотим рассказать о проблемах, с которыми столкнулись в течение прошедших семи лет, связанных с ее программными и аппаратными компонентами, и о путях их решений. В данном докладе речь пойдет о том, как сохранить независимость от поставщика и построить масштабируемую систему хранения с длительным сроком эксплуатации и способностью к оперативному внесению изменений в конфигурацию. Как сделать изменения на аппаратном уровне прозрачными для разработчиков, а также о том, как упростить развертывание и обслуживание. В общих чертах изложен опыт и проблемы, которые мы получили в ходе эксплуатации классических мультиконтроллерных СХД. Основная тема - построение собственных хранилищ на базе общедоступных компонентов (полки, адаптеры, экспандеры, интерпозеры, диски, ЦПУ и т.д.) с потенциальной возможностью замены любого из выше перечисленного на другую модель. Дублирование критически важных узлов в рамках одной СХД. Обзор используемых транспортов - SRP, FC, iSCSI и описание того, каким образом можно быстро адаптировать такое хранилище под один или несколько транспортов, с минимальными вложениями. Обзор ПО для реализации СХД (SCST/LIO или проприетарные решения в области Software Defined Storage ). Автоматизация развертывания (инсталляция/управление с помощью Puppet). Тестирование перед вводом в эксплуатацию. Multipath I/O и упрощение именования экспортируемых блочных устройств. Политика составления наборов firmware для стабильной работы. Мониторинг. Расследование сбоев (Order of failure и т.п.).

Mysql vs postgresql

Daniel Podolsky

Погружение в виртуальную память и большие страницы / Константин Новаковский (...

РИТ++ 2017, HighLoad Junior Зал Сингапур, 5 июня, 12:00 Тезисы: http://junior.highload.ru/2017/abstracts/2688.html Современные приложения часто используют большое количество памяти, ещё чаще разработчики не задумываются, как именно приложение работает с памятью, и откуда она берётся. Просим ядро дать кусок памяти и начинаем с ним что-то делать... Но что за память нам выделяет ядро операционной системы? Память на самом деле виртуальная и делится на единицы, называемые страницами. Страницы бывают маленькими, бывают большими и очень большими. ...

Что особенного в СУБД для данных в оперативной памяти / Константин Осипов (Ta...

Оперативная память становится всё более дешёвой и производительной, что позволяет использовать её для хранения рабочего набора данных всё большего числа приложений. Хранение всех данных в оперативной памяти позволяет сделать их высоко доступными, а алгоритмы для работы с данными либо существенно упростить, либо ускорить, а иногда — и то, и другое. Тезисы - http://www.highload.ru/2015/abstracts/1964.html

Антон Тюрин "Распределённая система near-realtime агрегации больших объёмов д...

Yandex

В любом кластере пишутся логи, огромное количество. Анализ данных из этих логов важен для мониторинга состояния кластера. Со временем объемы данных растут, а сами данные становятся неоднородными. Как решить эту проблему? Как всегда, задача имеет много решений. В докладе рассказывается об одном из путей её решения с применением облачной технологии cocaine.

Интегрировать сторонний продукт или пилить самим? К вопросу о выборе системы ...

Многие проекты рано или поздно встают перед выбором – какую систему аналитики выбрать? Создавать что-то самим или брать готовое решение на рынке? А если брать, то как выбрать оптимальный вариант? Василий расскажет о том, какие существуют системы аналитики, чем они отличаются друг от друга, как они интегрируются в продукт и чем могут быть ему полезны.

What's hot

Современная операционная система: что надо знать разработчику / Александр Кри...

OpenResty: превращаем NGINX в полноценный сервер приложений / Владимир Прота...

10 способов достижения HighLoad'а и BigData на ровном месте / Илья Космодемья...

Внутреннее устройство PostgreSQL: временные таблицы и фрагментация памяти / Г...

Как устроена MySQL-репликация / Андрей Аксенов (Sphinx)

Консольные приложения на Go

Flashcache в mamba.ru / Яковлев Александр Юрьевич (ЗАО Мамба)

Twisted Framework - фреймворк для написания сетевых приложений на Python (Анд...Ontico

Twisted Framework - сетевые приложения в Python

Анатомия веб сервиса (HighLoad-2014)Andrey Smirnov

Кластеры баз данных делаем сложные вещи просто / Андрей Тихонов (Avito)

Опыт миграции между дата-центрами / Михаил Тюрин, Сергей Бурладян (Avito)

101 способ приготовления RabbitMQ и немного о pipeline архитектуре / Филонов ...

Балансировка нагрузки и отказоустойчивость в Одноклассниках

Архитектура хранения фотографий в Badoo

Badoo Development

Юрий Насретдинов, Badoo

Эволюция программно-аппаратного обеспечения хранения фотографий в Badoo / Дми...

Mysql vs postgresql

Daniel Podolsky

Погружение в виртуальную память и большие страницы / Константин Новаковский (...

Что особенного в СУБД для данных в оперативной памяти / Константин Осипов (Ta...

What's hot (20)

Современная операционная система: что надо знать разработчику / Александр Кри...

OpenResty: превращаем NGINX в полноценный сервер приложений / Владимир Прота...

10 способов достижения HighLoad'а и BigData на ровном месте / Илья Космодемья...

Внутреннее устройство PostgreSQL: временные таблицы и фрагментация памяти / Г...

Как устроена MySQL-репликация / Андрей Аксенов (Sphinx)

Консольные приложения на Go

Flashcache в mamba.ru / Яковлев Александр Юрьевич (ЗАО Мамба)

Twisted Framework - фреймворк для написания сетевых приложений на Python (Анд...

Twisted Framework - сетевые приложения в Python

Анатомия веб сервиса (HighLoad-2014)

Кластеры баз данных делаем сложные вещи просто / Андрей Тихонов (Avito)

Опыт миграции между дата-центрами / Михаил Тюрин, Сергей Бурладян (Avito)

101 способ приготовления RabbitMQ и немного о pipeline архитектуре / Филонов ...

Балансировка нагрузки и отказоустойчивость в Одноклассниках

Архитектура хранения фотографий в Badoo

Юрий Насретдинов, Badoo

Эволюция программно-аппаратного обеспечения хранения фотографий в Badoo / Дми...

Mysql vs postgresql

Погружение в виртуальную память и большие страницы / Константин Новаковский (...

Что особенного в СУБД для данных в оперативной памяти / Константин Осипов (Ta...

Viewers also liked

Антон Тюрин "Распределённая система near-realtime агрегации больших объёмов д...

Yandex

Интегрировать сторонний продукт или пилить самим? К вопросу о выборе системы ...

Real-time Analytics in Big data

Pratiksha Manan

#10 "Опыт создания Real-time игры на WebGL, Angular, Socket.io и Node.js" Его...

JSib

DataTalks #4: Необходимый минимум инструментов для построения своей системы р...

С каждым днем вопрос о персонализации поведения системы для пользователя становится все острее. В докладе Алексей рассмотрит набор инструментов, с помощью которых можно построить свой сервис по рекомендациям с минимальными временными затратами. Алексей расскажет не только о теории, но и приведет практические советы, как построить прототип, не отвлекая разработчиков на построение цельного pipeline, имея на руках одного-двух Data Scintist, которые могут сформулировать идею модели, и одного java/scala-разработчика, способного перевести модель в код. Доклад будет полезен техническим специалистам, отвечающим на запросы вроде: «мы хотим начать хоть с чего-то, но не знаем с какой стороны подойти». Интересуетесь анализом данных? Присоединяйтесь к нашей группе на Facebook: https://www.facebook.com/groups/DataTalks/

Flink 1.0-slides

Jamie Grier

Examples of realtime data processingYoungHEO

Flexible and Real-Time Stream Processing with Apache Flink

DataWorks Summit

DataTalks #4: Что такое предиктивная аналитика и кому она нужна / Надежда Руч...

По результатам исследования Information Week, ключевыми драйверами аналитики больших данных в 2015 г. стали: поиск корреляций между поступившими из различных источников данными, предиктивная аналитика покупательского поведения и предиктивная аналитика уровня продаж. Эксперты SAP расскажут об актуальных достижениях в развитии теории машинного обучения и покажут, как работает предиктивная аналитика, на конкретных примерах: прогнозирование вероятности невозврата кредита заёмщиком банка. управление качеством готовой продукции и выявление брака прогнозирование отклика аудитории в маркетинговых кампаниях розничных сетей анализ продуктовой корзины и организация получения персонализированных рекомендаций покупателями Интересуетесь анализом данных? Присоединяйтесь к нашей группе на Facebook: https://www.facebook.com/groups/DataTalks/

DataTalks #4: Построение хранилища данных на основе платформы hadoop / Игорь ...

DataWorks Summit/Hadoop Summit

В докладе Игорь продемонстрирует архитектуру хранилища, базирующуюся на технологиях от Cloudera и Oracle. Он расскажет об опыте интеграции множества источников данных с помощью самописных решений и использованием специализированных инструментов, как Apache NiFi. Выступление заинтересует технических специалистов, которые уже знакомы со стеком Hadoop. Интересуетесь анализом данных? Присоединяйтесь к нашей группе на Facebook: https://www.facebook.com/groups/DataTalks/

Современные тенденции развития платформ бизнес-аналитики, обзор мнений ведущи...

Prognoz

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

Apache spark

Anton Anokhin

Предиктивная аналитика и Big Data: методы, инструменты, решения

Dell_Russia

Parallel batch processing with spring batch slideshareMorten Andersen-Gott

Spark For Faster Batch Processing

Edureka!

William Vambenepe – Google Cloud Dataflow and Flink , Stream Processing by De...

Flink Forward

Robust Stream Processing with Apache Flink

Jamie Grier

Real-time Big Data Processing with Storm

viirya

Unified Stream and Batch Processing with Apache Flink

Batch and Stream Graph Processing with Apache Flink

Vasia Kalavri

Viewers also liked (20)

Антон Тюрин "Распределённая система near-realtime агрегации больших объёмов д...

Интегрировать сторонний продукт или пилить самим? К вопросу о выборе системы ...

Real-time Analytics in Big data

#10 "Опыт создания Real-time игры на WebGL, Angular, Socket.io и Node.js" Его...

DataTalks #4: Необходимый минимум инструментов для построения своей системы р...

Flink 1.0-slides

Examples of realtime data processing

Flexible and Real-Time Stream Processing with Apache Flink

DataTalks #4: Что такое предиктивная аналитика и кому она нужна / Надежда Руч...

DataTalks #4: Построение хранилища данных на основе платформы hadoop / Игорь ...

Современные тенденции развития платформ бизнес-аналитики, обзор мнений ведущи...

Apache spark

Предиктивная аналитика и Big Data: методы, инструменты, решения

Parallel batch processing with spring batch slideshare

Spark For Faster Batch Processing

William Vambenepe – Google Cloud Dataflow and Flink , Stream Processing by De...

Robust Stream Processing with Apache Flink

Real-time Big Data Processing with Storm

Unified Stream and Batch Processing with Apache Flink

Batch and Stream Graph Processing with Apache Flink

Similar to архитектурные приемы онлайн игры

Hosting for forbes.ru_drupalconf

Облако в Badoo год спустя

Yuriy Nasretdinov

Облако в Badoo год спустя - работа над ошибками, Юрий Насретдинов (Badoo)

Badoo Development

Облако в Badoo год спустя - работа над ошибками, Юрий Насретдинов (Badoo)Ontico

Бэкенд, фронтенд — всё смешалось (nodkz)

Pavel Chertorogov

Бэкенд, Фронтенд — всё смешалось. Обзорная экскурсия в будущее веб-разработки

ITCrowd Almaty

Внедрение параллельного рендеринга в игровой движок

Roman_Lut

Android: Как написать приложение, которое не тормозитElena Kotina

Node.js Меньше сложности, больше надежности Holy.js 2021

Timur Shemsedinov

BigПочта: как мы строили DataLake в Почте России / Алексей Вовченко (Luxoft)