Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5   вперед  Ctrl      все
 Re: Выбор СУБД  [new]
Yo.!
Guest
объявляю кокурс кто догадается, что за звон с "неконтролируемого рестарта стейтментов" улсышало мнение может это он оракл с interbase и его cursor stabilty путает ?
21 фев 07, 16:45    [3817449]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
мнение
Guest
softwarer


Упоминание подзапроса здесь имхо не совсем к месту. Если это существенная часть Ваших рассуждений, подозреваю, Вы хотели рассказать не о мини-откатах, а о специфике read consistency в этом случае.


И от том и о другом.
Мне кажется вы передергиваете. ( Уверен, что понимаете о чем идет речь).

А речь в следующем:
ИХМО read consistency здесь причина, а миниоткат следствие.
Нельзя разделять эти вещи с точки зрения подержки цеслостности данных.
Мною были упомянуты следствия, вы указали на причины.
Все логично.


softwarer

В общем, суть получается такой: версионник плох тем, что в некоторых случаях ведет себя так же, как блокировочник ведет себя всегда :))


Не буду спорить с авторитетом сайта.
Пусть будет по Вашему.
21 фев 07, 16:54    [3817520]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Yo.!
Guest
афтар жжет я с него балдею.
открою страшную тайну - версионный MSSQL при isolation level snapshot, имеет предикатные блокировки и не имеет миниотката, ужос да ?
и, мнение, потеште нас, расскажите все же что за связь вы нашли у этого update и миниоткатом ? там достаточно одного такого update да :) ?
21 фев 07, 17:06    [3817609]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
мнение
Мне кажется вы передергиваете. ( Уверен, что понимаете о чем идет речь).

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

мнение
А речь в следующем:
ИХМО read consistency здесь причина, а миниоткат следствие.
Нельзя разделять эти вещи с точки зрения подержки цеслостности данных.
Мною были упомянуты следствия, вы указали на причины.
Все логично.

Вы говорите весьма общими словами, что создает весьма широкое поле для возможных трактовок. Скажу так: по состоянию на настоящий момент то, что и как Вы сказали, создает впечатление того, что Вы... не знакомы с обсуждаемой механикой достаточно, чтобы обсуждать ее опасность для этой задачи. В свою очередь, я не знаю эту область настолько досконально, чтобы отрицать возможность некоторых неведомых мне опасностей, но если Вы - ловко замаскировавшийся гуру, Ваши намеки оказались слишком тонкими.
21 фев 07, 17:09    [3817638]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
мнение
Guest
softwarer
мнение
Мне кажется вы передергиваете. ( Уверен, что понимаете о чем идет речь).

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


softwarer

Упоминание подзапроса здесь имхо не совсем к месту. Если это существенная часть Ваших рассуждений, подозреваю, Вы хотели рассказать не о мини-откатах, а о специфике read consistency в этом случае.


мнение

И от том и о другом.


а именно :

мнение

ИХМО read consistency здесь причина, а миниоткат следствие.
Нельзя разделять эти вещи с точки зрения подержки цеслостности данных.
Мною были упомянуты следствия, вы указали на причины.
Все логично.


То что эти понятия (рестарт и read consistency)
находятся в тесной связи, у меня сомнений не вызывает.
21 фев 07, 17:50    [3817934]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Yo.!
Guest
мнение

То что эти понятия (рестарт и read consistency)
находятся в тесной связи, у меня сомнений не вызывает.


я понимаю, что тему мнение не осилило :) но ниосилить даже заголовок - это круто
Алгоритм “мини-откатов” в Oracle или еще раз о Write Consistency
21 фев 07, 18:02    [3818057]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
мнение
То что эти понятия (рестарт и read consistency)
находятся в тесной связи, у меня сомнений не вызывает.

Прошу прощения, уезжаю, отвечу через пару часов. Пока ограничусь констатацией того, что зря "не вызывает".
21 фев 07, 18:09    [3818115]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
мнение
Guest
Yo.!
мнение

