Уровни изоляции в Юконе

[zVlad]

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

........

Представьте например ситуацию когда на складе идет приемка новых партии различных единиц хранения и выдача их же. Учет бумажный. Поступает запрос: "А столько у нас на данный момент изделий "Ю" имеется на складе?"

Это как раз OLPT проблема. И как Вам здесь поможет OLAP?

Много лет назад, в другой сфере, обсуждался вопрос: что есть диалоговый запрос, а что есть пакетное задание - до сих пор нет однозначного решения. Так же и с OLTP/OLAP. Когда я вижу "online" транзакцию перелопачивающую многомиллионную таблицу (соединение многомиллионнострочных таблиц!) в то время как Service Level Agreement (SLA) требует sub-second responce time, я вспоминаю ту диллему и думаю есть вещи которым нет однозначного определения. Так и с OLTP/OLAP дела обстоят. И, естественно, мне (и любому другому) OLAP никак помочь не может, ни здесь ни где-либо еще поскольку это лишь набор слов, отражающий возмущение против ресурсоемких запросов к базе данных. Правильной (на мой взгляд) реакцией девелоперов СУБД являются: триггеры и их более понятное для прикладных программеров воплощение - материализованные "примочки". Ну не понимаю я SnapShot Isolation Level!

[tengiz]

Tengiz! Положа руку на сердце скажите: есть нынче, на уровне SQL 2000 неразрешимые проблемы конкурентного доступа? Не надуманные - настоящие, неразрешимые. Я имею в виду, которых нельзя было бы разрешить правильным прикладным решением - не на уровне СУБД?...

Согласен, будет круче, не надо будет вкладываться в образование прикладных программеров, СУБД будет толлерантна ко многим глубостям. Наверное это может согреть сердце девелопера СУБД, но.... как-то противится этому душа DBA-я, работающего "в поле"

Для опытного разработчика приложений неразрешимых проблем нет .

Если серьёзно - а Вы разве забыли, что своей популярностью реляционные СУБД и SQL обязаны тем, что системы предыдущих поколений были значительно менее удобны для прикладных программистов? Почему Вы полагаете, что движение в сторону удобства и логичной простоты без ущерба для функциональности и производительности должно почему-то прекратиться?

Даже если проблема оптимальной изоляции транзакций снимется с повестки дня для самого широкого спректра приложений (давайте помечтаем - например, СУБД будут иметь только два надёжных и качественных режима работы каким-то ещё чудом обеспечивающих максимальную параллельность - serializable и readonly), не переживайте - без интересной и уважаемой работы не окажетесь: для DBA и опытных разработчиков приложений баз данных всё равно остаётся огромная область приложения ума и сил помимо шаманства вокруг изоляции транзакций - оптимально построенные модели данных, аккуратно спроектированные и написанные запросы, тонкая настройка производительности приложений, оптимальное индексирование и пр.

[tengiz]

Поступает запрос: "А столько у нас на данный момент изделий "Ю" имеется на складе?"

Это как раз OLPT проблема. И как Вам здесь поможет OLAP?

Много лет назад, в другой сфере, обсуждался вопрос: что есть диалоговый запрос, а что есть пакетное задание - до сих пор нет однозначного решения. Так же и с OLTP/OLAP.

Ну для меня водораздел между оперативной обработкой транзакций и всем остальным проходит довольно чётко - если данные используются для принятия оперативного решения, причём под решением имеется в виду в том числе и изменение других оперативных данных, и если ошибка при принятии решения должна быть поймана немедленно - то это оперативная обработка. В вашем примере - если ответ на вопрос об изделии Ю нужен для организации немедленной погрузки в вагон, который стоит у ворот, причём если попросили 50 ящиков этого изделия, то в вагон гарантированно должны попасть 50 поэтому никто больше эти 50 ящиков тронуть не должен, то это OLTP. Объёмы обрабатываемой информации - признак вторичный, хотя, как правило, в виду требования "оперативности" объёмы изо всех сил стараются не раздувать.

Правильной (на мой взгляд) реакцией девелоперов СУБД являются: триггеры и их более понятное для прикладных программеров воплощение - материализованные "примочки". Ну не понимаю я SnapShot Isolation Level!

Вы удивитесь как много интересного позволяет сделать snapshot isolation для того, чтобы "триггеры и материализовнные примочки" работали ещё лучше и ещё более оперативно. Дайте срок - обязательно убедитесь.

[Merle]

