NoSQL - что это? Новомодное словечко или современных подход, который позволяет обслуживать сотни миллионов запросов в день без использования супер-компьютеров? Почему все крупнейшие интернет-проекты используют базы данных, которые не поддерживают операций по связыванию данных, не гарантируют ACID при проведении транзакций и не имеют фиксированных схем хранения данных? В данном докладе будут проанализированы области применения NoSQL, раскрыты основные принципы, которые используются для хранения записей в неряционных БД, а также приведены характеристики по которым можно классифицировать сотни существующих на данный момент NoSQL базы данных.
Выбор NoSQL базы данных для вашего проекта: "Не в свои сани не садись"Alexey Zinoviev
Alexey Zinoviev Алексей Зиновьев рассказывает о выборе одной из следующих баз данных CouchDB, Neo4j, Mongo, Cassandra, HBase, Riak на Happydev 2013
Article "Choice of NoSQL database for your project: Don't bite off more than you can chew" presented on HappyDev 2013 (IT-conference in Omsk) by Alexey Zinoviev
The main idea of this article is comparison of the most popular NoSQL databases: CouchDB, Cassandra, Mongodb, Riak, Neo4j, HBase
СУБД 2013 Лекция №10 "Нереляционное решение в области баз данных — NoSQL"Technopark
Технопарк Mail.ru Group, МГТУ им. Н.Э. Баумана. Курс "Базы данных".
Лекция №10 "Нереляционное решение в области баз данных — NoSQL". Лектор - Станислав Ступников.
Вводная часть посвящена определению и истории развития концепции NoSQL. Даются характеристики, рассказывается о способах использования. Рассматриваются виды NoSQL БД, теоретические основы NoSQL, а в конце лекции обсуждаются недостатки NoSQL-решений, а также проводится сравнение разных NoSQL-решений.
Видео лекции курса https://www.youtube.com/playlist?list=PLrCZzMib1e9obOz5K695ugYuiOOCBciEi
ClickHouse: очень быстро и очень удобно / Виктор Тарнавский, Алексей Миловидо...Ontico
ClickHouse - высокопроизводительная база данных для больших данных и аналитики.
На ClickHouse основана Яндекс.Метрика - крупнейшая система веб-аналитики в России.
Ради чего мы написали свою базу данных? Ради скорости! ClickHouse работает невероятно быстро, быстрее всех известных нам конкурентов, и при этом может обрабатывать запросы по петабайтам данных.
Я расскажу про:
- Краткую историю создания проекта;
- Основные преимущества и особенности ClickHouse;
- Архитектура проекта; подход к хранению данных, отказоустойчивости, исполнению запросов;
- Как работает внутри, почему ClickHouse такой быстрый;
- Текущие кейсы использования в Метрике и других проектах Яндекса;
- Профит, который вы можете получить от ClickHouse.
Выбор NoSQL базы данных для вашего проекта: "Не в свои сани не садись"Alexey Zinoviev
Alexey Zinoviev Алексей Зиновьев рассказывает о выборе одной из следующих баз данных CouchDB, Neo4j, Mongo, Cassandra, HBase, Riak на Happydev 2013
Article "Choice of NoSQL database for your project: Don't bite off more than you can chew" presented on HappyDev 2013 (IT-conference in Omsk) by Alexey Zinoviev
The main idea of this article is comparison of the most popular NoSQL databases: CouchDB, Cassandra, Mongodb, Riak, Neo4j, HBase
СУБД 2013 Лекция №10 "Нереляционное решение в области баз данных — NoSQL"Technopark
Технопарк Mail.ru Group, МГТУ им. Н.Э. Баумана. Курс "Базы данных".
Лекция №10 "Нереляционное решение в области баз данных — NoSQL". Лектор - Станислав Ступников.
Вводная часть посвящена определению и истории развития концепции NoSQL. Даются характеристики, рассказывается о способах использования. Рассматриваются виды NoSQL БД, теоретические основы NoSQL, а в конце лекции обсуждаются недостатки NoSQL-решений, а также проводится сравнение разных NoSQL-решений.
Видео лекции курса https://www.youtube.com/playlist?list=PLrCZzMib1e9obOz5K695ugYuiOOCBciEi
ClickHouse: очень быстро и очень удобно / Виктор Тарнавский, Алексей Миловидо...Ontico
ClickHouse - высокопроизводительная база данных для больших данных и аналитики.
На ClickHouse основана Яндекс.Метрика - крупнейшая система веб-аналитики в России.
Ради чего мы написали свою базу данных? Ради скорости! ClickHouse работает невероятно быстро, быстрее всех известных нам конкурентов, и при этом может обрабатывать запросы по петабайтам данных.
Я расскажу про:
- Краткую историю создания проекта;
- Основные преимущества и особенности ClickHouse;
- Архитектура проекта; подход к хранению данных, отказоустойчивости, исполнению запросов;
- Как работает внутри, почему ClickHouse такой быстрый;
- Текущие кейсы использования в Метрике и других проектах Яндекса;
- Профит, который вы можете получить от ClickHouse.
Переезжаем на Yandex ClickHouse / Александр Зайцев (LifeStreet)Ontico
Несколько месяцев назад компания "Яндекс" совершила маленькую революцию, открыв свою внутреннюю систему хранения и аналитики больших данных ClickHouse в opensource для всех желающих.
ClickHouse стабильно показывает очень высокие результаты на тестах производительности запросов, часто догоняя и обгоняя лидеров рынка аналитических RDBMS, включая HP Vertica. Высокие результаты и авторитет "Яндекса" привлекают к этой системе заслуженное внимание разработчиков и архитекторов. Вместе с тем, архитектура ClickHouse довольно существенно отличается от привычных архитектур RDBMS, в ClickHouse отсутствует многое из привычной функциональности, есть ряд "неудобных" ограничений. Поэтому разработка новых и миграция существующих решений сопровождается значительными сложностями.
В докладе рассматриваются основные архитектурные особенности ClickHouse, отличия от традиционных RDBMS или NoSQL баз данных, и обсуждаются способы решения типичных задач, возникающих при разработке аналитических систем на ClickHouse.
NodeJS в HighLoad проекте / Акрицкий Владимир (iAge Engineering)Ontico
NodeJS — достаточно молодой фреймворк, и пока не каждый решается использовать его в продакшене, а тем более в highload.
В течение последнего года мы разрабатывали проект DMP (Data Management Platform), используя NodeJS для прототипирования. На данный момент проект в большей степени все еще остался на JS и без труда справляется с текущими нагрузками в 10 000 запросов в секунду.
В докладе я расскажу, почему остановились именно на NodeJS и совсем не жалеем об этом.
К сожалению, никакое дело не обходится без граблей и костылей. Я расскажу обо всех встретившихся проблемах и уделю особое внимание проблемам со спагетти-кодом, утечками и нехваткой памяти. Как мы убили немало времени, тщетно ища источник проблем, и какие правила мы составили для себя на будущее, чтобы не повторить своих ошибок.
Расскажу немного о применении микросервисов для решения проблемы спагетти-кода.
И, как итог, опишу ряд рекомендаций, которые помогут избежать большой траты времени при использовании NodeJS.
NewSQL: SQL никуда не уходит / Константин Осипов (tarantool.org)Ontico
РИТ++ 2017, Backend Conf
Зал Сан-Паулу, 6 июня, 12:00
Тезисы:
http://backendconf.ru/2017/abstracts/2788.html
Что такое NewSQL, почему NoSQL-движение превращается в NewSQL, и что эта трансформация привносит в SQL?
Попробуем разобраться, почему NoSQL-вендоры добавляют всё больше SQL-возможностей, почему стандарт SQL не пользуется популярностью, и куда это всё идёт.
Рассмотрим новые диалекты языка SQL, такие как:
- Cassandra QL
- Couchbase NQL
- Elastisearch
и сравним их с подходом MongoDB & RethinkDB, добавляющим новый язык работы с данными.
Останется ли в мире СУБД что-то ценного от NoSQL-движения?
Ну и, наконец, рассмотрим новый вызов реляционной модели: multi-model databases.
Как мы готовим MySQL / Николай Королёв (Badoo)Ontico
* Исторический экскурс, введение понятия спота, принцип функционального деления баз на группы (споты / не споты), шардирование как способ масштабирования спотов.
* Возникновение второго датацентра на другом континенте, создание самодельной репликации, позволяющей работать по схеме много -> много, краткая схема (структура спотов, схема репликации, служебные базы - очереди, репликация, мониторинг), плюсы и минусы этого решения, инструменты диагностики.
* Альтеры шадрированых спотов - первый вариант утилиты для этой задачи: схема его работы и возникшие проблемы; вторая версия утилиты - улучшения, а также, что осталось неисправленным.
* “Температура” спота, трудности её определения, проблемы, возникающие из-за его “перегрева”, наш способ решения и возникновение проекта “кладбище”.
* Деплой и около - почему мы используем MySQL в chroot, как мы его собираем и как деплоим.
* Бэкапы спотовых данных - первоначальное решение (ленточные хранилища), работа над ошибками, текущая схема.
* Query sampling: проект Minba.
Промышленное ускорение сайтов / Николай Мациевский (Айри.рф)Ontico
Идея: обеспечить реально высокую скорость загрузки нагруженного сайта (от 100 тысяч посетителей в день) для всех пользователей, ничего не сломав и уложившись в бюджет.
Введение. Подходы к оптимизации фронтенда:
* Классический: делаем по GPSI или WPT.
* Самостоятельный: прикрутили PageSpeed и CDN.
* Промышленный: PDSA (попробовали, измерили, внедрили, подсчитали).
* Кейс: открытие новостного сайта за 1 секунду на любом устройстве.
Часть 1. Мониторинг клиентской производительности
* Google Analytics / Яндекс.Метрика / Битрикс.
* New Relic / mPulse / Айри / Navigation Timing API.
* Resource Timing API / User Timing Api: собственные метрики.
* Кейс: как понять из метрик сайта, что и где тормозит.
Часть 2. Внедрение ускорения
* Как выбрать KPI скорости сайта.
* Базовые правила: как автоматизировать, внедрить, раскатать.
* "Бюджет" на ускорение страницы: как распределить.
* Поточное и отложенное ускорение: как выбрать.
* Некоторые типичные ошибки "оптимизации".
* Кейс: нестандартные подходы к оптимизации производительности.
Часть 3. Узкое профилирование
* Тестируем CDN: что смотрим, как измеряем.
* Тестируем мобильные устройства: тормозит CPU или GPRS ?
* Тестируем асинхронную загрузку: подводные камни.
* Кейс: сколько "стоит" ошибка в клиентской производительности.
Заключение. Промышленное внедрение
* Кейс: "швейцарский нож" для оптимизации изображений.
* Кейс: когда реально работает отложенная загрузка.
* Кейс: HTTP/2. Реальные данные.
* Кейс: как ускорить 2000 ресурсов в секунду?
Бигдата — как добывать золото из данных / Александр Сербул (1С-Битрикс)Ontico
Расскажем о самых распространенных технологиях и алгоритмах добычи критичной для бизнеса информации из больших массивов данных. Отдельно коснемся темы рекомендательных сервисов и их эффективного применения.
План:
1) Откуда брать данные, тренды и концепции.
2) Основные алгоритмы и технологии их применения для обработки массивов данных: MapReduce, Spark.
3) Методика создания рекомендательного сервиса — этапы от концепции до работающей системы.
Электронная коммерция: от Hadoop к Spark ScalaRoman Zykov
Как обрабатывать большой объем данных быстро с наименьшими затратами? Мы смогли этого добиться в компании
RetailRocket. Обработка данных – это наш бизнес! У нас много данных: более 100 Тбайт, в сутки нам поступает более 100 млн
событий для обработки. До недавнего времени у нас все работало на кластере на базе Hadoop относительно устаревшего
дистрибутива Cloudera CDH 4.5, программный код был написан на Pig, Hive, Python и Java. Это порождало ряд проблем с
архитектурой, производительностью. Тестирование превращалось в настоящую головную боль. В конце лета RetailRocket
перешел на Yarn на базе CDH 5.1.2. Это открыло путь к более совершенным технологиям семейства Spark. Сейчас мы
находимся в фазе полного перехода на Spark на функциональном языке Scala. Это позволило нам избавиться от зоопарка
технологий, упростив архитектуру решений и автоматизировав тестирование. Первые результаты не заставили себя ждать –
получен прирост производительности на том же железе в три-пять раз. А это значит, что мы будем меньше инвестировать в
расширение парка серверов кластера. В докладе будет рассказано о проблемах, с которыми мы столкнулись, и о том как мы
их решили. Будут примеры исходного кода для оптимизации производительности и повышения удобства работы, который мы
закоммитили в наш публичный GitHub
Про некоторые кейсы использования elasticsearch в современных проектах.
- С какими сложностями столкнулись
- Где успешо применили elasticsearch, а где был избыточен
Презентация с мероприятия https://habr.com/ru/company/odnoklassniki/blog/452978/
Обзор перспективных баз данных для highload / Юрий НасретдиновOntico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 5 июня, 10:00
Тезисы:
http://backendconf.ru/2017/abstracts/2773.html
В этом докладе я рассмотрю несколько перспективных, на мой взгляд, баз данных, которые пока еще не очень популярны, но которые определенно ждет успех в будущем, особенно для highload-проектов. Я расскажу о Tarantool, ClickHouse и CockroachDB, о том, как они устроены, и почему я считаю, что они в будущем станут стандартом де-факто, как раньше был MySQL, а сейчас — MongoDB.
...
- Как начать развивать систему аналитики в компании, не имея армию data-инженеров.
- Как перейти из состояния «я не понимаю какие квадратики на этой схеме нужны для моих задач» и при этом не уйти в R&D на несколько месяцев.
- Как реализовать потоковую обработку данных на PHP (~40К записей в минуту).
- Какие технические решения применяли в нашем решении и какие факторы учитывали в принятии решений.
Презентация с мероприятия https://habr.com/ru/company/tuturu/blog/426059/
Переезжаем на Yandex ClickHouse / Александр Зайцев (LifeStreet)Ontico
Несколько месяцев назад компания "Яндекс" совершила маленькую революцию, открыв свою внутреннюю систему хранения и аналитики больших данных ClickHouse в opensource для всех желающих.
ClickHouse стабильно показывает очень высокие результаты на тестах производительности запросов, часто догоняя и обгоняя лидеров рынка аналитических RDBMS, включая HP Vertica. Высокие результаты и авторитет "Яндекса" привлекают к этой системе заслуженное внимание разработчиков и архитекторов. Вместе с тем, архитектура ClickHouse довольно существенно отличается от привычных архитектур RDBMS, в ClickHouse отсутствует многое из привычной функциональности, есть ряд "неудобных" ограничений. Поэтому разработка новых и миграция существующих решений сопровождается значительными сложностями.
В докладе рассматриваются основные архитектурные особенности ClickHouse, отличия от традиционных RDBMS или NoSQL баз данных, и обсуждаются способы решения типичных задач, возникающих при разработке аналитических систем на ClickHouse.
NodeJS в HighLoad проекте / Акрицкий Владимир (iAge Engineering)Ontico
NodeJS — достаточно молодой фреймворк, и пока не каждый решается использовать его в продакшене, а тем более в highload.
В течение последнего года мы разрабатывали проект DMP (Data Management Platform), используя NodeJS для прототипирования. На данный момент проект в большей степени все еще остался на JS и без труда справляется с текущими нагрузками в 10 000 запросов в секунду.
В докладе я расскажу, почему остановились именно на NodeJS и совсем не жалеем об этом.
К сожалению, никакое дело не обходится без граблей и костылей. Я расскажу обо всех встретившихся проблемах и уделю особое внимание проблемам со спагетти-кодом, утечками и нехваткой памяти. Как мы убили немало времени, тщетно ища источник проблем, и какие правила мы составили для себя на будущее, чтобы не повторить своих ошибок.
Расскажу немного о применении микросервисов для решения проблемы спагетти-кода.
И, как итог, опишу ряд рекомендаций, которые помогут избежать большой траты времени при использовании NodeJS.
NewSQL: SQL никуда не уходит / Константин Осипов (tarantool.org)Ontico
РИТ++ 2017, Backend Conf
Зал Сан-Паулу, 6 июня, 12:00
Тезисы:
http://backendconf.ru/2017/abstracts/2788.html
Что такое NewSQL, почему NoSQL-движение превращается в NewSQL, и что эта трансформация привносит в SQL?
Попробуем разобраться, почему NoSQL-вендоры добавляют всё больше SQL-возможностей, почему стандарт SQL не пользуется популярностью, и куда это всё идёт.
Рассмотрим новые диалекты языка SQL, такие как:
- Cassandra QL
- Couchbase NQL
- Elastisearch
и сравним их с подходом MongoDB & RethinkDB, добавляющим новый язык работы с данными.
Останется ли в мире СУБД что-то ценного от NoSQL-движения?
Ну и, наконец, рассмотрим новый вызов реляционной модели: multi-model databases.
Как мы готовим MySQL / Николай Королёв (Badoo)Ontico
* Исторический экскурс, введение понятия спота, принцип функционального деления баз на группы (споты / не споты), шардирование как способ масштабирования спотов.
* Возникновение второго датацентра на другом континенте, создание самодельной репликации, позволяющей работать по схеме много -> много, краткая схема (структура спотов, схема репликации, служебные базы - очереди, репликация, мониторинг), плюсы и минусы этого решения, инструменты диагностики.
* Альтеры шадрированых спотов - первый вариант утилиты для этой задачи: схема его работы и возникшие проблемы; вторая версия утилиты - улучшения, а также, что осталось неисправленным.
* “Температура” спота, трудности её определения, проблемы, возникающие из-за его “перегрева”, наш способ решения и возникновение проекта “кладбище”.
* Деплой и около - почему мы используем MySQL в chroot, как мы его собираем и как деплоим.
* Бэкапы спотовых данных - первоначальное решение (ленточные хранилища), работа над ошибками, текущая схема.
* Query sampling: проект Minba.
Промышленное ускорение сайтов / Николай Мациевский (Айри.рф)Ontico
Идея: обеспечить реально высокую скорость загрузки нагруженного сайта (от 100 тысяч посетителей в день) для всех пользователей, ничего не сломав и уложившись в бюджет.
Введение. Подходы к оптимизации фронтенда:
* Классический: делаем по GPSI или WPT.
* Самостоятельный: прикрутили PageSpeed и CDN.
* Промышленный: PDSA (попробовали, измерили, внедрили, подсчитали).
* Кейс: открытие новостного сайта за 1 секунду на любом устройстве.
Часть 1. Мониторинг клиентской производительности
* Google Analytics / Яндекс.Метрика / Битрикс.
* New Relic / mPulse / Айри / Navigation Timing API.
* Resource Timing API / User Timing Api: собственные метрики.
* Кейс: как понять из метрик сайта, что и где тормозит.
Часть 2. Внедрение ускорения
* Как выбрать KPI скорости сайта.
* Базовые правила: как автоматизировать, внедрить, раскатать.
* "Бюджет" на ускорение страницы: как распределить.
* Поточное и отложенное ускорение: как выбрать.
* Некоторые типичные ошибки "оптимизации".
* Кейс: нестандартные подходы к оптимизации производительности.
Часть 3. Узкое профилирование
* Тестируем CDN: что смотрим, как измеряем.
* Тестируем мобильные устройства: тормозит CPU или GPRS ?
* Тестируем асинхронную загрузку: подводные камни.
* Кейс: сколько "стоит" ошибка в клиентской производительности.
Заключение. Промышленное внедрение
* Кейс: "швейцарский нож" для оптимизации изображений.
* Кейс: когда реально работает отложенная загрузка.
* Кейс: HTTP/2. Реальные данные.
* Кейс: как ускорить 2000 ресурсов в секунду?
Бигдата — как добывать золото из данных / Александр Сербул (1С-Битрикс)Ontico
Расскажем о самых распространенных технологиях и алгоритмах добычи критичной для бизнеса информации из больших массивов данных. Отдельно коснемся темы рекомендательных сервисов и их эффективного применения.
План:
1) Откуда брать данные, тренды и концепции.
2) Основные алгоритмы и технологии их применения для обработки массивов данных: MapReduce, Spark.
3) Методика создания рекомендательного сервиса — этапы от концепции до работающей системы.
Электронная коммерция: от Hadoop к Spark ScalaRoman Zykov
Как обрабатывать большой объем данных быстро с наименьшими затратами? Мы смогли этого добиться в компании
RetailRocket. Обработка данных – это наш бизнес! У нас много данных: более 100 Тбайт, в сутки нам поступает более 100 млн
событий для обработки. До недавнего времени у нас все работало на кластере на базе Hadoop относительно устаревшего
дистрибутива Cloudera CDH 4.5, программный код был написан на Pig, Hive, Python и Java. Это порождало ряд проблем с
архитектурой, производительностью. Тестирование превращалось в настоящую головную боль. В конце лета RetailRocket
перешел на Yarn на базе CDH 5.1.2. Это открыло путь к более совершенным технологиям семейства Spark. Сейчас мы
находимся в фазе полного перехода на Spark на функциональном языке Scala. Это позволило нам избавиться от зоопарка
технологий, упростив архитектуру решений и автоматизировав тестирование. Первые результаты не заставили себя ждать –
получен прирост производительности на том же железе в три-пять раз. А это значит, что мы будем меньше инвестировать в
расширение парка серверов кластера. В докладе будет рассказано о проблемах, с которыми мы столкнулись, и о том как мы
их решили. Будут примеры исходного кода для оптимизации производительности и повышения удобства работы, который мы
закоммитили в наш публичный GitHub
Про некоторые кейсы использования elasticsearch в современных проектах.
- С какими сложностями столкнулись
- Где успешо применили elasticsearch, а где был избыточен
Презентация с мероприятия https://habr.com/ru/company/odnoklassniki/blog/452978/
Обзор перспективных баз данных для highload / Юрий НасретдиновOntico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 5 июня, 10:00
Тезисы:
http://backendconf.ru/2017/abstracts/2773.html
В этом докладе я рассмотрю несколько перспективных, на мой взгляд, баз данных, которые пока еще не очень популярны, но которые определенно ждет успех в будущем, особенно для highload-проектов. Я расскажу о Tarantool, ClickHouse и CockroachDB, о том, как они устроены, и почему я считаю, что они в будущем станут стандартом де-факто, как раньше был MySQL, а сейчас — MongoDB.
...
- Как начать развивать систему аналитики в компании, не имея армию data-инженеров.
- Как перейти из состояния «я не понимаю какие квадратики на этой схеме нужны для моих задач» и при этом не уйти в R&D на несколько месяцев.
- Как реализовать потоковую обработку данных на PHP (~40К записей в минуту).
- Какие технические решения применяли в нашем решении и какие факторы учитывали в принятии решений.
Презентация с мероприятия https://habr.com/ru/company/tuturu/blog/426059/
До недавнего времени в Одноклассниках около 50 ТБ данных, обрабатываемых в реальном времени, хранилось в Microsoft SQL Server. Многие знают, что для такого объема обеспечить быстрый и надежный, да еще и устойчивый к отказу ЦОД доступ, используя SQL СУБД, практически невозможно. Обычно в таких случаях используют одно из NoSQL хранилищ, но не всё можно перенести в NoSQL: некоторые сущности требуют гарантий ACID-транзакций.
Это ограничение подвело нас к необходимости использования NewSQL хранилища, то есть СУБД, предоставляющей отказоустойчивость, масштабируемость и быстродействие NoSQL-систем, но при этом сохраняющей привычные для классических систем ACID-гарантии. Работающих промышленных систем этого нового класса немного (сразу приходит на ум только Google Spanner), а доступных — и вовсе нет. Поэтому мы реализовали такую систему сами на любимой нами Java и запустили ее в промышленную эксплуатацию несколько месяцев назад.
Доклад про то, как устроено это хранилище будет интересен всем, кто следит за развитием технологий управления базами данных и имеет опыт работы с (No)SQL.
NoSQL - коротко о главном / Сергей Туленцев (TextMaster)Ontico
В последнее время сайты и веб-приложения растут всё быстрее, а задачи, стоящие перед БД, эволюционируют. Поэтому для (успешных) проектов традиционная реляционная СУБД часто не может удовлетворить все нужды. В ответ на эту проблему возникло большое количество разнообразных решений, очень различающихся по функциональности и характеристикам. При этом они все заносятся под один большой зонтик "NoSQL", что не способствует пониманию вещей. Запутанные веб-разработчики пытаются взять текущую модную и обсуждаемую NoSQL БД и приспособить её под свои нужды, не всегда понимая, нужную ли технологию они выбрали (референс к MongoDB is Web Scale http://www.youtube.com/watch?v=b2F-DItXtZs).
Целью доклада является упорядочение хаоса в головах разработчиков.
- Обзор популярных БД и их классификация (KV store, document store, columnar, etc).
- CAP-теорема и её применение к выбору БД (где-то параметры можно настроить, где-то подпереть сбоку костылем, где-то - увы).
- Типичные примеры применения.
- Антипаттерны применения (из личного опыта и тысяч прочитанных вопросов на stackoverflow :) ).
Because Elixir and Phoenix borrow so many good ideas from the Rails ecosystem, it’s astoundingly easy for Ruby developers to become proficient in this powerful new set of tools. First, I’ll introduce Phoenix from a Rails POV, and then show two ways it can be used in conjunction with Rails.
This is a presentation given on October 24 by Michael Uzquiano of Cloud CMS (http://www.cloudcms.com) at the MongoDB Boston conference.
In this presentation, we cover Hazelcast - an in-memory data grid that provides distributed object persistence across multiple nodes in a cluster. When backed by MongoDB, objects are naturally written to Mongo by Hazelcast. The integration points are clean and easy to implement.
We cover a few simple cases along with code samples to provide the MongoDB community with some ideas of how to integrate Hazelcast into their own MongoDB Java applications.
«Бутылочное горлышко многопоточных программ – кто виноват, и что делать. Мастер-класс.»
BitByte: 20 апреля 2013, Санкт-Петербург
http://bitbyte.itmozg.ru/
In this webinar we will compare the complexities involved in Terracotta with the code/configuration changes to migrate to Hazelcast. You will learn about important features of Hazelcast such as IMDG capabilities, off-heap data storage, distributed collections, etc. and the feature-rich product portfolio of Hazelcast. We will cover how Hazelcast can scale up and out dynamically and without downtime against the static configuration of Terracotta. Expect to leave the webinar being more educated about Hazelcast in terms of architecture, important features and best practices.
We’ll cover these topics:
- Hazelcast architecture and features
- Terracotta distributed architecture
- Scale – Vertical + Horizontal = Showcase no downtime feature in Hazelcast
- BigMemory vs. HDC
- Ease of installation – two jars against multiple jars
- Config and Code changes – cache vs. maps, off-heap vs. HDC
- Portability of Client APIs – IMap, IQueue, Topics, etc.
- Added functionalities – Showcase IExecutorService, EntryProcessors, Multimap, etc.
- DSO – Showcase EntryProcessors taking place of DSO
- Live Q&A
Presenter:
Rahul Gupta, Senior Solutions Architect
Rahul is a technology-driven professional with 12+ years of experience in building and architecting highly scalable and concurrent, low latency business critical distributed infrastructure. His expertise lies in Big Data and Real Time Analytics space where he specializes in big data governing technologies and Enterprise Architecture. Rahul is an expert in working with decision makers across different business verticals within an organization and guiding them in right decision making through in-depth technical understanding, analysis and evaluation procedures to bring home critical deals with high business values.
When you work in a small collocated team many engineering practices and approaches are relatively easy to use and adapt. In large project with many teams working on the same product this task is not so simple. I want to share experience report in implementing Code Review practice in big product development team (more than 150 people, 10+ feature teams). In this talk we will review what approaches works in such setup and what don’t work, what tools and additional practices are needed to support Code Review and make it more effective, what difficulties and blockers will you probably see in the real life cases, what useful metrics could be produced by this practice.
HighLoad++ 2017
Зал «Сингапур», 7 ноября, 17:00
Тезисы:
http://www.highload.ru/2017/abstracts/3069.html
Если ещё 10 лет назад движение нереляционных СУБД подчёркнуто называлось NoSQL и ходило под лозунгом «SQL is kludge», то сейчас мы видим, что на SQL можно «поговорить» практически с любыми источниками данных: двигаясь от SQL-подобных диалектов (вроде HiveQL, AQL, CQL), возникла целая плеяда SQL-on-Hadoop, среди которых есть способный просверлиться в самые невероятные нереляционные структуры Apache Drill, а в конце августа 2017 появился даже KSQL — SQL-движок над поточником Apache Kafka. И гордость российского NoSQL-субдостроения — Tarantool — также оснастился SQL-движком, а в мире IMDG (резидентных гридов данных) уже речь идёт не просто о поддержке SQL, а ведётся соревнование между движками за полноту соответствия стандартам SQL-99.
...
Архитектура растущего проекта на примере ВКонтакте / Алексей Акулович (ВКонт...Ontico
В докладе я расскажу о проблемах роста, с которыми сталкивался проект как в плане доступа к БД, так и в целом. Как решали, что получалось, как (общетеоретически или практически) можно решать подобные проблемы в других проектах.
Разберем несколько реальных случаев, когда что-то шло не так.
Доклад можно рассматривать и как небольшой экскурс в развитие технической платформы ВК, и как собрание нескольких практических способов для проекта вырасти и стать надежнее.
Примеры использования базы clickhouse для анализа данных.
Экспорт данных access.log в clickhouse. Примеры анализа скорости пользователей на основе логов сервера.
The new realise of one Microsoft flagman product is approaching – SQL Server. New realizes of SQL Server are not so often, that is why every new realise causes a splash of society activities and wide discussions. We already know the content of the new realise and the product is going through the last stages of testing before the launch. Let’s look, what new things wull bring us new SQL Server.
Денис Колошко, Пример нагруженной системы на базе продуктов Microsoft, Amazon...Tanya Denisyuk
Будет показан пример архитектуры популярной социальной сети в Англии, переработанной на новом стеке, чтобы решить проблемы производительности, отказоустойчивости и горизонтального масштабирования. Новый стек базируется на технологиях: .NET, SignalR, Couchbase, RabbitMQ, ElasticSearch, Amazon Services (CloudFront, S3, EC2, Route 53, Balancer), Windows, Linux. Цель: показать одну из моделей архитектуры нагруженных веб-систем, практики и возможные подводные камни при разработке высоконагруженных Интернет систем.
Керівники проектів часто стикаються з тим, що здійснення масштабних і багатоцільових проектів являє собою певну складність. В результаті їм допомагають в управлінні такими проектами з роками накопичені знання та інтуїція, оскільки досвіду виявляється недостатньо і проект поповнює розділ невдах у черговому Chaos Report.
У своїй доповіді проаналізую сучасні тренди в проектному менеджменті і поміркую на тему інженерної, соціально і емерджентної складності в проектах.
Управление ожиданиями заказчика при построении R&D центра в УкраинеAleksey Solntsev
При открытии нового R&D центра любой заказчик думает, что в миг все его проблемы уйдут. Чудодейственный Agile всех вылечит, а Jira даст кристально чистую картинку происходящего. Продукты начнут появляться на свет с невиданной скоростью и с очень высоким уровнем качества. В реальности же всё оказывается намного сложнее. И именно управление ожиданиями заказчика становится ключевым процессом и очень сильно влияет на успех нового R&D центра в будущем.
Полной автоматизацией процесса сборки приложения уже никого не удивишь. Не в последнюю очередь благодаря Maven – системе управления жизненным циклом проекта. Однако проекты растут очень быстро: увеличивается количество модулей, тестов, зависимостей, используемых плагинов. И всего лишь за год легковесный проект, на сборку которого уходило 5 минут, превращается в монстра, который пожирает время разработчиков 30-минутной сборкой. Чтобы справится с этой проблемой разработчикам приходится постоянно чистить свой код и бороться со скоростью выполнения тестов. Это верное решение, но не следует забывать о том, что и сам процесс сборки можно улучшить. В этом докладе будет рассмотрено, как при помощи простых и нехитрых шагов можно оптимизировать работу с зависимостями и обогатить скрипты сборки полезными плагинами. Также будут обсуждаться тонкости конфигурации основных плагинов и особенности работы с командной строкой, которые появились в последней версии Maven.
«Inspect and adapt» один из ключевых принципов любой Agile методологии. Поэтому если вы ходите поднять эффективность вашей команды, вам не обойтись без ретроспектив. Они предназначены не только для улучшения процесса разработки, но и используются для регулярной оценки командного духа.
В ходе доклада мы рассмотрим ключевые этапы проведения ретроспектив, разберём не только основные проблемы на каждом из этих этапов, но и способы их решения. К примеру, вы получите информацию о том, что нужно делать чтобы ретроспектива не переросла в «blame session» и о том, какие методы сбора и анализа информации работают наиболее эффективно.
К тому же мы проанализируем всевозможные форматы проведения ретроспектив, потому как формат «что мы сделали хорошо – что мы сделали плохо» очень быстро надоедает и перестаёт работать.
Although all of us speak the same language, each of us uses different meaning of words "soon”, "fine” and "done”. That’s why for one developer "I’m done” means that just a moment ago the part of the code with implemented functionality has been successfully executed, while for another developer it means that code has been committed to repository but without checking if build is green or not on continuous integration server. At the same time "done" of developer-perfectionist means totally refactored and optimized code. And only for "black swan”-developer phrase "I'm done“ means that all tests were passed, new functionality was documented on wiki and a new feature was verified by customer on the demo server.
So if you want to decrease a risk of misunderstanding inside a team or between team and customer you should make agreement about common vision of “definition of done“ and then start using it on a daily basis. In order to prevent losing your time and stepping on the hidden rake during discussion of your done criteria we will share our knowledge about creating compact and most effective “definition of done“. We will talk about lifecycle of this document and about approaches that help you to add important items to it. We will discuss doneness on different levels (preplanning, user story and task development, sprint). And of course we won’t forget to tell you how to create “Definition of Done“ which will satisfy not only your team but your customer as well.
Многие жалуются на качество кода, автоматизированных тестов или продукта в целом, на количество ошибок, найденных конечными пользователями или отделом тестирования. Почему это происходит? Необходимо понимать, что для того чтобы не допустить подобных ситуаций требуются дополнительные усилия – необходимо следить за качеством кода и работать над его улучшением.
Code Review является одной из наиболее полезных и эффективных практик для ранней борьбы с дефектами в коде и повышению его качества. Использование Code Review на различных этапах разработки, начиная от дизайна и заканчивая написанием кода и тестов, помогает построить ранний цикл обратной связи и избежать потерь времени в будущем на исправление ошибок.
Дополнительным преимуществом применения Code Review является распространение знаний между членами команды и адаптация других командных подходов. Данная практика может быть интересна любому члену команды вне зависимости от его роли в проекте.
В докладе будут рассмотрены основные аспекты Code Review, способы проведения, инструменты и техники. Также будут продемонстрированы основные ошибки в использовании этой практики, полезные советы, приемы по внедрению и поддержке.
Nikolay Alimenkou and Aleksey Solntsev will show how to migrate from Ant project to Maven2 project and start using full power of XP engineering practices: CI, TDD, refactoring.
1.
NoSQL – взрыв возможностей
Алексей Солнцев, iForum, 17 апреля 2012
2. О себе
10 лет в индустрии
информационных технологий
Solution Architect в компании
Infopulse Украина
Agile волонтёр
Организатор и координатор
краудсорсинг-переводов книг на
русский язык
Алексей
Тренер в центре XP Injection
Солнцев
@a_solntsev
9. Информация в фактах
Обрабатывает Хранит свыше Получает 160 За 20 минут
24 петабайта 2 миллиардов миллионов добавляют 10
информации в фотографий твиттов в миллионов
день месяц комментариев
@a_solntsev
10. Проблемы цифровой вселенной
Объёмы данных
Связанность данных
Слабая структурируемость данных
Обработка данных при помощи
независимых сервисов
@a_solntsev
11. Ограничения реляционных СУБД
Фиксированная структура
Разряженные таблицы
JOIN плохо масштабируется
Блокировки при записи
Работа с медленными дисками
@a_solntsev
23. Key -Value
Ключ – DHT Кэширование
Хранение сессий
Value – String, Set Хранение логов
Примитивные операции In-memory
Сохранение на
Нет составных запросов диск
@a_solntsev
25. Amazon Dynamo и Basho Riak
Решение для
систем, требующих
высокую степень
доступности
Децентрализованная, расп
ределённая база данных
@a_solntsev
28. Согласованность «в конечном итоге»
Дано N – количество копий
R – кворум на чтение
W – кворум на запись
Если W > N/2
R+W > N
Тогда При чтении получите
последнюю версию
Иначе Получите согласованность
в «конечном итоге»
29. Согласованность и скорость ответа
Быстро, но не совсем надёжно
R = 1, W = 1, N = 3
Надёжно, но медленно
R = 2, W = 3, N = 4
30. Google BigTable и Apache HBase
Хранение огромных
объёмов данных
Обработка огромных
объёмов данных
Анализ огромных объёмов
данных
@a_solntsev
36. Схемы и запросы
Схема Запросы
MySQL Фиксированная Динамические
CouchDB Динамическая Фиксированные
MongoDB Динамическая Динамические
37. Формат документов
{
"_id" : ObjectId("497ce96f395f2f052a494fd4"),
"title" : "Awesome Blog Post",
"body" : "Text text text text, text text text ...",
"created": "Tue, 3 Jan 2011 11:13:56 GMT",
"tags" : [ "css", "javascipt", "jquery" ],
"comments" : [
{
"name" : "Kelly Glover"
"created" : "Tue, 22 Jan 2011 2:22:32 GMT",
"text" : "This is a very good ..."
},
],
"shortUrl" : "awesome-blog-post"
}
38. API для запросов
// найти записи по условию
db.stat.find({clicks: {$gt: 10} });
// найти все записи и отсортировать
db.users.find({}).sort({name: 1});
//найти все записи, пропустить первые 20 записей
db.users.find().skip(20).limit(10);