параноидальная база-журнал

Запросы, планы, оптимизация запросов, ...

Модераторы: kdv, CyberMax

Ответить
rilu
Сообщения: 9
Зарегистрирован: 13 фев 2007, 19:15

параноидальная база-журнал

Сообщение rilu » 13 фев 2007, 19:48

Родилась такая задача, надеюсь кто-нить подкинет идею как её красиво решить :)
Есть рабочая база (FB2) довольно скромного размера. правда довольно много логики на триггерах висит, так что забывать о производительности не удаётся.
Есть идея - вести лог изменений базы. причём никаких сравнений не проводиться - по логике выделяется пару десятков записей из 2-4 таблиц, который мона смело сейвить в журнал как некую непротиворечивую сущность :)
И есть параноя - ведение журнала автоматом (в смысле без участия клиентских прог, только за счёт архитектуры базы/консольных утилит или библиотек на сервере) в отдельной базе на произвольном сервере и в рамках текущей транзакции.
Другими словами юзверь типа закончил некий сеанс и грит "коммит, m^я". при этом происходит запись в базу-журнал на удалённом сервере, и обязательном условием успешного коммита является коммита данных в журнале.
fbcopy в основном не подходит из-за описанной паранои с комитами.
вроде всё :) жду идей обсчественности, заранее благодарен :)

WildSery
Заслуженный разработчик
Сообщения: 1738
Зарегистрирован: 05 июн 2006, 16:19

Сообщение WildSery » 13 фев 2007, 20:04

Сперва определись, что такое "лог" в твоём понимании.
Теория и физика.
Потом почитай раздел "Репликация" в документации на этом сайте.
А уж когда возникнут какие-то конкретные вопросы - возвращайся :wink:

rilu
Сообщения: 9
Зарегистрирован: 13 фев 2007, 19:15

Сообщение rilu » 13 фев 2007, 20:30

WildSery писал(а):Сперва определись, что такое "лог" в твоём понимании.
Определился - каждая "запись" лога это документ, отредактированный пользователем, состоящий из ~10-20 записей из ~2-4 различных таблиц рабочей базы
WildSery писал(а):Теория и физика.
знал бы практику не спрашивал бы :)
WildSery писал(а):Потом почитай раздел "Репликация" в документации на этом сайте.
почитал и не только на этом сайте. у меня не распределёнка и мне не нужно синхронизировать базы. В базе-журнале хранятся копии определённых записей рабочей базы, снятые в определённый момент времени. причём хранятся с одной целью - при необходимости просмотреть последовательность изменений этих записей. причём лог должен быть записан ДО комита основной транзакции
WildSery писал(а):А уж когда возникнут какие-то конкретные вопросы - возвращайся :wink:
Обращаюсь - как в рамках текущей транзакции передать набор данных в другую базу данных на произвольном сервере? причём передать средствами сервера (родными или моими) по некоему сигналу с клиентского приложения.
каким образом мне здесь поможет репликация?
вообще по сути гетерогенные запросы всё прекрасно решили бы :)
поэтому нужно как-то их сыммитировать либо придумать какой-либо другой механизм

rilu
Сообщения: 9
Зарегистрирован: 13 фев 2007, 19:15

Сообщение rilu » 13 фев 2007, 20:36

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

WildSery
Заслуженный разработчик
Сообщения: 1738
Зарегистрирован: 05 июн 2006, 16:19

Сообщение WildSery » 13 фев 2007, 20:45

ulir писал(а):как в рамках текущей транзакции передать набор данных в другую базу данных на произвольном сервере? причём передать средствами сервера (родными или моими) по некоему сигналу с клиентского приложения.
Без клиентской части или извращений типа UDF пишущей в другую базу - никак.
Встречный вопрос - зачем журнал должен быть в другой базе?

Merlin
Динозавр IB/FB
Сообщения: 1502
Зарегистрирован: 27 окт 2004, 11:44

Сообщение Merlin » 13 фев 2007, 20:46

ulir писал(а):причём лог должен быть записан ДО комита основной транзакции
Нет, сынок, это фантастика (С). Точнее, он может быть записан до коммита, аж двумя способами. Первый - в таблицу-лог в той же базе, которую после коммита может вычитать заинтересованное приложение и сложить куда угодно. Но только после. Второй - во внешнюю таблицу-файл на том же сервере. Однако, тут ты не узнаешь, завершилась изменявшая транзакция коммитом или изменения потом откатились.
ulir писал(а): Обращаюсь - как в рамках текущей транзакции передать набор данных в другую базу данных на произвольном сервере? причём передать средствами сервера (родными или моими) по некоему сигналу с клиентского приложения.
вообще по сути гетерогенные запросы всё прекрасно решили бы :)
Взаправди? Сдаёццо мне, что ты, отрок, не знаешь значения произносимого тобою заклинания... Вот твоё приложение действительно может это само сделать, для этого тебе надобно ознакомиться с понятием двухфазного коммита (2PC).

