172 похожих чатов

У меня опять теоретический вопрос, на этот раз о кишках

сервера БД.
есть поток событий (не очень большой, примерно 1-1.5к в секунду). у каждого события есть один уникальный признак и 3 возможно не уникальных.
нужно сохранить только последнее состояние для каждого уникального события.
в моем мире ( :) ) я бы просто использовал список, например, с доступом по хэшу от уникального признака и каждый раз переписывал состояние вне зависимости от того, изменилось оно или нет. операции в памяти - быстрые.

в случае с БД, как я понял, можно делать INSERT ... ON CONFLICT UPDATE.

вопрос в следующем - движок БД поймет, что неуникальные записи не изменились и не будет ничего апдейтить, или втупую каждый раз будет аплейтить безусловно?

тупой пример:
CREATE TABLE T1 (uid primary key not null, property1 int, property2 int, property 3 int)
insert into t1 (1, 2,3,4);
insert into t1(1, 1,1,4);

при вставке второй записи естественно возникнет исключение неуникальности uid. будет ли движок БД обновлять property3, учитывая, что оно не изменилось с предидущего раза?

4 ответов

12 просмотров
Дмитрий-Бессонов Автор вопроса

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

MVCC требует хранить прошлое состояние

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

Новая версия будет создаваться всегда. Но при определённых условиях, если Посгрес поймёт что старая никому не нужна и старая и новая версия окажутся на одной странице, то старая версия реюзнётся достаточно быстро. В противном случае на странице останется "дырка". Если записи на этой странице больше апдейтится не будет, то она там так и останется - никакой vacuum её не схлопнет. Т.е. у нас будет фрагментация. Поможет только vacuum full - полное переписываение таблицы. Кроме того, в Посгресе реализован hot update: если апдейт не затрагивает проиндексированные поля и новая версия попадает на одну страницу со старой, то в индексы она включаться не будет, а будет провязана в hot update цепочку. Что значительно ускоряет апдейты. Но это только если не поменялось ни одно из проиндексированных полей. Самое очевидной решение - это использовать upsert (insert ... on conflict update). Но в некоторых случаях append only табличка может действительно оказаться более эффективной.

Похожие вопросы

Обсуждают сегодня

Господа, а что сейчас вообще с рынком труда на делфи происходит? Какова ситуация?
Rꙮman Yankꙮvsky
29
А вообще, что может смущать в самой Julia - бы сказал, что нет единого стандартного подхода по многим моментам, поэтому многое выглядит как "хаки" и произвол. Короче говоря, с...
Viktor G.
2
30500 за редактор? )
Владимир
47
а через ESC-код ?
Alexey Kulakov
29
Чёт не понял, я ж правильной функцией воспользовался чтобы вывести отладочную информацию? но что-то она не ловится
notme
18
У меня есть функция где происходит это: write_bit(buffer, 1); write_bit(buffer, 0); write_bit(buffer, 1); write_bit(buffer, 1); write_bit(buffer, 1); w...
~
14
Добрый день! Скажите пожалуйста, а какие программы вы бы рекомендовали написать для того, чтобы научиться управлять памятью? Можно написать динамический массив, можно связный ...
Филипп
7
Недавно Google Project Zero нашёл багу в SQLite с помощью LLM, о чём достаточно было шумно в определённых интернетах, которые сопровождались рассказами, что скоро всех "ибешни...
Alex Sherbakov
5
Ребят в СИ можно реализовать ООП?
Николай
33
https://github.com/erlang/otp/blob/OTP-27.1/lib/kernel/src/logger_h_common.erl#L174 https://github.com/erlang/otp/blob/OTP-27.1/lib/kernel/src/logger_olp.erl#L76 15 лет назад...
Maksim Lapshin
20
Карта сайта