L>Тем-то и опасен READ UNCOMMITTED, что нет защиты от dirty reads. А что касается Тома Кайта, то он же о версионнике толкует. Т.ч. возвращаемся к словам Merle: "Должно быть что-то сильно не так, если по другому приложение работать не может..." (c)

это что-то, которое сильно не так поправили в Юконе, уровень isolation level snapshot. ждите.

Gt_

Здравствуйте, <Аноним>, Вы писали:

А>это что-то, которое сильно не так поправили в Юконе, уровень isolation level snapshot.
Ну уж всяко не для скорости, а сугубо удобства для....
И, кстати, там версионность реализована получше чем в Оракле... С теоретической точки зрения...

Здравствуйте, Merle, Вы писали:

M>И, кстати, там версионность реализована получше чем в Оракле... С теоретической точки зрения...
А из собственного (вашего) опыта ответ есть ... что в итоге перевесит версионность или блокировочность (в MS SQL Server ...) в тенденции так сказать.

Здравствуйте, KGP, Вы писали:

KGP>А из собственного (вашего) опыта ответ есть ... что в итоге перевесит версионность или блокировочность (в MS SQL Server ...) в тенденции так сказать.
Ээээ... Это вопрос?

Здравствуйте, Merle, Вы писали:

M>Ээээ... Это вопрос?
Да. Добавление версионости не является ли пробным шагом MS в направлении полной версионности?

Здравствуйте, KGP, Вы писали:
KGP>Да. Добавление версионости не является ли пробным шагом MS в направлении полной версионности?
Что значит "полной"? Нет, MS не собирается отказываться от блокировок. Уж очень они себя хорошо показывают

Здравствуйте, KGP, Вы писали:

KGP>Да. Добавление версионости не является ли пробным шагом MS в направлении полной версионности?
Однозначно нет. В любом случае это не будет "полной версионностью". Не смотря на ряд удобств, в производительности на OLTP задачах чистые версионники явно проигрывают, что подтверждается и теорией и тестами. Тот же Оракл далеко не чистый версионник.
При работе с чистым блокировочником проблема одна — свести задачу к OLTP. Иногда это довольно трудоемкий процесс, да и не всегда это в принципе возможно. И в таких случаях наличие версионности здорово помогает, так что в MSSQL'е будет одинаково развиваться и блокировочность, и версионность, (благо реализация это позволяет: http://rsdn.ru/?Forum/?mid=525046

Автор: Иван Бодягин (Merle)
Дата: 30.01.04

) и, возможно, что-то еще.

В идеале, для разработчика должно быть совершенно не важно, какой механизм Concurrency Control применяется в СУБД. Он должен обеспечивать честный Serializability с приемлимой производительностью, и это все что требуется.
Все остальные уровни изоляции, существующие на данный момент и в теории, и в реализациях — "от бедности", от того, что при любой реализации "честного" Serializability производительность серьезно страдает.
На сколько мне известно, теоретические работы в этом направлении довольно активно ведуться, но как это будет выглядеть вконечном итоге, если вообще получится, не известно.
Это вполне может быть и не версионность и не блокировочность, а какой-нибудь Serialization Graph Testing навороченый или вообще, гибрид трех-четырех различных механизмов.

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

странно, а вот на tpc-c версионный оракл на одинаковом железе одного производителя делает блокировочника MS на 25% ... или речь о других тестах, может SAP ?


ЗЫ. модель должна определятся задачей, тут красавцы MySQL — модель привязана к типу таблицы, где нада — там версионность, где не нада — там реактивные атомарные операции без транзакций, красота жаль на серьезных нагрузках проседает
ЗЗЫ. опен соурс например тоже как-то не увидело преимуществ блокировочника, все кто появился — версионники Firebird, Posgres, SAP, Mysql ...

Gt_

Здравствуйте, Аноним, Вы писали:

А>странно, а вот на tpc-c версионный оракл на одинаковом железе одного производителя делает блокировочника MS на 25% ... или речь о других тестах, может SAP ?
Во-первых Оракл не чистый версионник, о чем я, кстати, написал.
Во вторых, в тестах tpc Оракл побежает за счет того, что сейчас там используется 64bit интеловские процессоры, которые по архитектуре схожи с сановскими спарками, под которые у Оракла написаны тонны софта, вотличие от MS и IBM. Так что выигрывает он там не за счет механизма параллелизма, а за счет более оптимально написаных низкоуровневых алгоритмов, заточеных под конкретную архитектуру. Позволю себе напомнить, что предыдущая версия сливала раза в два.
В третьих, даже при этом, если внимательно посмотреть на 5е и 6е места tpc-c тесте, где на одном и том же железе и одной и той же операционке Oracle и DB2 показали практически одинаковые результаты, то выясняется, что DB2 работал на 20 оптоволоконных контроллерах, в то время как Ораклу, чтобы достичь той же пропускной способности понадобилось 70. Что говорит о том, что с дисковой подсистемой у Оракла далеко не все шоколадно, а это как раз и Concurrency Control в том числе.
В четвертых, у SAP'а свой собственный менеджер транзакций, который механизм параллелизама СУБД не трогает вообще. Поэтому в споре версионность vs блокировочность его тесты вообще не при чем.

А>ЗЫ. модель должна определятся задачей,
Да кто бы спорил...

А> тут красавцы MySQL
По мне бы лучше бы в транзакции они вообще не совались. Был неплохой сервер для своих задачь, единственный в своем роде, а сейчас получится уродец, который толком работать не сможет ни там, ни там.. (IMHO).

А>ЗЗЫ. опен соурс например тоже как-то не увидело преимуществ блокировочника, все кто появился — версионники Firebird, Posgres, SAP, Mysql ...
Ага, и приличного сервера из них ни одного... Даже до уровня Sybase ни один и близко не дотягивает, не говоря уже об остальных лидерах.

зачем так горичится, достаточно урла где " в производительности на OLTP задачах чистые версионники явно проигрывают"

cool
и это у IBM нет опыта с 64 ? а можно точнее на мэйнфрейме нет или POWER4 ? ? у интела 64 бита родилось благодоря DECовской альфы ... а откуда инфо что сан имеет какое-то отношение к интелу ?
чо-то в теорию 64-бита пока слабо верится ...

то выясняется, что DB2 работал на 20 оптоволоконных контроллерах,

ну и о чем это говорит ? ... мне не очем, но могу как офигенный проффесионал в этом деле (в прочем как и все сдесь ) пофантазировать — например IBM 20 или 70 — пофигу, его проблема (например с блокировками) этим не решается, а оракл в свою очередь показал с 20 тот же результат, а с 70 лучший (чем IBM) т.е. у IBM "далеко не все шоколадно, а это как раз и Concurrency Control в том числе." т.к. не могут эфективно использовать диски.
а если еще пивка глотнуть — еще могу пару теорий двинуть

Gt_

Здравствуйте, Аноним, Вы писали:

А>достаточно урла где " в производительности на OLTP задачах чистые версионники явно проигрывают"
tcp.org
Ткни пальцем хоть в один чистый версионник присутствующий в этих тестах. Заранее оговорюсь, даже самые упертые Ораклоиды чистым версионником Оракл не считают.

А>и это у IBM нет опыта с 64 ?
Да. UDB разрабатывает совершенно отдельная команда, от той, которая пишед под майнфреймы. Одни в торонто, а другие где-то в штатах.

А>ну и о чем это говорит ?
О том, что у Оракла проблемы с дисковой подсистемой.

А>... мне не очем, но могу как офигенный проффесионал в этом деле
Оно и видно, так что молчал бы уж....

А> (в прочем как и все сдесь )
А вот я бы не обобщал, все обобщения — ложны, как известно.

А>пофантазировать — например IBM 20 или 70 — пофигу, его проблема (например с блокировками) этим не решается
Тут одно из двух, либо пофигу, либо проблемы с блокировками. Так что опять ты промазал и совсем что-то не то нафантазировал.

