Настраивая postgresql.conf, Вы могли заметить, что там есть параметр full_page_writes. Имеющийся рядом с ним комментарий гласит что-то о частичной записи страниц и люди, как правило, оставляют его в состоянии on — что не плохо, это я и объясню далее в данной статье. Тем не менее, очень полезно понимать что full_page_writes делает, так как влияние на работы системы может быть значительным.

В отличие от моего прошлого поста про настройку чекпоинтов, этот не является пособием о том, как надо настраивать сервер. Здесь не так много всего того, что Вы могли бы настроить, на самом деле, но я покажу Вам как некоторые решения на уровне приложения (к примеру, выбор типов данных) могут взаимодействовать с записью полных страниц.

---

Трансляция первого дня от 7 ноября окончена. 8 ноября в 09:45 Мск продолжение видео на странице спецпроекта и текстовой трансляции в новом посте и на странице спецпроекта.

---

Сегодня в этом посте весь день будет вестись текстовая трансляция конференции HighLoad++ 2016, проходящей в Сколково 7 и 8 ноября. HighLoad++ — это более 200 экспертов высочайшего класса с докладами о высоконагруженных сервисах, проблемах работы с ними и вопросах администрирования. Более 15 залов, плотный график, честный и полезный опыт спикеров — HighLoad++ умеет собирать крутые темы, задавать тон дискуссии и всё на одном дыхании.

Если вы хотите смотреть видео из главного зала и включения из мобильной студии Хабрахабра, то вам на страницу спецпроекта. Если почитать онлайн и поообщаться в кооментариях — под кат.

Так получилось, что я начал работать с PostgreSQL три года назад и за это время умудрился методично собрать все возможные грабли, которые можно вообразить. И сказать по правде, если бы была возможность поделиться с собой трехлетней давности нынешним горьким опытом, моя жизнь была бы куда проще и нервные клетки целее. Именно поэтому я решил написать абсолютно субъективную статью со сводом правил, которых придерживаюсь при разработке на PostgreSQL. Возможно, кому-то эта статья поможет обойти собранные мной грабли (и наступить на другие, ха-ха!).

Олег Царёв ( zabivator )

Есть мастер, мастер неожиданно упал, но система продолжает работать. Клиенты мигрируют на вторую базу. Нужно делать резервные копии базы. Если делать резервные копии на основной базе, мы можем получить какие-то проблемы производительности, увеличение времени отклика. Это плохо. Поэтому достаточно распространенный пример асинхронной репликации — это снятие резервной копии со слэйва. Другой пример — это миграция тяжелых запросов с мастера на слэйв, с основной базы на вторую. Например, построение отчетов.

Иногда бывает необходимо, чтобы приложение могло получать все обновления из базы и желательно в режиме реального времени. Этим занимается оpen source библиотека, которая называется libslave.

Константин Осипов ( kostja ), Алексей Рыбак ( fisher )

Константин Осипов: Доклад родился из следующего разговора. Я, как всегда, пытался убедить Алексея больше использовать Tarantool, а он сказал, что там до сих пор нет шардинга и, вообще, неинтересно. Тогда мы стали рассуждать о том, почему нет. Я стал рассказывать, что тут нет одного универсального решения, автоматика полная за вас работает, а вы только кофе на работе пьете и все…

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

Сравнение схем двух или более различных баз данных Postgres является распространенной задачей, но она может стать более каверзной, если эти базы работают на разных версиях Postgres'а. Быстрым и каноническим способом сравнить схемы является использование одной и той же программы pg_dump для взаимодействия с каждой базой со --schema-only параметром. Этот метод работает великолепно, но имеются некоторые подводные камни, особенно при копировании представлений.


(Фото сделано Philippe Vieux-Jeanton)

Недавно на хабре уже было опубликовано описание интеграции PostgreSQL и MSSQL. Но, деталей там категорически не хватало. Посему, цели сей публикации следующие:

• расширить и углубить общедоступную информацию о FDW для MSSQL называемом tds_fdw: рассказать о разнице в мажорных версиях и описать базовые проблемы совместимости;
• рассказать о возможностях оптимизации запросов, использующих внешние таблицы;
• затронуть тему кэширования внешних данных в материализованных представлениях;
• сказать пару слов об экзотических подходах к интеграции PostgreSQL и MSSQL.

Олег Бартунов (zen), Александр Коротков (smagen), Федор Сигаев

Илья Космодемьянский: Сейчас будет самая животрепещущая тема по PostgreSQL. Все годы, что мы занимаемся консалтингом, первое, что спрашивают люди: «Как сделать мультимастер-репликацию, как добиться волшебства?». Много профессиональных волшебников будут рассказывать о том, как это сейчас хорошо и здорово реализовано в PostgreSQL — ребята из Postgres Professional в рамках этого доклада расскажут про кластер все. Название соответствующее — «Сага» — что-то эпическое и монументальное. Сейчас ребята из Postgres Professional начнут свою сагу, и это будет интересно и хорошо.

Итак, Олег Бартунов, Александр Коротков и Федор Сигаев.

В последние два месяца лета в управлении хранилищ данных (Data Warehouse, DWH) Тинькофф Банка появилась новая тема для кухонных споров.

Всё это время мы проводили масштабное тестирование нескольких in-memory СУБД. Любой разговор с администраторами DWH в это время можно было начать с фразы «Ну как, кто лидирует?», и не прогадать. В ответ люди получали длинную и очень эмоциональную тираду о сложностях тестирования, премудростях общения с доселе неизвестными вендорами и недостатках отдельных испытуемых.

Подробности, результаты и некое подобие выводов из тестирования — под катом.

Всем привет! Только что выложили бету DBGlass PostgreSQL GUI клиент. Стандартные функции клиента — просмотр и редактирование данных.

К сожалению мы не являемся специалистами в области баз данных и PostgreSQL, явно упустили важный функционал или особенности работы базы. Будем рады фидбэку или пулл реквестам.

Для тех, кто не знаком с интерфейсом гитхаба, скачать бинарники можно тут.

Недавно мы выложили на GitHub ZSON. ZSON — это расширение к PostgreSQL для прозрачного сжатия JSONB-документов. Сжатие осуществляется путем выделения строк, наиболее часто встречающихся в ваших документах, и построения словаря с этими строками. Притом строки могут быть не только ключами документа, но и значениями или, например, строками из вложенных массивов. В некоторых случаях ZSON позволяет уменьшить размер базы до двух раз и увеличить количество транзакций в секунду на 10%. В shared buffers документы хранятся в сжатом виде, за счет чего память тоже экономится.

Интересно? Читайте дальше, и вы узнаете, как пользоваться всем этим хозяйством на практике.

Здравствуй, Хабр! Мы начинаем блог об Idea Platform — платформе для автоматизации бизнес-процессов.

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

Мы сами и наши партнеры успешно применяем платформу для автоматизации самых разных бизнес-процессов в маленьких и больших компаниях (в том числе масштаба всей страны).
Сейчас мы хотим рассказать о платформе Хабр-сообществу, чтобы еще больше разработчиков могли использовать Idea Platform в своих проектах.

Целостность данных легко нарушить. Бывает так, что в поле price попадает значение 0 из-за ошибки в коде приложения (периодически всплывают новости, как в том или ином инет-магазине продавали товары по 0 долларов). Или бывает, что удалили юзера из таблицы, но какие-то данные о нем остались в других таблицах, и эти данные вылезли в каком-то интерфейсе.

PostgreSQL, как и любая другая СУБД, умеет делать некоторые проверки при вставке/изменении данных, и этим обязательно нужно уметь пользоваться. Давайте посмотрим, что мы можем проверять:

1. Кастомный подтип через ключевое слово DOMAIN

