|
|
|
Сохранение истории изменений в БД
|
|||
|---|---|---|---|
|
#18+
Всем привет. Дорогие коллеги, очень нужна Ваша помощь! Пишу большой проект, в котором должна быть предусмотрена возможность сохранения истории изменений во всех таблицах и впоследствии откат к этим изменениям. Проект будет высоконагруженный. На сколько я понимаю есть два варианта. 1. Навесить триггеры на таблицу и дублировать каждое изменение отдельной строкой в этой же таблице 2. Используя триггеры, дублировать каждое изменение отдельной строкой в отдельной таблице с такой же структурой в другой схеме. Посоветуйте, какой из вариантов лучше(желательно с аргументацией). Или оба варианта идентичны в плане производительности и скорости выборки изменений? Если предложите вариант получше будет вообще супер. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2018, 16:52 |
|
||
|
Сохранение истории изменений в БД
|
|||
|---|---|---|---|
|
#18+
php coder, повесьте систему триггерной репликации типа лондайста, и подпишитесь дохлым подписчиком (чтобы очередь копилась вечно). получите очереди событий данных, более менее синхронизированные по снепшотам. в реально высоконагруженном проекте это будет прорва данных. с событиями ддл (структуры данных) будут накладки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2018, 17:19 |
|
||
|
Сохранение истории изменений в БД
|
|||
|---|---|---|---|
|
#18+
php coder, для чего нужна история изменения во всех таблицах? только для отката на определенный момент времени? если да и откат нужен на относительно небольшой интервал времени (дни-недели) - то см. архивацию wal'ов и point in time recovery. иначе, прежде чем что-то делать, советую прикинуть объем этих изменений, если проект действительно высоконагруженный и большой. из предложенных вариантов лучше второй вариант, т.к. для приложения он прозрачный и размеры данных и индексов не будут пухнуть при большом числе изменений. из готовых реализаций есть такое: A TARDIS for your ORM - application level time travel in PostgreSQL , тут правда более продвинутый вариант. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2018, 17:34 |
|
||
|
Сохранение истории изменений в БД
|
|||
|---|---|---|---|
|
#18+
php coder, если вам нужен «откат», то это означает уничтожение всех изменений, выполненных после времени, на которое выполняется «откат». вы уверены, что именно это вам нужно? откат делается журналированием запросов. триггеры тут не в кассу вообще, так как любые групповые операции ставят базу раком, а ddl ломают возможность сделать откат. только журнал выполненных запросов на изменение. если вам нужна именно история, чтобы в любой момент времени получить срез данных на любой момент времени (read only, query), это означает по сути либо ведение двух баз данных (физически разные, или отдельная схема, или копия всех таблиц с историческим префиксом в названии), в исторической во все таблицы добавляются метки времени (begin_dt, end_dt). от цели зависит спектр возможных решений, он очень разный. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2018, 02:13 |
|
||
|
Сохранение истории изменений в БД
|
|||
|---|---|---|---|
|
#18+
hVostt, Некоторые для этих целей заводят Kafka. Туда льют raw-данные, а потом раскидывают их в базы данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2018, 05:45 |
|
||
|
|
start [/forum/topic.php?fid=53&tid=1995902]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
37ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
46ms |
get tp. blocked users: |
2ms |
| others: | 295ms |
| total: | 426ms |
| 0 / 0 |
