| |
| 2.2, Аноним (2), 08:21, 02/12/2024 [^] [^^] [^^^] [ответить]
| +7 +/– |
Может, и не врут, только вот сколько букв от ACID осталось?
| | |
| |
| 3.7, Аноним (7), 09:13, 02/12/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
Просто покажи циферки побольше и менеджмент будет доволен.
| | |
| 3.14, funny.falcon (?), 10:50, 02/12/2024 [^] [^^] [^^^] [ответить]
| +5 +/– |
Всё там с ACID в порядке. Архитектура Постгресса действительно не оптимальна в нынешних реалиях, и сделать что-то выделяющееся на её фоне вполне возможно.
| | |
| |
| 4.33, freebzzZZZzzd (ok), 17:57, 02/12/2024 [^] [^^] [^^^] [ответить]
| –2 +/– |
 >Всё там с ACID в порядке
а ты кто? вот когда jepsen пруфнет, тогда поверим.
у субд вообще много разных проблем, не только бинарное "acid да/нет".
по описанию вообще шг в сторону монго сделали ) осталось JSON нормально сделать и лет 5 повылизывать код. и получится что-то путнее
| | |
|
| 3.97, Alexander Korotkov (?), 10:55, 06/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
 Гарантии ACID такие же как и в дефолтовом движке PostgreSQL, за исключением отсутствия поддержки SSI (за всю карьеру не припомню случая где он был бы реально необходим). Но на текущем этапе зрелости проекта серьёзные баги, конечно, могут быть.
| | |
| |
| 4.98, Аноним (98), 14:26, 06/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
SSI нужен. Полно задач, в которых бизнес-правила опираются на хронологию, выстроенную вокруг начала выполнения транзакции, а не их завершения. И если это правило не выполняется, то транзакция, как минимум, должна считаться не валидной. Хотя, конечно, кратно больше ситуаций, где SSI излишен совершенно и RC/RR достаточно.
| | |
| |
| |
| 6.103, AName (?), 15:08, 23/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
Положительный отклик на ваш комментарий понятен -- никто не любит возиться со случаями, когда serializable действительно нужен, и никто не любит его стандартного поведения. Тем не менее, подходы вроде select for update не позволяют достаточно приблизиться к семантике "честного" SSI. Потому что именно так, как себя ведёт SSI, единственный доступный и реализуемый подход, когда важна последовательность транзакционных событий. На практике чаще всего честный S не используют не потому, что он не нужен на уровне предметной области, а потому что его поведение считают, скажем так, странным -- ведь все хотят, чтобы на этом уровне конфликты последовательности транзакций НЕ ДОПУСКАЛИСЬ в том смысле, чтобы они как-то сами собой РАЗРЕШАЛИСЬ, а не так, как это сейчас и единственно возможно, выбрасыванием исключения о невозможности соблюсти условия транзакции, которое, вот же досада, нужно как-то самому разработчику разрешать. Так вот, это я к тому, что если важна последовательность совершения транзакций, то сейчас ПРОСТО НЕТ НИКАКОГО ДРУГОГО СПОСОБА, кроме унылого и нелюбимого всеми S(SI). То, что его разработчики всячески избегают использовать, не значит, что он семантически избыточен и "тоже самое можно сделать иначе" (потому что иначе нельзя), а потому что... ну интеллектуально сложно честно реализовывать такие доменные поведения и даже казалось бы в тех сферах, где поведение модели должно быть предельно адекватным доменному, сплошь и рядом упрощения разной степени безответственности. Но что ещё веселей, что зачастую и доменный эксперт (заказчик) честную реализацию воспринимает как какой-то нелепый абсурд. В общем, по-моему, обычное дело: неосилянты, кароч, а не не нужно.
| | |
|
|
|
|
| 2.93, ptr (ok), 17:20, 04/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
 Может и не врут, но TPC-C - это всё же тест больше на модификацию, чем на выборку. И вообще без тяжелых выборок. А на аналитическом профиле нагрузки можно получить наоборот, большой провал.