В 2008 году в списке рассылки pgsql-hackers началось обсуждение расширения по сбору статистики по запросам. Начиная с версии 8.4 расширение pg_stat_statements входит в состав постгреса и позволяет получать различную статистику о запросах, которые обрабатывает сервер.

Обычно это расширение используется администраторами баз данных в качестве источника данных для отчетов (эти данные на самом деле являются суммой показателей с момента сброса счетчиков). Но на основе этой статистики можно сделать мониторинг запросов — посмотреть на статистику во времени. Это оказывается крайне полезно для поиска причин различных проблем и в целом для понимания, что происходит на сервере БД.

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

Сегодня, 29 сентября 2016 года, вышел новый релиз PostgreSQL, получивший номер 9.6. В нём содержится много весьма полезных фич, и нельзя не рассказать о них, тем более что вклад нашей компании в этот релиз существенен. Поэтому в этой статье мы расскажем о тех разработках Postgres Pro, которые вошли в сегодняшний релиз.

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

Сегодня мы рассмотрим примеры уже более серьезных патчей, устраняющих узкие места в коде, исправляющих достаточно серьезные баги, относительно крупные рефакторинги, и так далее. Как и ранее, основная цель статьи — не столько осветить изменения, принятые в PostgreSQL 9.6, сколько показать, что разработка open source проектов, в частности PostgreSQL, это интересно и не так сложно, как вам это может казаться.

Если эта тема вам интересна, прошу под кат.

Иногда использование третьей таблицы для связи многое ко многим не есть необходимым и добавляет в разработку проекта дополнительные сложности. Попытаемся уйти от использования третьей таблицы используя столбец типа массив добавленный в PostgreSQL 9.1

Вы не любите кошек? Да вы просто не умеете их готовить! (с) Альф

При проектировании достаточно объёмных реляционных баз данных часто принимается решение об отступлении от нормальной формы — «денормализации».
Причины могут быть разными. От попытки ускорения доступа к определённым данным, ограничений используемой платформы/фреймворка/средств разработки и до недостатка квалификации разработчика/проектировщика БД.
Впрочем, строго говоря, ссылка на ограничения фреймфорка и т.п. — по сути попытка оправдать недостаток квалификации.

Денормализованные данные — слабое звено, через которое легко можно привести нашу базу в неконсистентное (нецелостное) состояние.

Что с этим делать?

Вот и наступила осень. Кто-то возвращается в город с центнером яблок в багажнике, кто-то — c норвежским пивом прямиком с JavaZone, а мы подготовили для вас материал, который, надеемся, скоротает дождливые вечера. Мы расскажем о трёх летних встречах JUG.ru. Посему разработчики, вернувшись из отпусков, имеют замечательную возможность запастись чашкой горячего чая, завернуться в плед и посмотреть видео с наших митапов.

Итак, летом у нас было три встречи:
    — Douglas Hawkins из Azul рассказал об особенностях работы JIT-компиляторов в HotSpot JVM;
    — Alvaro Hernandez, разработчик ToroDB, рассказал о том, как Java работает с PostgreSQL;
    — наконец, Евгений Борисов порадовал нас новой порцией загадок на тему Spring.

Масштабирование базы данных через шардирование и партиционирование

Денис Иванов (2ГИС)

Всем привет! Меня зовут Денис Иванов, и я расскажу о масштабировании баз данных через шардирование и партиционирование. После этого доклада у всех должно появиться желание что-то попартицировать, пошардировать, вы поймете, что это очень просто, оно никак жрать не просит, работает, и все замечательно.

Немного расскажу о себе — я работаю в команде WebAPI в компании 2GIS, мы предоставляем API для организаций, у нас очень много разных данных, 8 стран, в которых мы работаем, 250 крупных городов, 50 тыс. населенных пунктов. У нас достаточно большая нагрузка — 25 млн. активных пользователей в месяц, и в среднем нагрузка около 2000 RPS идет на API. Все это располагается в трех датацентрах.

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