Народ,

какие есть в принципе концептуальные решения для каше для построения консистентных отчетов.

Идеальано получать отчету по snap-shot'у данных, однако при условии активного изменения данных пользователями (1000+ CU), генерация отчета происходит по изменяющемуся во времени extent'у. Соответственно вне зависимости от скорости работы генератора отчета существует вероятность изменения данных подлежащих включению в отчет, в итоге генерация отчета по состоянию "на сегодня" дает неверный результат при любом раскладе.

Варианты решений которые видятся навскидку
1) Выполнять отчеты в ночное время - не подходит т.к. отчеты могут выполняться дольше ночного времени, к тому же ночью происходят другие регламентные задачи включая full backup. К тому же теоретически ночью пользователи могут работать.

2) Лочить данные на запись и выполнять очередь отчетов - также неприемлем, ввиду длительного подвешивания системы на локе

3) Делать что-то похожее на snap-shot путем организации shadow - тоже малопрактичен, т.к. для каждой операции построения отчета необходимо отключать апдейты с источника на весь период выполнения отчетов. Соответственно частота обновления данных определяется временем требуемым на выполнение всей очереди отчетов. К тому же требует доп. сервера для shadow

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

Вопрос как вы выходите из ситуации в своих системах? Есть ли решения на системном уровне для других СУБД?

На мой взгляд проблема фактически мало зависит от размера БД - она концептуальная.

Если это прояснит выбор решения то, размер БД самого большого хоста порядка 100Гб с тенденцией роста на 20-30Gb+ ежегодно. Количество пользователей 1000+.

ser_shu,
Мысль с бэкапом понятна, и перекликается с п.3 моего поста. Единственное неудобство в этом варианте - медленный бэкап/рестор (полуручной) и нужен постоянный контроль все ли завершено без ошибок. Свежесть данных получится с задержкой на день. Shadow в этом смысле может дать более актуальные данные, правда shadow api еще тот инструмент.

Блок А.Н.,
Вы пишете про п.4 моего поста. Это понятно, что на стадии проектирования можно было бы подумать об историчности данных, однако в проекте вы не всегда можете стоять у истоков архитектуры. Кроме того исторические данные влекут распухание БД, т.к. приходится хранить версии всех апдейтов. Вдобавок этот вариант не панацея, т.к. я написал в своем сообщении что приложения позволяет вводить документы задними числами - т.е. Вы все равно не избегаете неконсистентности отчета.


Основной мой вопрос - а как эта проблема решается в других СУБД? Это же наверняка проработанный шаблон

ПЕНСИОНЕРКА-каждое утро запоминались как-есть таблицей-моментальный снимок таблиц задачи

что значит запоминалось? время требуемое на выполнение snap-shot должно быть близко к нулю чтобы никто не успел изменить данные которые вы включаете в snap-shot. Не думаю что Вам удалось достичь такой беспрецедентной скорости.

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

Блок А.Н.Rus000,
Остается вариант - делать ночью какое-то агрегирование данных для отчетов и отчеты делать это этим данным, а не по живым.
Как защиту от пользователей - лочить систему (если уж они у вас такие упорные).


этот вариант понятен и он изначально озвучен. какие еще принципиально новые подходы есть?


Блок А.Н.Скажите хоть, о каких объемах идет речь?


выше я давал кратко - 100Gb БД, 1000+ пользователей, классов (таблиц) около 50, размер базовых икстентов порядка 1-4 млн, с приростом 0,5-1 млн в квартал.

Блок А.Н.Просто постановка задачи противоречивая - не можем изменить данных, не можем залочить систему (даже на ночь), но хотим видеть мнгновенный срез. Мне кажется, так не бывает :-)

таковы условия


Однако еще раз повторю свой вопрос, который даже не в плоскости кашовой реализации

КАК В ПРИНЦИПЕ СЧИТАТЬ НЕПРОТИВОРЕЧИВЫЕ ОТЧЕТЫ В АБСТРАКТНОЙ СУБД?

ПЕНСИОНЕРКАвы не оговаривали в постановке размеры таблиц

вряд ли вы корректируете прошлогодний снег



хорошо размеры я оговорил. да они в принципе не имеют значения т.к. вы не сделаете снапшот за мгновение. А раз не сделаете, значит вероятность что отчет будет противоречив остается.

ser_shuЕсли у Вас что то происходит с выборкой во время формирования отчета, то это решается фиксацией выборки во временную таблицу. И делайте потом отчет по этой временной таблице, никаких противоречий не будет при любой продолжительности отчета.


помещение во временную таблицу - попытка сделать снапшот со временем существенно отличным от нуля.

За время которое потребуется на копирование во временную таблицу (t) возможно произойдут изменения в данных (в ранее скопированных которые СТАЛИ удовлетворять условию отбора, но не были включены и/или в тех которые были отобраны для копирования и ПЕРЕСТАЛИ удовлетворять условию отбора) и объекты будут учены во временной таблице не на время запуска отчета (t0), и даже не на время окончания генерации отчета (или копирования во временную структуру), а на временные точки лежащие МЕЖДУ t0 и t0+t.
Время t может занимать часы, соответственно, запустив генерацию отчета в 8.00 утра Вы получите результат не по состоянию БД на 8.00 утра, а по плавающему состоянию БД между 8 утра и временем окончания генерации, например 22.00.

