Администрирование баз данных *

Сравниваем использование IN, EXISTS и JOIN для нахождения вхождений и рассматриваем их планы выполнения для разных ситуаций.

Друзья, как будто мы пропустили интересное и важное событие! В декабре 2024 года Сальваторе Санфилиппо - автор Redis - спустя 4 с половиной года отсутствия в проекте возвращается к своему детищу.

Для меня редис - это по-прежнему простой и эффективный элемент разрабатываемых систем. Возможно еще и поэтому я с большим интересном и даже удовольствием прочитал пост antirez-а о возвращении. Под катом взгляд Сальваторе на проблемы лицензирования, раскол в сообществе редис, нейронные сети и LLM, векторный поиск и, конечно, дальнейшие планы по работе над Redis и всё, что с этим связано.

Вышел Postgres Pro Enterprise 17, и этот релиз принесёт улучшения в области производительности и масштабирования. Одно из ключевых нововведений — расширение Proxima, объединяющее функции пулера, прокси и балансировщика нагрузки, интегрированное непосредственно в ядро СУБД. Кроме того, разработчиков ждут новые возможности управления очередями сообщений, инструменты оптимизации запросов, средства обеспечения безопасности и функции интеллектуального хранения данных.

Продолжаем посты на тему технических интервью. Новый пост, который мы позаимствовали у автора Дилана Смита, будет для джунов по специальностям «Системный аналитик», «Backend‑разработчик» и «Fullstack‑разработчик». Иногда такой вопрос также попадается на интервью архитекторам и инженерам баз данных. Ответ на вопрос из заголовка может быть как очень коротким, где всего четыре пункта, так и развернутым — включая примеры кода и диаграммы. Естественно, мы рассмотрим тему во всех подробностях.

Однажды поздним воскресным вечером ничто не предвещало неприятностей, пока не поступило сообщение о проблемах с репликацией в продуктовом кластере ClickHouse. В статье поделились опытом восстановления сервиса после сбоя и разобрали  репликацию материализованных представлений.

Редко можно встретить технологии, которые существуют более пятидесяти лет в стремительно меняющейся ИТ-индустрии. Пока одни разработки быстро теряют актуальность, базы данных продолжают играть ключевую роль. По мере увеличения объёмов данных растёт и потребность в инструментах для их обработки, управления и анализа. 

Первая СУБД, основанная на иерархическом подходе, была разработана ещё в 1960-х годах. В 1970-х появились реляционные системы, которые и сегодня остаются востребованными благодаря своей универсальности и эффективности.  

Сегодня обсудим, каким был путь развития СУБД.

Вам нужно интегрировать несколько компонентов без помощи менеджеров транзакций с поддержкой ACID (атомарность, согласованность, изоляция и долговечность)? Тогда этот пост для вас.

Я сначала кратко объясню, что такое менеджеры транзакций и почему вы можете не иметь их под рукой в современных архитектурах. Затем я опишу решение, как работать без менеджеров транзакций в целом, а также рассмотрю проект, который я знаю лучше всего, как конкретный пример: движок процессов Camunda.

В современном мире данных нагрузка на базы данных стремительно растёт. Когда один сервер перестаёт справляться с объёмом запросов, встаёт вопрос о масштабировании: как эффективно распределить нагрузку, сохранив высокую производительность и доступность?

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

Администраторы баз данных часто ломают голову над тем, чтобы выявить самые «прожорливые» процессы, из-за которых страдает быстродействие систем. В далеком 2017-м DBA (а теперь инженер Postgres Professional) Андрей Зубков тоже задавался этим вопросом, а в результате придумал утилиту pg_profile для PostgreSQL, которая сейчас «проросла» в pgpro_pwr.

В этой статье мы расскажем о стратегическом мониторинге БД и научим выявлять узкие места в ваших БД с помощью наших утилит.

Greengage Database — наш форк Greenplum Database. Основная идея — оставить исходный код открытым и продолжить разработку и совершенствование базы данных. Мы собираемся перенести Greengage Database на более новую версию Postgres, предоставив более богатый набор функций всем пользователям сообщества и нашим клиентам.

Но эта задача сложнее, чем может показаться. Ранее для реализации функций массивно-параллельных вычислений Greenplum Database основная функциональность Postgres была существенно переработана. Таким образом, обновление версии Postgres создавало огромные сложности. Например, переход с Postgres 9 на Postgres 12 потребовал огромных усилий — между мажорными релизами было почти 5 лет разработки.

