Есть ли в PostgreSQL аналоги таких фичь из MSSQLSERVER

Коллеги, приветствую!
Тут у нас начал подниматься вопрос о миграции софта на "отечественные" платформы.
Предварительно прорабатываем вопрос.

Может кто-то имеет опыт и в MSSQLSERVER?
Есть ли в постгрессе аналог Filetable и вообще - Filestream? (как выяснилось, в одном из проектов очень активно используется)
Если есть, то в каком направлении копать, бросьте пару ключевых слов!
И еще:
Есть ли аналог resource governor, можно ли как-то выделить конкретному пользователю конкретный пул ресурсов, по диску и процессору?
Есть ли аналог колоночных индексов? Интересует Clustered columnstore со сжатием (в проектах встречаются таблички по 1-15 млрд. записей, их тяжко хранить в rowstore)
Секционирование есть, это я уже увидел, мне понравилось больше, как оно сделано. Как я понимаю, секцию в секционированной таблице в постгрессе можно "налету" заменить на таблицу аналогичной структуры, с данными, подпадающими под параметр секционирования?
В нескольких проектах (это всякие СЭДы) используется хранение всяких ворд/эксель документов в filestream, и полнотекстовый индекс по их содержимому поверх всего этого. Есть что-нибудь в таком духе?

Коллеги, если можно, кто знает, буквально по паре слов. По типу: Есть, называется так-то. Если ссылкой ткнете, будет вообще праздник.

Спасибо!

0

resource governor точно нет.
типы поля такие как ворд/эксель нет. НО
есть jsonb и xml, есть двоичные строки( bytea) Эти все типы не больше гига.
Если надо большие документы - пилите отдельный(иначе будет плохо) кластер postgres с большими объектами(LOB), а лучше распределёнку с оными И поисковую базу по этому всему.
По поводу индексации по содержимому таких полей -- с двоичными данными облом, а вот эксемель и джисон вполне можно протянуть индексацию, причём разную.
Что такое Clustered columnstore ХЗ, но postgres умеет физически упорядочивать таблицу по первичному ключу, неважно, какой он. Можно ваще функцию от нескольких полей запилить и по ней упорядочить. Но такая функция требует immutable флага. Единственное что -- часто меняющуюся табличку треба периодически обслуживать
И с этим могут возникнуть проблемы, т.к. оператор блокирующий.

Добавлено через 3 минуты
https://postgrespro.ru/docs/postgresql

Добавлено через 43 секунды
Цэ - гарный мануал.

Добавлено через 5 минут
Вообще, мы мигрировали с mysql(INNODB storage engine) в своё время.
Базы тоже разные.
Скажу сразу, тупая перекладка кода --- сценарий фаталити.
Лучше начинать разработку новой версии с новой субд и продумывать миграцию данных.
И с венды сразу спрыгивать, win это вряд ли надолго.

0

Clustered columnstore - есть раширение timescaledb

0

Сообщение от oktogen двоичные строки( bytea) Эти все типы не больше гига. Если надо большие документы - пилите отдельный(иначе будет плохо) кластер postgres с большими объектами(LOB), а лучше распределёнку с оными И поисковую базу по этому всему.

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

0

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

0

Сообщение от oktogen типы поля такие как ворд/эксель нет. НО

Не, это и MSSQLSERVER не умеет. Ну, точнее, храни, пожалуйста, как varbinary(max), и всё.
Он умеет, с помощью штатного механизма, залазить внутрь бинарников (txt, doc, docx, xls, rtf, pdf (генерированных, а не сканированных), html, xml, json) - и строить полнотекстовые индексы по их содержимому. И искать, соответственно, с помощью contains, очень быстро.

Сообщение от Рыжий Лис Хранить блобы в базе плохая идея (сразу и размер пухнет и нагрузка на СУБД бешеная при чтении). Какой-нибудь оракл, может, и потянул бы. Обычно хранят в базе лишь идентификатор файла или полный путь в файловой системе до него.

А сами блобы хранить в базе, но как бы вне ее. В контейнерах Filestream. В базе, поле с блобом (Varchar(max) или Varbinary(max)) помечаешь как Filestream, и СУБД начинает хранить содержимое этих полей в виде файлов, в папочке, на локальном диске. И не тащит всё это в память, пока не попросишь.
Там куча недостатков, конечно. Например, нужно отключить на томе всякие проверки, индексирование, создание 8.3 имен, отслеживание времени последнего доступа. Нужно следить, чтобы в каталоге не скапливалось больше 300 тыс. файлов, иначе будет подтормаживать, т.е. если вы хотите хранить 2 миллиона файлов, например, нужно чтобы каталогов было 10 (правда это просто настроить, только если завел, например один - то добавив еще 10 - фиг мигрируешь туда файлы, без головной боли). И еще, всё это богатство бэкапится вместе с базой, поэтому если у тебя там миллионов 10-20 документов - то бэкап будет длится сутки.
Зато прямо из СУБД можно оперировать со всем этим делом. И память не занимает.
У нас товарищи, которые писали систему электронного документооборота - активно этим пользовались.
Теперь думаем, что с этим делать.

Сообщение от oktogen Что такое Clustered columnstore ХЗ, но postgres умеет физически упорядочивать таблицу по первичному ключу, неважно, какой он. Можно ваще функцию от нескольких полей запилить и по ней упорядочить. Но такая функция требует immutable флага. Единственное что -- часто меняющуюся табличку треба периодически обслуживать

Clustered columnstore - это другой способ хранение данных в базе, не как обычная таблица или куча rowstore. Т.е. это не бинарное дерево из записей. Оно как то хранит значения по столбцам, дедублицируя и сжимая в них значения.
В результате, физический размер данных на диске меньше, чем у обычной таблицы в 7-8, а если пометить как clustered columnstore archive - то в 9-12 раз. У нас есть, например, в одном из проектов, табличка с 2,2 млрд. записей, которая в обычном виде, даже с построчной компрессией, занимает 1,8 Тб, а в виде колумнстора - 120 Гб, и вполне себе живенько работает, в порезанном на секции, конечно, виде.
Всякие агрегаты по этой штуке - считаются мгновенно. Count(field), count(distinct field), sum(field), max(field) - вообще огонь. Но, оборотная сторона медали, заджойнить эту табличку с чем-то - боль.
В колумнсторе не производится поиск, он всегда сканируется целиком. Поэтому, например, никакой запрос с джойном в табличке см. выше, не длится менее 2 минут (время сканирования колумнстора), если не предпринять какие то специальные действия, например - явным образом не исключить секции, добавив where по ключу секционирования.

Тоже, непонятно куды бечь.fte65, спасибо, попробуем ковырнуть.

Сообщение от oktogen Скажу сразу, тупая перекладка кода --- сценарий фаталити.

Да это то понятно.

0

Уходить от файловых потоков однозначно!
В файловой системе ext4 их нема. А postgresql на win- платформе, мягко говоря, неоптимально работает.
Можно замутить такой механизм, но есть НО.
1)Треба функции дать доступ к диску, к каталогу. И обращаться через этот механизм. И молиться, чтобы не запороть кластер.
2)ХЗ как обеспечить консистентность этих файлов в случае сбоев.

Добавлено через 15 минут
Может, всё-таки стоит подумать, и не увязывать файлы с БД? Замутить файлпомойку, уидники в качестве имени файла в и БД хранить?
Самый дубовый способ на практике часто оказывается проще админить/дорабатывать.

1

Сообщение от uaggster А сами блобы хранить в базе, но как бы вне ее. В контейнерах Filestream. В базе, поле с блобом (Varchar(max) или Varbinary(max)) помечаешь как Filestream, и СУБД начинает хранить содержимое этих полей в виде файлов, в папочке, на локальном диске. И не тащит всё это в память, пока не попросишь.

Понятно, BFILE короче, в терминах оракла.

Тип данных Oracle BFILE — это бизнес-тип данных Oracle, содержащий ссылку на двоичные данные с максимальным размером 4 гигабайт. Oracle BFILE отличается от других типов данных Oracle LOB тем, что его данные хранятся в физическом файле в операционной системе, а не на сервере. Обратите внимание, что тип данных BFILE предоставляет доступ к данным только для чтения.

Про колоночную СУБД: боюсь, вам придётся распиливать проект на три части:
1) реляционная СУБД на постгрессе
2) какая-нибудь файлопомойка, возможно, самописная
3) колоночная БД для аналитики, или что вы там храните. Можно посмотреть в строну ClickHouse

2

Сообщение от oktogen Может, всё-таки стоит подумать, и не увязывать файлы с БД? Замутить файлпомойку, уидники в качестве имени файла в и БД хранить?

Это СЭД. Система электронного документооборота. Там всякие файлы с ЭЦП хранятся, счета от контрагентов и всякие входящие из прокуратуры или минфина.
Там очень больно может если какой-то рассинхрон будет, вплоть до немедленных оргвыводов.
:-(

Ответ Рыжий Лис, наверное, помечу как решение.
По крайней мере, понятно в каком направлении двигаться.
А что-то типа ClickHouse - есть "отечественное"?
Ну, хотя бы столь же "отечественное", как постгресс-про?

0

Сообщение от uaggster Там очень больно может если какой-то рассинхрон будет, вплоть до немедленных оргвыводов. :-(

Тогда блобы надёжнее будут. У нас система Дело на оракле живёт, а так как ничего не удаляется, то база прилично распухла от файлов.

Сообщение от uaggster А что-то типа ClickHouse - есть "отечественное"?

Ну оно было в реестре… https://reestr.digital.gov.ru/excluded/306704/
Не знаю, вроде, опенсурс ещё не запретили.

0

Сообщение от Рыжий Лис Там очень больно может если какой-то рассинхрон будет, вплоть до немедленных оргвыводов.

Тогда держать отдельный postgresql спецом для блобов и только для них. Можно не один такой и не на одной машине.
Возможно, с использованием docker-контейнеров

Добавлено через 1 минуту
Сделать комп, обозвать чем-то типа fucking-blobs-mashine
и обращаться к ней.

0

Сообщение от oktogen Тогда держать отдельный postgresql спецом для блобов и только для них. Можно не один такой и не на одной машине. Возможно, с использованием docker-контейнеров

Блобы через дблинки? Ну такое себе. Проще отдельный диск к машине подключить и хранить таблицу с блобами на этом диске. Тем более, что pg довольно просто хранит датафайлы.

0

На головной машине держать таблицу-справочник-индекс, типа

id	ip	port	datname	local_id	name	description	attr
UUID	INET	INT	VARCHAR(100)	OID	TEXT	TEXT	JSONB

Добавлено через 2 минуты

Сообщение от Рыжий Лис Блобы через дблинки?

Зачем? Можно маршрутизировать. Доступ по тем же ограничениям, что и головная база.

Добавлено через 40 секунд
Зато масштабирование горизонтальное можно замутить.

Добавлено через 1 минуту
Главное, политику безопасТности продумать, шоб по тюрьмам потом не сидеть.

Добавлено через 7 минут

Сообщение от uaggster постгресс-про

Вы зря над этим смеётесь. Контору ведут несколько прямых разрабов postgres.
Некоторые плюшки у коммерческой версии таки есть.

0

Сообщение от oktogen Некоторые плюшки у коммерческой версии таки есть.

Это да, недавно узнал, что автономных транзакций у pg нет. В про версии есть

0

Там много чего интересного
https://postgrespro.ru/docs/en... gpro-vs-pg
А поскольку с "открытыми" исходниками, судя по последним прецедентам,
не всё так однозначно, то свой fork хорошей субды - это неплохо.

0

Сообщение от oktogen Вы зря над этим смеётесь. Контору ведут несколько прямых разрабов postgres. Некоторые плюшки у коммерческой версии таки есть.

Я не смеюсь.
Я к тому, что постгресс-про - это какой угодно, но не не отечественный продукт.
Да, я в курсе, что 30% ядра международного постгресс - это, физически, отечественные разработчики, и, даже, резиденты РФ.
Но, например тот же MSSQLSERVER - он, в чуть меньшей пропорции "отечественной" разработки (правда - нерезидентной), зато чуть менее, чем весь - индийской.
:-)

Но это так, флейма для. Постгресс мне понравился, честно говоря. Думаю, к середине следующего года мигрировать под него чего-нибудь попроще, но массивное. Витрину какую-нибудь.
Отсутствие кластерных колумнсторов конечно, удручает. С другой стороны, жили же мы как-то до 2016 без этого?
Кстати, на Хабре сегодня видел статейку про постраничное сжатие в простгресс-про-энтерпрайз.
Ну, тоже хлеб.

Не по теме вопрос. Для администрирования посгресс что-то лучше DBeaver есть?
Может платное?

Добавлено через 1 минуту

Сообщение от Рыжий Лис Это да, недавно узнал, что автономных транзакций у pg нет. В про версии есть

А это что за зверь, позвольте полюбопытствовать?

0

Видел лично двух ключевых разрабов, с тех пор у них неплохой коллектив последователей образовался.
А если у тебя есть коллектив толковых разработчиков и исходники, то продукт по-факту твой, ну или страны, если угодно.
Мало ли кто его писал.

Сообщение от uaggster Не по теме вопрос. Для администрирования посгресс что-то лучше DBeaver есть?

OMNI-DB относительно неплох. Для маленьких баз хорош ems-sql manager for postgresql (freeware edition).
Я использую DBeaver, связку консольного psql + аналог notepad++.
Проблем ваще никаких.

Сообщение от uaggster А это что за зверь, позвольте полюбопытствовать?

Возможность в транзакции начинать другую транзакцию. Штука редко нужная, отсутствие rкое-как обходится расширением dblink.

0

Сообщение от oktogen Возможность в транзакции начинать другую транзакцию. Штука редко нужная, отсутствие rкое-как обходится расширением dblink.

В смысле, чтобы изнутри транзакции чего-то зафиксировать вовне, но чтобы это не откатилось при откате внешней транзакции?
Так часто логирование какое-нибудь делают. Или информацию для отладки какую-нибудь пишут.
В MSSQLSERVER, обычно рисуют linked server сам на себя, и шлют на него.
А PostgressPro enterprise, значит, умеет без костылей?
Интересно интересно!

0

Я этот механизм не пробовал(postgrespro не ставил).
Обходился dblink.

Добавлено через 33 секунды
Возможно, пошустрее работает.

0

Еще вопрос возник, может кто сталкивался...
А темпоральные таблицы в каком-нибудь варианте постгресса есть? Внезапно обнаружили, что эту свежую фичу MSSQL активно используют в одном из проектов.

Темпоральная таблица - это такая, которая хранит все свои изменения, и можно сделать Select данных из таблицы по состоянию на какую-то дату. Т.е. сегодня, например 31.08.2023. Системное версионирование на таблице включено, к примеру, 01.01.2023. Мы можем сделать select из таблицы с указанием даты версионирования 10.08.2023, то результатом будут данные, как если бы мы находились в 10м августа.

Постгресс же версионник. У него такие штуки должны, наверное, из коробки быть?

0