UnDo лог должен хранить записи до завершения всех транзакций, которые начались до попадания записи в UnDo лог. Да еще и эффективно находить эти записи для таких транзакций, так как они должны видеть эти записи такими, какими они были на момент начала транзакции. И тут вполне можно потерять больше, чем выиграл на модификациях в страницах по месту.
| | |
|
| |
| 2.10, chdlb (?), 10:16, 02/12/2024 [^] [^^] [^^^] [ответить]
| +8 +/– | |
а теперь смотрим как он считается:
Number of mentions of the system on websites, measured as number of results in search engines queries. At the moment, we use Google and Bing for this measurement. In order to count only relevant results, we are searching for <system name> together with the term database, e.g. "Oracle" and "database".
General interest in the system. For this measurement, we use the frequency of searches in Google Trends.
Frequency of technical discussions about the system. We use the number of related questions and the number of interested users on the well-known IT-related Q&A sites Stack Overflow and DBA Stack Exchange.
Number of job offers, in which the system is mentioned. We use the number of offers on the leading job search engines Indeed and Simply Hired.
Number of profiles in professional networks, in which the system is mentioned. We use the internationally most popular professional network LinkedIn.
Relevance in social networks. We count the number of Twitter (X) tweets, in which the system is mentioned.
т.е. достаточно, чтобы было много головняка - и упс, ты лидер на форумах или в поисковых запросах
это явно не то что ожидаешь под словом RANK, понимая его как некую функцию от качества продукта, неизвестну. функции, но от характеристик продукта, а не вот это вот всё
| | |
| |
| 3.30, нах. (?), 15:44, 02/12/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> это явно не то что ожидаешь под словом RANK
но хотя бы - интересно. И да, те у кого все работает, не будут оставлять хвалебные отзывы в "twitter events". А вот "оно опять %%!$!" - да.
Так что инфа полезная, главное уметь понять.
| | |
| 3.40, Прохожий (??), 01:36, 03/12/2024 [^] [^^] [^^^] [ответить] | +/– | 1 То есть вот этот критерий Number of job offers вы в попытке построить свою ... большой текст свёрнут, показать | | |
| |
| 4.41, Прохожий (??), 01:37, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
Опечатка:
если специалистов по СУБД "Б" больше, чем специалистов по СУБД "А" - так правильно
| | |
| 4.43, chdlb (?), 09:18, 03/12/2024 [^] [^^] [^^^] [ответить] | +/– | Я ничего не выбирал, а сказал, что этот ранк бессмысленный по своей сути и показ... большой текст свёрнут, показать | | |
|
|
|
| |
| 2.11, chdlb (?), 10:17, 02/12/2024 [^] [^^] [^^^] [ответить]
| +2 +/– |
а для всего постгреса шардинг, постгрес в принципе сильно переоценен
| | |
| |
| 3.47, Аноним (98), 12:13, 03/12/2024 [^] [^^] [^^^] [ответить]
| –1 +/– |
Шардинг это не про РСУБД вообще. Как слоить данные решение прикладного уровня, а не модельного.
| | |
| |
| 4.77, chdlb (?), 18:07, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– | |
тот случай, когда даже электромоторчик из детской машинки умнее, чем очередной Аноним
погугли список распределенных RDBMS с шардингом на уровне бд - удивишься
а некоторые из них еще и синхронные, т.е полноценный multi-master
притом некоторые из них еще и кластерные с балансировкой нагрузки между нодами
| | |
| 4.79, chdlb (?), 18:15, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– | |
теперь что касается "слоить", прикладной уровень, модельный - я такого дерьма в голове с терминологией не видел очень давно, потому что всячекски старался избегать дешевых бложиков
в БД у тебя не модели, а таблицы, будет ли отражено это на модели в предметной области (он же domain в DDD) - это еще вопрос
в любом случае даже если моя БД, будет из одной таблицы, она все равно может шардится... )))
что там под слоить понимаешь вообще никто не знает, как в принципе и "прикладной уровень", так то СУБД тоже "прикладной уровень" )))
| | |
| |
| 5.85, Аноним (98), 12:10, 04/12/2024 [^] [^^] [^^^] [ответить] | –2 +/– | Дружок, шардинг это когда разраб на уровне р-модели да-да решает, что некая су... большой текст свёрнут, показать | | |
| |
| 6.86, chdlb (?), 15:04, 04/12/2024 [^] [^^] [^^^] [ответить] | +/– | этот бред надо заскринить это даже прочитать сложно, но ладно, если ты решил... большой текст свёрнут, показать | | |
| |
| 7.89, Аноним (98), 15:53, 04/12/2024 [^] [^^] [^^^] [ответить]
| –1 +/– |
При шардинге схема как может меняться, так может и не меняться. Если есть сущность с запредельным количеством реализаций, то подразумевается изменение модели -- вместо одной сущности в модели появляются n-сущностей, по которым распределяются реализации исходной.
Ещё раз. Имеет ли это какое-то отношение именно к Рсубд? Нет. Не имеет. Ещё раз, такая декомпозиция диктуется не теорией отношений, а реализацией.
| | |
| 7.90, Аноним (98), 16:06, 04/12/2024 [^] [^^] [^^^] [ответить]
| –1 +/– |
Если обобщить, то критерий шардирования/секционирования простой -- если в модель вводятся новые сущности, между которыми перераспределяются реализации прежде одной сущности, то это шардирование, если новые сущности не вводятся на уровне модели, а "физически" перераспределяются только реализации всё той же сущности, то это секционирование.
| | |
| 7.91, Аноним (98), 16:24, 04/12/2024 [^] [^^] [^^^] [ответить]
| –1 +/– |
Продолжим. Если взять, скажем, кусок сыру и фломастером разметить его на части, скажем, подписав на них "васе", "пете", "маше", то это разбиение куска сыра на секции -- кусок остался целым, но его снабдили мета-информацией для потребителя, провели секционирование. Если же кусок брутально нарезать ножом -- то это уже шардирование, потому что вместо одного куска сыра появилось много кусков.
В пэтэу на курсах тебе такого не объяснят.
| | |
| |
| 8.92, chdlb (?), 16:55, 04/12/2024 [^] [^^] [^^^] [ответить] | +1 +/– | я даже уже не читаю, что ты пишешь, и я надеюсь от твоих решений никто не зависи... текст свёрнут, показать | | |
|
|
|
|
|
|
|
| |
| 2.12, chdlb (?), 10:19, 02/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
это было бы логичным решением, но только если на замену родного движка, как подключаемый не вариант
| | |
| |
| 3.16, www2 (??), 10:53, 02/12/2024 [^] [^^] [^^^] [ответить]
| +/– | |
PostgreSQL - очень консервативная система. Пока что в виде подключаемого движка, потом, когда-нибудь, поменяют настройки и он по умолчанию будет использоваться при создании новых таблиц. Потом, глядишь, его начнут использовать большинство инсталляций. И только потом старый движок отключат, возможно, удалят, как устаревший.
Но всё это пока что вилами на воде писано. Надо хотя бы дождаться выпуска стабильной версии и доработки интерфейсов PostgreSQL для подключения этого движка без необходимости накладывать заплатки на исходный текст и пересобирать из исходников.
| | |
| |
| 4.18, нах. (?), 11:45, 02/12/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> Пока что в виде подключаемого движка
оно уже перестало требовать патчить основной код, или как было?
Потому что это обещали два года назад.
| | |
| |
| 5.20, нах. (?), 11:54, 02/12/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
А, уже вижу - "with extensibility patches". Вот когда будут в мэйнлайне, тогда и приходите.
| | |
|
|
|
|
| 1.6, anguest (?), 09:11, 02/12/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +8 +/– |
Попробовал предыдущий выпуск на реальной нагрузке. После определенного кол-ва запросов начинаются утечки памяти и все падает. Но надеюсь что допилят, очень нужная весчь.
| | |
| 1.17, ОООноним (?), 11:19, 02/12/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
>При выполнении операции UPDATE поддерживается замена данных по месту (без освобождения текущей записи и создания новой), что положительно сказывается на производительности.
Но ведь запись в конец при update и была сделана для повышения производительности. А теперь вернули как было и стало еще производительней?
| | |
| |
| 2.21, anonimus (?), 12:07, 02/12/2024 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Но ведь запись в конец при update и была сделана для повышения производительности.
это про HOT, но не все апдейты можно сделать HOT, поэтому для ванильного посргре нагрузка на rewrite тех же строк - это беда. В то же время MySQL или OracleDB работают при такой нагрузке стабильно
| | |
| 2.22, inklesspen (ok), 12:17, 02/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
 Пару раз попрыгаем туда-сюда и будет еще производительнее =D
Неизвестно в какой среде проводились тесты, с какими дисками, с какими рейдами если они были и т.д. и т.п.
К тому же, обновлять данные по месту записи в любом случае надо: надо записать, что физическая запись устарела и более недействительна (т.е. установить значение t_xmax). Постгрес в этом случае просто делает двойную запись: в новое место новые данные и в старое место пометку. Да и не факт, что новая запись в конце.
Вот WAL да, это Append-Only log и писать там куда-то еще не требуется
| | |
| 2.63, Аноним (98), 15:29, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
В конец чего? Новая строка при update вставляется туда, где место есть, совсем не обязательно в конец чего-то.
| | |
|
| 1.23, Аноним (23), 14:54, 02/12/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Надо срочно пробовать. PostgreSQL жутко неповоротлив, как в работе, так и в разработке. Но альтернатив нет, к сожалению.
| | |
| 1.24, Аноним (24), 15:13, 02/12/2024 [ответить] [﹢﹢﹢] [ · · · ] | +/– | Сейчас 1733140900 PostgreSQL 1996-07-08, 836784000, 896356900 ago, 100 ago Ori... большой текст свёрнут, показать | | |
| |
| 2.31, Аноним (31), 15:58, 02/12/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
А кому нужно ровно 100% от функциональности продукта "П", ни процентом больше, ни процентом меньше? Мне вот например достаточно базового CRUD без выпендрёжа. Если оно в 10 раз быстрее чем конкуренты и без каких-то особых проблем то отлично, такое мы берём.
| | |
| |
| 3.46, Alexander Korotkov (?), 10:53, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
Добавлю ещё, что в данном контексте я рассматриваю производительность именно самого табличного движка и непосредственно связанных подсистем (WAL, checkpointer, buffer manager и т.д.)
При этом в PostgreSQL есть ещё много узких мест: протокол, планировщик, экзекьютер и т.д., которые OrioleDB почти никак не затрагивает.
| | |
| 3.50, fuggy (ok), 12:31, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
 Они не открыли америку. Движок на основе undo logs, уже реализовали несколько лет назад zheap, сразу как только появилась возможность подключать кастомные движки. Есть где-то сравнение что из этого лучше, чтобы сравнивать похожие технологии. Ссылка полезная. Но нужно учитывать что у undo logs есть и свои минусы, что изменение записи требует вставки + перемещения старой версии в лог. В то время как у стандартного движка только вставка новой версии.
