В этой презентации мы расскажем о своем опыте применения этого хранилища на примере одной из самых высоконагруженных подсистем — хранилища Класс!ов. В данный момент в системе хранится около 50 миллиардов записей о Класс!, что занимает в сумме около 8 Тб. Для того чтобы реализовать такое хранилище пришлось отойти от классического способа работы с Cassandra. Мы расскажем об этом, а также о том, как Cassandra устроена под капотом, её сильные и слабые стороны, какие решения мы принимали и что мы изменили в Cassandra, чтобы сделать наше хранилище более высокопроизводительным и надежным.
"YT — новая платформа распределённых вычислений". Максим Бабенко, Яндекс. Yandex
На протяжении трёх лет мы проектировали, разрабатывали и внедряли YT — новую платформу для хранения и обработки больших объёмов данных. Она создавалась как альтернатива MapReduce-подобной системы, которая используется в Яндексе с 2008 года. При этом требовалось повысить её эффективность, доступность и масштабируемость. Задачу усложнял огромный объём унаследованного кода клиентов, с которыми необходимо было сохранить совместимость, а также наличие общепризнанных открытых альтернатив (например, платформы Hadoop). Поскольку YT изначально проектировалась по принципу «больше чем MapReduce», в её дизайне выделяется набор компонент, допускающих повторное использование: подсистема распределённого консенсуса и репликации состояния, дерево метаданных, blob-хранилище и другие. В докладе я дам краткий обзор архитектуры новой системы, расскажу о нескольких ключевых компонентах, а также поделюсь опытом, полученным в процессе разработки и внедрения. В завершение, перечислю приоритетные направления дальнейшего развития YT.
Защита данных и датацентров от катастроф. Подход Nutanix / Максим Шапошников ...Ontico
+ Защита данных — это не "одна кнопка", нет годного любому единого решения. Задача всегда диктует выбор средств и решений.
+ RTO — Recovery Time Objective — максимальное время, за которое все ваши бизнес-задачи должны полностью быть восстановлены в работоспособное состояние после полной катастрофы ДЦ.
+ RPO — Recovery Point Objective — максимально приемлемый для ваших задач промежуток времени, за который вы готовы потерять данные.
+ Защита на уровне приложений. Приложение лучше всех знает, как защищать и реплицировать свои данные.
+ Асинхронная репликация — наилучший выход с точки зрения производительности, единственно возможный вариант в случае значительного географического разнесения дата-центров (сотни и более километров). Работает на уровне виртуальных машин.
+ Метро / "растянутые" кластеры и синхронная репликация — нулевой RPO, минимальный RTO, большие потери производительности и множество ограничений. Но иногда — единственный выход, если уровень приложения не умеет реплицировать данные.
+ Лучший подход — комбинация из репликации на уровне приложений, асинхронной и синхронной репликации средствами хранилища.
+ Что есть у Nutanix для решения подобных задач: DR (Async replication), Metro availability cluster, Timestream Backup.
+ Реализация решения с использованием Nutanix на примере FBI: крупнейший VDI в США. Защищенная, mission-critical инфраструктура на 70 тысяч виртуальных десктопов. Асинхронная репликация дата-центров на 1500 миль, защита данных от катастроф.
В этой презентации мы расскажем о своем опыте применения этого хранилища на примере одной из самых высоконагруженных подсистем — хранилища Класс!ов. В данный момент в системе хранится около 50 миллиардов записей о Класс!, что занимает в сумме около 8 Тб. Для того чтобы реализовать такое хранилище пришлось отойти от классического способа работы с Cassandra. Мы расскажем об этом, а также о том, как Cassandra устроена под капотом, её сильные и слабые стороны, какие решения мы принимали и что мы изменили в Cassandra, чтобы сделать наше хранилище более высокопроизводительным и надежным.
"YT — новая платформа распределённых вычислений". Максим Бабенко, Яндекс. Yandex
На протяжении трёх лет мы проектировали, разрабатывали и внедряли YT — новую платформу для хранения и обработки больших объёмов данных. Она создавалась как альтернатива MapReduce-подобной системы, которая используется в Яндексе с 2008 года. При этом требовалось повысить её эффективность, доступность и масштабируемость. Задачу усложнял огромный объём унаследованного кода клиентов, с которыми необходимо было сохранить совместимость, а также наличие общепризнанных открытых альтернатив (например, платформы Hadoop). Поскольку YT изначально проектировалась по принципу «больше чем MapReduce», в её дизайне выделяется набор компонент, допускающих повторное использование: подсистема распределённого консенсуса и репликации состояния, дерево метаданных, blob-хранилище и другие. В докладе я дам краткий обзор архитектуры новой системы, расскажу о нескольких ключевых компонентах, а также поделюсь опытом, полученным в процессе разработки и внедрения. В завершение, перечислю приоритетные направления дальнейшего развития YT.
Защита данных и датацентров от катастроф. Подход Nutanix / Максим Шапошников ...Ontico
+ Защита данных — это не "одна кнопка", нет годного любому единого решения. Задача всегда диктует выбор средств и решений.
+ RTO — Recovery Time Objective — максимальное время, за которое все ваши бизнес-задачи должны полностью быть восстановлены в работоспособное состояние после полной катастрофы ДЦ.
+ RPO — Recovery Point Objective — максимально приемлемый для ваших задач промежуток времени, за который вы готовы потерять данные.
+ Защита на уровне приложений. Приложение лучше всех знает, как защищать и реплицировать свои данные.
+ Асинхронная репликация — наилучший выход с точки зрения производительности, единственно возможный вариант в случае значительного географического разнесения дата-центров (сотни и более километров). Работает на уровне виртуальных машин.
+ Метро / "растянутые" кластеры и синхронная репликация — нулевой RPO, минимальный RTO, большие потери производительности и множество ограничений. Но иногда — единственный выход, если уровень приложения не умеет реплицировать данные.
+ Лучший подход — комбинация из репликации на уровне приложений, асинхронной и синхронной репликации средствами хранилища.
+ Что есть у Nutanix для решения подобных задач: DR (Async replication), Metro availability cluster, Timestream Backup.
+ Реализация решения с использованием Nutanix на примере FBI: крупнейший VDI в США. Защищенная, mission-critical инфраструктура на 70 тысяч виртуальных десктопов. Асинхронная репликация дата-центров на 1500 миль, защита данных от катастроф.
Тюним память и сетевой стек в Linux: история перевода высоконагруженных серве...Ontico
В процессе обновления высоконагруженных серверов раздачи видео (40Gbit/s с каждого сервера) со старого OpenSuSE 10.2 на новый CentOS 7 (время между релизами — 7 лет) мы столкнулись с рядом проблем — необъяснимый свопинг и запуски OOM killer, неравномерное распределение нагрузки по ядрам, обрывы соединений, скачки системной нагрузки на CPU.
В докладе будет рассказано о том, как мы боролись с этими проблемами и какие технологии для этого использовали.
Chronicle Map — key-value хранилище для трейдинга на Java / Левентов Роман (C...Ontico
Сфера финансовых приложений и трейдинга выдвигает особые требования к системам обработки данных: ультракороткие задержки, конкурентные обновления (в т.ч. из разных процессов), репликация высокочастотных обновлений.
Существовавшие открытые key-value хранилища не справлялись, поэтому мы сделали свое — Chronicle Map.
В докладе я отвечу на вопросы:
+ Почему бывает эффективнее разбить систему, работающую с общим состоянием, на несколько отдельных процессов?
+ Зачем вам может захотеться распилить JVM на несколько частей?
+ Как добиться от key-value хранилища медианной latency меньше 1 микросекунды?
+ Как сделать репликацию, если она упирается в пропускную способность сети из-за слишком частых обновлений?
Развею миф о том, что Java — это медленно :)
Также, в докладе будет сравнение Chronicle Map с redis, one-nio и ConcurrentHashMap.
Технологии хранения для больших проектов / Сергей Платонов (RAIDIX)Ontico
HighLoad++ 2017
Зал «Пекин+Шанхай», 7 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2990.html
Мы ежедневно сталкиваемся с тем, что даже работающие более 15 лет в индустрии специалисты, путаются в понятиях и преимуществах и недостатках тех или иных архитектур больших СХД.
В своем докладе мы расскажем о разнице между distributed (распределенными), shared (общими) и параллельными файловыми системами, покажем, в каких задачах Scale In-системы превосходят Scale Out и наоборот.
...
Чем заняться вечером, если я знаю сколько будет ++i + ++i / Андрей Бородин (Y...Ontico
HighLoad++ 2017
Зал «Пекин + Шанхай», 8 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2960.html
При изучении алгоритмов и структур данных я предлагаю студентам закрепить знания и попытаться сделать мир лучше, выполнив небольшие проекты по внедрению эффективных алгоритмов в свободное программное обеспечение. В этом докладе я расскажу несколько идей для таких проектов.
Мы рассмотрим существующие фрагменты исходного кода, поговорим о том, что в нём можно допилить, и обсудим, сколько баллов за это надо давать.
Реализацией идей могут заняться, разумеется, все желающие.
До недавнего времени в Одноклассниках около 50 ТБ данных, обрабатываемых в реальном времени, хранилось в Microsoft SQL Server. Многие знают, что для такого объема обеспечить быстрый и надежный, да еще и устойчивый к отказу ЦОД доступ, используя SQL СУБД, практически невозможно. Обычно в таких случаях используют одно из NoSQL хранилищ, но не всё можно перенести в NoSQL: некоторые сущности требуют гарантий ACID-транзакций.
Это ограничение подвело нас к необходимости использования NewSQL хранилища, то есть СУБД, предоставляющей отказоустойчивость, масштабируемость и быстродействие NoSQL-систем, но при этом сохраняющей привычные для классических систем ACID-гарантии. Работающих промышленных систем этого нового класса немного (сразу приходит на ум только Google Spanner), а доступных — и вовсе нет. Поэтому мы реализовали такую систему сами на любимой нами Java и запустили ее в промышленную эксплуатацию несколько месяцев назад.
Доклад про то, как устроено это хранилище будет интересен всем, кто следит за развитием технологий управления базами данных и имеет опыт работы с (No)SQL.
сравнение производительности СУБД MySQL и PostgreSQL для "типичной задачи стартапа".
Презентация сопровождала тестовую online-сессию и потому не содержит результатов тестирования.
Ceph является одной из мнообещающих архитектур для построения облачных хранилищ данных. В презентации приведены основные возможности, описана архитектура, дан краткий обзор команд CLI
Я и моя группа занимаемся разработкой страницы Яндекс.Браузера, весь наш фронтенд построен на Node.js. Для нас очень важно максимально быстро отвечать нашим пользователям, и не только потому, что тем самым мы снижаем потребление нами системных ресурсов, а прежде всего для того, чтобы наш пользователь не ожидал лишние десятки миллисекунд и не терял интерес к нашим страницам.
Многие исследования подтверждают — каждые 100мс ожидания загрузки страницы вы теряете долю пользователей, которые ждать не захотели. Именно поэтому после того, как некоторые страницы сильно разрослись и время ответа перестало удовлетворять нас, я начал исследование узких мест.
Я перебрал множество доступных на данный момент инструментов профилирования Node.js приложений, покопался с работой оптимизаторов V8 и в результате за две недели уменьшил время ответа нашей страницы в 2.5 раза, а теперь я бы хотел поделиться с вами своим опытом.
Что особенного в СУБД для данных в оперативной памяти / Константин Осипов (Ta...Ontico
Оперативная память становится всё более дешёвой и производительной, что позволяет использовать её для хранения рабочего набора данных всё большего числа приложений. Хранение всех данных в оперативной памяти позволяет сделать их высоко доступными, а алгоритмы для работы с данными либо существенно упростить, либо ускорить, а иногда — и то, и другое.
Тезисы - http://www.highload.ru/2015/abstracts/1964.html
Тюним память и сетевой стек в Linux: история перевода высоконагруженных серве...Ontico
В процессе обновления высоконагруженных серверов раздачи видео (40Gbit/s с каждого сервера) со старого OpenSuSE 10.2 на новый CentOS 7 (время между релизами — 7 лет) мы столкнулись с рядом проблем — необъяснимый свопинг и запуски OOM killer, неравномерное распределение нагрузки по ядрам, обрывы соединений, скачки системной нагрузки на CPU.
В докладе будет рассказано о том, как мы боролись с этими проблемами и какие технологии для этого использовали.
Chronicle Map — key-value хранилище для трейдинга на Java / Левентов Роман (C...Ontico
Сфера финансовых приложений и трейдинга выдвигает особые требования к системам обработки данных: ультракороткие задержки, конкурентные обновления (в т.ч. из разных процессов), репликация высокочастотных обновлений.
Существовавшие открытые key-value хранилища не справлялись, поэтому мы сделали свое — Chronicle Map.
В докладе я отвечу на вопросы:
+ Почему бывает эффективнее разбить систему, работающую с общим состоянием, на несколько отдельных процессов?
+ Зачем вам может захотеться распилить JVM на несколько частей?
+ Как добиться от key-value хранилища медианной latency меньше 1 микросекунды?
+ Как сделать репликацию, если она упирается в пропускную способность сети из-за слишком частых обновлений?
Развею миф о том, что Java — это медленно :)
Также, в докладе будет сравнение Chronicle Map с redis, one-nio и ConcurrentHashMap.
Технологии хранения для больших проектов / Сергей Платонов (RAIDIX)Ontico
HighLoad++ 2017
Зал «Пекин+Шанхай», 7 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2990.html
Мы ежедневно сталкиваемся с тем, что даже работающие более 15 лет в индустрии специалисты, путаются в понятиях и преимуществах и недостатках тех или иных архитектур больших СХД.
В своем докладе мы расскажем о разнице между distributed (распределенными), shared (общими) и параллельными файловыми системами, покажем, в каких задачах Scale In-системы превосходят Scale Out и наоборот.
...
Чем заняться вечером, если я знаю сколько будет ++i + ++i / Андрей Бородин (Y...Ontico
HighLoad++ 2017
Зал «Пекин + Шанхай», 8 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2960.html
При изучении алгоритмов и структур данных я предлагаю студентам закрепить знания и попытаться сделать мир лучше, выполнив небольшие проекты по внедрению эффективных алгоритмов в свободное программное обеспечение. В этом докладе я расскажу несколько идей для таких проектов.
Мы рассмотрим существующие фрагменты исходного кода, поговорим о том, что в нём можно допилить, и обсудим, сколько баллов за это надо давать.
Реализацией идей могут заняться, разумеется, все желающие.
До недавнего времени в Одноклассниках около 50 ТБ данных, обрабатываемых в реальном времени, хранилось в Microsoft SQL Server. Многие знают, что для такого объема обеспечить быстрый и надежный, да еще и устойчивый к отказу ЦОД доступ, используя SQL СУБД, практически невозможно. Обычно в таких случаях используют одно из NoSQL хранилищ, но не всё можно перенести в NoSQL: некоторые сущности требуют гарантий ACID-транзакций.
Это ограничение подвело нас к необходимости использования NewSQL хранилища, то есть СУБД, предоставляющей отказоустойчивость, масштабируемость и быстродействие NoSQL-систем, но при этом сохраняющей привычные для классических систем ACID-гарантии. Работающих промышленных систем этого нового класса немного (сразу приходит на ум только Google Spanner), а доступных — и вовсе нет. Поэтому мы реализовали такую систему сами на любимой нами Java и запустили ее в промышленную эксплуатацию несколько месяцев назад.
Доклад про то, как устроено это хранилище будет интересен всем, кто следит за развитием технологий управления базами данных и имеет опыт работы с (No)SQL.
сравнение производительности СУБД MySQL и PostgreSQL для "типичной задачи стартапа".
Презентация сопровождала тестовую online-сессию и потому не содержит результатов тестирования.
Ceph является одной из мнообещающих архитектур для построения облачных хранилищ данных. В презентации приведены основные возможности, описана архитектура, дан краткий обзор команд CLI
Я и моя группа занимаемся разработкой страницы Яндекс.Браузера, весь наш фронтенд построен на Node.js. Для нас очень важно максимально быстро отвечать нашим пользователям, и не только потому, что тем самым мы снижаем потребление нами системных ресурсов, а прежде всего для того, чтобы наш пользователь не ожидал лишние десятки миллисекунд и не терял интерес к нашим страницам.
Многие исследования подтверждают — каждые 100мс ожидания загрузки страницы вы теряете долю пользователей, которые ждать не захотели. Именно поэтому после того, как некоторые страницы сильно разрослись и время ответа перестало удовлетворять нас, я начал исследование узких мест.
Я перебрал множество доступных на данный момент инструментов профилирования Node.js приложений, покопался с работой оптимизаторов V8 и в результате за две недели уменьшил время ответа нашей страницы в 2.5 раза, а теперь я бы хотел поделиться с вами своим опытом.
Что особенного в СУБД для данных в оперативной памяти / Константин Осипов (Ta...Ontico
Оперативная память становится всё более дешёвой и производительной, что позволяет использовать её для хранения рабочего набора данных всё большего числа приложений. Хранение всех данных в оперативной памяти позволяет сделать их высоко доступными, а алгоритмы для работы с данными либо существенно упростить, либо ускорить, а иногда — и то, и другое.
Тезисы - http://www.highload.ru/2015/abstracts/1964.html
Виртуализация уровня операционной системы в Linux (так, называемые контейнеры) опирается на изоляцию ресурсов и на управление их использованием. Пространства имен в Linux (linux namespaces) тот инструмент, который позволяет изолировать ресурсы друг от друга на уровне имен. Например, именами процессов являются их идентификаторы (PIDs), которые можно организовать таким образом, что процессы никогда не могут узнать о существовании друг друга. Об этом и других интересных вещах рассказывается в презентации.
Yevgen Lysenko "AWS RDS Aurora Serverless, ECS Fargate and more serverless-pr...Fwdays
Marketing materials and documentation of AWS and other cloud providers do present their Serverless-services as a future of cloud computing, that ought to solve nearly all current problems. Is that so? Is there something marketers and documentation are hiding from us? What are costs and productivity?
Обзор перспективных баз данных для highload / Юрий НасретдиновOntico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 5 июня, 10:00
Тезисы:
http://backendconf.ru/2017/abstracts/2773.html
В этом докладе я рассмотрю несколько перспективных, на мой взгляд, баз данных, которые пока еще не очень популярны, но которые определенно ждет успех в будущем, особенно для highload-проектов. Я расскажу о Tarantool, ClickHouse и CockroachDB, о том, как они устроены, и почему я считаю, что они в будущем станут стандартом де-факто, как раньше был MySQL, а сейчас — MongoDB.
...
2. План
1) Что такое Apache Cassandra
2) Типы данных
3) Как хранятся данные
4) Ключ
5) CQL
6) CQLSH
7) Создание индексов
8) Запись на диск
9) Конфиг файл
3. Что такое Кассандра
Касса́ндра (Cassandra, др.-греч.
Κασσάνδρα) — в древнегреческой
мифологии дочь последнего троянского
царя Приама и его второй супруги Гекубы.
Получила пророческий дар от
влюбившегося в неё Аполлона, однако за
то, что она, обманув, не ответила ему
взаимностью, он сделал так, что
предсказаниям Кассандры никто не верил.
4. Apache Cassandra
● NOSQL database
● Free, Open source
● Лицензия: Apache License 2.0
● Написана на Java в Facebook (2009)
● 4GB ram минимум (32GB рекоменд.)
● Разработа для хранения больших
объемов данных и для частой записи
● Предназначена:
○ Запись данных с устройств
○ Аналитика соц. медиа
5. Типы данных
● int
● bigint
● boolean
● float
● double
● text
● UUID
● timestamp
● blob
● Collections: list, set, map
6. Модель данных
Модель данных Cassandra состоит из:
1) Пространства ключей (keyspace)
2) Семейств столбцов (Column Family)
3) Ключ (row key)
4) Запись (row)
5) Колонка (column)
a) Имя (name)
b) Значение (value)
c) Временная метка
7. Ключ
Кассандра поддерживает композитные ключи.
● Partition key - первый ключ
● Clustering key - остальные ключи
Partition key - определяет где будет хранится запись
Clustering key - поля, по которым планируется делать поиск.
8. CQL
Что такое CQL - Cassandra query language.
Пример синтаксиса:
select * from user where id = ‘1000’’;
insert into user (id, name) values (‘1001’, ‘Sid’);
delete from user where id = ‘1001’;
10. Особенности запросов
Мы хотим взять данные в каком-то промежутке.
SELECT * FROM user WHERE balance > 5000 AND friends < 100
SELECT * FROM user WHERE balance > 5000 AND friends < 100 ALLOW FILTERING;
12. Согласованность данных
Для каждого запроса, как на чтение, так и на запись, есть возможность задать уровень
согласованности данных.
Для записи этот уровень будет влиять на количество узлов-реплик, с которых будет ожидаться
подтверждение удачного окончания операции (данные записались) перед тем, как вернуть
пользователю управление.
ONE, TWO, THREE,
QUORUM, LOCAL_QUORUM, EACH_QUORUM,
ALL, ANY
13. Распределение данных
Разные стратегии распределения данных между узлами кластера.
1) Случайный разметчик (Random partitioner)
2) Порядковый разметчик (Byte-ordered partitioner)
14.
15. CQLSH
Что такое CQLSH - командная оболочка для работы с Cassandra.
Ставится при установке Cassandra.
17. TTL
CQL поддерживает Time to live записи.
То есть записи, которые будут хранится в базе указанное время.
Пример:
INSERT INTO myTable (id, myField) VALUES (2, 9) USING TTL 86400;
18. Config file
cassandra.yaml - файл конфигурации
Что прописывается в конфигах?
● Название кластера
● Порт
● Тип авторизации
● Путь к папке с данными
● Шифрование
● Стратегию распределения данных
● Размер memtable (⅓ java heap size)