Имея это в виду, мы начали масштабный рефакторинг ядра Greengage Database. Мы собираемся разделить ядро ​​Postgres и специфичные функции Greengage Database, используя стандартные существующие средства Postgres для расширений.

Необходимость переноса данных из одной среды в другую — задача, с которой разработчики сталкиваются достаточно часто. Например, для отправки таблиц из прода в среды для тестирования. Вместе с тем, такая «перезаливка» таблиц нередко превращается в настоящий квест, по ходу которого нужно не только гарантировать сохранность данных, но и исключить ошибки, связанные с человеческим фактором. Поэтому лучшей практикой является автоматизация переноса.

Меня зовут Евгений Грибков. Я ведущий программист в центре технологий VK. В этой статье мы рассмотрим одно из возможных решений создания скрипта перезаливки заданных таблиц из одной БД в другую на примере MS SQL.

В обзоре узнаете, как графический интерфейс PG Back Web значительно облегчает управление резервными копиями PostgreSQL. Мы покажем, как настраивать резервные копии всего за несколько кликов.

Привет! Меня зовут Геннадий, я Oracle и PostgreSQL DBA в компании Uzum. По пути еще иногда занимаюсь NoSQL, люблю автоматизировать информацию из Ansible и визуализировать нужные мне метрики в Grafana. Хочу поделиться дашбордом для Grafana, который отображает историю активных сессий PG с их текущим SQL, отсортированных по группам ожиданий. Он помогает мне искать проблемы производительности PG-баз, и может пригодиться тем, кто администрирует Postgres.

Так как я активно использую возможности Flyway, такие как repeatable migrations и callbacks, и не хочу от них отказываться, а аналогов этих функций в других системах миграции нет, я решил написать собственный лёгкий клон Flyway на Node.js для PostgreSQL.

1. SQLite — самая часто разворачиваемая и используемая база данных. На текущий момент активно используется более одного триллиона (1000000000000 или миллиона миллионов) баз данных SQLite.
   
   Её поддерживают три человека. Они не допускают внешних контрибьюторов.
   

«Как ускорить выполнение запросов к базам данных?» — извечный вопрос админов и пользователей. Казалось бы, раньше всё работало неплохо, но стоило клиентской базе вырасти в пять раз, как всё замедлилось. Знакомая ситуация? В этой статье расскажем, как найти запросы, которые можно ускорить, и оптимизировать их.

Статья подготовлена по материалам выступления на конференции PGCONF.СПБ 2024.

В этой статье я хотел бы рассказать о задаче, решение которой легло в основу моей дипломной работы. На момент ноября 2023 года я был студентом Физтеха — учился на базовой кафедре Яндекса, программа обучения которой реализуется совместно с ШАДом. Задача заключалась в переводе парсера языка запросов YQL (диалект SQL для YDB и YTsaurus) с ANTLR3 на ANTLR4. Мой наставник в ШАД и руководитель команды разработки клиентских библиотек YDB в Яндексе к. т. н. Алексей Мясников @asmyasnikovотметил еёе как особо сложную. Но меня это не отпугнуло:, тема работы из всех тем, предложенных в ШАД, эта показалась самой интересной и близкой мне.

Как сравнить? - измерить execution-time конечно! - скажет опытный читатель. И будет совершенно прав: с практической точки зрения эффективнее та СУБД, которая выдаёт больший TPS. Однако иногда нам требуется спроектировать систему, которой ещё нет или сделать прогноз поведения на нагрузках, которые ещё не пришли. В таком случае нам нужна некоторая характеристика, позволяющая выполнить качественный анализ плана или выполнить сравнение пары планов. Обсуждению одной такой характеристики - количество прочитанных страниц данных - и посвящён данный пост.

Сегодня я рад представить новый масштабный проект, в рамках которого мы подробно рассмотрим технологии и подходы, ранее не освещенные в моих статьях.

На этот раз мы создадим телеграм-бота с MiniApp (ранее известным как WebApp) — это будет бот с интегрированным мини-сайтом прямо в Telegram. Для реализации проекта мы используем два основных фреймворка:

1. FastAPI — мощный Python-фреймворк, который мы задействуем для разработки API нашего телеграм-бота. Мы рассмотрим уникальный подход, позволяющий создать полноценный бэкенд, который будет закрывать как API-методы, так и функционал телеграм-бота.

2. Vue.js 3 — JavaScript-фреймворк, выбранный за его удобство разработки и возможности создания сложных визуальных элементов.

В этой статье мы сосредоточимся на описании бэкенда, а создание приложения на Vue.js 3 будет вынесено на следующую статью.