The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Релиз СУБД PostgreSQL 15, opennews (??), 13-Окт-22, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


31. "Релиз СУБД PostgreSQL 15"  –10 +/
Сообщение от Анно Домини (?), 13-Окт-22, 19:45 
Базу с вакуумом трудно назвать нормальной. Для большинства задач Перкона лучше.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

49. "Релиз СУБД PostgreSQL 15"  –1 +/
Сообщение от Аноним (49), 13-Окт-22, 20:39 
Так там тоже есть vaccum: https://dev.mysql.com/doc/refman/8.0/en/optimize-table.html
Ответить | Правка | Наверх | Cообщить модератору

59. "Релиз СУБД PostgreSQL 15"  –1 +/
Сообщение от Анно Домини (?), 13-Окт-22, 21:19 
> Так там тоже есть vaccum: https://dev.mysql.com/doc/refman/8.0/en/optimize-table.html

Это несопоставимые по накладным расходам (читай, по даунтайму) операции: http://rhaas.blogspot.com/2011/02/mysql-vs-postgresql-part-2...

И это нельзя исправить никакими улучшениями Постгреса, такова его архитектура by design.


Ответить | Правка | Наверх | Cообщить модератору

74. "Релиз СУБД PostgreSQL 15"  +/
Сообщение от Аноним (49), 13-Окт-22, 22:54 
> Это несопоставимые по накладным расходам (читай, по даунтайму) операции

Всё верно, ведь optimize table требует эксклюзивную блокировку: "An exclusive table lock is only taken briefly during the prepare phase and the commit phase of the operation" тогда как стандартный vacuum в postgres работает в фоне.

Действительно optimize table несопоставимо хуже, и это нельзя исправить никакими улучшениями, такова его архитектура by design.

Ответить | Правка | Наверх | Cообщить модератору

114. "Релиз СУБД PostgreSQL 15"  –1 +/
Сообщение от Анно Домини (?), 14-Окт-22, 13:37 
Не путай вакуум и автовакуум, невежда. Речь идёт о первом, его надо запускать вручную с даунтаймом, чтобы база не разрасталась как на дрожжах, и ничего подобного в мускуле нет.
Ответить | Правка | Наверх | Cообщить модератору

118. "Релиз СУБД PostgreSQL 15"  +1 +/
Сообщение от Аноним (118), 14-Окт-22, 13:56 
Невежда, у тебя в твоей статье написано что вакуум в mysql называется purge, то что он называется по другому не значит что его там нет.
Ответить | Правка | Наверх | Cообщить модератору

120. "Релиз СУБД PostgreSQL 15"  +/
Сообщение от Анно Домини (?), 14-Окт-22, 14:11 
> Невежда, у тебя в твоей статье написано что вакуум в mysql называется
> purge, то что он называется по другому не значит что его
> там нет.

Это ты мне говоришь, неуч? В мускуле нет вакуума, требующего даунтайма, как вакуум (не автовакуум) в Постгре. И даже автовакуум в Постгре нагружает базу сильнее, чем пурж в мускуле.

MySQL performs purges *in the background*.

Ответить | Правка | Наверх | Cообщить модератору

126. "Релиз СУБД PostgreSQL 15"  +/
Сообщение от Аноним (118), 14-Окт-22, 14:24 
Неуч, вакуум с даунтаймом в мускукле называется optimize table, а автовакуум в постгрес нагружает базу так как его настроишь.

PostgreSQL performs autovacuum *in the background*.

Ответить | Правка | Наверх | Cообщить модератору

133. "Релиз СУБД PostgreSQL 15"  +/
Сообщение от Анно Домини (?), 14-Окт-22, 14:45 
> Неуч, вакуум с даунтаймом в мускукле называется optimize table, а автовакуум в
> постгрес нагружает базу так как его настроишь.
> PostgreSQL performs autovacuum *in the background*.