В этом и противоречивость.

В то время как если бы мы могли делать снапшоты с временем создания слепка стремящимся к нулю (ну или как вариант путем создания резервной копии, или shadow с отключенным коннектом) мы всегда будем формировать правильный и непротиворечивый отчет по состоянию на время запуска.

DirksDRКАК В ПРИНЦИПЕ СЧИТАТЬ НЕПРОТИВОРЕЧИВЫЕ ОТЧЕТЫ В АБСТРАКТНОЙ СУБД?

СУБД разделяются на "блокировочники"(MSSQL, Cache) и "версионники"(Oracle).
В блокировочниках, чтобы взять непротиворечивый отчет, устанавливается блокировка на изменение данных на время форирования отчета.
правильно я понял что при запуске отчета на блокировочнике СУБД лочит все таблицы включенные в запрос и пока отчет не посчитается? Однако в этом случае пользователи должны висеть и транзакции не должны коммитится, так?
Можете дать линк на документацию того же MSSQL где про это написано.

DirksDRВ версионниках в отчет выбираются версии данных, сохраненные до момента запуска отчета.
эта фича поддерживается на уровне СУБД? Можете детальнее пояснить механизм при условии что отчет сложный и требуется выполнить несколько sql-запросов к БД и между ними сделать аналитические вычисления.
Если sql-запрос один логично что версионник может отдавать версии закоммиченных данных по состоянию на дату запуска запроса. Но КАК версионник контролирует процедуру прикладного отчета в котором разные селекты вызываются в разные времена в пределах процедуры формирования отчета?
DirksDRДля Вашего случая, как вариант, можно предложить "витрину данных" или DataWarehouse, оптимизированную под быстрое выполнение отчетов, а не просто копию базы.
Тогда отчеты будут работать быстрее, и обновлять витрину Вы сможете чаще.
мой случай здесь не причем. У вас в приложении отчеты также неконсистентны если вы не придумали механизма который бы ее обеспечил. Либо условия эксплуатации Вашего приложения позволяют иметь технологические окна в которые вы вставляете обновления витрин. В это случае Вы работаете лишь по ограниченной модели, а я хотел бы понять теоретический механизм и лучшие практики в каше и других СУБД в максимально общем случае, который не подразумевает технологических окон, для пущей важности считайте что система 24x7 - что предложите?

Блок А.Н.Вот навскидку(хотя заочно сложно оценить их применимость):
1. историчность данных (да, я понял, как вы к этому относитесь ;-))


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

Блок А.Н.2. делать снапшот ид таблиц и делать отчеты исходя из него, выкидывать все более поздние ид. Не работает, если правятся уже введенные ранее документы.


именно

Блок А.Н.3. переводить систему в состояние "все изменения ненастоящие, пока делаем отчет", т.е. все изменения вносить в отдельные таблицы или в основные таблицы с особым флагом, а после окончания отчета сливать их с основными данными. Тут плохо то, что работы больше, чем с внедрением историчности.


согласен - реализация слишком сложна

Блок А.Н.4. постоянно держать актуальной статистику, при этом каждое изменение данных меняет статистический отчет. Тут надо очень аккуратно кодить, иначе есть риск, что статистика поплывет, а вы этого не заметите. Плюс еще надо думать как не попасть в блокировки от 1000 одновременно работающих пользователей.


не вариант, иначе статистику придется актуализировать ДЛЯ ВСЕХ полей которые в принципе могут быть включены в какой-нибудь отчет. Это накладные расходы по записи, жесткая регламентация на перечень полей включаемых в отчет. По сути такая статистика никак не отличается от индексов и самое главное не решает вопрос противоречивости, потому как "статистика" будет также меняться в промежутке [t0;t0+t] где t0-время запуска отчета, а t- его длительность


Блок А.Н.5. каждое изменение документа в особую таблицу добавляет "дельту", плюс еще есть стабильная статистика. Позволит обойти взаимоблокировки, кодинга больше чем в (4), но чувствительность к ошибкам немного меньше.

не решает, ибо ограничено периодами докатки дельт на основную "статистику", а именно в это время может быть запущен отчет который пройдется по плавающей "статистике"

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

В случае с shadow с отключаемым коннектом отчет тоже будет не на момент запуска, а на момент отключения коннекта предыдущими запущенными, но незавершенными, отчетами.

С shadow лучше только тем, что все транзакции будут завершены. С копиями завершение транзакций не гарантировано, нужно это обеспечивать дополнительно.

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

DirksDRА вот как работает Оракл...


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

Во вторых, я не понял каким образом обеспечить непротиворечивое чтения для ВСЕГО ОТЧЕТА при условии что данные выбираются более чем одной транзакцией чтения.

Приведен пример где в двух сессия коммитят данные на уровне READ_COMMITED и данные закоммиченные второй сессией попадают в первую.

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

А по этой ссылке можно прочесть что в оракле версии 8 проблема консистентности отчетов все еще была.

Интересно есть ли изменения на системном уровне в более поздних версиях?

Вот описание подхода по созданию снапшотов у железячников.

Пока 3:0 в пользу кашового shadow с возможностью программного отключения дежорналинга по свистку.

Ну и наконец википедия - snapshot .
Замените создание резервной копии создание отчета на меняющейся БД получим один в один

Что-то тема не пользуется популярностью, хотя концептульные недоработки каше налицо - нет ни версионности ни реализации снапшота ни repeatable read, которые есть в большинстве популярных РСУБД :(

/topic/846423&pg=1

а как тогда отчеты-то строим, господа? в расчете на ночные калькуляции?

Блок А.Н.,

чему удивляетесь? разве Вы не согласны что в отсутствии нужного уровня изоляции транзакций формировать консистентные отчеты можно не в 100% случаев и лишь со множеством "если"

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

Блок А.Н.Могу вам сказать, что вашу систему проектировал тот, кто не умеет этого делать, и теперь вы негодуете, что не пришел добрый дядя и не сделал за вас всю работу "на системном уровне".


в отсутствие нормальных аргументов переход на личности порочная практика некоторых авторов в форумах

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

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


а где я упоминаю блокировки?

Блок А.Н.То же касается и транзакций, мало того многие программы с транзакциями мы иногда переписывали на код без транзакций либо с минимальным их количеством.

Видимо Вы не ведаете что творите. Каким образом Вы обеспечиваете атомарность изменений в Вашей системе?

Блок А.Н.Rus000 без системно поддерживаемого СУБД снапшота или повторяемого чтения Вы принципиально в приложении не сможете обеспечить повторяемое чтение. Да нет, вы путаете. Это Вы не можете ;-)


хех, для начала "давайте обсуждать вкус креветок с теми кто их ел" (c)

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

Проще разобраться с ситуацией, когда падающий процесс говорит "пиу", и оставляет все как было.
Значительная часть операций уже сама по себе атомарна, либо атомарность не критична.


это просто перл :)

классический пример: со счета А делаем перевод денег на счет Б. Со счета А сняли, записать на Б не успели и процесс "пиу" (c). Транзакции нет - что делать-то будете?

Для примера, нужно разнести макет на 100000 записей.
[skip]
Транзакции остаются только на самом нижнем уровне, который являятся критичным.

и что показывает этот пример? вернитесь к repeatable read

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


ждем примера, потом продолжим дискуссию про микрооперации

Блок А.Н.Вы опять все путаете. Это у вас проблемы, и вам нужна помощь.
А с подходом, что вам кто-то что-то должен, вы далеко не уедете.

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

Если хотите это опровергнуть прошу привести пример повторяемого чтения на уровне прикладного кода каше, о котором вы публично заявили.

Блок А.Н.Rus000 без системно поддерживаемого СУБД снапшота или повторяемого чтения Вы принципиально в приложении не сможете обеспечить повторяемое чтение. Да нет, вы путаете. Это Вы не можете ;-)


Сказали А говорите Б - ждем, ждем.

Блок А.Н.На слабо пытаетесь взять? Чтобы я пытаясь что-то вам доказать, делал за вас работу?
Нее ... :-)


я не прошу делать за меня работу, а прошу показать ЛЮБОЙ мифический пример который бы показывал свойства повторяемого чтения.
Примера я не вижу здесь, значит делаю вывод что этого сделать нельзя. Ну или точнее вы его сделать не можете, несмотря на бахвальство выше.

Слив засчитан, как говорится. Что и требовалось доказать про концептульные пробелы каше.

Попытайтесь понять, что нет некого мистического "системного уровня". Все зависит от того, куда вас пускает производитель субд и что он за вас делает.
Представьте, что вы разработчик оракла. Вот что бы вы сделали? Вот нужно сделать инсерт, чтобы его не видел другой процесс, вот апдейт нужно делать, но для разных процессов хранить обе копии. Представьте, что нет никаких транзакций. Ну? Это ведь не сложно.


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

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

Если Вы этого не понимаете то это не значит что этой проблемы в СУБД не существует. Я утверждаю что есть нерешенная в каше задача обеспечения transaction level consistency.
Именно поэтому приходится лепить коленочные "конструкторы" которые и отдаленно не могут приблизится по степени проработки системных решений, которые есть в большинстве популярных СУБД, ДАЖЕ в FB, которая не позиционируется как промышленная. И из-за отсутствия таких системных механизмов прикладные разработчики и как следствие заказчики получают непонятно какие отчеты.
Вот в чем печаль, коллега.

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


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

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


это понятно, вопрос не в этом, а в том, что для обеспечения консистентности вам _придется_ использовать длинную транзакцию для обертывания всего отчета, чтобы он посчитался корректно. По крайней мере так делается в оракле, ms sql, sybase и FB.

С учетом того, что в каше нет консистентности на уровне транзакций, делать длинные транзакции не имеет смысла.

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

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