То что эти понятия (рестарт и read consistency)
находятся в тесной связи, у меня сомнений не вызывает.


я понимаю, что тему мнение не осилило :) но ниосилить даже заголовок - это круто
Алгоритм “мини-откатов” в Oracle или еще раз о Write Consistency


Похоже что кроме заголовка Вы ничего осилили:

автор

Происходит это потому, что выполнение команды UPDATE состоит из двух фаз: 1) согласованное чтение (consistent read) таблицы на момент начала выполнения команды для нахождения строк, подлежащих модификации (в том числе удовлетворяющих предикату, если он задан); 2) чтение блоков данных таблицы в текущем (current read) режиме для модификации найденных на предыдущей фазе строк.
Поэтому все новые строки, которые были вставлены в таблицу другими сеансами после начала выполнения команды UPDATE, “не видны” во время первой фазы команды UPDATE даже несмотря на фиксацию (COMMIT) таких вставок. Но, как мы увидим позже, это уже не так, если производится “мини-откат” этих команд.

......


Кроме того, в этом тесте я ввел четвертый сеанс “New rows”, который вставляет новые строки в таблицу wc_test, которые удовлетворяют предикату тестируемой команды. Эти строки вставляются после начала команды UPDATE в сеансе “Long update”. Моя цель в этом случае – показать, что, во-первых, эти строки после “мини-отката” будут изменены сеансом “Long update”. Во-вторых, что блокировка строк сеансом “Long update” после “мини-отката”, вполне возможно, будет происходить неоднократно.




За ссылку спасибо, раньше этого документа не видел.
21 фев 07, 18:42    [3818327]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
не важно
Guest
softwarer
мнение
То что эти понятия (рестарт и read consistency)
находятся в тесной связи, у меня сомнений не вызывает.

Прошу прощения, уезжаю, отвечу через пару часов. Пока ограничусь констатацией того, что зря "не вызывает".
Следует отметить, что здесь "мнение" право. Не было бы read consistency - не было бы и write consistency. тобы понять это, достаточно схоить по вышеуказанной ссылке и внимательно почитать. Также стоит отметить, что частично "мнение" не право, так как "рестарты" в Oracle контролируемы, правда для этого его придется делать "супер-блокировочником" :)
21 фев 07, 18:57    [3818406]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
мнение
Guest
не важно
softwarer
мнение
То что эти понятия (рестарт и read consistency)
находятся в тесной связи, у меня сомнений не вызывает.

Прошу прощения, уезжаю, отвечу через пару часов. Пока ограничусь констатацией того, что зря "не вызывает".
Следует отметить, что здесь "мнение" право. Не было бы read consistency - не было бы и write consistency. тобы понять это, достаточно схоить по вышеуказанной ссылке и внимательно почитать. Также стоит отметить, что частично "мнение" не право, так как "рестарты" в Oracle контролируемы, правда для этого его придется делать "супер-блокировочником" :)



Супер блокировочники имеют уровни изоляции

dirty read
read commited
repeatable read
serializable

привильное их использование позволяет не делать рестартов и не грузить систему вовсе,
а просто ждать.
Что на 1000 комитах в секунду очень немаловажно.

Это было причиной ввести пункт 3 ( о поддержке сервером максимального количества уровней изоляции) в рекомендацию.


с уважением, мнение
21 фев 07, 19:26    [3818537]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
мнение
Guest
мнение



Супер блокировочники имеют уровни изоляции

dirty read
read commited
repeatable read
serializable

привильное их использование позволяет не делать рестартов и не грузить систему вовсе,
а просто ждать.


Что на 1000 комитах в секунду очень немаловажно.

Это было причиной ввести пункт 3 ( о поддержке сервером максимального количества уровней изоляции) в рекомендацию.


с уважением, мнение


