Что было бы хорошим решением для хранения истории изменений объектов?

Question

Необходимо отслеживать изменения, внесенные в объекты в базе данных.

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

Так как мое самое большое требование здесь - иметь минимальное влияние на производительность базы данных и приложения, мое текущее предпочтение - записать изменения в syslog-ng поверх udp и сохранить ихв простых текстовых файлах.

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

Так что я предполагаю, что мой вопрос - есть ли уже система, которая хотя бы частично удовлетворяет моим потребностям?Идеально подходит система доступа к базе данных без доступа к схеме, доступная по протоколу UDP, с возможностью автоматического архивирования данных (или, по крайней мере, минимального объема конфигурации, необходимого для этого) или очень медленное снижение производительности вставки.MongoDB?CouchDB?YourDB

Answer 1

Ну, есть много способов приблизиться к этому. Я наиболее знаком с MongoDB и поэтому склоняюсь в этом направлении. В общем, я думаю, что это удовлетворит ваши потребности в производительности, и использование набора реплик с чтениями, исходящими от подчиненных, скорее всего, будет подходом. Однако управление версиями не встроено. Вы можете увидеть один подход к управлению версиями с помощью Mongoid :: Versioning здесь:

Mongoid :: Управление версиями - как проверить предыдущие версии?

Другие упомянутые вами решения могут иметь лучшую встроенную поддержку, но я не могу об этом говорить. Надеюсь, это, по крайней мере, даст вам несколько советов по поводу MongoDB.

Answer 2

Для простых целей (MySQL!) Просто сделайте триггер AFTER UPDATE для таблиц, для которых вы хотите вести запись.

Например для настольных машин с полями

carId (первичный ключ) цвет производитель модель

создать таблицу 'cars_history' (или равное имя) с полями: carId поле old_value new_value

и добавьте триггер AFTER UPDATE следующим образом:

delimiter //

CREATE TRIGGER trigger_changes
AFTER UPDATE ON cars
FOR EACH ROW
BEGIN
IF OLD.manufacturer <> NEW.manufacturer THEN
  INSERT INTO cars_history
  ( carId, field, old_value, new_value)
  VALUES
  (OLD.carId, 'manufacturer', OLD.manufacturer, NEW.manufacturer);
ELSE IF OLD.color <> NEW.color THEN
  ...
END IF;
END;//
delimiter ;

не проверено, поэтому может содержать синтаксические ошибки :) надеюсь, это поможет в любом случае!

Answer 3

RavenDB имеет эту встроенную функцию (но может быть слишком молодой, как NoSQL db для производственных нужд - конечно, на ваше усмотрение)

http://ravendb.net/docs/server/bundles/versioning

http://www.slideshare.net/jwoglamott/battle-of-nosql-stars-amazons-sdb-vs-mongodb-vs-couchdb-vs-ravendb

Если вы хотите перейти на MongoDB, в этом потоке предлагаются две стратегии реализации

Strategy 1: embed history не будут влиять на производительность записи и будут читать, если вы настроите свой код, чтобы избежать возврата историикогда это не нужно, однако у вас есть ограничение в 16 МБ для одного документа (может быть блокирующим для вас или нет).Strategy 2: write history to separate collection требует (явно) двух операций.Я согласен с тем, что сказано (или их комбинация) - это стратегии, доступные в MongoDB.

CouchDB внутренне использует подход MVCC (и вы можете использовать его, как предложено здесь ),но в SO такой подход обсуждается .По этой теме есть вопрос , и предлагаемое решение аналогично встроенной стратегии, описанной выше для MongoDB (поэтому вы должны выбрать ту, которую предпочитаете).

Answer 4

Взгляните на историю mongoid

Отслеживает историю изменений, например, что, когда, кем и версией. Его также предоставляют опции конфигурации

Answer 5

Интересно, это тип решения, которое вы ищете: http://www.tonymarston.net/php-mysql/auditlog.html

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

Answer 6

А как насчет SQLite? Каждая БД представляет собой автономный файл, который вы можете легко переименовать и переместить при архивировании. Если файл переименован или перемещен автоматически, при следующей вставке создается другой файл.

Единственная проблема в SQLite - это одновременные записи, которые должны блокировать файл для записи. Он может выполнять около 60 транзакций в секунду, но вы можете выполнить тысячи вставок за одну транзакцию (см. doc ).