AlexGruВернее, почему проблема так остро не стоит? Почитать бы по этому аспекту что-то

Как уже сказали выше - в Oracle вместо write ahead log - реализован механизм UNDO.
Для баз данных с относительно небольшим объемом вставки/обновления данных подобная реализация вполне приемлима.

Т.е. для задач класса бухгалтерия - 2.5 бухалтера вносят максимум по три изменения в секунду. В этих условиях
вполне можно позволить себе и не такую роскошь - а еще и форинкеи, идексы и прочие праймари-уникеи всякие, чай мейнфрейм класс выдержит это все рандомное чтение-запись на микроскопической нагрузке (99% случаев применения RDBMS).


А вот когда начинается вопрос вставки многих десятков тысяч фактов в секунду (всякие биржевые роботы, показы рекламы и т.п.) и обновлений оных, то Oracle вполне ожидаемо...
ну не то чтобы садится в лужу, но начинает работать не настолько хорошо, быстро и с несколько НЕ гарантированным временем реакции.



И все что остается в этом случае - это все UPDATE и даже DELETE приводить к INSERT, даже есть концепция такая, кажется называется Temporal Database (Oracle Workplace - частный случай) https://en.wikipedia.org/wiki/Temporal_database

Т.е. база данных только делает INSERT (его время реакции ожидамое, UNDO не используется), вставляя эдакий version_id или change_time (primary key, естественно, уже невозможен)

А текущее/последнее состояние делать через SELECT v2 ... FROM NOT EXISTS ( v1.id = v2.id and v1.change_time > v2.change_time)


Тем самым получается тот самый WAL. А vacuum потом можно сделать уже вручную - через CREATE new_table AS SELECT ... NOT EXISTS, когда данные из OLTP класса перейдут в DHW - т.е. факты уже обновляться не будут, только читаться, это уже скорее задача ETL

Dimitry SibiryakovdbpatchКак уже сказали выше - в Oracle вместо write ahead log - реализован механизм UNDO.

Вообще-то write ahead log это redo, так что undo реализован не "вместо" а "в дополнение".


Называй как хочешь, но да есть концепция, по сути, write log only баз данных.
Частный случай - Interbase/Firebird (могу ошибаться), или из мира NoSQL/Embedded - LevelDB, LightningDB

Когда любой DML это по сути операция copy on write, т.е. гарантированно делается только один iops. Т.е. пишется, по сути, только лог, вся база данных - это лишь redo, а data/undo и прочего - просто нет как класса, только логи.

Имеет свое применение - потоковая запись (чтоб головки диска не гонять - рандомная запись - это мегабайт в секунду, линейная - 100 мегабайт, даже в случае SSD писать линейно намного быстрее)

И в Oracle такое можно достичь только принудительным путем - делать только INSERT (приводя UPDATE/DELETE к INSERT), да еще и с APPEND NOLOGGING - т.е. датафайл использовать просто как лог файл (изврат, но иногда приходится и на такое идти, чтоб справиться с потоком фактов).

Leonid KudryavtsevdbpatchИ в Oracle такое можно достичь только принудительным путем....
А зачем в Oracle такое достигать? redo log на отдельном диске, а запись в файлы базы идет асинхронно. Дальше можно тюнить размер buffer и кол-во dirty buffer'ом. AFAIK По крайне мере в 8'ке. В PostgreSQL так же.

Если же подходить к настройке экземпляра по принципу "Oracle умный, ему виднее" ( C ) админы, то никакое принуждение не поможет ))). IMHO

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

т.е. в течение дня ты вставляешь факты просто в датафайлы, recovery нам не нужен ибо копия данных все равно есть на стороне аппсервера, а вот потом делаешь вакуум (последнее состояние) и уже его отправляешь в DWH

при этом фактов очень много, на терабайты в день, в RAM просто не помещаются, обновления оных приводят к дисковому IO, со всеми вытекающими

задача выглядит наверное непонятной и слегка идиотичной, но, на самом деле, проста как дверь - у нас сотни миллионов фактов в день с минимум 3-4 обновлениями каждого, нам нужно максимально эффективно иметь возможность получить из базы данных последнее состояние.


т.е. сотни миллионов мелких nested-loop на UPDATE/DELETE превращаются в один большой hash-join по требованию, по строкам, которые только INSERT

Leonid Kudryavtsevdbpatch... на терабайты в день, в RAM просто не помещаются...
Добавить RAM )))

физически невозможно, и так все слоты забиты

xtenderDimitry SibiryakovОбычно бизнесу нужна также и история статусов, так что да - через инсерт и, возможно,
делит вместе с сущностью.
dbpatchИ все что остается в этом случае - это все UPDATE и даже DELETE приводить к INSERT, даже есть концепция такая, кажется называется Temporal Databaseгоспидя, откуда у вас такая каша то в головах?!
Во-первых, большинство реализаций SCD2/Temporal Validity включают в себя апдейт текущей записи и инсерт новой.
Во-вторых, это никоим образом не оптимизация по доступу, т.к. селекты в данном случае становятся на порядки медленнее, а их как раз обычно на порядки больше, чем инсертов/апдейтов/делитов вместе взятых.

у тебя каша в голове? ну ок.

да, иногда в подобных реализациях есть апдейт. если нагрузка небольшая, то даже работает - ну, когда один поток в 8000recs/s падает до 700rec/s за счет апдейта и тебя это вполне устраивает :)

селекты на порядки медленнее? селектов на порядки больше, это на сколько? в два раза, в десять раз медленее?

а как насчет всего одного селекта в раз в полчаса (на 80к вставок в секунду)?

или ты решил животрепещуще описать свою базу данных размером в 10 гигабайт с проводками?