powered by simpleCommunicator - 2.0.40     © 2025 Programmizd 02
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / PostgresSql vs Ent. Postgres
25 сообщений из 54, страница 2 из 3
PostgresSql vs Ent. Postgres
    #40058287
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Надфиль
Maxim Boguk,

Еще вопрос. У меня в базе оракла довольно много BLOB полей.
тут вычитал, дескать blobы сделаны в ПГ мягко говоря не блестяще и лучше храните их где нибудь на ФС, а в базе ссылку.
у меня картинки, и документы в виде пдф, док, ексель и т.д. присутствуют в большом количестве.
прочел здесь
https://wiki.postgresql.org/wiki/Oracle_to_Postgres_Conversion
в разделе про blob

или я наткнулся на "наскальные надписи предков" и уже все совсем не так?


Блобы в pg держать можно... имею под рукой базу на 5TB где 95% это блобы и bytea и как то шевелится.

Но НЕ НУЖНО, не надо из базы делать файловую систему.
Не нужно - в данном случае экономически по overhead на оборудование будет неоправданно на хоть сколько то тяжелых базах и обьемах файлов.

И это не зависит от того насколько вся блестяще сделано, просто база это база а файлы это файлы.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
PostgresSql vs Ent. Postgres
    #40058303
Надфиль
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
yob

так вот каждый ДБА обрастает набором рабочих скриптов, которые использует для решения конкретных прикладных задач и проблем. Исходя из этой логики Drop view при изменении поля вносится в список рабочих скриптов/фич/не знаю, хранится под рукой и не вызывает проблем.

да есть уже "скрит" для этого, у этих вьюх тоже может быть куча зависимостей. часто это далеко не конченый объект, лично я вьюхи терпеть не могу в любой базе)
вопрос был связан с тем что при смене типа поля, все гораздо более сложные и важные объекты "сами" перестраиваюются без проблем. индексы, функции, процедуры. с сраные вьюхи даже не дают это сделать.
...
Рейтинг: 0 / 0
PostgresSql vs Ent. Postgres
    #40058309
Надфиль
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Maxim Boguk

Блобы в pg держать можно... имею под рукой базу на 5TB где 95% это блобы и bytea и как то шевелится.

Но НЕ НУЖНО, не надо из базы делать файловую систему.
Не нужно - в данном случае экономически по overhead на оборудование будет неоправданно на хоть сколько то тяжелых базах и обьемах файлов.

И это не зависит от того насколько вся блестяще сделано, просто база это база а файлы это файлы.

я немного о другом спросил, блобы действительно мешают делать бэкапы?
пока врядли нам будет дело до переноса блобов в ФС. их много и они нужны, но не часто, поэтому пока полежат там где они есть.
вопрос насколько они отравят мне жизнь?
у нас будет мощный сервер с хранилкой на ССД.
...
Рейтинг: 0 / 0
PostgresSql vs Ent. Postgres
    #40058312
Фотография mefman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Надфиль
Maxim Boguk

Блобы в pg держать можно... имею под рукой базу на 5TB где 95% это блобы и bytea и как то шевелится.

Но НЕ НУЖНО, не надо из базы делать файловую систему.
Не нужно - в данном случае экономически по overhead на оборудование будет неоправданно на хоть сколько то тяжелых базах и обьемах файлов.

И это не зависит от того насколько вся блестяще сделано, просто база это база а файлы это файлы.

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

вот уж не думаю что они как-то особенно мешают.
...
Рейтинг: 0 / 0
PostgresSql vs Ent. Postgres
    #40058320
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Надфиль
Maxim Boguk

Блобы в pg держать можно... имею под рукой базу на 5TB где 95% это блобы и bytea и как то шевелится.

Но НЕ НУЖНО, не надо из базы делать файловую систему.
Не нужно - в данном случае экономически по overhead на оборудование будет неоправданно на хоть сколько то тяжелых базах и обьемах файлов.

И это не зависит от того насколько вся блестяще сделано, просто база это база а файлы это файлы.

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


Тут вопрос в том что снять backup (base_backup) базы не затягивая в него blobs все оптом - не получится.
Поэтому если у вас в базе гигабайт данных и терабайт почти никогда не изменяемых файлов - у вас на каждый base backup будет этот самый терабайт копироваться... нагружая и диски и сеть и требуя изрядно времени и места на backup и/или аварийное восстановление.
Технически проблем нет просто сильно больше сети и оборудования надо.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
PostgresSql vs Ent. Postgres
    #40058332
Фотография mefman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Maxim Boguk
Надфиль
пропущено...

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


