* приемы доступа к данным;
* прикладной класс работы с БД поверх PDO, особенности PDO;
* связки пуллов коннектов;
* API хранимых процедур;
* работа c распределенным хранилищем;
* RPC между базами на примере асинхронного геокодинга.
"Кластеры баз данных: делаем сложные вещи просто" Андрей Тихонов (Avito)AvitoTech
Порой в процессе развития высоконагруженного проекта наступает момент, когда необходимо масштабирование. Возможно, ваш проект впервые упёрся в производительность железа (и таким образом перешёл в разряд высоконагруженных); возможно, это уже не первое масштабирование — не важно. Какие же проблемы могут возникнуть?
Во-первых, если вы увеличиваете количество бэкенд-серверов, и, соответственно, количество рабочих процессов, то с ростом количества одновременных клиентских подключений вырастают и накладные расходы на базах данных.
Во-вторых, достаточно быстро может кончиться ресурс in-memory баз данных. Потребуется создать (либо увеличить) кластер, а это каждый раз влечёт за собой необходимость модифицировать логику приложения.
В-третьих, чем больше серверов, тем больше вероятность, что один из них выйдет из строя. Поэтому неплохо задуматься о том, как обеспечить отказоустойчивость, а это, опять же, потребует модифицировать логику приложения.
В этом докладе я расскажу, как и какими инструментами можно легко решить все вышеперечисленные проблемы: уменьшить накладные расходы от большого количества подключений к базам данных, создать/модифицировать кластер БД прозрачно для приложения, а также прозрачно добавить устойчивость к падениям серверов БД.
* приемы доступа к данным;
* прикладной класс работы с БД поверх PDO, особенности PDO;
* связки пуллов коннектов;
* API хранимых процедур;
* работа c распределенным хранилищем;
* RPC между базами на примере асинхронного геокодинга.
"Кластеры баз данных: делаем сложные вещи просто" Андрей Тихонов (Avito)AvitoTech
Порой в процессе развития высоконагруженного проекта наступает момент, когда необходимо масштабирование. Возможно, ваш проект впервые упёрся в производительность железа (и таким образом перешёл в разряд высоконагруженных); возможно, это уже не первое масштабирование — не важно. Какие же проблемы могут возникнуть?
Во-первых, если вы увеличиваете количество бэкенд-серверов, и, соответственно, количество рабочих процессов, то с ростом количества одновременных клиентских подключений вырастают и накладные расходы на базах данных.
Во-вторых, достаточно быстро может кончиться ресурс in-memory баз данных. Потребуется создать (либо увеличить) кластер, а это каждый раз влечёт за собой необходимость модифицировать логику приложения.
В-третьих, чем больше серверов, тем больше вероятность, что один из них выйдет из строя. Поэтому неплохо задуматься о том, как обеспечить отказоустойчивость, а это, опять же, потребует модифицировать логику приложения.
В этом докладе я расскажу, как и какими инструментами можно легко решить все вышеперечисленные проблемы: уменьшить накладные расходы от большого количества подключений к базам данных, создать/модифицировать кластер БД прозрачно для приложения, а также прозрачно добавить устойчивость к падениям серверов БД.
Из презентации вы узнаете:
— как мы пришли к Go, оставив идею использования Node.js, Scala или Rust;
— про первый сервис, который мы написали на Go и запустили в продакшен;
— про ошибки, с которыми сталкивались под нагрузкой;
— про оптимизации, которые мы сделали и еще планируем сделать;
— про тестирование и предотвращение тестирования на продакшене (в частности, websocket'ов).
Мониторинг ожиданий в PostgreSQL / Курбангалиев Ильдус (Postgres Professional)Ontico
В многоядерных высоконагруженных системах с высокой конкурентностью часто бывает сложно определить, чем занят отдельный процесс PostgreSQL. Он может находиться в ожидании локов высокого уровня, таких как локи таблиц, внутренних локов, используемых для синхронизации процессов, ввода-вывода и многих других.
В настоящий момент среди всех событий ожидания мониторить можно только локи высокого уровня с помощью представлений PostgreSQL. Другие типы ожиданий требуют использования низкоуровневых утилит типа perf, systemtap и других. Эти утилиты требуют специальных знаний и могут быть платформозависимыми. В то же время другие enterprise базы данных уже включают в себя инструменты для мониторинга ожиданий.
Мы разработали патч, который реализует мониторинг ожиданий в PostgreSQL. С минимальной настройкой (несколько конфигурационных параметров) этот патч показывает полную информацию о текущих ожиданиях в режиме реального времени и с небольшим оверхедом на всю систему. Этот патч уже работает на продакшен серверах Яндекса и показал свою полезность.
«Миллион открытых каналов с данными по сети» – Илья Биин (Zenhotels)AvitoTech
Поговорим о том, почему это далеко не самая простая задача, и как следует разбираться с возникающими трудностями. Рассмотрим и покритикуем существующие решения. Научимся создавать свой собственный велосипед.
Андрей Светлов-«Делаем своё решение для оптимальной загрузки кластера»Tanya Denisyuk
"Мое выступление поможет ответить на следующие вопросы:
1. Что такое HTTP reverse proxy?
2. Настройка NGINX в режиме reverse proxy.
3. Стандартные способы выбора upstream server: Round Robin, Hash, Consistent Hash.
4. Не сдерживаем фантазию -- пишем свой алгоритм.
5. Примеры, когда создание собственного решения оправдано."
"Успеть за 100 миллисекунд: контекстная реклама на Sphinx" Дмитрий Хасанов (...AvitoTech
C недавнего времени на Avito.ru появилась контекстная реклама. Миллионы объявлений, из которых нужно в режиме реального времени отобрать несколько релевантных для каждого отдельного пользователя.
Я расскажу о том, как и зачем мы используем миллионы коэффициентов при обработке каждого запроса, почему мы выбрали Sphinx и какие хитрости мы применили, чтобы уложиться в 100 миллисекунд.
В докладе рассматривается текущее состояние механизмов поиска и установки необходимых библиотек и утилит. Мы пробежим по общему определению менеджера пакетов и рассмотрим несколько распространенных примеров. Взглянем на типичные сценарии использования и на то, какие возможности были использованы в качестве критериев сравнения, а также составим представление о существующих решениях в мире С++ их конструктивных особенностях и примерах решаемых задач.
Из презентации вы узнаете:
— как мы пришли к Go, оставив идею использования Node.js, Scala или Rust;
— про первый сервис, который мы написали на Go и запустили в продакшен;
— про ошибки, с которыми сталкивались под нагрузкой;
— про оптимизации, которые мы сделали и еще планируем сделать;
— про тестирование и предотвращение тестирования на продакшене (в частности, websocket'ов).
Мониторинг ожиданий в PostgreSQL / Курбангалиев Ильдус (Postgres Professional)Ontico
В многоядерных высоконагруженных системах с высокой конкурентностью часто бывает сложно определить, чем занят отдельный процесс PostgreSQL. Он может находиться в ожидании локов высокого уровня, таких как локи таблиц, внутренних локов, используемых для синхронизации процессов, ввода-вывода и многих других.
В настоящий момент среди всех событий ожидания мониторить можно только локи высокого уровня с помощью представлений PostgreSQL. Другие типы ожиданий требуют использования низкоуровневых утилит типа perf, systemtap и других. Эти утилиты требуют специальных знаний и могут быть платформозависимыми. В то же время другие enterprise базы данных уже включают в себя инструменты для мониторинга ожиданий.
Мы разработали патч, который реализует мониторинг ожиданий в PostgreSQL. С минимальной настройкой (несколько конфигурационных параметров) этот патч показывает полную информацию о текущих ожиданиях в режиме реального времени и с небольшим оверхедом на всю систему. Этот патч уже работает на продакшен серверах Яндекса и показал свою полезность.
«Миллион открытых каналов с данными по сети» – Илья Биин (Zenhotels)AvitoTech
Поговорим о том, почему это далеко не самая простая задача, и как следует разбираться с возникающими трудностями. Рассмотрим и покритикуем существующие решения. Научимся создавать свой собственный велосипед.
Андрей Светлов-«Делаем своё решение для оптимальной загрузки кластера»Tanya Denisyuk
"Мое выступление поможет ответить на следующие вопросы:
1. Что такое HTTP reverse proxy?
2. Настройка NGINX в режиме reverse proxy.
3. Стандартные способы выбора upstream server: Round Robin, Hash, Consistent Hash.
4. Не сдерживаем фантазию -- пишем свой алгоритм.
5. Примеры, когда создание собственного решения оправдано."
"Успеть за 100 миллисекунд: контекстная реклама на Sphinx" Дмитрий Хасанов (...AvitoTech
C недавнего времени на Avito.ru появилась контекстная реклама. Миллионы объявлений, из которых нужно в режиме реального времени отобрать несколько релевантных для каждого отдельного пользователя.
Я расскажу о том, как и зачем мы используем миллионы коэффициентов при обработке каждого запроса, почему мы выбрали Sphinx и какие хитрости мы применили, чтобы уложиться в 100 миллисекунд.
В докладе рассматривается текущее состояние механизмов поиска и установки необходимых библиотек и утилит. Мы пробежим по общему определению менеджера пакетов и рассмотрим несколько распространенных примеров. Взглянем на типичные сценарии использования и на то, какие возможности были использованы в качестве критериев сравнения, а также составим представление о существующих решениях в мире С++ их конструктивных особенностях и примерах решаемых задач.
PostgreSQL: Un motor Impulsado por una comunidadSantiago Zarate
Una charla sobre PostgreSQL, La comunidad que se encuentra detras, paseo por algunas funcionalidades interesantes y finalmente recursos y donde encontrar mas informacion
Implementing the Future of PostgreSQL Clustering with TungstenCommand Prompt., Inc
Robert Hodges
Users have traditionally used database clusters to solve database availability and performance requirements. However, clustering requirements are changing as hardware improvements make performance concerns obsolete for many users. In this talk I will discuss how the Tungsten project uses master/slave replication, group communications, and rules processing to develop easy-to-manage database clusters that solve database availability, protect data, and address hardware utilization. Our implementation is based on existing PostgreSQL capabilities like Londiste and WAL shipping, which we eventually plan to replace with our own log-based replication. Come see the future of database clustering with Tungsten!
Joshua D. Drake
Are you tired of not having a real solution for PITR? Enter PITRTools, a single and secure solution for using Point In Time Recovery for PostgreSQL.
Bruce Momjian
Pg_Migrator allows data to be transfered between major Postgres versions
without a dump/restore. This talk explains the internal workings of
pg_migrator and includes a pg_migrator demonstration
Adrian Klaver
An exploration of various Python projects (PyRTF,ReportLab,xlwt) that help with presenting your data in formats (rtf,pdf,xls) that other people want. I will step through a simple data extraction and conversion process using the above software to create an RTF,PDF and XLS file respectively.
Rod Anderson
For the small business support person being able to provide PostgreSQL hosting for a small set of specific applications without having to build and support several Pg installations is necessary. By building a multi-tenant Pg cluster with one tenant per database and each application in it's own schema maintenance and support is much simpler. The issues that present themselves are how to provide and control dba and user access to the database and get the applications into their own schema. With this comes need to make logging in to the database (pg_hba.conf) as non-complex as possible.
Josh Berkus
Most users know that PostgreSQL has a 23-year development history. But did you know that Postgres code is used for over a dozen other database systems? Thanks to our liberal licensing, many companies and open source projects over the years have taken the Postgres or PostgreSQL code, changed it, added things to it, and/or merged it into something else. Illustra, Truviso, Aster, Greenplum, and others have seen the value of Postgres not just as a database but as some darned good code they could use. We'll explore the lineage of these forks, and go into the details of some of the more interesting ones.
Howdah - An Application using Pylons, PostgreSQL, Simpycity and ExceptableCommand Prompt., Inc
Aurynn Shaw
This mini-tutorial covers building a small application on Howdah, an open source, Python based web development framework by Commandprompt, Inc. We will cover the full process of designing a vertically coherent application on Howdah, integrating DB-level stored procedures, DB exception propagation through Exceptable, DB access through Simpycity, authentication through repoze.who, permissions through VerticallyChallenged, and application views through Pylons. By the end of the talk, we will have covered a full application built on The Stack, and how to cover common pitfalls in using Howdah components.
This presentation explores a broad cross-section of enterprise Postgres deployments to identify key usage patterns and reveals important aspects of performance, scalability, and availability including:
* Challenges organizations encounter most frequently during the stages of database development, deployment and maintenance
* Tuning parameters used most frequently to improve performance of production databases
* Frequently problematic database maintenance processes and configuration parameters
* Most commonly-used database back-up and recovery strategies
LIVE CD ́s - Linux con solo un CD...
“Y no tocas el Disco Duro! ! !“
Un Live CD es un sistema operativo funcional que estará ejecutándose directamente desde la unidad de /cdrom, en vez de tener la necesidad de estar instalado en el disco duro, crear particiones o llevar a cabo configuraciones que pudieran ser traumantes para un nuevo entusiasta GNU/LINUX.
Реализация восстановления после аварий / Сергей Бурладян (Avito)Ontico
Базы данных PostgreSQL занимают одно из центральных мест в Авито. Они являются разделяемой платформой, вокруг которой построено множество дополнительных сервисов. Одной из основных задач при их администрировании является задача восстановления после аварий как самих баз, так и связанной с ними инфраструктуры.
В своём докладе я постараюсь рассказать про:
+ общую схему связей баз данных между собой и с другими компонентами;
+ точки отказа и виды аварий, затрагиваемые связи;
+ бинарную репликацию и архив;
+ логическую репликацию, pgq, londiste, UNDO (REDO), пересоздание репки;
+ скрипт и процедуру переключения при аварии;
+ планы: развитие «восстановлений» по всем связям, автоматика на основе системы zookeeper (etcd и т.п.).
Moscow Exchange Test Automation of a Backup System at TMPA-2014 (Trading Syst...Iosif Itkin
Tools & Methods of Program Analysis (TMPA-2014)
Conference in Kostroma, November 14-15
Рассмотрена задача автоматизации тестирования программного комплекса с двухуровневым резервированием. Предложен подход на основе описания комплекса как системы конечных автоматов, тогда тестовые сценарии есть пути на графе переходов конечного автомата. На основе этого подхода создано инструментальное средство, позволяющее находить всевозможные пути графа (возможные сценарии осуществления переходов, порождающие управляющие bash-скрипты в операционной системе Linux). Предусмотрено исполнение порожденных скриптов в рамках инфраструктуры автоматизированного тестирования. Инструментальное средство позволяет проверить исправность работы системы резервирования
Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2854.html
Из этого доклада вы узнаете о возможностях репликации и автофейловера PostgreSQL, в том числе о возможностях, ставших доступных в PostgreSQL 10.
Среди прочих, будет затронуты следующие темы:
* Виды репликации и решаемые с ее помощью проблемы.
* Настройка потоковой репликации.
* Настройка логической репликации.
* Настройка автофейловера / HA средствами Stolon и Consul.
После прослушивания доклада вы сможете самостоятельно настраивать репликацию и автофейловер PostgreSQL.
#RuPostges в Yandex, эпизод 3. Что же нового в PostgreSQL 9.6Nikolay Samokhvalov
Первый релиз-кандидат версии 9.6 вышел 1 сентября, а это значит, что совсем скоро будет полноценный релиз. Все вокруг уже успели обсудить новинки, и теперь уже стыдно ничего не знать о таких вещах, как параллелизация выполнения запросов, pushdown для FDW, мониторинг waitlocks, полнотекстовый поиск по фразам или магический \gexec в psql. Чтобы никому не приходилось краснеть, мы быстро пройдёмся по всем основным и интересным моментам версии 9.6.
Эксперименты с 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-конвейер?
Промышленный подход к тюнингу PostgreSQL: эксперименты над базами данныхNikolay Samokhvalov
Shared_buffers = 25% – это много или мало? Или в самый раз? Как понять, подходит ли эта – довольно устаревшая – рекомендация в вашем конкретном случае?
Пришло время подойти к вопросу подбора параметров postgresql.conf "по-взрослому". Не с помощью слепых "автотюнеров" или устаревших советов из статей и блогов, а на основе:
строго выверенных экспериментов на БД, производимых автоматизированно, в больших количествах и в условиях, максимально приближенных к "боевым",
глубокого понимания особенностей работы СУБД и ОС.
Используя Nancy CLI (https://gitlab.com/postgres.ai/nancy), мы рассмотрим конкретный пример – пресловутые shared_buffers – в разных ситуациях, в разных проектах и попробуем разобраться, как же подобрать оптимальную настройку для нашей инфраструктуры, БД и нагрузки.
https://pgconf.ru/2019/242809
The Art of Database Experiments – PostgresConf Silicon Valley 2018 / San JoseNikolay 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.
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.
#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-запросыNikolay Samokhvalov
Онлайн-опросы неизменно показывают — всех нас очень интересуют две вещи: а) как писать наиболее эффективные SQL-запросы, б) как «читать» такие запросы, а точнее, как понимать, что именно делает или будет делать СУБД при их выполнении.
Эти две неразрывно связанные друг с другом темы чрезвычайно обширны, SQL-искусству можно (и нужно) учиться годами. Во время нашей очередной встречи в прямом эфире мы затронем некоторые аспекты обеих.
ЧАСТЬ 1: EXPLAIN
Алексей Ермаков. Как читать и интерпретировать вывод команды EXPLAIN
Команда EXPLAIN — основной инструмент анализа запросов, позволяющий разобраться, каким образом запрос будет выполняться и как можно его ускорить. Для сложных запросов вывод может быть довольно громоздким и его становится сложно читать. Я расскажу, из каких частей состоит план запроса, на какие «маркеры» в нём следует обращать внимание в первую очередь и как на это реагировать.
ЧАСТЬ 2: ADVANCED SQL
Николай Самохвалов. SQL современный и «продвинутый»
«Я не волшебник, я только учусь». Продвинутому SQL нас постоянно учат такие видные гуру как Markus Winand и Макс Богук. Рекурсивные CTE, LATERAL JOIN, виртуозная работа с массивами и строками, window functions и прочие модные штучки, которые помогут вам в дрессировке вашего Постгреса, — я постараюсь сделать хороший обзор, а если вдруг тема покажется интересной, то в следующих сеансах группового Постгреса мы обязательно пригласим настоящих гуру :)
Database First! О распространённых ошибках использования РСУБДNikolay Samokhvalov
Мы обсудим несколько фундаментальных ситуаций использования РСУБД (каждая из которых неоднократно встречалась автору), попутно разбирая возможные ошибки:
- элементарная модификация данных;
- работа с датой, временем и временными зонами;
- проверка ограничений целостности;
- очередь заданий;
- пакетная работа с данными (например, удаление пачки записей в таблице);
- полнотекстовый поиск;
- относительно новые задачи (создание API, machine learning).
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
Владимир Бородин: Как спать спокойно - 2015.10.14 PostgreSQLRussia.org meetu...Nikolay Samokhvalov
More: http://PostgreSQLRussia.org
Доклад посвящён резервному хранению СУБД PostgreSQL. Мы поговорим о том, как устроено хранение данных на диске и организован WAL в PostgreSQL, какие есть средства для резервного копирования и восстановления данных. Обсудим, как перестать беспокоиться за свои данные и почему PostgreSQL славится своей надёжностью.
#PostgreSQLRussia 2015.09.15 - Николай Самохвалов - 5 главных особенностей Po...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 Завершение встречи, свободное общение.
Максим Трегубов, CUSTIS. Миграция данных из Oracle в Postgres. Доклад о том, как мы для одного из заказчиков тестировали переход с СУБД Oracle на Postgres. Расскажем о выборе инструмента миграции данных, настройке тестовой среды и о полученных результатах. Также немного затронем модную тему DevOps и покажем роль Ansible в миграции данных.
Три вызова реляционным СУБД и новый PostgreSQL - #PostgreSQLRussia семинар по...Nikolay Samokhvalov
Реляционной модели скоро исполнится полвека – это огромный срок для любой технологической индустрии, не говоря уже об ИТ. За прошедшие годы этой модели было брошено немало вызовов, оказавших немалое влияние на развитие реляционных СУБД. В докладе обсуждаются три главных вызова реляционной модели, включая и NoSQL. На основе многолетнего опыта использования PostgreSQL для создания социальных сетей, объединяющих многомиллионные аудитории, наглядно демонстрируется как эта СУБД реагировала на возникающие вызовы. Речь также пойдет о «трех китах» PostgreSQL, которые не дают этой системе превратиться в монстра и позволяют обогащаться функционалом, необходимым для создания современных высоконагруженных проектов. Особое внимание в докладе уделено новым типам данных, JSON и JSONB — их возможностям, способам индексирования, а также разбору имеющихся недостатков.
2014.12.23 Николай Самохвалов, Ещё раз о JSON(b) в PostgreSQL 9.4Nikolay Samokhvalov
Тип данных JSONb – это, пожалуй, самая яркая новинка PostgreSQL 9.4, который вышел 18 декабря 2014.
Уже немало докладов и статей посвящено этому типу данных, работе с ним и индексации. Но как правило, информация в них перегружена специфичными для PostgreSQL терминами.
Запутались в моделях данных? В том, какие индексы могут вам помочь ускорить вашу работу с СУБД?
Этот доклад помогает сложить паттерн. Он для тех, кто начал использовать PostgreSQL совсем недавно или только планирует работать с ним. В нём рассказано о месте PostgreSQL в современном мире СУБД, о борьбе различных моделей данных за место под солнцем на этом рынке и то, как это отразилось на развитие Postgres.
Помимо прочего, рассказывается о том, какие вообще бывают деревья, как они помогают ускорять базы данных и почему PostgreSQL — просто райский лес для деревьев самого разного типа :)
См. также видео: http://postgresmen.ru/meetup/2014-12-23-parallels
Доклад от Parallels:
Методики тестировния производительности database-centric приложений
Описание: При работе над сложными продуктами в database-centric приложениях изменения в коде и тем более в SQL запросах к базе данных могут приводить к неожиданным падениям производительности или же деградации производительности приложения с ростом размера базы данных. Поэтому важно уметь как можно быстрее отлавливать и исправлять причины таких деградаций.
Доклад о том, как устроен процесс мониторинга производительности продукта автоматизации хостинга и облачных сервисов Parallels Automation, для которого определяющим фактором является производительность базы данных.
Компания покажет, как анализирует планы исполнения SQL запросов внутри PostgreSQL, как проверяет насколько быстро и эффективно в целом работают SQL запросы, как определяет стратегию дальнейшей оптимизации.