Дабы упредить последующие нападки со стороны религиозных фанатиков
выделенный текст следует читать :

автор

привильное их использование позволяет не делать рестартов и не грузить систему вовсе,
а просто ждать на блокировке, установленной на необходимом для поддеражания логической целостности уровне изоляции.
21 фев 07, 19:55    [3818642]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
мнение
привильное их использование позволяет не делать рестартов и не грузить систему вовсе, а просто ждать на блокировке, установленной на необходимом для поддеражания логической целостности уровне изоляции.

Такое впечатление, что у вас сложилось чрезмерно негативное мнение о реальном влиянии мини-откатов на общую производительность системы.
Там, где блокировочник будет просто долго ждать, оракл с мини-откатами освободится быстрее от очереди. Обратите внимание на примеры в статье Сергея Маркеленкова - первой была длинная транзакция, потом было несколько конкурирующих с ней коротких. Короткие отработали первыми (без задержек), длинная транзакция ждала.
В классическом блокировочнике (которому вы так безрассудно преданы) все бы ждали выполнения длинной транзакции, только позавершению оной прошли бы те мелкие.
Так проще? Да. Вот только быстрее ли?
21 фев 07, 20:36    [3818751]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
мнение
Guest
Anton Demidov
мнение
привильное их использование позволяет не делать рестартов и не грузить систему вовсе, а просто ждать на блокировке, установленной на необходимом для поддеражания логической целостности уровне изоляции.

Такое впечатление, что у вас сложилось чрезмерно негативное мнение о реальном влиянии мини-откатов на общую производительность системы.
Там, где блокировочник будет просто долго ждать, оракл с мини-откатами освободится быстрее от очереди. Обратите внимание на примеры в статье Сергея Маркеленкова - первой была длинная транзакция, потом было несколько конкурирующих с ней коротких. Короткие отработали первыми (без задержек), длинная транзакция ждала.
В классическом блокировочнике (которому вы так безрассудно преданы) все бы ждали выполнения длинной транзакции, только позавершению оной прошли бы те мелкие.
Так проще? Да. Вот только быстрее ли?


В чем вы меня пытаетесь убедить?
В том что Oracle в принципе удобнее, не спорю удобнее.

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

Если говорить о длинных транзакциях вообще можете затронуть еще более веселую тему
(Заметьте не я это начал).
Консистентность на уровне транзакции, а не отдельного стейтмента.
И получите тот же супер-блокировочник снова, с одним уровнем изоляции serializable.
А потом начнутся доказательства того что dbms_lock лучше всех уровней изоляции вместе взятых.

Но это уже без меня.


з.ы. Со всеобщего позволения откланяюсь, дабы не розводить флейм , как просил автор топика.

с уважением, мнение.

з.ы.ы Похоже любое мнение является глупым , если оно не соответствует мнению пользователей Oracle.
21 фев 07, 21:41    [3818915]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Yo.!
Guest
мнение


з.ы.ы Похоже любое мнение является глупым , если оно не соответствует мнению пользователей Oracle.

нее, не любое, пока только конкретное, до которого так и не дошло, что миниоткат это фича не связаная ни с версиониоником ни с уровнями изолированости, а только с наличием/отсутсвием предикатных блокировок.
да, а про читающий update, спасибо, такой глубокой мысли от такого мнения не ожидал - записал и поставил в рамочку рядом с эскалацией обеспечивающей целостность
21 фев 07, 22:38    [3819073]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
мнение
Guest
Yo.!
мнение


з.ы.ы Похоже любое мнение является глупым , если оно не соответствует мнению пользователей Oracle.

нее, не любое, пока только конкретное, до которого так и не дошло, что миниоткат это фича не связаная ни с версиониоником ни с уровнями изолированости, а только с наличием/отсутсвием предикатных блокировок.


Похоже у Вас абсолютные проблемы с причинно следственной логикой.

