Hacking PostgreSQL. Лекция 1. Вводная лекция для начинающих разработчиков ядра PostgreSQL. Видео и площадка для обсуждения в блоге http://postgres-edu.blogspot.ru/2016/02/20160225.html
Сага о кластере. Все что вы хотели знать про горизонтальное масштабирование в...Ontico
Популярность постгреса в мире и России растет, с каждым новым релизом появляется все новая и новая функциональность, постгрес становится реальной угрозой монополии Оракл, уже подвинул Монго на поле свободных NoSQL СУБД, однако мировое сообщество ждет решения для горизонтального масштабирования. Создание постгресового кластера является крайне трудной задачей, так как постгрес является базой данных, ориентированной на целостность данных, а используемый алгоритм обеспечения конкурентности транзакций ставит серьезные челленджи перед разработчиками алгоритмов распределенных транзакций.
Оказывается, уже целых пять групп работает над этой задачей, и мы расскажем про их подходы, трудности, в том числе, и политические. Отдельно остановимся на российском опыте и нашем вкладе в решение этой задачи.
Hacking PostgreSQL. Лекция 1. Вводная лекция для начинающих разработчиков ядра PostgreSQL. Видео и площадка для обсуждения в блоге http://postgres-edu.blogspot.ru/2016/02/20160225.html
Сага о кластере. Все что вы хотели знать про горизонтальное масштабирование в...Ontico
Популярность постгреса в мире и России растет, с каждым новым релизом появляется все новая и новая функциональность, постгрес становится реальной угрозой монополии Оракл, уже подвинул Монго на поле свободных NoSQL СУБД, однако мировое сообщество ждет решения для горизонтального масштабирования. Создание постгресового кластера является крайне трудной задачей, так как постгрес является базой данных, ориентированной на целостность данных, а используемый алгоритм обеспечения конкурентности транзакций ставит серьезные челленджи перед разработчиками алгоритмов распределенных транзакций.
Оказывается, уже целых пять групп работает над этой задачей, и мы расскажем про их подходы, трудности, в том числе, и политические. Отдельно остановимся на российском опыте и нашем вкладе в решение этой задачи.
Разработка real-time приложений с RethinkDB / Илья Вербицкий (Независимый кон...Ontico
RethinkDB - это распределенное документо-ориентированное хранилище данных с открытым исходным кодом. Данная система ориентирована на разработку систем обработки данных реального времени, позволяя клиентскому приложению подписываться на изменение тех или иных данных.
В данном докладе я бы хотел осветить не только вопросы разработки приложений на базе RethinkDB, но и поговорить о том, как все это работает. Мы поговорим о ReQL (язык запросов), “changefeeds”, индексах, шардинге, репликациях, а также затронем вопросы особенностей проектирования баз данных под данную платформу.
Антон Щербаков, Отказоустойчивость на примере aviasales — почему даже если на...Tanya Denisyuk
В докладе на примере системы метапоиска aviasales будет рассмотрен переход от монолитной архитектуры RoR приложения к многозвенной системе внутренней разработки на базе tornado/python в целях ослабления зависимостей между подсистемами, упрощения контроля за потоком данных и изоляции потенциальных аварийных ситуаций.
Будут рассмотрены побочные эффекты этого перехода, такие как устойчивость к пиковым нагрузкам, упрощение схемы выкатки обновлений и сокращение потребляемых машинных ресурсов.
Выступление на Pgconf Москва 2015. История развития сервиса МойСклад, статистика эксплуатации, особенности внутренней реализации работы с СУБД PostgreSQL.
Обзор перспективных баз данных для highload / Юрий НасретдиновOntico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 5 июня, 10:00
Тезисы:
http://backendconf.ru/2017/abstracts/2773.html
В этом докладе я рассмотрю несколько перспективных, на мой взгляд, баз данных, которые пока еще не очень популярны, но которые определенно ждет успех в будущем, особенно для highload-проектов. Я расскажу о Tarantool, ClickHouse и CockroachDB, о том, как они устроены, и почему я считаю, что они в будущем станут стандартом де-факто, как раньше был MySQL, а сейчас — MongoDB.
...
«Дорожная сеть в графовой базе данных Neo4j» — Вадим Шашенко, 2ГИС2ГИС Технологии
В своем докладе я расскажу, почему мы выбрали графовую базу данных Neo4j для проверки дорожного графа городов России (все населенные пункты с населением больше 300 000 жителей). Основные задачи, которые мы решаем средствами Neo4j — это проверки на связность и доступность проезда.
Опорные пункты доклада:
— SQL против графовых баз данных;
— обзор графовой базы данных neo4j;
— архитектура решения, в котором используется графовая БД;
— выполнение алгоритмов на графе в условиях его частых изменений.
В основе доклада лежат результаты работы над проектом «Fiji». Это внутрикорпоративная система, которая позволяет штатным картографам 2ГИС создавать, хранить и экспортировать карту во внешние продукты: онлайн-, десктоп- и мобильную версии 2ГИС.
Михаил Табунов, Аналитическая платформа на несколько миллиардов событий в месяцTanya Denisyuk
Доклад про:
– развитие архитектуры этой системы, как менялись и как будут меняться требования к такого рода системам
– анализ подходящих под эту систему БД, с их проблемами, и опытом реальной эксплуатации
– почему мы остановились на MongoDB, со всеми минусами и плюсами
– немного про команду, трудозатраты и поддержку
– как мы используем эту систему и как она помогает растить наши продукты
Простая и дешёвая бизнес-аналитика на базе Google BigQuery / Алексей Паршуков...Ontico
РИТ++ 2017, Backend Conf
Зал Сан-Паулу, 6 июня, 14:00
Тезисы:
http://backendconf.ru/2017/abstracts/2778.html
Хотите научиться принимать решения на основе данных, но не знаете, с чего начать? Нужно записать миллионы событий, но не уверены, как делать это правильно? Вы не знаете, как быстро и дёшево строить аналитические отчеты или запутались в инструментах?
На примере DocDoc я расскажу о плюсах и минусах различных подходов: как выбрать систему хранения, почему мы остановились на Google BigQuery. Как правильно организовать данные, записать свой clickstream, отказаться от сэмплирования в GA, а также строить простые и понятные отчеты.
мониторинг производительности Web приложений на pythonSlach
как понять где тормозит твое приложение в реальном времени? как не потеряться в океане метрик и собрать на дашборде только нужные? видео https://youtu.be/JgezdgtoNG8
Разработка real-time приложений с RethinkDB / Илья Вербицкий (Независимый кон...Ontico
RethinkDB - это распределенное документо-ориентированное хранилище данных с открытым исходным кодом. Данная система ориентирована на разработку систем обработки данных реального времени, позволяя клиентскому приложению подписываться на изменение тех или иных данных.
В данном докладе я бы хотел осветить не только вопросы разработки приложений на базе RethinkDB, но и поговорить о том, как все это работает. Мы поговорим о ReQL (язык запросов), “changefeeds”, индексах, шардинге, репликациях, а также затронем вопросы особенностей проектирования баз данных под данную платформу.
Антон Щербаков, Отказоустойчивость на примере aviasales — почему даже если на...Tanya Denisyuk
В докладе на примере системы метапоиска aviasales будет рассмотрен переход от монолитной архитектуры RoR приложения к многозвенной системе внутренней разработки на базе tornado/python в целях ослабления зависимостей между подсистемами, упрощения контроля за потоком данных и изоляции потенциальных аварийных ситуаций.
Будут рассмотрены побочные эффекты этого перехода, такие как устойчивость к пиковым нагрузкам, упрощение схемы выкатки обновлений и сокращение потребляемых машинных ресурсов.
Выступление на Pgconf Москва 2015. История развития сервиса МойСклад, статистика эксплуатации, особенности внутренней реализации работы с СУБД PostgreSQL.
Обзор перспективных баз данных для highload / Юрий НасретдиновOntico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 5 июня, 10:00
Тезисы:
http://backendconf.ru/2017/abstracts/2773.html
В этом докладе я рассмотрю несколько перспективных, на мой взгляд, баз данных, которые пока еще не очень популярны, но которые определенно ждет успех в будущем, особенно для highload-проектов. Я расскажу о Tarantool, ClickHouse и CockroachDB, о том, как они устроены, и почему я считаю, что они в будущем станут стандартом де-факто, как раньше был MySQL, а сейчас — MongoDB.
...
«Дорожная сеть в графовой базе данных Neo4j» — Вадим Шашенко, 2ГИС2ГИС Технологии
В своем докладе я расскажу, почему мы выбрали графовую базу данных Neo4j для проверки дорожного графа городов России (все населенные пункты с населением больше 300 000 жителей). Основные задачи, которые мы решаем средствами Neo4j — это проверки на связность и доступность проезда.
Опорные пункты доклада:
— SQL против графовых баз данных;
— обзор графовой базы данных neo4j;
— архитектура решения, в котором используется графовая БД;
— выполнение алгоритмов на графе в условиях его частых изменений.
В основе доклада лежат результаты работы над проектом «Fiji». Это внутрикорпоративная система, которая позволяет штатным картографам 2ГИС создавать, хранить и экспортировать карту во внешние продукты: онлайн-, десктоп- и мобильную версии 2ГИС.
Михаил Табунов, Аналитическая платформа на несколько миллиардов событий в месяцTanya Denisyuk
Доклад про:
– развитие архитектуры этой системы, как менялись и как будут меняться требования к такого рода системам
– анализ подходящих под эту систему БД, с их проблемами, и опытом реальной эксплуатации
– почему мы остановились на MongoDB, со всеми минусами и плюсами
– немного про команду, трудозатраты и поддержку
– как мы используем эту систему и как она помогает растить наши продукты
Простая и дешёвая бизнес-аналитика на базе Google BigQuery / Алексей Паршуков...Ontico
РИТ++ 2017, Backend Conf
Зал Сан-Паулу, 6 июня, 14:00
Тезисы:
http://backendconf.ru/2017/abstracts/2778.html
Хотите научиться принимать решения на основе данных, но не знаете, с чего начать? Нужно записать миллионы событий, но не уверены, как делать это правильно? Вы не знаете, как быстро и дёшево строить аналитические отчеты или запутались в инструментах?
На примере DocDoc я расскажу о плюсах и минусах различных подходов: как выбрать систему хранения, почему мы остановились на Google BigQuery. Как правильно организовать данные, записать свой clickstream, отказаться от сэмплирования в GA, а также строить простые и понятные отчеты.
мониторинг производительности Web приложений на pythonSlach
как понять где тормозит твое приложение в реальном времени? как не потеряться в океане метрик и собрать на дашборде только нужные? видео https://youtu.be/JgezdgtoNG8
Разработка API для большого, нагруженного сервисаendeveit
Рассказ о том, что творилось с проектами kolesa.kz и krisha.kz в 2011-2012 годах и что происходит сейчас, как мы создавали с нуля API и впоследствии переезжали на него, как на лету меняли хранилища данных, как боролись с нагрузками и воевали за надежность, расскажу о граблях на которые наступили и как их можно было бы избежать.
Последние новости постгреса с PGCon / О.Бартунов, А.Коротков, Ф.Сигаев (Postg...Ontico
Как быстро развивается сейчас PostgreSQL — общеизвестно. За несколько дней до РИТ++ заканчивается главный мировой форум разработчиков этой СУБД — конференция PGCon в Канаде. Большая команда разработчиков Postgres Professional принимает участие в этой конференции и готова рассказать все последние новости прямо с PGCon.
Параллельное исполнение запросов, новые стораджи, неутихающая тема Postgres vs key-value storage, распределенный Postgres, высокая доступность, многочисленные улучшения производительности, планы и интриги разработчиков — вот основные темы этой конференции.
Я остановлюсь подробнее на нашем вкладе в ожидаемый релиз 9.6 и планах на, возможно, релиз 10.0.
BigMemory - работа с сотнями миллионов бизнес-объектов / Дмитрий Хмаладзе (Ag...Ontico
РИТ++ 2017, HighLoad Junior
Зал Сингапур, 5 июня, 11:00
Тезисы:
http://junior.highload.ru/2017/abstracts/2683.html
Наш доклад описывает способ использования больших объемов памяти, которые стали доступны в последние годы. К сожалению, эта память обычно остается незадействованной в управляемых средах исполнения в связи с принудительной сборкой мусора. Разработчики прибегают к внешним хранилищам данных ( i.e Memcached), что несет дополнительные расходы.
...
PG Day'14 Russia, PostgreSQL в avito.ru, Михаил Тюринpgdayrussia
Доклад был представлен на официальной российской конференции PG Day'14 Russia, посвященной вопросам разработки и эксплуатации PostgreSQL.
С момента старта проекта на PostgreSQL были возложены серьёзные задачи. Это во многом предопределило успешное развитие всего продукта. Вокруг СУБД выстроены основные компоненты архитектуры, при этом сами базы берут на себя львиную долю обработки пользовательских запросов. Набор фич и расширений, легендарная надёжность PostgreSQL, наличие встроенной репликации, средств резервирования и архивирования — весь потенциал нашел своё воплощение, а наличие открытого профессионального комьюнити не оставляет шансов к неэффективной реализации.
В докладе будет дан обзор развития подсистем, сосредоточенных вокруг PostgreSQL, представлены параметры и режимы функционирования. Будут описаны успешные решения в рамках отдельного PostgreSQL-кластера и при распределенной обработке данных, приведены текущие вызовы, связанные с продолжающимся активным ростом проекта.
Применение фреймворка GStreamer в системе видеонаблюденияcorehard_by
Я хочу рассказать о фреймворке GStreamer, который предназначен для обработки аудио/видеоданных. А также для чего мы его использовали в одном из наших проектов.
Эксперименты с Postgres в Docker и облаках — оптимизация настроек и схемы ва...Nikolay Samokhvalov
Администрирование баз данных в будущем будет полностью автоматизировано. Это уже так для базовых операций DBA: поднятие инстансов, бэкапы, управление репликацией, failover — мы наблюдаем это по бурному развитию облачных «управляемых» СУБД (AWS RDS, Google Cloud SQL и десятков игроков поменьше), работе над k8s-оператором для Postgres и MySQL в ряде компаний, внедрению внутренних RDS-like DBaaS (database-as-a-service) решений внутри крупных организаций.
Но диагностика и оптимизация производительности баз данных сегодня всё ещё очень «ручные». Например, в Postgres: находим медленную группу запросов в pg_stat_statements, ищем конкретный пример (а то и «выдумываем» его на ходу), пробуем EXPLAIN ANALYZE сначала в dev/staging-окружении, где, как правило, данных не так много, а потом на prod'е... Подбираем индекс, убеждаемся, что он ускоряет (вроде бы) один SQL-запрос и — всё, отправляем в production. Метод «чик-чик и в production» должен остаться в прошлом! Как остались в прошлом развёртывание и настройка серверов и сервисов вручную.
Nancy CLI (https://github.com/postgres-ai/nancy) – открытый фреймворк для проведения экспериментов над базами данных PostgreSQL, позволяющий любому инженеру наладить системный подход к анализу и оптимизации производительности БД. Nancy поддерживает проведение экспериментов локально (на любом сервере) и удалённо на дешёвых высокопроизводительных спот-инстансах AWS EC2.
Без каких-либо специальных знаний, используя Nancy CLI, любой инженер может теперь:
- собрать подробную информацию о поведении «SQL-запросов с прода» на «клоне прода», но «не трогая прод» с целью выявления узких мест (на «проде» под нагрузкой включать обширную диагностику неразумно, а иногда и невозможно);
- проверить, как тот или иной индекс влияет на производительность SQL (в том числе, насколько он замедлит UPDATE'ы);
- подобрать оптимальные параметры настройки Postgres'а (пример: запустить в облаке проверку 100 вариантов default_statistics_target с подробным исследованием эффекта и анализом для каждой группы SQL-запросов);
- сравнить 2+ прогонов моделированной нагрузки на клоне реальной БД в различных условиях (разное оборудование, разные версии Postgres, разные настройки, разные наборы индексов).
В докладе мы также обсудим конкретные примеры внедрения метода автоматизации экспериментов над БД и Nancy CLI в ряд проектов различных компаний (БД до 2ТБ, hybrid workload, до 15k TPS) и трудности, которые пришлось преодолеть на пути:
1. Включение полного логирования запросов: когда это просто страх, а когда это действительно серьёзный стресс для сервера? Как быть, если диски «не тянут» полное логирование?
2. Вопросы безопасности: нужно ли давать доступ к экспериментальным узлам всем разработчикам или можно обойтись без этого? Обфускировать ли данные?
3. Как убедиться, что результаты эксперимента достоверны?
4. Как проводить эксперименты над терабайтной базой данных быстро?
5. Стоит ли включать Nancy в CI/CD-конвейер?
MyBatis и Hibernate на одном проекте. Как подружить?Alexey Zinoviev
Zinoviev Alexey presented this paper on CodeFest 2013, Novosibirsk.
Paper covers next topics: Hibernate, MyBatis, ORM, databases, SQL, JDBC, patterns, XML
Зиновьев Алексей Zinoviev Alexey выступил на Codefest 2013 с данным докладом.
Видео приглашение: http://youtu.be/8KObW8pZ9e0
Видео доклада: http://youtu.be/Tm5rl4ObWBA
1. Перевод новостного приложения
на базу данных PostgreSQL
Meetup в Mail.ru
3 ноября 2015
Дмитрий Кремер
Администратор баз данных
E-mail: d.kremer@rian.ru
jabber: dmitry.kremer@gmail.com
#PostgreSQLRussia
2. МИА «Россия сегодня»
● Ведущее международное новостное агентство с 1941 года (тогда СовИнформБюро)
● Крупнейший поставщик новостного и медиа-контента в Российской Федерации (бренды РИА Новости и
Sputnik News)
● Фотохостинг Олимпиады в Сочи 2014
● Десятки корреспондентов по всей России
● Современные мультимедиа-прессцентры в Москве и Симферополе
● Платформы в социальных сетях
● Производство и распространение фотоконтента,инфографики,контента для мобильных приложений.
Дмитрий Кремер
● Опыт работы с различными базами данных в качестве разработчика и системного администратора с 1999 года.
● Непрерывный опыт работы с БД Oracle c 2007 года
● Oracle Certified Professional 9i,10g
● Начал работать с PostgreSQL в мае 2015 года.
3. Особенности новостного приложения
● Работа в режиме 24/7.Прерывание работы сайтов должна стремиться к нулю.
Прерывание сервисов выпуска допустимо на минуты в периоды минимальной
нагрузки.
● Использование движка (структур данных и кода приложений) собственной разработки,
стандартизация кодовой базы проектов.
● Трёхзвенная архитектура —бизнес-логика на сервере приложений
● Использование преимущестенно свежих данных (partitioning)
● Многоязычность (UTF-8)
● Необходимость использования полнотекстового поиска (Solr,tsearch2 и т. д.)
● Solr —поиск на сайте
● tsearch2 —поиск в редакторском интерфейсе
4. Требования к переводу
● Избежать деградации производительности и отказоустойчивости системы.
● Избежать существенной деградации уровня контроля над системой,мониторинга и
стредств разрешения проблем (troubleshooting).
● По возможности не касаться структуры БД —одно из требований миграции.
● Все изменения должны быть максимально прозрачными для движка приложения.
● Минимизация простоя.
● Предварительная подготовка структуры БД.
● Использование собственных скриптов.
● Миграция данных + накат дэльты
5. Особенности конвертации БД
● Серьезное отличие средств и методик диагностики проблем и мониторинга
● Использование пула соединений pgbouncer в транзакционном режиме
● Необходимость сопоставления типов (различные варианты хранения числовых
значений,дат и т.д.)
● Автоматическая конвертация исключительно структур данных без хранимых объектов.
Использование Ora2Pg для получения первичного варианта структур данных.
● В исходной БД и PostgreSQL данные об объектах в словаре (dictionary и
information_schema + pg_catalog) хранятся в разных регистрах.Dictionary —в верхнем,
information_schema + pg_catalog —в нижнем.Поэтому использование кавычек в
названиях объектов должно быть объектом пристального внимания!!!
6. Производительность системы
● 40+ проектов (баз данных) на одном сервере БД.
● 124 миллиона транзакций в сутки
● 8 тысяч запросов в секунду
● 1200 DML операций в секунду
● 300+ vacuum операций в сутки
● Среднее время запросов 5ms
7. Особенности настройки БД
● Авторизация и аутентификация пользователей
● Настройка autovacuum (согласно презентации Ильи Космодемьянского)
http://www.slideshare.net/PostgreSQL-Consulting/postgresql-meetup-berlin-at-zalando-hq
● Агрессивные настройки в БД
● Понижение приоритета процесса autovacuum в операционной системе
● Настройка streaming replication
● Использование шаблонов базы данных для развёртывания стандартных проектов
● Логи пишутся на syslog-сервер
8. Авторизация и аутентификация пользователей
● Аутентификация пользователей через pgbouncer
● Хеши паролей пользователей хранятся не в БД,а в конфигурационном файле pgbouncer
● Пользователи с привилегиями DDL-операций соединяются с БД только локально из ssh-
сессии или ssh-тунеля (поддерживается EMS SQL Manager for PostgreSQL)
● Пользователь для реплики создаётся исключительно с правами replication без права
login.Это единственный пользователь,который соединяется с БД удалённо минуя
pgbouncer.В pg_hba.conf соединение разрешено только между реплицируемыми нодами
и сервером бэкапа.
● Авторизация пользователей
● Для приложений каждого проекта создаётся свой пользователь с минимальными
привилегиями
● Для пользователей DevOps создана соответствующая роль-владелец объектов без права
login от которой наследуются привилегии для конкретных пользователей
9. Настройка streaming replication
● Симметричная конфигурация
● Отказ от триггерного файла,ручное переключение ролей репликации,безшовный
переход с мастер-сервера на сервер реплики (standby) без смены timeline
● wal_level = hot_standby
wal_keep_segments = 500
hot_standby = on
hot_standby_feedback = on
10. Backup и PITR-сервер
● Доставка wal-логов с использованием демона lsyncd и подсстемы ядра Linux
обработки событий файловой системы inotify.
● После очистки каталога wal-огов на мастере демон lsyncd нужно перезапустить с
проверкой очистки дочерних ssh-процессов,а лучше остановить,почистить,запустить
lsyncd
● Резервное копирование с использованием pg_basebackup с опцией --xLog —создание
бэкапа,готового к восстановлению.
● Полное дублирование компонентов архитектуры
● Использование Point In Time Recovery (PITR) сервера для замены функционала Oracle
Flashback Database (не является аналогом этой технологии)
● Использование pg_switch_xlog() для создания точки восстановления.
13. Мониторинг и производительность
● Использование Zabbix
● За основу взят шаблон https://github.com/lesovsky/zabbix-extensions
● Доработка дискавера БД+таблица
● Использование pg_buffercache и pg_stat_statements
● Выставить параметры в postgresql.conf:
shared_preload_libraries = 'pg_stat_statements'
pg_stat_statements.max = 10000
pg_stat_statements.track = all
● Использование pgBadger (объём логов,ротация)
● pgBadger установлен на syslog-серверах
● Ротация логов каждый час: инкрементальное добавление данных в отчёт,ротация и сжатие часового лога
14. Благодарности:
● Сергею Томулевичу —за помощь в подготовке выступления
● Алексею Лесовскому —за шаблон мониторинга PostgreSQL на Zabbix
● Николаю Самохвалову —за приглашение на мероприятие в качестве спикера.
15. Спасибо за внимание!
Вопросы?
Meetup в Mail.ru
3 ноября 2015
Дмитрий Кремер
Администратор баз данных
E-mail: d.kremer@rian.ru
jabber: dmitry.kremer@gmail.com
#PostgreSQLRussia