Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5   вперед  Ctrl      все
 Re: Выбор СУБД  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67464
Блог
Yo.!
не, конечно всю таблицу блокировать глупо - аукцион у меня синоним лота :)

Поэтому я и отвечаю для лота. Для "всемирного аукциона" даже блокировка лота может стать существенной неприятностью; лучше дать людям insert-ить биды или апдейтить каждому свой бид.
22 фев 07, 14:29    [3822734]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Yo.!
Guest
softwarer
Yo.!
не, конечно всю таблицу блокировать глупо - аукцион у меня синоним лота :)

Поэтому я и отвечаю для лота. Для "всемирного аукциона" даже блокировка лота может стать существенной неприятностью; лучше дать людям insert-ить биды или апдейтить каждому свой бид.

а как тогда показывать актульного победителя и его ставку гораздо большему числу читателей ? вычислять каждый раз имхо несоизмеримо дороже выйдет ...
22 фев 07, 14:35    [3822787]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
мнение
Guest
softwarer
мнение
Я пытался взлянуть на проблему более глобально,

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

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


Как вы заметили я не намерен протягивать ни один из брендов.
Если уж речь зашла об oracle я высказал свое видиние ситуации по этому поводу.
Экспертных заключений я не делал, я высказал возможность возникновения проблем
связанных с описанным мною выше.


softwarer

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


Аргументацию я кажется приводил.
Или вы хотели что бы я вам statspack-и выложил?

Конкретных замечаний по поводу фактов изложенных мной от Вас лично небыло.

Ни одного из моих аргументов вы не опровергили (технически).

Максимум что я от вас слышал это про Фому и Ерему
а также
softwarer

Пока ограничусь констатацией того, что зря "не вызывает".

и
softwarer

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


Привидите пожалуйста цитату из сообщения с Вашей фразой.



В подтверждение Ваших слов о моей некомпетентности прошу привести цитаты где я был не прав.
Я люблю работать над собственными ошибками.


softwarer

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


Где я допустил ошибки в деталях?

softwarer


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


Где я сказал чушь?
Цитаты , ссылки?

softwarer

В общем, получилось к сожалению "как всегда".


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

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

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


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

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


Просьба обратить внимание на слоты траназкций в oracle, и кто и что там будет
как вы выразелись елозить.
22 фев 07, 14:58    [3823000]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Yo.!
Guest
softwarer
Yo.!
а как тогда показывать актульного победителя и его ставку гораздо большему числу читателей ? вычислять каждый раз имхо несоизмеримо дороже выйдет ...

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


кешировать, сомневаюсь, да и пауза в минуту думаю не приемлимо. а наблюдал за аукционном наименьшей суммы (выигрывает кто сделал наименьшую уникальную ставку), так там все веселье начинается за минуту до конца аукциона (лота), т.е. эта минута все и решает. еще прикольно что может выйграть случайная ставка из-за того, что остальные ставки оказались неуникальны :)
там за 10 секунд один пользователь способен сделать 20 ставок, т.е. видеть актуальное инфо просто необходимо ...
22 фев 07, 15:32    [3823254]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Yo.!
Guest
хотя там кажется как раз около минуты транзакции и рассасывлись после закрытия.
22 фев 07, 15:41    [3823325]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Yo.!
Guest
мнение


Просьба обратить внимание на слоты траназкций в oracle, и кто и что там будет
как вы выразелись елозить.


о да, я обратил, и вы тоже !? правда они великолепны ?
22 фев 07, 15:49    [3823398]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67464
Блог
мнение
Аргументацию я кажется приводил.

Где, простите? Максимум того, что Вы привели, это "если попробуете последовать вот этому намеку, сможете самостоятельно подтвердите мою точку зрения".

мнение
Или вы хотели что бы я вам statspack-и выложил?

Если у Вас есть под рукой система с аналогичной нагрузкой, было бы неплохо. Особенно интересной была бы строка "потери на мини-откатах" из этого отчета :)

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

мнение
Конкретных замечаний по поводу фактов изложенных мной от Вас лично небыло.

От Вас лично не было изложено конкретных фактов. Исключительно несколько общих слов.

мнение
Ни одного из моих аргументов вы не опровергили (технически).

Технически, если Вы не в курсе, аргументы требуется сначала "обосновывать", и только после этого, может быть, "опровергать"1.

1 Аргумент - это "утверждение, выдвинутое в подтверждение другого утверждения". До тех пор, пока аргумент-утверждение не обоснован, опровергать его необходимо не более, нежели любое другое необоснованное утверждение

