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

Недолго рассмотрев сложившуюся ситуацию предложил ребятам метод апгрейда через репликацию, для них никаких сложностей лишь один раз перезапустить приложение с изменением имени базы в коннекторе. Это позволит за раз сделать все что необходимо с учетом всех условий. Объяснил что разработчикам нужно наверно даже больше уделить внимание тестированию того что может выстрелить в новой версии самого 14 PosgreSQL - возможно изменение синтаксиса SQL, или свежий баг на лини сопряжения «база - ОС», или особенность драйвера, в общем нужно протестировать работу всего функционала и ухо держать востро, ну а я сделаю все максимально гладко со своей стороны.

Соответственно на тесте постарался процедуру обкатать и проиграть в различных вариантах и ситуациях. Да и конечно было ограничение - на сервере не было дискового пространства на 8 баз суммарно, разве что на 3 хватило. Короче есть ограничение по месту. Да и сразу скажу, что в моей базе партиций не было, поэтому стоит это учесть и внести изменения в скрипты, если требуется !

Задача у команды стояла такая - нужно разделить одну базу на 8 отдельных баз по внутреннему индикатору- ID проекта (в процессе работы проект разделился на признаку и все жило в пределах одной базы). Так же у меня была своя задача апгрейда с 13 на 14 версию PostgreSQL. Была просьба от команды сделать это с минимальный простоем и совсем хорошо если за один присест, а не разбивая частями по 2-3 базы за итерацию.

https://habr.com/ru/post/704606/?utm_source=habrahabr&utm_medium=rss&utm_campaign=704606

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

Недолго рассмотрев сложившуюся ситуацию предложил ребятам метод апгрейда через репликацию, для них никаких сложностей лишь один раз перезапустить приложение с изменением имени базы в коннекторе. Это позволит за раз сделать все что необходимо с учетом всех условий. Объяснил что разработчикам нужно наверно даже больше уделить внимание тестированию того что может выстрелить в новой версии самого 14 PosgreSQL - возможно изменение синтаксиса SQL, или свежий баг на лини сопряжения «база - ОС», или особенность драйвера, в общем нужно протестировать работу всего функционала и ухо держать востро, ну а я сделаю все максимально гладко со своей стороны.

Соответственно на тесте постарался процедуру обкатать и проиграть в различных вариантах и ситуациях. Да и конечно было ограничение - на сервере не было дискового пространства на 8 баз суммарно, разве что на 3 хватило. Короче есть ограничение по месту. Да и сразу скажу, что в моей базе партиций не было, поэтому стоит это учесть и внести изменения в скрипты, если требуется !

Задача у команды стояла такая - нужно разделить одну базу на 8 отдельных баз по внутреннему индикатору- ID проекта (в процессе работы проект разделился на признаку и все жило в пределах одной базы). Так же у меня была своя задача апгрейда с 13 на 14 версию PostgreSQL. Была просьба от команды сделать это с минимальный простоем и совсем хорошо если за один присест, а не разбивая частями по 2-3 базы за итерацию.

https://habr.com/ru/post/704606/?utm_source=habrahabr&utm_medium=rss&utm_campaign=704606

Достаточно часто при проектировании схемы БД возникает задача сохранить по основной сущности некоторый набор простых второстепенных данных.

Например, это могут быть ФИО сотрудников, принимающих участие во встрече, список приложенных к сообщению файлов или перечень отгружаемых по документу позиций.

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

Давайте посмотрим, какие варианты хранения таких данных мы можем использовать в PostgreSQL, и какой из них окажется в разы более эффективным.

https://habr.com/ru/post/704250/?utm_source=habrahabr&utm_medium=rss&utm_campaign=704250

Достаточно часто при проектировании схемы БД возникает задача сохранить по основной сущности некоторый набор простых второстепенных данных.

Например, это могут быть ФИО сотрудников, принимающих участие во встрече, список приложенных к сообщению файлов или перечень отгружаемых по документу позиций.

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

Давайте посмотрим, какие варианты хранения таких данных мы можем использовать в PostgreSQL, и какой из них окажется в разы более эффективным.

https://habr.com/ru/post/704250/?utm_source=habrahabr&utm_medium=rss&utm_campaign=704250

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

Основным языком разработки у нас, в TIMELESS, является TypeScript, как на frontend, так и на backend. Поэтому в рамках идеи типизации всего и вся для работы с БД мы выбрали Prisma, которая позиционирует себя как “Next generation ORM for Node.js and TypeScript”.