Хм.. У меня взгляд на версионность примерно таков, поправьте меня, если я ошибаюсь.
Реально именно выигрыш в производительности будет получаться для достаточно узкого круга задач, когда блокировочнику уже начинают при массовых чтениях мешаться пишущие запросы, но этих пишущих запросов еще не на столько много, чтобы начало сказываться замедление от необходимости сохранять устаревшие версии и поиска по этим версиям нужной.
К тому же OLAP/OLTP - это достаточно грубое деление. Обычно нет необходимости выносить OLAP в отдельный экземпляр или сервер, если есть такая необходимость, то никакая версионность не спасет. Как правило все начинается с промежуточных агрегатных табличек, индексированых въюшек, в крайнем случае отдельной базы. Более того, подобное разделение - это практически стандартный паттерн для проектировщика БД, который в конечном итоге дает гораздо больший эффект на выходе нежели версионность, так как тут две отдельных сущности заточенные имено под свои задачи.
Но все же версионность штука очень полезная. От какой же головной боли она может избавить!
Вообще идеальным мне видится вариант, при котором поддержка версий может выставляться не на уровне базы, а на уровне отдельной таблицы.

[Dmitry67]

Эта проблема решается элементарно репликацией (warehouse, data mart and so on). А также адекватным пониманием того что есть OLAP и что есть OLTP. Я имею в виду когда говорят что мол нужен отчет по всей базе и именно на любой текущий момент времени - то это есть не понимание сути OLAP. Проблема устраняется путем непродолжительной душевной беседы с тем кто этого просит.

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

2. Дело не в том что хотят отчет в любой момент времени. Если хотят OLAP отчет на 11/11/2003 12:34:45, то это непонимание сути OLAP
Но как правило момент то говорится не потому что секунды важны
А важен просто CONSISTENT отчет. А вот без версионности это ох как сложно !

2 tengiz
Меня порадовали новые возможности Yukon. Я правда пока повозился пару часов а потом у меня упала VMWare
В понедельник переставлю
Пока вот какой минус. Конечно работал я мало... но... c интерфейсом надо чтото делать
То что раньше занимало один клик, теперь целаю проблема. Похоже программисты соревновались у кого больше на экране глюкалок и прогресс баром больше будет, а об эргономике не думали вообще
Это мое частное и предварительное мнение

[tengiz]

Пока вот какой минус. Конечно работал я мало... но... c интерфейсом надо чтото делать То что раньше занимало один клик, теперь целаю проблема.

Спасибо за Ваше частное мнение

Об интерфейсе чего идёт речь? Единственный интерфейс, с которым я сталкиваюсь - это setup, SQL Workbench, и BOL - я больше ничего никогда не включал ввиду сцепифики ядра сервера. Что касается setup - то по-моему там всё достаточно просто. SQL Workbench сначала бесит почти всех (дайте взад наш QA!), но потом, после того, как немного освоишься (через неделю-другую), обратно на QA уже не перетащишь. Тоже почти всех.

[tengiz]

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

Самые эффективные агрегатные таблицы имеют очень неприятное свойство создания дополнительных hotspots - например, если даже если в исходных таблицах большинство оперативных транзакций легко "разводятся" благодаря тому, что в основом трогают разные данные, при агрегации те же самые транзакции начинают сталкиваться лбами на значительно более узком пространстве, в результате серьёзно замедляя работу. В итоге почти полностью дискредитируя главную идею материализованных представлений. А вот версионность в сочетании с кое-какими другими, пока ещё экзотическими техниками, позволяет использовать значительно более тонкие алгоритмы оперативного создания и поддержки материализованных агрегатов.

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

Возможность включать и выключать поддержку версионности на уровне отдельной таблицы к сожалению не попала в Yukon - по причинам не связанным с ресурсами или временем на разработку/внедрение. Тенхически это элементарно. Но по сути добавляет проблем концептуального характера - например, как делать join таблицы с версиями с таблицами без поддержки весрионности? Очевидно, что о согласованных результатах в таком случае не может идти и речи. Поэтому эта фича ещё требует тщательного продумывания.

[Merle]

Тенхически это элементарно. Но по сути добавляет проблем концептуального характера - например, как делать join таблицы с версиями с таблицами без поддержки весрионности? Очевидно, что о согласованных результатах в таком случае не может идти и речи. Поэтому эта фича ещё требует тщательного продумывания.

А как сейчас происходит в Юконе join таблиц из разных баз одна из которых с поддержкой версионности, а другая без?

