После 11 месяцев разработки опубликована новая стабильная ветка СУБД PostgreSQL 16. Обновления для новой ветки будут выходить в течение пяти лет до ноября 2028 года. Поддержка PostgreSQL 11.x, самой старой из поддерживаемых веток, будет прекращена 9 ноября...Подробнее: https://www.opennet.me/opennews/art.shtml?num=59758
А ещё 25 сентября будет PGConf.СПб 2023
https://pgconf.ru/202309Был на PGConf.Siberia 9 сентября в Томске. Было интересно.
посмотрел списог докладов… в очередной раз переливание из пустого в порожнее. ну чисто в Питер тупо сьездить потусить…
Я тоже ничего не понимаю. Глупый сликшом. Но об этом никому не говорю. Только на опеннетике ною, а на конференциях с умным лицом сижу и киваю
Насчет того что ничего не понимаешь - согласен. А вот насчет тоже - ты себе льстишь. Тут ты в одиночестве...
это ты себе льстишь - как раз тут, с такими как ты, он на месте, в компании равных
лесом
Долгих лет проекту!
Иначе MS и Oracle все под себя подгребут.
в РФ этим места уже нет
https://opennet.ru/59461-mysql
В РФ эти https://www.postgrespro.ru/
Как будто что-то плохое.
Монополия это всегда плохо.
В РФ монополия уже... на PostgreSQL, так как всякие ораклы уже не доступны
Оракл и МС почти не конкурируют, слишком уж разные весовые категории. С Оракла по всему миру народ побежал -- дорого очень стало. Прям вот совсем дорого. И раньше за каждый чих гребли, но альтернативы никакой вообще не было. А теперь хоть что-то есть. Хотя, конечно, не аналог и близко.
Никуда народ не побежал, скорее, в облака начал мигрировать - это удобно, и расходы размазываются во времени.Цена, конечно, выросла, но где-то коррелирует с инфляцией. У Оракла другая проблема - иной раз он слишком монструозен, перенасыщен функциональностью, не всем она нужна. И стабильность работы оставляет желать лучшего: из квартала в квартал огромная куча багов и дыр закрывается, но всё равно что-то остаётся на следующий период.
Техподдержка часто любит отмораживаться, что бесит очень и очень сильно порою. Как-то десять месяцев доказывал, что это у них баг в СУБД, а не у нас всё тормозит, и мы настроить не можем правильно. Доказал в итоге. Но столько времени на это угробить...
Бег в облака как раз бег с Оракла.
За базовый ценник Оракл, мягко скажем, не перенасыщен функциональностью.
Что настроить, чтобы не пухли базы?
индексы не строить по низкоселективным данным и вакуум агресивным
Чисти
pg_repack в помощь тебе, брат!
VACUUM
> Что настроить, чтобы не пухли базы?dd if=/dev/rtfm of=/dev/head
Не пользуйте базу, не будут пухнуть
Настроить ACL deny all
Потом идти спать, отключив телефон
логическую репликацию с 1с уже подружили?
Есть серьёзные базовики с БД размером не со флэшку? - У постгреса есть перспективы на рынке серьёзных БД, или это поделка профессоров-студентов, годящаяся на записную книжку.
Ниче не понятно, но очень интересно.
Покажешь флешку на три терабайта?
https://www.amazon.com/SABRENT-External-Aluminum-Transfer-SB...
Он на три просил.
>Есть серьёзные базовики с БД размером не со флэшкуЭксплуатация СУБД это не только "размер". У меня уже лет 10 назад была Монга ТБ на 6-10. Но это ж не значит, что там мегахайлоад.
Skype с самого начала на постгресе. Сойдёт?
У MS куча системных программистов в штате. Обычный энтерпрайз такими ресурсами не обладает. Поэтому так себе пример.
Вот и выросло поколение, которое не знало Скайп без Майкрософта
Сначала себе что-то придумаем, а потом иронизируем на эту тему. Ох уж эти поколения.
Размер базы не показывает её серьёзности.
Постгрес по сути единственное SQL решение на рынке которое имеет смысл рассматривать.
Но надо понимать что контрибьютят в нее для себя. Т.е. контрибьютят серьезно, но что-то может выглядеть костыльно или недоделанно. Не потому что криво и косо, а потому что разработчику больше и не нужно было, а дальше никто не подобрал (обычно это не критичные вещи). Какие-то вещи на ней лучше не реализовывать(например если нужен мастер-мастер). Какие-то вещи решаются не из коробками (pg_repack например) или не слишком очевидны или удобны.
Эта БД в которую стоит вложить кучу времени и оно окупится. Т.к. SQL вариантов по сути нет (mysql слился за редкими специфическими случаями, проприетарщина для дегенератов) то это вложение однозначено стоит сделать (но в некоторых случаях стоит отдать предпочтение специализированным решениям вроде clickhouse или timescale или noSQL).
Осиливает хайлоад? Да. Масштабируется? Да. Без костылей? Нет. Из коробки? Нет. Просто настроил и работает? Скорее всего нет. Потребуется изучать документацию? Да и только ее недостаточно. Потребуется изучать код? Да. Потребуется изучать принципы работы? Да. Есть неочевидные вещи? Предостаточно. Жрет ресурсы? Нет, весьма экономична при правильной настройке, но есть специфические кейсы. Удобно пользоваться? Нет. Продакшн энтерпрайз риди? Да
> ридирэди
>рэдиготова
продакшен энтерпрайз риди только оракл. Кейс из опыта - ПАК от оракла, БД 150Тб
Постгря - маленький оракл, с фишками доя энтерпрайза на уровне 9 версии (щас за 20 уже). Но допилят, думаю себе
Я правильно понимаю что 149.999Тб можно было выгрузить в текстовый файлик, сжать и убрать на дальнюю полку? Но все равно держим в базе т.к. данные важные, база сертифицирована и "потому что могу".
Если нет, расскажите подробнее как вы ей пользуетесь. Очень интересно. Спасибо.
Удивляет постановка вопроса "жрет ресурсы". Нормальная СУБД и должна максимально утилизировать имеющиеся аппаратные ресурсы для максимально быстрого выполнения запросов. Помню, как старые версии MySQL из-за идиотского кэша запросов с глобальной блокировкой (хорошо хоть отключаемого в настройках) "экономил" ресурсы, находясь большую часть времени в ожидании освобождения лока.
Некоторые бд изначально хотят миниум среднюю тачку (тот же эластик) и кластер на среднем ноутбуке в виртуалках уже не поместится. Постгря же запускается на калькуляторе и гибко настраивается.
Ну а ресурсы, запросы и требования к времени ответа у всех разное.
а бэкапы когда завезут?
А какие тебе нужны ?
Чтобы можно было восстановить произвольную базу на произвольный момент времени на произвольный инстанс. Бинарно.
Ну как в MS Sql или Oracle :)
Так это решается просто с любым софтом - LXD (контейнеры Linux), а в управлении LXD есть снепшоты и бэкапы
не решается ни разу, т.к. специфика субд - часть измененных данных в памяти. Можно после восстановления такого снапшота получить разваленную или нецелостную БД
вы совсем совсем не понимаете о чем идет речь, да?
Понимаю, речь про наколленные васькины бд
Вопрос был про постгрес, а не про _смекалочку_ и прочие «щи из топора».
PITR? Есть же. Сохраняешь WAL и восстанавливаешься на нужную точку.
Человек спрашивал про отдельную БД, а не про кластер целиком.
А, ну ой, да. Насколько я знаю, тут пока вариантов нет.
Кажется это можно сделать через реплики. Подключаешь реплику, ждешь пока догонит, останавливаешь реплику - вот твой бинарный бэкап, готовый стать мастером в любой момент.
Ну вот есть у вас в кластере две базы, и есть бинарный бэкап с wal-ами... и вот вам надо откатить _только_ ОДНУ базу (!!!) на месяц назад (!!!) подняв ее из бэкапа. Вторая при этом должна работать без перерыва. нельзя кластер останавливать. Ваши действия? в MSSQL это делается как два байта переслать...
У меня немного другое направления. Я никогда не делаю что-то на уровне базы данных. Делать кластер из двух баз даже в голову не приходило.
обычно их там десятки. Это же СУБД. В одном инстансе могут быть десятки разных баз.
"Может быть" - не значит, что это хорошо. Если хотя бы 2 нагруженные БД на одной СУБД и отличаются по структуре и профилю запросов - уже проблема нормально оптимизировать, а если 3 - это как "задача трёх тел" в физике/астрономии - не решаемо вообще.
Одна БД серьёзная, а остальные мелкие довеском - ещё можно. А несколько серьёзных... Сопровождать подобное похлеще, чем секс стоя в гамаке надо пропастью.
Напридумывать можно много экзотических обстоятельств. И очень сложных и творческих. И обобщения этих выдумок до реальных правил - просто нелепость. Есть реальные кейсы, когда относительно небольших баз в кластере много. очень много. А оптимизация о которой вы упомянули... либо плод тех же выдумок, либо давно делается автоматически.
> либо давно делается автоматически.Сочувствую вашим проектам...
Иными словами вы не понимаете что надо делать чтобы запросы работали быстро.
> обычно их там десятки. Это же СУБД. В одном инстансе могут быть
> десятки разных баз.Зачем такое делать? Не в курсе про контейнеры?
про оракловые? в курсе... а линуксовые - каким тут боком помогут?
Нет, как раз обычно в Слоне, когда один экземпляр = одна база. Если вы налепили иначе, то, ну не стоит свой опыт в одних СУБД транслировать на другие.
разработчики с вами не согласны, и именуют "схемы" - "базами". Пойдите разберитесь с ними, че себе позволяют, Вас не слушают...
Понимаешь, так и термин "кластер" или, скажем, "кластерная таблица" в МС, Оракле и Слоне совершенно различное описывают. Ну вообще различное, даже ничего близкого. Я согласен, что этот терминологический ад ясности не добавляет, мягко скажем. Но что поделаешь.
Откройте для себя архив WAL-ов. Ну или хотя бы pg_probackup.
Они помогут восстановить ОТДЕЛЬНУЮ БД (а не ВЕСЬ КЛАСТЕР) на момент времени в прошлом?
> Они помогут восстановить ОТДЕЛЬНУЮ БД (а не ВЕСЬ КЛАСТЕР) на момент времени в прошлом?У меня pg_probackup создаёт каждый день дельту от предыдущей дельты (ну и есть изначальный полный бэкап). И на любую хранящуюся дельту я могу восстановить любую отдельную базу.
С WAL почти не работал напрямую именно в этой части: не могу сказать точно. Меня более чем удовлетворил pg_probackup.
Но отдельные базы мне нужны только на тестовом кластере : продуктивные серьёзные БД стараюсь держать по одной на кластер. Да и восстанавливать терабайты - не быстрое весьма дело: лучше доп.узлом зарезервировать.
>могу восстановить любую отдельную базу.Покажите командрую строку pg_probackup в которой вы указываете для него конкретную базу в момент бэкапа
Покажите командрую строку pg_probackup в которой вы указываете для него конкретную базу в момент восстановления
>>могу восстановить любую отдельную базу.
> Покажите командрую строку pg_probackup в которой вы указываете для него конкретную базу
> в момент бэкапа
> Покажите командрую строку pg_probackup в которой вы указываете для него конкретную базу
> в момент восстановленияБэкапится кластер целиком, а восстанавливается - нужная база (по необходимости):
1) снятие полного бэкапа:
pg_probackup backup -B /_backup/pgsqlbkp --instance=prod -j12 --backup-mode=FULL --compress --compress-level=8 --stream --delete-expired --pguser=u_backup --pgdatabase=db_backup --remote-host=172.16.3.1 --remote-user=postgres
2) снятие дельты:
pg_probackup backup -B /_backup/pgsqlbkp --instance=prod -j12 --backup-mode=DELTA --progress --compress --stream --delete-expired
3) мерж полного бэкапа с дельтой (для движения "окна" глубины хранения):
pg_probackup merge -B /_backup/pgsqlbkp --instance=prod -j12 -i QSIB7Z
4) ну и восстановление конкретной базы db_1 (postgres - для удобства):
pg_probackup restore -B /_backup/pgsqlbkp --instance=prod -j12 --remote-user=postgres --remote-host=172.16.4.2 --db-include=postgres --db-include=db_1Важно помнить, что восстановление идёт (надо делать) в отдельный каталог и уже оттуда базу можно "загружать" в целевой кластер. Чтобы не порушить остальные базы в кластере.
Это как раз тот самый метод про смекалку и кашу из топора.
Вы восстанавливаете полностью кластер на другой путь [НЕ БАЗУ, весь кластер, просто остальные базы при этом восстановлении имеют нулевой размер], и потом каким-то хитрым образом "загружаете"...
Через дамп поди ? :)
Смекалка и каша из топора....Знаете, после нормальных СУБД - это выглядит как откат в каменный век... вместо решения задачи- вам приходится решать ТЕХНИЧЕСКИЕ УСЛОВНОСТИ. Вместо бэкапа- вы делаете последователность странных действий. Когдато это было интересно, но потом такие действия в нормальных базах стали частью скрытой от администратора логики, ввиду абсолютной рутинности и бессмысленности ручного управления ею...
> Это как раз тот самый метод про смекалку и кашу из топора.
> Вы восстанавливаете полностью кластер на другой путь [НЕ БАЗУ, весь кластер, просто
> остальные базы при этом восстановлении имеют нулевой размер], и потом каким-то
> хитрым образом "загружаете"...
> Через дамп поди ? :)
> Смекалка и каша из топора....pg_dump ... | psql ...
Но всё достаточно легко заворачивается в скрипт и работает не чавкая.
> Знаете, после нормальных СУБД - это выглядит как откат в каменный век...
Какие СУБД вы называете нормальными? Оракл, вероятно. Немного сталкивался и лично у меня тоже не мало вопросов к нему (правда там я вообще без понятия, как бэкапы строятся (ну кроме таких же дампов).
Мне энтерпрайзности Оракла хватило, когда кластер без ДБА жить практически не умеет: постоянно надо что-то делать, чтобы работало и не падало (работал с "Борлас" со стороны заказчика). Одноузловая СУБД - работает не плохо. Кластер - нахер надо сопровождать.
У нас на Слонике БД крутятся с минимумом управляющих воздействий. В основном для профилактики и при обновлениях прикладного ПО, для контроля.> вместо решения задачи- вам приходится решать ТЕХНИЧЕСКИЕ УСЛОВНОСТИ. Вместо бэкапа- вы
> делаете последователность странных действий. Когдато это было интересно, но потом такие
> действия в нормальных базах стали частью скрытой от администратора логики, ввиду
> абсолютной рутинности и бессмысленности ручного управления ею...А в чём проблема? Берите централизованную систему резервного копирования, которая будет делать всю рутинную работу. И уж в энтерпрайзе централизованная СРК должна быть, верно?
Вообще-то делать бэкапы прода и пару сотен ТБ - это настолько на крайний случай, о которых в кошмарах вспоминают. А для оперативного резервирования - многоузловой кластер, который и с балансировкой и с горячим резервированием поможет.
Ну и лицензия PostgresPro тоже поможет снять многие проблемы, если что.
> Они помогут восстановить ОТДЕЛЬНУЮ БД (а не ВЕСЬ КЛАСТЕР) на момент времени
> в прошлом?Контейнеризация позволяет восстанавливать отдельную БД. Вообще без проблем, на лету, хоть на подлёте, хоть сбоку, хоть с припёка. Вообще без разницы.
каким образом?
Нет, ты вообще не в теме и даже понятия не имеешь о чём поёшь. В Слоне wal общий на весь кластер, поэтому в Слоне на уровне экземпляр нет отдельных БД, хотя они так и называются. Человека ввело в заблуждение название и мнение, что всё вокруг терминологически так же, как в МС Сиквеле (даже не в Оракле, потому что в Оракле множественные БД на экземпляр появились относительно недавно).
Я на счёт Постгреса не в теме, да. В планах на ближайшее время. Но что мешает организовать одно БД на один кластер? А этих кластеров развести хоть тысячи?? Не понятно.
Ничего не мешает, так и делают типично. Но если ты перешёл с МС, то мешают былые стереотипы.
Штатный PITR есть с 9+ версии. Но вот уровень абстракции "арендных БД" ещё хуже, чем МС. Т.е. отдельную БД восстановить нельзя -- можно только весь кластер.
Зачем нужны какие-то отдельные бекапы?
В "философии unix" программы делают так, чтобы они могли работать совместно с другими программами. В postgres для этого в archive_command нужно прописывать ту программу, которая тебе нравится.
Я например использую для этого walg.
одна схема на инстанс?
А что проблема какая то? Не в курсе про линукс контейнеры или на худой конец докер?
одна база на один контейнер? :)
Смеешься что ли? Одна база на 2 и более инстансов. Сколько деньги позволяют
похоже вы не понимаете что такое база.. шардинг по разным инстансам не является одной базой в терминологии СУБД. это РАЗНЫЕ базы.
Инстанс это не "база". "База" это набор данных на носителе. Инстранс же это набор работающих процессов с памятью, под их работу выделенной. Инстанс вполне себе может и без "базы" жить. Как и база лежать себе без инстанса.
Шардинг термин очень уж гибкий. Это просто разбиение данных по некоторому критерию. Реализовано это может быть сильно по-разному. Могут быть и разные базы разных инстансов, могут быть и вирутальные бд одного одного инстанса, могут быть и разные "таблички" в рамках одной БД или вариант этого же решения в виде секционирования одной "таблички".
> одна схема на инстанс?Какая schema? Это физическая репликация! Какая ей разница за схемы, если схемы = логические структуры над физическими.
Даже в базовые вещи не въезжешь, но даешь советы космической важности и такой же глупости.
В этом ответе все прекрасно. Все комплектом и к одному месту. :)очевидно что вопрос "одна схема на инстанс?" - это насмешка, указывающая на некий общеизвестный недостаток системы. Ну общеизвестен он конечно тем кто в теме.
Вы - походу нет.
Нет, БД не аналог схемы, потому что схемы в Слоне есть. Самые обычные привычные. И схем может быть множество на БД.
> а бэкапы когда завезут?Сколько постгрес помню, столько бекапы и были, еще и разных видов (бинарные, текстовые).
текстовая выгрузка -это не бэкап. Вы конечно можете сделать так и назвать ЭТО бэкапом, но вот вам вопрсо:
как с помощью этой хер.и вы собираетесь делать инкрементный бэкап? а как восстанавливать базу на произвольный момент времени?
да никак. потому что текстовая выгрузка- это НЕ бэкап.То что в постгресе называется бинарным бэкапом- неудобный костыль. Вот у вас в кластере 2 базы. как вы восстановите только одну?
нормально- никак. есть некоторая последовательность действий которую можно совершить, чтобы добиться подобного результата, но....это будет ДРУГАЯ история.
и с этими извращениями можно было бы мириться, если бы не MSSQL. ВОт если бы взрослые базы делали бэкапы так-же- можно было бы развести руками и сказать - ну да, это уебищ.ое действо уу всех так... но ведь нет же. Есть MSSQL, есть Oracle...
Потому что там бэкап восстанавливается на произвольный момент времени, на произвольный кластер, в произвольное место, с релокациями, и независимо от других баз в инстансе... Это - бэкап... а в постгресе- бэкапа нет. есть рак на безрыбье..
Неужели в Постгресе нет журнала?? Хмм.. Хочу почитать про него, но пока времени нет
журнал на весь кластер в целом. нет отдельного журнала на отдельную базу
А в журнале кластера нельзя выбрать базу?? Вот дела...
Тебе - можно. Выбирай.
> А в журнале кластера нельзя выбрать базу?? Вот дела...Да все можно, ыы просто жирный троль. Ты всегда можешь прервать репликацию и раскатить нужные wal логи (он же журнал) на нужной базе. Фактически у тебя станет 2 кластера. И конечно все должно быть настроено https://www.postgresql.org/docs/current/continuous-archiving.... Костыльно, да, но зато не проприетарщина - у оракла свои проблемы и можно начать и закончить на ценовой политике и поддержке в дефолтной стране.
>Фактически у тебя станет 2 кластера.Вам не стыдно рассуждать про торолей? Вы совсем не понимаете что то что вы советуете - такая себе смекалка и совсем не похоже на то что в MSSQL например? Это не решение для продуктовой среды.
>>Фактически у тебя станет 2 кластера.
> Вам не стыдно рассуждать про торолей? Вы совсем не понимаете что то
> что вы советуете - такая себе смекалка и совсем не похоже
> на то что в MSSQL например? Это не решение для
> продуктовой среды.У нас тут еще и антивируса нет. Совсем не продакшн риди, не для продуктовой среды. Катился бы ты к мелкомягким и дальше ел кактус.
ну, у вас может и нет антивируса, соболезную, а Касперский для линукса прекрасно работает.
Не жмотьтесь, купите уже...
Ешь гумно сам, продакшенист экий.
Стесняюсь спросить, тебя в Гугле забанили? Ты из сообщения в сообщение повторяешь неправильную транскрипцию слова "ready". Оно читается, как "рЭди", а не как "риди". Открой гугло-переводчик уже и послушай. Глаза же режет подобное написание: мало что кириллицей, так ещё и исковерканное.Или это такой способ тупого троллинга?
Ой правда что ль? А в Новой зеландии поди и не знайут, нада им рассказать https://youtu.be/m73xUSQVrLI?t=1280
> Продакшн энтерпрайз риди? ДаНет. Разве что в штате есть системные программисты. Но это недешёвое удовольствие.
А иметь в штате системных оракловодов - удовольствие надо полагать копеечное? 😁
Любой Ынтерпрайс прод требует спецов, и они как правило чуток дороже здешних Ыгспертов, что ораклоЕды, что слоноводы, что мсыквуны …
> А иметь в штате системных оракловодов - удовольствие надо полагать копеечное?Нет, разумеется.
Но с Oracle вам надо иметь только админов СУБД и купленную техподдержку. А с PostgreSQL - и админов, и программистов. Если у вас реально очень много экземпляров баз данных в production, такой подход окупится. Но таких предприятий не так уж много. Кроме этого надо учитывать подавляющее превосходство функциональности Oracle над функциональностью PostgreSQL - а это тоже всё денежки.
В каждом случае надо считать. Но, мне кажется, проще и, скорее всего, дешевле Oracle в облаке арендовать (если законодательство и всякие санкции не препятствуют). Админы всё ещё будут нужны, но уже в меньшем количестве.
оракл в россии не ведет бизнес. забудьте
У меня несколько по 2-3 сотни ТБ - пойдёт? С очень серьёзной нагрузкой (вся страна).
Про мелочи в 2-3 ТБ даже не упоминаю...
У коллег есть аналогичные. Вполне себе живут и не чавкают.
25 Тб, одна из баз и что? У нас, к примеру, критичен не размер, а количество пользователей, которые туда ломятся, когда количество пользователей превышает 10 млн, а одновременно лезут 100к, становится интересно.
Лучшая СУБД! (среди PG, Mysql и sqlite)
И чем лучшая ?
Pgbouncer уже не нужен, научились в пул соединений ? Или вакум какие то фишки в плюс добавляет ...
А в чем проблема воткнуть pgbouncer?
Безвакуумный движок есть, но дойдет ли до апстрима, это да, вопрос. Впрочем, это часто некритично.MySQL 8+ неплох, но отсутствие транзакционного DDL по-прежнему создаёт эксплуатационные сложности. Ну не разваливается, как раньше, уже неплохо.
> А в чем проблема воткнуть pgbouncer?Если один хост - ни в чём. Но обычно их намного больше.
> Впрочем, это часто некритично.Это основное критичное слабое звено этой бд
MySQL это Оракл. И не развивается вообще уже лет 8-мь как.
Кто знает, может ли клиент постгреса асинхронно получать сообщения о том, что данные были изменены в базе?
Да, на основе того же механизма logical decoding, на котором работает логическая репликация. См. Logical Decoding Plugins в официальном мануале.
а стандартный notify сильно хуже? или это подвид этих плагинов?
Может. Тут логическая репликация во всей красе. Но только учитывай, что это не даром -- сильно медленней, чем потоковая.
а для некоторых приложений разработчики прямо говорят- для работы негодная
Но она в этом смысле такая же негодная, как и логическая в Оракле.
В чем удобно работать/вторгаться в БД PG под Linux? Программы, не одежда
DBeaver
Работал, пока не наткнулся на неприятный глюк - в какой-то момент стал показывать устаревшие данные, но делал вид, что обновляет. Потратил зря день, снёс и вернулся на неудобный pgAdmin.
У Бобра слишком затейливая настройка (авто)фиксации транзакций. С ним, да, можно нарваться на косяки с тем, что данные тупо не фиксятся/не обновляются.
DbGate - очень приятная штука.
он web? сомнительная приятность
pgAdmin тоже web
psql
вторгайся vi-ем, чтобы доказать нужность дбодмина.
Удобнее всего - через плагин к привычной IDE.
Удобный средств, увы, нет. В Бобре удобно писать код, но есть проблемы с разметкой транзакций. Причём, очень-очень стрёмные проблемы. В pgAdmin-е код писать не удобно совсем, но меньше всяких причуд, хотя и не без них. В навикэте более-менее всё ничего, но тоже есть глюки с транзакциями.
> По умолчанию теперь выполняется сборка с ICU-локалями ("ICU Collation") вместо локали libc.для Case-Insensitive всё ещё требуется citext, или уже можно без него?
Backup с помощью SQL Dump - детский сад. File System Level Backup - database server must be shut down. Но, пионеры продолжают что-там за конкуренцию Ораклу говорить.
Если б только в этом проблемы. Хотя это само по себе важно, конечно.Direct io - не умеет до сих пор, а ведь не у всех SSD диски.
Flashback database с restore points - не умеет. Для больших баз данных - критически важная вещь после каких-нибудь обновлений, могущих закончиться чем-нибудь неприятным.
В кластеры - не умеет.
Для управления стендбаями ничего встроенного нет - тащи костыли со стороны, тестируй потом на свой страх и риск. Потом придёт другой DBA-шник, который с этим инструментом ни в зуб ногой, а потребуется срочно failover сделать - засада на ровном месте.
Vacuum - ущербен, об этом только ленивый не писал. Вроде, начались подвижки в сторону UNDO, как у Оракла, но пока всё в зачаточном состоянии, насколько мне известно.
Пакетов в свободной версии нет, только в энтерпрайзной - вендор-лок, который так не любят местные халявщики. Кто-то может сказать "не нужно". Кому не нужно - пусть не пользуется. Мне - нужно.
Remap схем, пользователей на лету - не умеет, как тот же expdp/impdp в Oracle, пользуйтесь sed-ом в своё удовольствие, и может даже не отгребёте при какой-нибудь некорректной замене.
Для каких-то не особо крупных предприятий, не особо страдающих от возможных простоев СУБД - сойдёт. Ну или если у вас в штате системные программисты есть - тоже сойдёт. Остальным лучше проходить мимо.
Хотя в РФ на безрыбье и Postgres - СУБД.
>Ну или если у вас в штате системные программисты естьа штатные программисты орацля вообще не бывают в природе. поэтому при каждом баге приходится сосат у волшебного оркосаппорта.
p.s. как ви оцениваете поддержку JSON в могучем оракле? по пятибальной.
p.p. s. как ви оцениваете поддержку XML в могучем оракле? по пятибальной.
Зачем в бд поддерхка всякой хрени? Для этого есть уровень приложений.
Возможно потому что БД бывают не только реляционные?
Потому что приложения работают с JSON и XML?
Потому что не все структуры данных удобно раскладываются на реляционную схему?
Если вам не нужна поддержка JSON и XML, то не значит что никому не нужна.
Пихай в clob что хочешь и парсь то посинения хоть json, хоть нет.
> а штатные программисты орацля вообще не бывают в природе. поэтому при каждом баге приходится сосат у волшебного оркосаппорта.А у PGSQL и "сосат" не у кого в таких случаях. Разве что по форумам лазить и плакать до посинения, пока кто не отзовётся, и то маловероятно. Сиди сам ковыряйся в непростом коде, ага. 🤷♀️
Оракл далёк от идеала. Я-то это прекрасно знаю: работаю с ним больше 20 лет уже. И когда-то думал, что хуже этой СУБД быть не может, столько в ней "особенностей". Как же я ошибался, встретив на своём пути PG SQL.> p.s. как ви оцениваете поддержку JSON в могучем оракле? по пятибальной.
> p.p. s. как ви оцениваете поддержку XML в могучем оракле? по пятибальной.Оценить не могу, потому что не пользовался.
А вот кучу разных индексов в Оракле оценить могу. Советников по построению этих индексов тоже могу оценить. И так далее. На мой взгляд, для РСУБД эти плюшки куда как более ценная вещь.
Впрочем, реляционная алгебра у нынешней молодёжи не в почёте - не модно, слишком сложно, давай всё лепить из г-на и палок (читай из тех же JSON и XML). Проектировать и продумывать структуру БД - не царское это дело.
Как там в оракле с настоящей serializable изоляцией? До сих пор write skew не ловит?
Это, наверное, одна из тех "особенностей", про которые я писал в предыдущем сообщении.
Однако же эта "особенность", насколько я понимаю, соответствует стандарту ANSI SQL.https://www.cockroachlabs.com/blog/what-write-skew-looks-like/
Не знаю, мне и то и то -- норм. Вернее, уровень доставляемого головняка более-менее одинаков.
> А у PGSQL и "сосат" не у кого в таких случаях.как то ись не у кого? Вон, импортозамещательный postgrespro спешит на помощь (pedobear.jpg)
cocите на здоровье! (а что оно поможет - вам никто ведь и не обещал)
> Оценить не могу, потому что не пользовался.
работает, но "есть нюансы". Но в целом если тебе не нужна реляционная база данных - так дядьку, и отойдите же от быка, у нас в канаде доют только коров!
нуи собственно фишки энтерпрайз экосистемы - детальный сбор метрик по тысяче статистик и событий ожидания, возможность исторического анализа хоть на два года назад - хоть для подсистем движка СУБД, хоть для сессии, хоть для запроса, инструменты автоматической аналитики и далее по списку
Это, наверное, дорого. Чтобы железо лучше покупали, да?
Наоборот, чтобы на железках можно было экономить.
Это ты про AWR? Часовой срез за два года? Это чтоб на железе сэкономить? ))))))) AWR чаще всего бесполезен, потому что результат проблем либо самоочевиден, либо не устраним. Хотя его наличие утешает, да.
Бэкапер нахер не нужен, наймите опытного девопса. Проблема решается красиво на совсем другом уровне, бэкап в онлайне прямо целиком весь инстанс
> девопсаИ это пройдёт.
Не решается, если в кластере несколько баз данных.
да и point in time recovery не нужен, верно же?
Увы, PITR на БД от десятка 10Т, а это очень скромная БД (типичные продуктовые сильно больше), исключительно умозрительная возможность. Но не ясно в чём тут упрёк Слону. В Слоне PITR точно такой же, как и в Оракле. На фул бэкапа накатываешь журналы до требуемой точки. Но вот флэшбэка в Слоне нет. Вернее, раньше в Слоне он был, а в Оракле не было, потом в Оракле появился, а в Слоне исчез. Флэшбэк удобно бывает. Но, опять же, только на тестовых БД.
я бы сказал что типичность базы в 10Тб исключительно умозрительна. Поскольку массвовый постгрес сейчас где? правильно, в 1с :) а в 1с какие базы типичны? по 10 Тб? как называется тот дуб с какого эта идея рухнула? в 1с кейс выглядит совсем иначе :) базы относительно небольшие, но из много. очень много. десятки и сотни.
1С в жизни ни разу не видел, не знаю что там к чему.
В Постргресе механизм бэкапов ничего не отличается от Ораклового. Только в Постгресе его проще настраивать.
Ну я бы так не утверждал. Начнём с простого. Вот вы работаете с базой и она вдруг навернулась. Сколько данных в потеряете после восстановления?
Собственно только некоторые мехaнизмы из Oracle в pg (например режим ARCHIVE LOG) появились. Но не все.
Ни там, ни там несколько не потеряешь. Причём, в очень широком смысле. Механизмы репликации хоть и устроены несколько иначе, но результат они обеспечивают один и тот же. И там и там есть полная строгая синхронная репликация, есть нестрогая репликация. Выбирай на вкус.
Вернее, нисколько, сорян.
А откуда возьмутся не успевшие синхронизироваться транзакции?
Это при двойных затратах на железо. Это заведомо хуже, чем обычный archive log или stand by.
Что это за "не успевшие синхронизироваться транзакции"? При синхронной репликации транзакция фиксится только, когда стэнбай пришлёт подтверждение разной степени гарантированности, что данные он получил/записал/проверил/накатил. Тут нет никаких "не успевших". Тут между Ораклом и Слоном разница только косметическая. Ты выше сокрушался, что в Слоне аналога брокера репликации нет, так вот, их несколько и каждый из них вполне норм. Точно не хуже ораклового брокера. Вот аналога ADG, вроде как, пока в Слоне нет, но тут я не уверен.
Или ты о преимуществах флэшбэка? Ну про флэшбэк спору нет. Удобно. Но его типичное применение это создание временных снапшотов БД для различных нужд, а резервное копирование/восстановление. Всё же, восстановление БД вне теста явление крайне-крайне редкое.
26.3.4. Recovering Using a Continuous Archive Backup раздел просто прекрасен, особенно:
...
9. Inspect the contents of the database to ensure you have recovered to the desired state. If not, return to step 1Успехов в восстановлении террабайтных баз из бекапов и инспекции содержимого.
А, молодец, дочитал мануал до Continuous Archiving.Это к любому восстановлению после бэкапа относится. То, что в мануале на какой-нибудь Xtrabackup этого не написано, не означает, что ты гарантированно получишь ожидаемое. Таких гарантий, сюрприщ, не намт ничего, кроме систем, основанных на блокчейне.
Предлагаю подумать, как сделать так, чтобы это было относительно легко проверить.
За complete recovery в Орацле прочитай, потом комменты раздавай.
У Оракла есть такое понятие, как SCN - system change number. И вот можно хоть на это атомарное событие восстановить, хоть на любой момент времени в прошлом (в пределах backup policy).А ещё есть flashback database with restore points. Создаёшь точку восстановления до начала какого-то потенциально опасного события, и восстанавливаешь на момент её создания огромную БД за считанные минуты потом, случись что неприятное.
Ещё в Оракле можно отдельные сбойные блоки восстанавливать, если они по какой-то причине испортились. При этом полное восстановление БД не требуется. Офигенно время экономит, если БД большая.
Можно также отдельные таблицы восстанавливать на момент в прошлом.
Можно запрос на определённый момент времени в прошлом построить, посмотреть, какие тогда данные были в таблице (flashback query).
Что из этого всего есть в PG SQL?
Это?
https://www.postgresql.org/docs/current/continuous-archiving...
Так человек выше написал же, что целостность не гарантируется. Предлагается как-то на глаз это оценивать. Или я что-то не так понял?
В постгресе LSN точно то же самое. Только никто не рассказывает, что его совпадение гарантирует целостность данных. Потому что, сюрприз, оно ничего не гарантирует нигде.
Почему же? В Оракле - гарантирует вообще-то. Пока транзакция не подтверждена, нет нового SCN.
И какое это отношение имеет к целостности бэкапа?
LSN в PostgreSQL - это не то же самое, что SCN, насколько я понимаю.LSN in PostgreSQL stands for Log Sequence Number. It is a 64-bit integer that uniquely identifies a position in the Write-Ahead Log (WAL). The WAL is a sequential file that records all changes made to the database, even uncommitted ones.
SCN в Oracle - это или подтверждённая, или отменённая (rollback) транзакция, или DDL-операция.
Почувствуйте разницу.
Разницы нет никакой. Кроме того, что LSN это циркулярный счётчик, а SCN линейный. А так, тоже самое -- метит любое значимое изменение БД.
Как же нет? LSN действительно отмечает ЛЮБОЕ изменение (даже неподтверждённую транзакцию). А SCN - только ПОДТВЕРЖДЁННОЕ.
Транзакции тут вообще не причём. Любой хронологической БД нужен счётчик изменений. Транзакция не синоним изменения. Как при этом этот счётчик организован вопрос важный, но важным тем, кто их проектированием занимается.
Любое изменение данных в БД - это зафиксированная транзакция. Транзакция которая не получила commmit никакие изменения вносить а БД не может. В этом смысл процесса двухфазной фиксации. Без этого механизма деньги правильно посчитать не получиться.
Афигеть ты мудростями сыплешь.
Это не так. Есть изменения, которые происходят не в рамках прикладных транзакций. Эти изменения тоже в Слоне счётчик инкрементируют (как и, например, в МС). Но это всё скучные подробности. Они ни прикладного админа, ни разраба не касаются.
Не бывыет никаких "прикладных транзакций".
Не бывыет никаких "прикладных транзакций".Операции DDL и обращение к счетчикам это тоже тразакции.
И у них есть номер, начало транзакции и звершение.Всё что вы делаете на SQL - транзакции.
На SQL ничего не делается вообще. В потрохах БД полно операций, которые приращают счётчик и юзают его значения, но к обслуживанию прикладных запросов никакого отношения не имеют. Доступ к счётчику так или иначе во всех СУБД выведен и на прикладной уровень, но это просто обёртка. Но, ещё раз, эта внутренняя кухня нужна только тем, кому... нужна.
Нет, SCN генерится последовательно по требованию, а не в момент фиксации. Поэтому-то в фиксированных SCN бывают пропуски.
Не пугай людей. Обычный чек гарантирует, что кусок журнала нормальный. И по восстановлению получишь то, что было. Если не было между бэкапом и восстановлением злонамеренного манипулирования данными.
Мальчики, не ссорьтесь. Бэкап на лету, инкрементный делается на другом уровне абстракции
Сам то понял? Или абы шо ляпнуть
Для отдельной БД внутри кластера не делается никак ни на каком уровне (если мы говорим о PostgreSQL).
Делается, только очень уж затейливо. Можно сделать через логическую репликацию. Но вообще, в Слоне общее правило как в старом Оракле: один экземпляр -- одна БД. В Оракле же жили до 12-той версии с одной БД и не жужжали.
Бэкапы на "горящую", в том числе и инкрементальные, давно делаются без каких-либо приседаний.
А восстановить отдельно взятую БД оттуда как? Не целый кластер, а именно отдельно взятую БД.
Ну смирись с тем, что в Слоне такого явления, как "отдельная БД" нет. В слоен БД это просто раздел в в общем пространстве имён. Работать это не мешает. Это обычно мешает тем, кто с МС Сиквела перешёл -- для них это чудесато выглядит (хотя в МС отдельная БД тоже не отдельная). После старого Оракла же вполне привычно.
> А восстановить отдельно взятую БД оттуда как? Не целый кластер, а именно
> отдельно взятую БД.Пробекапом
> Разрешено использование в числах символа подчёркивания для повышения наглядности цифровых литералов. Например "SELECT ... WHERE a > 1_000_000"О! Это круто! Во всех бы языках такое добавили
В C++ добавили.
Rust, Python - там это есть.
а джавовские линтеры иногда даже ругаются если такое не используешь
Вакуум когда уберут? Впечатление что эта постгре застряла в нулевых.
ху из постгре? это Вы застряли в эсодин
Чем тебе вакуум не угодил? В других взрослых СУБД он тоже так или иначе есть, без него никуда.
Во взрослых СУБД его нет. Например, в Oracle. Там есть UNDO, но он не ведёт к раздуванию табличных пространств, которые содержат пользовательские данные. Кроме того, UNDO можно положить на другую дисковую подсистему и разнести нагрузку таким образом. Можно даже несколько UNDO создать (и в Multitenant это поддерживается для каждой приватной БД внутри контейнера).
VACUUM и UNDO это про разное. Ты не в теме. Задача VACUUM-а в значительной степени идентична задачам перестройки индексов и дефрагментации табличных пространств (ты его в автовакуумом путаешь). UNDO же просто обслуживает откат и многоверсионность через него. Где хранить данные отката совершенно не важно. Вот вообще. Куда важнее их организация, и тут Оракл, да, лучше и Слона, и МС, потому что хранит тупо более рационально и избирательно, т.е. в итоге меньшим объёмом обслуживает те же задачи.
Multitenant это общий термин для всех БД -- мультиарендность, а не приватность. Эта мультиарендность бывает сильная (как в Оракле с 19-той версии, до старших патчей 12-той версии мультиарендность в Оракле вообще не поддерживалась ни в каком виде, напомню), слабая (как в МС Сиквеле, журнал тразакций разделён, системный каталог -- нет) и формальная (как в Слоне сейчас, где журнал транзакций, увы, общий и системный каталог тоже). И тд и тп.
Т.е. по твоему получается, что Оракл хронологические данные не хранит ))) А хранит некое UNDO, которое совсем другое дело ))) UNDO Оракл обслуживает приблизительно точно так же, как Слон протухшие записи. При нормально настроенном автовакууме какого-то прям распухания относительно типичного поведения прочих СУБД Слон не демонстрирует вообще. Разница лишь в том, что в Оракле, если ошибся с настройками UNDO, ты получишь ошибку 01555 и откат, но экземпляр продолжит молотить, а Слон при кривой настройке автовакуума просто встанет из-за исчерпания LSN.
Так в Слоне и табличных пространств нет в том смысле, как в Оракле. Нет наследия AS370. В Слоне чаще всего каждый объект схемы отдельный файл или набор файлов, распихивай их как хочешь. Просто опыт Оракла на Слона почти не переносим.
ES370 правильное название. На этой системе не было файловой системы вообще :). Были только разделы и экстенты. Примерно как tablespace в Oracle. Но вот то, что в pg каждый объект порождает несколько файлов для данных, это для оптимизации ввода-вывода и обслуживания не очень хорошо
Интересно, что будет при репликации, если одна и та же запись с предыдущего сеанса репликации изменялась на обеих репликах, и значение в каком-нибудь поле на них различно различно.
Что в прикладной логике пропишешь, то и будет. На то и логическая репликация.
Причем тут прикладная логика? Логическая репликация не имеет никакого отношения к прикладной логите.
То что и там и там используется слово "логика" - не делает эти сущности родственными. Это разные уровни абстракции вообще...
Это ты не имеешь, а логическая репликация, как раз, имеет. По сути это настраиваемый фильтр поверх WAL-а с одной стороны и триггер с фильтром на вставку с другой.
хамство еще никого ни в чем не убедило, кроме того что собеседник дурак.
а прикладная логика- это сущность на уровне реализации бизнес-логики приложения трехзвенной модели (приложение, база, клиент) но никак не на уровне рутинных операций внутри СУБД.
Это опять пэтэушные мудрости? или курсистские? Логика, сущность, какие-то звенья. Всё в кучу. Логическая репликация на то и логическая, ещё раз, что может быть настроена так, что будет зависеть от условий ПРИКЛАДНОЙ среды. Хоть у тебя "стозвеньевая модель". Пэтэушные ребята, не пользуйтесь словами, смысла которых не знаете, пользуйтесь теми, которые вам знакомы и понятны, их вполне будет достаточно.