В данной статье будет рассмотрен подход к автоматизированному созданию карт с использованием следующего технологического стека: QGIS, PostgreSQL, Django, Leaflet. Идея родилась ввиду необходимости быстрого создания интерактивных карт из уже созданных проектов в QGIS. Хочу сразу оговорится что проекты создаются без использования локальных слоев, а исключительно с использование БД для их хранения.
Иногда типичная IT-инфраструктура крупной компании выгляд так: PostgreSQL для аналитики, и Oracle для корпоративных данных, и MySQL для каких-нибудь микросервисов. В таких условиях взаимодействие между различными системами становится настоящим мастхевом. И тут может помочь герой нашей статьи - dblink.
dblink позволяет нам безболезненно дергать данные из одной базы в другую, будь то PostgreSQL или что-то вроде Oracle или MySQL.
Представим некое перепутье, где с одной стороны — мощные возможности PostgreSQL, а с другой — необъятные просторы Hadoop. Выбор кажется сложным, но зачем выбирать одно, если можно соединить их и получить лучшее из обоих?
Объединяя их можно создать мощную систему, способную обрабатывать и анализировать огромные объемы данных.
Привет, Хабр!
Представьте себе, вы приходите домой после долгого рабочего дня, и вас встречает пушистый котик. Вы знаете, что он ждет вас, чтобы вы рассказали ему о своих подвигах на работе. И вот, вы начинаете свой рассказ, а он, этот милый мурлыка, вдруг спрашивает: "А как там у тебя с оптимизацией запросов в PostgreSQL?"
Вы, конечно, удивлены: "Откуда у кота такие знания?" Но котик смотрит на вас с понимающим видом и говорит: "Ведь хороший запрос должен быть как прыжок кошки - быстрым, точным и грациозным..."
Иногда перед разработчиком, аналитиком или даже бизнес-пользователем встает задача выполнить какие-то финансовые расчеты, соблюдая два строгих требования. Во-первых, даже для миллиардных сумм необходимо обеспечить точность до копейки, во-вторых, перекрестные итоги тоже должны сходиться до копейки.
Привет, Хабр!
Мы — команда Рег.ру, направление облачных сервисов, — однажды решили создать сервис управляемых баз данных, он же DBaaS. Раскрываем технические аспекты DBaaS: на каких технологиях основана услуга, какие инструменты использованы, с какими трудностями мы столкнулись при создании и запуске в продакшн. Будет интересно!
Джонатан Кац (Jonathan Katz) пишет:
PostgreSQL 17 Beta 1 запланирована на 23 мая. Пожалуйста, продолжайте тяжёлую работу по закрытию недоделанных пунктов (open items), все поправки намечено доделать к 18 мая. Всем спасибо! Это очень здорово, что мы подошли к этому этапу!
Release notes уже есть, Брюс Момджан о них:
В этом релизе пунктов, связанных с новшествами (feature count), будет 188. Приятный сюрприз для меня: большое число улучшений в оптимизации. Postgres 17 Beta 1 выйдет на днях, а окончательный релиз Postgres 17 запланирован на сентябрь/октябрь этого года.
А также 15.7, 14.12, 13.15 и 12.19. Ветку 12 больше поддерживать не будут.
Привет, Хабр!
Хеш-индексы в PostgreSQL — это хороший инструмент для ускорения выполнения запросов.
В основе хеш-индекса лежит хеш-функция. Хеш-функция — это алгоритм, который преобразует входные данные (или ключ) в число фиксированного размера, называемое хеш-значением. В PostgreSQL хеш-функция всегда возвращает значение типа integer, что составляет примерно 4 миллиарда возможных значений.
Поделюсь как начал писать приложение для интернет-магазина на монолите, затем перешёл на микросервисы.
Привет, Хабр!
Сегодня мы поговорим об актуальной задаче — миграции баз данных с Oracle на PostgreSQL с использованием Ora2Pg. Сейчас популярность PostgreSQL обоснована его мощностями и экономически выгодной альтернативы коммерческим решениям.
Данная статья является продолжением первой части: "PostgreSQL 16. Организация данных. Часть 1".
В этой части мы обсудим, как транзакции могут влиять друг на друга, вызывая "аномалии", а также рассмотрим различные уровни изоляции, которые помогают избежать подобных проблем.
Всем привет! Меня зовут Виктор, я работаю в Компании БФТ-Холдинг руководителем группы разработки. Продолжаю цикл статей по работе с Greenplum. В этом материале хочу рассказать, как СУБД Greenplum строит планы и выбирает самый оптимальный, а также разберу типовые проблемы, которые влияют на выбор плана запроса. Статья будет полезна разработчикам Greenplum, которые пока не имеют достаточного опыта «чтения» плана запроса.
Последние несколько лет мы в Postgres Professional активно занимаемся разработкой своего решения для горизонтального масштабирования PostgreSQL. Пользователям нужен был простой способ увеличить производительность путем добавления узлов. Традиционно для веба в таких случаях просто брали NoSQL базы или шардировали вручную, позже появились распределенные SQL-решения с поддержкой ACID-транзакций. Тем не менее терялась часть возможностей и достоинств PostgreSQL. Корпоративный рынок тяжелых вертикальных решений также сильно ограничен как ценой, так и доступностью. Поэтому исследованиями в области распределенных СУБД в компании занимались еще с 2017 года, а в 2020 началась работа над коммерческим продуктом.
В этой статье я расскажу про технические детали реализации и почему был сделан такой выбор технологий. Опишу, какие направления нам показались преждевременными и их пришлось отложить, а также что мы ожидаем в будущем.
CDC вам не «Centers for Disease Control and Prevention» а «Change data capture». В статье рассказано какие есть виды CDC и как реализовать один из CDC при помощи Debezium.
Вдохновившись прошлогодним опытом, мы продолжили начинание и снова проводим конкурс по SQL на международной олимпиаде «IT-Планета».
Конкурс состоит из трех этапов. Заочный теоретический тест собрал почти 3000 человек, из которых на следующий этап мы отобрали примерно 200. Вопросы для этого этапа были подготовлены моим коллегой, Евгением Давыдовым.
Второй этап — также заочный. Здесь участником было предложено подумать над пятью задачами моего авторства, о которых я сегодня и хочу рассказать.
Третий — очный — этап пройдет в конце мая; постараюсь не затягивать с отчетом, но пока храню интригующее молчание.
Поскольку все вводные слова про мотивацию я уже сказал в прошлый раз, сразу приступим к делу.
PostgreSQL очень популярная СУБД. Её используют во многих проектах, как новички, так и профессионалы. Однако не все понимают, как именно работает данная система и какое у неё внутренне устройство.
Давайте разберемся вместе на основе книги «PostgreSQL 16 изнутри» и официальной документации!
Как реализовать хранение и работу каталога папок в PostgreSQL? Есть большое количество вариантов. Но хочется, чтобы реализация выглядела лаконично, не нарушала прозрачность выполняемых операций, не вызывала блокировок, не требовала большого вовлечения клиента в специфику работы и т.д. Потому сегодня попробуем реализовать хранение древовидных структур и работу с ними без использования триггеров, блокировок, дополнительных таблиц (представлений) и внешних инструментов в SQL.
Когда я пришёл работать в компанию GreenData шесть лет назад, мои задачи были достаточно стандартными для аналитика, который работает с low-code решениями. Работа с объектной моделью, написание алгоритмов, настройка визуалов - всё что обычно выполняет начинающий специалист в данной области. Однако в процессе моей работы и роста иногда я сталкивался с необходимостью разбираться в тонкостях работы Java, а именно с ошибками, которые возникали в процессе её исполнения.
Эти встречи с Java сначала были случайностью, но со временем превратились в моё новое профессиональное увлечение. Каждый случай сбоя или нестандартного поведения программы становился для меня вызовом; я понял, что за ошибками стоят не просто коды и сообщения, а целые истории о том, как работает система. Этот интерес постепенно перерос в глубокое погружение в мир Java-логов, благодаря чему я стал одним из ведущих экспертов по анализу программных сбоев в компании.
Всем привет!
Как вы знаете, многие поставщики ПО ушли с российского рынка ввиду введённых санкций и многие компании столкнулись с необходимость заняться импортозамещением в кратчайшие сроки. Не стал исключением и наш заказчик. Целевой системой, на которое было принято решение мигрировать старое хранилище, стал Greenplum (далее GP) от компании Arenadata.
Этой статьей мы запускаем цикл материалов посвященных Greenplum. В рамках цикла мы разберем, как вообще устроен GP и как выглядит его архитектура. Постараемся выделить must have практики при работе с данным продуктом, а также обсудим, как можно спроектировать хранилище на GP, осуществлять мониторинг эффективности работы и многое другое. Данный цикл статей будет полезен как разработчикам БД, так и аналитикам.
Сначала запрос адаптирован для работы в PostgreSQL 15.6.
Затем работа запроса проверена на достаточно объемной иерархии - в качестве источника данных использована структура архива jdk-master.zip из OpenJDK 22