Что касается WorkBench, то я наоборот, сначала был от него в диком восторге, и пытался даже с 2000 в нем работать =), но потом перешел обратно в QA, уж очень WB медленный... Иногда просто встревает и долго-долго над чем-то думает... Впрочем я склонен списывать все это на его раньюю беттовость, там похоже половина функций not yet implemented..

Да, в BOL есть некая неточность, в том месте, где описывается snapshot уровень изоляции, глава "Understanding Snapshot Isolation". В примере отсутствует команда commit для snapshot трананзакции, из-за этого не ясно когда она завершается, и сам пример похоже не для snapshot транзакции, а для версионного read committed.
Страничка кажется вот эта:ms-help://MS.SQLSVR9/accdb9/htm/acd_locks_4ule.htm

[tengiz]

А как сейчас происходит в Юконе join таблиц из разных баз одна из которых с поддержкой версионности, а другая без?

Догадайтесь . Распределённые запросы (куда входят запросы, затрагивающие разные базы на одном сервере) вообще тема особая. Например, так как распределённая декларативная ссылочная целостность не поддерживается сервером, то некоторые оптимизации, которые процессор запросов мог бы применить, исходя из наличия связей между таблицами, для распределённых запросов не проходят. Поэтому и случай разных баз даже без версионности уже сам по себе особый из-за распределённости.

Да, в BOL есть некая неточность...

Спасибо - я перешлю Вашу находку в группу документации.

[Merle]

Догадайтесь .

Лучшая догадка - экспериментально подтвержденная...

Если я Вам еще не надоел , то вот очередная порция вопросов..
1. Маркируется ли как нибудь последняя запись в цепочке версий в tempdb или в этом нет необходимости? И как вообще происходит очистка устаревших версий? Это какой-то процесс который запускается по расписанию? И учитывается ли при этом как-нибудь нагрузка?
2. Как именно происходит копирование старых версий из базы в tempdb? Может ли возникнуть ситуация при которой пишущая транзакция уже захватила запись на изменение, но зафиксированной копии в tempdb еще не появилось? Как я понял из документации обязанность класть копию записи в tempdb возлагается на изменяющую транзакцию?
3. Проводились ли какие-нибудь хитрые оптимизации над tempdb, возможно даже другая структура? И не вступают ли в конфликт методы оптимизации для версионности и методы оптимизации необходимые для работы с временными таблицами? Не станет ли работа с временными таблицами из-за этого более тяжелой?

[zVlad]

Tengiz! Положа руку на сердце скажите: есть нынче, на уровне SQL 2000 неразрешимые проблемы конкурентного доступа?..........

Согласен, будет круче, не надо будет вкладываться в образование прикладных программеров, СУБД будет толлерантна ко многим глубостям. Наверное это может согреть сердце девелопера СУБД, но.... как-то противится этому душа DBA-я, работающего "в поле"

Для опытного разработчика приложений неразрешимых проблем нет .

Если серьёзно - а Вы разве забыли, что своей популярностью реляционные СУБД и SQL обязаны тем, что системы предыдущих поколений были значительно менее удобны для прикладных программистов? Почему Вы полагаете, что движение в сторону удобства и логичной простоты без ущерба для функциональности и производительности должно почему-то прекратиться?

Даже если проблема оптимальной изоляции транзакций снимется с повестки дня для самого широкого спректра приложений (давайте помечтаем - например, СУБД будут иметь только два надёжных и качественных режима работы каким-то ещё чудом обеспечивающих максимальную параллельность - serializable и readonly), не переживайте - без интересной и уважаемой работы не окажетесь: для DBA и опытных разработчиков приложений баз данных всё равно остаётся огромная область приложения ума и сил помимо шаманства вокруг изоляции транзакций - оптимально построенные модели данных, аккуратно спроектированные и написанные запросы, тонкая настройка производительности приложений, оптимальное индексирование и пр.

По порядку:
1. "....Если серьёзно - а Вы разве забыли, что своей популярностью реляционные СУБД и SQL обязаны тем, что системы предыдущих поколений были значительно менее удобны для прикладных программистов?"
Нет не забыл. Потому что уже давно (скорее никогда) в эту сказку не верю. А Вы ни разу не видели мук программистов переходящих скажем с "удобств" IDMS на "удобства" RDBMS?
Есть два-три поинта почему RDBMS завоевали рынок, например, производительность труда программера - т.е. сколько с него можно выдоить за единицу времени, или модифицируемость приложения. Но никак не "удобства".

