Здравствуйте, vgrigor, Вы писали:
V>т.е. версионность сделана так чо в ней возникают аналоги блокировок ? V>т.е. весьма неполноценно сделанная версионность?
Откуда такой вывод? Я ничего подобного не писал. Более того, я нигде не писал про "сделана", я писал про "устроена".
Здравствуйте, Alex.Che, Вы писали:
AC>Иван, я написал какие твои утверждения не соответствуют действительности. AC>Настаиваешь на их непогрешимой непоколебимости?
Ты не написал почему, поэтому естественно настаиваю. Насколько мне известно на данный момент не существует ни одной практической реализации версионности без откатов в случае конфликта записи. До недавнего времени небыло даже никаких теоретических работ по этой тематике. Развей мои заблуждения, расскажи, как можно реализовать полноценную версионность без отката, при условии что нам нужен уровень изоляции не ниже RR по классификации ANSI.
Привет, Merle!
Вы пишешь 21 декабря 2005:
AC>> Иван, я написал какие твои утверждения не соответствуют действительности. AC>> Настаиваешь на их непогрешимой непоколебимости?
M> Ты не написал почему, поэтому естественно настаиваю. Насколько мне известно M> на данный момент не существует ни одной практической реализации версионности M> без откатов в случае конфликта записи. До недавнего времени небыло даже никаких M> теоретических работ по этой тематике.
Так и не заглянул?
AC>> Там по ссылкам интересно походить.
M> Во-во, для IB/FB, AFAIK не существенна дяже оговорка про RR, M> он откатывает по честному, вплоть до юзера даже при RC.
Здравствуйте, Alex.Che, Вы писали:
AC>Так и не заглянул?
Если ты утверждаешь, что можно разрешить конфликт версий без отката, то распиши пожалуйста на пальцах алгоритм или дай ссылку на внятное описание оного алгоритма, а то я уже устал от твоей загадочности.. )
Привет, Merle!
Вы пишешь 21 декабря 2005:
AC>> Так и не заглянул?
M> Если ты утверждаешь, что можно разрешить конфликт версий без отката, M> то распиши пожалуйста на пальцах алгоритм или дай ссылку на внятное M> описание оного алгоритма, а то я уже устал от твоей загадочности.. )
Устал от твоей одиозности не меньше
Ты пишешь:
=========Beginning of the citation============== для IB/FB, AFAIK не существенна дяже оговорка про RR,
он откатывает по честному, вплоть до юзера даже при RC.
=========The end of the citation================
Смотрим сюда.
Tr1.Start(read_committed, rec_version, nowait)
Tr2.Start(read_committed, rec_version, nowait)
Tr1.UpdateSomeRecord
Tr2.UpdateSomeRecord ==> Lock conflictk on nowait transaction
Tr1.Commit
Tr2.UpdateSomeRecord
Tr2.Commit
Где откат?
И поясни убогому про "вплоть до юзера"...
ЗЫ: чистого RR у IB нет, есть SnapShot это несколько иной уровень изоляции.
Там картина будет несколько иная, в зависимости от wait/nowait и rec_version/no_rec_version
Товарищ пишет по делу.
Чудес не бывает. Проблемы синхронизации остаются проблемами синхронизации вне зависимости от подхода.
Еще раз повторю — с чего вы взяли, что версионники вообще должны быть лучше блокировочников? По крайней мере заметно лучше и на задачах реального мира, а не на условных тестах?
Здравствуйте, Alex.Che, Вы писали:
AC>Устал от твоей одиозности не меньше
И в чем выражается моя одиозность? В отсутствии слепой веры в версионники?
AC>Смотрим сюда. AC>Tr1.Start(read_committed, rec_version, nowait) AC>Tr2.Start(read_committed, rec_version, nowait) AC>Tr1.UpdateSomeRecord AC>Tr2.UpdateSomeRecord ==> Lock conflictk on nowait transaction
Что в этот момент делает TR2?
AC>Tr1.Commit AC>Tr2.UpdateSomeRecord AC>Tr2.Commit AC>Где откат?
Что — нету? Лень искать, но в этом же форуме мне годя два назад доказывали с пеной у рта, что откат-таки будет. Но дело даже не в этом.
AC>И поясни убогому про "вплоть до юзера"...
Вплоть до юзера это значит что на уровне провайдера происходит exception, который вываливается в клиентский код и нуждается в дополнительной обработке. Тот же Oracle в такой ситуации, производит откат запроса, а затем выполняет запрос повторно, внутри себя, клиент об этой механике даже не догадывается, но тем не менее это полноценный откат.
AC>ЗЫ: чистого RR у IB нет, есть SnapShot это несколько иной уровень изоляции.
Это уже нюансы, Snapshot сильнее RR, а я ставил условие хотя бы RR. И если теоретически при RC на конфликт версий можно просто забить и писать поверх, что делает MSSQL и, в некоторых ситуациях Oracle (насчет IB/FB вопрос все еще туманный), то для того чтобы добиться хотя бы RR без отката уже не обойтись даже теоретически.
P. S.
Я все еще жду описания реализации версионного алгоритма без откатов. Не уходи от темы, пожалуйста.
M>Еще раз повторю — с чего вы взяли, что версионники вообще должны быть лучше блокировочников? По крайней мере заметно лучше и на задачах реального мира, а не на условных тестах?
M>У меня вот нет оснований так думать.
У меня два аргумента — первый здравый смысл
отсутсвие блокировок — должно быть быстрее блокировок,
если накладные расходы по организации копии данных меньше чем отслеживание зависимостей и задержки.
второе — я сам писал код реализующий параллельную обработку с помощью версионности,
копий данных,
и там где были тормозные операции — все получалось несколько лучше.
На практике это можно наблюдать когда вы решаете писать многопоточную систему чтобы интерфейс —
тоже задача — не тормозил,
оптимизируется использование системных ресурсов,
и чем их больше тем задержек на блокировки меньше.
подход тот же,
почему не быть похожим результатам хоть кое-где ?
почему бы Микрософт не сделать это тоже хорошо, так чтобы эффект был виден на некоторых задачах?
а мой взглдя довольно тщательное исследование
и полезное заключение,
но без исследования конкретных случаев,
что я хотел узнать — когда именно лучше в реальном приложении,
пир каких действиях и установках.
автор сказал — "надо иметь такие тесты" — может кто-то видел такое ?
т.е. нашел что на основании "понятий" выводы сложно сделать:
______________________________________
из статьи (- полная цитата) :
Заключение
Новая функциональность, безусловно, окажется очень полезной. Самый заметный эффект – это отсутствие блокировок между читающими и пишущими запросами. То есть читающие запросы не блокируют пишущие, и наоборот. Собственно, вся версионность ради этого и затевалась.
У чистых блокировочников, каковым до недавнего времени являлся и Microsoft SQL Server, при наступлении того печального момента, когда читающие запросы начинают довольно сильно конфликтовать с пишущими, используется стандартный архитектурный прием. Механизм работы с данными делится на две составляющие, OLAP и OLTP. OLTP реализует работу пишущих транзакций на относительно небольшом объеме актуальных данных, а OLAP содержит основные данные, доступные только для чтения, причем в силу того, что каждый механизм оптимизирован исключительно под свои задачи, подобное решение, как правило, оказывается очень эффективным. При этом совершенно необязательно сразу строить большую систему и покупать дополнительное оборудование. Если задача не требует излишней громоздкости, то начинается все обычно с построения промежуточных агрегирующих таблиц и материализованных представлений, в дальнейшем возможен перенос одной из составляющих в отдельную базу, экземпляр сервера и, наконец, если в том возникнет необходимость, на отдельный сервер или даже группу серверов.
Может показаться, что класс задач, для которых реально нужна версионность, достаточно узок. С одной стороны, использование версионности имеет смысл, если в блокировочнике конфликт читающих и пишущих запросов начинает оказывать заметное влияние на производительность. Но с другой стороны, при дальнейшем увеличении нагрузки, производительность версионного механизма довольно быстро начнет снижаться из-за частых обновлений по причине больших накладных расходов на поддержку версионности, она ведь тоже обходится не даром.
Но тут можно вспомнить, что существуют задачи, где необходимо выполнять большое количество малопрогнозируемых запросов (ad-hoc queries). В этом случае конфликты читающих и пишущих запросов выходят на первое место, поскольку в подобной ситуации очень высока вероятность возникновения взаимоблокировок.
Также стоит заметить, что, несмотря на всю полезность агрегатных таблиц, они обладают одним большим недостатком, сильно сужающим область их применения. Если в исходной таблице активность запросов можно физически разнести по разным страницам данных, то в агрегатной таблице большое количество изменений создаст совершенно ненужный ажиотаж в очень маленьком объеме.
Немаловажно также и то, что писать приложения для БД с поддержкой версионности попросту удобнее. Отсутствие необходимости отслеживать возможные конфликты читающих и пишущих запросов здорово облегчает жизнь, особенно не слишком опытным разработчикам, и повышает масштабируемость системы (хотя в этом случае выше вероятность появления некоторых неочевидных эффектов).
И наконец, введенная поддержка версионности позволит легче адаптироваться к новому серверу тем, кто привык работать с подобной функциональностью.
Преимущества версионности.
Читающие запросы не блокируют пишущие, и наоборот.
Уменьшатся вероятность возникновения взаимоблокировок.
Есть возможность выполнять большие согласованные чтения, не предусмотренные структурой базы (ad-hoc queries), без риска сильного падения производительности остальных запросов.
Можно выполнять согласованные агрегатные запросы без повышения уровня изоляции.
Во что обходится версионность.
Пишущие транзакции обязаны создавать копию записи в хранилище версий, даже если на данный момент нет читающих запросов, которым нужна эта запись.
Под хранилища версий, которые расположены в tempdb, необходимо дополнительное место. Причем его может потребоваться довольно много (при наличии длинных версионных транзакций и большом количестве изменений).
Длина каждой записи увеличивается на 14 байт.
Читающие версионные запросы выполняются тем дольше, чем старее транзакция, из-за необходимости спускаться по цепочке ссылок к нужной версии данных. Это также порождает дополнительную нагрузку на процессор и память.
Часть пишущих транзакций при snapshot-уровне изоляции может быть отменена из-за конфликта версий при изменении данных.
В целом реализация версионности от Microsoft выглядит довольно удачно. Существует широкий класс задач, для которых выгоднее использовать чисто блокировочный механизм. Поэтому возможность отключить совершенно не нужную в данном случае версионность довольно полезна.
При включенной поддержке версионности становятся доступны практически все прелести версионных СУБД, а поскольку при записи в большинстве случаев серверу выгоднее вести себя как блокировочнику, то Yukon так и поступает, благо опять-таки есть такая возможность. А если из repeatable read- или даже serializable-транзакции понадобиться забрать согласованные данные, никого не блокируя, то можно использовать версионное чтение.
Вообще, с данной точки зрения, очень полезной была бы функциональность позволяющая включать или выключать поддержку версионности отдельно для каждой таблицы. Но здесь есть ряд концептуальных проблем, например, сложно представить, как будет выглядеть объединение в запросе двух таблиц, одна из которых поддерживает версионность, а другая – нет.
Сам механизм обеспечения версионности в Yukon также обещает быть довольно быстрым и надежным. Используемый алгоритм относительно прост и обеспечивает стопроцентное обнаружение конфликтов при версионных изменениях, без холостых срабатываний. Впрочем, о производительности данного механизма можно будет говорить только после проведения относительно адекватных тестов, а еще лучше — после применения в реальном приложении.
При чем тут здравый смысл, коллега?
Речь идет о проблемах такого уровня сложности, что бытовой здравый смысл уже не работает.
Не существует (насколько мне известно) оснований полагать, что версионный подход должен быть более эффективным. Причем не существует ни в теории, ни на практике. Только частные случаи.
Очень близкие результаты получаются в реальной жизни.
Здравствуйте, vgrigor, Вы писали:
V>что я хотел узнать — когда именно лучше в реальном приложении, V>пир каких действиях и установках.
Когда строится много отчетов по активно изменяющимся данным.
Мы уже победили, просто это еще не так заметно...
