Рубрика «postgresql» - 49

Привет! Обсуждение DataGrip началось уже в комментариях к анонсу новой IntelliJ IDEA, давайте продолжим здесь. Расскажу, что нового в DataGrip 2017.1.

image

Будет много текста и картинок. Вкратце, вот что мы добавили:
Читать полностью »

Запись при чтении в postgresql: скандалы, интриги, расследования - 1 Я уже рассказывал про мониторинг запросов postgresql, в тот момент мне казалось, что я полностью разобрался, как postgresql работает с различными ресурсами сервера.

При постоянной работе со статистикой по запросам постгреса мы начали замечать некоторые аномалии. Я полез разбираться, заодно очередной раз восхитился понятностью исходного кода постгреса:)

Под катом небольшой рассказ о неочевидном поведении postgresql.

Читать полностью »

Сегодня мы хотели бы затронуть очень важную для DLP-решений тему – выбор СУБД для хранения данных. Так исторически сложилось, что большинство российских DLP используют для этих целей Oracle Database. На заказчиков это накладывает определенные финансовые ограничения: стоимость лицензий Oracle закладывается в стоимость DLP-системы. Это создает определенный фильтр, сокращающий аудиторию пользователей продукта: СУБД Oracle могут позволить себе не все – как в техническом, так и в финансовом плане.

Теперь, когда импортозамещение шагает по стране, госсектор (и не только) формирует спрос на DLP, поддерживающие свободные СУБД. Это очень ощутимый импульс, но, метнувшись в сторону свободных СУБД, важно сохранить удобство, производительность и функциональные возможности продукта. В этой статье речь пойдет о том, как мы решали эту задачу, реализуя поддержку PostgreSQL и разрабатывая схему секционирования в Solar Dozor.

Замена Oracle на PostgreSQL и возможности работы с секционированием внутри DLP-системы - 1
Читать полностью »

Работа с PostgreSQL: настройка и масштабирование. 5-е издание - 1
Добрый день, хаброжители. Прошло много времени с выпуска 4 версии книги по PostgreSQL — успела выйти версия 9.5 и 9.6 этой замечательной базы данных. Материалов по практическому использованию этой БД также накопилось немало, поэтому я решил выпустить обновление по книге. Итак, встречайте:«Работа с PostgreSQL: настройка и масштабирование», 5-е издание.

Читать полностью »

Сегодня предлагаю поразмышлять о том, как искать паттерны в биржевых данных и как их использовать для успешной торговли.
Будем получать биржевые данные Forex от одного из брокеров, сохраним в базу данных PostgreSQL и попробуем найти закономерности при помощи алгоритмов машинного обучения.
В статье есть несколько приятных бонусов в виде кода на Python — Вы сможете сами проанализировать любые (почти) биржевые данные (или значения индикаторов), запустить собственного торгового робота и проверить любую торговую стратегию.
Все условия и определения паттернов в статье приведены для примера, вы можете использовать любые критерии.
Читать полностью »

Начнем с того, что все ваши объявления живут в базе PostgreSQL. До сих пор львиная часть бизнес-логики скрыта в хранимых процедурах, и не всегда их работу удобно контролировать.

PG Metricus — сбор метрик из plpgsql кода или как три строчки кода упростили жизнь - 1

Для нас хранимые процедуры удобны, в первую очередь тем, что не надо передавать гигабайты данных между базой и приложением. Удобно сделать несколько действий с разными таблицами в базе, а в приложение только отчитаться о том, что всё было выполнено успешно. Это действительно удобно, но в то же время это привносит и ряд проблем. Бизнес-логика частично прячется в базе, механизмы, которые используются для отладки и мониторинга на PHP/Go/Python/etc неприменимы на стороне СУБД. Конечно, есть свои замечательные средства, например, pg_stat_statements, но иногда они не могут в полной мере ответить на вопрос, какой именно кусок кода в нашей большой и сложной хранимке работает не так. Предложенное нами решение не претендует на звание «серебряной пули», но может помочь быстро определить среднее время выполнения кусков кода внутри хранимой процедуры, которая выполняется тысячи раз в секунду, и сделать это без создания лишней нагрузки. Интересно? Добро пожаловать!
Читать полностью »

С моей прошлой публикации о распределенной базе данных CrateDB прошло около года. Проект на основе Elasticsearch и PrestoDB написан на Java. Он за это время активно развивался и обрастал новым функционалом в github репозитарии:

  • поддержка outer join;
  • case when… then… end в запросах;
  • функции для работы с пространственными(Geospatial) данными;
  • возможно отображение данных временных рядов (Time Series) в Grafana;
  • ограниченная поддержка подзапросов;
  • узлы кластера работающие в режиме только чтения;
  • эмуляцией подмножества протокола PostgreSQL 9.5;
CrateDB: снаружи как PostgreSQL, а внутри Elasticsearch - 1

Приятной неожиданностью было обнаружить в github проекта, что в команде CrateDB есть русскоговорящий разработчик Руслан. Достаточно быстро получил от него ответ на вопросы про внутреннее устройство и зависимости проекта.
Читать полностью »

Еще одна новая фича pg_filedump: восстанавливаем каталог PostgreSQL - 1

В прошлой статье мы узнали, как при помощи утилиты pg_filedump можно восстановить данные, или, по крайней мере, какую-то их часть, из полностью убитой базы PostgreSQL. При этом предполагалось, что мы откуда-то знаем номера сегментов, соответствующих таблице. Если мы знаем часть содержимого таблицы, ее сегменты действительно не сложно найти, например, простым grep'ом. Однако в более общем случае это не так-то просто сделать. К тому же, предполагалось, что мы знаем точную схему таблиц, что тоже далеко не факт. Так вот, недавно мы с коллегами сделали новый патч для pg_filedump, позволяющий решить названные проблемы.

Читать полностью »

image

Возникла необходимость вести аудит изменения данных в существующей системе.

Требования:

  • Простота подключения/отключения логгирования отдельных таблиц.
  • Сократить до минимума изменения в уже существующих функциях БД.
  • Минимизировать деградацию производительности.

Читать полностью »

Uber — причины перехода с Postgres на MySQL - 1

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

Наверное, не будет преувеличением сказать, что за последние несколько лет это было одно из самых громких и резонансных событий, связанных с СУБД PostgreSQL, которую мы, к слову сказать, очень любим и широко используем. Эта ситуация наверняка пошла на пользу не только упомянутым системам, но и движению Free and Open Source в целом. При этом, к сожалению, русского перевода статьи так и не появилось. Ввиду значимости события, а также подробного и интересного с технической точки зрения изложения материала, в котором в стиле Postgres vs MySQL идет сравнение физической структуры данных на диске, организации первичных и вторичных индексов, репликации, MVCC, обновлений и поддержки большого количества соединений, мы решили восполнить этот пробел и сделать перевод оригинальной статьи. Результат вы можете найти под катом.

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js