Merlin
Динозавр IB/FB
Сообщения: 1502
Зарегистрирован: 27 окт 2004, 11:44

Сообщение Merlin » 13 фев 2007, 20:48

WildSery писал(а):Без извращений типа UDF пишущей в другую базу - никак.
Именно извращений. Те же йацы, что и external table, только в профиль.

rilu
Сообщения: 9
Зарегистрирован: 13 фев 2007, 19:15

Сообщение rilu » 13 фев 2007, 21:24

WildSery писал(а):Без клиентской части или извращений типа UDF пишущей в другую базу - никак.
а чем UDF извращение? не считая необходимости таскать dll и собсно написать иво :)
WildSery писал(а):Встречный вопрос - зачем журнал должен быть в другой базе?
а) дабы как минимум располагаться на другом венике, а лучше на другом компе
б) дабы юзер никаким боком не видел и ничего не мог сделать с этой базой
в) такой лог будет на несколько порядков больше весить, чем рабочая база. а юзеру даны настоятельные рекомендации бэкапится минимум раз в неделю. проект не настолько промышленный, юзеры лишние веники покупать или рейды ставить не будут
г) варианты с логом непосредственно в базе мы уже и так обдумали :) поэтому интересны другие варианты, может они будут лучше
Merlin писал(а):Нет, сынок, это фантастика (С). Точнее, он может быть записан до коммита, аж двумя способами. Первый - в таблицу-лог в той же базе, которую после коммита может вычитать заинтересованное приложение и сложить куда угодно. Но только после. Второй - во внешнюю таблицу-файл на том же сервере. Однако, тут ты не узнаешь, завершилась изменявшая транзакция коммитом или изменения потом откатились.
Для папы ещё раз - лог в той же базе не интересует, случай известный, с ним грешные и сами справимся. плюс не вижу концептуальной разницы между вариантом один и два - тоже самое вид с боку. откатиться изменявшая транзакция может только по системным ошибкам, юзер там ничего уже не контролирует.
Важнее другое: если транзакция прошла, а лог не создан - это очень неприятный глюк. патаму ша вернуть данные фактически невозможно. а если лог записан, а транзакция в последний момент накрылась (хотя бы даже из-за аппаратного глюка) то запись лога завсегда удалить можно
Merlin писал(а):Взаправди? Сдаёццо мне, что ты, отрок, не знаешь значения произносимого тобою заклинания...
сделай милость папаша, объясни что такую мысль принесло в твою светлую голову? али запрос с селектом из одного алиаса и инсертом в другой уже не гетерогенным называется? три таких запроса в процедуре полностью решили бы такую задачу. я не говорю что это было бы хорошее или красиво решение, но это могло бы быть возможным решением...
Merlin писал(а):Вот твоё приложение действительно может это само сделать, для этого тебе надобно ознакомиться с понятием двухфазного коммита (2PC).
двухфазный комит это замечательно, но для этого нужно
а) серверная часть или б) участие клиентское программы
оба варианта не устраивают. потому и вопрос задавал, как без них обойтись можно, только за счёт FB али сопутствующих утилит и т.д. в самом крайнем случае - сервис на сервере с базой.

Merlin
Динозавр IB/FB
Сообщения: 1502
Зарегистрирован: 27 окт 2004, 11:44

Сообщение Merlin » 13 фев 2007, 21:51

ulir писал(а): б) дабы юзер никаким боком не видел и ничего не мог сделать с этой базой
в) такой лог будет на несколько порядков больше весить, чем рабочая база.
Твои юзера в состоянии пипкодавством обогнать бота, получающего эвент на коммите и тут же вычитывающего и зачищающего внутрений лог? Сымаю перед ними шляпу...
ulir писал(а): Для папы ещё раз - лог в той же базе не интересует, случай известный, с ним грешные и сами справимся. плюс не вижу концептуальной разницы между вариантом один и два - тоже самое вид с боку.
Папа понял. Печально два раза. И что намерен бороться с природой, и что не видишь разницы. Хотя, папе в общем-то пофиг, природе не убудет.
ulir писал(а): откатиться изменявшая транзакция может только по системным ошибкам,
Ааа... мосье пишет программы без ошибок и системных у него тоже не случаеццо и сетка не ложиццо периодицки... Ну что ж, кто-то из юзеров пойдёт под расстрел за изменения, в которые его будут тыкать носом в логе, и которых он в базе на самом деле так и не сделал. В конце концов, юзером больше, юзером меньше...
ulir писал(а):
Merlin писал(а):Взаправди? Сдаёццо мне, что ты, отрок, не знаешь значения произносимого тобою заклинания...
сделай милость папаша, объясни что такую мысль принесло в твою светлую голову? али запрос с селектом из одного алиаса и инсертом в другой уже не гетерогенным называется? три таких запроса в процедуре полностью решили бы такую задачу.
Ах, ещё и в процедуууре гетерогенные подавай... Да к базе на другом серваке... свежо, оригинальненько. И главное, очень, очень надёжно с точки зрения работы самого сервера... Ну-с, ждите.

