Интересно, если бы такая штука была с самого начала, ей бы пользовались?

ТаблоидNickDeeИнтересно, если бы такая штука была с самого начала, ей бы пользовались?если бы ты поимел удовольствие видеть бесконечные "100500 млн records indexed" по одной и той же аудитной помойке, которая тебе в бол-ве случаев вообще не нужна (а нужна только юзерам), то ты бы точно пользовался :-)
Я тоже придумал где я бы воспользовался в прошлом. Я бы логи хранил вместе с БД, а не сливал бы их в отдельную ради быстрого b/r.

Кстати PITR и flashback query вроде хорошо ложатся на архитектуру FB :) Немного ODS поменять. Мусор не убирать.
А кто-нибудь такое уже умеет из больших игроков? Или мы будем первыми? :)

Dimitry Sibiryakov"Это делается совершенно иначе", - сказал мне тогда Влад.
Очень может быть :)

dimitrNickDeeМусор не убирать
и тормозить все сильнее и сильнее в надежде что оный флешбек таки кому-нибудь понадобиться...
Значит нужно придумать алгоритм, чтобы скорость не зависела от количества версий. Текущий алгоритм где-нибудь описан?

ТаблоидЗЫ. Да и не решит это простую задачу: пропустить рестор не нужных сейчас данных, на которые нет ссылок из других таблиц.
Это-то понятно.

ТаблоидВерсии хранят ИД транзакций, которые их создали (см. тут ). ЕЯПП, сейчас идёт сначала поиск самой записи, а потом уже начинается ковыряние в её версиях, чтобы выбрать из них ту, которую имеет права видеть текущая транзакция. Т.е. поиск версии идёт просто "линейным перебором".
Быстрый обход версий всех записей некоторой таблицы, которые существовали *до* момента времени tx, возможен только при каком-то подобии "индекса" с убывающим timestamp-ключем, хранящим указатели на версии в качестве значений. Чтобы при входном значении ключа (каком-то таймштампе) быстро выйти на нужный лист и начать движение по листовому уровню, а затем по каждому указателю вытряхивать версию. Какой будет размер у этого индекса ? И сколько времени уйдёт на реализацию этого и отлов багов ?
timestamps должны быть в TIP. А с версиями должны храниться Id транзакций. При чтении читать от хвоста, но не читать все 100000 версий, а читать только несколько последних актуальных (номер первой актуальной хранить вместе с записью, и своевременно изменять её (сборщик мусора должен не мусор убирать, а изменять номер последней актуальной версии)). Как-то так :)

ТаблоидNickDeeКак-то так :)ну, а по поводу размера такой базы, в которой существуют все версии от Царя Гороха ради флешбака, - что скажешь ?
Это юзеру решать :)
Я бы решил положительно в нескольких случаях (ради истории). Кому-то откат бы пригодился (правда он имхо должен бы и для метаданных работать).
К тому же всегда можно в заголовке БД прописать "хранить версии начиная с такой-то даты(номера транзакции)", и не бэкапить их (и чистить фоновым сборщиком мусора, ради освобождения места на страницах).