RE
все проекты на PG, но понимаю, что в определенных сценариях, деградация по скорости идет, до очередного полного вакума.
Size: a a a
2021 May 12
ВС
Любимый спор за СУБД)
ВС
Все равно все воруют идеи у оракла)
RN
Скорее просьба подкрепить аргументами :)
RN
Наверное нет, не все :)
RE
я был бы рад. Но PGшная multiversion она как у Interbase. При ковровых update, всё портит. Но говорят в 13 PG уже будет новый движок хранения, как в MySQL и Oracle.
AA
ораклу не интересна ниша до 1000 пользователей, там другие кормятся
ВС
Всегда будет так. Кто то впереди, кто то догоняет)
RN
Именно, кто-то копирует, а кто-то придумывает :)
RE
сейчас они таких до 1000 пользователей с радостью в облако гонят. Понятное дело, что не в РФ
ВС
А что такое "ковровый апдейт"
RN
В РФ все ещё много оракла, из носухи конечно уходит.
RE
ну когда не единичные update, а сразу во всех записях таблицы
ВС
В OLTP системах он где возникает?
RE
в биллинге, финальные перерасчёты например, когда изменения всех мастер данных точно внесены
ВС
Билинги в ERP это совсем маленькая часть и используется даже не всегда
RN
Пока аргументы так себе ...
ВС
и там даже при очень большом объеме - сотни тысяч записей надо апдейтнуть. назвать это "ковровым апдейтом" ну наверно с натяжкой
RN
Есть же решения, когда к примеру через IDM ...
ВС
да на самом деле там много решений даже средствами СУБД. основное замедление апдейтов - ролбеки, индексы и ключи. если прям уж надо что то много апдейтнуть, чтоб не возникало каскадов нагрузки есть спецприемы которые проведут транзакции например без ролбеков, или проводить апдейт многих записей одной транзакцией - чтобы индексы теряли актуальность не после каждого комита