Submit Search
Upload
PostgreSQL Moscow Meetup - September 2014 - Ilya Kosmodemyansky
•
1 like
•
2,142 views
Nikolay Samokhvalov
Follow
PostgreSQL 9.4 Performance -- join us at http://Meetup.com/PostgreSQLRussia!
Read less
Read more
Technology
Report
Share
Report
Share
1 of 35
Download now
Download to read offline
Recommended
bie daaltiin jishe
ªãºAãäëèéí ñàíã çîõèîí áàéãóóëàõ
ªãºAãäëèéí ñàíã çîõèîí áàéãóóëàõ
Namkhainyambuu Gan-Erdene
Bash on Railsの逆襲
Bash on Railsの逆襲
emasaka
An overview to impact of critical css in responsive design
Critical Path Rendering - Rwdconf94
Critical Path Rendering - Rwdconf94
Arash Manteghi
http://leontyev.at.ua
Dhtml
Dhtml
StAlKeRoV
Wda t 91_2010
Wda t 91_2010
aaruicwai
WordFes2016年登壇内容です。 slideshareでPDFアップしたら、日本語が表示できず、http://d.hatena.ne.jp/a_bicky/20160516/1463337063この記事を参考にして、もっかいアップしました。アップしても、3回くらい何ページか真っ白でしたが、アップ4回目で成功しました。 今度はslideshare失敗あるあるでもやろうと思います。
WordFes2016登壇資料
WordFes2016登壇資料
wasi300
Cac giai phap_lap_trinh_c___final_[bookbooming.com]
Cac giai phap_lap_trinh_c___final_[bookbooming.com]
bookbooming1
Molinos.web
Molinos.web
Rishat Shigapov
Recommended
bie daaltiin jishe
ªãºAãäëèéí ñàíã çîõèîí áàéãóóëàõ
ªãºAãäëèéí ñàíã çîõèîí áàéãóóëàõ
Namkhainyambuu Gan-Erdene
Bash on Railsの逆襲
Bash on Railsの逆襲
emasaka
An overview to impact of critical css in responsive design
Critical Path Rendering - Rwdconf94
Critical Path Rendering - Rwdconf94
Arash Manteghi
http://leontyev.at.ua
Dhtml
Dhtml
StAlKeRoV
Wda t 91_2010
Wda t 91_2010
aaruicwai
WordFes2016年登壇内容です。 slideshareでPDFアップしたら、日本語が表示できず、http://d.hatena.ne.jp/a_bicky/20160516/1463337063この記事を参考にして、もっかいアップしました。アップしても、3回くらい何ページか真っ白でしたが、アップ4回目で成功しました。 今度はslideshare失敗あるあるでもやろうと思います。
WordFes2016登壇資料
WordFes2016登壇資料
wasi300
Cac giai phap_lap_trinh_c___final_[bookbooming.com]
Cac giai phap_lap_trinh_c___final_[bookbooming.com]
bookbooming1
Molinos.web
Molinos.web
Rishat Shigapov
PostgreSQLRussia community relaunched in Moscow, Russia in form of meetups -- join us at http://Meetup.com/PostgreSQLRussia!
PostgreSQL Moscow Meetup - September 2014 - Nikolay Samokhvalov
PostgreSQL Moscow Meetup - September 2014 - Nikolay Samokhvalov
Nikolay Samokhvalov
PostgreSQL 9.4 changes: JSON, JSONB, GiST, GIN, jsquery. Future development. VODKA -- join us at http://Meetup.com/PostgreSQLRussia!
PostgreSQL Moscow Meetup - September 2014 - Oleg Bartunov and Alexander Korotkov
PostgreSQL Moscow Meetup - September 2014 - Oleg Bartunov and Alexander Korotkov
Nikolay Samokhvalov
More: http://PostgreSQLRussia.org Доклад посвящён резервному хранению СУБД PostgreSQL. Мы поговорим о том, как устроено хранение данных на диске и организован WAL в PostgreSQL, какие есть средства для резервного копирования и восстановления данных. Обсудим, как перестать беспокоиться за свои данные и почему PostgreSQL славится своей надёжностью.
Владимир Бородин: Как спать спокойно - 2015.10.14 PostgreSQLRussia.org meetu...
Владимир Бородин: Как спать спокойно - 2015.10.14 PostgreSQLRussia.org meetu...
Nikolay Samokhvalov
Postgres Vision 2016 Lightning Talk
2016.10.13 PostgreSQL in Russia
2016.10.13 PostgreSQL in Russia
Nikolay Samokhvalov
Тип данных JSONb – это, пожалуй, самая яркая новинка PostgreSQL 9.4, который вышел 18 декабря 2014. Уже немало докладов и статей посвящено этому типу данных, работе с ним и индексации. Но как правило, информация в них перегружена специфичными для PostgreSQL терминами. Запутались в моделях данных? В том, какие индексы могут вам помочь ускорить вашу работу с СУБД? Этот доклад помогает сложить паттерн. Он для тех, кто начал использовать PostgreSQL совсем недавно или только планирует работать с ним. В нём рассказано о месте PostgreSQL в современном мире СУБД, о борьбе различных моделей данных за место под солнцем на этом рынке и то, как это отразилось на развитие Postgres. Помимо прочего, рассказывается о том, какие вообще бывают деревья, как они помогают ускорять базы данных и почему PostgreSQL — просто райский лес для деревьев самого разного типа :) См. также видео: http://postgresmen.ru/meetup/2014-12-23-parallels
2014.12.23 Николай Самохвалов, Ещё раз о JSON(b) в PostgreSQL 9.4
2014.12.23 Николай Самохвалов, Ещё раз о JSON(b) в PostgreSQL 9.4
Nikolay Samokhvalov
Реляционной модели скоро исполнится полвека – это огромный срок для любой технологической индустрии, не говоря уже об ИТ. За прошедшие годы этой модели было брошено немало вызовов, оказавших немалое влияние на развитие реляционных СУБД. В докладе обсуждаются три главных вызова реляционной модели, включая и NoSQL. На основе многолетнего опыта использования PostgreSQL для создания социальных сетей, объединяющих многомиллионные аудитории, наглядно демонстрируется как эта СУБД реагировала на возникающие вызовы. Речь также пойдет о «трех китах» PostgreSQL, которые не дают этой системе превратиться в монстра и позволяют обогащаться функционалом, необходимым для создания современных высоконагруженных проектов. Особое внимание в докладе уделено новым типам данных, JSON и JSONB — их возможностям, способам индексирования, а также разбору имеющихся недостатков.
Три вызова реляционным СУБД и новый PostgreSQL - #PostgreSQLRussia семинар по...
Три вызова реляционным СУБД и новый PostgreSQL - #PostgreSQLRussia семинар по...
Nikolay Samokhvalov
Опыт миграции с Oracle на PostgreSQL в проекте Яндекс.Почта
2014.09.24 история небольшого успеха с PostgreSQL (Yandex)
2014.09.24 история небольшого успеха с PostgreSQL (Yandex)
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-конвейер?
Эксперименты с Postgres в Docker и облаках — оптимизация настроек и схемы ва...
Эксперименты с Postgres в Docker и облаках — оптимизация настроек и схемы ва...
Nikolay Samokhvalov
Shared_buffers = 25% – это много или мало? Или в самый раз? Как понять, подходит ли эта – довольно устаревшая – рекомендация в вашем конкретном случае? Пришло время подойти к вопросу подбора параметров postgresql.conf "по-взрослому". Не с помощью слепых "автотюнеров" или устаревших советов из статей и блогов, а на основе: строго выверенных экспериментов на БД, производимых автоматизированно, в больших количествах и в условиях, максимально приближенных к "боевым", глубокого понимания особенностей работы СУБД и ОС. Используя Nancy CLI (https://gitlab.com/postgres.ai/nancy), мы рассмотрим конкретный пример – пресловутые shared_buffers – в разных ситуациях, в разных проектах и попробуем разобраться, как же подобрать оптимальную настройку для нашей инфраструктуры, БД и нагрузки. https://pgconf.ru/2019/242809
Промышленный подход к тюнингу PostgreSQL: эксперименты над базами данных
Промышленный подход к тюнингу PostgreSQL: эксперименты над базами данных
Nikolay Samokhvalov
Future database administration will be highly automated. Until then, we still live in a world where extensive manual interactions are required from a skilled DBA. This will change soon as more "autonomous databases" reach maturity and enter the production environment. Postgres-specific monitoring tools and systems continue to improve, detecting and analyzing performance issues and bottlenecks in production databases. However, while these tools can detect current issues, they require highly-experienced DBAs to analyze and recommend mitigations. In this session, the speaker will present the initial results of the POSTGRES.AI project – Nancy CLI, a unified way to manage automated database experiments. Nancy CLI is an automated database management framework based on well-known open-source projects and incorporating major open-source tools and Postgres modules: pgBadger, pg_stat_kcache, auto_explain, pgreplay, and others. Originally developed with the goal to simulate various SQL query use cases in various environments and collect data to train ML models, Nancy CLI turned out to be very a universal framework that can play a crucial role in CI/CD pipelines in any company. Using Nancy CLI, casual DBAs and any engineers can easily conduct automated experiments today, either on AWS EC2 Spot instances or on any other servers. All you need is to tell Nancy which database to use, specify workload (synthetic or "real", generated based on the Postgres logs), and what you want to test – say, check how a new index will affect all most expensive query groups from pg_stat_statements, or compare various values of "default_statistics_target". All the collected information with a very high level of confidence will give you understanding, how various queries and overall Postgres performance will be affected when you apply this change to production.
The Art of Database Experiments – PostgresConf Silicon Valley 2018 / San Jose
The Art of Database Experiments – PostgresConf Silicon Valley 2018 / San Jose
Nikolay Samokhvalov
Nancy CLI, a unified way to manage automated database experiments. Nancy CLI is an automated database management framework based on well-known open-source projects and incorporating major open-source tools. Using these tools, casual DBAs can conduct automated experiments today, either on AWS EC2 Spot instances or on any other servers. All you need is to tell Nancy which database to use, how to determine workloads and what you want to verify – say, check how some index will help, or compare various values of "default_statistics_target" for your database and your workload. Everything else Nancy will do for you, in fully automated fashion, in the end presenting you detailed results for comparison.
Nancy CLI. Automated Database Experiments
Nancy CLI. Automated Database Experiments
Nikolay Samokhvalov
Онлайн-опросы неизменно показывают — всех нас очень интересуют две вещи: а) как писать наиболее эффективные SQL-запросы, б) как «читать» такие запросы, а точнее, как понимать, что именно делает или будет делать СУБД при их выполнении. Эти две неразрывно связанные друг с другом темы чрезвычайно обширны, SQL-искусству можно (и нужно) учиться годами. Во время нашей очередной встречи в прямом эфире мы затронем некоторые аспекты обеих. ЧАСТЬ 1: EXPLAIN Алексей Ермаков. Как читать и интерпретировать вывод команды EXPLAIN Команда EXPLAIN — основной инструмент анализа запросов, позволяющий разобраться, каким образом запрос будет выполняться и как можно его ускорить. Для сложных запросов вывод может быть довольно громоздким и его становится сложно читать. Я расскажу, из каких частей состоит план запроса, на какие «маркеры» в нём следует обращать внимание в первую очередь и как на это реагировать. ЧАСТЬ 2: ADVANCED SQL Николай Самохвалов. SQL современный и «продвинутый» «Я не волшебник, я только учусь». Продвинутому SQL нас постоянно учат такие видные гуру как Markus Winand и Макс Богук. Рекурсивные CTE, LATERAL JOIN, виртуозная работа с массивами и строками, window functions и прочие модные штучки, которые помогут вам в дрессировке вашего Постгреса, — я постараюсь сделать хороший обзор, а если вдруг тема покажется интересной, то в следующих сеансах группового Постгреса мы обязательно пригласим настоящих гуру :)
#RuPostgresLive 4: как писать и читать сложные SQL-запросы
#RuPostgresLive 4: как писать и читать сложные SQL-запросы
Nikolay Samokhvalov
Онлайн-опросы неизменно показывают — всех нас очень интересуют две вещи: а) как писать наиболее эффективные SQL-запросы, б) как «читать» такие запросы, а точнее, как понимать, что именно делает или будет делать СУБД при их выполнении. Эти две неразрывно связанные друг с другом темы чрезвычайно обширны, SQL-искусству можно (и нужно) учиться годами. Во время нашей очередной встречи в прямом эфире мы затронем некоторые аспекты обеих. ЧАСТЬ 1: EXPLAIN Алексей Ермаков. Как читать и интерпретировать вывод команды EXPLAIN Команда EXPLAIN — основной инструмент анализа запросов, позволяющий разобраться, каким образом запрос будет выполняться и как можно его ускорить. Для сложных запросов вывод может быть довольно громоздким и его становится сложно читать. Я расскажу, из каких частей состоит план запроса, на какие «маркеры» в нём следует обращать внимание в первую очередь и как на это реагировать. ЧАСТЬ 2: ADVANCED SQL Николай Самохвалов. SQL современный и «продвинутый» «Я не волшебник, я только учусь». Продвинутому SQL нас постоянно учат такие видные гуру как Markus Winand и Макс Богук. Рекурсивные CTE, LATERAL JOIN, виртуозная работа с массивами и строками, window functions и прочие модные штучки, которые помогут вам в дрессировке вашего Постгреса, — я постараюсь сделать хороший обзор, а если вдруг тема покажется интересной, то в следующих сеансах группового Постгреса мы обязательно пригласим настоящих гуру :)
#RuPostgresLive 4: как писать и читать сложные SQL-запросы
#RuPostgresLive 4: как писать и читать сложные SQL-запросы
Nikolay Samokhvalov
Мы обсудим несколько фундаментальных ситуаций использования РСУБД (каждая из которых неоднократно встречалась автору), попутно разбирая возможные ошибки: - элементарная модификация данных; - работа с датой, временем и временными зонами; - проверка ограничений целостности; - очередь заданий; - пакетная работа с данными (например, удаление пачки записей в таблице); - полнотекстовый поиск; - относительно новые задачи (создание API, machine learning).
Database First! О распространённых ошибках использования РСУБД
Database First! О распространённых ошибках использования РСУБД
Nikolay Samokhvalov
Первый релиз-кандидат версии 9.6 вышел 1 сентября, а это значит, что совсем скоро будет полноценный релиз. Все вокруг уже успели обсудить новинки, и теперь уже стыдно ничего не знать о таких вещах, как параллелизация выполнения запросов, pushdown для FDW, мониторинг waitlocks, полнотекстовый поиск по фразам или магический \gexec в psql. Чтобы никому не приходилось краснеть, мы быстро пройдёмся по всем основным и интересным моментам версии 9.6.
#RuPostges в Yandex, эпизод 3. Что же нового в PostgreSQL 9.6
#RuPostges в Yandex, эпизод 3. Что же нового в PostgreSQL 9.6
Nikolay Samokhvalov
RITConf 2016 Moscow Russia – #noBacked, REST API, PostgreSQL, Postgres
#noBackend, или Как выжить в эпоху толстеющих клиентов
#noBackend, или Как выжить в эпоху толстеющих клиентов
Nikolay Samokhvalov
Greenplum: архитектура, опыт внедрения и использования в банке, Дмитрий Немчин, банк Тинькофф
#PostgreSQLRussia в банке Тинькофф, доклад №1
#PostgreSQLRussia в банке Тинькофф, доклад №1
Nikolay Samokhvalov
A Lightning talk about Postgres in Russia and #PostgreSQLRussia, Nikolay Samokhvalov, includes 2016 CfPs inviting speakers to PgDay.ru, PgConf.ru and Highload.co convefereces
SFPUG 2015.11.20 lightning talk "PostgreSQL in Russia"
SFPUG 2015.11.20 lightning talk "PostgreSQL in Russia"
Nikolay Samokhvalov
Встречи сообщества http://PostgreSQLRussia.org - Миграция из Oracle в Postgres. Встреча в компании CUSTIS. План встречи: 19:00 Приветственная пицца, свободное общение. 19:20 Вступление. Рассказ о CUSTIS. 19:25 Николай Самохвалов. Коротко о PostgreSQL. 19:35 Максим Трегубов, CUSTIS. Миграция данных из Oracle в Postgres. Доклад о том, как мы для одного из заказчиков тестировали переход с СУБД Oracle на Postgres. Расскажем о выборе инструмента миграции данных, настройке тестовой среды и о полученных результатах. Также немного затронем модную тему DevOps и покажем роль Ansible в миграции данных. 20:10 Вячеслав Муравлев, CUSTIS. Data Access Layer как страховка при миграции СУБД. Для многих АС миграция с одной СУБД на другую сродни наступлению страхового случая «тотал» - необходимо переписать львиную долю кода. Подстраховаться от такого ущерба можно с помощью шаблона проектирования Data Access Layer (DAL). Мы расскажем как этот подход помог нам провести первый этап миграции АС одного из заказчиков с Oracle на PostgreSQL, рассмотрим инструментарий, обсудим применимость подхода на уровне предприятия. 20:30 Иван Кухарчук, ЯНДЕКС. Как можно сэкономить на лицензиях и снизить нагрузку на Oracle, переселив отчёты в PostgreSQL. 20:50 Завершение встречи, свободное общение.
#PostgreSQLRussia 2015.09.15 - Николай Самохвалов - 5 главных особенностей Po...
#PostgreSQLRussia 2015.09.15 - Николай Самохвалов - 5 главных особенностей Po...
Nikolay Samokhvalov
Максим Трегубов, CUSTIS. Миграция данных из Oracle в Postgres. Доклад о том, как мы для одного из заказчиков тестировали переход с СУБД Oracle на Postgres. Расскажем о выборе инструмента миграции данных, настройке тестовой среды и о полученных результатах. Также немного затронем модную тему DevOps и покажем роль Ansible в миграции данных.
#PostgreSQLRussia 2015.09.15 - Максим Трегубов, CUSTIS - Миграция из Oracle в...
#PostgreSQLRussia 2015.09.15 - Максим Трегубов, CUSTIS - Миграция из Oracle в...
Nikolay Samokhvalov
Доклад от Parallels: Методики тестировния производительности database-centric приложений Описание: При работе над сложными продуктами в database-centric приложениях изменения в коде и тем более в SQL запросах к базе данных могут приводить к неожиданным падениям производительности или же деградации производительности приложения с ростом размера базы данных. Поэтому важно уметь как можно быстрее отлавливать и исправлять причины таких деградаций. Доклад о том, как устроен процесс мониторинга производительности продукта автоматизации хостинга и облачных сервисов Parallels Automation, для которого определяющим фактором является производительность базы данных. Компания покажет, как анализирует планы исполнения SQL запросов внутри PostgreSQL, как проверяет насколько быстро и эффективно в целом работают SQL запросы, как определяет стратегию дальнейшей оптимизации.
2014.12.23 Александр Андреев, Parallels
2014.12.23 Александр Андреев, Parallels
Nikolay Samokhvalov
Демонстрация восстановления и отката PostgreSQL
2014.10.15 Сергей Бурладян, Avito.ru
2014.10.15 Сергей Бурладян, Avito.ru
Nikolay Samokhvalov
More Related Content
Viewers also liked
PostgreSQLRussia community relaunched in Moscow, Russia in form of meetups -- join us at http://Meetup.com/PostgreSQLRussia!
PostgreSQL Moscow Meetup - September 2014 - Nikolay Samokhvalov
PostgreSQL Moscow Meetup - September 2014 - Nikolay Samokhvalov
Nikolay Samokhvalov
PostgreSQL 9.4 changes: JSON, JSONB, GiST, GIN, jsquery. Future development. VODKA -- join us at http://Meetup.com/PostgreSQLRussia!
PostgreSQL Moscow Meetup - September 2014 - Oleg Bartunov and Alexander Korotkov
PostgreSQL Moscow Meetup - September 2014 - Oleg Bartunov and Alexander Korotkov
Nikolay Samokhvalov
More: http://PostgreSQLRussia.org Доклад посвящён резервному хранению СУБД PostgreSQL. Мы поговорим о том, как устроено хранение данных на диске и организован WAL в PostgreSQL, какие есть средства для резервного копирования и восстановления данных. Обсудим, как перестать беспокоиться за свои данные и почему PostgreSQL славится своей надёжностью.
Владимир Бородин: Как спать спокойно - 2015.10.14 PostgreSQLRussia.org meetu...
Владимир Бородин: Как спать спокойно - 2015.10.14 PostgreSQLRussia.org meetu...
Nikolay Samokhvalov
Postgres Vision 2016 Lightning Talk
2016.10.13 PostgreSQL in Russia
2016.10.13 PostgreSQL in Russia
Nikolay Samokhvalov
Тип данных JSONb – это, пожалуй, самая яркая новинка PostgreSQL 9.4, который вышел 18 декабря 2014. Уже немало докладов и статей посвящено этому типу данных, работе с ним и индексации. Но как правило, информация в них перегружена специфичными для PostgreSQL терминами. Запутались в моделях данных? В том, какие индексы могут вам помочь ускорить вашу работу с СУБД? Этот доклад помогает сложить паттерн. Он для тех, кто начал использовать PostgreSQL совсем недавно или только планирует работать с ним. В нём рассказано о месте PostgreSQL в современном мире СУБД, о борьбе различных моделей данных за место под солнцем на этом рынке и то, как это отразилось на развитие Postgres. Помимо прочего, рассказывается о том, какие вообще бывают деревья, как они помогают ускорять базы данных и почему PostgreSQL — просто райский лес для деревьев самого разного типа :) См. также видео: http://postgresmen.ru/meetup/2014-12-23-parallels
2014.12.23 Николай Самохвалов, Ещё раз о JSON(b) в PostgreSQL 9.4
2014.12.23 Николай Самохвалов, Ещё раз о JSON(b) в PostgreSQL 9.4
Nikolay Samokhvalov
Реляционной модели скоро исполнится полвека – это огромный срок для любой технологической индустрии, не говоря уже об ИТ. За прошедшие годы этой модели было брошено немало вызовов, оказавших немалое влияние на развитие реляционных СУБД. В докладе обсуждаются три главных вызова реляционной модели, включая и NoSQL. На основе многолетнего опыта использования PostgreSQL для создания социальных сетей, объединяющих многомиллионные аудитории, наглядно демонстрируется как эта СУБД реагировала на возникающие вызовы. Речь также пойдет о «трех китах» PostgreSQL, которые не дают этой системе превратиться в монстра и позволяют обогащаться функционалом, необходимым для создания современных высоконагруженных проектов. Особое внимание в докладе уделено новым типам данных, JSON и JSONB — их возможностям, способам индексирования, а также разбору имеющихся недостатков.
Три вызова реляционным СУБД и новый PostgreSQL - #PostgreSQLRussia семинар по...
Три вызова реляционным СУБД и новый PostgreSQL - #PostgreSQLRussia семинар по...
Nikolay Samokhvalov
Опыт миграции с Oracle на PostgreSQL в проекте Яндекс.Почта
2014.09.24 история небольшого успеха с PostgreSQL (Yandex)
2014.09.24 история небольшого успеха с PostgreSQL (Yandex)
Nikolay Samokhvalov
Viewers also liked
(7)
PostgreSQL Moscow Meetup - September 2014 - Nikolay Samokhvalov
PostgreSQL Moscow Meetup - September 2014 - Nikolay Samokhvalov
PostgreSQL Moscow Meetup - September 2014 - Oleg Bartunov and Alexander Korotkov
PostgreSQL Moscow Meetup - September 2014 - Oleg Bartunov and Alexander Korotkov
Владимир Бородин: Как спать спокойно - 2015.10.14 PostgreSQLRussia.org meetu...
Владимир Бородин: Как спать спокойно - 2015.10.14 PostgreSQLRussia.org meetu...
2016.10.13 PostgreSQL in Russia
2016.10.13 PostgreSQL in Russia
2014.12.23 Николай Самохвалов, Ещё раз о JSON(b) в PostgreSQL 9.4
2014.12.23 Николай Самохвалов, Ещё раз о JSON(b) в PostgreSQL 9.4
Три вызова реляционным СУБД и новый PostgreSQL - #PostgreSQLRussia семинар по...
Три вызова реляционным СУБД и новый PostgreSQL - #PostgreSQLRussia семинар по...
2014.09.24 история небольшого успеха с PostgreSQL (Yandex)
2014.09.24 история небольшого успеха с PostgreSQL (Yandex)
More from 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-конвейер?
Эксперименты с Postgres в Docker и облаках — оптимизация настроек и схемы ва...
Эксперименты с Postgres в Docker и облаках — оптимизация настроек и схемы ва...
Nikolay Samokhvalov
Shared_buffers = 25% – это много или мало? Или в самый раз? Как понять, подходит ли эта – довольно устаревшая – рекомендация в вашем конкретном случае? Пришло время подойти к вопросу подбора параметров postgresql.conf "по-взрослому". Не с помощью слепых "автотюнеров" или устаревших советов из статей и блогов, а на основе: строго выверенных экспериментов на БД, производимых автоматизированно, в больших количествах и в условиях, максимально приближенных к "боевым", глубокого понимания особенностей работы СУБД и ОС. Используя Nancy CLI (https://gitlab.com/postgres.ai/nancy), мы рассмотрим конкретный пример – пресловутые shared_buffers – в разных ситуациях, в разных проектах и попробуем разобраться, как же подобрать оптимальную настройку для нашей инфраструктуры, БД и нагрузки. https://pgconf.ru/2019/242809
Промышленный подход к тюнингу PostgreSQL: эксперименты над базами данных
Промышленный подход к тюнингу PostgreSQL: эксперименты над базами данных
Nikolay Samokhvalov
Future database administration will be highly automated. Until then, we still live in a world where extensive manual interactions are required from a skilled DBA. This will change soon as more "autonomous databases" reach maturity and enter the production environment. Postgres-specific monitoring tools and systems continue to improve, detecting and analyzing performance issues and bottlenecks in production databases. However, while these tools can detect current issues, they require highly-experienced DBAs to analyze and recommend mitigations. In this session, the speaker will present the initial results of the POSTGRES.AI project – Nancy CLI, a unified way to manage automated database experiments. Nancy CLI is an automated database management framework based on well-known open-source projects and incorporating major open-source tools and Postgres modules: pgBadger, pg_stat_kcache, auto_explain, pgreplay, and others. Originally developed with the goal to simulate various SQL query use cases in various environments and collect data to train ML models, Nancy CLI turned out to be very a universal framework that can play a crucial role in CI/CD pipelines in any company. Using Nancy CLI, casual DBAs and any engineers can easily conduct automated experiments today, either on AWS EC2 Spot instances or on any other servers. All you need is to tell Nancy which database to use, specify workload (synthetic or "real", generated based on the Postgres logs), and what you want to test – say, check how a new index will affect all most expensive query groups from pg_stat_statements, or compare various values of "default_statistics_target". All the collected information with a very high level of confidence will give you understanding, how various queries and overall Postgres performance will be affected when you apply this change to production.
The Art of Database Experiments – PostgresConf Silicon Valley 2018 / San Jose
The Art of Database Experiments – PostgresConf Silicon Valley 2018 / San Jose
Nikolay Samokhvalov
Nancy CLI, a unified way to manage automated database experiments. Nancy CLI is an automated database management framework based on well-known open-source projects and incorporating major open-source tools. Using these tools, casual DBAs can conduct automated experiments today, either on AWS EC2 Spot instances or on any other servers. All you need is to tell Nancy which database to use, how to determine workloads and what you want to verify – say, check how some index will help, or compare various values of "default_statistics_target" for your database and your workload. Everything else Nancy will do for you, in fully automated fashion, in the end presenting you detailed results for comparison.
Nancy CLI. Automated Database Experiments
Nancy CLI. Automated Database Experiments
Nikolay Samokhvalov
Онлайн-опросы неизменно показывают — всех нас очень интересуют две вещи: а) как писать наиболее эффективные SQL-запросы, б) как «читать» такие запросы, а точнее, как понимать, что именно делает или будет делать СУБД при их выполнении. Эти две неразрывно связанные друг с другом темы чрезвычайно обширны, SQL-искусству можно (и нужно) учиться годами. Во время нашей очередной встречи в прямом эфире мы затронем некоторые аспекты обеих. ЧАСТЬ 1: EXPLAIN Алексей Ермаков. Как читать и интерпретировать вывод команды EXPLAIN Команда EXPLAIN — основной инструмент анализа запросов, позволяющий разобраться, каким образом запрос будет выполняться и как можно его ускорить. Для сложных запросов вывод может быть довольно громоздким и его становится сложно читать. Я расскажу, из каких частей состоит план запроса, на какие «маркеры» в нём следует обращать внимание в первую очередь и как на это реагировать. ЧАСТЬ 2: ADVANCED SQL Николай Самохвалов. SQL современный и «продвинутый» «Я не волшебник, я только учусь». Продвинутому SQL нас постоянно учат такие видные гуру как Markus Winand и Макс Богук. Рекурсивные CTE, LATERAL JOIN, виртуозная работа с массивами и строками, window functions и прочие модные штучки, которые помогут вам в дрессировке вашего Постгреса, — я постараюсь сделать хороший обзор, а если вдруг тема покажется интересной, то в следующих сеансах группового Постгреса мы обязательно пригласим настоящих гуру :)
#RuPostgresLive 4: как писать и читать сложные SQL-запросы
#RuPostgresLive 4: как писать и читать сложные SQL-запросы
Nikolay Samokhvalov
Онлайн-опросы неизменно показывают — всех нас очень интересуют две вещи: а) как писать наиболее эффективные SQL-запросы, б) как «читать» такие запросы, а точнее, как понимать, что именно делает или будет делать СУБД при их выполнении. Эти две неразрывно связанные друг с другом темы чрезвычайно обширны, SQL-искусству можно (и нужно) учиться годами. Во время нашей очередной встречи в прямом эфире мы затронем некоторые аспекты обеих. ЧАСТЬ 1: EXPLAIN Алексей Ермаков. Как читать и интерпретировать вывод команды EXPLAIN Команда EXPLAIN — основной инструмент анализа запросов, позволяющий разобраться, каким образом запрос будет выполняться и как можно его ускорить. Для сложных запросов вывод может быть довольно громоздким и его становится сложно читать. Я расскажу, из каких частей состоит план запроса, на какие «маркеры» в нём следует обращать внимание в первую очередь и как на это реагировать. ЧАСТЬ 2: ADVANCED SQL Николай Самохвалов. SQL современный и «продвинутый» «Я не волшебник, я только учусь». Продвинутому SQL нас постоянно учат такие видные гуру как Markus Winand и Макс Богук. Рекурсивные CTE, LATERAL JOIN, виртуозная работа с массивами и строками, window functions и прочие модные штучки, которые помогут вам в дрессировке вашего Постгреса, — я постараюсь сделать хороший обзор, а если вдруг тема покажется интересной, то в следующих сеансах группового Постгреса мы обязательно пригласим настоящих гуру :)
#RuPostgresLive 4: как писать и читать сложные SQL-запросы
#RuPostgresLive 4: как писать и читать сложные SQL-запросы
Nikolay Samokhvalov
Мы обсудим несколько фундаментальных ситуаций использования РСУБД (каждая из которых неоднократно встречалась автору), попутно разбирая возможные ошибки: - элементарная модификация данных; - работа с датой, временем и временными зонами; - проверка ограничений целостности; - очередь заданий; - пакетная работа с данными (например, удаление пачки записей в таблице); - полнотекстовый поиск; - относительно новые задачи (создание API, machine learning).
Database First! О распространённых ошибках использования РСУБД
Database First! О распространённых ошибках использования РСУБД
Nikolay Samokhvalov
Первый релиз-кандидат версии 9.6 вышел 1 сентября, а это значит, что совсем скоро будет полноценный релиз. Все вокруг уже успели обсудить новинки, и теперь уже стыдно ничего не знать о таких вещах, как параллелизация выполнения запросов, pushdown для FDW, мониторинг waitlocks, полнотекстовый поиск по фразам или магический \gexec в psql. Чтобы никому не приходилось краснеть, мы быстро пройдёмся по всем основным и интересным моментам версии 9.6.
#RuPostges в Yandex, эпизод 3. Что же нового в PostgreSQL 9.6
#RuPostges в Yandex, эпизод 3. Что же нового в PostgreSQL 9.6
Nikolay Samokhvalov
RITConf 2016 Moscow Russia – #noBacked, REST API, PostgreSQL, Postgres
#noBackend, или Как выжить в эпоху толстеющих клиентов
#noBackend, или Как выжить в эпоху толстеющих клиентов
Nikolay Samokhvalov
Greenplum: архитектура, опыт внедрения и использования в банке, Дмитрий Немчин, банк Тинькофф
#PostgreSQLRussia в банке Тинькофф, доклад №1
#PostgreSQLRussia в банке Тинькофф, доклад №1
Nikolay Samokhvalov
A Lightning talk about Postgres in Russia and #PostgreSQLRussia, Nikolay Samokhvalov, includes 2016 CfPs inviting speakers to PgDay.ru, PgConf.ru and Highload.co convefereces
SFPUG 2015.11.20 lightning talk "PostgreSQL in Russia"
SFPUG 2015.11.20 lightning talk "PostgreSQL in Russia"
Nikolay Samokhvalov
Встречи сообщества http://PostgreSQLRussia.org - Миграция из Oracle в Postgres. Встреча в компании CUSTIS. План встречи: 19:00 Приветственная пицца, свободное общение. 19:20 Вступление. Рассказ о CUSTIS. 19:25 Николай Самохвалов. Коротко о PostgreSQL. 19:35 Максим Трегубов, CUSTIS. Миграция данных из Oracle в Postgres. Доклад о том, как мы для одного из заказчиков тестировали переход с СУБД Oracle на Postgres. Расскажем о выборе инструмента миграции данных, настройке тестовой среды и о полученных результатах. Также немного затронем модную тему DevOps и покажем роль Ansible в миграции данных. 20:10 Вячеслав Муравлев, CUSTIS. Data Access Layer как страховка при миграции СУБД. Для многих АС миграция с одной СУБД на другую сродни наступлению страхового случая «тотал» - необходимо переписать львиную долю кода. Подстраховаться от такого ущерба можно с помощью шаблона проектирования Data Access Layer (DAL). Мы расскажем как этот подход помог нам провести первый этап миграции АС одного из заказчиков с Oracle на PostgreSQL, рассмотрим инструментарий, обсудим применимость подхода на уровне предприятия. 20:30 Иван Кухарчук, ЯНДЕКС. Как можно сэкономить на лицензиях и снизить нагрузку на Oracle, переселив отчёты в PostgreSQL. 20:50 Завершение встречи, свободное общение.
#PostgreSQLRussia 2015.09.15 - Николай Самохвалов - 5 главных особенностей Po...
#PostgreSQLRussia 2015.09.15 - Николай Самохвалов - 5 главных особенностей Po...
Nikolay Samokhvalov
Максим Трегубов, CUSTIS. Миграция данных из Oracle в Postgres. Доклад о том, как мы для одного из заказчиков тестировали переход с СУБД Oracle на Postgres. Расскажем о выборе инструмента миграции данных, настройке тестовой среды и о полученных результатах. Также немного затронем модную тему DevOps и покажем роль Ansible в миграции данных.
#PostgreSQLRussia 2015.09.15 - Максим Трегубов, CUSTIS - Миграция из Oracle в...
#PostgreSQLRussia 2015.09.15 - Максим Трегубов, CUSTIS - Миграция из Oracle в...
Nikolay Samokhvalov
Доклад от Parallels: Методики тестировния производительности database-centric приложений Описание: При работе над сложными продуктами в database-centric приложениях изменения в коде и тем более в SQL запросах к базе данных могут приводить к неожиданным падениям производительности или же деградации производительности приложения с ростом размера базы данных. Поэтому важно уметь как можно быстрее отлавливать и исправлять причины таких деградаций. Доклад о том, как устроен процесс мониторинга производительности продукта автоматизации хостинга и облачных сервисов Parallels Automation, для которого определяющим фактором является производительность базы данных. Компания покажет, как анализирует планы исполнения SQL запросов внутри PostgreSQL, как проверяет насколько быстро и эффективно в целом работают SQL запросы, как определяет стратегию дальнейшей оптимизации.
2014.12.23 Александр Андреев, Parallels
2014.12.23 Александр Андреев, Parallels
Nikolay Samokhvalov
Демонстрация восстановления и отката PostgreSQL
2014.10.15 Сергей Бурладян, Avito.ru
2014.10.15 Сергей Бурладян, Avito.ru
Nikolay Samokhvalov
* приемы доступа к данным; * прикладной класс работы с БД поверх PDO, особенности PDO; * связки пуллов коннектов; * API хранимых процедур; * работа c распределенным хранилищем; * RPC между базами на примере асинхронного геокодинга.
2014.10.15 Мурат Кабилов, Avito.ru #PostgreSQLRussia
2014.10.15 Мурат Кабилов, Avito.ru #PostgreSQLRussia
Nikolay Samokhvalov
Стас Кельвич, аспирант МИФИ; Александр Коротков, «Интаро-Софт», PostgreSQL GDG: «Эффективный поиск ближайшего объекта своими руками»
2014.10.15 блиц-доклад PostgreSQL kNN search
2014.10.15 блиц-доклад PostgreSQL kNN search
Nikolay Samokhvalov
20080214 Rupg Meeting1 Whatisnewpostgresql8.3
20080214 Rupg Meeting1 Whatisnewpostgresql8.3
Nikolay Samokhvalov
20080424 Cdb2008 Postgresql News Bartunov
20080424 Cdb2008 Postgresql News Bartunov
Nikolay Samokhvalov
20080424 Cdb2008 Postgresql8.3 Samokhvalov
20080424 Cdb2008 Postgresql8.3 Samokhvalov
Nikolay Samokhvalov
More from Nikolay Samokhvalov
(20)
Эксперименты с Postgres в Docker и облаках — оптимизация настроек и схемы ва...
Эксперименты с Postgres в Docker и облаках — оптимизация настроек и схемы ва...
Промышленный подход к тюнингу PostgreSQL: эксперименты над базами данных
Промышленный подход к тюнингу PostgreSQL: эксперименты над базами данных
The Art of Database Experiments – PostgresConf Silicon Valley 2018 / San Jose
The Art of Database Experiments – PostgresConf Silicon Valley 2018 / San Jose
Nancy CLI. Automated Database Experiments
Nancy CLI. Automated Database Experiments
#RuPostgresLive 4: как писать и читать сложные SQL-запросы
#RuPostgresLive 4: как писать и читать сложные SQL-запросы
#RuPostgresLive 4: как писать и читать сложные SQL-запросы
#RuPostgresLive 4: как писать и читать сложные SQL-запросы
Database First! О распространённых ошибках использования РСУБД
Database First! О распространённых ошибках использования РСУБД
#RuPostges в Yandex, эпизод 3. Что же нового в PostgreSQL 9.6
#RuPostges в Yandex, эпизод 3. Что же нового в PostgreSQL 9.6
#noBackend, или Как выжить в эпоху толстеющих клиентов
#noBackend, или Как выжить в эпоху толстеющих клиентов
#PostgreSQLRussia в банке Тинькофф, доклад №1
#PostgreSQLRussia в банке Тинькофф, доклад №1
SFPUG 2015.11.20 lightning talk "PostgreSQL in Russia"
SFPUG 2015.11.20 lightning talk "PostgreSQL in Russia"
#PostgreSQLRussia 2015.09.15 - Николай Самохвалов - 5 главных особенностей Po...
#PostgreSQLRussia 2015.09.15 - Николай Самохвалов - 5 главных особенностей Po...
#PostgreSQLRussia 2015.09.15 - Максим Трегубов, CUSTIS - Миграция из Oracle в...
#PostgreSQLRussia 2015.09.15 - Максим Трегубов, CUSTIS - Миграция из Oracle в...
2014.12.23 Александр Андреев, Parallels
2014.12.23 Александр Андреев, Parallels
2014.10.15 Сергей Бурладян, Avito.ru
2014.10.15 Сергей Бурладян, Avito.ru
2014.10.15 Мурат Кабилов, Avito.ru #PostgreSQLRussia
2014.10.15 Мурат Кабилов, Avito.ru #PostgreSQLRussia
2014.10.15 блиц-доклад PostgreSQL kNN search
2014.10.15 блиц-доклад PostgreSQL kNN search
20080214 Rupg Meeting1 Whatisnewpostgresql8.3
20080214 Rupg Meeting1 Whatisnewpostgresql8.3
20080424 Cdb2008 Postgresql News Bartunov
20080424 Cdb2008 Postgresql News Bartunov
20080424 Cdb2008 Postgresql8.3 Samokhvalov
20080424 Cdb2008 Postgresql8.3 Samokhvalov
PostgreSQL Moscow Meetup - September 2014 - Ilya Kosmodemyansky
1.
×òî íîâîãî â
PostgreSQL 9.4 c òî÷êè çðåíèÿ ïðîèçâîäèòåëüíîñòè Èëüÿ Êîñìîäåìüÿíñêèé ik@postgresql-consulting.com
2.
Ïëàí Óëó÷øåíèÿ ïðîèçâîäèòåëüíîñòè
Materialized views Huge pages WAL Íåáîëüøèå íî ïðèÿòíûå ìåëî÷è Ìîíèòîðèíã ïðîèçâîäèòåëüíîñòè Çàäåë íà áóäóùåå
3.
Materialized views
View, êîòîðàÿ íå îáíîâëÿåòñÿ ïðè îáðàùåíèè, à õðàíèò äàííûå ëîêàëüíî
4.
Materialized views
View, êîòîðàÿ íå îáíîâëÿåòñÿ ïðè îáðàùåíèè, à õðàíèò äàííûå ëîêàëüíî Î÷åíü öåííî äëÿ OLAP è äåíîðìàëèçàöèè
5.
Materialized views
View, êîòîðàÿ íå îáíîâëÿåòñÿ ïðè îáðàùåíèè, à õðàíèò äàííûå ëîêàëüíî Î÷åíü öåííî äëÿ OLAP è äåíîðìàëèçàöèè Çàäà÷à îáíîâëåíèÿ äàííûõ â Mat. View - ñëîæíàÿ
6.
Materialized views
View, êîòîðàÿ íå îáíîâëÿåòñÿ ïðè îáðàùåíèè, à õðàíèò äàííûå ëîêàëüíî Î÷åíü öåííî äëÿ OLAP è äåíîðìàëèçàöèè Çàäà÷à îáíîâëåíèÿ äàííûõ â Mat. View - ñëîæíàÿ Äî 9.3 â PostgreSQL íå áûëî âñòðîåííîé ðåàëèçàöèè
7.
Materialized views
View, êîòîðàÿ íå îáíîâëÿåòñÿ ïðè îáðàùåíèè, à õðàíèò äàííûå ëîêàëüíî Î÷åíü öåííî äëÿ OLAP è äåíîðìàëèçàöèè Çàäà÷à îáíîâëåíèÿ äàííûõ â Mat. View - ñëîæíàÿ Äî 9.3 â PostgreSQL íå áûëî âñòðîåííîé ðåàëèçàöèè Most desired feature â TODO
8.
Materialized views
View, êîòîðàÿ íå îáíîâëÿåòñÿ ïðè îáðàùåíèè, à õðàíèò äàííûå ëîêàëüíî Î÷åíü öåííî äëÿ OLAP è äåíîðìàëèçàöèè Çàäà÷à îáíîâëåíèÿ äàííûõ â Mat. View - ñëîæíàÿ Äî 9.3 â PostgreSQL íå áûëî âñòðîåííîé ðåàëèçàöèè Most desired feature â TODO Materialized views â 9.3 ýòî PoC
9.
Materialized views â
9.4 REFRESH MATERIALIZED VIEW CONCURRENTLY
10.
Materialized views â
9.4 REFRESH MATERIALIZED VIEW CONCURRENTLY Íå òðåáóåòñÿ ýêñêëþçèâíàÿ áëîêèðîâêà
11.
Materialized views â
9.4 REFRESH MATERIALIZED VIEW CONCURRENTLY Íå òðåáóåòñÿ ýêñêëþçèâíàÿ áëîêèðîâêà Òî åñòü óæå ìîæíî ïîëüçîâàòüñÿ
12.
Materialized views â
9.4 REFRESH MATERIALIZED VIEW CONCURRENTLY Íå òðåáóåòñÿ ýêñêëþçèâíàÿ áëîêèðîâêà Òî åñòü óæå ìîæíî ïîëüçîâàòüñÿ Â ñèëó îñîáåííîñòåé ðåàëèçàöèè òðåáóåòñÿ Primary Key/ Unique Index
13.
Huge pages -
÷òî òàêîå è çà÷åì Ñåðâåðà ñ áîëüøèì êîëè÷åñòâîì ïàìÿòè (128-256Gb) òåïåðü ñòîÿò ðàçóìíûõ äåíåã
14.
Huge pages -
÷òî òàêîå è çà÷åì Ñåðâåðà ñ áîëüøèì êîëè÷åñòâîì ïàìÿòè (128-256Gb) òåïåðü ñòîÿò ðàçóìíûõ äåíåã Äåðæàòü áàçó â ïàìÿòè õîðîøî (ëþáóþ õîðîøî, PostgreSQL ñîâñåì õîðîøî)
15.
Huge pages -
÷òî òàêîå è çà÷åì Ñåðâåðà ñ áîëüøèì êîëè÷åñòâîì ïàìÿòè (128-256Gb) òåïåðü ñòîÿò ðàçóìíûõ äåíåã Äåðæàòü áàçó â ïàìÿòè õîðîøî (ëþáóþ õîðîøî, PostgreSQL ñîâñåì õîðîøî) Ïî óìîë÷àíèþ ïàìÿòü âûäåëÿåòñÿ ïî 4kB - òàê áûñòðåå
16.
Huge pages -
÷òî òàêîå è çà÷åì Ñåðâåðà ñ áîëüøèì êîëè÷åñòâîì ïàìÿòè (128-256Gb) òåïåðü ñòîÿò ðàçóìíûõ äåíåã Äåðæàòü áàçó â ïàìÿòè õîðîøî (ëþáóþ õîðîøî, PostgreSQL ñîâñåì õîðîøî) Ïî óìîë÷àíèþ ïàìÿòü âûäåëÿåòñÿ ïî 4kB - òàê áûñòðåå ÎÑ òðàíñëèðóåò âèðòóàëüíûå àäðåñà â ôèçè÷åñêèå, ðåçóëüòàò êýøèðóåòñÿ â Translation Lookaside Buffer (TLB)
17.
Huge pages -
÷òî òàêîå è çà÷åì Ñåðâåðà ñ áîëüøèì êîëè÷åñòâîì ïàìÿòè (128-256Gb) òåïåðü ñòîÿò ðàçóìíûõ äåíåã Äåðæàòü áàçó â ïàìÿòè õîðîøî (ëþáóþ õîðîøî, PostgreSQL ñîâñåì õîðîøî) Ïî óìîë÷àíèþ ïàìÿòü âûäåëÿåòñÿ ïî 4kB - òàê áûñòðåå ÎÑ òðàíñëèðóåò âèðòóàëüíûå àäðåñà â ôèçè÷åñêèå, ðåçóëüòàò êýøèðóåòñÿ â Translation Lookaside Buffer (TLB) 1Gb 4kB = 262144 è 64-áèòíàÿ àäðåñàöèÿ - íà áîëüøèõ îáúåìàõ ïàìÿòè îâåðõýä è íèçêàÿ ýôôåêòèâíîñòü TLB
18.
Huge pages -
÷òî òàêîå è çà÷åì Ñåðâåðà ñ áîëüøèì êîëè÷åñòâîì ïàìÿòè (128-256Gb) òåïåðü ñòîÿò ðàçóìíûõ äåíåã Äåðæàòü áàçó â ïàìÿòè õîðîøî (ëþáóþ õîðîøî, PostgreSQL ñîâñåì õîðîøî) Ïî óìîë÷àíèþ ïàìÿòü âûäåëÿåòñÿ ïî 4kB - òàê áûñòðåå ÎÑ òðàíñëèðóåò âèðòóàëüíûå àäðåñà â ôèçè÷åñêèå, ðåçóëüòàò êýøèðóåòñÿ â Translation Lookaside Buffer (TLB) 1Gb 4kB = 262144 è 64-áèòíàÿ àäðåñàöèÿ - íà áîëüøèõ îáúåìàõ ïàìÿòè îâåðõýä è íèçêàÿ ýôôåêòèâíîñòü TLB Âûäåëÿåì ïàìÿòü áîëüøèìè (íàïðèìåð 2Mb) ïîðöèÿìè
19.
Huge pages è
PostgreSQL vm:nr_hugepages = 3170 (sysctl, ÿäðî äîëæíî ïîääåðæèâàòü)
20.
Huge pages è
PostgreSQL vm:nr_hugepages = 3170 (sysctl, ÿäðî äîëæíî ïîääåðæèâàòü) Äî 9.2 âêëþ÷èòåëüíî - ÷åðåç áèáëèîòåêó hugetlb
21.
Huge pages è
PostgreSQL vm:nr_hugepages = 3170 (sysctl, ÿäðî äîëæíî ïîääåðæèâàòü) Äî 9.2 âêëþ÷èòåëüíî - ÷åðåç áèáëèîòåêó hugetlb 9.3 óëó÷øåíà ðàáîòà ñ shared memory c ïîìîùüþ mmap - huge pages íå ðàáîòàþò
22.
Huge pages è
PostgreSQL vm:nr_hugepages = 3170 (sysctl, ÿäðî äîëæíî ïîääåðæèâàòü) Äî 9.2 âêëþ÷èòåëüíî - ÷åðåç áèáëèîòåêó hugetlb 9.3 óëó÷øåíà ðàáîòà ñ shared memory c ïîìîùüþ mmap - huge pages íå ðàáîòàþò huge_pages = try jonjo (postgresql.conf)
23.
Huge pages è
PostgreSQL vm:nr_hugepages = 3170 (sysctl, ÿäðî äîëæíî ïîääåðæèâàòü) Äî 9.2 âêëþ÷èòåëüíî - ÷åðåç áèáëèîòåêó hugetlb 9.3 óëó÷øåíà ðàáîòà ñ shared memory c ïîìîùüþ mmap - huge pages íå ðàáîòàþò huge_pages = try jonjo (postgresql.conf) try - äåôîëò, íå ïîëó÷èëîñü, íå èñïîëüçóåì
24.
Huge pages è
PostgreSQL vm:nr_hugepages = 3170 (sysctl, ÿäðî äîëæíî ïîääåðæèâàòü) Äî 9.2 âêëþ÷èòåëüíî - ÷åðåç áèáëèîòåêó hugetlb 9.3 óëó÷øåíà ðàáîòà ñ shared memory c ïîìîùüþ mmap - huge pages íå ðàáîòàþò huge_pages = try jonjo (postgresql.conf) try - äåôîëò, íå ïîëó÷èëîñü, íå èñïîëüçóåì Ñåé÷àñ ðàáîòàò òîëüêî íà linux, try íà FreeBSD - OK
25.
Îïòèìèçàöèÿ çàïèñè â
WAL Áîëåå îäíîãî áýêåíäà ìîæåò ïèñàòü â áóôåðû WAL
26.
Îïòèìèçàöèÿ çàïèñè â
WAL Áîëåå îäíîãî áýêåíäà ìîæåò ïèñàòü â áóôåðû WAL Ïðè àïäåéòå â WAL ìîæåò çàïèñûâàòüñÿ òîëüêî èçìåíåííîå ïîëå, à íå âñÿ ñòðîêà (åñëè tuple ïèøåòñÿ â òó æå ñòðàíèöó)
27.
Íåáîëüøèå íî ïðèÿòíûå
ìåëî÷è Ïðîèçâîäèòåëüíîñòü WINDOW ôóíêöèé
28.
Íåáîëüøèå íî ïðèÿòíûå
ìåëî÷è Ïðîèçâîäèòåëüíîñòü WINDOW ôóíêöèé Ïðîèçâîäèòåëüíîñòü COPY
29.
Íåáîëüøèå íî ïðèÿòíûå
ìåëî÷è Ïðîèçâîäèòåëüíîñòü WINDOW ôóíêöèé Ïðîèçâîäèòåëüíîñòü COPY Çàòðàòû ïàìÿòè íà àíîíèìíûå áëîêè (DO)
30.
Íåáîëüøèå íî ïðèÿòíûå
ìåëî÷è Ïðîèçâîäèòåëüíîñòü WINDOW ôóíêöèé Ïðîèçâîäèòåëüíîñòü COPY Çàòðàòû ïàìÿòè íà àíîíèìíûå áëîêè (DO) Óëó÷øåíèÿ îïòèìèçàòîðà
31.
Ìîíèòîðèíã pg_stat_all_tables:n_mod_since_analyze
32.
Ìîíèòîðèíã pg_stat_all_tables:n_mod_since_analyze
pg_stat_archiver
33.
Ìîíèòîðèíã pg_stat_all_tables:n_mod_since_analyze
pg_stat_archiver backend_xmin
34.
Ìîíèòîðèíã pg_stat_all_tables:n_mod_since_analyze
pg_stat_archiver backend_xmin Óëó÷øåí EXPLAIN
35.
Çàäåë íà áóäóùåå
- ïàðàëëåëèçì è ëîãè÷åñêàÿ ðåïëèêàöèÿ ïîëüçîâòåëüñêèé Ñ-êîä ìîæåò èñïîëíÿòüñÿ êàê îòäåëüíèûé ïðîöåññ (background workers) Ïàðàëëåëüíàÿ çàïèñü â áóôåðû WAL Logical Decoding
Download now