Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 12 13 14 15 16 [17] 18 19 20 21 .. 26   вперед  Ctrl
 Re: Провал операции Yukon  [new]
Glory
Member

Откуда:
Сообщений: 104751
откуда дополнительные 20% производительности операций пишущих в базу берутся при переводе MS SQL с файловой системы на сырой девайс?

Откуда у вас появилась цифра 20% ???
26 май 04, 21:26    [703484]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
barmaglot
Member

Откуда:
Сообщений: 10
автор
Кстати, в MS SQL авторитеты рекомендуют использовать "сырые партиции" для подъема производительности операций пишущих в базу

Чуш какая, хотя может для какого-нибудь 6.5 это и было справедливо...
Я как раз встречал обратные рекомендации от MS, смысл коих был в том, что raw device - устарел и оставлен исключительно для обратной совместимости, посему пользоваться им не рекомендуется.
Пресловутые 8K никоим образом на ФС не завязаны. Это просто универсальный размер страницы подходящий для подавляющего большинства случаев (для MSSQL'я), за исключением совсем уж экзотики, при этом даже если этот случай такой уж уникальный, вряд ли изменение размера страницы даст серьезный выигрыш.

Что касается этой замечательной succsess story по поводу победы Оракла над несчастным эскуелем в одном отдельно взятом банке, то дело вовсе не в неспособности сервера держать нагрузку. Осмелюсь утверждать, что в россии на данный момент в принципе нет задачь, с которыми MSSQL не справился бы, равно как и Оракл и DB2.
То, что MS масштабируется хуже факт известный, но это общая беда всех блокировочников (DB2, Sybase, Informix), но не стоит из этого делать вывод о не способности MS вообще держать нагрузку. Ровно с теми же проблемами столкнулись бы и в DB2 и в Sybase, и способы преодоления этих проблем давно известны и везде с успехом используются - было бы желание...
Причины же выбора Оракла могут быть самыми разнообразными, начиная от того, что переделка системы на MS обошлась бы дороже (в следствии большей трудоемкости), чем переделка системы на Оракле и заканчивая тем, что наоборот, система на Оракле получалась существенно дороже и, как следствие, нужны люди получали гораздо более вкусный откат...

Что же касается терминологии, то спор изначально глупый, все прекрасно понимают о чем речь, но глотки подрать - милое дело. Справедливости ради надо заметить, что слово "блок" действительно упоминается в теоретической литературе, но крайне редко и больше во введении в качестве синонима, в основном все-таки используется "страница", и я считаю этот термин более чем подходящим. Основную неразбериху в терминологию вносит как раз Оракл (а уж за переводы этого дела вообще стрелять надо), очень многие, кроме обрывков его документации ничего в глаза не видели но спорить лезут в первых рядах, но, к счастию, не Ораклом единым жив СУБД'шный мир....
26 май 04, 23:06    [703580]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
2 alexeyvg

Ok, с начала
1) Меня удивила ваша фраза о том, что MSSQL может работать с дисками
в обход raw device. В моем представлении, последнее есть не более чем
партиция диска.
2) Вы в ответ на мое удивление выразили сомнение в моей компетентности.
Честно говоря, меня это удивило еще больше.
3) Любая, сколь угодно прямая работа с диском через файл не может быть
более быстрой чем работа с сырой партицией. Просто потому, что
добавляется еще один слой. И разница не в издержках на интерфейсы,
а именно в таких моментах как фрагментация файлов (в частности).
4) Более быстрой может быть только работа с физикой не разбитого диска,
но разумеется это очень неудобно, посему не используется, кроме того,
сильно сомневаюсь, что это приведет к сколь нибудь заметному ускорению
в работе (теоретически).
27 май 04, 08:43    [703820]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 32167
2Gluk (Kazan)
автор
1) Меня удивила ваша фраза о том, что MSSQL может работать с дисками в обход raw device. В моем представлении, последнее есть не более чем партиция диска.

Возможно, я неправильно выразился. Я имел в виду, что MSSQL работает с диском совершенно одинаково как при работе с "raw device", так и при работе с файлом, и разницы в производительности при этом нет.
Ну а схему работы с файлом для MSSQL нам уже замечательно описал juha_teuvonnen :-)

автор
2) Вы в ответ на мое удивление выразили сомнение в моей компетентности. Честно говоря, меня это удивило еще больше.

Тут как раз всё просто - это ответ на сомнения в моей некомпетентности. И вообще, как-то помягче надо писать.
Напоминаю:
автор
Гы Гы Гы, на оленьих упряжках или голубиной почтой ?
Сам то понял, что сморозил ?

Это я ещё не стал устанавливать связи между используемой обычно БД и вашим ником :-)

автор
3) Любая, сколь угодно прямая работа с диском через файл не может быть более быстрой чем работа с сырой партицией. Просто потому, что
добавляется еще один слой. И разница не в издержках на интерфейсы,
а именно в таких моментах как фрагментация файлов (в частности).

Ну вот это мне и непонятно. Где конкретно разница (допустим, что сильной, фатальной фрагментации нет)?
Когда вы говорите "добавляется еще один слой", я понимаю это именно как "издержки на интерфейсы", с этим я согласен.
А ещё-то что?

автор
4) Более быстрой может быть только работа с физикой не разбитого диска, но разумеется это очень неудобно, посему не используется, кроме того, сильно сомневаюсь, что это приведет к сколь нибудь заметному ускорению в работе (теоретически).


Тут как раз уменьшается к-во уровней драйверов. Трудно сказать, приведёт это к сколь нибудь заметному ускорению в работе или нет. Я тоже сомневаюсь.
27 май 04, 14:12    [705050]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
2 alexeyvg

Только не надо про ники и БД и тем и другим горжусь. Кроме того, Вы не будете в этом оригинальны Про оленьи упряжки, это я не проспавшись, веселый был очень, прошу прощения, но Вы тоже не ангел.
В общем мне нравится MS SQL 2000, но он имеет серьезные недостатки.
Разумеется и Oracle имеет свои минусы, но то что преподноситься в качестве его минусов адептами MS SQL лично мне никогда не мешало, а существенные минусы MS SQL этими людьми сильно преуменьшаются. В общем:

В чужом глазу ...
27 май 04, 14:47    [705184]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2400
Блог
barmaglot
Я как раз встречал обратные рекомендации от MS, смысл коих был в том, что raw device - устарел и оставлен исключительно для обратной совместимости, посему пользоваться им не рекомендуется

BOL

Devices (Level 3)
The database architecture of Microsoft® SQL Server™ 2000 differs from the database architecture of SQL Server 6.x. In SQL Server 2000:

Operating system files replace database devices.
........

BOL
Using Raw Partitions
Microsoft® SQL Server™ 2000 supports the use of raw partitions for creating database files. Raw partitions are disk partitions that have not been formatted with a Microsoft Windows NT® file system, such as FAT and NTFS. In some cases, using databases created on raw partitions can yield a slight performance gain over NTFS or FAT.


Вы сперва разобрались бы о чём речь...
27 май 04, 15:05    [705239]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Leonid
Member [заблокирован]

Откуда: From nowhere
Сообщений: 743
автор
В общем мне нравится MS SQL 2000, но он имеет серьезные недостатки... В чужом глазу ...
Народ, давайте попробуем еще раз, без драки, какие и у кого "существенные" недостатки?

IMHO:
Что мне нравится в MSSQL и не нравится в Oracle:
  • самоконфигурируемые буферы в MS и динамическое управление памятью. В oracle мне необходимо вручную задавать размер буферов, либо (начиная с 9i) создавать скрипты на изменение в зависимости от ситуации. Это по сути означает, необходимость приглядывать за буферами, т.е. наличие грамотного (высокооплачиваемого) админа.
    Другое дело, что никто не знает точного алгоритма конфигурации буферов в MS (это им минус).
  • организация в виде несколько БД на одном сервере в MS удобнее с точки зрения хранения разнородный данных на одном сервере. Даже отключение/перенос БД с сервера на сервер проще чем схемы в Oracle.
    Схемы есть и в mssql, но про них там можно забыть.
  • более простой способ предоставления доступа к объктам БД в MS. В oracle, зачастую, для доступа разных юзеров к объектам схемы, необходимо создание паблик синонимов.
  • shrink (сжатие) делается в MSSQL легко, а в Oracle это сложный процесс деактивации тригеров/процедур, переброса таблиц и реорганизации индексов. Не так часто это надо, но все же.
  • удобный и всеобъемлющий набор инструментов идущий в поставке MSSQL. Практически, не нужно сторонних программ.

    Все это и масса других тонкостей делает удобным применение MS в решении задач малого и среднего бизнеса.
    На больших задачах, где "супер-пупер-админ" должен быть по определению, эти "неудобства" Oracle не будут заметны, но далеко не все и не всегда имеют дело с такими задачами. Но на этих же задачах с успехом может применяться и mssql.
  • 27 май 04, 17:10    [705800]     Ответить | Цитировать Сообщить модератору
     Re: Провал операции Yukon  [new]
    Зл0й
    Member

    Откуда: Северная Калифорния
    Сообщений: 686
    Соглашусь с Леонидом в том, что у Оракла и MS SQL несколько разная ниша на рынке. Мой личный Оракловый опыт такой:

    OLTP: back-end веб сайта крупнейшего в США телеком-оператора.
    Система обработки кредитов. Много сотен клиентов по всей стране.
    DW/DSS/OLAP: Хранилище данных на десяток терабайт. Data Mart кредитного отдела. В том же банке.

    Все проекты - крупные. Во всех проектах не просто 1 админ, а целая команда. Она состоит из нескольких Юниксовых сисадминов, нескольких DBA и одного или нескольких человек разбирающихся менее глубоко, но "во всем" (Юникс,Оракл DBA, Разработка). Каждый занимается всоим делом, а "универсальные" спецы - интеграцией. Например под нагрузкой и при определенном стечении обстоятельств вылезает ORA-600. Поди разберись, кто там виноват, баг в Оракле, ОС, firmware дискового массива. И чел из Оракла у нас "на сайте" пасется. Ибо мы у Оракла - "нежно любимый клиент". При таком раскладе у нас и Оракл и ОС затюнены дальше некуда. Ну и естественно у нас есть standby за полторы тысячи миль от основного сервера. Так что если штат Калифорния завтра провалится в тар-тарары, то денежки никуда не пропадут. Это от нас требуют грозные организации, такие как FDIC, OCC и прочие. Регуляторы так сказать.

    Так вот, к чему я это все пишу. А к тому что в таких проектах "достоинства" MS SQL оборачиваются недостатками. Ибо банде квалифицированных админов не нужен "самонастраивающийся" сервер. Он как-нибудь не так "самонастроится" и потом иди - гадай, что же там произошло. Для больших проектов нужен сервер гибкий, который квалифицированные спецы могут настрить по данную конкретную задачу.

    А мелкой российской конторе действительно пока проще поставить MS SQL и нанять программера за 1000 долларов и пару студентов за 500 чтобы они на дельфях им там что-то наваяли. Или 1С поставить с тем же MS SQL. Интересно будет посмотреть на это безобразие, когда кто-то дальновидный станет делать ASP модель. То есть клиенту не нужен сервер вообще. Покупаете "абонемент" и имеете все что вам надо в сети через веб-интерфейс. Правда, учитывая российские реалии (доступ в сеть с оплатой за траффик, маски-шоу и пр.) эта идея может и не "проканать". Если прокатит, та на такой проект СУБД - Оракл однозначно.
    27 май 04, 21:49    [706311]     Ответить | Цитировать Сообщить модератору
     Re: Провал операции Yukon  [new]
    Alexander_Chepack
    Member

    Откуда: London
    Сообщений: 22649
    автор

    То есть клиенту не нужен сервер вообще. Покупаете "абонемент" и имеете все что вам надо в сети через веб-интерфейс. Правда, учитывая российские реалии (доступ в сеть с оплатой за траффик, маски-шоу и пр.) эта идея может и не "проканать". Если прокатит, та на такой проект СУБД - Оракл однозначно


    На моей предыдущей работе мы именно этим и занимались - СУБД - SQL Server. Проблем не было.
    28 май 04, 13:12    [707749]     Ответить | Цитировать Сообщить модератору
     Re: Провал операции Yukon  [new]
    Зл0й
    Member

    Откуда: Северная Калифорния
    Сообщений: 686
    Уважаемый Александр,

    А можно интересоваться какая была нагрузка на SQL сервер? То есть сколько было одновременно подключенных пользователей, итп. Хотя, соглашусь с вами в том, что используя кластеризацию или load balancing в той или иной форме можно масштабировать даже "не масштабируемые" интербэйс и MySQL. Главное - чтобы клиенты за одни и те же данные не боролись. Раскидываем клиентов по серверам СУБД, не допуская такой нагрузки при которой данная СУБД ложится, грубо говоря. Подход здоровый и имеющий право на существование. Но это - скорее умение разработчиков обходить недостатки СУБД чем достоинство самой СУБД. Из серии "голь на выдумки хитра" и "хочешь жить - умей вертеться". Я тут как-то копался в исходниках оупенсорсного интербэйса, исключительно из академического интереса. Там все как в старых BSD-юниксах сделано, в которых SMP по-нормальному не поддерживается. Стоит один большой lock на все структуры ядра СУБД (в старых юниксах - ядра ОС). Поэтому в любой момент времени с ними может работать только один трэд. Поскольку немерянными счетными задачами СУБД не занимается, а в структуры данных и буффера лазит постоянно, то что у вас 1 процессор, что 16 производительность будет почти такая же. И знаете как с этим бороться? А запустить много интербэйсов и распределять нагрузку между ними на уровне сервера приложений. Так что выкрутиться можно и при откровенно хреновой в плане месштабируемости СУБД. За что люблю Оракл - не надо выкручиваться. Я - ленивый до ужаса. И пишу что-то только тогда, когда задача стандартными средствами не решается ни в какую. Лень - благодетель программиста (С) Джон Бентли "Жемчужины творчества программистов".
    28 май 04, 20:29    [709110]     Ответить | Цитировать Сообщить модератору
     Re: Провал операции Yukon  [new]
    Alexander_Chepack
    Member

    Откуда: London
    Сообщений: 22649
    Одновременно более или менее активно работающих пользователей было около 2500.

    Да у меня и сейчас спокойно около 1000 пользователей работает с одним сервером - причем эта база данных - это их основной рабочий инструмент, они в ней непрерывно сидят весь рабочий день. Через месяц еще 200 добавится из Голландии. Причем, повторяю, это не просто зарегистрированные пользователи - это люди, которые довольно активно тяжелые запросы гоняют по базе данных.

    Все работает, сервер перезагружаю крайне редко - может раза 3-4 в год.
    28 май 04, 20:55    [709129]     Ответить | Цитировать Сообщить модератору
     Re: Провал операции Yukon  [new]
    Зл0й
    Member

    Откуда: Северная Калифорния
    Сообщений: 686
    Гонять запросы против MS SQL можно. А у вас бывает такой расклад когда один юзер в данные rows пишет а другой из них читает, причем в одно и то же время? Например под конец дня народ спешно заколачивает информацию о выданных кредитах а начальник гоняет отчет кто чего и сколько выдал? Чтобы спросить у подчиненного у которого "мало выдано" он действительно мало выдал или еще не успел в систему заколотить. Начальник отчет перезапускает неоднократно (после звонков подчиненным). Поговорил - хочет быстренько иметь результат на экране. А в режиме "только чтение" можно и без Оракла обойтись. Правда в Оракле есть куча всего полезного для аналитики. Но у MS на эту тему свои средства. Поскольку я их не юзал, то хвалить или ругать не возьмусь.
    29 май 04, 03:55    [709291]     Ответить | Цитировать Сообщить модератору
     Re: Провал операции Yukon  [new]
    Leonid
    Member [заблокирован]

    Откуда: From nowhere
    Сообщений: 743
    Зл0й:
    Гонять запросы против MS SQL можно. А у вас бывает такой расклад когда один юзер в данные rows пишет а другой из них читает, причем в одно и то же время?
    Иначе говоря, основная ваша притензия к MSSQL, что он блокировочник, поэтому хуже масштабируется.
    Хорошо, притензия принимается. Подождем Yukon со snapshot-ами, посмотрим что будет там...
    А есть ли спецы по DB2? Как там дела с блокировками?
    29 май 04, 12:23    [709342]     Ответить | Цитировать Сообщить модератору
     Re: Провал операции Yukon  [new]
    Alexander_Chepack
    Member

    Откуда: London
    Сообщений: 22649
    автор

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


    Конечно бывает - база используется как для чтения, так и для изменения данных. Более того, года 2.5 назад были проблемы с блокировками - но вместо того, чтобы рвать волосы и абстрактно рассуждать о версионниках vs. блокировочников, я просто разобрался с кластерными индексами и объяснил программистам что строить clustered primary key по identity колонкам - это не самое разумное решение. До этого наши программисты о кластерных индексах просто не задумывались. С тех пор все жужжит и работает практически без проблем, хотя иногда после очередного "усовершенствования" софта снова приходится немного повозиться - индексы подкрутить, особо навороченные процедуры подправить - но это дефекты девелоперов, а не СУБД. SQL Server, на самом деле, очень классный продукт - особенно начиная с версии 7. Вот версия 4.21 (1993 год) была действительно довольно примитивной - ну так и первая версия Oracle, наверное, тоже не была чем-то сверхъестественным.
    29 май 04, 15:30    [709423]     Ответить | Цитировать Сообщить модератору
     Re: Провал операции Yukon  [new]
    dimitr
    Member

    Откуда: PNZ
    Сообщений: 7000
    Зл0й
    Поскольку немерянными счетными задачами СУБД не занимается, а в структуры данных и буффера лазит постоянно, то что у вас 1 процессор, что 16 производительность будет почти такая же. И знаете как с этим бороться? А запустить много интербэйсов и распределять нагрузку между ними на уровне сервера приложений.


    Несмотря на абсолютную корректность твоих замечаний, не стоит забывать про факт, что IB поддерживает еще и т.н. "классическую" архитектуру, имеющую те же BSD-корни и реализующую многозадачность по принципу "один процесс сервера на коннект пользователя". И в этой архитектуре IB масштабируется практически линейно, при наличии соответствующего железа. По крайней мере, реально существуют системы до 1000 активных коннектов, на всю катушку использующих SMP-железо. Так что для не совсем монстроидных систем сервер приложений все же необязателен. Кто-то, конечно, может сказать, что 1000 коннектов - это даже не средняя система, но я никогда не рассматривал IB как решение более сложных задач, IMHO для этого есть Oracle/DB2/MSSQL.

    Все вышесказанное - не в защиту IB, а объективности ради.

    P.S. Borland декларирует поддержку SMP в своем multithreaded сервере IB 7. Но насчет качества оной я деликатно промолчу ;-)
    30 май 04, 12:26    [709761]     Ответить | Цитировать Сообщить модератору
     Re: Провал операции Yukon  [new]
    alexeyvg
    Member

    Откуда: Moscow
    Сообщений: 32167
    2Зл0й

    Насчёт масштабируемости расскажу про свой опыт с MSSQL.

    Для эксплуатации одной западной ЕРП системы у заказчиков типично было 500 пользователей, работавших на 4-х процессорном П3 ксеон. Одна система была с 1000 пользователей и работала на 8-и процессорном сервере.
    Системы тяжёлые, не только чтение, конечно.

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

    По объёмам - с террабайтными базами не работал, обычно не более нескольких десятков гигов, так-что такого опыта нет.
    30 май 04, 18:16    [709874]     Ответить | Цитировать Сообщить модератору
     Re: Провал операции Yukon  [new]
    Зл0й
    Member

    Откуда: Северная Калифорния
    Сообщений: 686
    Для начала введу термин собственного изобретения "hot spot" - запись (или группа записей) в одной или нескольких таблицах, таких что:
    - Записи подвергаются одновременному (возможно неоднократному) изменению несколькими сессиями
    - Одновременно с изменением происходит чтение данных и предъявляются жесткие требования к чистоте этого чтения (read consistency)
    "Горячие точки" имеют тенденцию остывать по мере того как снижается актуальность данных. Если кто-то знает более удачный общепринятый термин - с удовольствием приму на вооружение.

    Версионик (Оракл) позволяет решать проблему "горячих точек" ценой увеличения объема ввода/вывода и потребляемой памяти. За все надо платить, а плата за поддержание нескольких версий - память и i/o расходуемые на этот механизм. Зато, проблема решается столь милыми моей крайне ленивой душе "стандартными средствами". В данном случае - средствами СУБД. Если же СУБД не предоставляет неблокирующего "чистого" чтения, то тогда разработчикам приходится использовать различные приемы чтобы решать проблему "горячих точек" другими средствами. Если нам удается разнести по времени (сериализовать, поставить в очередь) запросы на чтение и изменение "горячих" записей, то проблема становится менее актуальной. Делаться же это может различными способами, от дизайна клиентского ПО и базы до использования специального ПО для обработки транзакций, "внешнего" по отношению к СУБД. Например идеология IBM (ИМХО "разводилово на бабки") - использовать различное недешевое дополнительное ПО. Но все это - различные способы обхода ограничений СУБД-блокировщиков (MS SQL/Sybase/DB2/Informix). Хороший, грамотный разработчик тем или иным способом из этих ограничений "выкрутится". Цена - дополнительные затраты на разработку и поддержку "выкрутасов" или покупку и сопровождение дополнительного ПО. Я лично сторонник того подхода, что транзакциями должна управлять СУБД ибо она ближе всего к данным находится, и ей "виднее".
    1 июн 04, 08:53    [712613]     Ответить | Цитировать Сообщить модератору
     Re: Провал операции Yukon  [new]
    Borland
    Member

    Откуда: $HOME
    Сообщений: 15839
    Любителям мелкомягких посвящается...


    З.Ы. Хоть и несовсем по теме...
    -----
    Все великие дела совершаются в командной строке
    1 июн 04, 10:21    [712861]     Ответить | Цитировать Сообщить модератору
     Re: Провал операции Yukon  [new]
    Leonid
    Member [заблокирован]

    Откуда: From nowhere
    Сообщений: 743
    Borland
    З.Ы. Хоть и несовсем по теме...
    Да уж точно, не понятно, к чему это? :)
    1 июн 04, 10:47    [712972]     Ответить | Цитировать Сообщить модератору
     Re: Провал операции Yukon  [new]
    Glory
    Member

    Откуда:
    Сообщений: 104751
    Да уж точно, не понятно, к чему это? :)
    Имхо - это в строну слияния с топиком "Почему я ненавижу Microsoft" :)
    1 июн 04, 10:49    [712977]     Ответить | Цитировать Сообщить модератору
     Re: Провал операции Yukon  [new]
    Leonid
    Member [заблокирован]

    Откуда: From nowhere
    Сообщений: 743
    Glory
    Имхо - это в строну слияния с топиком "Почему я ненавижу Microsoft" :)
    Так вот, выходит, истинная причина ненависти к MS. Что ж вы раньше-то молчали!? :)
    Я считаю, что MS должна принести официальные извинения всем ценителям Белоснежки. Может и на этом форуме MS-ненавистников поубавится
    1 июн 04, 11:50    [713205]     Ответить | Цитировать Сообщить модератору
     Re: Провал операции Yukon  [new]
    BGg
    Guest
    автор
    Для начала введу термин собственного изобретения "hot spot"

    Hot Spot - это немного из другой оперы, ну да ладно.

    автор
    Но все это - различные способы обхода ограничений СУБД-блокировщиков (MS SQL/Sybase/DB2/Informix). Хороший, грамотный разработчик тем или иным способом из этих ограничений "выкрутится". Цена - дополнительные затраты на разработку и поддержку "выкрутасов" или покупку и сопровождение дополнительного ПО.

    Все не так.
    В чистой OLTP время ожидания на блокировке в среднем равно времени которое необходимо версионнику, чтобы найти нужную версию данных. При этом блокировочник по определению требует меньше ресурсов, он на блокировке просто ждет, в отличии от версионника, который в версиях копается и ищет нужную (это все в первом приближении, ну примерно на том же уровне, что Вы проблему описали). Таким образом, для блокировочника в принципе эта проблема ("hot spot") менее актуальна и производительность он показывает выше, да и нагрузку держит лучше.
    Другое дело, что задачу надо свести к чистому OLTP, а для этого нужен разработчик с прямыми руками, тут Вы правы, но не ужели вы будете утверждать, что для Оракла менее прямые руки требуются? ;)
    1 июн 04, 18:31    [714754]     Ответить | Цитировать Сообщить модератору
     Re: Провал операции Yukon  [new]
    alexeyvg
    Member

    Откуда: Moscow
    Сообщений: 32167
    2BGg

    автор
    не ужели вы будете утверждать, что для Оракла менее прямые руки требуются? ;)


    А вот меня в форуме многие спецы убеждали что для Оракла квалификации меньше требуется, что он легче прощает ошибки разработчика...

    Так что я спокоен - спрос на высококвалифицированные кадры для MSSQL будет расти быстрее :-)
    1 июн 04, 18:55    [714818]     Ответить | Цитировать Сообщить модератору
     Re: Провал операции Yukon  [new]
    Зл0й
    Member

    Откуда: Северная Калифорния
    Сообщений: 686
    BGg
    В чистой OLTP время ожидания на блокировке в среднем равно времени которое необходимо версионнику, чтобы найти нужную версию данных. При этом блокировочник по определению требует меньше ресурсов, он на блокировке просто ждет,

    Вынужден не соглачиться с этим утверждением. По моему личному опыту при грамотно настроенном версионнике и предоставлении ему адекватных ресурсов время необходимое ему для поиска нужной версии данных гораздо меньше времени ожидания на блокировке. Если данные которые нужны для создания снапшота лежат в кэше, то их выемка оттуда и выдача клиенту выполяется "на раз". Вынимать данные (особенно если значительная их часть кэширована) быстрее чем "спать" на блокировке. То что версионнику нужно больше ресурсов - факт известный, но и кушает эти ресурсы он не зря. "Чистый OLTP" это я так понимаю полное отсутствие "долгоиграющих" отчетов? К сожалению иногда наличие отчетов выполняемых против онлайновых данных - жесткое (необсуждаемое) требование заказчика. Особенно если заказчик разбалован Ораклом. Пример приведен выше - БД кредитного отдела.

    Все вышеизложенное - наблюдения из моего личного опыта. Your mileage may vary.
    1 июн 04, 21:07    [714988]     Ответить | Цитировать Сообщить модератору
     Re: Провал операции Yukon  [new]
    Bbg
    Guest
    автор
    По моему личному опыту при грамотно настроенном версионнике и предоставлении ему адекватных ресурсов время необходимое ему для поиска нужной версии данных гораздо меньше времени ожидания на блокировке.

    ... тогоже версионника.. ;) Ну да ладно.

    автор
    Если данные которые нужны для создания снапшота лежат в кэше, то их выемка оттуда и выдача клиенту выполяется "на раз"

    При тяжелой нагрузке, когда разные версии одних и тех же данных нужны разным транзакциям, поиск нужной версии процесс не быстрый.
    И в принципе сравнимый с ожиданием на блокировке в хорошо отлаженном блокировочнике, ну как минимум того же порядка.

    Но тут есть еще один момент, вся эта радужная картина счастливого версионника хорошо работает только на read only транзакциях, но как только транзакция начинает что-нибудь куда-нибудь писать, сразу все становится очень грустно. Тем более в Оракле, с его нездоровым стремлением к согласованности, к тому же недоведенной до ума.
    Там где блокировочнику достаточно опять-таки просто подождать, версионник вынужден откатывать, а это та еще развлекуха, которая сводит на нет все преимущество отыгранное при чтении.

    Да, действительно, когда нужны отчеты по активно изменяемым данным блокировочнику приходится сложнее, но задача вовсе не так неразрешима, как Вы пытаетесь ее представить и все приемы и способы довольно давно и хорошо известны.
    1 июн 04, 21:40    [715022]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: Ctrl  назад   1 .. 12 13 14 15 16 [17] 18 19 20 21 .. 26   вперед  Ctrl
    Все форумы / Сравнение СУБД Ответить