| | |
|
|
| 1.28, slew (ok), 15:38, 02/12/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
 Наконец-то сделали так, как в оракле было сделано 50 лет назад.
| | |
| |
| 2.29, нах. (?), 15:42, 02/12/2024 [^] [^^] [^^^] [ответить]
| +1 +/– | |
не сделали. Всего лишь бета. Зато - седьмая. Такими темпами успеют к концу света.
| | |
| 2.49, Аноним (98), 12:29, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
Оракл нормальным стал только с версии 9. Даже 8-ка была так себе удовольствием. Т.е. с начала 00-вых. Не полвека, а только четверть.
| | |
| 2.52, fuggy (ok), 12:33, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
Так а зачем городить велосипед, если можно взять взять тот же бесплатный mysql. Где тоже структура таблицы имеет первичный индекс.
| | |
| |
| 3.59, Аноним (98), 14:46, 03/12/2024 [^] [^^] [^^^] [ответить] | +/– | Это как понять -- структура таблицы имеет первичный индекс Табличка это упорядо... большой текст свёрнут, показать | | |
| |
| 4.70, fuggy (ok), 15:53, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
Почему только myisam, innodb тоже, который по сути остался единственным вариантом для acid транзакций. Там каждая таблица кластеризована по первичному индексу. И все остальные вторичные индексы ссылаются на этот индекс.
В отличие от postgresql, где все данные лежат в неупорядоченном массиве. Там кластеризация, это лишь временная операция. А также приходится часто обновлять индексы, из-за обновления строк новыми версиями.
| | |
| |
| 5.76, Аноним (98), 18:04, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
Ещё раз, таблица эта такая хрень, где есть первая строка, вторая, вторая ниже первой, но выше третьей, и так далее. И это порядок где-то в мета-инфе задан. Вот на листке бумажки ты табличку рисуешь карандашиком, а как ей пользоваться у тебя в социо-культурном коде в мозгах "зашито". Больше никаких таблиц нет. А "кластерная таблица" в МС или в Инно это дерево, а не таблица, в котором данные строк приделаны к листовому уровню. По факту это двунаправленных список.
И не в каких "неупорядоченных" массивах данные не лежат -- таких массивов не бывает, массив это множество, к которому приделали категорию порядка, т.е. упорядочили по определению. Типично данные "табличек"-отношений хранятся в куче.
| | |
| 5.78, Аноним (98), 18:11, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
Кластерная таблица очень-очень мутный термин. Потому что в МС кластерная таблица это про хранение данных отношения в структуре битри-индекса, а вот в Оракле кластерная таблица это вообще не про индексы, а про хранение однотипных данных разных отношений в одной куче.
| | |
|
|
|
|
| 1.35, Olololololololo (-), 20:43, 02/12/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>прямое связывание страниц в оперативной памяти со страницами в постоянном хранилище
Ну вот это они зря, нужно было всё самим ручками писать, а не ядро использовать и уж тем более не использовать mmap. Это прямой затык. Кто не верит ищите тесты гугле.
| | |
| |
| |
| |
| 4.57, Аноним (98), 14:31, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
Хабровая статья, как это часто бывает, перевод продуктивного бреда какого-то очередного шизофреника. Нет никакой проблемы с fsync-ом.
| | |
| |
| 5.65, Olololololololo (-), 15:34, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
Ждём оттвета Короткова.
Моё личное мнение, что БД должны использовать только direct io беря на себя функции кеша и т.п., если нужна надёжность и производительность.
| | |
| |
| 6.101, bOOster (ok), 11:31, 17/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
 Решение БД в 99% случаев не знает о каких нибудь специфичных, супербыстрых аппаратных средствах кэширования данных. Но система с этими средствами скорее всего работает нормально.
