The document discusses using PostgreSQL in web applications and some of the challenges of increasing productivity, scalability, and reliability in web applications. It covers several topics related to optimizing PostgreSQL performance and configuration for web applications.
vSphere Launch Business Keynote - Москва, 26 маяAnton Antich
Keynote-презентация по vSphere и бизнес-преимуществам технологий виртуализации от VMware (автор - Антон Антич, глава представительства VMware Россия / СНГ)
vSphere Launch Business Keynote - Москва, 26 маяAnton Antich
Keynote-презентация по vSphere и бизнес-преимуществам технологий виртуализации от VMware (автор - Антон Антич, глава представительства VMware Россия / СНГ)
Java For Digitally Signing Documents In Web Book - Svetlin NakovSvetlin Nakov
Java For Digitally Signing Documents In Web Book
Freeware book by Svetlin Nakov
Java за цифрово подписване на документи в уеб – съдържание
Съдържание
Увод
Глава 1. Цифрови подписи и сертификати
1.1. Цифров подпис
1.1.1. Основни понятия
1.1.2. Технология на цифровия подпис
1.2. Цифрови сертификати и PKI
1.2.1. Модели на доверие между непознати страни
1.2.2. Цифрови сертификати и инфраструктура на публичния ключ
1.2.3. Хранилища за сертификати
1.2.4. Издаване и управление на цифрови сертификати
1.2.5. Анулирани сертификати
1.3. Технологии за цифрово подписване в уеб среда
1.3.1. Общи съображения при подписването в уеб среда
1.3.2. Цифров подпис в уеб браузъра на клиента
Глава 2. Цифрови подписи и сертификати в Java
2.1. Java Cryptography Architecture и Java Cryptography Extension
2.1.1. Основни класове за работа с цифрови подписи и сертификати
2.1.2. Директна верификация на сертификати с Java
2.1.3. Верификация на сертификационни вериги с Java
2.2. Достъп до смарт карти от Java
Глава 3. Проектиране на система за цифрово подписване в уеб среда
3.1. Архитектура на системата
3.2. Java аплет за подписване на документи
3.2.1. Подписани Java аплети
3.2.2. Връзка между Java аплет и уеб браузър
3.2.3. Проектиране на аплета за подписване
3.3. Уеб приложение за верификация на цифровия подпис и използвания сертификат
3.3.1. Система за верификация на цифровия подпис
3.3.2. Система за верификация на сертификати
3.3.3. Проектиране на уеб приложението
Глава 4. NakovDocumentSigner – система за подписване на документи в уеб среда
4.1. Рамкова система NakovDocumentSigner
4.2. Java аплет за подписване с PKCS#12 хранилище
4.3. Java аплет за подписване със смарт карта
4.4. Уеб приложение за верификация на цифровия подпис и сертификата на изпращача
Глава 5. Тестване, оценка и усъвършенстване
5.1. Поддържани платформи
Эксперименты с 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).
#RuPostges в Yandex, эпизод 3. Что же нового в PostgreSQL 9.6Nikolay Samokhvalov
Первый релиз-кандидат версии 9.6 вышел 1 сентября, а это значит, что совсем скоро будет полноценный релиз. Все вокруг уже успели обсудить новинки, и теперь уже стыдно ничего не знать о таких вещах, как параллелизация выполнения запросов, pushdown для FDW, мониторинг waitlocks, полнотекстовый поиск по фразам или магический \gexec в psql. Чтобы никому не приходилось краснеть, мы быстро пройдёмся по всем основным и интересным моментам версии 9.6.
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 запросы, как определяет стратегию дальнейшей оптимизации.
* приемы доступа к данным;
* прикладной класс работы с БД поверх PDO, особенности PDO;
* связки пуллов коннектов;
* API хранимых процедур;
* работа c распределенным хранилищем;
* RPC между базами на примере асинхронного геокодинга.
UiPath Test Automation using UiPath Test Suite series, part 6DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 6. In this session, we will cover Test Automation with generative AI and Open AI.
UiPath Test Automation with generative AI and Open AI webinar offers an in-depth exploration of leveraging cutting-edge technologies for test automation within the UiPath platform. Attendees will delve into the integration of generative AI, a test automation solution, with Open AI advanced natural language processing capabilities.
Throughout the session, participants will discover how this synergy empowers testers to automate repetitive tasks, enhance testing accuracy, and expedite the software testing life cycle. Topics covered include the seamless integration process, practical use cases, and the benefits of harnessing AI-driven automation for UiPath testing initiatives. By attending this webinar, testers, and automation professionals can gain valuable insights into harnessing the power of AI to optimize their test automation workflows within the UiPath ecosystem, ultimately driving efficiency and quality in software development processes.
What will you get from this session?
1. Insights into integrating generative AI.
2. Understanding how this integration enhances test automation within the UiPath platform
3. Practical demonstrations
4. Exploration of real-world use cases illustrating the benefits of AI-driven test automation for UiPath
Topics covered:
What is generative AI
Test Automation with generative AI and Open AI.
UiPath integration with generative AI
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Essentials of Automations: The Art of Triggers and Actions in FMESafe Software
In this second installment of our Essentials of Automations webinar series, we’ll explore the landscape of triggers and actions, guiding you through the nuances of authoring and adapting workspaces for seamless automations. Gain an understanding of the full spectrum of triggers and actions available in FME, empowering you to enhance your workspaces for efficient automation.
We’ll kick things off by showcasing the most commonly used event-based triggers, introducing you to various automation workflows like manual triggers, schedules, directory watchers, and more. Plus, see how these elements play out in real scenarios.
Whether you’re tweaking your current setup or building from the ground up, this session will arm you with the tools and insights needed to transform your FME usage into a powerhouse of productivity. Join us to discover effective strategies that simplify complex processes, enhancing your productivity and transforming your data management practices with FME. Let’s turn complexity into clarity and make your workspaces work wonders!
Maruthi Prithivirajan, Head of ASEAN & IN Solution Architecture, Neo4j
Get an inside look at the latest Neo4j innovations that enable relationship-driven intelligence at scale. Learn more about the newest cloud integrations and product enhancements that make Neo4j an essential choice for developers building apps with interconnected data and generative AI.
Sudheer Mechineni, Head of Application Frameworks, Standard Chartered Bank
Discover how Standard Chartered Bank harnessed the power of Neo4j to transform complex data access challenges into a dynamic, scalable graph database solution. This keynote will cover their journey from initial adoption to deploying a fully automated, enterprise-grade causal cluster, highlighting key strategies for modelling organisational changes and ensuring robust disaster recovery. Learn how these innovations have not only enhanced Standard Chartered Bank’s data infrastructure but also positioned them as pioneers in the banking sector’s adoption of graph technology.
How to Get CNIC Information System with Paksim Ga.pptxdanishmna97
Pakdata Cf is a groundbreaking system designed to streamline and facilitate access to CNIC information. This innovative platform leverages advanced technology to provide users with efficient and secure access to their CNIC details.
Enchancing adoption of Open Source Libraries. A case study on Albumentations.AIVladimir Iglovikov, Ph.D.
Presented by Vladimir Iglovikov:
- https://www.linkedin.com/in/iglovikov/
- https://x.com/viglovikov
- https://www.instagram.com/ternaus/
This presentation delves into the journey of Albumentations.ai, a highly successful open-source library for data augmentation.
Created out of a necessity for superior performance in Kaggle competitions, Albumentations has grown to become a widely used tool among data scientists and machine learning practitioners.
This case study covers various aspects, including:
People: The contributors and community that have supported Albumentations.
Metrics: The success indicators such as downloads, daily active users, GitHub stars, and financial contributions.
Challenges: The hurdles in monetizing open-source projects and measuring user engagement.
Development Practices: Best practices for creating, maintaining, and scaling open-source libraries, including code hygiene, CI/CD, and fast iteration.
Community Building: Strategies for making adoption easy, iterating quickly, and fostering a vibrant, engaged community.
Marketing: Both online and offline marketing tactics, focusing on real, impactful interactions and collaborations.
Mental Health: Maintaining balance and not feeling pressured by user demands.
Key insights include the importance of automation, making the adoption process seamless, and leveraging offline interactions for marketing. The presentation also emphasizes the need for continuous small improvements and building a friendly, inclusive community that contributes to the project's growth.
Vladimir Iglovikov brings his extensive experience as a Kaggle Grandmaster, ex-Staff ML Engineer at Lyft, sharing valuable lessons and practical advice for anyone looking to enhance the adoption of their open-source projects.
Explore more about Albumentations and join the community at:
GitHub: https://github.com/albumentations-team/albumentations
Website: https://albumentations.ai/
LinkedIn: https://www.linkedin.com/company/100504475
Twitter: https://x.com/albumentations
GraphSummit Singapore | The Art of the Possible with Graph - Q2 2024Neo4j
Neha Bajwa, Vice President of Product Marketing, Neo4j
Join us as we explore breakthrough innovations enabled by interconnected data and AI. Discover firsthand how organizations use relationships in data to uncover contextual insights and solve our most pressing challenges – from optimizing supply chains, detecting fraud, and improving customer experiences to accelerating drug discoveries.
In his public lecture, Christian Timmerer provides insights into the fascinating history of video streaming, starting from its humble beginnings before YouTube to the groundbreaking technologies that now dominate platforms like Netflix and ORF ON. Timmerer also presents provocative contributions of his own that have significantly influenced the industry. He concludes by looking at future challenges and invites the audience to join in a discussion.
Why You Should Replace Windows 11 with Nitrux Linux 3.5.0 for enhanced perfor...SOFTTECHHUB
The choice of an operating system plays a pivotal role in shaping our computing experience. For decades, Microsoft's Windows has dominated the market, offering a familiar and widely adopted platform for personal and professional use. However, as technological advancements continue to push the boundaries of innovation, alternative operating systems have emerged, challenging the status quo and offering users a fresh perspective on computing.
One such alternative that has garnered significant attention and acclaim is Nitrux Linux 3.5.0, a sleek, powerful, and user-friendly Linux distribution that promises to redefine the way we interact with our devices. With its focus on performance, security, and customization, Nitrux Linux presents a compelling case for those seeking to break free from the constraints of proprietary software and embrace the freedom and flexibility of open-source computing.
The Art of the Pitch: WordPress Relationships and SalesLaura Byrne
Clients don’t know what they don’t know. What web solutions are right for them? How does WordPress come into the picture? How do you make sure you understand scope and timeline? What do you do if sometime changes?
All these questions and more will be explored as we talk about matching clients’ needs with what your agency offers without pulling teeth or pulling your hair out. Practical tips, and strategies for successful relationship building that leads to closing the deal.
UiPath Test Automation using UiPath Test Suite series, part 5DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 5. In this session, we will cover CI/CD with devops.
Topics covered:
CI/CD with in UiPath
End-to-end overview of CI/CD pipeline with Azure devops
Speaker:
Lyndsey Byblow, Test Suite Sales Engineer @ UiPath, Inc.
Dr. Sean Tan, Head of Data Science, Changi Airport Group
Discover how Changi Airport Group (CAG) leverages graph technologies and generative AI to revolutionize their search capabilities. This session delves into the unique search needs of CAG’s diverse passengers and customers, showcasing how graph data structures enhance the accuracy and relevance of AI-generated search results, mitigating the risk of “hallucinations” and improving the overall customer journey.
Observability Concepts EVERY Developer Should Know -- DeveloperWeek Europe.pdfPaige Cruz
Monitoring and observability aren’t traditionally found in software curriculums and many of us cobble this knowledge together from whatever vendor or ecosystem we were first introduced to and whatever is a part of your current company’s observability stack.
While the dev and ops silo continues to crumble….many organizations still relegate monitoring & observability as the purview of ops, infra and SRE teams. This is a mistake - achieving a highly observable system requires collaboration up and down the stack.
I, a former op, would like to extend an invitation to all application developers to join the observability party will share these foundational concepts to build on:
Communications Mining Series - Zero to Hero - Session 1DianaGray10
This session provides introduction to UiPath Communication Mining, importance and platform overview. You will acquire a good understand of the phases in Communication Mining as we go over the platform with you. Topics covered:
• Communication Mining Overview
• Why is it important?
• How can it help today’s business and the benefits
• Phases in Communication Mining
• Demo on Platform overview
• Q/A
Alt. GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using ...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
Alt. GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using ...
20070613 Rit2007 Training
1. Использование PostgreSQL
в веб-приложениях
Проблемы повышения производительности,
масштабирования, надёжности веб-приложений
Николай Самохвалов
Иван Золотухин
компания Postgresmen
13 июня 2007, Москва, РИТ-2007
2. План действий
1000 Начало
1100 Перерыв (10 мин)
1200 Перерыв (10 мин)
1300 Обед (1 час)
1530 Кофе-брейк (30 мин)
1645 Перерыв (10 мин)
1800 Завершение программы
3. План работ
1. Вводная часть
2. Диагностика. Тестирование производительности. Мониторинг
3. Тюнинг (postgresql.conf, параметры OC)
4. Проблемы проектирования БД
5. Как найти медленные запросы?
6. Оптимизация запросов. EXPLAIN & EXPLAIN ANALYZE
7. Индексы. Специальные типы данных
8. Кэширование и СУБД
9. Отказоустойчивость и HA
10. Балансировка нагрузки. Масштабирование
11. Выбор железа
4. Что такое PostgreSQL?
PostgreSQL – свободно распространяемая
объектно-реляционная система управления
базами данных (ORDBMS), наиболее
развитая из открытых СУБД в мире и
являющаяся реальной альтернативой
коммерческим базам данных.
7. PostgreSQL сегодня
ISO/ANSI SQL (SQL:200x)
схемы, представления, триггеры, rules, 2PC...
Типы данных
varlena, массивы, GIS, композитные, GiST
Интерфейсы
C, C++, C#, python, perl, ruby, php, Lisp и т.д.
Процедурные языки
PL/pgSQL, pl/Tcl, Pl/Perl и pl/Python; PHP, Java, Ruby, R, shell
8. Кто использует
Sony Entertainment (EnterpriseDB)
Skype
Cisco
Fujitsu
NTT
Apple
SUN Microsystems (Solaris, 24x7 support)
hi5.com
UNISYS
9. Кто использует
SourceForge
LAMP: Linux/Apache/Middleware(Perl,PHP,Python,Ruby)/PostgreSQL
New Zealand's Electoral Enrolment Centre
.ORG, .INFO domain registry
Многотерабайтные архивы астрономических данных
10. Кто использует: Россия
Рамблер
1С:Предприятие (наряду с MS SQL)
irr.ru («Из рук в руки»)
rabota.ru («Работа для вас»)
price.ru
moikrug.ru (Яндекс)
webalta.ru
РБК
Beeline
Мастерхост
neznakomka.ru
12. Аспекты производительности
Транзакц
Приложение
Запросы
ии
Драйвер Соедине
Middleware Кэш
а ния
PostgreSQL
Схема Конфиг
Файл. Операционная система
Ядро
система
RAM/CP
Железо
Диски Сеть
U
13. Аспекты производительности
Транзакц
Приложение
Запросы
ии
Драйвер Соедине
Middleware Кэш
а ния
PostgreSQL
Схема Конфиг
Файл. Операционная система
Ядро
система
RAM/CP
Железо
Диски Сеть
U
14. Правила оптимизации
Большинство проблем PostgreSQL на самом
деле не являются проблемами PostgreSQL
10% проблем порождают 90% ухудшения
производительности (the hockey stick)
Как правило, при оптимизации видна только
крупнейшая проблема
17. Устройство PostgreSQL
ACID-совместимая база данных
− atomicity (атомарность)
− consistency (непротиворечивость)
− isolation (изоляция)
− durability (надежность)
18. Устройство PostgreSQL
ACID-совместимая база данных
уровни изоляции транзакций:
− Read Uncommited
− Read Commited (разумный компромисс)
− Repeatable read
− Serializable (надежно, но медленно)
Вывод: забудьте про SET TRANSACTION, если вы
не в банке
19. Устройство PostgreSQL
MVCC: Multiversion Concurrency Control
− xid – transaction id
− каждая запись имеет xid_start и xid_end
− каждая транзакция видит версию базы в момент
xid_start
− записи не удаляются, а просто помечаются
xid_end
20. Устройство PostgreSQL
MVCC – накапливаются старые версии
данных
требует пылесоса – VACUUM
VACUUM: re-use мертвых данных
VACUUM FULL: физическое удаление
мертвых данных и дефрагментация базы
Autovacuum – ваш друг
21. Устройство PostgreSQL
WAL – Write Ahead Log
механизм протоколирования всех
транзакций
позволяет восстановить систему после
возможных сбоев
все изменения данных записываются на
диск только после их гарантированного
журналирования в WAL
PITR – Point In Time Recovery
24. Диагностика проблем
Средства операционной системы
Тесты производительности (benchmarks)
Средства PostgreSQL: логи, статистика
Системы внешнего мониторинга
25. Средства операционной системы
ps
Возможность увидеть PostgreSQL-процессы
− Понимание конкуретной работы с CPU и RAM
− Возможность заметить долгие запросы
26. Средства операционной системы
mpstat
Просмотр активности каждого CPU
− Используются ли все процессоры?
− Является ли CPU узким местом?
− Диагностика context switches
27. Средства операционной системы
vmstat, free
Просмотр использования памяти
− Оценка размеров дискового кэша
− Хватает ли серверу PostgreSQL памяти?
− Не происходит ли swapping-а?
28. Средства операционной системы
iostat
Просмотр дисковой активности
− Сервер достиг предела по I/O?
− Все ли диски выдают ожидаемый I/O?
− Мониторинг checkpoint-ов
29. Тесты производительности
(benchmarks)
bonnie++
Тест дисковой подсистемы
− Измерьте производительность дисков
− Знайте скорость Sequential/Random Read/Write и
Random Seek своих дисков
30. Тесты производительности
(benchmarks)
contrib/pgbench
Простейший тест базы данных
− Тестирует I/O и скорость соединений
− Не тестирует: блокировки, вычислительные
задачи, планирование запросов
− Удобен для обнаружения больших HW+OS
проблем, мало пригоден для тонкой настройки
Тестируйте систему, подобную вашей
− База в shared_buffers
− База в дисковом кэше
− База не помещается в RAM
32. Средства PostgreSQL
pg_stat_database,
pg_database_size()
Вы должны знать общие параметры БД:
Количество соединений
Количество транзакций
Количество commit-ов и rollback-ов
Количество hit-ов (попаданий в буфер)
Размер базы данных (помещается в RAM?)
33. Средства PostgreSQL
pg_tables, pg_relation_size()
Вы должны знать общие параметры таблиц:
Количество таблиц
Размеры таблиц
Размеры индексов
Количество триггеров
«Вздутие» таблиц (bloating)
34. Средства PostgreSQL
pg_stat_activity, pg_locks
Детали конкурентного доступа к таблицам
Оценка количества idle-соединений
Runtime-оценка долгих запросов
Лучше, чем ps – больше деталей
Все ли нормально с блокировками? Нет ли WAITING-
бакендов?
35. Средства PostgreSQL
pg_stat[io]_user_tables,
pg_stat[io]_user_indexes
Статистика доступа к таблицам
Количество SELECT/INSERT/UPDATE/DELETE
Количество seqscan vs. indexscan
Есть ли неиспользуемые индексы? Drop it!
Есть seqscan-ы по большим таблицам? CREATE
INDEX
36. Средства PostgreSQL
pg_stat_bgwriter
− Можно видеть, как bgwriter чистит кэш
− Помогает при затруднении проходимости
checkpoint-ов
37. Системы внешнего мониторинга
PgFouine (анализ логов)
Zabbix
− Легко расширяется
Nagios
− Готовое расширение для PostgreSQL
pgsnmpd – SNMP-агент для PostgreSQL
38. Системы внешнего мониторинга
Примеры запросов для мониторинга:
select datname,now()-query_start as duration,current_query from
pg_stat_activity;
select datname, case when blks_read = 0 then 0 else blks_hit /
blks_read end as ratio from pg_stat_database;
select relname,seq_scan,idx_scan, case when idx_scan = 0 then 100
else seq_scan / idx_scan end as ratio from pg_stat_user_tables
order by ratio desc;
select relname,n_tup_ins,n_tup_upd,n_tup_del from pg_stat_user_tables
order by n_tup_upd desc;
select indexrelname,idx_tup_read,idx_tup_fetch,case when
idx_tup_fetch = 0 then 100 else idx_tup_read / idx_tup_fetch end as
ratio from pg_stat_user_indexes order by ratio desc;
select relname,n_tup_ins,n_tup_upd,n_tup_del from pg_stat_user_tables
order by n_tup_upd desc;
select l.mode,d.datname,c.relname,l.granted,l.transactionid from
pg_locks as l left join pg_database as d on l.database= d.oid left
join pg_class as c on l.relation = c.oid;
39. postgresql.conf
shared_buffers = 25 ÷ 35% RAM
Размер разделяемой памяти
work_mem = free / max_nconn * 1 ÷ 3
Неразделяемая память для сортировок,
аггрегирования, вычисления хэш-функций.
malloc до нескольких раз за соединение
effective_cache_size = 2/3 * RAM
Средний размер дискового кеша
checkpoint_timeout = 600 ÷ 900 sec
Макс. время между WAL chekpoint-ами
41. postgresql.conf
checkpoint_segments = 3 ÷ 10
Макс. время между WAL checkpoint-ами, в WAL-
сегментах размером 16MB
commit_delay, commit_siblings
Задержка и сброс нескольких активных
транзакций в WAL одним вызовом fsync
maintenance_work_mem = 75% от
pg_relation_size('the_biggest_table')
Размер памяти для VACUUM, ANALYZE, CREATE
INDEX
42. postgresql.conf
max_fsm_pages = (n измененных рядов)
Количество дисковых страниц, используемых для
Free Space Map. Правильная настройка может
отменить необходимость в VACUUM FULL и
REINDEX.
random_page_cost = 2.0 ÷ 4.0
Оценка времени случайного доступа (пробег по
индексу). 2.0 в случае быстрых дисков, 4.0 в
случае, если БД не помещается в RAM
wal_buffers = default
Размер буфера WAL в разделяемой памяти,
важен для больших транзакций. Забудьте это.
43. postgresql.conf
log_destination = 'syslog'
redirect_stderr = off
silent_mode = on
log_min_duration_statement = 500
log_duration = off
log_statement = 'none'
Настройки для логгирования через syslog
запросов, медленнее 500ms (pgFouine)
44. postgresql.conf
stats_command_string = on
update_process_title = on
stats_start_collector = on
stats_block_level = on
stats_row_level = on
Настройки для сбора row-level статистики.
Ухудшают производительность на ~5%, но
дают возможность работы с
вышеуказанными сиcтемными
представлениями и необходимы для
autovacuum
45. postgresql.conf
autovacuum = on
Автовакуум
autovacuum_naptime = 1 ÷ 10 min
Время между последовательными
автоматическими запусками автовакуума
autovacuum_vacuum_threshold,
autovacuum_analyze_threshold = 250 ÷
1000
Пороги по количеству измененных рядов для
запуска VACUUM или ANALYZE на конкретную
таблицу
46. postgresql.conf
vacuum_cost_delay = 50 ÷ 250 ms
Откладывание VACUUM на данное время
vacuum_cost_limit = 100 ÷ 200
Откладывание VACUUM при достижении данной
стоимости операций
vacuum_page_hit = 1 ÷ 10
Условная стоимость одной из основных операций
VACUUM
48. Bgwriter & shared buffers
bgwriter_delay = 50 ÷ 200 ms
Пауза между циклами bgwriter-а
bgwriter_lru_percent = 1.0 ÷ 5.0
Предел на сканирование LRU-буферов / цикл
bgwriter_all_percent = 0.3 ÷ 1.0
Предел на сканирование всех буферов / цикл
bgwriter_lru_maxpages = 5 ÷ 20
Количество LRU-буферов, записанное на диск /
цикл
bgwriter_all_maxpages = 5 ÷ 20
49. Производительность PostgreSQL
Диски > RAM > CPU
Чем больше дисков, тем лучше
Отделяйте pg_xlog от данных
RAID 1+0 / 0+1 > RAID 5
Не ставьте на сервер другие приложения
51. Денормализация
Производные атрибуты
Одна «широкая» таблица лучше нескольких «узких»
Как правило, TOAST (varlena types) работает хорошо
Теперь есть не только GiST, но и GIN!
Медленный count(): хранение «счётчиков»
Процесс денормализации – компромисс между производительностью и
гибкостью
message
person message_id
SERIAL
person_id SERIAL message_subject
person_name VARCHAR(32)
VARCHAR(64) message_body
person_email VARCHAR(255) VARCHAR(2000)
?
person_age INT2 message_from_person_id INT4
message_to_person_id INT4
message_from_person_name VARCHAR(64)
message_to_person_name
VARCHAR(64)
52. Медленный count()
Хранение «счётчиков» (дополнительные
поля, триггеры)
Оценочные методы
CREATE FUNCTION count_estimate(query text) RETURNS integer AS $$
DECLARE
rec record;
rows integer;
BEGIN
FOR rec IN EXECUTE 'EXPLAIN ' || query LOOP
rows := substring(rec.quot;QUERY PLANquot; FROM ' rows=([[:digit:]]+)');
EXIT WHEN rows IS NOT NULL;
END LOOP;
RETURN rows;
END;
$$ LANGUAGE plpgsql VOLATILE STRICT;
SELECT count_estimate('SELECT * FROM foo WHERE r < 0.1');
Автор: Michael Fuhr
53. Логическое секционирование
Вертикальное
− Разделение данных по таблицам, схемам, базам (хостам)
Горизонтальное
Наследование, constraint exclusion:
CREATE TABLE obj (
obj_id INTEGER,
obj_created TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP
);
CREATE TABLE person(
obj_id INTEGER PRIMARY KEY,
person_name VARCHAR(32) NOT NULL,
CHECK(obj_id >= 1000000000 AND obj_id < 2000000000)
) INHERITS(obj);
CREATE TABLE car(
obj_id INTEGER PRIMARY KEY,
obj_type_id INT2 NOT NULL DEFAULT 2,
car_model VARCHAR(16) NOT NULL,
CHECK(obj_id >= 2000000000 AND obj_id < 3000000000)
) INHERITS(obj);
SET constraint_exclusion TO on;
54. Физическое секционирование
Вертикальное
− Разделение по дискам
symlinks
tablespaces
партицирование таблиц + tablespaces
− Разделение по хостам
после логического секционирования (напр., Logging DB)
contrib/dblink
55. Физическое секционирование
Горизонтальное
− По дискам: партицирование таблиц + tablespaces
CREATE TABLE obj ...
CREATE TABLE obj_a(
obj_id INTEGER PRIMARY KEY,
obj_type_id INT2 NOT NULL DEFAULT 2,
CHECK(obj_id >= 2000000000 AND obj_id < 3000000000)
) INHERITS(obj) TABLESPACE space1;
CREATE RULE ...
ON INSERT TO obj WHERE ...
DO INSTEAD INSERT INTO obj_a ...;
SET constraint_exclusion TO on;
− По хостам (по базам): pl/proxy
58. Оптимизация запросов
Минимизация количества запросов (один «большой» SQL-
запрос лучше серии «маленьких») – выигрыш до 80%
− 2-6 мс на каждый запрос => несколько «лишних» секунд для
1000 строк!
Объединение запросов в одну транзакцию – выигрыш до 50%
− не всегда лучший выбор для web-приложений!
Минимизация объёмов данных (включая промежуточные)
− минимизация проекции (перечисление столбцов)
− минимизация выборки (WHERE)
− учёт мощности множеств (кардинальность и
селективность каждой из таблиц)
59. Оптимизация запросов
Минимизация медленных count()
Минимизация количества операций DELETE
− UPDATE
− TRUNCATE TABLE
Массивные (bulk) операции вместо группы row-level
операций
− один UPDATE вместо цикла UPDATE-ов
− COPY вместо группы INSERT-ов
Для массивных операций:
− ALTER TABLE ... DISABLE TRIGGER ALL
− DROP INDEX ... / ... / CREATE INDEX ...
Подготовленные запросы (PREPARE ...)
60. Обработка запроса в PostgreSQL
Parser (синтаксический анализатор)
Planner (выбор оптимального пути)
Executor (непосредственное выполнение)
SQL – декларативный язык. СУБД решает, как
именно будет выполняться запрос.
61. EXPLAIN
План запроса – дерево
Узлы – действия
− соединения (join)
− сортировка
− просмотр таблицы
Выполнение происходит от листьев к корню
Оценка «ширины» данных, количества строк
и стоимости
Это только оценка, реальную стоимость
покажет EXPLAIN ANALYZE
62. Пример EXPLAIN
test=# explain select * from pg_proc order by proname;
QUERY PLAN
-------------------------------------------------------------
Sort (cost=191.67..197.08 rows=2166 width=299)
Sort Key: proname
-> Seq Scan on pg_proc (cost=0.00..71.66 rows=2166
width=299)
(3 rows)
63. EXPLAIN: width
test=# explain select * from pg_proc order by proname;
QUERY PLAN
-------------------------------------------------------------
Sort (cost=191.67..197.08 rows=2166 width=299)
Sort Key: proname
-> Seq Scan on pg_proc (cost=0.00..71.66 rows=2166
width=299)
(3 rows)
«Ширины» типов данных
Показывает примерное
среднее количество байт int2 2
int4 4
в одной строке int8 8
результата boolean 1
varchar(n) / char(n) n+4
timestamp / timestamptz 8
64. EXPLAIN: rows
test=# explain select * from pg_proc order by proname;
QUERY PLAN
-------------------------------------------------------------
Sort (cost=191.67..197.08 rows=2166 width=299)
Sort Key: proname
-> Seq Scan on pg_proc (cost=0.00..71.66 rows=2166
width=299)
(3 rows)
Показывает примерное количество строк результата (в
т.ч., промежуточного)
Большое отклонение от реальности => необходим
VACUUM & ANALYZE!
Можно использовать для вывода примерного
количества строк результата конечному пользователю
65. EXPLAIN: cost
test=# explain select * from pg_proc order by proname;
QUERY PLAN
-------------------------------------------------------------
Sort (cost=191.67..197.08 rows=2166 width=299)
Sort Key: proname
-> Seq Scan on pg_proc (cost=0.00..71.66 rows=2166
width=299)
(3 rows)
Абстрактная величина (ввода-вывода, CPU)
Именно это даёт возможность планнеру выбрать один
план из нескольких
2 значения: startup & total
Это всего лишь оценка!
66. EXPLAIN ANALYZE
test=# explain analyze select * from pg_proc order by
proname;
QUERY PLAN
-------------------------------------------------------------
Sort (cost=191.67..197.08 rows=2166 width=299) (actual
time=30.161..34.990 rows=2166 loops=1)
Sort Key: proname
Sort Method: quicksort Memory: 639kB
-> Seq Scan on pg_proc (cost=0.00..71.66 rows=2166
width=299) (actual time=2.094..20.232 rows=2166 loops=1)
Total runtime: 40.192 ms
(5 rows)
Фактическая информация
Время в миллисекундах
Добавляется общее время запроса
loops – количество «проходов» (необходимо умножить
время на loops, чтобы получить общее время)
67. EXPLAIN ANALYZE
Способы просмотра таблицы
− Seq Scan
− Index Scan
Способы подготовки данных
− Sort
− Hash
Способы соединения (join)
− Nested Loop
− Merge Join
− Hash Join
68. Общие рекомендации
Сбор статистики, мониторинг, анализ логов (pgFouine)
Итерационное выявление медленных запросов
Иногда стоит перестроить запрос, а не создать N
новых индексов
Следить за кардинальностью и селективностью
промежуточных результатов (SELECT * FROM a, b)
Потенциальные источники проблем: LEFT JOIN,
count(), UNION вместо UNION ALL, DISTINCT, WHERE
... IN (...), соединение 100 таблиц, неожиданное
«выпрямление» запросов с подзапросами
Не забывать об ANALYZE после массивных
изменений!
69. Общие рекомендации
Ещё раз: при решении проблемы, убедитесь в том, что
вам не нужны VACUUM & ANALYZE
Запускайте EXPLAIN ANALYZE не менее двух раз (не
забываем про кэш)
Читайте план снизу вверх, ищите, где начинаются
замедления и/или ошибки планнера
При возможности, используйте реальные данные в
тестировании (Slony?) и оборудование, приближенное
к production
Обращайтесь за помощью: pgsql-performance, IRC,
sql.ru, коммерческая поддержка
70. Управление планнером
enable_seqscan
enable_indexscan
enable_sort
enable_nestloop
enable_hashjoin
enable_mergejoin
enable_hashagg
Как правило, помогает при разработке, но вредит на
«боевых» серверах (другие объёмы данных => другая
статистика)
72. Индексы в PostgreSQL
B-tree
Hash
R-tree – теперь тоже GiST
GiST (обобщенное поисковое дерево)
GIN (обратный индекс)
Фёдор Сигаев, Олег Бартунов
73. Индексы в PostgreSQL
Не забываем о таких «приятных» вещах как:
− Частичные индексы (CREATE INDEX ... WHERE ...)
− Функциональные индексы (CREATE INDEX ... USING
btree(myfunc(a)))
уникальные функциональные индексы
индексирование данных экзотических типов (XML, array, ...)
− Многоколоночные индексы
следим за правильным порядком столбцов
избегаем ненужных одноколоночных индексов
− GIN-индексы для массивов
− CLUSTER table USING indexname
74. Индексы в PostgreSQL
Настройка и обслуживание
− CREATE INDEX ... FILLFACTOR
− CREATE INDEX ... CONCURRENT
− Необходимость в перестроении индексов (read/fetch ratio):
select
indexrelname,idx_tup_read,idx_tup_fetch,case
when idx_tup_fetch = 0 then 100 else
idx_tup_read / idx_tup_fetch end as ratio from
pg_stat_user_indexes order by ratio desc;
83. Кэширование и СУБД
Кэширование на уровне СУБД (и ОС):
− файловый кэш ОС (!)
− shared_buffers
− кэширование планов запросов
не забываем указывать признак IMMUTABLE/STABLE/VOLATILE у
функций
минимизация количества динамического SQL
Кэширование на уровне приложения:
− кэширование результатов запросов (файлы, memcached, shared memory)
основные справочники
объекты
метаданные базы данных
− кэширование страниц
на сервере (memcached, proxy-server)
на стороне клиента (правильные HTTP-заголовки)
95. Pgpool-II
Балансировка нагрузки
Master/Slave режим -- работа вместе с другой
системой репликации: Slony-I, WAL, ...
Параллельное выполнение запросов
Нет ограничений на число узлов кластера
(как было в pgpool-I)
Кэш запросов
GUI
Линейная масштабируемость на «dblink»-
запросах
97. Slony-I
Master to multiple slaves
Самая известная репликация для
PostgreSQL
Асинхронная система
Десятки слейвов
Каскады реплицируемых серверов
99. PgCluster
Синхронный мультимастер
Балансировка нагрузки
Высокодоступная (HA) система
Cluster DBs, Load Balancer, Replicator
Для ленивых: решение от Cybertec,
Austria
100. WAL shipping
Асинхронная система
Встроена в PostgreSQL
Hot backup
Нельзя читать со слейвов
walmgr.py
Скоро read queries!
106. Правильный выбор железа
Диски
− SCSI лучше, чем SATA
− Чем больше дисков, тем лучше: 12 SATA лучше
4 SCSI
− Чем быстрее диски, тем лучше: 15K RPM = 250
оборотов в сек = 250 TPS
107. Правильный выбор железа
RAID контроллер
− Очень важный элемент
− Только не Adaptec!
− Уж лучше software RAID
− Хорошие отзывы о MegaRAID, 3ware
− Включайте write cache только если есть BBC
− Чем больше памяти на контроллере, тем лучше
109. Правильный выбор железа
RAID 0
− Stripe
− 2 диска минимум
− Нет отказоустойчивости
− Отличный I/O
− Простое устройство и
обслуживание
110. Правильный выбор железа
RAID 1
− Mirror
− 2 диска минимум
− Отказоустойчивость
(1 диск)
− Выигрыш в скорости
чтения, небольшая
деградация в скорости
записи
111. Правильный выбор железа
RAID 5
− Striped set with
distributed parity
− 3 диска минимум
− Отказоустойчивость
(1 диск)
− Медленная запись
− Чтение чуть медленнее
RAID 0
112. Правильный выбор железа
RAID 6
− Striped set with Dual
distributed parity
− 4 диска минимум
− Отказоустойчивость
(2 диска)
− Медленная запись
− Чтение чуть медленнее
RAID 0 на том же
количестве дисков
113. Правильный выбор железа
RAID 0+1
− Отказоустойчивость
(выдерживает отказ
только 1 диска)
− Требует полного
rebuild-а при отказе
диска
114. Правильный выбор железа
RAID 1+0
− Отказоустойчивость
(n*RAID1 дисков
может отказать)
− При отказе диска –
только rebuild его
зеркала
− Оптимальная
конфигурация для 4
дисков
117. Правильный выбор железа
Всегда тестируйте дисковую подсистему
− time quot;dd if=/dev/zero of=bigfile bs=8k
count=RAM*2 && syncquot;
− time dd if=bigfile of=/dev/null bs=8k
− bonnie++ (de-facto стандарт дисковых тестов)
Обычный 7200 RPM диск:
− 56MB/s чтение
− 42MB/s запись
− Линейный рост по числу дисков в RAID 0
118. Настройки файловой системы
Ext3 & AnyOtherJournalingFS
− noatime: не обновлять last access timestamp
− writeback на диске с WAL: только целостность
метаданных, нет коммита самих данных в
журнал
OtherFS
− Журналируйте в разумных масштабах
− Компрессия rocks!
− ZFS rocks!
119. Правильный выбор железа
CPU
− Чем больше ядер,
тем лучше (Linux)
− Opteron-ы считаются
лучше Xeon-ов