А>, а оракл в свою очередь показал с 20 тот же результат, а с 70 лучший (чем IBM)
Еще раз посмотри внимательно, он с 70 показал не лучше, а такой же результат, как IBM с 20.
Из чего явно следует, что проблемы у него а не у DB2.

А>а если еще пивка глотнуть — еще могу пару теорий двинуть
Иногда лучше жев... пиво пить, чем дурацкий флейм разводить в приличном месте.

Здравствуйте, Аноним, Вы писали:

А>ну и о чем это говорит ? ... мне не очем, но могу как офигенный проффесионал в этом деле (в прочем как и все сдесь ) пофантазировать — например IBM 20 или 70 — пофигу, его проблема (например с блокировками) этим не решается, а оракл в свою очередь показал с 20 тот же результат, а с 70 лучший (чем IBM) т.е. у IBM "далеко не все шоколадно, а это как раз и Concurrency Control в том числе." т.к. не могут эфективно использовать диски.
А>а если еще пивка глотнуть — еще могу пару теорий двинуть

1) Причем здесь процессоры если мы обсуждаем СУБД???

2) на 40 контроллеров больше, а результат лучше на 4% и у DB2 проблемы "не смешите меня Муля". Причем посмотри на время выпуска IBM опубликовал результат раньше. А то что увеличение кол-ва дисков и контроллеров приводит к увеличению производительности СУБД это к гадалке не ходи. Так как диски обычно и есть узкое место. Смотри золотое правило Amdahl.

Здравствуйте, <Аноним>, Вы писали:

А>1) Причем здесь процессоры если мы обсуждаем СУБД???
Рад низкоуровневых алгоритмов, типа сканирования индекса, довольно серьезно зависит от архитектуры процессора.

Здравствуйте, <Аноним>, Вы писали:

А>зачем так горичится, достаточно урла где " в производительности на OLTP задачах чистые версионники явно проигрывают"
Вот, кстати, о птичках.
DB2 дернул все рекорды Оракла оптом, в не кластерах.
http://www.tpc.org/tpcc/results/tpcc_perf_results.asp?resulttype=noncluster
Что характерно, на 32 разрядном процессоре собственного производства.
Подробно не сравнивал, но на первый взгляд, они добавили пару(!) контроллеров, чуть-чуть разогнали процессоры и перевели клиентов на wintel...

А>1) Причем здесь процессоры если мы обсуждаем СУБД???
в этом мире все взаимосвязанно, например МС не может в принципе использовать не интел (ну альфа исключение), дальше можно развести флейм на тему риски/мэйнфреймы и интел ...


А>2) на 40 контроллеров больше, а результат лучше на 4% и у DB2 проблемы "не смешите меня Муля". Причем посмотри на время выпуска IBM опубликовал результат раньше. А то что увеличение кол-ва дисков и контроллеров приводит к увеличению производительности СУБД это к гадалке не ходи. Так как диски обычно и есть узкое место. Смотри золотое правило Amdahl.


а вы случайно к разработке 1C не имете отношения ? там тоже ребята добились феноменального результата — сколько не тратся на железо система бысрее шевилится не будет. для справки это называется маштабируемостью (непомню как по русски звучало в ширину и в ...), т.е. еслиб дб2 могла она естественно показала бы лучший результат, но как грит оракл когда им надо показать лучший результат они берут оракл ...

Gt_

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, <Аноним>, Вы писали:

А>>зачем так горичится, достаточно урла где " в производительности на OLTP задачах чистые версионники явно проигрывают"
M>Вот, кстати, о птичках.
M>DB2 дернул все рекорды Оракла оптом, в не кластерах.
M>http://www.tpc.org/tpcc/results/tpcc_perf_results.asp?resulttype=noncluster
M>Что характерно, на 32 разрядном процессоре собственного производства.
M>Подробно не сравнивал, но на первый взгляд, они добавили пару(!) контроллеров, чуть-чуть разогнали процессоры и перевели клиентов на wintel...

ну ? если бы на этом железе запустили бы оракл то можно было бы делать выводы, а так — соглашусь POWER4 на сервере покруче чем интел, но стоимость ...
сейчас у нас есть тесты HP и предыдущие тесты IBM где на близких конфигурация разные БД

