Народ,

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

Идеальано получать отчету по 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 .
Замените создание резервной копии создание отчета на меняющейся БД получим один в один