Базы данных

На докладе мы в деталях разберём примеры проблем с производительностью PostgreSQL, которые безусловно будут интересны как администраторам баз данных, так и разработчикам систем. Например, настроить checkpointer и как bgwriter помогает (или не помогает) с этим? Что за магический SLRU cache и каким он станет в PostgreSQL 17? Почему может блокироваться таблица, если код приложения этого не делал? Приходите на доклад со своими вопросами, будет что обсудить в дискуссии.

Город спит, даже не догадываясь, как мужественно администраторы баз данных ради всеобщего блага сражаются за ускорение выполнения запросов на каждую милисекунду.

Используем встроенные инструменты PostgreSQL, чтобы

• вычислять неоптимальные запросы,

• избегать проблем с ними в будущем

• и даже принимать решения на ходу, без остановки их выполнения.

Когда речь заходит про multi-master режим работы СУБД, у многих разработчиков и архитекторов она часто вызывает эмоции от неприятия до практически презрения. Кто-то не уверен в стабильности такого решения, кто-то в его производительности. Если к этому добавляется необходимость разместить серверы в разных географических локациях, градус сомнения сразу умножается на 10. Между тем существуют сервисы, использующие СУБД именно в этом режиме. Мы в компании Базис-Центр создаём именно такие сервисы и я готов поделиться своим опытом сборки и эксплуатации MySQL кластера в multi-master режиме, рассказать каким инструментарием мы для этого пользуемся.

1. Выбор архитектуры и построение кластера

Определение требований к масштабируемости и отказоустойчивости.

Выбор между кластеризацией в активном и пассивном режиме.

Разработка стратегии распределения данных и узлов.

2. Выбор между бесплатной и коммерческой версией СУБД

Оценка функциональных возможностей и ограничений бесплатной версии.

Сравнение уровня поддержки и документации.

Учет общих затрат на лицензии и поддержку.

3. Миграция данных

Планирование миграции для минимизации простоев.

Выбор инструментов для миграции и их настройка.

Проведение тестов миграции на небольших объемах данных.

4. Тестирование производительности

Определение ключевых метрик производительности для тестирования.

Использование инструментов для профилирования и мониторинга.

Проведение стресс-тестов и анализа узких мест.

Начнем с истории эволюции хранилищ данных к состоянию Data Lakehouse.

Объясню, почему мы выбрали Ozone, и с какими трудностями столкнулись при внедрении.

Поделюсь решёнными проблемами и тем, которые ещё предстоит решить.

Завершу тем как мы взаимодействуем с Apache Foundation и прогнозом будущего Ozone после завершения эпохи Hadoop.

Как и на чем лучше строить систему, которая должна работать с пространственными данными?

Современные СУБД позволяют хранить и обрабатывать цифровую информацию о местности, но в чем они значительно уступают геоинформационным системам?

А в чем современные ГИС не дотягивают до возможностей СУБД?

Рассмотрим эти смежные и во многом пересекающиеся технологии, и то, как взять лучшее из обоих.

Поделюсь опытом разумных компромиссов БД и ГИС, которые мы успешно применяем в своих решениях.

Аннотация:

- Доклад о том, как в PostgreSQL работают "обычные индексы". Доклад будет крайне полезен как тем, кто начинает работать с базами данных, так и тем, кто работал, но подзабыл. Если доклад попадёт в золотые подборки "обязательно посмотреть на on-boarding'е разработчика", то цель достигнута.

В докладе рассмотрим:

- Как индекс ускоряет поиск

- Нужно ли индексировать условия where

- Нужно ли индексировать условия в order by

- Нужно ли индексировать внешние ключи (foreign keys)

- Что делать, если критериев поиска несколько

- В каком порядке указывать колонки в индексе

- Случаи, когда индекс замедляет работу, и как снизить влияние индекса на приложение