Gt_

Здравствуйте, <Аноним>, Вы писали:

А>ну ? если бы на этом железе запустили бы оракл то можно было бы делать выводы, а так — соглашусь POWER4 на сервере покруче чем интел, но стоимость ...
Да что опять за дешевые отмазки? Пускали уже Оракл на этом железе, и даже с той же операционкой. Сейчас это шестое место.
Причем опять-таки, Ораклу понадобилось почти в три раза больше дисковых контроллеров.
Вообщем, говоря твоими же словами, "могли бы сделать быстрее — сделали бы".
Да, и вот еще что, UDB 8.1 уже черти сколько времени, а Оракл типа новый.

я не знаю что вы там пускали, а IBM последний результат получил на своих новых процах, я не знаю чем они отличаются но как минимум тактовая частота у них на 200MHZ больше (power4 1.9ghz), а судя по прес релизу не только. то что оракл не запустили на таком железе минус ораклу, но на одинаковых процах (power4 1.7ghz) оракл быстрее на 5000 транзакций в минуту ...

Да. UDB разрабатывает совершенно отдельная команда, от той, которая пишед под майнфреймы. Одни в торонто, а другие где-то в штатах.

ага, у них наверно корпоративная политика — технологиями только с HP и ораклом делится, а свои с 0 пишут, это ж нешутка программисты за тысячи км а аутсоурсинг провакаторы индусы придумали. global services это не про IBM

Gt_

Здравствуйте, <Аноним>, Вы писали:

А> на одинаковых процах (power4 1.7ghz) оракл быстрее на 5000 транзакций в минуту ...
Что составляет полтора процента, и при этом ораклу потребовалось в три раза больше дисковых контроллеров, чтобы этой производительности добиться.
Рекордная же система DB2 имеет всего на два контроллера больше чем их же предыдущая, что говорит как раз о том, что с дисковой подсистемой у DB2 проблем нет, в отличии от Оракла.
Кстати, я ошибся, процессоры там, на самом деле, 64 разрядные.

А>ага, у них наверно корпоративная политика — технологиями только с HP и ораклом делится, а свои с 0 пишут, это ж нешутка программисты за тысячи км а аутсоурсинг провакаторы индусы придумали. global services это не про IBM
Все это конечно весело но майнфреймы ничего общего с новой архитектурой интела не имеют, и делиться опытом просто некому.

А>> на одинаковых процах (power4 1.7ghz) оракл быстрее на 5000 транзакций в минуту ...
M>Что составляет полтора процента, и при этом ораклу потребовалось в три раза больше дисковых контроллеров, чтобы этой производительности добиться.
M>Рекордная же система DB2 имеет всего на два контроллера больше чем их же предыдущая, что говорит как раз о том, что с дисковой подсистемой у DB2 проблем нет, в отличии от Оракла.
M>Кстати, я ошибся, процессоры там, на самом деле, 64 разрядные.

кто говорит ? Мерле самый комизм ситуации что ни ты ни я в глаза этих процев не видели
на счет IBM я вижу все на оборот — проц на 10% бысрее, а дисков не добавили — бесполезно, блокировки не дают эфективно использовать диски, поэтому сколько их не суй толку нет. у оракла толк есть, поэтому их напихали больше, поэтому результат лучше на 5тыщ tpc. зато у IBM работа с памятью (+200MHZ для разруливания блокировок) дала вон какой прирост производительности причем всего 32 проца (!)


А>>ага, у них наверно корпоративная политика — технологиями только с HP и ораклом делится, а свои с 0 пишут, это ж нешутка программисты за тысячи км а аутсоурсинг провакаторы индусы придумали. global services это не про IBM
M>Все это конечно весело но майнфреймы ничего общего с новой архитектурой интела не имеют, и делиться опытом просто некому.

в интеле от интела одни x86 инструкции остались, большинство это технологии DEC и риск проца альфа. IBM всю жизнь на 64 битах, как не крути AIX + power4 + DB2 UDB "ничего общего с новой архитектурой интела не имеют"

Gt_