Citus — это расширение для PostgreSQL, которое обеспечивает масштабируемость PostgreSQL за счет прозрачного распределения и/или репликации таблиц на одном или нескольких узлах PostgreSQL. Citus можно использовать как на облачной платформе Azure, так и на собственных серверах, поскольку расширение базы данных Citus имеет полностью открытый исходный код.
Ранее я рассказывал о том, как запустить PostgreSQL в Docker. Тогда речь шла об использовании «ванильных» образов Postgres и поднятии одного хоста. В большинстве случаев этого достаточно как для тестов, так и для экспериментов, но нужно понимать, что в промышленной эксплуатации чаще всего используются высокодоступные (отказоустойчивые, кластеризованные) конфигурации PostgreSQL.
Сегодня я покажу, как запустить уже целый кластер PostgreSQL в Docker, а также в тестах через Testcontainers, и как вручную инициировать смену мастер-хоста.
Пару недель назад (перевод статьи от 2021 г.) мы с Джобином (Jobin) сделали небольшую презентацию в рамках Percona Live Online с названием, подобным теме этой статьи: "PostgreSQL HA с Patroni: Сценарии отказов и способы восстановления кластера после них". Мы развернули 3-узловую среду PostgreSQL на имеющемся у нас оборудовании и решили "ломать" ее различными способами: отключали от интернета и электропитания кабели, “убивали” основные процессы, пытаясь насытить процессоры. Всё это происходило при постоянной записи и чтении данных из PostgreSQL. Идея заключалась в том, чтобы посмотреть, как Patroni справится с отказами и будет управлять кластером, продолжая обеспечивать работу. Это была интересная демонстрация!
В этой статье Антон Колесов, технический руководитель группы по эксплуатации платформ и системных решений, расскажет, как команда разработчиков Nexign настраивала альтернативное решение для кэша одной из наших высоконагруженных систем и анализировала возможность использования PostgreSQL в качестве одного из вариантов.
Конференции, битва за Ибицу
PGConf впервые пройдёт 25 сентября в Санкт-Петербурге. Конференция будет называться PGConf.СПб 2023. Место - Отель «Коринтия», Невский проспект., д.57.
Регистрация открыта и заявки принимаются. Подать заявку можно в личном кабинете. Количество тем не ограничено.
Пройдёт на площадке Город ИТ пройдёт 9-го сентября в Томске. Программа еще формируется, но общая канва известна.
PGIbiza 2023: Postgres and Ecosystem
Но с ней не всё просто. Казалось бы, на Ибице есть всё, чтобы поработать и расслабиться последовательно или одновременно (насколько помню, там даже доклады на пляже). Но всплыл старый конфликт между Альваро Эрнандесом (Álvaro Hernández Tortosa) и старейшинами (Core Team) PostgreSQL. Поскольку есть риск многое истолковать неправильно, напомним предысторию. Альваро не рейдер, попытавшийся захватить торговые марки PostgreSQL. Он революцьонэр. История эта началась ещё в 2021-м.
В статье разберём основные этапы создания расширения для PostgreSQL на языке C и как запустить внутри СУБД игру Doom.
В этой статье я расскажу, какие подводные камни ждали команду разработки бэкенда служебных мобильных приложений одного банка, решившей мигрировать с MySQL на PostgreSQL.
Всем привет! На связи разработчики БД - Юрий Плотников и Андрей Григорьев, в этот раз рассказывать мы будем вдвоем, вернее не совсем вдвоем - об одном "фирменном" решении расскажут коллеги из нашего центра компетенций PostgreSQL.
Пара слов о заглавной картинке и логотипе
Несмотря на то, что история pgmig началась раньше, большое развитие он получил при разработке наших "сказочных" продуктов (youtube).
Поэтому мы решили, что ему также место среди сказочных персонажей - домовенок, приводящий процессы в порядок
Начнем издалека, с очевидных вещей, однако без этого было бы сложнее понять главную идею. Итак, к делу:
Привет! Меня зовут Антон Казачков, я специалист вендорской поддержки СУБД Platform V Pangolin. Это реляционная СУБД уровня enterprise, которая разработана в СберТехе на основе PostgreSQL и доработана до корпоративного уровня надёжности и производительности. Сегодня Pangolin — целевая СУБД Сбера, основа для миграции всех существующих приложений и разработки новых.
Расскажу о ситуациях, с которыми сталкиваются команды на последних этапах миграции СУБД и в начале производственного цикла. На Хабре часто обсуждаются нюансы переезда СУБД из разных проприетарных версий на PostgreSQL. А вот информации о том, как вводить базы в эксплуатацию и выявлять производственные «болячки», на мой взгляд, не так много.
В ходе использования postgresql совместно с sqlalchemy я столкнулся с рядом особенностей, которые слабо документированы, о которых мне и хотелось бы поведать
Тут описаны как простые примеры использования, так и решения разнообазных проблем. Так что если вы являетесь пользователем postgresql и sqlalchemy данная статья может значительно упростить вашу жизнь
Среди применяемых в PostgreSQL методов доступа к данным Index Only Scan стоит особняком, считаясь у многих разработчиков "волшебной пилюлей" для ускорения работы запроса - мол, "Index Scan - плохо, Index Only Scan - хорошо, как только получим его в плане - все станет замечательно".
Как минимум, это утверждение неверно. Как максимум, при определенных условиях может вызвать проблемы чуть ли не на ровном месте.
Как протестировать код на Go с базой данных? В этой статье опишу пример такого тестирования в связке с Postgres, очисткой на основе копирования базы данных и рассмотрю некоторые альтернативы.
Привет, Хабр!
Впервые с вопросом анонимизации данных мы широко столкнулись при работе с динамическими окружениями.
Не секрет, что разработка даже небольшого проекта тесно связана с инфраструктурой, поскольку любая программа требует наличия определённого окружения. Часто таких окружений требуется несколько — одно под прод, а остальные — под разные нужды, например, тестирование. Иногда эти среды даже могут быть динамическими — когда вместе с новым бранчем создаётся окружение, в котором запускается разрабатываемая версия приложения и всё необходимое для неё, а после того как бранч вливается в main, эта среда и все её данные удаляется.
И вот как раз о данных (а точнее о базах данных) в таких средах и хотелось бы поговорить. А именно — где и как их взять, как сделать их максимально приближенными к боевым и как защититься от их утечки. Для решения этих задач мы в Nixys используем собственный инструмент — nxs-data-anonymizer. Хотим поделиться им с вами.
Иногда (часто) во время разработки веб-сайта возникает необходимость реализовать поиск с фильтрацией, и отсортировать результаты по какому-то фиксированному полю: например, поиск товаров в интернет-магазине, поиск туров в турагентстве, показ логов с фильтрацией по содержимому, и т.д. Очень часто бывает так, что фильтрация должна осуществляться чуть ли не по любому полю (а полей десятки), а записей тысячи или даже миллионы. Если данных много, или же нужно их часто обновлять, то индекс на каждое поле не создать, ибо много места будут занимать, или же будут создавать слишком большую нагрузку на диск при записи, и приходится что-то придумывать. Давайте что-нибудь придумаем.
Всем привет от команды ЮMoney ?
Делимся видеозаписями и главными мыслями митапа High SQL, который посвятили работе с данными в DWH на Microsoft SQL Server.
Кому советуем посмотреть доклады
◾️ Тем, кто планирует перебраться с Microsoft SQL в PostgreSQL, но всё ещё сомневается.
◾️ Тем, кто выбирает между ANTLR и DacFx и хочет научиться решать проблемы во время ревью TSQL-кода.
◾️ И тем, кто хочет узнать, зачем тестировать OLAP-кубы, что может пойти не так и какой результат дают автотесты силами разработчиков и тестировщиков.
Друзья, всем привет!
Помимо основной работы инженером данных, я поддерживаю небольшой сайт на Django (посвящен информационным материалам по преподаванию истории и обществознания).
Так как материалы на сайт добавляются довольно часто, а также регистрируются новые пользователи, конечно же возникла идея, как бы правильно организовать бэкап базы данных и загруженных медиафайлов - чтобы я мог легко синхронизировать данные на сервере с данными, лежащими в базе на рабочем компьютере.
Сразу скажу, что такой подход подойдет для баз, размер которых не является астрономическим (десятки и сотни гигабайт), в моем случае база весит всего 50 Мб, статика около 400 - поэтому мне не составляло большого труда синхронизировать такие объемы. Думаю, небольшие и даже средние интернет магазины и блоги вряд ли хранят на порядки больше данных.
Для больших проектов, лучше бэкапы архивировать, шифровать и отправлять куда-нибудь в s3 типа Minio.
Когда новая инфа на сайте появлялась довольно редко, я все делал руками, а именно...
Если вы работает с базами данных, то, скорее всего, знакомы с B-tree индексами. У них множество применений и они являются дефолтными типами индекса в большинстве движков баз данных. Если вы работаете с полнотекстовым поиском или пространственными данными, то скорее всего вы знакомы еще и с GIN и GIST индексами. Если вы работаете с массивными временными рядами, то слышали еще и о BRIN индексах.
Однако, есть еще один менее популярный тип, о котором большинство даже ничего не слышало. Пару версий PostgreSQL назад он был не то что даже непопулярен, но и строго не рекомендован к использованию. Однако в некоторых случаях он может обойти даже B-tree в плане производительности.
Сейчас мы переоткроем хэш-индекс!
О том, как именно использовать регулярки, написано уже много статей и туториалов. Другой вопрос, что сами по себе регулярные выражения являются параметром, подающимся на вход какой-нибудь функции. Именно функция осуществляет поиск по указанному регулярному выражению. О функциях, использующих регулярки мы сегодня и поговорим. Возможно, и по самим регуляркам я бахну свой гайд, но, как было сказано в том самом фильме: «Обязательно бахнем и не раз, весь мир в труху! Но потом...»
