PG Day'14 Russia, PostgreSQL: архитектура, настройка и оптимизация, Илья Косм...pgdayrussia
Доклад был представлен на официальной российской конференции PG Day'14 Russia, посвященной вопросам разработки и эксплуатации PostgreSQL.
Основные принципы устройства PostgreSQL, ключевые принципы правильного конфигурирования и подходы к оптимизации под высокие нагрузки — обо всем этом Илья поведает на специальном мастер-классе, посвященном "внутренностям" СУБД. Курс предназначен как для опытных профессионалов, так и для "молодых бойцов". Полученные в ходе прослушивания семинара знания пригодятся не только на практике. Они также призваны увеличить эффективность восприятия слушателями и, как следствие, полезность докладов, запланированных на второй день конференции.
Как база работает с памятью и файловой системой? Для чего предназначено версионирование? Что такое транзакции, как они устроены и почему полезны? Как строятся индексы и что происходит с запросом во время его выполнения? Что такое репликация и почему ее нельзя применять для backup/recovery? На все эти вопросы, и не только, ответит Илья.
Разобравшись с основами и "матчастью", мы перейдем к самому интересному: "тюнингу" базы в нагруженных системах, начиная с классического "Почему у меня тормозит запрос?" и заканчивая кручением "гаек" системных процессов "посгреса" под объемы данных и транзакционные нагрузки, соизмеримые с "big data".
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
Доклад "Remote Highload" c Highload++-2016
Созданием еще одной высоконагруженной системы сегодня уже сложно кого-то удивить. Как насчет высоконагруженной системы, которая была создана и эксплуатируется 100% удаленной командой, работающей в 5 часовых поясах?
В докладе пойдет речь о команде Virtustream (Dell Technologies), которая отвечает за Virtustream Storage Cloud.
Экзабайты данных, десятки тысяч серверов, сотни гигабит в секунду, сотни тысяч и миллионы запросов в секунду, 20 датацентров по всему миру и, при этом, команда разработчиков из 15 человек, это возможно?
В докладе мы поговорим о разных аспектах - от культуры разработки и процесса найма до контейнерной платформы запуска микросервисов и выбора языка программирования.
Почему не работает Scrum, и плохо работает парное программирование? Как Mesos, Marathon, Consul и Calico делают возможным выкладывание нового сервиса за 5 минут? Почему каждый разработчик должен иметь доступ в production?
Выбираем СУБД для хранения временных рядов / Павел Филонов (Лаборатория Каспе...Ontico
Проблема мониторинга целостности технологических процессов на индустриальных объектах связана с обработкой большого объема показаний различных датчиков (температура, давление, управляющие сигналы и т.д.). Каждый из таких сенсоров порождает временной ряд, который может быть использован как для потоковой обработки, так и для проведения исторического анализа и расследования инцидентов. Здесь возникает задача хранения показаний за некоторый период времени. При этом потоки данных могут достигать десятков тысяч показаний в секунду, а период хранения достигать нескольких месяцев или даже лет. При таких условиях необходимо предельно аккуратно выбирать СУБД для хранения временных рядов, которая правильно впишется в нефункциональные требования.
В качестве конкурсантов выступят: OpenTSDB, InfluxDB, MongoDB, PostgreSQL и еще несколько "чёрных лошадок".
В докладе будет рассмотрен многокритериальный подход к выбору с учетом таких показателей как:
* зависимость пропускной способности на запись от различных параметров;
* время исполнения запроса на чтение;
* степень сжатия данных;
* пропускная способность при нагрузочном тестировании.
В докладе предлагается не только привести получившиеся числа, но и обсудить почему они получились именно такими.
NoSQL — это слово громко "жужжит".
К сожалению, оно при этом ничего не означает. Это не продукт, не технология, и даже не концепция. Это даже не подход к проектированию. Это, скорее, декларация отказа от некоторых паттернов проектирования, господствовавших в разработке клиент-серверных систем долгие годы.
На этом доклад можно было бы и закончить. Если бы мы не знали достоверно, что на свете есть люди, которые умудряются извлекать прибыль, используя NoSQL в своих проектах. Ну или сокращать убытки, по крайней мере.
Попробуем еще раз.
NoSQL — это именно декларация отказа от некоторых паттернов.
- От чего именно придется отказаться? Упомянутые паттерны так живучи совсем не случайно.
- Как это ударит по проекту? Не сомневайтесь, оно ударит, в этом мире нет ни серебряных пуль, ни бесплатного сыра.
- Какими свойствами должен обладать проект, чтобы внедрение NoSQL СУБД принесло ему пользу? Избегать NoSQL — это не трусость, это осторожность.
- Каковы сильные стороны NoSQL СУБД, и в чем профит? Выбор NoSQL — это всегда выбор в пользу меньшего зла.
- Как выбрать NoSQL СУБД под свою задачу? На http://nosql-database.org/ есть список LIST OF NOSQL DATABASES [currently >225], и даже просто прочесть его — тяжелая работа.
- Почему реальный выбор NoSQL СУБД — это выбор между Aerospike и Cassandra? Да, это провокационный вопрос, но на него есть not-so-provocative ответ.
- С какими проблемами сталкиваются разработчики и администраторы при эксплуатации "тяжелой" NoSQL базы? К сожалению, большая часть этих проблем создается именно присутствием NoSQL.
- Что можно делать с NoSQL СУБД и чего нельзя? На какие параметры производительности и отказоустойчивости можно рассчитывать? В чем особенности выбора "железа" для NoSQL?
- И в чем, все-таки, profit?
На эти и некоторые другие, связанные с этими, вопросы автор намерен дать ответ в своем докладе.
PG Day'14 Russia, PostgreSQL: архитектура, настройка и оптимизация, Илья Косм...pgdayrussia
Доклад был представлен на официальной российской конференции PG Day'14 Russia, посвященной вопросам разработки и эксплуатации PostgreSQL.
Основные принципы устройства PostgreSQL, ключевые принципы правильного конфигурирования и подходы к оптимизации под высокие нагрузки — обо всем этом Илья поведает на специальном мастер-классе, посвященном "внутренностям" СУБД. Курс предназначен как для опытных профессионалов, так и для "молодых бойцов". Полученные в ходе прослушивания семинара знания пригодятся не только на практике. Они также призваны увеличить эффективность восприятия слушателями и, как следствие, полезность докладов, запланированных на второй день конференции.
Как база работает с памятью и файловой системой? Для чего предназначено версионирование? Что такое транзакции, как они устроены и почему полезны? Как строятся индексы и что происходит с запросом во время его выполнения? Что такое репликация и почему ее нельзя применять для backup/recovery? На все эти вопросы, и не только, ответит Илья.
Разобравшись с основами и "матчастью", мы перейдем к самому интересному: "тюнингу" базы в нагруженных системах, начиная с классического "Почему у меня тормозит запрос?" и заканчивая кручением "гаек" системных процессов "посгреса" под объемы данных и транзакционные нагрузки, соизмеримые с "big data".
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
Доклад "Remote Highload" c Highload++-2016
Созданием еще одной высоконагруженной системы сегодня уже сложно кого-то удивить. Как насчет высоконагруженной системы, которая была создана и эксплуатируется 100% удаленной командой, работающей в 5 часовых поясах?
В докладе пойдет речь о команде Virtustream (Dell Technologies), которая отвечает за Virtustream Storage Cloud.
Экзабайты данных, десятки тысяч серверов, сотни гигабит в секунду, сотни тысяч и миллионы запросов в секунду, 20 датацентров по всему миру и, при этом, команда разработчиков из 15 человек, это возможно?
В докладе мы поговорим о разных аспектах - от культуры разработки и процесса найма до контейнерной платформы запуска микросервисов и выбора языка программирования.
Почему не работает Scrum, и плохо работает парное программирование? Как Mesos, Marathon, Consul и Calico делают возможным выкладывание нового сервиса за 5 минут? Почему каждый разработчик должен иметь доступ в production?
Выбираем СУБД для хранения временных рядов / Павел Филонов (Лаборатория Каспе...Ontico
Проблема мониторинга целостности технологических процессов на индустриальных объектах связана с обработкой большого объема показаний различных датчиков (температура, давление, управляющие сигналы и т.д.). Каждый из таких сенсоров порождает временной ряд, который может быть использован как для потоковой обработки, так и для проведения исторического анализа и расследования инцидентов. Здесь возникает задача хранения показаний за некоторый период времени. При этом потоки данных могут достигать десятков тысяч показаний в секунду, а период хранения достигать нескольких месяцев или даже лет. При таких условиях необходимо предельно аккуратно выбирать СУБД для хранения временных рядов, которая правильно впишется в нефункциональные требования.
В качестве конкурсантов выступят: OpenTSDB, InfluxDB, MongoDB, PostgreSQL и еще несколько "чёрных лошадок".
В докладе будет рассмотрен многокритериальный подход к выбору с учетом таких показателей как:
* зависимость пропускной способности на запись от различных параметров;
* время исполнения запроса на чтение;
* степень сжатия данных;
* пропускная способность при нагрузочном тестировании.
В докладе предлагается не только привести получившиеся числа, но и обсудить почему они получились именно такими.
NoSQL — это слово громко "жужжит".
К сожалению, оно при этом ничего не означает. Это не продукт, не технология, и даже не концепция. Это даже не подход к проектированию. Это, скорее, декларация отказа от некоторых паттернов проектирования, господствовавших в разработке клиент-серверных систем долгие годы.
На этом доклад можно было бы и закончить. Если бы мы не знали достоверно, что на свете есть люди, которые умудряются извлекать прибыль, используя NoSQL в своих проектах. Ну или сокращать убытки, по крайней мере.
Попробуем еще раз.
NoSQL — это именно декларация отказа от некоторых паттернов.
- От чего именно придется отказаться? Упомянутые паттерны так живучи совсем не случайно.
- Как это ударит по проекту? Не сомневайтесь, оно ударит, в этом мире нет ни серебряных пуль, ни бесплатного сыра.
- Какими свойствами должен обладать проект, чтобы внедрение NoSQL СУБД принесло ему пользу? Избегать NoSQL — это не трусость, это осторожность.
- Каковы сильные стороны NoSQL СУБД, и в чем профит? Выбор NoSQL — это всегда выбор в пользу меньшего зла.
- Как выбрать NoSQL СУБД под свою задачу? На http://nosql-database.org/ есть список LIST OF NOSQL DATABASES [currently >225], и даже просто прочесть его — тяжелая работа.
- Почему реальный выбор NoSQL СУБД — это выбор между Aerospike и Cassandra? Да, это провокационный вопрос, но на него есть not-so-provocative ответ.
- С какими проблемами сталкиваются разработчики и администраторы при эксплуатации "тяжелой" NoSQL базы? К сожалению, большая часть этих проблем создается именно присутствием NoSQL.
- Что можно делать с NoSQL СУБД и чего нельзя? На какие параметры производительности и отказоустойчивости можно рассчитывать? В чем особенности выбора "железа" для NoSQL?
- И в чем, все-таки, profit?
На эти и некоторые другие, связанные с этими, вопросы автор намерен дать ответ в своем докладе.
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.
Rspamd — высокопроизводительная система фильтрации спама / Стахов Всеволод (U...Ontico
Rspamd — это система фильтрации спама с открытым кодом, выполняющая оценку e-mail сообщений по множеству критериев, который возник как попытка адаптировать фильтрацию спама к современным реалиям и постоянно растущему потоку электронных писем, нуждающихся в обработке.
Тезисы - http://www.highload.ru/2015/abstracts/1892.html
Метаданные для кластера: гонка key-value-героев / Руслан Рагимов, Светлана Ла...Ontico
HighLoad++ 2017
Зал Дели + Калькутта, 7 ноября, 10:00
Тезисы:
http://www.highload.ru/2017/abstracts/2974.html
Обзоры и сравнения key-value баз данных, коих сегодня огромное количество, пестрят обещаниями миллионов операций в секунду с менее чем миллисекундными задержками.
Мы строим высокопроизводительный кластер хранения, и нам нужно где-то хранить метаданные. Одним из вариантов стали хвалёные key-value-решения. Справятся ли они с такой нагрузкой?
...
Велосипед уже изобретен. Что умеют промышленные СХД? / Антон Жбанков (Nutanix)Ontico
Зачем мы каждый раз изобретаем велосипед, только потому что можем? Корпоративные СХД существуют более 25 лет и умеют очень многое.
Защита данных, качество обслуживания, многоуровневое хранение и кэширование на флэш-памяти. Система хранения данных - это не только гигабайт по минимальной цене, но так же и гарантированная производительность и отказоустойчивость.
Вы узнаете, как можно обеспечить своим данным высокую степень защиты, значительно сократив время реализации проекта. Или, наоборот, убедитесь в том, что СХД корпоративного класса вашему проекту не подходят.
My talk on Hadoop stack operations engineering at OSPConAlex Chistyakov
My talk on Hadoop stack operations engineering at OSPCon Nov 2015 (http://www.ospcon.ru/event/prakticheskaya-konferentsiya-tekhnologii-bolshikh-dannykh_130.html)
16 декабря, DEV {highload} - конференция о Highload веб-разработке, "Эксплуат...IT-Portfolio
16 декабря, DEV {highload} - конференция о Highload веб-разработке, "Эксплуатация HBase на паре жизненных примеров", Александр Чистяков (ведущий разработчик Git in Sky)
Екатерина Войденко "Горизонтальное масштабирование MySQL"Yandex
Екатерина Войденко "Горизонтальное масштабирование MySQL"
Я.Субботник в Санкт-Петербурге
О докладе:
Мы попытаемся понять, что делать, если наша база стала слишком большой. Немного поговорим про архитектурные моменты. Рассмотрим некоторые схемы шардирования, обсудим партиционирование и для чего оно нужно, а также затронем балансировку нагрузки.
Про некоторые кейсы использования elasticsearch в современных проектах.
- С какими сложностями столкнулись
- Где успешо применили elasticsearch, а где был избыточен
Презентация с мероприятия https://habr.com/ru/company/odnoklassniki/blog/452978/
MySQL: чек-лист для новичка в highload (Cвета Cмирнова, Aнастасия Распопина ...Anastasia Rostova
Подтемы доклада:
- обзор форков MySQL (для каких специфических задач подойдут форки вместо оригинального MySQL);
- что такое highload в современном мире (где ещё не highload, а где уже highload);
- что храним в памяти, что на диске;
- кэширование;
- кластеризация;
- репликация/шардинг базы данных;
- умеет ли СУБД кросс-датацентр репликацию;
- MySQL-индексы;
- настройка MySQL под нагрузку;
- лог медленных запросов в MySQL + анализ запросов;
- как понять, что "тупит" не MySQL.
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.
Rspamd — высокопроизводительная система фильтрации спама / Стахов Всеволод (U...Ontico
Rspamd — это система фильтрации спама с открытым кодом, выполняющая оценку e-mail сообщений по множеству критериев, который возник как попытка адаптировать фильтрацию спама к современным реалиям и постоянно растущему потоку электронных писем, нуждающихся в обработке.
Тезисы - http://www.highload.ru/2015/abstracts/1892.html
Метаданные для кластера: гонка key-value-героев / Руслан Рагимов, Светлана Ла...Ontico
HighLoad++ 2017
Зал Дели + Калькутта, 7 ноября, 10:00
Тезисы:
http://www.highload.ru/2017/abstracts/2974.html
Обзоры и сравнения key-value баз данных, коих сегодня огромное количество, пестрят обещаниями миллионов операций в секунду с менее чем миллисекундными задержками.
Мы строим высокопроизводительный кластер хранения, и нам нужно где-то хранить метаданные. Одним из вариантов стали хвалёные key-value-решения. Справятся ли они с такой нагрузкой?
...
Велосипед уже изобретен. Что умеют промышленные СХД? / Антон Жбанков (Nutanix)Ontico
Зачем мы каждый раз изобретаем велосипед, только потому что можем? Корпоративные СХД существуют более 25 лет и умеют очень многое.
Защита данных, качество обслуживания, многоуровневое хранение и кэширование на флэш-памяти. Система хранения данных - это не только гигабайт по минимальной цене, но так же и гарантированная производительность и отказоустойчивость.
Вы узнаете, как можно обеспечить своим данным высокую степень защиты, значительно сократив время реализации проекта. Или, наоборот, убедитесь в том, что СХД корпоративного класса вашему проекту не подходят.
My talk on Hadoop stack operations engineering at OSPConAlex Chistyakov
My talk on Hadoop stack operations engineering at OSPCon Nov 2015 (http://www.ospcon.ru/event/prakticheskaya-konferentsiya-tekhnologii-bolshikh-dannykh_130.html)
16 декабря, DEV {highload} - конференция о Highload веб-разработке, "Эксплуат...IT-Portfolio
16 декабря, DEV {highload} - конференция о Highload веб-разработке, "Эксплуатация HBase на паре жизненных примеров", Александр Чистяков (ведущий разработчик Git in Sky)
Екатерина Войденко "Горизонтальное масштабирование MySQL"Yandex
Екатерина Войденко "Горизонтальное масштабирование MySQL"
Я.Субботник в Санкт-Петербурге
О докладе:
Мы попытаемся понять, что делать, если наша база стала слишком большой. Немного поговорим про архитектурные моменты. Рассмотрим некоторые схемы шардирования, обсудим партиционирование и для чего оно нужно, а также затронем балансировку нагрузки.
Про некоторые кейсы использования elasticsearch в современных проектах.
- С какими сложностями столкнулись
- Где успешо применили elasticsearch, а где был избыточен
Презентация с мероприятия https://habr.com/ru/company/odnoklassniki/blog/452978/
MySQL: чек-лист для новичка в highload (Cвета Cмирнова, Aнастасия Распопина ...Anastasia Rostova
Подтемы доклада:
- обзор форков MySQL (для каких специфических задач подойдут форки вместо оригинального MySQL);
- что такое highload в современном мире (где ещё не highload, а где уже highload);
- что храним в памяти, что на диске;
- кэширование;
- кластеризация;
- репликация/шардинг базы данных;
- умеет ли СУБД кросс-датацентр репликацию;
- MySQL-индексы;
- настройка MySQL под нагрузку;
- лог медленных запросов в MySQL + анализ запросов;
- как понять, что "тупит" не MySQL.
MySQL: чек-лист для новичка в highload / Анастасия Распопина, Света Смирнова ...Ontico
РИТ++ 2017, HighLoad Junior
Зал Сингапур, 5 июня, 10:00
Тезисы:
http://junior.highload.ru/2017/abstracts/2737.html
В рамках данного доклада в диалоговом формате будут рассмотрены наиболее распространённые вопросы по MySQL - от краткого обзора возможностей основных вариантов этой СУБД (актуальное состояние Oracle MySQL, Percona Server и MariaDB) до выбора наиболее оптимальных значений для конкретных параметров, чтобы справиться с ростом вашего проекта.
...
Обзор перспективных баз данных для highload / Юрий НасретдиновOntico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 5 июня, 10:00
Тезисы:
http://backendconf.ru/2017/abstracts/2773.html
В этом докладе я рассмотрю несколько перспективных, на мой взгляд, баз данных, которые пока еще не очень популярны, но которые определенно ждет успех в будущем, особенно для highload-проектов. Я расскажу о Tarantool, ClickHouse и CockroachDB, о том, как они устроены, и почему я считаю, что они в будущем станут стандартом де-факто, как раньше был MySQL, а сейчас — MongoDB.
...
Build your own network security protocol and get away uncaughtDaniel Podolsky
This speech is about team which invented its own network security protocol for the big Golang project. Yes we were sober and conscious and still did it!
First of all - “why”?!
Everybody knows Go runtime SSL is quite slow. Less common it’s memory footprint could not be considered as optimal.
Yes, we do know we can link OpenSSL to our program and get as performant as NGINX, for example.
But did it cross your mind OpenSSL is also not fast enough for some corner cases? Say, you have to accept 1M new connections in 30 seconds…
The problem is: SSL is slow and CPU intensive on establishing connection phase.
On inCaller project we came across this: to perform the tasks we need 32 CPU cores only. That mean 4 servers cluster. To accept new connections fast enough we need 480 CPU cores, which give us 60 servers cluster.
60 servers cluster is about 15 times worst than 4 servers cluster, obviously.
Looking to this unpleasant math we’ve decided to build our own encryption and security protocol. And we succeeded!
What we did, how we did it and what we’ve got finally - this is what my speech about.
электронные средства поддержания трудовой дисциплины в географически распреде...Daniel Podolsky
Компания GitInSky, также известная как ООО "Жить в небе", действует на рынке, который мы назовем "аутсорсинг системного администрирования", более трех лет.
С одной стороны — не много. С другой — статистика жизненного цикла стартапов говорит нам, что пора слегка отвлечься от штурма и натиска, и поглядеть, что же у нас получается.
Удачно, что отвлекаться и глядеть входит в мои служебные обязанности как технического директора.
Я посвятил анализу сложившихся в компании практик, их результатов и перспектив довольно много времени в начале 2017 года. Человеко-месяц, в общей сложности, если не больше. В основном размышлениям над вопросом, который, я уверен, регулярно задает себе руководитель любого звена: "Почему я так много работаю, а результат такой скромный?". Ответ, кстати, прост и неприятен: "Потому, что я не работаю, а трачу время".
Но доклад мой не об этом. Доклад мой о том, что я раскопал в результате анализа оных практик применительно к такому явлению как "трудовая дисциплина" и техническим средствам ее поддержания.
Итак, я намерен рассказать:
* Что такое "трудовая дисциплина". Это, забегая вперед, совсем не "приходить на работу вовремя". Ну, или именно "приходить на работу вовремя", если правильно понимать это "вовремя".
* Что такое трудовая дисциплина в команде "удаленщиков". Надо сказать, что все это время мы набираем инженеров исключительно на "удаленку", и успешно — по большей части успешно — справляемся решать такой командой довольно сложные и интересные задачи.
* Почему на удаленке не работают традиционные средства поддержания дисциплины: личная харизма руководителя, бамбуковая палка, наручники и батарея.
* Какие формы принимает в такой ситуации традиционный процесс, и насколько эти формы уродливы.
* Подбираясь к теме доклада — как развивались наши представления о дисциплине, и какие средства мы пытались использовать на разных этапах становления компании.
* Наконец, к чему мы пришли. Что именно внедрено сейчас, как оно повлияло на наш доморощенный процесс. Что думают об этом менеджеры, и что говорят инженеры.
* Самое важное — для меня, уж точно: где провисает, и что мы собираемся с этим делать.
Golang в действии: Как нам удается писать highload приложение на (не?)подходя...Daniel Podolsky
Последние 2 года язык Go является моим - нашим - основным средством заработка на хлеб. Хватает, в общем-то, и на хлеб, и на масло, а иногда и на красную икру.
Не покривив душой, я могу сказать, что мы относимся к языку Go и его создателям с симпатией и уважением.
Однако, при всем нашем уважении, заявить, что Go предназначен для "тяжелых" проектов, я, не покривив душой, не могу.
Во-первых, Go молодой язык, для которого еще не известны паттерны и - что важнее - антипаттерны. Тем, кто пишет на Go тяжелое приложение сегодня, приходится тратить существенное время на тесты и оптимизации
Во-вторых, выразительные средства Go довольно скудны, что приводит к появлению в коде ужасающего количества boilerplate, за которым эффективно прячется бизнес-логика. Программу на Go бывает трудно охватить взглядом и поместить ее модель себе в голову просто из-за количества строк, которые надо для этого прочесть.
В-третьих, у Go есть проблемы с эффективностью кода. У Go плохой оптимизатор. У Go плохо с "заточкой" под железо - вспомним хотя бы историю с патчем CloudFlare для TLS. Патч ведь так и не попал в основную ветку...
Возникает вопрос - почему же, не по наслышке зная о вышеперечисленных проблемах, мы пишем наш реально тяжелый проект именно на Go?
Ответ прост: Go не идеален, но под наши задачи он подходит лучше всего.
Раньше мы строили разные тяжелые бекенды на perl, python, java, groovy и даже lua+nginx. Нам есть, с чем сравнивать.
Во-первых, Go достаточно быстр. Во всяком случае, он быстрее perl и python на нашем профиле нагрузки.
Во-вторых, и это важнее, Go предоставляет вполне достаточные средства контроля за потреблением как RAM, так и CPU. Например, регулярные выражения Go не такие гибкие, как pcre, и, по моим наблюдениям, медленнее, чем pcre. Но! регулярные выражения в Go всегда отрабатывают за предсказуемое время!
В-третьих, создатели языка не врут нам - они, действительно, постарались сделать язык, на котором человекочитаемую программу написать проще, чем нечитаемую. И у них - с некоторомы оговорками - получилось! Даже пресловутый boilerplate не способен этому помешать.
Наконец, Go просто сумел нам понравиться, чего уже давно не случалось с языками программирования.
Итак, на основании опыта, полученного при создании пилотной версии проекта inCaller.org я расскажу о том, как мы писали на Go тяжелое приложение.
Миллионы одновременных персистентных websocket соединений, десятки тысяч коннектов по ssl в секунду, сотни тысяч в секунду обновлений записей в БД.
Я расскажу об антипаттернах, нами обнаруженных, о методике тестирования производительности, анализа проблем и способах с проблемами справиться.
Доклад рассчитан на backend-программистов, как на языке Go, так и на других.
сравнение производительности СУБД MySQL и PostgreSQL для "типичной задачи стартапа".
Презентация сопровождала тестовую online-сессию и потому не содержит результатов тестирования.
RTB и его проблематика должны быть знакомы участникам конференции - мало кто сегодня не слышал об этом способе получить много krps с жесткими ограничениями на время генерации ответа.
Вот и компания Qmobi решила поучаствовать в этой гонке и отхватить свой кусок пирога под названием “рынок мобильной рекламы”.
При первом подходе к снаряду задача выглядит довольно простой: вот запрос с критериями, вот база данных с ответами - выбирай по индексу и отвечай.
На самом деле все несколько сложнее. Начать с того, что некоторые критерии отбора - негативные. Затем мы имеем дело с выборкой по десятку индексов, каждый из которых обладает низкой cardinality. И, наконец, мы имеем дело с большими объемами: около 10М строк в исходных данных, около 10К строк в финальной выборке. Ах, нет, еще финальная выборка должна быть отсортирована по приоритету! И надо не забыть про атомарные блокировку и списание средств...
От идеи прототипа на perl пришлось отказаться еще на этапе постановки задачи :)
Итак, мы имеем задачу с интенсивным IO, высокой нагрузкой, высокими скоростями, сложными структурами данных и эвристическими алгоритмами.
Анализ имеющихся вариантов показал, что Go должен прекрасно подойти для этой задачи. О том, на основании каких соображений мы сделали такой вывод, и какие из этих соображений прошли проверку практикой, а какие - нет, будет рассказано в докладе.
Также в докладе будет рассказано о том, как сортировка была заменена случайной выборкой, и чем пришлось заплатить за то, чтобы эта замена оказалась равноценной.
Будет показано, почему мы наплевательски отнеслись к гипотетической потере 20% возможностей поучаствовать в аукционе, и почему реальный процент потерь много ниже.
Будет раскрыта роль СУБД MySQL в этом проекте, со всем блеском высокой производительности и нищетой отказоустойчивости.
Вопросы геотаргетинга, использования PostGIS и кэширования результатов поиска региона по координатам будут затронуты вскользь, как неоднократно обсуждавшиеся на этой и подобных конференциях.
А вот анатомия производительности приложения на Go будет рассмотрена подробнейшим образом - с графиками и числами.
Также подробно будут рассмотрены наши победы и поражения в борьбе со статис
ночью через лес Stress-test пяти almost-the-same-functionality shared-nothin...Daniel Podolsky
1. "Mia! MIA! What the hell happened?", или что случается с производительностью вашей РСУБД, когда ее индексы перестают помещаться в память
2. "Why the fuck didn't you tell us about that guy in the bathroom?", или почему мы гадим под себя, когда речь заходит о шардинге РСУБД
3. "Now the night of the fight, you may fell a slight sting, that's pride fuckin' wit ya. Fuck pride! ", или почему shared nothing
4. "And that's what we're gonna be, we're gonna be cool.", или с какими проблемами сталкиваются люди, которые собрались эксплуатировать shared-nothing cluster
5. "Mind if I try one of yours?", или наша методика тестирования
6. “The truth. Three well-dressed, slightly toasted, Mexicans.”, или отбор кандидатов на тестирование
7. "So you're gonna go out there, drink your drink, say "Goodnight, I've had a very lovely evening," go home, and jack off.", или краткий отчет о безумной неделе
8. "This sensual thing's goin' on that nobody's talkin about, but you know it and she knows it, fuckin' Marsellus knew it, and Antwan shoulda known fuckin' better.", или выводы
Бинарные (файловые) хранилища- страшная сказка с мрачным концомDaniel Podolsky
1. Вводная часть: базовые понятия и определения
1.1. Что такое “файл”
1.2. Роль файлов в современном мире, миф о ненужности файлов
1.3. Файловое хранилище АКА файловая система
1.3.1. внутреннее устройство
1.3.1.1. винтажные и журналируемые. зачем нужен журнал
1.3.1.2. плоские и иерархические
1.3.1.3. контроль доступа
1.3.2. POSIX
1.3.2.1. произвольное чтение
1.3.2.2. произвольная запись
1.3.2.3. атомарные операции
1.3.3. bells and whistles
1.3.3.1. сжатие, шифрование, дедупликация
1.3.3.2. snapshots
1.4. кеширование чтения и записи
2. HighLoad - это сеть
2.1. что вообще такое “HighLoad”, или “ведет ли кроилово к попадалову”
2.2. протоколы доступа: stateless и stateful
2.3. отказоустойчивость и ее двуличие
2.3.1. целостность данных
2.3.2. бесперебойные запись и чтение
2.4. Теорема CAP
3. Так в чем проблема?
3.1. Берем большую-пребольшую СХД и…
3.1.1. локальный кеш?!
3.1.2. конкурентная запись?!!
3.1.3. Берем OCFS2 и…
3.1.3.1. Как “падают виртуалки”?!
3.1.3.2. И почему так медленно?
3.1.4. А еще большую-пребольшую СХД довольно трудно получить в свое распоряжение
3.2. Берем CEPH/Lustre/LeoFS и…
3.2.1. Почему так медленно?!
3.2.2. Что значит “ребалансинг”?!
3.3. И немного о резервном копировании
3.3.1. Резервное копирование - это не отказоустойчивость
3.4. И снова про атомарные операции
3.5. Так почему все-таки нельзя просто сложить файлы в базу?
4. Что же делать?
4.1. В первую очередь это зависит от того, какова наша задача
4.1.1. А надо ли экономить?
4.1.2. POSIX - нужен ли он?
4.1.3. Большие файлы - нужны ли они?
4.1.4. Атомарные операции - нужны ли они?
4.1.5. Версионирование - нужно ли версионирование?
4.1.6. Насколько большим должно быть наше хранилище?
4.1.7. И собираемся ли мы удалять файлы?
4.1.8. И каков будет профиль нагрузки?
4.2. I’m feeling lucky - для некоторых сочетаний требований решение есть!
4.3. А для остальных - решения нет.
5. Так что же все-таки делать? (заключение)
5.1. искать бюджет
5.2. все-таки сложить все файлы в базу - личное мнение докладчика
5.3. написать свое
5.3.1. не так это и сложно!
5.3.2. но все же довольно сложно
5. Немного о докладе
● Фактически - обзорный
● Цель - продемонстрировать отличия
от “традиционных” AKA
реляционных СУБД
6. Немного о докладе
● Фактически - обзорный
● Цель - продемонстрировать отличия
от “традиционных” AKA
реляционных СУБД
● Чтобы дать представление о круге
задач, для которых Cassandra
подходит хорошо
7. Немного о докладе
● Фактически - обзорный
● Цель - продемонстрировать отличия
от “традиционных” AKA
реляционных СУБД
● Чтобы дать представление о круге
задач, для которых Cassandra
подходит хорошо
○ Спойлер: этот круг довольно узок
15. Cassandra, как она есть
● NoSQL DBMS
○ схема данных и язык CQL
● Отказоустойчивая
16. Cassandra, как она есть
● NoSQL DBMS
○ схема данных и язык CQL
● Отказоустойчивая
● Распределенная
17. Cassandra, как она есть
● NoSQL DBMS
○ схема данных и язык CQL
● Отказоустойчивая
● Распределенная
● Быстрая
18. Cassandra, как она есть
● NoSQL DBMS
○ схема данных и язык CQL
● Отказоустойчивая
● Распределенная
● Быстрая
● Eventually consistent
19. Cassandra, как она есть
● NoSQL DBMS
○ схема данных и язык CQL
● Отказоустойчивая
● Распределенная
● Быстрая
● Eventually consistent
○ Time based, со всеми вытекающими
21. В сравнении с RDBMS
Отсутствуют
● Relations (foreign keys, joins, etc)
22. В сравнении с RDBMS
Отсутствуют
● Relations (foreign keys, joins, etc)
● Транзакции
23. В сравнении с RDBMS
Отсутствуют
● Relations (foreign keys, joins, etc)
● Транзакции
○ есть в рамках одной строки
24. В сравнении с RDBMS
Отсутствуют
● Relations (foreign keys, joins, etc)
● Транзакции
○ есть в рамках одной строки
● Вторичные индексы
25. В сравнении с RDBMS
Отсутствуют
● Relations (foreign keys, joins, etc)
● Транзакции
○ есть в рамках одной строки
● Вторичные индексы
○ Они есть
26. В сравнении с RDBMS
Отсутствуют
● Relations (foreign keys, joins, etc)
● Транзакции
○ есть в рамках одной строки
● Вторичные индексы
○ Они есть
○ Но работают иначе
30. Скорость
● Кассандра быстро пишет
○ И расходует при этом много iops
● Cassandra читает как-то
○ Никаких гарантий
31. Скорость
● Кассандра быстро пишет
○ И расходует при этом много iops
● Cassandra читает как-то
○ Никаких гарантий
○ Но обычно - быстро
32. Скорость
● Кассандра быстро пишет
○ И расходует при этом много iops
● Cassandra читает как-то
○ Никаких гарантий
○ Но обычно - быстро
■ Если не перегружена
40. Об архитектуре хранения данных
● PRIMARY KEY
○ Обязателен
○ Уникален
○ Определяет шард
■ Который определяет сервер, на
котором хранятся данные
41. Об архитектуре хранения данных
● PRIMARY KEY
○ Обязателен
○ Уникален
○ Определяет шард
■ Который определяет сервер, на
котором хранятся данные
○ Двухчастный
45. Об архитектуре хранения данных
● Двухчастный PRIMARY KEY
○ Partition Key
○ Clustering Key
● Ключевой фактор, влияющий на
производительность
46. Об архитектуре хранения данных
● Двухчастный PRIMARY KEY
○ Partition Key
○ Clustering Key
● Ключевой фактор, влияющий на
производительность
○ Трудно понять, как правильно
47. Об архитектуре хранения данных
● Двухчастный PRIMARY KEY
○ Partition Key
○ Clustering Key
● Ключевой фактор, влияющий на
производительность
○ Трудно понять, как правильно
○ Невозможно поменять
51. О вторичных ключах
● Чисто маркетинговая фишка
○ Не нужны
● Работают плохо
● Запрос по вторичному ключу
достает данные со всех нод
кластера
52. О вторичных ключах
● Чисто маркетинговая фишка
○ Не нужны
● Работают плохо
● Запрос по вторичному ключу
достает данные со всех нод
кластера
○ Производительность падает при
расширении кластера
53. Еще о первичном ключе
● UPDATE для колонок, в него
включенных, невозможен
54. Еще о первичном ключе
● UPDATE для колонок, в него
включенных, невозможен
○ Потому, что первичный ключ
определяет физическое
расположение данных
55. Еще о первичном ключе
● UPDATE для колонок, в него
включенных, невозможен
○ Потому, что первичный ключ
определяет физическое
расположение данных
○ А DELETE-INSERT нельзя
сделать транзакционным в
распределенной системе
58. Отказоустойчивость
● Ключевой фактор - replication factor
○ Определяет, сколько полных
копий всех данных вы храните
○ При значениях меньше 3 не
обеспечивает отказоустойчивости
59. Отказоустойчивость
● Ключевой фактор - replication factor
○ Определяет, сколько полных
копий всех данных вы храните
○ При значениях меньше 3 не
обеспечивает отказоустойчивости
● Выбор ноды реализован на клиенте
60. Отказоустойчивость
● Ключевой фактор - replication factor
○ Определяет, сколько полных
копий всех данных вы храните
○ При значениях меньше 3 не
обеспечивает отказоустойчивости
● Выбор ноды реализован на клиенте
● Rebalancing может быть болью
61. Отказоустойчивость
● Ключевой фактор - replication factor
○ Определяет, сколько полных
копий всех данных вы храните
○ При значениях меньше 3 не
обеспечивает отказоустойчивости
● Выбор ноды реализован на клиенте
● Rebalancing может быть болью
○ и унижением
64. Memory mapped files
● Штатный способ доступа к данным
со стороны cassandra
● Но:
○ Невидимы для iostat
65. Memory mapped files
● Штатный способ доступа к данным
со стороны cassandra
● Но:
○ Невидимы для iostat
○ Неэффективно используют кеш
66. Memory mapped files
● Штатный способ доступа к данным
со стороны cassandra
● Но:
○ Невидимы для iostat
○ Неэффективно используют кеш
■ Личные наблюдения
67. Memory mapped files
● Штатный способ доступа к данным
со стороны cassandra
● Но:
○ Невидимы для iostat
○ Неэффективно используют кеш
■ Личные наблюдения
● Должно сильно зависеть
от данных
69. ScyllaDB
● Disclaimer: чистая теория
● Scylla is a drop-in Apache Cassandra
replacement that powers your
applications with ultra-low latency and
extreme throughput.
70. ScyllaDB
● Disclaimer: чистая теория
● Scylla is a drop-in Apache Cassandra
replacement that powers your
applications with ultra-low latency and
extreme throughput.
● http://www.scylladb.com/
72. ScyllaDB: о совместимости
● Scylla is compatible with Apache
Cassandra, version 2.1.8
● Самая важная страница
73. ScyllaDB: о совместимости
● Scylla is compatible with Apache
Cassandra, version 2.1.8
● Самая важная страница
○ http://docs.scylladb.com/cassandra-
compatibility/