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

Меня зовут Олег, и в Яндексе мы с командой занимаемся Python-обвязкой вокруг нашей базы данных YDB. Python знаменит «батарейками в комплекте», широким ассортиментом библиотек на все случаи жизни, включая богатую экосистему для работы с базами данных. Есть свой интерфейс DBAPI (PEP-249), несколько конкурирующих ORM и многочисленные уровни абстракции между софтом и базами. В этой статье — о том, как мы делали полноценную интеграцию нашей базы данных с Apache Superset: чтобы достаточно было выбрать YDB из выпадающего меню и начать визуализировать аналитические данные.

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

Меня зовут Максим Коновалов, я архитектор Tarantool в VK Tech. В этой статье я расскажу, зачем и как мы уходили от Lua и что получили в итоге.

Каждый, кто работает с PostgreSQL, знает его символ — синего слона. Но задумывались ли вы, откуда он взялся? Его история — это не результат работы дорогого брендингового агентства, а захватывающее повествование о зарождении IT-сообщества, питерских энтузиастах, случайных файлах и том, как «маленький презент» стал мировым символом.

Привет, Хабр! Последние несколько лет я занимаюсь разработкой баз данных ВКонтакте. Аудитория такой крупной соцсети ежедневно генерирует огромные массивы информации. 

В этой статье я расскажу про хранилище ВКонтакте: как оно менялось, что мы делаем для оптимизации занятого места и как гарантируем сохранность данных.

Supabase с оценкой в $2 млрд стремительно становится технологическим фундаментом современного вайб-кодинга. Почему разработчики массово переходят на этот бэкенд с открытым исходным кодом, и как PostgreSQL-решение превратилось в незаменимый инструмент для AI-приложений, используемый в 29% стартапов последнего набора Y Combinator? История компании, чья ценность оказалась настолько высокой, что инвестор пролетел 17 часов до отдалённого уголка Новой Зеландии для встречи с её основателем.

В 2017 году мы рассказывали о том, как спроектировали нашу систему поиска сообщений так, чтобы она могла индексировать миллиарды сообщений. Благодаря этому наша поисковая инфраструктура стала высокопроизводительной, экономной, масштабируемой и простой в использовании. Мы решили выбрать Elasticsearch, в котором сообщения Discord шардились по индексам и использовалось логическое пространство имён для сообщений Elasticsearch в двух кластерах Elasticsearch. Сообщения шардились или по серверу Discord (который ниже будем называть гильдией) или по личным сообщениям (DM). Это позволило нам хранить все сообщения гильдии рядом для обеспечения высокой скорости запросов и работать с маленькими, более удобными кластерами. Так как поиском пользуются не все, сообщения индексировались лениво, и мы создали очередь сообщений, позволявшую воркерам получать блоки сообщений для индексирования, чтобы воспользоваться возможностями массового индексирования (bulk-indexing) Elasticsearch.

Но с ростом объёмов Discord наша поисковая инфраструктура начала трещать по швам…‍

Представьте знакомую ситуацию: утро понедельника, задачи сыпятся одна за другой. Перед вами задача срочно развернуть новый сервис на базе Postgres Pro. Или, возможно, в эти выходные вы обновили железо своего сервера базы данных, увеличили количество CPU и объём RAM. Расскажем, как быстро привести СУБД в состояние, оптимально подходящее новому оборудованию и текущим нагрузкам.

Опыт автоматизации финучета в небольшой IT-команде — честно, с мемами и фейлами. Как ушли от Excel, почему сначала все пошло не по плану, что сэкономили, где накосячили и зачем все-таки это сделали. Без волшебных кнопок, но с выводами, которые помогут другим не наступить на те же грабли.

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

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

Сразу отмечу, что решения и оценки, о которых пойдёт речь, подбирались для работы с большими данными на стеке технологий Apache Hadoop, где для обработки данных использовали фреймворк Apache Spark, СУБД — Apache Hive для анализа данных, оркестратор — Airflow, данные хранятся в колоночном формате Parquet.

Значения восьми параметров конфигурации мастера (primary, ведущего сервера PostgreSQL) сохраняются в управляющих файлах и изменения их значений передаются через журнал (WAL) на реплики. Если реплика открыта для запросов (hot_standby=on), то значения пяти числовых параметров на реплике должны быть не меньше, чем на мастере, иначе процесс startup прекратит накат (replay) журнальных записей. А после рестарта экземпляры реплик не запустятся. В статье рассматриваются эти параметры особенности изменения их значений.

Значения пяти числовых параметров конфигурации, сохраненных в управляющем файле кластера, можно посмотреть утилитой pg_controldata:

TL;DR

Хотите отслеживать трафик на статическом блоге без Matomo и Google Analytics?
Рассказываю, как с помощью OpenTelemetry, Prometheus, Grafana и небольшого самописного скрипта на JS (Otela) можно элегантно и эффективно следить за посещаемостью — при этом полностью сохранив контроль над своими данными.

Привет, Хабр!

Сегодня поговорим про одну из тех тем, что вроде бы тривиальна, но до последней капли грязи тащит за собой внушительный пласт вопросов. Речь пойдёт про COUNT(*) и COUNT(col) в PostgreSQL.

Представьте, что вы — гид в огромном городе под названием «Базы Данных». Ваша задача — помочь Java-приложениям найти нужную информацию, обновить данные или создать новые таблицы. Но как «разговаривать» с разными СУБД, если у каждой свой язык? Здесь на помощь приходит JDBC — универсальный переводчик, который знает все диалекты.  

Я занимаюсь разработкой баз данных с 1999 года и сейчас работаю над YDB — базой данных, которую мы в Яндексе недавно выложили в опенсорс. Это моя шестая база данных и четвертая — массивно-параллельная. И каждый раз, когда основные задачи решены, я сажусь разрабатывать оптимизатор запросов. Под катом я кратко расскажу о том, что такое оптимизаторы запросов в базах данных и почему их непросто делать.

В статье рассматривается использование теста TPC-H с PostgreSQL и проблемы, связанные с запросами Q17-Q20 теста.

Введение

Вместе с PostgreSQL поставляется утилит pg_bench с "TPC-B like" тестом. Кроме этого теста были созданы тесты TPC-R для отчётов, TPC-D для OLAP, TPC-W для заказов в веб-магазине, которые не получили распространения. На основе TPC-D был создан более удачный тест TPC-H для хранилищ данных и аналитических запросов ("OLAP нагрузка"). В тесте используется 8 таблиц и 17 ограничений целостности. В TPC-H выделены номинации по размерам обрабатываемых данных от "до 100Гб" до  30-100Тб. Тест TPC-H предназначен для хранилищ данных, включает в себя 22 запроса, которые называют Q1 ... Q22.

Запросы теста TPC-H не меняют данные в таблицах, а значит, для повторных тестирований не нужно пересоздавать или вакуумировать таблицы. В тестах TPC-B, TPC-C, TPC-E запросы довольно простые. В реальных приложениях запросы более сложные, чем в этих тестах. Поэтому для тестирования того, как СУБД выполняет запросы, которые могут встретиться в реальных приложениях, можно использовать все или отдельные запросы из теста TPC-H. Для быстрого аудита производительности различных СУБД используют вариант с 1Гб данных. В этом варианте запросы выполняются быстро, не нужно много памяти под экземпляр СУБД и много места на диске. Можно найти программы или скрипты для большинства СУБД, например, для PostgreSQL, Oracle Database, MySQL. После теста TPC-H появился тест TPC-DS с 99 запросами, но он менее популярен.

Я уже не раз поднимал в статьях тему [не]эффективной работы с json[b] в PostgreSQL — и как его лучше превращать в выборку, и как можно «транспонировать». Сегодня же рассмотрим некоторые возможности по его генерации на стороне базы.

Давно не было обстоятельных интервью, тем более с таким корифеем отечественной СУБД‑разработки. В 2022 году в Postgres Professional перешла команда специалистов по Oracle, включая Марка Ривкина, который занял позицию руководителя отдела технического консалтинга. Вместе с командой он занялся адаптацией продуктов под требования крупных корпоративных заказчиков и доработкой функциональности Postgres Pro — в первую очередь для тех, кто планирует миграцию с проприетарных СУБД.

В интервью для Хабра Марк рассказал, с какими задачами столкнулись на старте, какие функции пришлось внедрять в первую очередь, как выстроена работа с разработкой и сообществом, и в чём сегодня Postgres Pro реально может заменить Oracle, а в чём — пока нет. Поговорили и про ИИ в администрировании, и про перспективы российских форков PostgreSQL, и даже о том, что бы он заложил в архитектуру, если бы проектировал СУБД с нуля. Приятного чтения!

В статье визуализируется структура индекса и показывается, как меняется структура индекса типа btree в PostgreSQL. Это полезно для понимания, как выглядят индексы btree. Также рассматривается FILLFACTOR и пример исследования структуры индекса в целях определения, как перераспределяются индексные записи при включении в структуру индекса новых блоков (страниц). Создадим простую таблицу, индекс, вставим три строки:

Хочу поделиться с сообществом свой наработкой по мониторингу бэкапов PostgreSQL.

Для того чтобы делать сами бэкапы, используется сторонний open source инструмент pg_probackup (разработка компании Postgres Professional).

Этот инструмент умеет делать инкрементные бэкапы, а также автоматизирует сопутствующие процессы, такие как, сжатие данных, merge, удаление старых бэкапов и wal-файлов.

Остается проблема мониторинга. Предположим, мы настроили pg_probackup и он трудится упорно, вызываемый регулярно через cron.

Как мы узнаем, о том, что что-то сломалось?

Для решения этой проблемы был написан небольшой экспортер метрик pg_probackup для Prometheus.

Для тех, кто устал от «зоопарка» решений по созданию отказоустойчивых кластеров, расскажем, как добиться нужной функциональности одним решением. BiHA позволяет данным «выжить», даже если один из ЦОДов был физически уничтожен. Как же мы этого добились?