С вашим стилем общения у меня нет ни малейшего желания высказывать какое либо мнение
и коментировать Ваш бред.
22 фев 07, 12:02    [3821331]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
мнение
Похоже что кроме заголовка Вы ничего осилили:

Эта Ваша фраза и использованное Вами выделение убедили меня, что моей изначальной фразы (про связь read consistency и подзапросов) Вы просто не поняли. Ситуация упрощается, в частности, я убедился, что Ваше высказывание о передергивании вызвано исключительно недостаточным знанием.

не важно
Следует отметить, что здесь "мнение" право. Не было бы read consistency - не было бы и write consistency.

Read consistency и write consistency - разные понятия. Чтобы проиллюстрировать это, достаточно вспомнить тот факт, что в блокировочнике выполнение select на уровне read committed не обеспечивает read consistency, однако этот режим активно используется и при адекватном подходе не разрушает базу (что было бы неизбежно при нарушении write consistency).

Разумеется, это связанные понятия - так же, как связаны вообще любые частные концепции в рамках одной реализации, одного решения общей задачи. Мини-откаты обеспечивают write consistency, однако с read consistency они связаны не более, чем с какой-либо другой из основных концепций.
22 фев 07, 12:23    [3821492]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Yo.!
Guest
мнение

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

OK, слив засчитан.
22 фев 07, 12:24    [3821502]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
мнение
Guest
softwarer
мнение
Похоже что кроме заголовка Вы ничего осилили:

Эта Ваша фраза и использованное Вами выделение убедили меня, что моей изначальной фразы (про связь read consistency и подзапросов) Вы просто не поняли. Ситуация упрощается, в частности, я убедился, что Ваше высказывание о передергивании вызвано исключительно недостаточным знанием.

не важно
Следует отметить, что здесь "мнение" право. Не было бы read consistency - не было бы и write consistency.

Read consistency и write consistency - разные понятия. Чтобы проиллюстрировать это, достаточно вспомнить тот факт, что в блокировочнике выполнение select на уровне read committed не обеспечивает read consistency, однако этот режим активно используется и при адекватном подходе не разрушает базу (что было бы неизбежно при нарушении write consistency).

Разумеется, это связанные понятия - так же, как связаны вообще любые частные концепции в рамках одной реализации, одного решения общей задачи. Мини-откаты обеспечивают write consistency, однако с read consistency они связаны не более, чем с какой-либо другой из основных концепций.


Я пытался взлянуть на проблему более глобально,
с точки зрения целостности данных в соответсвии с требованиями для бизнес задачи.
И ограничениях платформы которую выбирают на старте проекта исходя из перспектив
развития и использования продукта.

Какими методами это достигается, зависит СУБД. Каждая имеет свои достоинства и недостатки.
Идеальных нет.

Если бы в требованиях не стояло 1000 транзакций в секунду, я бы остановился на oracle,
Без всяких намеков.

Давайте закончим это обсуждение.
22 фев 07, 12:42    [3821707]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Yo.!
Guest
похоже прийдется мнению уйти непонятым :) для того чтоб нарватся на миниоткат нужно найти кривое приложение в котором конкурентные транзакции бы модифицировали предикаты, в то время как задача проста как пробка - блокируется аукцион, после чего ставится ставка, т.е. версионику с головой хватит read commited, а вот блокировочнику read commited без хинтов нарушит целостность
22 фев 07, 13:04    [3821908]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
Yo.!
для того чтоб нарватся на миниоткат нужно найти кривое приложение в котором конкурентные транзакции бы модифицировали предикаты

Это я упоминал выше - учитывая, что апдейты в такой задаче в 99% случаев идут по первичному ключу, шансов мягко говоря немного.

Yo.!
, в то время как задача проста как пробка - блокируется аукцион, после чего ставится ставка

Я не уверен в том, что это хорошее решение. Такой дизайн сводит систему к блокировочнику и приводит к предсказуемой проблеме масштабируемости (что будет, если 10'000 человек одновременно попытаются сделать ставку на некую очень популярную хрень?) Возможно, такого ажиотажа не будет - не знаю предметную область, не готов судить - но вполне возможно, лучшим решением будет убрать это бутылочное горлышко, сделать ставки развязкой между лотами и покупателями.
22 фев 07, 13:30    [3822175]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
мнение
Я пытался взлянуть на проблему более глобально,

Не возражаю. Но хотел бы объяснить, как выглядит то, что Вы делали.

Первое: я нисколько не собираюсь "проталкивать" Oracle для этой задачи. Я могу обсудить со специалистами других направлений преимущества-недостатки конкретных деталей, но не считаю себя достаточно компетентным, чтобы выносить экспертную оценку типа "именно Oracle подойдет лучше других". Соответственно, Ваши легкие намеки в эту сторону выглядят... приписыванием.

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

Третье: Вы довольно долго прятались и до сих пор прячетесь за общими словами. Скажем, "попытка взглянуть на проблему более глобально" звучит достойно, но обоснованием для "ошибок в деталях" не является. Если не хотите думать о деталях - так и не говорите о них. Если же без них система взглядов разваливается - таки о них надо думать.

Четвертое: в последнем письме Вы фактически свели итог к следующему: "Я хотел как лучше, а что сказал чушь, так это фигня, все равно в главном я наверняка прав, но давайте не будем ковырять, а то окажется что и там не все гладко".

В общем, получилось к сожалению "как всегда".
22 фев 07, 13:44    [3822310]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Yo.!
Guest
softwarer

Это я упоминал выше - учитывая, что апдейты в такой задаче в 99% случаев идут по первичному ключу, шансов мягко говоря немного.

почему 99 ? на мой взгляд там может быть только один update - обновление победителя и выигрывающей ставки в аукционе (лоте), конечно же по первичному, т.е. шансов не просто мало их просто нет.

softwarer

Я не уверен в том, что это хорошее решение. Такой дизайн сводит систему к блокировочнику и приводит к предсказуемой проблеме масштабируемости (что будет, если 10'000 человек одновременно попытаются сделать ставку на некую очень популярную хрень?) Возможно, такого ажиотажа не будет - не знаю предметную область, не готов судить - но вполне возможно, лучшим решением будет убрать это бутылочное горлышко, сделать ставки развязкой между лотами и покупателями.

не, конечно всю таблицу блокировать глупо - аукцион у меня синоним лота :) конечно достаточно заблокировать один лот на время транзакции ставки. а вот 10К для блокировочника будет тяжко, особдиво mssql который из-за эскалации начнет лочить все лоты, т.к. эскалировать до страницы не умеет.
22 фев 07, 13:48    [3822346]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Yo.!
а вот 10К для блокировочника будет тяжко, особдиво mssql который из-за эскалации начнет лочить все лоты, т.к. эскалировать до страницы не умеет


Зато он может совсем не эскалировать.
22 фев 07, 13:56    [3822433]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Yo.!
Guest
pkarklin


Зато он может совсем не эскалировать.

может, но станет еще хуже, т.к. будет вынужден юлозить по громадному списку локов в памяти и то при условии, что памяти на такой список хватит. правда, это скорее свойтсво lock менеджера чем версионник/блокировочник.
22 фев 07, 14:04    [3822502]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Yo.!
может, но станет еще хуже, т.к. будет вынужден юлозить по громадному списку локов в памяти и то при условии, что памяти на такой список хватит. правда, это скорее свойтсво lock менеджера чем версионник/блокировочник.


Скажем так. Имеется недокументированная возможностью "отключить" эскалацию не только для всего сервера, но и для определенных "сильно нагруженных" таблиц. Насчет хуже\лучше - памяти можно и добавить. ;)
22 фев 07, 14:09    [3822548]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить