Интересная 3адача

Есть таблица в которую льются записи записи "добавляются" "изменяются" "удаляются" пользователем. Необходимо реализовать механизм который бы позволяля на посмотреть состояние таблицы на любой смоент времени, не используя при этом дополнительные поля, кроме как версии видимо. Таблица сожержит более 100000000000 записей. Может быть кто подскажет в каком направлении мыслить ?

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

Кто нибудь так делал? Насколько медленно это будет работать при таблицах в 100 миллионов записей ?

Немного непонятно суть вопроса. Объясните пожалуйста по русски что это значит.

позволяля на посмотреть состояние таблицы на любой смоент времени

ps. А вообще можно так:
хранить все в той же таблице, но ничего не удалять/изменять, а только добавлять, и помечать версии.
При изменении строки, меняем в ней только версию(помечаем устаревшей), Но добавляем новую строку с измененными данными.
Строк конечно получится много... Насколько это медленно даже предположить не могу

0

1. Делается таблица с логом и таблица с состояниями на момент времени.
2. Пишется процедура, которая расчитывает состояния на момент времени по таблице-логу.
3. Пишется ещё одна процедура, которая рассчитывает новое состояние на заданный момент от уже существующего состояния из таблицы-состояний.
4. Делается задание, которое считает состояния с заданными интервалами. Используем процедуру 2 или 3.
5. Когда нужно получить "отчёт на заданный момент", то сначала запускаем процедуру 3, а затем уже делаем отчет.

Процедура 3 нужна для обсчета только малой части лога.

Типичный пример - отчёты оборотов по складу.

Наличие такой задачи - говорит о наличии большой проблемы в учёте. Либо не определён отчётный период, либо он не соблюдается. Проще говоря - учёта нет.

Процедура 2 нужна для инициализации таблицы состояний. Периодически нужно будут делать её "сброс" - учёт-то кривой и будут правки задним числом.

2

Сообщение от Laba 1. Делается таблица с логом и таблица с состояниями на момент времени. 2. Пишется процедура, которая расчитывает состояния на момент времени по таблице-логу. 3. Пишется ещё одна процедура, которая рассчитывает новое состояние на заданный момент от уже существующего состояния из таблицы-состояний. 4. Делается задание, которое считает состояния с заданными интервалами. Используем процедуру 2 или 3. 5. Когда нужно получить "отчёт на заданный момент", то сначала запускаем процедуру 3, а затем уже делаем отчет.

С таблице состояний понятно, она скорее всего "исходная таблица" + "столбец версия". Как может выглядеть таблица-лог, с учетом того что на ее основе + значения "ближайшего состояния" можно было бы рассчитать состояние в нужный момент времени?

Добавлено через 59 минут
Наверное можно так
1. Время
2. Событие (sql запрос в чистом виде выполненый на данных)
т.о. состояние в момент времени = ближайшее состояние + последовательность запросов из таблицы лог выполненых "динамик sql".

0

Пусть у нас есть таблица лог. Пишем в неё копию записи из оригинальной таблицы (с пометкой "удалена, "изменена", "добавлена").

Пусть нас интересует, то как выглядела оригинальная таблица на такой-то момент - это состояние.

Тогда моё понятие "таблица-состояний" развернётся, например, в 2 таблицы:
- таблица A с параметрами расчёта (ид состояния, врямя этого состояния, кто и когда считал, нужно ли хранить состояние)
- таблица В с данными этого состояния - записи в оригинальной таблице на заданный момент.

Во-первых, одна и та же запись из лога может попадать в разные состояния. Но она лежит в логе и для доступа к ней нужно каждый раз перемалывать лишние данные. Возможностей сегментировать у нас мало - только версия или дата записи в лог. По ним, скорее всего, сделаем индекс, но использовать его для формирования состояния "на лету" вряд ли получиться, поскольку это дата изменения, а не дата состояния.

Мы делаем копию записи из таблицы-лога в таблицу B. Делаем ради уменьшения объёма обрабатываемых данных. Таблица В легко сегментируется по ид-состоянию, типу расчета, дате формирования тип и т.д. Тратим время на создание копии, но выигрываем при дальнейшей обработке.

Если нам нужно новое состояние, то мы можем:
- либо сканировать всю таблицу-лог,
- либо скопировать предыдущее состояние и отредактировать его (читаем лог с даты предыдущего состояния до даты нужного состояния и отобранные записи из лога используем для правки скопированного состояния).

Скорее всего, где-то да будет нужда в агрегированных значениях. Просто так что ли будете смотреть на состояние? Наверное, отчёт по ней будете делать. Может сразу рассчитывать данные под отчёт и хранить их, а не состояния?

Вот таблицы А или В это то самое место. И тогда они уже не будут "исходная таблица + столбец версия".

А если есть нужда в агрегированных данных, то легче их досчитывать от уже рассчитанного состояния.

0

Не совсем понятно, какой смысл вы вкладываете во фразу

... одна и та же запись из лога может попадать в разные состояния...

Если я вас правильно понял, множество состояний - последовательность снимков (snapshot) таблицы в моменты времени через определенный интервал. Сущность последующего состояния - есть предыдущее состояния + изменения из таблицы лог, т.о. записи в лог таблице можно разбить на группы набор значений каждой их которых определенным образом влияет на переход снимка таблицы из одного состояния в другое, согласно этой логике запись из предыдущег интервала особого смысла не имеет, потому как уже учтена в текущем состоянии, от которого мы и отталкиваемся для расчета нужного shapshot. Поясните, если не сложно.

0

Прочитал. Всё вроде так и есть. Я это и имел ввиду. Ваш вопрос (проблему) не очень понял.

0

Не совсем понятно, что вы имеете ввиду говоря что "одна и та же запись из лога может попадать в разные состояния". Я понял что одна запись входит (попадает, влияет) ТОЛЬКО на одно состояние, состояние перехода от одного к другому.

0

Когда написал, что одна запись попадает в два состояния, то имел ввиду следующее.
Пусть в момент X в лог попала запись.
Допустим нужно иметь состояние на T1 и T2 (T1<T2).
Если с оригинальной записью с момента X до T1 и T2 ничего не произошло, то запись из лога будет и в состоянии T1, и в T2.

0

Понятно.

0

Можно смотреть на задачу так.

Пусть у каждой оригинальной записи есть ид. В логе для этого ид хранится _одна_ и более записей. В кажой записи лога есть дата изменения и вид операции (доб, изм, удл)

Тогда для получения состояния на момент T1 нужно выбрать для каждого ид последню запись до момента T1. И выбросить все записи помеченные как удл.

Такой запрос можно написать. Только он работать будет в режиме полного сканирования таблицы. А таблица большая. И оптимизировать не получиться. Разве железо у гугла в аренду прикупить

0