Неуч тут это ты, не проецируй. Вот твои собственные слова: "вакуум в mysql называется purge". Проблема в том, что purge это аналог автовакуума, а не вакуума, так что не крутись тут как уж на сковородке -- ты уже показал своё незнание.

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

Ответить | Правка | Наверх | Cообщить модератору

137. "Релиз СУБД PostgreSQL 15"  –1 +/
Сообщение от Аноним (118), 14-Окт-22, 15:46 
Слово "неуч" ты написал первый, пытаясь своим хамством прикрыть отсутствие знаний. Ты даже не знаешь как база правильно называется про которую пытаешься рассуждать.

Функция очистки называется vacuum "There are two variants of the VACUUM command. The first form, known as "lazy vacuum" or just VACUUM" https://github.com/postgres/postgres/blob/master/src/backend...

а автовакуум — это процесс.

Никто vacuum full на базах с высокой активностью не делает, их бы заблокировало.

Ответить | Правка | Наверх | Cообщить модератору

150. "Релиз СУБД PostgreSQL 15"  –2 +/
Сообщение от Анно Домини (?), 14-Окт-22, 16:56 
Я работаю с БД больше, чем ты на свете живёшь, неуч, и не надо мне рассказывать сказки про то, что никто не делает вакуум на базах, которые разрастаются до петабайтов. Постгрес не может нормально работать без регулярного полного вакуума и сопутствующего даунтайма, а мускул может. Точка.
Ответить | Правка | Наверх | Cообщить модератору