мнение
Максимум что я от вас слышал это про Фому и Ерему

Да и то, либо не поняли, либо не захотели понять.

мнение
а также Пока ограничусь констатацией того, что зря "не вызывает".

Если Вы вдруг пропустили при чтении часть того поста, на которое отвечаете чуть ниже в тексте, могу дать ссылку для более внимательного изучения: https://www.sql.ru/forum/actualthread.aspx?tid=397997&pg=3#3821492

мнение
softwarer
убедили меня, что моей изначальной фразы (про связь read consistency и подзапросов) Вы просто не поняли.

Привидите пожалуйста цитату из сообщения с Вашей фразой.

Да запросто. Вы сами цитировали эти слова пару страниц назад -

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


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

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

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

мнение пару страниц назад
ИХМО read consistency здесь причина, а миниоткат следствие.


Из чего явно видно непонимание механики и предназначения мини-откатов. Чтобы закончить эту ветку, поясню:

- до тех пор, пока в Oracle не было read consistency, не было и использующих на эту концепцию механизмов, в частности мини-откатов

- когда read consistency появилась, появилась возможность обеспечить write consistency путем совместного использования read consistency и мини-откатов.

мнение
Где я допустил ошибки в деталях?

Хотя бы в том же совете ловить мини-откат в указанном Вами апдейте.

мнение
Где я сказал чушь?Цитаты , ссылки?

Уже отвечено выше.
22 фев 07, 15:53    [3823434]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
мнение
Или вы хотели что бы я вам statspack-и выложил?


Выложи, а ? Все лучше чем попусту воздух сотрясать
22 фев 07, 15:54    [3823443]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67464
Блог
Yo.!
кешировать, сомневаюсь

Думаю, не имеет смысла искать истину - она зависит от постановки и условий задачи :)

Yo.!
, да и пауза в минуту думаю не приемлимо.

Хм. Я почему-то уверен, что пауза будет больше. Просто представьте себе, что Вы покупаете например картину Рембрандта, и она уходит Вашему принципиальному сопернику из-за того, что Вы уронили мышку и не смогли нажать Ok :)

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

Судя по описанию, Вы говорите о весьма специфическом случае. На нормальных аукционах afaik торгуются до максимальной цены, а не до фиксированного времени завершения торгов.
22 фев 07, 16:02    [3823525]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
DPH
Guest
Yo.!

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


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

И при таком подходе в качестве БД можно хоть MySQL использовать...
(Впрочем, я бы использовал DB2 - благо тоже бесплатно для такого класса задач, на вставках весьма оперативна и имеет кучу возможностей к росту - но это личное мнение).
22 фев 07, 16:05    [3823542]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67464
Блог
DPH
Гм, я все пытаюсь понять, как скорость проведения update (и, соотвественно, модель блокировок) связна с задачей аукциона?

Хм. В той теме, что начало мнение, связь с задачей аукциона вообще постоянно теряется. Если помните, я еще первым же своим письмом на эту тему сказал, что тезис имхо не имеет отношения именно к этой задаче :)

DPH
Там гораздо проще текущего победителя и всю локальную историю хранить и кэшировать на уровне сервера приложений (с разными очевидными стратегиями распределения нагрузки между серверами). А в БД в этом случае нужно только вставлять (без всяких блокировок) заявки игроков - да и то только в целях аудита и, при необходимости, восстановления после падения.

Я бы не стал выделять сервер приложения. Собственно я сказал насчет вставок и кэширования, а как именно делать это кэширование - имхо уже вопрос десятый.

DPH
И при таком подходе в качестве БД можно хоть MySQL использовать...

А об этом я говорил чуть ли не во втором посте этого топика :)
22 фев 07, 16:10    [3823584]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Yo.!
Guest
softwarer

Судя по описанию, Вы говорите о весьма специфическом случае. На нормальных аукционах afaik торгуются до максимальной цены, а не до фиксированного времени завершения торгов.

ну да, специфический, просто думаю автор что-то подобное имел ввиду, щас это модно да и сомневаюсь я что за "Рембранта" будет 1К конкурентных транзакций .. пока он прекрасно продается табличками :)
конечно гадать что автор имел ввиду под аукционом смысла нет, но что бы он там не имел ввиду, миниоткатам там взятся неоткуда
22 фев 07, 16:15    [3823630]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Yo.!
Guest
DPH

Там гораздо проще текущего победителя и всю локальную историю хранить и кэшировать на уровне сервера приложений (с разными очевидными стратегиями распределения нагрузки между серверами).

