В апреле на RailsConf в Фениксе мы обсудили огромное количество советов по использованию Postgres с Rails, и подумали, что будет полезно их записать и поделиться с более широкой аудиторией. Здесь вы найдете некоторые из них, касающиеся отладки и улучшения производительности базы данных вашего Rails приложения.
Рубрика «postgres» - 10
Советы по Postgres для Rails разработчиков
2017-06-10 в 18:46, admin, рубрики: active record, activerecord, postgres, postgresql, ruby on rails, Блог компании okmeter.ioИндексы в PostgreSQL — 3
2017-05-29 в 6:48, admin, рубрики: index, indexing, postgres, postgresql, sql, Блог компании Postgres ProfessionalВ первой статье мы рассмотрели механизм индексирования PostgreSQL, во второй — интерфейс методов доступа, и теперь готовы к разговору о конкретных типах индексов. Начнем с хеш-индекса.
Hash
Устройство
Общая теория
Многие современные языки программирования включают хеш-таблицы в качестве базового типа данных. Внешне это выглядит, как обычный массив, но в качестве индекса используется не целое число, а любой тип данных (например, строка). Хеш-индекс в PostgreSQL устроен похожим образом. Как это работает?
Как правило, типы данных имеют очень большие диапазоны допустимых значений: сколько различных строк можно теоретически представить в столбце типа text? В то же время, сколько разных значений реально хранится в текстовом столбце какой-нибудь таблицы? Обычно не так много.
Идея хеширования состоит в том, чтобы значению любого типа данных сопоставить некоторое небольшое число (от 0 до N−1, всего N значений). Такое сопоставление называют хеш-функцией. Полученное число можно использовать как индекс обычного массива, куда и складывать ссылки на строки таблицы (TID). Элементы такого массива называют корзинами хеш-таблицы — в одной корзине могут лежать несколько TID-ов, если одно и то же проиндексированное значение встречается в разных строках.
Хеш-функция тем лучше, чем равномернее она распределяет исходные значения по корзинам. Но даже хорошая функция будет иногда давать одинаковый результат для разных входных значений — это называется коллизией. Так что в одной корзине могут оказаться TID-ы, соответствующие разным ключам, и поэтому полученные из индекса TID-ы необходимо перепроверять.
Читать полностью »
Как пропатчить KDE под FreeBSD или, что ждать от мастер-классов на DevCon School 1 июня
2017-05-24 в 10:19, admin, рубрики: azure service fabric, DevCon School, docker, java, kubernetes, Malmo, Microsoft Azure, minecraft, postgres, ssdl, Visual Studio, visual studio team services, VSTS, Блог компании Microsoft, Программирование, рефакторингС 2011 по 2016 включительно мы делали крутую конференцию DevCon в загородном формате на 2 дня. И каждый раз, в комментариях в анкетах нам просили больше рассказов про проекты реальных заказчиков, больше практикичеких работ!
И мы придумали и реализовали DevCon School: бесплатное для участников мероприяите с гдубоким погружением. Несмотря на свою сравнительно короткую исторю это название стало брендом и неким знаком качества. Нас просят провоидть их ещё и ещё. Особое моесто занимают большие DevCon School, которые мы проводим два раза в год. В отличие от обычных, в них есть нескольоко тем, а самое главное, есть возможность выбрать, каким именно образом с эими темами знакомиться: интенсивы или мастер-классы.
Итак, посмотрим, что же нам готовят 12 мастер-классов доступных 1 июня на DevCon School: Технологии будущего, которая пройдёт в Digital October.
Читать полностью »
Ускоряем восстановление бэкапов в Postgres. Часть вторая (потому что сокращения времени вдвое недостаточно)
2017-05-10 в 5:48, admin, рубрики: devops, pg_dump, pg_restore, postgres, Администрирование баз данных, Блог компании Southbridge, Серверная оптимизация, Серверное администрирование, системное администрирование
В первой части статьи «Ускоряем восстановление бэкапов в Postgres» я рассказал о предпринятых шагах по уменьшению времени восстановления в локальном окружении. Мы начали с простого: pg_dump-пили (а есть ли такое слово?), паковали gzip-ом, распаковывали и направляли вывод в psql < file.sql
. На восстановление уходило около 30 минут. В итоге мы остановились на настраиваемом (custom) формате Postgres и применили аргумент -j
, добившись уменьшения времени до 16 минут.
В этой статье я описал, как нам удалось уменьшить размер файла резервной копии, что дополнительно ускорило процедуру восстановления.
Индексы в PostgreSQL — 2
2017-05-10 в 5:34, admin, рубрики: index, indexing, postgres, postgresql, sql, Блог компании Postgres ProfessionalИнтерфейс
В первой части мы говорили о том, что метод доступа должен предоставлять информацию о себе. Посмотрим, как устроен этот интерфейс.
Свойства
Все свойства методов доступа представлены в таблице pg_am (am — access method). Из этой таблицы можно получить и сам список доступных методов:
postgres=# select amname from pg_am;
amname
--------
btree
hash
gist
gin
spgist
brin
(6 rows)
Хотя к методам доступа можно с полным правом отнести и последовательное сканирование, исторически сложилось так, что оно отсутствует в этом списке.
В версиях PostgreSQL 9.5 и более старых каждое свойство было представлено отдельным полем таблицы pg_am. Начиная с версии 9.6 свойства опрашиваются специальными функциями и разделены на несколько уровней:
- свойства метода доступа — pg_indexam_has_property,
- свойства конкретного индекса — pg_index_has_property,
- свойства отдельных столбцов индекса — pg_index_column_has_property.
Разделение на уровни метода доступа и индекса сделано с прицелом на будущее: в настоящее время все индексы, созданные на основе одного метода доступа, всегда будут иметь одинаковые свойства.
Docker контейнер с данными на Postgres для интеграционного тестирования и лёгким расширением
2017-05-08 в 20:47, admin, рубрики: container, containerization, containers, containment, devops, devops (*nix), docker, dockerfile, integration testing, postgres, postgresql, виртуализация, системное администрированиеПро использование Docker
и Docker-compose
последнее время написано очень много, например рекомендую недавнюю статью на Хабре, если вы до сих пор не прониклись. Это действительно очень удобно, а в связке в ansible особенно. И я его использую везде. От разработки, до автоматического интеграционного тестирования на CI
. Про использование в тестировании, тоже писали. Это здорово и удобно. Однако, для локальной разработки, для траблешутинга данных "как в продакшене" или тестирование производительности, на "объёмах близких в продакшену", хочется иметь под рукой образ, содержащий базу, "как в продакшене"!
Соответственно, хочется, чтобы каждый разработчик, приступая к работе над проектом, мог запустить его одной командой, например:
./gradlew dockerRun
и приложение поднялось бы сразу со всеми необходимыми связанными контейнерами? А главное чтобы в нём уже были бы данные для большинства кейсов разработки и багфиксинга, стандартные пользователи и большинство работающих сервисов, над которыми сразу можно было бы приступить работать, не тратя времени на экспорт-импорт каких-то там образов или демоданных!
Как приятный бонус, ну разве не здорово иметь базу данных в несколько гигабайт и возможность откатиться к её исходному (или любому другому коммиту) состоянию в течении пары секунд?
Разумеется мы поговорим о написании Dockerfile
для такого образа с данными, и некоторых подводных камнях этого процесса.
Ускоряем восстановление бэкапов в PostgreSQL
2017-05-05 в 9:00, admin, рубрики: devops, pg_dump, pg_restore, postgres, Администрирование баз данных, Блог компании Southbridge, Серверная оптимизация, Серверное администрирование, системное администрирование
Мои ощущения от процесса работы
Недавно я решил заняться ускорением восстановления нашей базы данных в dev-окружении. Как и во многих других проектах, база вначале была небольшой, но со временем значительно выросла. Когда мы начинали, ее размер было всего несколько мегабайт. Теперь упакованная база занимает почти 2 ГБ (несжатая — 30 ГБ ). Мы восстанавливаем dev-окружение в среднем раз в неделю. Старый способ проведения операции перестал нас устраивать, а вовремя подвернувшаяся в Slack-канале картинка “DB restore foos?” побудила меня к действию.
Ниже описано, как я ускорял операцию восстановления базы данных.
Индексы в PostgreSQL — 1
2017-04-19 в 7:52, admin, рубрики: index, indexing, postgres, postgresql, sql, Блог компании Postgres ProfessionalПредисловие
В этой серии статей речь пойдет об индексах в PostgreSQL.
Любой вопрос можно рассматривать с разных точек зрения. Мы будем говорить о том, что должно интересовать прикладного разработчика, использующего СУБД: какие индексы существуют, почему в PostgreSQL их так много разных, и как их использовать для ускорения запросов. Пожалуй, тему можно было бы раскрыть и меньшим числом слов, но мы в тайне надеемся на любознательного разработчика, которому также интересны и подробности внутреннего устройства, тем более, что понимание таких подробностей позволяет не только прислушиваться к чужому мнению, но и делать собственные выводы.
За скобками обсуждения останутся вопросы разработки новых типов индексов. Это требует знания языка Си и относится скорее к компетенции системного программиста, а не прикладного разработчика. По этой же причине мы практически не будем рассматривать программные интерфейсы, а остановимся только на том, что имеет значение для использования уже готовых к употреблению индексов.
В этой части мы поговорим про разделение сфер ответственности между общим механизмом индексирования, относящимся к ядру СУБД, и отдельными методами индексного доступа, которые в PostgreSQL можно добавлять как расширения. В следующей части мы рассмотрим интерфейс метода доступа и такие важные понятия, как классы и семейства операторов. После такого длинного, но необходимого введения мы подробно рассмотрим устройство и применение различных типов индексов: Hash, B-tree, GiST, SP-GiST, GIN и RUM, BRIN, Bloom.
Индексы
Индексы в PostgreSQL — специальные объекты базы данных, предназначенные в основном для ускорения доступа к данным. Это вспомогательные структуры: любой индекс можно удалить и восстановить заново по информации в таблице. Иногда приходится слышать, что СУБД может работать и без индексов, просто медленно. Однако это не так, ведь индексы служат также для поддержки некоторых ограничений целостности.
Аудит изменения данных PostgreSQL
2017-03-10 в 9:00, admin, рубрики: logger, plpgsql, postgres, postgresql, sql
Возникла необходимость вести аудит изменения данных в существующей системе.
Требования:
- Простота подключения/отключения логгирования отдельных таблиц.
- Сократить до минимума изменения в уже существующих функциях БД.
- Минимизировать деградацию производительности.
Uber — причины перехода с Postgres на MySQL
2017-03-07 в 7:41, admin, рубрики: database, mysql, mysql migration, open source, postgres, postgresql, sql, uber, uber data, Блог компании centos-admin.ru
В конце июля 2016 года в корпоративном блоге Uber появилась поистине историческая статья о причинах перехода компании с PostgreSQL на MySQL. С тех пор в жарких обсуждениях этого материала было сломано немало копий, аргументы Uber были тщательно препарированы, компанию обвинили в предвзятости, технической неграмотности, неспособности эффективно взаимодействовать с сообществом и других смертных грехах, при этом по горячим следам в Postgres было внесено несколько изменений, призванных решить некоторые из описанных проблем. Список последствий на этом не заканчивается, и его можно продолжать еще очень долго.
Наверное, не будет преувеличением сказать, что за последние несколько лет это было одно из самых громких и резонансных событий, связанных с СУБД PostgreSQL, которую мы, к слову сказать, очень любим и широко используем. Эта ситуация наверняка пошла на пользу не только упомянутым системам, но и движению Free and Open Source в целом. При этом, к сожалению, русского перевода статьи так и не появилось. Ввиду значимости события, а также подробного и интересного с технической точки зрения изложения материала, в котором в стиле Postgres vs MySQL идет сравнение физической структуры данных на диске, организации первичных и вторичных индексов, репликации, MVCC, обновлений и поддержки большого количества соединений, мы решили восполнить этот пробел и сделать перевод оригинальной статьи. Результат вы можете найти под катом.