Тут вопрос в том что снять backup (base_backup) базы не затягивая в него blobs все оптом - не получится.
Поэтому если у вас в базе гигабайт данных и терабайт почти никогда не изменяемых файлов - у вас на каждый base backup будет этот самый терабайт копироваться... нагружая и диски и сеть и требуя изрядно времени и места на backup и/или аварийное восстановление.
Технически проблем нет просто сильно больше сети и оборудования надо.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru

ну это для любой РСУБД верно.
...
Рейтинг: 0 / 0
PostgresSql vs Ent. Postgres
    #40058333
Павел Лузанов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Надфиль
...вопрос был связан с тем что при смене типа поля, все гораздо более сложные и важные объекты "сами" перестраиваюются без проблем. индексы, функции, процедуры. с сраные вьюхи даже не дают это сделать.

Из любопытства. А какие у вас причины менять тип столбцов таблицы? Не размерность varchar увеличивать случаем?
...
Рейтинг: 0 / 0
PostgresSql vs Ent. Postgres
    #40058334
yob
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yob
Гость
Надфиль
yob

так вот каждый ДБА обрастает набором рабочих скриптов, которые использует для решения конкретных прикладных задач и проблем. Исходя из этой логики Drop view при изменении поля вносится в список рабочих скриптов/фич/не знаю, хранится под рукой и не вызывает проблем.

да есть уже "скрит" для этого, у этих вьюх тоже может быть куча зависимостей. часто это далеко не конченый объект, лично я вьюхи терпеть не могу в любой базе)
вопрос был связан с тем что при смене типа поля, все гораздо более сложные и важные объекты "сами" перестраиваюются без проблем. индексы, функции, процедуры. с сраные вьюхи даже не дают это сделать.

1) Здесь вопрос в архитектуре и решается на стадии проектирования, но да, момент есть с некоторым неудобством имеется, иногда случаются сюрпризы
2) Используете систему контроля версий и без проблем отслеживаете зависимости с последующей выкаткой
...
Рейтинг: 0 / 0
PostgresSql vs Ent. Postgres
    #40058336
Надфиль
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Павел Лузанов

Из любопытства. А какие у вас причины менять тип столбцов таблицы? Не размерность varchar увеличивать случаем?

в основном изза немного кривой работы утилиты ora2pg, ни сразу увидел, что оно очень многие типы полей передало не так как нам нужно
numeric почти везде и без размера.
или float/double и тд там, где нужно с точкой и несколькими знаками после запятой.
ну и, кроме того, захотелось сделать для справочников маленьких в качестве ид инт2,
для вещей побольше инт4.
для совсем больших идешек инт8
я об этом в тайне мечтал на оракле).
...
Рейтинг: 0 / 0
PostgresSql vs Ent. Postgres
    #40058337
Надфиль
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
yob

1) Здесь вопрос в архитектуре и решается на стадии проектирования, но да, момент есть с некоторым неудобством имеется, иногда случаются сюрпризы
2) Используете систему контроля версий и без проблем отслеживаете зависимости с последующей выкаткой

1. система не с нуля же. и у нас обычно проектирование, написание, тестирование, деплой сводится к технологии "херак/херак и в продакшен"))
2. обычно выкатка "изменений" у нас заключается в "собственники решили, что теперь ценообразование целиком зависит от погоды в Гондурасе, но если нам не понравится, то прям вчера поменяйте на столетний прогноз погоды по Антарктиде".
и это боль чтото поменять в базе на которой нет серьезной нагрузки глубокой ночью с субботы на воскресенье.
...
Рейтинг: 0 / 0
PostgresSql vs Ent. Postgres
    #40058338
Надфиль
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Maxim Boguk

Тут вопрос в том что снять backup (base_backup) базы не затягивая в него blobs все оптом - не получится.
Поэтому если у вас в базе гигабайт данных и терабайт почти никогда не изменяемых файлов - у вас на каждый base backup будет этот самый терабайт копироваться... нагружая и диски и сеть и требуя изрядно времени и места на backup и/или аварийное восстановление.
Технически проблем нет просто сильно больше сети и оборудования надо.

спасибо.
и как сейчас принято хранить блобы отдельно?
на какой ФС хотябы)
...
Рейтинг: 0 / 0
PostgresSql vs Ent. Postgres
    #40058340
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Надфиль
Maxim Boguk

Тут вопрос в том что снять backup (base_backup) базы не затягивая в него blobs все оптом - не получится.
Поэтому если у вас в базе гигабайт данных и терабайт почти никогда не изменяемых файлов - у вас на каждый base backup будет этот самый терабайт копироваться... нагружая и диски и сеть и требуя изрядно времени и места на backup и/или аварийное восстановление.
Технически проблем нет просто сильно больше сети и оборудования надо.