тут непонял, под кешом обычно понимают нечто неактуальное, которое периодически обновляется, вы похоже просто предлагаете конкурентно обновлять объект апп сервера, а не табличку ... но я не вижу разницы, в субд табличка будет в той же памяти ...
22 фев 07, 16:27    [3823738]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67464
Блог
Yo.!
сомневаюсь я что за "Рембранта" будет 1К конкурентных транзакций ..

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

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

Безусловно.
22 фев 07, 16:32    [3823771]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
Помнится когда-то давно обсуждали подобное...)
https://www.sql.ru/forum/actualthread.aspx?tid=145611&hl=%e7%e0%e4%e0%f7%e0+oracle#1179863
22 фев 07, 16:48    [3823897]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67464
Блог
Хм. Лень читать все "то" обсуждение, начало, честно говоря, не впечатлило. Чем она подобна обсуждаемой, не понимаю (возможно из-за того, что таки не прочитал те пять страниц, но есть впечатление, что подобна только упоминанием слова Oracle).
22 фев 07, 17:06    [3824027]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Yo.!
Guest
gardenman
Помнится когда-то давно обсуждали подобное...)
https://www.sql.ru/forum/actualthread.aspx?tid=145611&hl=%e7%e0%e4%e0%f7%e0+oracle#1179863

ну да, и решили, что грязное чтение в 21 юзать не серьозно ...
22 фев 07, 17:07    [3824036]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
DPH
Guest
Yo.!
DPH

Там гораздо проще текущего победителя и всю локальную историю хранить и кэшировать на уровне сервера приложений (с разными очевидными стратегиями распределения нагрузки между серверами).

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


В СУБД "изменение таблички в памяти" требует ее изменения на диске, сохранения лога транзакции, весьма недешевую проверку блокировок и т.п
Для AppServer, даже если не рассматривать асинхронные варианты persistance, все гораздо дешевле - нет блокировок, выполняется команда insert, а не update.

Я неоднократно играл с подобными схемами, выигрыш от варианта "update объекта в кэше, вставка изменения в базу" по сравнению с "update поля в базе" зачастую более чем в десять раз. Ну и, конечно, никаких блокировок (вернее, блокировка по объекту AppServer, но она очень быстрая).
22 фев 07, 17:13    [3824085]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
DPH
Guest
softwarer

Я бы не стал выделять сервер приложения. Собственно я сказал насчет вставок и кэширования, а как именно делать это кэширование - имхо уже вопрос десятый.

Гм, тут не просто кэширование, тут еще и актуально кэширование без персистанса, т.е. уже вне уровня БД.
Т.е., в общем случае, на промежуточном слое между persistance и клиентом. Это, конечно, не обязательно сервер приложений, но что же еще?
(Если Web-server реализует такое кэширование - то это уже сервер приложения, по хорошему)
22 фев 07, 17:16    [3824100]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67464
Блог
Yo.!
ну да, и решили, что грязное чтение в 21 юзать не серьозно ...

И главное - зачем грязное чтение, если задача элементарно решается путем select for update skip locked?
22 фев 07, 17:19    [3824126]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
Yo.!
gardenman
Помнится когда-то давно обсуждали подобное...)
https://www.sql.ru/forum/actualthread.aspx?tid=145611&hl=%e7%e0%e4%e0%f7%e0+oracle#1179863

ну да, и решили, что грязное чтение в 21 юзать не серьозно ...


Yo! так решил для себя...)
22 фев 07, 17:20    [3824136]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
softwarer
Yo.!
ну да, и решили, что грязное чтение в 21 юзать не серьозно ...

И главное - зачем грязное чтение, если задача элементарно решается путем select for update skip locked?

А затем, что если скипнуть лоченные записи не узнать реального положения дел в настоящий момент)) :D
22 фев 07, 17:22    [3824151]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67464
Блог
DPH
Гм, тут не просто кэширование, тут еще и актуально кэширование без персистанса, т.е. уже вне уровня БД.

Во-первых, "уже" вообще говоря не обязательно. Никто не мешает создавать объект в БД, но без персистанса.

Во-вторых, я согласен с тем, что с практической точки зрения так, как предлагаете Вы, будет вполне удобно, но тем не менее, не вижу здесь принципиальности. Можно кэшировать и в БД и с персистенсом, ничего страшного не будет (конечно, дополнительные расходы, но контролируемые и непринципиальные).
22 фев 07, 17:22    [3824157]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить