После года разработки опубликована (https://www.postgresql.org/about/news/1894/) новая стабильная ветка СУБД PostgreSQL 11. Обновления для новой ветки будут выходить (http://www.postgresql.org/support/versioning/) в течение пяти лет до октября 2023 года. Основное внимание при подготовке новой ветки было уделено расширению функциональности в областях управления очень большими базами данных и разработки приложений для масштабируемой обработки больших данных.
Основные новшества (https://www.postgresql.org/docs/11/static/release-11.html):
- Добавлена возможность применения JIT-компиляции (Just-in-Time) для ускорения выполнения некоторых выражений в процессе обработки SQL-запроса. Например, JIT применим для ускорения выполнения выражений внутри блоков "WHERE", в выходных списках (target lists), агрегатных выражениях и проекциях. JIT также задействован для ускорения некоторых внутренних операций. Предложенный JIT-компилятор построен на основе наработок LLVM и для включения требует установки дополнительных зависимостей, связанных с LLVM. Включение осуществляется настройкой "jit = on" в файле конфигурации или командой "SET jit = on" в интерактивном сеансе;- Добавлен новый вид хранимых процедур, позволяющих использовать транзакции. Процедуры определяются с использованием синтаксиса SQL и позволяют использовать все средства управления транзакциями. Поддержка транзакций даёт возможность создавать более продвинутые серверные обработчики, например, для пакетной загрузки данных. Для определения хранимых процедур с транзакциями добавлена новая команда CREATE PROCEDURE (https://www.postgresql.org/docs/11/static/sql-createprocedur...). Для выполнения процедуры используется команда CALL. К SQL-процедурам также можно обращаться из хранимых процедур на PL/pgSQL, PL/Perl, PL/Python и PL/Tcl;
- Улучшения, связанные с секционированием (партицированием):- Реализована поддержка секционирования данных по хэшу, которая позволяет секционировать таблицы не только по диапазонам значений и спискам, но и по произвольным ключам.
- Обеспечена корректная маршрутизация операций INSERT, UPDATE и COPY для секционированных таблиц, обрабатываемых с использованием модуля postgres_fdw (https://www.postgresql.org/docs/current/static/postgres-fdw....) (логически объединяет таблицы с нескольких серверов);
- Представлена секция "catch-all", которая используется по умолчанию для данных, не соответствующих ключу секции, и позволяет применять первичные ключи, внешние ключи, индексы и триггеры над секционированными таблицами.
- Обеспечен автоматическое перемещение записей в корректную секцию, после изменения в записи ключа для выбора секции;
- Увеличена производительность запросов при чтении данных из секций;- Добавлена возможность применения операции "upsert" (добавить-или-модифицировать) к секционированным таблицам, что позволяет упростить код приложений и снизить число сетевых запросов;
- Проведена работа по увеличению производительности параллельной обработки запросов. Увеличена производительность распараллеливания операций последовательного сканирования и слияния хэшей. Добавлена возможности распараллеливания операций при выполнении команд "CREATE TABLE ... AS", "CREATE MATERIALIZED VIEW" и блоков UNION. В команду "CREATE INDEX" добавлена поддержка параллельная обработка данных при построении индексов B-tree;- Реализована возможность обойтись без полной перезаписи таблицы при выполнении "ALTER TABLE ... ADD COLUMN" при отличающемся от null значении столбца по умолчанию;
- В "CREATE INDEX" добавлена опция INCLUDE для создания индекстов-обёрток, включающих дополнительные столбцы;
- В оконные функции добавлена поддержка всех опций "рамок окна" (window frame), определённых в стандарте SQL:2011, включая возможность использования RANGE для PRECEDING/FOLLOWING, режима GROUPS и опций исключения рамок;
- В интерфейс командной строки в дополнение к штатной команде "\q" добавлены более привычные для новичков команды "quit" и "exit".
URL: https://www.postgresql.org/about/news/1894/
Новость: https://www.opennet.ru/opennews/art.shtml?num=49462
Буду ждать PostgreSQL Pro.
Я вот не пойму, почему этих ребят за нарушение тм в суд не пригласили?
У них договорённости какие-то или они на территории США не распространяются?
Да, тоже интересно было.. Но, вот почему, как я понимаю: https://postgrespro.com/about
С официального https://www.postgresql.org/docs/ даже линк на доки на https://postgrespro.com
> Я вот не пойму, почему этих ребят за нарушение тм в судКакое "нарушение"?? Это-то Вы, надеюсь, понимаете хотя до уровня -- объяснить. Прошу.
> не пригласили?
Нарушение, простите, чего? BSDL?
> Нарушение, простите, чего? BSDL?"" анОним с нарушенным шаблоном взывает к суду. ""
Когда движок перепилят, что бы избавится от вакуума?
Хотел тоже спросить.
> Когда движок перепилят, что бы избавится от вакуума?Зачем его выпиливать. Это крайне нужна вещь. Вакуум конечно можно отключить, но так вы базы загубите.
Вы говорите про следствие (вакум), а автор спросил про причину (движок).
С текущим движком постгри всё так. О том и речь, чтобы сделать наконец нормальный движок как в приличных СУБД.
А "Нормальные" это какие?
Ну, Оракл, видимо.
Это который ORA-01555; Snapshot too old? Нет, такой движок нам не нужен :-)
Ну ведь это тоже чисто "проблема реализации". Сделайте Сегмент отката пожирнее.
Нет это не "сегементы отката пожирнее". Если бы так то была бы ошибка о нехватки места в undo.А эта ошибка - проблема глупой (женской?) логики,
когда сначала "нет мне эти данные больше не нужны",
а через некоторое время "а дай мне те данные которые я говорила, что не нужны".
Конкретней?
Это ошибка, связанная с тем, что данные были из Сегмента отката вытеснены по причине их устаревания. Вот и всё. Больше Сегмент отката -- больше данных предыстории можно в них запихнуть, более длинные транзакции можно делать. Вот и всё. Нет тут никакой эзотерики или "женской" логики.
ORA-600 же
> А "Нормальные" это какие?Поколоночные? Типа Apache Kudu? Они точно нормальны к строкам....
> Когда движок перепилят, что бы избавится от вакуума?Как только из SQLя выкинут консистентность данных, транзакционность и пр. совершенно ненужные атавизмы.
Пишите письмя в ANSI и ISO!
https://en.wikipedia.org/wiki/Multiversion_concurrency_control
https://en.wikipedia.org/wiki/SQL#Interoperability_and_stand...
И как только InnoDB без всяких вакуумов справляется, предоставляя транзакционность и прочее нужное?
вы таки будете смеяться, но вакуум там есть, просто называется по другому
И только почему-то в InnoDB нужно периодически запускать optimize.
Ильюша, аналог "вакуума" есть во всех mvcc-рсубд. Это основа подхода -- сохранять исторические данные для организации многоверсионности. Реализаций существует несколько -- ни одна из них не являет особых преимуществ перед другими.
Совсем не лучше?
https://habr.com/company/southbridge/blog/322624
Хабр читать не буду. Хотите что-то узнать попробуйте осмысленно пересказать мне о чём там, я может и отвечу что-нибудь. Хотя не очень понимаю зачем мне этим культпросветом заниматься.
Наиболее важное архитектурное отличие заключается в том, что Postgres напрямую сопоставляет записи индекса с адресами на диске, а в InnoDB есть дополнительная структура, в рамках которой записи индекса содержат не указатель на место на диске (как ctid в Postgres), а указатель на значение первичного ключа. Таким образом, ключи вторичных индексов в MySQL ассоциированы со значениями первичного ключа:
Чтобы выполнить поиск по индексу (first, last), необходимо выполнить два действия: найти первичный ключ записи в таблице, а затем в индексе по первичному ключу отыскать расположение строки на диске.Такое конструктивное решение ставит InnoDB в менее выгодное положение по сравнению с Postgres, поскольку предполагает выполнение дополнительной операции по поиску ключа. Однако, так как данные нормализованы, при обновлении строк затрагиваются только те индексы, которые построены по изменившимся полям. Также InnoDB обычно выполняет обновления строк прямо на месте. Если каким-либо транзакциям в рамках механизма MVCC необходима старая версия строки, MySQL копирует ее в специальную область под названием сегмент отката (rollback segment).
Замечательно, что вы освоили ctrl-c и ctrl-v, но что из этого вы поняли? Вы критически можете оценить, что тут написано? Без иронии всякой спрашиваю.
Объясню. В Оракле записи в Сегмент отката обслуживается "на общих основаниях", т.е. сначала идёт запись в журнал повторного исполнения, только после этого происходит запись в Сегмент отката. Поэтому в случае краха данные утрачены не будут. В Инно это не так -- в Инно запись в Сегмент отката не защищается журналом транзакций. Это делает процедуру быстрее: меньше операций записи в разные места -- быстрее операция. Но делает такую операцию опасной. Это не говоря о том, что запись в Сегмент отката (в случае Инно, в Оракле -- не так реализовано) это копирование данных, т.е. считывание и запись, что никак не может быть быстрее "замогиливания" и вставки в Слоне...
У Инно ещё и косяки с синхронизацией. Нужно быть отчаянным авантюристом, чтобы Инно использовать для надёжной обработки коммерчески значимых данных.
Достаточно провести нагрузочное тестирование перед вводом в прод ну и не пользоваться оптимистичными блокировками при многопоточной репликации
Сама по себе концепция кластерного индекса не делает Инно не хуже, не лучше, чем Слон, в котором кластерных "таблиц" нет. Это вообще ничего о производительности не говорит.
ААААааааа.... Чуваки из Убера на полном серьёзе пишут, что транзакционность это ненужное фуфло, потому... что замедляет запись )))))))) Вот новость-то.
Да и флаг им в руки.
А ты свои 10 записей пишешь и тебе хватает. Как поработаешь с нагруженными прилржениями, поймешь, что это такое и какая нужна производительность
Ты, наверное админ, который про базы только в школе слышал и наверное тебе не рассказали что консистентность можно поддерживать разными способами
Тоже расскажи, а то посмотришь на хард после OPTIMIZE TABLE и прям диву даёшься
Ещё раз. Это общая проблема. Никто её пока как-то сильно лучше других не решил. Статистику нужно обновлять, индексы обновлять, данные отмены где-то и как-то хранить, а потом очищать. У всех одинаковые проблемы.
InnoDB на SSD или при преимущественно рандомных выборках не-range на любом носителе OPTIMIZE TABLE наксер не нужен, поскольку фрагментация роли не играет. Повторное использование страниц при этом есть.Для write-mostly нагрузок есть TokuDB, у которого реюз также сделан.
У постгри же вакуум в этих случаях также не отменяется, а для write-mostly вообще нет ничего.
да, я тоже что-то не понял, где в списке новостей - "1. vacuum deprecated и назначен к выпиливанию в 11.1" - сопровождавшее все выпуски, кажется, начиная с 8. Наверное, автор новости просто невнимательно читал оригинал. ;-)
В пользу автовакуума, угу, который один ксер тот же вакуум. Как вы с этим кактусом живёте. Ну ладно на хдд фрагментирование допустим таблиц InnoDB требовало аккуратного подхода, но вот на SSD-то оно не актуально уже.
вы свое "фрагментирование" (которое многозадачной системе, вообще-то, изрядно до лампы) с бесконечным разрастанием таблиц и их индексов из-за банального update -то не путайте.
Когда EnterpriseDB допилит zheap и протолкнет его в ваниль, тогда и будет...
А зачем? Чем "вакуум"-то мешает жить тем, кому он... мешает жить? Чем Сегменты откаты в Оракле удобней? Обычно про вакуум визжат ничего сложней Дельфина никогда не пробовавшие.
> Чем "вакуум"-то мешает житьтем что жрет ресурсы как не в себя и при этом не работает. И в результате - vacuum full; reindex
> Чем Сегменты откаты в Оракле удобней?
тем что они вне стора и после завершения транзакции просто помечаются как ненужные.
обычно проблема ваккума непонятна "аналитикам", которые никогда в базе ничего не меняют.
> тем что жрет ресурсы как не в себяэто настраивается
> и при этом не работает.
у всех работает
> И в результате - vacuum full
vacuum full не нужен
> reindex
тут не спорю, нужен, но маловероятно что отказ от вакуума это исправит, индексы всё равно будут пухнуть из-за поддержки многопоточности, либо придётся сильнее лочиться
> у всех работаетОтучаемся говорить за всю сеть.
Ну вообще то он работает, просто файлы остаются "разряженные"
Т. е. по вашему получается, что обслуживание Сегментов отката даром даётся ))) Ну, оно как-то само там что-то с собой делает. И хватит тут кичится своим невежеством и непрофессионализмом. Если у вас что-то не получается, то слушайте тех, у кого получается, а не хамите, как пэтэушник. "Проблема вакуума" непонятна тем, кто по этой проблеме и пары страниц не удосужился прочитать, но рассказывает тут какой он "практик". Даже не смешно уже.
ну, скажем так - оно во-первых вполне предсказуемое, во вторых, в самом банальном варианте таки даром, да - напоминаю, что постгрез раздувает и стор и индекс на банальном update не-ключевых полей. Без всяких параллельных транзакций и длительных блокировок - просто потому что вот так он у него устроен. В этом он совершенно уникален, кто-то там своего PhD в 95м за эту фичу получил.> И хватит тут кичится своим невежеством и непрофессионализмом.
переадресую вам этот полезный совет.
> Если у вас что-то не получается, то слушайте тех, у кого получается
мамкиных dba, не понявших даже в чем, собственно, проблема, потому что на их append-only базе такого вообще не бывает? Спасибо, неинтересно мне вас слушать. "пару страниц прочитавших", ага.
"такая же нога, и не болит".
Это уже очень давно произошло.
Иван, а что вы знаете о СУБД вообще? Хоть что-нибудь знаете, а? Ну хоть чуть-чуть?
Другой вопрос, когда появится поддержка других хранилищь, помимо блочных устройств? Энергонезависимую память уже втыкают в слот оперативной. MySQL уже несколько десятков лет умеет работать с оперативкой.
А как понять "умеет работать с оперативкой"? Все современные СУБД "умеют работать с оперативкой", с ней только и работают.
А что, оперативка и NVME вдруг перестали работать как блочные устройства?
т.е. вы предлагаете то, что можно адресовать по-байтно, адресовать по-блочно, чтобы только ничего не переделывать?
З а ч е м? Объём накладных расходов возрастает в десятки раз. Вы не задумывались почему так распространена постраничная адресация, а? Микроменеджмент всего это хозяйства будет занимать все ресурсы.
В интерфейс командной строки в дополнение к штатной команде "\q" добавлены более привычные для новичков команды "quit" и "exit".Джва года ждал!
...пока ждал - привык к \q)))
всегда по ctrl-D выходил :)
требую добавить :q
Ctrl + D Остальное для слабаков
>Добавлен новый вид хранимых процедур, позволяющих использовать транзакцииНе поклонник слоника, но вот от этого офигел.
Только добавили? Едрить!
Это вложенные транзакции, дурилка.
И это очень круто.
Из описания новости не понятно ни черта.Оно: https://wiki.postgresql.org/wiki/Autonomous_subtransactions ?
Или раньше нельзя было сделать BEGIN внутри функции?
Во-первых: https://www.postgresql.org/docs/11/static/xproc.html
Во-вторых, в функции можно было, в процедуре - нет
> Во-вторых, в функции можно было, в процедуре - нетСудя по https://www.postgresql.org/docs/11/static/sql-createprocedur... раньше и не было CREATE PROCEDURE.
В целом, я так и не понял разницу между функцией и процедурой (кроме как вы методе вызова и том, что процедура ничего не возвращает).
Значит, никогда ни транзактом, ни с пл-, ни с пг-сиквелом дел не имели. И с СУБД вообще. Зачем тогда вам разбираться в этих тонкостях?
> Зачем тогда вам разбираться в этих тонкостях?Для развития.
Назад к сути. Где в офф.документации почитать про разницу? Спасибо.
Исторически разница была в том, что функции можно было встраивать в SQL-выражения, т.е. они возвращали recordset, а процедуры -- нет.
Ну, я несколько не точно выразился. Процедуры тоже можно было в SQL-код встраивать, но они возвращали "скаляр", т.е. конкретное единичное значение. А функции -- могли вернуть и набор строк. Одни можно было использовать исключительно в процедурных расширениях, а другие -- в обычном декларативном коде.
Не то чтоб очень круто, а "как в Оракле".
> Это вложенные транзакцииНет, наоборот, это возможность вызвать процедуру _вне_ транзакции, что бы транзакцией управляла она сама.
Шёл 2018 год...
> слияния хэшейhash join это не "слияния хэшей"
> Добавлен новый вид хранимых процедур, позволяющих использовать транзакции.В оригинале:
> SQL stored procedures that support embedded transactionsЧто за "embedded transactions"?
Имеется в виду "autonomous transactions" или что-то другое?
Когда выпустят нормальный PgAdmin?
А зачем он? Я DBeaver-ом пользуюсь. Для всего. И для Слона тоже. Вполне достаточно.
Оооо!!! Спасибо, похоже это то, что я давно хотел.
А он умеет по SSH и через PHP-прокси в базы данных стучать, как Navicat?
Не знаю, не пробовал.
А зачем это вот прям уметь? Туннель сторонними средствами можно ведь без проблем сделать, только порты пробросить.
Не на всех хостингах можно использовать SSH, а так же вертеть mysql как угодно, а в БД бывает надо поковыряться. И в итоге в худших случаях начинается цирк с "забекапить, скачать, развернуть, поправить, сбекапить, залить обратно, развернуть"
navicat, на минуточку, стоит $1300. ну, $300, если вам только постгрес, а другие базы не нужны.
Какие-то мудовикипедисты выпилили его из wiki, хотя в кэше поиска гугл выдаёт превьюшку, что оно было и на русском
А не сравнивал с tora, как оно по возможностям?
Нормальный pg admin это тот, который на зарплате, например.
Дайте UNDO !!!
Кто скажет, есть табличка статусов, 2000 строк, обновляются половина каждые 10 секунд, и читаются постоянно, как запилить что бы оно не умирало?
Автовакуум поставить очень часто. Вот и всё. И вообще, иногда полезно читать документацию.
Так жопа получается, непрерывно работает вакум на одной таблице, а базе еще кроме этого много чем нужно заниматься :)
и мне нужно в одной таблице (большой), часто у 5 % строк менять статусы поле число 0,1,2,3
какого хрена таблица растет ппц как?
и что теперь, вакумы работают непрерывно, а базе данных что делать больше ничего не надо?
Но тут гонка получается. Один процесс лепит новые строки, под которые нужны новые или "удалённые" страницы: нет возвращённых страниц -- тогда нужно выделять новые. Другой должен успевать очищать страницы с удалёнными и ненужными строками. Баланс между ними настраивается стоимостью операций. В результате можно добиться, чтобы автовакуум был в приоритете, но тогда снизится производительность записи свежих данных. Поэтому выбор прост -- либо быстрее запись и файл будет пухнуть, либо пухнуть не будет (вернее будет существенно медленней пухнуть), но скорость записи на пиках просядет. У вас, насколько я понял, нагрузка равномерная и постоянная, а не периодическая. Поэтому, по-моему, вам подход с разрастанием файла вряд ли подойдёт; дайте больше шансов автовакууму успевать чистить файл. Повышайте лимит операций и снижайте время "сна", ну и памяти больше выдайте автовакууму (сразу в разы больше, а потом снижайте до приемлемого уровня). Настройка порогов включения, думаю, никаких сложностей само по себе не вызовет -- всё очевидно.
Чем undo-то лучше? Вы даже самому себе этого объяснить не сможете. Потому что понятия не имеете, как Сегменты отката в Оракле работают.
Имею, Oracle DBA уже 20 лет как :)
И что с того? То, что вы имеете 45-ть лет вождения жигулей на дачу не делает из вас раллийного гонщика. Сами ведь понимаете.
На DBA об этом знать ничего и не требуется.
Держите UNDO:
##
##
##
######################################
#########################################
###########################################
#############################################
########## ##
######## ##
####### ##
#####
#####
#####
####
####
###
####
####
###
#### ##
##### ##
#########################################
######################################
##
##
### ##
### ##
### ##
#################################################
#################################################
### #########
### ############
###############
################
###############
################
###############
###############
################
###############
###############
###############
############### ##
############### ##
################ ##
#################################################
#################################################
##
##
### ##
### ##
### ##
#################################################
#################################################
#################################################
#################################################
### ##
### ##
### ##
### ##
### ###
#### ####
### ###
#### ####
##### #####
###### #######
########## ##########
############# #############
#####################################
#################################
#############################
#####################
#############
###################
###########################
#################################
#####################################
########### ###########
####### #######
##### #####
#### ####
### ###
### ###
### ##
### ##
### ###
### ###
#### ####
##### #####
####### #######
######### #########
#######################################
###################################
###############################
#######################
#############
Я сделал UNDO, но потом случайно запустил, поэтому опять ничего нет...
> Дайте UNDOэто из той же серии где и vacuum full; reindex;
> как запилить что бы оно не умирало?
никак. Или сменить базу данных на такую, авторы которых не изобретали time travel или хотя бы исправили ошибки молодости.
а с форматом хранилища постгреза ничего сделать уже нельзя, только взорвать к чертям.
Ну к чему эту чушь транслировать? Вы же не разбираетесь в вопросе совсем. Автовакуум полностью эту проблему решает сейчас. Vacuum Full совсем про другое. И в Оракле нечто подобное тоже приходится делать. До 10-той версии это было крайне мутурное, к слову, занятие.
в том и дело что не решает. Проблему раздувания стора, я имею в виду, при банальных апдейтах (причем вовсе не PK, а вообще неиндексированного поля) и, как следствие - тормозов даже при банальном индексном селекте. Потому что индекс, внезапно, у нас отрос в десятки раз больше чем на самом деле надо.в орацле приходится делать в других случаях и случаи эти изрядно небанальны, если не сказать извратны. Неудивительно что и делается через задницу.
В innodb вообще не приходится - другая конструкция хранилки.
Ну, ё-маё, ну, ребята, читайте доки. Нет там никакого "раздувания стора". Если вы не обновляете статистику в соответствии с развитием модели, то, да, вы получаете снижение адекватности "разборщика" запросов. Это настолько очевидные вещи, что смешно о них тут упоминать.
> Нет там никакого "раздувания стора"Мамкин dba пытается спорить о вкусе устриц с теми, кто их таки ел?
Очень уныло и не понятно к чему.
Зато твой ник очень в тему, да.
Кластерные индексы что в Инно, что Сиквеле всё равно нужно обслуживать. В Оракле же ситуация с индексами очень похожа на Слона. Но, и тут я спорить не буду, Оракл значительно быстрее, но он в совсем другой лиге. В Оракле как раз крайне банальны. Куча и индексы по ней очень быстро расходятся под высокой нагрузкой. Но это всё неизбежно. Другое дело, что Оракле это от версии к версии всё больше делается само.
А, извините, переоценил. Вам, насколько я понял, сама концепциям мультиверсионности аппетит испортила. Ну так, дерзайте, делайте что-то другое.
не сама концепция, а последствия конкретно этой ее реализации. Образца 1995го года. Что сейчас нельзя сделать эффективно работающую - очень сомневаюсь.> Ну так, дерзайте, делайте что-то другое.
вам миллиона существующих storage egnines мало?
У нас и сейчас всё работает прекрасно.
Если данные условно временные, можете использовать UNLOGGED таблицы (не генерируют события WAL и при фейлах чистятся).Для частых обновляющихся действий довольно неплохо подходит.
Поменять подход не пробовали?
Дохрена чего пробовали, но вот НАДО, очень, при том что есть и оракл, на тех же задачах, на гораздо более слабом железе, у него не возникает проблем совсем никаких,
без холиваров, нравится постгрес, для небольших задач где только вставки-запросы, все хорошо, sql возможностями нравится и т.д.
Кортежей доступно 2130
«Мертвых» кортежей 206960
Последняя автоочистка 2018-10-20 10:55:03.599286+03
Размер таблицы 114 MBавтовакум работает практически непрерывно, 2000 строк Карл!!!, 114 mb
как победить? такая таблица с таким режимом работы нужна.
Как часто апдейты идут?
Типичный апдейт покажите запросом.
Я же писал уже задержку сдедал, не чаще чем 30 сек
в цикле от 30% до 100% строк
update po.status set last_send_time=, ....= where id=:id по примари кей
ну очень нужна таблица статусов
Режим изоляции какой? Как транзакция разграничена? И разграничена ли вообще?
Вы транзакцию закрываете? Commit есть?
То что наблюдаете очень похоже на типичный недосмотр, нет коммита в коннекте. Апдейты делаете, а транзакцию не закрываете.
Да-да-да. Поэтому автовакуум и держит всю это помойку нетронутой.
Сделайте отдельную таблицу из двух полей: ID и STATUS.
Ещё раз, читайте как настраивать автовакуум. Покажите тут действующие настройки.
Давайте попробуем разобраться. Версия Слона у вас какая? Что вас конкретно не устраивает? То, что файл пухнет? Сценарий ваш довольно типичен и к такому поведению при адекватных настройках приводить не должен.
Тот случай Когда архитектор должен повеситься от стыда
Или его пристрелят бизнесс процессы которые не смогут подстроится под кривизну архитектуры СУБД
Вас должен спрасти ZHeap. Прототип показали в марте, и уже тогда было понятно, что в 11 версию оно не попадает. Но всё-ещё есть надежда, что к 12 версии его таки успеют допилить.Если пропустили, то анонс был тут: https://www.enterprisedb.com/blog/zheap-storage-engine-provi...
Текущий статус тут: https://wiki.postgresql.org/wiki/Zheap
За прогрессом следить тут: https://github.com/EnterpriseDB/zheap
Ваша проблема, на самом деле, в дизайне. Добавьте поле last_updated или insert_ts и замените UPDATE на INSERT, а запросы на чтение замените на выборку только самого актуального результата. При INSERT вакуум не работает, а удаление старых записей (и запуск вакуума) можно сделать по крону в периоды наименьшей нагрузки и чтобы удалял все и сразу (плюсом будет еще и то, что все удаляемые строки будут к конце таблицы, так что длинных блокировок не будет)А по хорошему, постгрес не для этой задачи, возьмите другую БД под именно этот функционал и не делайте себе мозг.
Это очень плохое и некомпетентное предложение.
> Это очень плохое и некомпетентное предложение.Сказал человек с ником "Мудила"
Обоснуйте тогда, что ли
Ставить диагноз, когда потциент слился в неизвестном направлении, даже не расписав, что его конкретно не устраивает, занятие бесполезное. "Оракле ДБА" с седыми яйцами, вроде как, не понравилось что "файл разрастается". Ну так замена delete/insert на insert точно ситуацию не улучшит (инсерты точно будут требовать новых страниц, и проблему с устаревание нужно будет решать врукопашную; этим обычно админы Сиквела любят страдать -- читать доки для них сложнее, чем невообразимо идиотские триггеры лабать). В действительности, по-моему, никакой проблемы у жалобщика со Слоном нет, кроме того факта, что Слона он даже минимально не пытался настроить, а с логикой модели у него что-то явно не так (видимо, есть застарелая длительная транзакция, которая мертвые кортежи держит). Потому как движок Слона даже с умолчальными настройками автовакуума с подобным справляется вообще без проблем. Сам проверил: сделал отношение с несколькими тысячами строк и менял в них по циклу значение, выбирая произвольно по ключу (обновление одной строки за одну транзакцию). Ни тормозов на выборках, ни какого-то роста размера файла за час нагрузки получить не удалось. Это плёвая задача. Оно вообще никак особо на загрузке сервера не сказалась. Да и к тому же оставляет массу возможностей по оптимизации: хошь периодичность чекпоинтов повысь и тогда вообще ничего на диск падать не будет, хошь приоритет автовакуума подними -- всё будет чиститься влёт и файл расти будет очень умеренно.
Up: неверное выразился -- периодичность чекпоинтов нужно понижать, т.е. повышать промежутки между ними.
Ну так вот и я о том же. Просто топикстартер жаловался, что у него вакуум не устраивает, что он распространяется на всю базу и частый запуск ему мешает или не работает, т.к. блокировки. В этом плане моё решение работает как раз норм, т.к. можно контролировать когда делать delete и соответственно вакуум (просто как идея, я ж хз что у него за данные и за модель)Но вообще да, Слон спокойно справляется с такими вещами, более того, у меня была таблица с 5 млрд строк и 50к апдейтов в секунду - каждый апдейт 5Мб размером и ничего - всё работало и не жужжало и место особенно сильно не ело
Просто Мудилы и ДБА с яйцами видать не очень умеют доки/код читать - вакуум простая штука, пару дней курения мануалов, на крайняк почитать немного кода - и всё становится ясно - где, что и как работает и за что отвечает
> В этом плане моё решение работает как раз норм, т.к. можно контролировать
> когда делать delete и соответственно вакуум (просто как идея, я ж
> хз что у него за данные и за модель)Забыл уточнить - у него UPDATE, то есть он часто и много делает UPDATE. Если делать часто INSERT, но редко и много DELETE и сразу после этого вакуум, то файл будет расти, но только в периоды между запусками вакуума
> то файл будет расти, но только в периоды между запусками вакуумаесли мы правильно угадали его проблему (что это именно из-за особенностей стора, а не, действительно, "ой, commit забыли") - не будет (будет один раз, до первого delete ; vacuum).
vaccum прошел - следующие insert попадут в области того, что недавно delete, ничего особо заметно расти не будет.
и выполняется он при таком раскладе быстрее. Но решеньице, прямо скажем, выглядит кривоватенько.
Настройка стоимости операции для (авто)вакуума сделает тоже самое, только скрипты плодить и от Update-а отказываться не нужно будет.
Ладно, понял, что осмысленно диалога "DBA с двадцатилетним стажем" не выйдет.
Просто накрутите
-- autovacuum_vacuum_cost_limit в десять раз (больше 1000) поставьте;
-- autovacuum_vacuum_cost_delay сделайте в районе 5--10.
Если не помогло, то предварительно всё же стоило убедиться, что проблема именно в недостаточно частой "уборке" файла отношения. Потому что подобное поведение может быть следствием очень длительной транзакции, которая работает по данным, которые вы часто изменяете, а значит -- это ошибка вашей модели и её нужно корректировать. В общем, не тупите и читайте документацию.
Ну нету там длинных транзакций, нету инсертов, делейтов, много коротких апдейтов, и это НЕ единственная таблица, другим тоже нужны ресурсы процессора, память, вакумы, и т.д.
Вакуум на ней висит практически постоянно, и не успевает, блять 2000 строк уже 260MB, простенький запрос к этой таблице должен выполнятся мгновенно, а он задумывается
Думаю, вы уже знаете, что в Слоне update-ов нет, а есть delete/insert. Как и все современные РСУБД Слон работает исключительно с кэшем буферов (не с диском), а синхронно пишет изменения только в WAL. Поэтому ваш характер нагрузки на нормально настроенном серваке не должен приводить к частым сбросам буферов в файл (и его росту) -- данные меняются в кэше и, по идее, их вообще не нужно сбрасывать в файл. Вам этого и нужно добиться. Увеличивайте а) время между чекпоинтами, б) размазывайте фактический сброс по этому времени сильнее, в) проверьте достаточно ли памяти вашим процессам автовакуума (см. логи на предмет ошибок недостатка памяти, их в таком случае будет очень много), г) настройте параметры вакуума для конкретного отношения (настройки выше проскакивали), д) чтобы HOT-механизм работал эффективней (а это как раз ваш случай, у вас же не меняются индексные поля), увеличивайте значение филфактора для данной конкретной таблички.
С много процессов параллельно пытаются эти ваши статусы менять?
есть и много процессов, но разные строки, read commited,
в данном конкретном случае, 2-3 процесса, (плюс позанимался, добавил нужных индексов для других таблиц, в целом уменьшилась нагрузка на сервер), сделал
alter table set (autovacuum_vacuum_cost_limit = 1000);
alter table set (autovacuum_vacuum_cost_delay = 5);
теперь автовакум не висит постоянно, остановил все сервисы, сделал VACUUM FULL
через пол дня:
Кортежей доступно 2130
«Мертвых» кортежей 28101
vacuum verbose
найдено удаляемых версий строк: 0, неудаляемых - 30230,
какого хрена?, никто таблицу не блокирует
select * from pg_catalog.pg_locks l where l.relation=23037
пусто
Блокировки тут не причём.
Зомби-транзакции поищите. Всё же, очень похоже на то, что транзакции не фиксируются или разграничены не так, как вы себе представляете. Поэтому задействованные ими кортежи и не подвергаются уборке.
А vacuum full эти мёртвые кортежи убирает?
Понимаете, если у вас много обновляющих данные процессов в одном отношении, то подобная картинка вполне себе типична. В том, что в результате дофига хранится исторических данных, нет ничего ужасного и необычного. Их будет тем больше, чем больше параллельных процессов, работающих с отношением: им же всем нужно получить состояние кортежей на момент начала каждой из транзакций. Другое дело, что шлака столько не должно оставаться.
Вот, скажем, началась у вас транзакция Т1. Она длиться, условно, 10 единиц времени. Через десять единиц времени она фиксируется.
T1 началась во время t1.
T2 началась в t1 + 1.
T3 : t1 + 2
T4 : t1 + 3.
Ну и т.д.
Т2 хочет видеть состояние БД на момент t1 + 1. И, соответственно, те кортежи, которые T1 похерила, но не зафиксировала, вакуум удалять не может -- они нужны T2, T3... И так по цепочке. В результате если у вас много процессов которые производят большое кол-во обновлений по ключу, то исторических "хвост" нужно будет держать весьма значительный.
На этом фоне замена обновление на вставку, а потом явное удаление устаревших событий, не кажется таким уж нелепым решением.
А памяти у нас на серваке много? Значение maintenance_work_mem сколько выставлено? БД в кластере много?
Короче, нашел, в этой же базе но, вообще не имеюшее к этой таблице никакого отношения, "чужое" приложение после select-а не делает коммит. но у него свои таблицы и к моей никогда не обращается!!!
> Короче, нашел, в этой же базе но, вообще не имеюшее к этой
> таблице никакого отношения, "чужое" приложение после select-а не делает коммит. но
> у него свои таблицы и к моей никогда не обращается!!!Чужое приложение научили делать commit? Помогло?
Чужого разработчика надо пнуть, а потом чтобы обновилось на сотнях ПК, я рубал все их сессии, и пока не налезли опять, вакум проходил
но он же НИКАК не касается этой таблицы, оно делает ЗАПРОСЫ и к СВОИМ таблицам, короче бред какойто
> Чужого разработчика надо пнуть, а потом чтобы обновилось на сотнях ПК, я
> рубал все их сессии, и пока не налезли опять, вакум проходил
> но он же НИКАК не касается этой таблицы, оно делает ЗАПРОСЫ и
> к СВОИМ таблицам, короче бред какойтоЕсли дело в одной БД происходит и даже в разных схемах - бывает просто имена совпадают, допустим в вашей схеме (дефолтный public) есть таблица state и у него есть в его схеме таблица с тем же имененм, но в запросе указать схему чужой разраб забыл и обращается не к своей, потом получает не те колонки вылетает с софте ошибка и коннект с тразакцией теряется и висит бесконечно.
Не зря вас про уровень изоляции транзакции спрашивали. Если у вас много параллельных запросов на изменение, к тому же все они serializable, то что-то подобное может произойти. Если приложение работает через jdbc-драйвер нужно проверить какой режим изоляции для транзакций выбран.
>есть табличка статусов, 2000 строк, обновляются половина каждые 10 секундНакукуй тут вообще реляционная субд?
Если нужна мегаскорость (ну там сотни тысяч запросов в сек с 1 сервера) любой in-memory KV носкль будет хорошо работать или вообще hashmap какой-нибудь с записью журнала и lazy-persistence.
10 строчек кода.
Слон с этим тоже работает без проблем. Собственно, как раз это самое lazy persistence и происходит: блоки из буферов практически с файл и не успевают попадать большую часть времени. Там фактический I/O с диском получается вообще мизерный.
Уже в Debian, Mandriva и, как ни странно, Termux:
Переводчика на мыло! Зачем так переводить, что смысл кардинально меняется?>> Добавлен новый вид хранимых процедур, позволяющих использовать транзакции.
Никакого _нового_ вида хранимых процедур не добавляли. Добавили поддержку управления транзакциями из хранимых процедур, и всё. Английское "SQL procedures"- это любые хранимые процедуры, написанные на любом поддерживаемом языке, кроме динамически загружаемых из внешних модулей процедур, написанных, как правло, на C.
>> Поддержка транзакций в процедурах даёт возможность создавать более продвинутые серверные обработчики, например, для пакетной загрузки данных.
В оригинале было "incremental bulk data loading". Инкрементальной пакетной, а не просто пакетной- разница очень существенна.
>> Для определения хранимых процедур с транзакциями добавлена новая команда CREATE PROCEDURE.
Эм... Вообще-то она не новая, она там с незапамятных времен. В оригинале было всего-лишь "SQL procedures can be created using the CREATE PROCEDURE command". То есть просто напомнили, как их создавать.
Ваш вариант, по-моему, не лучше.
Мой вариант, простите, чего именно? Я, кажется, не предлагал альтернативных вариантов перевода, а лишь указал на ошибки в оригинальном переводе из новости...
CockroachDB через пару лет отправит на свалку этого динозавра.
Из Postgresql уже песок сыпется
https://opennet.ru/opennews/art.shtml?num=46529"11.05.2017 11:50 Первый стабильный выпуск отказоустойчивой СУБД CockroachDB "
"Из ограничений CockroachDB отмечается плохая пригодность для решений, требующих очень низкого времени отклика при выполнении операций записи и чтения. CockroachDB также плохо адаптирован для нагруженных систем обработки аналитической информации (OLAP), манипулирующих сразу большими срезами данных, и плохо оптимизирован для выполнения сложных SQL-запросов со слиянием нескольких таблиц "Вы об этом?
Да, то было в первой версии.
Прикинь, база маскируется под PostgreSQL, а ведет себя как распределенная, строго консистентная база данных.
Маскируется она полностью, реализуя протокол PostgreSQL.
Запускаешь 1 бинарник и у тебя база с мониторингом, которой приятно пользоваться.
> Да, то было в первой версии.а сейчас что?
> Прикинь, база маскируется под PostgreSQL, а ведет себя как распределенная, строго консистентная база данных.
это, конечно, красиво в плане посмотреть как оно стоит, но ничуть не подразумевает того, что оно работает с той же скоростью и теми же (понятными, хотя бы) проблемами, что и оригинал.
> Маскируется она полностью, реализуя протокол PostgreSQL.
"но зачем?!"
неужели это было проще, чем написать свои коннекторы для c/c++/пехепе/пихон/жабы (на самом деле не "и", а "сперва или, а потом как пойдет", поскольку вряд ли одному проекту нужно больше пары из списка ? Или протокол постгреза оказался чем-то удивительно хорош и приятен?
(вот уж вряд ли)
Протокол постгреса весьма приятен и хорошо задокументирован. Null terminated-строками только несколько злоупотребляют, но это не страшно.
Что значит "Обеспечена корректная маршрутизация операций"? Оно и раньше работало, вот только транзакции там не работали, это оно или о чём речь?
Для венды так и не сканпеляли. :( Чё за расизм?
> Для венды так и не сканпеляли. :( Чё за расизм?Это пазитиффная дискриминация, дурашка.
https://www.enterprisedb.com/download-postgresql-binariesЕсть для винды и макоси, для линукса пока нету :(
Как была тормозной херней так и осталась
Где бинарные сборки?