Спустя год применения Prisma хотелось бы поделиться опытом ее использования при работе с PostgreSQL из Node.js приложения.

https://habr.com/ru/post/702930/?utm_source=habrahabr&utm_medium=rss&utm_campaign=702930

Некоторые базы данных такие, как Microsoft SQL Server, IBM Db2, а также PostgreSQL начиная с 11 версии – предлагают прибегнуть к оператору include для генерации индекса. Представление данного функционала в PostgreSQL (исходная статья вышла 30.04.2019) послужило поводом для этого объёмного рассуждения о работе с оператором include.

Содержание:

1) Напоминание: btree-индексы

2) Напоминание: Index-only сканирование

3) Оператор include

4) Фильтрация по полям в include

5) Уникальные индексы при использовании include

6) Сравнение

7) PostgreSQL: Никакой фильтрации до проверки области видимости

https://habr.com/ru/post/703578/?utm_source=habrahabr&utm_medium=rss&utm_campaign=703578

Некоторые базы данных такие, как Microsoft SQL Server, IBM Db2, а также PostgreSQL начиная с 11 версии – предлагают прибегнуть к оператору include для генерации индекса. Представление данного функционала в PostgreSQL (исходная статья вышла 30.04.2019) послужило поводом для этого объёмного рассуждения о работе с оператором include.

Содержание:

1) Напоминание: btree-индексы

2) Напоминание: Index-only сканирование

3) Оператор include

4) Фильтрация по полям в include

5) Уникальные индексы при использовании include

6) Сравнение

7) PostgreSQL: Никакой фильтрации до проверки области видимости

https://habr.com/ru/post/703578/?utm_source=habrahabr&utm_medium=rss&utm_campaign=703578

Представим, что у вас есть некоторая табличка статистики, куда вы периодически скидываете таймстамп последнего "текущего" состояния в паре координат - например, (ID организации, ID сотрудника).

Как больно наступить на грабли в совсем простом, казалось бы, запросе?

https://habr.com/ru/post/702902/?utm_source=habrahabr&utm_medium=rss&utm_campaign=702902

Представим, что у вас есть некоторая табличка статистики, куда вы периодически скидываете таймстамп последнего "текущего" состояния в паре координат - например, (ID организации, ID сотрудника).

Как больно наступить на грабли в совсем простом, казалось бы, запросе?

https://habr.com/ru/post/702902/?utm_source=habrahabr&utm_medium=rss&utm_campaign=702902

Всем привет! Мы команда Dev’s Battle. В этом посте расскажем о том, как мы создавали для нашего продукта (MMO RPG игра в телеграм) собственную систему аналитики

https://habr.com/ru/post/702658/?utm_source=habrahabr&utm_medium=rss&utm_campaign=702658

Этот материал посвящен сервису Xalq Nazorati (Народный Контроль) — с ним люди могут пожаловаться на нерабочий лифт, яму на дороге, сломанный светофор или стертую дорожную разметку. В статье расскажем, с чего мы начинали проект, какие ошибки допускали, как их исправляли и где в итоге оказались.

88% всех обращений были в итоге решены.

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

Чтобы лучше обозначать раскрытие темы, используем индикатор из хорошо знакомой многим игры. Так интереснее.

Резюме

Сегодня в сервис Народный Контроль уже поступило более 28 тыс. обращений от горожан — чаще всего люди жалуются на проблемы на дорогах, ЖКХ и экологические проблемы.

https://habr.com/ru/post/701682/?utm_source=habrahabr&utm_medium=rss&utm_campaign=701682

Postgres - один из крупнейших open source проектов. Он создавался многие года. Кодовая база накопилась огромная. Мне, как программисту, всегда было интересно как он работает под капотом. Но не про SQL пойдет речь, а про язык на котором он написан. Про C.

С общей архитектурой можно ознакомиться здесь

Для начала поймем, что происходит до входа в главный цикл сервера.

https://habr.com/ru/post/701284/?utm_source=habrahabr&utm_medium=rss&utm_campaign=701284

Postgres - один из крупнейших open source проектов. Он создавался многие года. Кодовая база накопилась огромная. Мне, как программисту, всегда было интересно как он работает под капотом. Но не про SQL пойдет речь, а про язык на котором он написан. Про C.

С общей архитектурой можно ознакомиться здесь

Для начала поймем, что происходит до входа в главный цикл сервера.

https://habr.com/ru/post/701284/?utm_source=habrahabr&utm_medium=rss&utm_campaign=701284