| | |
|
| 5.95, Alexander Korotkov (?), 08:18, 05/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
Бредом шизофреника я был статью не назвал. Но она является вольным пересказом треда постгресовой рассылки автором статьи. И что самое главное, там отсутствует финал – коммиты которыми всё закончилось.
| | |
|
| 4.73, Olololololololo (-), 16:21, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
И ещё вопросы:
- PostgreSQL использует huge pages, если нет то пробовали ли включать?
- Если пробовали какой результат?
Слышал, что или MariaDB или PerconaDB или т.п. включило huge pages и результат был хуже чем без них.
| | |
| 4.81, Alexander Korotkov (?), 08:11, 04/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
> - А fsync всё ещё используете (навеено этим https://habr.com/ru/articles/472684/)?
> - Не считаете, что использовать fsync в БД это глупо?
Да, fsync используем. Не считаю, что это глупо, но считаю то не оптимально.
К статье на хабре стоит добавить то, чем всё закончилось
https://git.postgresql.org/gitweb/?p=postgresql.git;h=1556cb2fc5c774c3f7390dd6
https://git.postgresql.org/gitweb/?p=postgresql.git;h=9ccdd7f66e3324d2b6d3dec2
> - Не думали использовать, что-то типа io_uring или spdk?
Да, планируем в будущем переходить на более продвинутые решения.
| | |
|
| 3.54, Olololololololo (-), 13:21, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– | |
>Мы mmap используем только для экспериментального режима хранения данных в persistent memory (проводили эксперименты с Intel Optane).
А это в принципе не важно для чего вы используете. HFT системы, например, не используют mmap т.к. ядро Linux становится тормозом. А ядро вы используете, значит и с optane у вас на нагрузках будут те же самые грабли.
| | |
| |
| 4.80, Alexander Korotkov (?), 08:01, 04/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
Как раз таки важно для чего использовать mmap!
Если мапить файл или блочное устройство – то ядро занимается подгрузкой и записью страниц, и происходят тормоза о которых вы говорите.
Если мапить персистентную память, подключенную к шине также как и обычная память, память просто мапится на адресное пространство процесса. И при этом уже во взаимодействии с данной памятью ядро никак не участвует.
Так что mmap mamp'у – рознь :)
| | |
|
| |
| 4.83, Alexander Korotkov (?), 09:00, 04/12/2024 [^] [^^] [^^^] [ответить]
| +/– | |
Да, OrioleDB написан на C.
Есть низкоуровневая часть кода, связанная с форматом tuples, упаковкой данных на страницы и т.д. Насколько я знаю, эта часть практически везде написана на C.
Есть часть кода, сильно завязанная на внутренние структуры и функции PostgreSQL, которые в свою очередь тоже написаны на C.
Между ними есть небольшая прослойка, которая возможно выиграла бы от Rust. Но не занимались.
| | |
|
|
|
| |
| 2.102, bOOster (ok), 11:34, 17/12/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> к 1с это можно прикрутить?
С 1С это вообще никак не связано. Есть еще уровень абстракции выше системы хранения с которым и работает 1С.
| | |
|
| 1.48, Аноним (98), 12:26, 03/12/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Прям маркетинговая няшка для утомлённых ораклом. Все приписываемые улучшения улучшения только в сознании дба-неофита. Сплошные разоблачения мифов. Нет вакуума -- ура!!! Счётчик 64 бита -- ура!!! Есть отдельное ТП для undo -- ура!!! Обновления по месту, а не постоянный cow -- ура!!! WAL на уровне строк, а не на уровне кластера целиком -- ура!!! Как-то слишком про желание сделать из одного, что-то совсем другое.
| | |
| |
| 2.55, Olololololololo (-), 13:25, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– | |
>Обновления по месту, а не постоянный cow -- ура!!!
Мне этот конкрентый момент показался спорным с точки зрения производительности и нагрузки. Нужны тесты. Предполагаю, профита в скорости не будет, а вот падение производительности не исключенно.
| | |
| |
| 3.60, Аноним (98), 14:50, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
>>Обновления по месту, а не постоянный cow -- ура!!!
> Мне этот конкрентый момент показался спорным с точки зрения производительности и нагрузки.
> Нужны тесты. Предполагаю, профита в скорости не будет, а вот падение
> производительности не исключенно.
Самый очевидный профит в том, что замена одной закорючки в строке из десятков или даже сотен полей не приведёт к созданию новой строки. Но модель MVCC отход от принципа всегда insert корёжит радикально.
| | |
| |
| 4.64, Olololololololo (-), 15:30, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
Мусье считает, что залочить (используя atomic операции) строку для её обновления это дешевле чем вставить новую? Может тебе мат.часть подучить?
| | |
| |
| 5.68, Аноним (98), 15:44, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
Мат. часть чего? Понятия не имею, что в конкретных условиях будет быстрее: найти место под вставку и скопировать или просто по месту, которое уже найдено, что-то поменять. По опыту лишь знаю, что даже при большом внимании к настройке вакуума файлы данных пухнут стремительно и необратимо, это в бд, в которых update-ов кратно больше insert-ов.
| | |
| |
| 6.71, Olololololololo (-), 16:04, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– | |
>Мат. часть чего?
Процессора, кешей, влияния atomics на кеши, протоколы когерентности кешей и т.п. и само собой каким образом делается обновление/вставка строки по месту. Про лог не упоминаю, ты сам про него пишешь ниже. Чтобы строку заменить/обновить по месту нужно эту строку залочить (у PostgreSQL, наскольку помню, есть такая возможность), а лок делается на атомиках, а чтобы добавить новую версию строки в конец файла БД нужно всего лишь её добавить атомарно залочив в метаданные, к которым нет такого потенциально высокого конкуретного доступа.
Дешевле лочить метаданные (заголовок таблицы) чем лочить строку и это я ещё не говорил про перенос старой строки в лог, про который ты написал ниже.
>Но вот Оракл как-то справляется
Правильнее сказать - PostgreSQL не справляется, но это не значит что подход PostgreSQL в некоторых вопросах хуже чем у Oracle. Вполне может быть, что подход у PostgreSQL правильный, но руки не дошли отполировать.
| | |
| |
| 7.72, Olololololololo (-), 16:10, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– | |
>Дешевле лочить метаданные (заголовок таблицы) чем лочить строку
Дополнение, при условии, что читателей больше чем писателей.
| | |
| 7.74, Аноним (98), 16:49, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
Э, Слон, как и прочие, в случае вставки вставляет не в конец (кого/чего?), а туда, где место есть. Т.е. это не тупая вставка в некий всегда известный заранее "хвост", а поиск куда вснуть в уже распределённом и только, если там нету, то выделить новую страницу, опять же, вопрос где. В общем, операция вставки далеко не факт, что дешевле, корректировки по месту. Хотя для корректировки по месту и надо лочить.
| | |
| 7.84, Alexander Korotkov (?), 09:07, 04/12/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> Правильнее сказать - PostgreSQL не справляется, но это не значит что подход PostgreSQL в некоторых вопросах хуже чем у Oracle. Вполне может быть, что подход у PostgreSQL правильный, но руки не дошли отполировать.
Я скорее склонен считать, что дело скорее в подходе PostgreSQL, чем в оптимизациях. Например, вот интересная критика подхода [1] из академических кругов.
О том, что PostgreSQL достаточно отполирован косвенно свидетельствует провал таких оптимизаций как WARM [2]. WARM должен был решить часть проблем MVCC, но породил такое количество архитектурных проблем, что доделать его не получилось
1. https://www.cs.cmu.edu/~pavlo/blog/2023/04/the-part-of-postgresql-we-hate-the-
2. https://www.postgresql.org/message-id/flat/CABOikdMNy6yowA%2BwTGK9RVd8iw&
| | |
|
|
| 5.69, Аноним (98), 15:51, 03/12/2024 [^] [^^] [^^^] [ответить]
| –2 +/– |
А, понял твой скепсис. Да, такой подход требуют где-то хранить лог (или не лог, а всю строку целиком) изменений для строки. И интуиция подсказывает, что вести такой лог будет недешево. Но вот Оракл как-то справляется. Я тестил ещё 13-тый Слон против 19-го Оракл. Оракл update-ы делает быстрее. Ни на что не претендую, но разница была до 40%. Условия были такие, что в исходно созданных и заполненных табличках кол-во строк не менялось, а менялись только сами строки. За цикл все таблички переписывались полностью. Сначала Слон и Оракл были более-менее равно, но чем больше циклов, тем Слон всё сильнее отставал. Во всех табличках был только один индекс по первичному ключу.
| | |
|
|
|
|
| 1.66, Аноним (98), 15:39, 03/12/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А в чём профит маппить буферы сразу на блоки? Такое больше не надо чекпоинтить? В этом?
| | |
|