rilu
Сообщения: 9
Зарегистрирован: 13 фев 2007, 19:15

Сообщение rilu » 14 фев 2007, 00:12

Merlin писал(а):Твои юзера в состоянии пипкодавством обогнать бота, получающего эвент на коммите и тут же вычитывающего и зачищающего внутрений лог? Сымаю перед ними шляпу...
а) юзеру могут случайно или намеренно эту базу грохнуть. как файл. вероятность что они грохнут два файла одновременно близка к нулю.
б) не все юзеры вообще о её существовании должны знать
в) идеи с комитом интересны как минимум концептуально. во всяком случае мне. при определённых условиях такой изврат может оказаться далеко не лишним
Merlin писал(а):Папа понял. Печально два раза. И что намерен бороться с природой, и что не видишь разницы. Хотя, папе в общем-то пофиг, природе не убудет.
а) разницы не вижу в разрезе предложенной проблемы
б) с природой никогда не соревновался и не собираюсь, потому и вопрос задал, думал может кто предложит природное решение
Merlin писал(а):Ааа... мосье пишет программы без ошибок и системных у него тоже не случаеццо и сетка не ложиццо периодицки... Ну что ж, кто-то из юзеров пойдёт под расстрел за изменения, в которые его будут тыкать носом в логе, и которых он в базе на самом деле так и не сделал. В конце концов, юзером больше, юзером меньше...
а) есть, случаеццо, ложиццо. и что? это как-то приблизило к ответу?
б) так вот о решении, которое обеспечит надёжность и целостность данных я и спрашиваю. как гарантировать запись в лог и как эту запись вообще провести.
Merlin писал(а):Ах, ещё и в процедуууре гетерогенные подавай... Да к базе на другом серваке... свежо, оригинальненько. И главное, очень, очень надёжно с точки зрения работы самого сервера... Ну-с, ждите.
я говорил что это возможное или хорошее решение???
Merlin, не искушай флудом, может о деле что-нить скажешь? например, о udf варианте. был бы рад услышать в чём извращённость.

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 14 фев 2007, 00:29

Merlin, не искушай флудом, может о деле что-нить скажешь?
это ты кончай флудить. разберись сначала с транзакциями и евентами, и как они работают. А потом будешь думать.

Насчет udf я могу сказать.

1. коннект к другой БД из udf это изврат, ненадежно, и не гарантируется. Особенно если сбойнет соединение. в UDF обычно пишется обработка входных параметров, и передача результата на выход. A+B, Pos(A, B), и так далее. Никаких действий, которые могут вызвать паузу в работе udf, в ней выполнять нельзя.

2. вызов udf также не подвержен транзакционности. после вызова нелья узнать, чем была транзакция завершена, и вообще была ли завершена.

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

Ivan_Pisarevsky
Заслуженный разработчик
Сообщения: 644
Зарегистрирован: 15 фев 2005, 11:34

Сообщение Ivan_Pisarevsky » 14 фев 2007, 12:56

ulir писал(а):а) юзеру могут случайно или намеренно эту базу грохнуть. как файл. вероятность что они грохнут два файла одновременно близка к нулю.
б) не все юзеры вообще о её существовании должны знать
а) АГА ЩАЗЗЗ. Файл БД как файл по сети и не должен быть доступен, если админ разрешил доступ к файлу по СМБ/ФТП или еще как так он сам себе злобный буратина.
б) юзер вообще не должен знать где лежит база, даже если он и знает что БД физически лежит на пятом сверху сервере в стойке, то в серверной ему одн фиг делать нечего, и это сокровенное знание ему ничего не даст. Про доступ по сети см. пункт а.

Уважаемый юный друг настоятельно рекомендую продумать процедуру бэкапа данных с сервера, особенно его административную часть, например холодные копии должны храниться на удаленной относительно сервера площадке в несгораемом шкафу, под замком и т.п. А логические изменения БД писать программу в саму БД, триггерами, например. И не стоит сюда тянуть за уши двухфазный коммит, он тут решительно ни к чему.

rilu
Сообщения: 9
Зарегистрирован: 13 фев 2007, 19:15

Сообщение rilu » 14 фев 2007, 16:12

в общем идея вышла абсурдная и велосипедная.
через клиента будет на порядок проще/веселее.
кстати с сеткой у клиента полуанархичное состояние,
а админить её за спасибо тоже желания нет.
думаю топик исчерпан. спасибо всем кто ответил.

Ответить