спасибо.
и как сейчас принято хранить блобы отдельно?
на какой ФС хотябы)


minIO - совсем модно/молодежно
Ceph - модно/молодежно
NFS на нормальном сторадже - сурово по корпоративному
просто файловая система (ext4) + rsync - просто и в лоб (просто надо про backups не забывать)
Amazon S3 и аналоги если в облаке...

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
PostgresSql vs Ent. Postgres
    #40063113
Надфиль
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
а что у нас в PG с джобами?
pg_cron в целом норм, но как быть с джобами, которые работают чаще раза в минуту?
пока ничего кроме как вставить sleep в цикл внутри кода джоба, столько раз, сколько нужно в минуту выполнить(с соответствующей паузой), но это же не фига не освобождает процессор, и джоб будет постоянно занимать ядро. или я ошибаюсь?
спасибо.
...
Рейтинг: 0 / 0
PostgresSql vs Ent. Postgres
    #40063118
Фотография mefman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Надфиль
как быть с джобами, которые работают чаще раза в минуту?

сварить архитектора этого бреда в большом котле.
...
Рейтинг: 0 / 0
PostgresSql vs Ent. Postgres
    #40063121
Надфиль
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
mefman

сварить архитектора этого бреда в большом котле.

и как благородный дон предлагает решать задачи требующие регулярного асинхроннного внимания с такой частотой?
например, большой склад, на место упаковки приезжаю с помощью конвеейра "тазики" с набранным товаром для одного заказа,
тазика от 1 до несколких сотен, когда "приехал" весь заказ мы, образно говоря, должны подсветить тазики одного заказа, при условии, что упаковщик собрал предыдущий подсвеченный заказ. тазики доставляться могут на место упаковки разными способами,
упаковываться тоже (с пересчетом или без например). ну и показалось, что проще раз в 10 секунд оценить "прибытие" заказов и освобождение там мощностей на упаковку, чем определять это после каждого значимого действия. помоему не плохое решение.
первоначально было, кстати, с большИм интервалом, но было высказано недовольство из за простоя лишнего в полминуты)

и что плохого в джобе раз в 10 секунд?
...
Рейтинг: 0 / 0
PostgresSql vs Ent. Postgres
    #40063129
Фотография mefman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Надфиль
mefman

сварить архитектора этого бреда в большом котле.

и как благородный дон предлагает решать задачи требующие регулярного асинхроннного внимания с такой частотой?
например, большой склад, на место упаковки приезжаю с помощью конвеейра "тазики" с набранным товаром для одного заказа,
тазика от 1 до несколких сотен, когда "приехал" весь заказ мы, образно говоря, должны подсветить тазики одного заказа, при условии, что упаковщик собрал предыдущий подсвеченный заказ. тазики доставляться могут на место упаковки разными способами,
упаковываться тоже (с пересчетом или без например). ну и показалось, что проще раз в 10 секунд оценить "прибытие" заказов и освобождение там мощностей на упаковку, чем определять это после каждого значимого действия. помоему не плохое решение.
первоначально было, кстати, с большИм интервалом, но было высказано недовольство из за простоя лишнего в полминуты)

и что плохого в джобе раз в 10 секунд?

Такую логику в современной it уже не реализуют на уровне БД.
Так что тут - только убить архитектора апстену.
...
Рейтинг: 0 / 0
PostgresSql vs Ent. Postgres
    #40063134
Надфиль
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
mefman

Такую логику в современной it уже не реализуют на уровне БД.
Так что тут - только убить архитектора апстену.

ладно я ему передам, но во первых работает хорошо уже не один год на нескольких складах.
а во вторых я спросил не об этом.
...
Рейтинг: 0 / 0
PostgresSql vs Ent. Postgres
    #40063156
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Надфиль,

Мне кажется, что ваша задача по описанию подходит под описание именно очереди.
Для обработки очередей есть PGQ.

В любом случае, вам не обязательно тащить всё в базу.
Можно планирование вынести отдельно (в ОС, или в свой софт) и просто дёргать процедуры (или запросы) по расписанию.
...
Рейтинг: 0 / 0
PostgresSql vs Ent. Postgres
    #40063623
Надфиль
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Еще вопрос, если можно.
файловая система под ПГ?
хранилка на 10 Тб на ССД дисках, как ее лучше "утилизировать" под постгрес?
...
Рейтинг: 0 / 0
PostgresSql vs Ent. Postgres
    #40063660
Фотография mefman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Надфиль
Еще вопрос, если можно.
файловая система под ПГ?
хранилка на 10 Тб на ССД дисках, как ее лучше "утилизировать" под постгрес?

xfs/ext4 - принципиальной разницы нет
...
Рейтинг: 0 / 0
PostgresSql vs Ent. Postgres
    #40063817
Гулин Федор
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Надфиль
Павел Лузанов

Из любопытства. А какие у вас причины менять тип столбцов таблицы? Не размерность varchar увеличивать случаем?

в основном изза немного кривой работы утилиты ora2pg, ни сразу увидел, что оно очень многие типы полей передало не так как нам нужно
numeric почти везде и без размера.
или float/double и тд там, где нужно с точкой и несколькими знаками после запятой.
ну и, кроме того, захотелось сделать для справочников маленьких в качестве ид инт2,
для вещей побольше инт4.
для совсем больших идешек инт8
я об этом в тайне мечтал на оракле).


ну мне кажется что в данном случае правкой начальной DDL и все.
да я тоже люблю экономить место для ключей (правда больше в OLAP системах там это оправданно)
но да даже банальное изменение размера Varchar() приводит к необходимости пересоздавать вью
(опять же если данные будут закачиваться по новой - можно менять начальную DDL)

Если нет да drop/create View - мне тоже не нравится и НЕ удобно.
Но по сравнению с другими проблеами (как перевод оракл. пакетов , XML индексы в оракле ) это такамя МЕЛОЧЬ.
...
Рейтинг: 0 / 0
PostgresSql vs Ent. Postgres
    #40066811
Надфиль
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Еще вопрос, если можно.
1 Тб ОЗУ, база обычное ОЛТП, хранилка на ССД.
как лучше память организовать?
...
Рейтинг: 0 / 0
PostgresSql vs Ent. Postgres
    #40067003
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Надфиль
Еще вопрос, если можно.
1 Тб ОЗУ, база обычное ОЛТП, хранилка на ССД.
как лучше память организовать?


по большому счету на этот вопрос есть 3 школы
1)8GB shared_buffers (мне кажется эта школа сильно устарела)
2)25% shared_buffers (256GB)
3)75-90% shared_buffers (700-900GB)

для 2 и 3 обязательно huge pages включать иначе будет печально

выбор между 2 и 3 определяется влезет основной work set вашей базы в 3) или он заведомо больше чем...
я бы начал с варианта 3) имея такой сервер.


--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
PostgresSql vs Ent. Postgres
    #40067076
Надфиль
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Maxim Boguk

по большому счету на этот вопрос есть 3 школы
1)8GB shared_buffers (мне кажется эта школа сильно устарела)
2)25% shared_buffers (256GB)
3)75-90% shared_buffers (700-900GB)

для 2 и 3 обязательно huge pages включать иначе будет печально

выбор между 2 и 3 определяется влезет основной work set вашей базы в 3) или он заведомо больше чем...
я бы начал с варианта 3) имея такой сервер.

Спасибо.
я вчера распределил по второму пути)
переделаю наверно на 3-й. У нас еще большая нагрузка от коротких сессий из интернет магазин и мы предоставляем АПИ(через веб запросы) к базе.

huge pages это обязательно при памяти больше 4Гб, ну у меня такое правило)
мало того что таблица адресов небольшая, эта память еще и не свапится никогда.
...
Рейтинг: 0 / 0
PostgresSql vs Ent. Postgres
    #40067161
Фотография mefman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Надфиль
Maxim Boguk

по большому счету на этот вопрос есть 3 школы
1)8GB shared_buffers (мне кажется эта школа сильно устарела)
2)25% shared_buffers (256GB)
3)75-90% shared_buffers (700-900GB)

для 2 и 3 обязательно huge pages включать иначе будет печально

выбор между 2 и 3 определяется влезет основной work set вашей базы в 3) или он заведомо больше чем...
я бы начал с варианта 3) имея такой сервер.

Спасибо.
я вчера распределил по второму пути)
переделаю наверно на 3-й. У нас еще большая нагрузка от коротких сессий из интернет магазин и мы предоставляем АПИ(через веб запросы) к базе.

huge pages это обязательно при памяти больше 4Гб, ну у меня такое правило)
мало того что таблица адресов небольшая, эта память еще и не свапится никогда.

вот на 4 Гб не заменил выгоды. На сотнях - мастхев.
...
Рейтинг: 0 / 0
25 сообщений из 54, страница 2 из 3
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / PostgresSql vs Ent. Postgres
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]