В рамках же обсуждаемой темы я вижу один лишь поинт зачем Microsoft это (snapshot) понадобилось - чтобы упростить перевод приложений с Оракл на SQL Server. Разве не так?

2. "...давайте помечтаем - например, СУБД будут иметь только два надёжных и качественных режима работы каким-то ещё чудом обеспечивающих максимальную параллельность - serializable и readonly".

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

[Dmitry67]

Пока вот какой минус. Конечно работал я мало... но... c интерфейсом надо чтото делать То что раньше занимало один клик, теперь целаю проблема.

Спасибо за Ваше частное мнение

Об интерфейсе чего идёт речь? Единственный интерфейс, с которым я сталкиваюсь - это setup, SQL Workbench, и BOL - я больше ничего никогда не включал ввиду сцепифики ядра сервера. Что касается setup - то по-моему там всё достаточно просто. SQL Workbench сначала бесит почти всех (дайте взад наш QA!), но потом, после того, как немного освоишься (через неделю-другую), обратно на QA уже не перетащишь. Тоже почти всех.

Я имел ввиду Workbench.
Пытаешься удалить таблицу. Было как ? Клик, delete, OK, все
Теперь - окно с глюкалками запускается, этапы процесса удаления показывает... Правда более одной таблицы за раз не выбрать и после удаления список таблиц не рефрешится...
Квери незаконнекченные которые при попытке запуска просят себя законеектить... Все это замечательно, но как только законнектился - она начинает выполняться по master...
Вот пока что всбесило

[Dmitry67]

В рамках же обсуждаемой темы я вижу один лишь поинт зачем Microsoft это (snapshot) понадобилось - чтобы упростить перевод приложений с Оракл на SQL Server. Разве не так?

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

Я так понимаю, проблема в том, что из "большой тройки" только у DB2 теперь нет версионности и стоит задача доказать, что версионность никому не нужна ?

Как зелен виноград! - лиса здохнула, не в силах дотянуться до плодов. (c)

[zVlad]

В рамках же обсуждаемой темы я вижу один лишь поинт зачем Microsoft это (snapshot) понадобилось - чтобы упростить перевод приложений с Оракл на SQL Server. Разве не так?

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

Я так понимаю, проблема в том, что из "большой тройки" только у DB2 теперь нет версионности и стоит задача доказать, что версионность никому не нужна ?

Как зелен виноград! - лиса здохнула, не в силах дотянуться до плодов. (c)

1. Наверняка в ИБМ велось и ведется изучение версионности. Возможно существование исследовательского версионного варианта ИБМ RDBMS.

2. Не исключаю, хотя и не понимаю зачем бы это было нужно (разве для облегчения перевода приложений с Оракл на DB2) что в очередной версии DB2 версионность появится.

3. Что касается нужности или не нужности версионности. Попробуйте провести опрос среди прикладных программеров. Вы узнаете что 80-90% даже не в курсе существования уровней как таковых. Так что доказывать или опровергать нужность или ненужность того о существовании чего большинство участников процесса даже не подозревают - совершенно бессмысленное занятие.
Кстати, интересен вопрос: как можно ощутить, измерить (потрогать) наличие (или отсутствие) версионности, если приложение написано исходя из принципов блокировочника? Не даст ли в этом случае версионность негативного эффекта?

[tengiz]

Merle,

Я не могу ответить на все Ваши вопросы - я не уверен, что всё, что Вы спрашиваете планируется сделать доступным публике. Вот ответы на часть из них:

как вообще происходит очистка устаревших версий? Это какой-то процесс который запускается по расписанию?

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

Как именно происходит копирование старых версий из базы в tempdb? Может ли возникнуть ситуация при которой пишущая транзакция уже захватила запись на изменение, но зафиксированной копии в tempdb еще не появилось? Как я понял из документации обязанность класть копию записи в tempdb возлагается на изменяющую транзакцию?

Копирование старой версии строки происходит в момент изменения строки. Наложение X блокировки ещё ничего не создаёт. Если в этот момент (после наложения блокировки но до фактического изменения) другой транзакции на версионном уровне изоляции понадобилось прочитать это строку, то строка будет прочитана безотносительно к блокировке.

не вступают ли в конфликт методы оптимизации для версионности и методы оптимизации необходимые для работы с временными таблицами? Не станет ли работа с временными таблицами из-за этого более тяжелой?

Нет, не вступают. Нет, не станет.