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

В DataGrip, как и в других наших IDE с поддержкой баз данных, есть механизм экспорта данных. Пользователь выбирает формат экспорта из предложенных или создает его сам.

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

Осенний Postgres в Райффайзенбанке - 1

В понедельник, 13 ноября приглашаем вас в офис Райффайзенбанка, где пройдет очередной PostgreSQL MeetUp. Мероприятие организовано совместно с компанией Postgres Professional.

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

Как мы делаем карту для тех, кто делает карту - 1

Продуктами 2ГИС пользуются 30 млн горожан. Чтобы огромный набор данных попал к конечному пользователю, мы используем множество внутренних продуктов, о которых очень редко рассказываем.

Однажды на Хабре уже была статья о нашем внутреннем продукте — векторном редакторе геометрий. Чудеса нейминга привели нас к трём точкам — Fiji. До них проект назывался так: «Новая карта» → «Новая новая карта» → «Новая новая новая карта». Три года назад мы приступили к реализации Fiji и рассказали о прототипировании UI, сегодня — погрузимся в технические детали и расскажем о том, как создать быстрый и надежный ГИС-редактор.
Читать полностью »

Мы уже познакомились с механизмом индексирования PostgreSQL и с интерфейсом методов доступа, и рассмотрели хеш-индексы, B-деревья, индексы GiST и SP-GiST. А в этой части займемся индексом GIN.

GIN

— Джин?.. Джин — это, кажется, такой американский спиртной напиток?..
— Не напиток я, о пытливый отрок! — снова вспылил старичок, снова спохватился и снова взял себя в руки. — Не напиток я, а могущественный и неустрашимый дух, и нет в мире такого волшебства, которое было бы мне не по силам.

Лазарь Лагин, «Старик Хоттабыч».

Gin stands for Generalized Inverted Index and should be considered as a genie, not a drink.

README

Общая идея

GIN расшифровывается как Generalized Inverted Index — это так называемый обратный индекс. Он работает с типами данных, значения которых не являются атомарными, а состоят из элементов. При этом индексируются не сами значения, а отдельные элементы; каждый элемент ссылается на те значения, в которых он встречается.

Хорошая аналогия для этого метода — алфавитный указатель в конце книги, где для каждого термина приведен список страниц, где этот термин упоминается. Как и указатель в книге, индексный метод должен обеспечивать быстрый поиск проиндексированных элементов. Для этого они хранятся в виде уже знакомого нам B-дерева (для него используется другая, более простая, реализация, но это не существенно). К каждому элементу привязан упорядоченный набор ссылок на строки таблицы, содержащие значения с этим элементом. Для выборки данных упорядоченность не принципиальна (порядок сортировки TID-ов не несет в себе особого смысла), но она важна с точки зрения внутреннего устройства индекса.

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

Администраторы баз данных и разработчики часто сталкиваются с ситуациями, когда необходимо данные из разных баз сравнивать и синхронизировать, либо просто перенести их в другую рабочую базу. В этом случае очень важно выбрать правильный инструмент, который поможет справиться с этой задачей быстро и эффективно. Для PostgreSQL на рынке существует несколько готовых инструментов, которые позволяют находить различия и выполнять синхронизацию данных. В этой статье проведем небольшой обзор особенностей этих инструментов, а именно продукты таких компаний как Devart, SQL Maestro Group, Navicat и Altova.

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

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

В ходе работы DLP-система ежедневно перехватывает огромные массивы информации – это и письма сотрудников, и информация о действиях пользователей на рабочих станциях, и сведения о хранящихся в сети организации файловых ресурсах, и оповещения о несанкционированном выводе данных за пределы организации. Но полезной эта информация будет только в случае, если в DLP реализован качественный механизм поиска по всему массиву перехваченных коммуникаций. С тех пор, как в 2000 году увидела свет первая версия нашего DLP-решения, мы несколько раз меняли механизм поиска по архиву. Сегодня мы хотим рассказать о том, какие технологии мы использовали, какие видели в них преимущества и недостатки, и почему мы от них в итоге отказывались. Возможно, кому-то наш опыт окажется полезен.
«В активном поиске»: как мы выбирали поисковый механизм для DLP-системы - 1
Читать полностью »

Мы в своей работе активно используем PostgreSQL, много участвуем в тематических конференциях, проводим соревнования и пишем про администрирование и разработку. И вот сегодня я хочу пригласить вас поучаствовать ещё в одной встрече, посвященной Postgres — живом митапе на канале #RuPostgres Live. В прямом эфире, который будет вести и модерировать Николай Postgresmen Самохвалов, я и мои коллеги ответим на ваши вопросы. Подробности под катом.

Живой митап #RuPostgres: вопросы и ответы с экспертами Avito - 1

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

Курс молодого бойца PostgreSQL - 1

Хочу поделиться полезными приемами работы с PostgreSQL (другие СУБД имеют схожий функционал, но могут иметь иной синтаксис).

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

Данный материал будет полезен тем, кто полностью освоил базовые навыки SQL и желает учиться дальше. Советую выполнять и экспериментировать с примерами в pgAdmin'e, я сделал все SQL-запросы выполнимыми без разворачивания каких-либо дампов.

Поехали!
Читать полностью »

Во время миграции из Oracle в PostgreSQL с помощью ora2pg встал вопрос с несоответствием типов данных между разными базами. По умолчанию не все колонки конвертируется правильно, а отсутствие в Oracle Boolean и вовсе порождает неоднозначность – часть колонок нужно перенести как числа, часть как логические значения. В тоже время hibernate знает все о типах данных и может создать эталонную схему.

Итоговый процесс переноса выглядел следующим образом: создание структуры таблиц через ora2pg, исправление структуры по эталонной схеме, перенос данных, конвертация blob и Boolean, добавление отсутствующих в PostgreSQL функций (nvl, nvl2, regexp_substr), создания оставшейся структуры — индексов, view и прочего.

Под катом накопившиеся за время конвертации sql скрипты для полуавтоматической миграции.
Читать полностью »


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