И ОПЯТЬ ТРАНЗАКЦИИ (в компонентах FibPlus)!

IBX, FIBPlus, UIB, ADO, .Net и прочее-прочее-прочее, в общем все, что относится к созданию приложений, работающих с InterBase, Firebird и Yaffil - клиент-серверных, трехзвенных, консольных и т.п.

Модератор: kdv

CyberMax
Заслуженный разработчик
Сообщения: 638
Зарегистрирован: 31 янв 2006, 09:05

Сообщение CyberMax » 26 июл 2006, 13:47

Merlin писал(а):Малость излишне категорично. Отчёты разные бывают. Не все же по горячим данным. И для аналитики редко нужна миллиметровая точность. А снапшот таки мусор держит, а отчёты затяжные случаюццо... Такшта всё по месту.
"Мир InterBase, 4-е издание". Цитата:
"Для запросов, которые применяются для построения отчетов, однозначно нужно использовать транзакцию с режимом доступа "только для чтения" и с уровнем изоляции concurrency. Такая тразакция будет возвращать строго те данные, что существовали на момент ее запуска, - это важная особенность для отчетов, которые строятся за несколько проходов по базе данных". Конец цитаты.

Извините, вы под каждый вид отчета свои настройки транзакции устанавливаете? Здесь отчет с ReadOnly-транзакцией, здесь со snapshot'ной? И при чем тут мусор, если надо корректно отчет сформировать? :shock:.

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

Сообщение Merlin » 26 июл 2006, 14:33

CyberMax писал(а): "Мир InterBase, 4-е издание". Цитата:
"Для запросов, которые применяются для построения отчетов, однозначно нужно использовать транзакцию с режимом доступа "только для чтения" и с уровнем изоляции concurrency.
А мало ли я глупостей-то говорю (C) :D А серьёзно - смысл вот в этом контексте:
CyberMax писал(а): Такая тразакция будет возвращать строго те данные, что существовали на момент ее запуска, - это важная особенность для отчетов, которые строятся за несколько проходов по базе данных". Конец цитаты.
Вот когда этот контекст важен, тогда, безусловно, нужен снапшот. И не только из-за нескольких проходов, и одним длинным запросом по большой таблице в r_c можно получить неконсистные данные на фоне интенсивных модификаций. А вот если отчёт строится, скажем, по промежуточным хранимым агрегатам, собираемым ночным ботом - нафиг он упал? Набор-то условно-статический. Или OLAP-вертушка для оценки тенденций за год, пусть даже по горячим данным - ей пофиг что к паре миллионов записей за время построения добавится ещё пара десятков, на тренд это не повлияет.
CyberMax писал(а): Извините,
Нет! Я на это пойтить не могу! (С) :D
CyberMax писал(а): вы под каждый вид отчета свои настройки транзакции устанавливаете? Здесь отчет с ReadOnly-транзакцией, здесь со snapshot'ной?
Исесьно. У меня аналитиков вдвое больше чем регистраторов, кажный поручик лезет в Бонапарты (С). Так что, мне мусор плодить, рабочую часть TIP раздувать и мешать OLTP? Там, где по условиям задачи это не обязательно?
CyberMax писал(а): И при чем тут мусор, если надо корректно отчет сформировать? :shock:.
Вопрос в определении понятия "корректно". Не в абсолюте, а с учётом функционала применения оного отчёта и характера данных. Где нужен снапшот, там он нужен, бесплатных пряников не бывает. А где нет - фигли палить из пушки по воробьям?

CyberMax
Заслуженный разработчик
Сообщения: 638
Зарегистрирован: 31 янв 2006, 09:05

Сообщение CyberMax » 26 июл 2006, 15:25

2 Merlin.
Собственно, доводы понятны и приняты. Но то, что вы описали - это редкая ситуация. Имхо, в подавляющем большинстве случаев не стоит так извращаться. Во-первых, не настолько страшен мусор, как его малюют. Если отчет будет делаться час, сколько новых версий записей появится за это время? Во-вторых, дело в корректности самой идеи исполнять запросы/хп/представления отчетов в несоответствующем окружении, в данном случае RO-транзакции. Для чего и привел цитату из "Мира IB".

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

Сообщение WildSery » 26 июл 2006, 17:17

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

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

Сообщение kdv » 27 июл 2006, 15:35

дело в корректности самой идеи исполнять запросы/хп/представления отчетов в несоответствующем окружении, в данном случае RO-транзакции.
в Мир IB в этом плане написана фигня. Котому как спутаны RO read_committed и snapshot. Для snapshot что RW, что RO - никакой разницы, кроме той что транзакция теряет возможность менять данные. А вот для read_committed - разница большая.

Собственно, про отчеты, и "несоответствующем окружении". Выполнять отчеты в read_committed - это идея, прямо скажем, странная. За исключением варианта, когда отчет выполняется в единственной существующей на данный момент в БД транзакции. Ну или когда это snapshot table reserving (и тогда при чем тут RO...).

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

Сообщение Merlin » 27 июл 2006, 15:59

Дим, а давай дадим определение "отчёту" :)

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

Сообщение kdv » 27 июл 2006, 17:54

давай дадим определение "отчёту"
"процедура, запрос или несколько запросов, выполняющиеся длительное время (более 1-й минуты), и считывающее данные, изменяемые в данный момент другими пользователями".

в общем, что-то вроде "двуногого без перьев". :)

для меня "отчет" это нечто вроде подсчета баланса, когда read_committed неприменимо. Собственно, параметры транзакции определяют ее УРОВЕНЬ ИЗОЛИРОВАННОСТИ, который и выбирает разработчик для конкретной ситуации. Если все бизнес-процессы в БД являются последовательными, то эти действия можно хоть в dirty-read выполнять.

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

Сообщение Merlin » 27 июл 2006, 18:25

kdv писал(а):
давай дадим определение "отчёту"
"процедура, запрос или несколько запросов, выполняющиеся длительное время (более 1-й минуты), и считывающее данные, изменяемые в данный момент другими пользователями".
А как будем назввать то же самое, но не только без перьев, но и без перламутровых пуговиц? Примеры когда или не менются другими пользователями или погрешность пренебрежимо мала я приводил.
kdv писал(а): для меня "отчет" это нечто вроде подсчета баланса, когда read_committed неприменимо.
Панимаш какая штука. Баланс как отчёт считают обычно на уже закрытом периоде. Бывает что пользуют как инструмент в текущей работе, но редко. Чаще оборотные ведомости по какому-нибудь счёту, отчёт о прибылях и убытках, о движении денежных средств...

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

Сообщение kdv » 27 июл 2006, 18:38

Чаще оборотные ведомости по какому-нибудь счёту
тогда "отчет" как термин в данном случае идет лесом.

CyberMax
Заслуженный разработчик
Сообщения: 638
Зарегистрирован: 31 янв 2006, 09:05

Сообщение CyberMax » 28 июл 2006, 10:32

Merlin писал(а):Баланс как отчёт считают обычно на уже закрытом периоде.
Это получается логический снапшот :). Когда путем установки какого-то признака (например, поля CLOSED), добиваются неизменности данных, с которыми работает отчет. Ведь вероятность, что кто-то откроет период и начнет изменять данные во время выполнения запросов, настолько мала, что ей можно пренебречь.

SAMZ
Сообщения: 128
Зарегистрирован: 21 мар 2005, 08:17

Сообщение SAMZ » 28 июл 2006, 11:08

CyberMax писал(а):2 Merlin.
Собственно, доводы понятны и приняты. Но то, что вы описали - это редкая ситуация. Имхо, в подавляющем большинстве случаев не стоит так извращаться. Во-первых, не настолько страшен мусор, как его малюют. Если отчет будет делаться час, сколько новых версий записей появится за это время? Во-вторых, дело в корректности самой идеи исполнять запросы/хп/представления отчетов в несоответствующем окружении, в данном случае RO-транзакции. Для чего и привел цитату из "Мира IB".
Коллеги, можно, конечно, спорить о том, что использовать при формировании отчетов "снапшорт" или "read_committed", но думаю, копья ломаете, каждый разработчик сам должен решить в зависимости от того, какой это отчет, что использовать. Но вопрос вот какой, CyberMax, все про мусор какой-то говорит, мусор то здесь при чем. Или здесь имеются ввиду измененные данные по транзакциям, завешенные позже старта транзакции, в контесте которой формируется отчет, но это строго говоря не мусор.

CyberMax
Заслуженный разработчик
Сообщения: 638
Зарегистрирован: 31 янв 2006, 09:05

Сообщение CyberMax » 28 июл 2006, 11:35

SAMZ писал(а):Но вопрос вот какой, CyberMax, все про мусор какой-то говорит, мусор то здесь при чем.
2 SAMZ. Что ты меня-то зацепил? Прочитай всю тему внимательно. Я отвечал на пост Мерлина:
Merlin писал(а):А снапшот таки мусор держит, а отчёты затяжные случаюццо... Такшта всё по месту.
Я то как раз по поводу мусора не переживаю.

SAMZ
Сообщения: 128
Зарегистрирован: 21 мар 2005, 08:17

Сообщение SAMZ » 28 июл 2006, 11:54

CyberMax писал(а):
SAMZ писал(а):Но вопрос вот какой, CyberMax, все про мусор какой-то говорит, мусор то здесь при чем.
2 SAMZ. Что ты меня-то зацепил? Прочитай всю тему внимательно. Я отвечал на пост Мерлина:
Merlin писал(а):А снапшот таки мусор держит, а отчёты затяжные случаюццо... Такшта всё по месту.
Я то как раз по поводу мусора не переживаю.
Ну, понял, понял!
Но вообще - то ситуация, когда можно сказать и ты прав и Мерлин прав. Есть туча случаев, когда формируеши запросы - отчеты, необходимые для задач оперативного управления и, когда снапшотная точность никого не колышет. Ну и есть отчеты, в которых все "надо вешать в граммах". Тут каждый пьет в одиночку.

CyberMax
Заслуженный разработчик
Сообщения: 638
Зарегистрирован: 31 янв 2006, 09:05

Сообщение CyberMax » 28 июл 2006, 12:02

2 SAMZ. Угу.
Предлагаю на этом тему отчетов считать закрытой.

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

Сообщение Merlin » 28 июл 2006, 13:24

SAMZ писал(а): здесь имеются ввиду измененные данные по транзакциям, завешенные позже старта транзакции, в контесте которой формируется отчет, но это строго говоря не мусор.
Эт я главный мусорщик :) Вопрос философический. Снапшот удерживает версии с момента своего старта по всей базе, независимо от того, касаются они тех запросов, которые в нём выполняются или нет. Мусор это или не мусор? :) Не будь этого снапшота - однозначно был бы мусором и прибирался помалеху. А так копится. Посему хорошим тоном является делать снапшоты по возможности короткими. По возможности. Потому что если надо, значит надо. И иметь это "надо" ли в виду при построении тяжёлого функционала. Я просто часто реагирую на избыточную категоричность. Не имея в виду ничего личного к автору того или иного высказывания, всё в заботе о читателях-чайниках :-D Народ же простой - читают что кто-то где-то сказал и возводят в ранг абсолютной истины. Альтруист я. Правда со звериным оскалом, как kdv про меня говорит :-D

Ответить