Mysql - Как я могу запросить о прошлом (вернуться во времени)? - PullRequest
0 голосов
/ 09 сентября 2011

У меня есть база данных, которая постоянно меняется ... обновляет, вставляет и удаляет.По статистическим причинам нам нужно некоторое время, чтобы «вернуться в прошлое» (-: и запросить базу данных, как в прошлом.

Например: у меня есть таблица с именем user, я вчера обновилодному из пользователей нравится следующее:

update user set status = 1 where user_id = 2656

Старый status был равен 0, поэтому, если я могу "вернуться во времени" ко вчерашнему дню и запросить его, получится status 0, а в случае болезнизапросить его сейчас, я получу status 1.
Я знаю, что один из способов сделать это - запустить обновление, вставить и удалить и записать его в разные таблицы, но это не так чисто, и это усложнит разработку.

Надеюсь, вы поняли меня правильно, не так просто объяснить ни для кого не говорящего по-английски ...

Edit-1
У нас мало алгоритмов вприложения, и мы исправляем их и всегда обновляем их, мы должны знать, как база данных была в прошлом, чтобы мы могли работать над алгоритмами, у нас есть запросы / интерфейс, которые могут быть изменены для поддержки этого (я знаю, что это неодин недельный проект, у нас есть ресурсы для этого)

Спасибо

Ответы [ 3 ]

3 голосов
/ 09 сентября 2011

Вариант 1 Включить двоичный журнал .
Это сохранит все обновления, вставки и удаления.
Есть инструменты запроса для binlog.

См:
http://dev.mysql.com/doc/refman/5.0/en/binary-log.html
http://www.mydigitallife.info/how-to-read-mysql-binary-log-files-binlog-with-mysqlbinlog/

Вариант 2 Создать триггер, который сохраняет изменения
Триггер сохраняет данные в базе данных Parallell, которая имеет ту же структуру, что и исходная база данных, за исключением того, что во всех таблицах есть два дополнительных поля. Идентификатор unqiue с именем log_id и отметка времени. Всякий раз, когда поле изменяется, у вас есть триггер войти в журнал.
Вам нужен как минимум триггер after_update и after_delete, и я бы также рекомендовал триггер after_insert. Если вам это нравится, вы можете добавить третье поле к каждой таблице с именем operation, которое является ENUM('insert','delete','update').

DELIMITER $$

CREATE TRIGGER au_table1_each AFTER UPDATE ON table1 FOR EACH ROW
BEGIN
  insert into back_to_the_past.table1_log (`timestamp`,operation,f1,f2,f3.f4) 
    values (now(), 'update', OLD.f1, OLD.f2, OLD.f3, OLD.f4);
END $$

DELIMITER ;

Конечно, если вы создаете дополнительное поле типа отметки времени в table1_log, вам не нужно явно указывать его в now(), БД сделает это.

См .: http://dev.mysql.com/doc/refman/5.0/en/triggers.html

1 голос
/ 09 сентября 2011

На самом деле, «машина времени» для базы данных OLTP часто реализуется с использованием Хранилища данных .

Ваша база данных OLTP (обработка онлайн-транзакций) должна содержать только самые последние данные, чтобы ваши приложения могли работать. Заполнение его историческими данными действительно загрязнит схему, замедлит ее, сделает ее более сложной, и так далее.

Ваш Datawarehouse будет содержать МНОГО данных, но не должен принимать частые записи. Вместо этого вы используете его для создания отчетов, анализа тенденций, прогнозов. Это оптимизированная для чтения система OLAP (Аналитическая обработка в режиме онлайн) .

0 голосов
/ 09 сентября 2011

Если у вас есть ресурсы, как вы говорите, я предлагаю вам купить SAN и поместить файлы данных MySQL на виртуальный диск. Установите инкрементные снимки этого диска с любым желаемым интервалом.

Всякий раз, когда вам нужно просмотреть некоторые исторические данные, вы можете создать новый виртуальный диск на основе одного из этих снимков. Смонтируйте новый диск с другим сервером MySQL и ... поиграйте с ним.

Этот метод не даст вам непрерывную временную шкалу, поэтому, если это необходимо, вы должны игнорировать это предложение ...

...