166. "Релиз СУБД PostgreSQL 15"  –1 +/
Сообщение от Заноним (?), 15-Окт-22, 02:56 
А ничего, что mysql может невзначай целиком упасть в любом треде (например при drop'е временной таблички), попутно покоцав данные? Не умеет сам в функции (и упаси вас двоичныйкод использовать udf)? Да и на петабайтах mysql не вывозит, т.к. не поддерживает Point In Time Recovery в отличии от pg.
Ответить | Правка | Наверх | Cообщить модератору

167. "Релиз СУБД PostgreSQL 15"  –1 +/
Сообщение от Заноним (?), 15-Окт-22, 03:14 
про функции в том смысле, что в mysql они весьма бедны.
Ответить | Правка | К родителю #166 | Наверх | Cообщить модератору

172. "Релиз СУБД PostgreSQL 15"  –1 +/
Сообщение от penetrator (?), 15-Окт-22, 11:57 
> А ничего, что mysql может невзначай целиком упасть в любом треде (например
> при drop'е временной таблички), попутно покоцав данные? Не умеет сам в
> функции (и упаси вас двоичныйкод использовать udf)? Да и на петабайтах
> mysql не вывозит, т.к. не поддерживает Point In Time Recovery в
> отличии от pg.

это оно?

https://dev.mysql.com/doc/mysql-backup-excerpt/8.0/en/point-...
https://dev.mysql.com/doc/mysql-backup-excerpt/8.0/en/point-...

и функции космические нах не нужны в СУБД, перекладывать на базу то, что она не должна делать - плохое решение

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

Ответить | Правка | К родителю #166 | Наверх | Cообщить модератору

203. "Релиз СУБД PostgreSQL 15"  –1 +/
Сообщение от Заноним (?), 17-Окт-22, 00:31 
По поводу:
https://dev.mysql.com/doc/mysql-backup-excerpt/8.0/en/point-...
https://dev.mysql.com/doc/mysql-backup-excerpt/8.0/en/point-...

Этот детский сад, на практике поюзайте на базе от десятков TB - быстро осознаете, что эта "реализация" в mysql непредсказуема.

По поводу функций - какое-то помешательство, тотальное у свидетелей горизонтально-масштабируемой бизнес-логики... Так окромя такой бизнес-логики, есть и другие задачи, которые функциями в СУБД решать быстрее, удобнее и эффективнее. Например гекодинг с опорой на PostGIS (прикинь это тоже набор функций, типов, моделей и он даже обновляется) - просто мастхэв и только идиот будет это на питон перепихивать. А так ухли вообще СУБД применять, положите в файл и пишите воткруг всё сами, а лучше вообще ОС напишите сразу с блек-джеком и рест-апи.

Ответить | Правка | К родителю #172 | Наверх | Cообщить модератору

220. "Релиз СУБД PostgreSQL 15"  +/
Сообщение от Аноним (220), 19-Окт-22, 07:29 
Ради интереса решил проверить не растущую на дрожжах базу на мыскле.

Итак, есть некая таблица, в которую активно идет INSERT/UPDATE и никакого DELETE. Смотрим размер таблички:

-rw-r----- 1 mysql mysql 260046848 окт 19 12:06 radacct.ibd

автопурж ваш включен и "не нагружает". Запускаем руками OPTIMIZE TABLE, и после 5 минут жевания соплей получаем

-rw-r----- 1 mysql mysql 201326592 окт 19 12:15 radacct.ibd

Да, в эту таблицу в процессе продолжал валиться поток запросов UPDATE/INSERT.

Таки в итоге получаем ~23% ужатия таблицы при ручном OPTIMIZE.

А, да. В случае с точно такой же работой под PG процент ужатия таблицы при ручной вакууме составляет ~10% после автовакуума.

При активном DELETE размер занимаемого таблицей места и там и там не стремится к уменьшению. Ну и добавим ко всему, что массовый DELETE в мыскле это боль, а при наличии репликации это боль-боль, при которой проще грохнуть на реплике базу и тупо перезалить ее из бэкапа примари.

Ответить | Правка | К родителю #114 | Наверх | Cообщить модератору

222. "Релиз СУБД PostgreSQL 15"  +/
Сообщение от Анно Домини (?), 19-Окт-22, 18:56 
RTFM.

https://dev.mysql.com/doc/refman/8.0/en/innodb-purge-configu...

Purge runs on a *periodic* schedule.

Ответить | Правка | Наверх | Cообщить модератору

223. "Релиз СУБД PostgreSQL 15"  +/
Сообщение от Анно Домини (?), 19-Окт-22, 19:00 
> RTFM.
> https://dev.mysql.com/doc/refman/8.0/en/innodb-purge-configu...
> Purge runs on a *periodic* schedule.

+ https://www.percona.com/blog/2014/10/17/innodb-transaction-h.../

Ответить | Правка | Наверх | Cообщить модератору

63. "Релиз СУБД PostgreSQL 15"  –6 +/
Сообщение от Chlen22sm (?), 13-Окт-22, 21:26 
> Базу с вакуумом трудно назвать нормальной

Тоже всегда считал это лютейшей дичью

Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

66. "Релиз СУБД PostgreSQL 15"  –3 +/
Сообщение от Славик (?), 13-Окт-22, 21:55 
Дазе с нормальным дизайном вакуум ненужен.
Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

106. "Релиз СУБД PostgreSQL 15"  –2 +/
Сообщение от Славик (?), 14-Окт-22, 10:04 
> Дазе с нормальным дизайном вакуум ненужен.

Я имел ввиду Базе с нормальным дизайном...

Ответить | Правка | Наверх | Cообщить модератору

127. "Релиз СУБД PostgreSQL 15"  –1 +/
Сообщение от Аноним (118), 14-Окт-22, 14:26 
Типа MyISAM?
Ответить | Правка | Наверх | Cообщить модератору

146. "Релиз СУБД PostgreSQL 15"  +2 +/
Сообщение от Славик (ok), 14-Окт-22, 16:33 
> Типа MyISAM?

не СУБД а базе данных. В курсе что это такое дизайн базы данных? Или ты из тех фулстакеров, на все руки мастеров.

Ответить | Правка | Наверх | Cообщить модератору

78. "Релиз СУБД PostgreSQL 15"  +2 +/
Сообщение от Аноним (78), 14-Окт-22, 00:31 
Так ты его отключить можешь, но тогда сам решай проблемы которые решает вакуум
Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

115. "Релиз СУБД PostgreSQL 15"  –1 +/
Сообщение от Анно Домини (?), 14-Окт-22, 13:40 
То бишь, не можешь.
Ответить | Правка | Наверх | Cообщить модератору

128. "Релиз СУБД PostgreSQL 15"  +/
Сообщение от Аноним (118), 14-Окт-22, 14:27 
Как и отключить purge в mysql.
Ответить | Правка | Наверх | Cообщить модератору

132. "Релиз СУБД PostgreSQL 15"  –1 +/
Сообщение от Анно Домини (?), 14-Окт-22, 14:32 
> Как и отключить purge в mysql.

Purge не нагружает базу так сильно как автовакуум, а ручной вакуум в мускуле  не нужен, потому что база не пухнет из-за более правильной архитектуры.

Ответить | Правка | Наверх | Cообщить модератору

138. "Релиз СУБД PostgreSQL 15"  –1 +/
Сообщение от Аноним (118), 14-Окт-22, 15:55 
Нагрузка от вакуум настраивается и по молчанию он ничего не нагружает, ручной вакуум в мускукле нужен, потому что от массовых delete база пухнет точно так же, так как архитектуры у всех MVCC движков похожи и подразумевают хранение старых туплов иначе они бы не называли MULTIVersion, а понятие правильности архитектуры не бывает в вакууме ;-) понятие «правильности» зависит от требований, у всех MVCC движков есть плюсы и минусы.
Ответить | Правка | Наверх | Cообщить модератору

151. "Релиз СУБД PostgreSQL 15"  +/
Сообщение от Анно Домини (?), 14-Окт-22, 17:02 
Я смотрю, ты уже забыл статью, которую комментировал два часа назад, неуч. Ничего, я буду тыкать тебя в неё носом, пока ты полностью не просветлишься относительно разницы подходов Постгре и мускула, из-за которой оптимизация базы с даунтаймом требуется в мускуле гораздо реже: http://rhaas.blogspot.com/2011/02/mysql-vs-postgresql-part-2...
Ответить | Правка | Наверх | Cообщить модератору

152. "Релиз СУБД PostgreSQL 15"  –1 +/
Сообщение от Анно Домини (?), 14-Окт-22, 17:05 
Ничего не нагружает только у клоунов на локалхосте, которые никогда в жизни прода не видели, вроде тебя.

https://stackoverflow.com/questions/54831212/postgresql-auto...

Ответить | Правка | К родителю #138 | Наверх | Cообщить модератору

159. "Релиз СУБД PostgreSQL 15"  +/
Сообщение от Аноним (159), 14-Окт-22, 21:40 
Напротив, нормальная база может быть только с вакуумом, потому что полноценная параллельность и изоляция подразумевает хранение нескольких версий строк (тогда как innodb'шные undo логи - это как раз уродство и лишние копирования на каждый чих), а их неизбежно нужно периодически чистить. Ну да, при этом нужно чтобы у вас транзации не висели бесконечно и да, на некоторых ворклоудов его нужно явно настраивать, но это не rocket science.
Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

175. "Релиз СУБД PostgreSQL 15"  +1 +/
Сообщение от Прохожий (??), 15-Окт-22, 14:19 
У Oracle, например, которая нормальная СУБД, нет вакуума. Есть специальное табличное пространство для целей хранения предыдущих версий данных.
Ответить | Правка | Наверх | Cообщить модератору

207. "Релиз СУБД PostgreSQL 15"  +1 +/
Сообщение от Заноним (?), 17-Окт-22, 15:17 
> Oracle ... нормальная СУБД

Щаз! Ниразу не нормальная СУБД, в ней просто тонны ньюансов, легаси конструкций и performance-penalty элементов в самых неожиданных местах.

Ответить | Правка | Наверх | Cообщить модератору

217. "Релиз СУБД PostgreSQL 15"  +/
Сообщение от Прохожий (??), 19-Окт-22, 06:18 
В каком зрелом и сложном продукте это не так? Про легаси конструкции хотелось бы больше подробностей.
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру