|
|
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
Есть задача написать эфективное онлайн приложение с высокой доступностью(99.99% uptime) и масштабироуемостью до 1000 (и более если возможно) обращений в секунду. Объём БД будет постоянно расти и скажем лет через 5 будет состалять 50Гб через 10лет 500Гб Суть онлайн приложения Аукцион Магазин Некоторое подобие платёжноей системы, с возможностью резервирования денег на счету платящего Ведение акаунтов пользователей некоторое подобие системы документооборота Мне нужна рекомендация на какой СУБД это будет эфективнее работать и почему. Ответы лучше подкреплять ссылками. Как водится чем меньше денег будет стоить СУБД тем лучше. Буду особо благодарен за отсутствие флейма и конструктивные предложения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.02.2007, 14:46 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
Opegприложение с высокой доступностью(99.99% uptime) и масштабироуемостью до 1000 (и более если возможно) обращений в секунду. Объём БД будет постоянно расти и скажем лет через 5 будет состалять 50Гб через 10лет 500Гб Как водится чем меньше денег будет стоить СУБД тем лучше. Uptime будет определяться железом и каналами связи. Железом же будет определяться скорость работы системы. Как пример, что примерно апргрейдил Озон в 2004 году: тынц Берем самый недорогой из нормальных серверов и читаем его примеры внедрений (есть там примеры и похожих задач): тынц Сейчас придут ораклоиды, адепты дб2, мс скл и дадут аналогичные ссылки. Что это будет доказывать? То, что на любом из серверов подобные задачи решались. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.02.2007, 16:33 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
Имхо тут стоит удариться в одну из крайностей. Если хочется думать о масштабировании и вообще о глобальном росте, гуглите на тему "на чем работают всякие amazon-ы с ebay-ями и почему". Если же оптимизироваться под цену и сегодняшнее состояние, вполне вероятно, лучшим выбором будет MySQL (если его лицензия позволит использовать его бесплатно). Почему: во-первых, на таких простых запросах он показывает отличное быстродействие, во-вторых, такие задачи легко и дешево можно масштабировать за счет shared nothing кластеризации на уровне аппсервера. При этом, разумеется, стоит понимать, что "стоимость лицензий" в этом случае в конце концов окажется выплаченной в виде зарплаты программистов, зато есть возможность с нуля написать крутую вещь, да и своим платить приятнее :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.02.2007, 16:34 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
softwarerИмхо тут стоит удариться в одну из крайностей. Если хочется думать о масштабировании и вообще о глобальном росте, гуглите на тему "на чем работают всякие amazon-ы с ebay-ями и почему". Если же оптимизироваться под цену и сегодняшнее состояние, вполне вероятно, лучшим выбором будет MySQL (если его лицензия позволит использовать его бесплатно). Почему: во-первых, на таких простых запросах он показывает отличное быстродействие, во-вторых, такие задачи легко и дешево можно масштабировать за счет shared nothing кластеризации на уровне аппсервера. При этом, разумеется, стоит понимать, что "стоимость лицензий" в этом случае в конце концов окажется выплаченной в виде зарплаты программистов, зато есть возможность с нуля написать крутую вещь, да и своим платить приятнее :) не согласен, 99%, 5-50Gb + workflow - это явно не стихия mysql. да и в аукционе не такие уж простые запросы получаются. 1-way xeon тянет 65К tpc-c транзакций, так что не думаю что есть смысл заморачиватся ему с кластеризацией субд в ближайшие годы :) к стате сейчас смотрю на IBM x3950 , вроде прикольно получается, их можно собирать в SMP частями, типа добавлять по 4 проца при необходимости, на 99% конечно не проканает но ... ЗЫ. если нужна 99% то нужен standby хотябы, а это не так много кто умеет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.02.2007, 17:46 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
OpegЕсть задача написать эфективное онлайн приложение с высокой доступностью(99.99% uptime) и масштабироуемостью до 1000 (и более если возможно) обращений в секунду. Объём БД будет постоянно расти и скажем лет через 5 будет состалять 50Гб через 10лет 500Гб Смотрим tpc.org, tpc-c тесты, и видим что вообще-то 1000 запросов в секунду не так уж и много и любая БД из тройки MSSQL/DB2/Oracle это тянет. 99.99% доступность (полчаса простоя в год) - на MS SQL обеспечить можно - но это требует соответствующего подхода к проектированию приложения и к проектированию развертывания приложения/применения хотфиксов. У нас 1000 запросов в секунду нет, есть 700 в секунду при 1500 одновременных пользователях. Приложение 24x6, в течение этих шести дней в неделю 99.99% выдерживается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.02.2007, 18:04 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
Прошу обратить внимание на одну маленькую деталь, я использовал слово обращение а не запрос. Сколько запросов будет в обращении?- может 15, может 60. Думаю сложно сказать при наличии ТЗ, а без его наличия практически невозможно. А мне нужны цыфры для БП, можно ли для этого использовать что-то из опенсорса или нужен оракл или дб2. Судя по цифрам которые я нарыл в инете соответствующий аптайм можно получить только при помощи кластеризации. Причём как я понял нужна кластеризация мульти-мастер. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.02.2007, 18:32 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
OpegСудя по цифрам которые я нарыл в инете соответствующий аптайм можно получить только при помощи кластеризации. Причём как я понял нужна кластеризация мульти-мастер. Чет я не понял... Тебе деньги пристроить или работать?... Если первое - хлястер на 2, а потом каженный год + 2 сервера. Ни и ПО Ораклю и не парится... Если второе: 1. Где сейчас база и где ты через 10 лет?.. 2. Начинай с чего знаешь, ту БД и ставь. Потом все равно 5 раз переделывать... 3. По желеу - уже высказались. Как-така Аптайма 99,99%??? Чего в сервер-то смотреть, если искричества нету? Ты прикинь, что это даже собственная дизель-генераторная НЕ дает!... По армеским нормам при 100% ГОРЧЕМ резерве. Наличии 200% холодного резерва. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.02.2007, 18:54 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
OpegПрошу обратить внимание на одну маленькую деталь, я использовал слово обращение а не запрос. Сколько запросов будет в обращении?- может 15, может 60. Думаю сложно сказать при наличии ТЗ, а без его наличия практически невозможно. А мне нужны цыфры для БП, можно ли для этого использовать что-то из опенсорса или нужен оракл или дб2. 700 запросов о которых я писал - это вызовы хранимых процедур, со размером от 2 до 25кб, с транзакциями и т.п, со значительной бизнес логикой помимо операций над данными. Opeg Судя по цифрам которые я нарыл в инете соответствующий аптайм можно получить только при помощи кластеризации. Причём как я понял нужна кластеризация мульти-мастер. Кластер необходим. Что такое мультимастер не знаю. Если под этим подразумевается RAC - не знаю чем он лучше safeguard в плане обеспечения доступности. Главное в обеспечении доступности - разработка с учетом требований к доступности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.02.2007, 19:34 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
Di_LIne Как-така Аптайма 99,99%??? Чего в сервер-то смотреть, если искричества нету? 8 На это мне расказали об оптическом кольце, и площадках разнесённых на 20 км с независимым питанием, и пулемётчиках за колючей проволокой по периметру :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.02.2007, 19:39 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
Ап_Тайму 99,9% я дам только на... кулер CPU. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.02.2007, 19:53 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
Еще в тему по амазону и по е-баю . Наверное два самых больших в мире инет-магазина. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2007, 06:25 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
> онлайн приложение с высокой доступностью(99.99% uptime) У stack.net (это далеко не самый последний дата-центр в России), например, гарантированный uptime каналов порядка 99,95%. Вы понимаете, что четыре девятки - это дорогое удовольствие? > и масштабироуемостью до 1000 (и более если возможно) обращений в секунду. По сравнению с доступностью это так себе задача. > Объём БД будет постоянно расти и скажем лет через 5 будет состалять 50Гб через 10лет 500Гб Вряд ли понадобится 500 Гб оперативных данных. > Мне нужна рекомендация на какой СУБД это будет эфективнее работать и почему. Два варианта: либо снижайте требования к доступности, либо идите к интегратору, рисуйте схему приложения и формулируйте требования к СУБД нормальным образом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2007, 09:10 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
1000 обращений в секунду? Назовите мне широко известный _российский_ web-портал с таким количеством обращений в секунду. А особенно какой-нибудь аукцион, или магазин. и чтобы не растопыривать пальцы :-) советую сравнить эту 1000 обращений с числом заходов на anekdot.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2007, 09:46 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
Проект даже не предназначен для России, в России он будет не жизнеспособен ещё очень долго. Если придёт в Россию, то лет через 10 не раньше. По поводу интеграторов, посоветуйте плиз ведущих, лучших, и наиболее рациональных с вашей точки зрения. Также неплохо бы перечислить параметры, по чему их рекомендуете. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2007, 10:10 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
ну не для России, фиг с ней. Пользователей сколько в системе будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2007, 10:54 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
kdv1000 обращений в секунду? Назовите мне широко известный _российский_ web-портал с таким количеством обращений в секунду. - ЯНДЕКС со всеми сервисами. Потянет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2007, 11:09 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
Предположительно Черезполгода после реализации около 300 в день, при этом около 100 из них будет находиться в онлайн в течении рабочего дня, регулярно обращайсь к сайту (возможно это будет AJAX). Остальные 200 это люди периодически обращающиеся ~раз в 15 минут пользователей которые просто заходят и уходят я несчитаю тк они практически не создают нагрузки хотя их может быть ещё 1000-5000 за 5 лет эксплуатации предполагаю увеличение до тех что 300 до 5000, тех что 1000 до 40000-80000 думаю всё будет не так, но это то из чего я пока исхожу при расчётах, возможно мои колеги подойдут по позже и меня существенно по правят. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2007, 11:14 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
а можно спросить что это такое? хотя бы из какой области? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2007, 11:38 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
> По поводу интеграторов, посоветуйте плиз ведущих, лучших, и наиболее рациональных > с вашей точки зрения. > Также неплохо бы перечислить параметры, по чему их рекомендуете. Это называется консалтинг и стоит денег. P.S. У меня стойкое убеждение, что Вы занимаетесь не своим делом. Ничего личного. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2007, 13:50 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
OpegПредположительно Черезполгода после реализации около 300 в день, при этом около 100 из них будет находиться в онлайн в течении рабочего дня, регулярно обращайсь к сайту (возможно это будет AJAX). Остальные 200 это люди периодически обращающиеся ~раз в 15 минут пользователей которые просто заходят и уходят я несчитаю тк они практически не создают нагрузки хотя их может быть ещё 1000-5000 за 5 лет эксплуатации предполагаю увеличение до тех что 300 до 5000, тех что 1000 до 40000-80000 думаю всё будет не так, но это то из чего я пока исхожу при расчётах, возможно мои колеги подойдут по позже и меня существенно по правят. ИМХО Глобальные критерии выбора СУБД в порядке убывания приоритета исходя из 1000 операций ( транзакций , запросов) в сек и доступности 99.99%: 1. Возможность иметь горячий standby. И архиваровать логические журналы. 2. Поддержака кластерной конфигурации. 3. Поддержка максимально возможного количества уровней изоляции. Чем выше будет конкуренция ( на изменение) за данные между сессиями , тем быстрее вы этот пункт оцените. 3. Поддержка репликации таблиц ( опреративная история должна быть короткой). Или другой простой механизм переноса данных с OLTP в DWH. Нет сейчас железа способного обрабатывать и одновременно хранить историю по 1000 операций в секунду за 5 лет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2007, 15:28 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
guest_20040621> По поводу интеграторов, посоветуйте плиз ведущих, лучших, и наиболее рациональных > с вашей точки зрения. > Также неплохо бы перечислить параметры, по чему их рекомендуете. Это называется консалтинг и стоит денег. P.S. У меня стойкое убеждение, что Вы занимаетесь не своим делом. Ничего личного. :) Что же тогда моё дело, если не разобраться на рынке и выбрать оптимальное решение. Если бы это было моё дело, я бы наверное уже написал приложение, и не задавал глупых вопросов. зы: Это называется не консалтинг, а изучение рынка, что по сути маркетинговое исследование imho ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.02.2007, 19:00 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
Opeg Это называется не консалтинг, а изучение рынка, что по сути маркетинговое исследование imho - А чё? Я сам путаю: - Где левое, а где низ.... Или где у меня Front- и End-сервера... сегодня. - Правда, ДокОлл? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.02.2007, 20:51 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
Di_LIne Opeg Это называется не консалтинг, а изучение рынка, что по сути маркетинговое исследование imho - А чё? Я сам путаю: - Где левое, а где низ.... Или где у меня Front- и End-сервера... сегодня. - Правда, ДокОлл? Главное - мягкое с тёплым не путай :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.02.2007, 23:46 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
ИзопропилГлавное - мягкое с тёплым не путай :) Был б Кат2, я б каментов наделал. Не только Изо, но и бутыль б пропили. А сейсас - воздержусь... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 03:02 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
мнение OpegПредположительно Черезполгода после реализации около 300 в день, при этом около 100 из них будет находиться в онлайн в течении рабочего дня, регулярно обращайсь к сайту (возможно это будет AJAX). Остальные 200 это люди периодически обращающиеся ~раз в 15 минут пользователей которые просто заходят и уходят я несчитаю тк они практически не создают нагрузки хотя их может быть ещё 1000-5000 за 5 лет эксплуатации предполагаю увеличение до тех что 300 до 5000, тех что 1000 до 40000-80000 думаю всё будет не так, но это то из чего я пока исхожу при расчётах, возможно мои колеги подойдут по позже и меня существенно по правят. ИМХО Глобальные критерии выбора СУБД в порядке убывания приоритета исходя из 1000 операций ( транзакций , запросов) в сек и доступности 99.99%: 1. Возможность иметь горячий standby. И архиваровать логические журналы. 2. Поддержака кластерной конфигурации. 3. Поддержка максимально возможного количества уровней изоляции. Чем выше будет конкуренция ( на изменение) за данные между сессиями , тем быстрее вы этот пункт оцените. 3. Поддержка репликации таблиц ( опреративная история должна быть короткой). Или другой простой механизм переноса данных с OLTP в DWH. Нет сейчас железа способного обрабатывать и одновременно хранить историю по 1000 операций в секунду за 5 лет. С такими требованиями выбор сужается до одной СУБД :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 08:46 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
10046 wrote: > С такими требованиями выбор сужается до одной СУБД :) Грязная провокация. Независимо от СУБД Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 12:52 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
locky 10046 wrote: > С такими требованиями выбор сужается до одной СУБД :) Грязная провокация. Независимо от СУБД Posted via ActualForum NNTP Server 1.4 а что standby от MS уже научился без востановления подниматся или попрежнему нужно ручками юзеров востанавливать ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 13:03 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
10046 С такими требованиями выбор сужается до одной СУБД :) До 2-х. To Yo.! : Oracle среди них нет. Он по третьему пункту не укладывается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 14:22 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
мнение To Yo.! : Oracle среди них нет. Он по третьему пункту не укладывается. глупое мнение :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 14:31 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
мнениеОн по третьему пункту не укладывается. Для начала стоило бы уточнить, какой именно из третьих пунктов Вы имеете в виду. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 14:39 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
softwarer мнениеОн по третьему пункту не укладывается. Для начала стоило бы уточнить, какой именно из третьих пунктов Вы имеете в виду. мнение 3. Поддержка максимально возможного количества уровней изоляции. Чем выше будет конкуренция ( на изменение) за данные между сессиями , тем быстрее вы этот пункт оцените. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 14:41 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
Конечно же это гораздо умнее и конструктивнее : Yo.! а что standby от MS уже научился без востановления подниматся или попрежнему нужно ручками юзеров востанавливать ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 14:44 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
Yoа что standby от MS уже научился без востановления подниматся или попрежнему нужно ручками юзеров востанавливать ? Если использовать новый ADO .Net провайдер для MSSQL - то там такая возможность встроена. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 14:48 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
Что же касается именно этой задачи, то признаться, вообще не понял, зачем этот пункт упомянут. В дизайне БД, вполне вероятно, придется учесть высокую конкуренцию, чтобы лихорадочный бидвар не стал бутылочным горлышком, но и все; я не вижу тут задач риалтаймовой отчетности или подобных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 14:49 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
softwarer я не вижу тут задач риалтаймовой отчетности или подобных. Мнение совпало, любой версионник для этой задачи не лучший выбор. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 14:53 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
мнение Мнение совпало, любой версионник для этой задачи не лучший выбор. я ж говорю: глупое мнение :) как раз у блокировочника нет вариантов кроме как serializable, что при таком кол-ве читателей завалит дедлоками, эскалациями и прочими прелестями блокировочников. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 15:02 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
Yo.! мнение Мнение совпало, любой версионник для этой задачи не лучший выбор. я ж говорю: глупое мнение :) как раз у блокировочника нет вариантов кроме как serializable, что при таком кол-ве читателей завалит дедлоками, эскалациями и прочими прелестями блокировочников. Коментировать этот бред нет никакого желания. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 15:06 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
По теме. Блокировочник должен уметь ставить блокировку на строку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 15:06 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
мнениеПо теме. Блокировочник должен уметь ставить блокировку на строку. А эскалацию блокировок он должен уметь делать? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 15:11 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
10046 мнениеПо теме. Блокировочник должен уметь ставить блокировку на строку. А эскалацию блокировок он должен уметь делать? :) Должен, для поддержания логической целостности данных на выбранном уровне изоляции. По сравнению неконтролируемыми рестартами стейтментов , эскалация блокировок на 1000 комитов в секунду вам покажется легкой прогулкой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 15:16 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
мнение Должен, для поддержания логической целостности данных на выбранном уровне изоляции. эскалация для поддержания целостности буга-га, держите меня семеро :) мнение По сравнению неконтролируемыми рестартами стейтментов , эскалация блокировок на 1000 комитов в секунду вам покажется легкой прогулкой. чую это очередной шедевр, но боюсь пока недоступный для понимания широкой обществености :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 15:22 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
Yo.! мнение Должен, для поддержания логической целостности данных на выбранном уровне изоляции. эскалация для поддержания целостности буга-га, держите меня семеро :) Видимо у человека понятие эскалации асоциируется только с СУБД не умеющими устанавливать блокировки на уровне строки. Я уже держу , падайте :) Yo.! [quot мнение] По сравнению неконтролируемыми рестартами стейтментов , эскалация блокировок на 1000 комитов в секунду вам покажется легкой прогулкой. чую это очередной шедевр, но боюсь пока недоступный для понимания широкой обществености :) Поделитесь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 15:31 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
мнение 10046 мнениеПо теме. Блокировочник должен уметь ставить блокировку на строку. А эскалацию блокировок он должен уметь делать? :) Должен, для поддержания логической целостности данных на выбранном уровне изоляции. По сравнению неконтролируемыми рестартами стейтментов , эскалация блокировок на 1000 комитов в секунду вам покажется легкой прогулкой. Хм... честно говоря, не совсем понял вас. Если вас не затруднит, не могли бы вы поподробнее пояснить, и заодно уж почему версионник здесь не катит? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 15:32 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
мнениеМнение совпало, любой версионник для этой задачи не лучший выбор. C кем Вы совпали, я не знаю, но не со мной. Имхо этой задаче глубоко и принципиально пофиг, версионник там или блокировочник. Ну а высказанный пункт, повторюсь, к задаче отношения не имеет (точнее, я этого отношения не вижу, готов выслушать обоснование). мнениеПо сравнению неконтролируемыми рестартами стейтментов Кстати, было бы любопытно увидеть пример "неконтролируемого рестарта стейтментов" для операции апдейта одной записи (наиболее типичной для данной задачи). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 15:37 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
мнение Поделитесь. я бы с радостью, но пока сам теряюсь в догадках :) с эскалацией тут ясно, тут мнение невьехало даже чо это, а вот что такое "рестартами стейтментов" пока есть только догадка, это мнение слышала звон (именуемым миниоткатом) и как-то его связалло с комитами. было бы весело узнать поподробней об этом чудном явлении именно от вас, мнение :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 15:38 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
10046 мнение 10046 мнениеПо теме. Блокировочник должен уметь ставить блокировку на строку. А эскалацию блокировок он должен уметь делать? :) Должен, для поддержания логической целостности данных на выбранном уровне изоляции. По сравнению неконтролируемыми рестартами стейтментов , эскалация блокировок на 1000 комитов в секунду вам покажется легкой прогулкой. Хм... честно говоря, не совсем понял вас. Если вас не затруднит, не могли бы вы поподробнее пояснить, и заодно уж почему версионник здесь не катит? Долго обьяснять, и обычно все это заканчивается заявлениями типа "Глупое мнение". Наводку я уже дал, это количество поддерживаемых уровней изоляции. И поддержка блокировки на уровне строки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 15:40 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
softwarer мнениеМнение совпало, любой версионник для этой задачи не лучший выбор. C кем Вы совпали, я не знаю, но не со мной. Имхо этой задаче глубоко и принципиально пофиг, версионник там или блокировочник. Ну а высказанный пункт, повторюсь, к задаче отношения не имеет (точнее, я этого отношения не вижу, готов выслушать обоснование). мнениеПо сравнению неконтролируемыми рестартами стейтментов Кстати, было бы любопытно увидеть пример "неконтролируемого рестарта стейтментов" для операции апдейта одной записи (наиболее типичной для данной задачи). Рестарты ловите здесь : Код: plaintext 1. 2. 3. Сколько там обычно записей изменяется для данной задачи смоделируйте в where ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 15:58 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
softwarer C кем Вы совпали, я не знаю, но не со мной. Имхо этой задаче глубоко и принципиально пофиг, версионник там или блокировочник. Ну а высказанный пункт, повторюсь, к задаче отношения не имеет (точнее, я этого отношения не вижу, готов выслушать обоснование). мнение Рестарты ловите здесь : Код: plaintext 1. 2. 3. Сколько там обычно записей изменяется для данной задачи смоделируйте в where В качестве обоснования попробуйте этот пример на серверах поддерживающих не только RC & SERIALIZABLE. Сравните типы блокировок устанавливаемые на строки для разный уровней изоляции и целостность данных в соответствии с задачей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 16:22 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
мнениеРестарты ловите здесь : Имхо если не создавать ненормальных условий, не поймаю. Что я имею в виду под ненормальными условиями: например, изменение первичного ключа записи апдейтом в другом сеансе. Упоминание подзапроса здесь имхо не совсем к месту. Если это существенная часть Ваших рассуждений, подозреваю, Вы хотели рассказать не о мини-откатах, а о специфике read consistency в этом случае. мнениеВ качестве обоснования попробуйте этот пример на серверах поддерживающих не только RC & SERIALIZABLE. Сравните типы блокировок устанавливаемые на строки для разный уровней изоляции и целостность данных в соответствии с задачей. Ага, похоже на то, что начали про Фому, закончили про Ерему. В общем, суть получается такой: версионник плох тем, что в некоторых случаях ведет себя так же, как блокировочник ведет себя всегда :)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 16:36 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
мнение До 2-х. А вторая - это какая? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 16:37 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
объявляю кокурс кто догадается, что за звон с "неконтролируемого рестарта стейтментов" улсышало мнение может это он оракл с interbase и его cursor stabilty путает ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 16:45 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
softwarer Упоминание подзапроса здесь имхо не совсем к месту. Если это существенная часть Ваших рассуждений, подозреваю, Вы хотели рассказать не о мини-откатах, а о специфике read consistency в этом случае. И от том и о другом. Мне кажется вы передергиваете. ( Уверен, что понимаете о чем идет речь). А речь в следующем: ИХМО read consistency здесь причина, а миниоткат следствие. Нельзя разделять эти вещи с точки зрения подержки цеслостности данных. Мною были упомянуты следствия, вы указали на причины. Все логично. softwarer В общем, суть получается такой: версионник плох тем, что в некоторых случаях ведет себя так же, как блокировочник ведет себя всегда :)) Не буду спорить с авторитетом сайта. Пусть будет по Вашему. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 16:54 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
афтар жжет я с него балдею. открою страшную тайну - версионный MSSQL при isolation level snapshot, имеет предикатные блокировки и не имеет миниотката, ужос да ? и, мнение, потеште нас, расскажите все же что за связь вы нашли у этого update и миниоткатом ? там достаточно одного такого update да :) ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 17:06 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
мнениеМне кажется вы передергиваете. ( Уверен, что понимаете о чем идет речь). Нет, не понимаю. Зато заинтригован и хотел бы увидеть разъяснение, в чем именно я некорректен. мнениеА речь в следующем: ИХМО read consistency здесь причина, а миниоткат следствие. Нельзя разделять эти вещи с точки зрения подержки цеслостности данных. Мною были упомянуты следствия, вы указали на причины. Все логично. Вы говорите весьма общими словами, что создает весьма широкое поле для возможных трактовок. Скажу так: по состоянию на настоящий момент то, что и как Вы сказали, создает впечатление того, что Вы... не знакомы с обсуждаемой механикой достаточно, чтобы обсуждать ее опасность для этой задачи. В свою очередь, я не знаю эту область настолько досконально, чтобы отрицать возможность некоторых неведомых мне опасностей, но если Вы - ловко замаскировавшийся гуру, Ваши намеки оказались слишком тонкими. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 17:09 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
softwarer мнениеМне кажется вы передергиваете. ( Уверен, что понимаете о чем идет речь). Нет, не понимаю. Зато заинтригован и хотел бы увидеть разъяснение, в чем именно я некорректен. softwarer Упоминание подзапроса здесь имхо не совсем к месту. Если это существенная часть Ваших рассуждений, подозреваю, Вы хотели рассказать не о мини-откатах, а о специфике read consistency в этом случае. мнение И от том и о другом. а именно : мнение ИХМО read consistency здесь причина, а миниоткат следствие. Нельзя разделять эти вещи с точки зрения подержки цеслостности данных. Мною были упомянуты следствия, вы указали на причины. Все логично. То что эти понятия (рестарт и read consistency) находятся в тесной связи, у меня сомнений не вызывает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 17:50 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
мнение То что эти понятия (рестарт и read consistency) находятся в тесной связи, у меня сомнений не вызывает. я понимаю, что тему мнение не осилило :) но ниосилить даже заголовок - это круто http://www.oracle.com/global/ru/oramag/dec2006/images/write_consistency.zip]Алгоритм “мини-откатов” в Oracle или еще раз о Write Consistency ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 18:02 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
мнениеТо что эти понятия (рестарт и read consistency) находятся в тесной связи, у меня сомнений не вызывает. Прошу прощения, уезжаю, отвечу через пару часов. Пока ограничусь констатацией того, что зря "не вызывает". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 18:09 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
Yo.! мнение То что эти понятия (рестарт и read consistency) находятся в тесной связи, у меня сомнений не вызывает. я понимаю, что тему мнение не осилило :) но ниосилить даже заголовок - это круто http://www.oracle.com/global/ru/oramag/dec2006/images/write_consistency.zip]Алгоритм “мини-откатов” в 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.02.2007, 18:42 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
softwarer мнениеТо что эти понятия (рестарт и read consistency) находятся в тесной связи, у меня сомнений не вызывает. Прошу прощения, уезжаю, отвечу через пару часов. Пока ограничусь констатацией того, что зря "не вызывает".Следует отметить, что здесь "мнение" право. Не было бы read consistency - не было бы и write consistency. тобы понять это, достаточно схоить по вышеуказанной ссылке и внимательно почитать. Также стоит отметить, что частично "мнение" не право, так как "рестарты" в Oracle контролируемы, правда для этого его придется делать "супер-блокировочником" :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 18:57 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
не важно softwarer мнениеТо что эти понятия (рестарт и read consistency) находятся в тесной связи, у меня сомнений не вызывает. Прошу прощения, уезжаю, отвечу через пару часов. Пока ограничусь констатацией того, что зря "не вызывает".Следует отметить, что здесь "мнение" право. Не было бы read consistency - не было бы и write consistency. тобы понять это, достаточно схоить по вышеуказанной ссылке и внимательно почитать. Также стоит отметить, что частично "мнение" не право, так как "рестарты" в Oracle контролируемы, правда для этого его придется делать "супер-блокировочником" :) Супер блокировочники имеют уровни изоляции dirty read read commited repeatable read serializable привильное их использование позволяет не делать рестартов и не грузить систему вовсе, а просто ждать. Что на 1000 комитах в секунду очень немаловажно. Это было причиной ввести пункт 3 ( о поддержке сервером максимального количества уровней изоляции) в рекомендацию. с уважением, мнение ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 19:26 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
мнение Супер блокировочники имеют уровни изоляции dirty read read commited repeatable read serializable привильное их использование позволяет не делать рестартов и не грузить систему вовсе, а просто ждать. Что на 1000 комитах в секунду очень немаловажно. Это было причиной ввести пункт 3 ( о поддержке сервером максимального количества уровней изоляции) в рекомендацию. с уважением, мнение Дабы упредить последующие нападки со стороны религиозных фанатиков выделенный текст следует читать : автор привильное их использование позволяет не делать рестартов и не грузить систему вовсе, а просто ждать на блокировке, установленной на необходимом для поддеражания логической целостности уровне изоляции. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 19:55 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
мнениепривильное их использование позволяет не делать рестартов и не грузить систему вовсе, а просто ждать на блокировке, установленной на необходимом для поддеражания логической целостности уровне изоляции. Такое впечатление, что у вас сложилось чрезмерно негативное мнение о реальном влиянии мини-откатов на общую производительность системы. Там, где блокировочник будет просто долго ждать, оракл с мини-откатами освободится быстрее от очереди. Обратите внимание на примеры в статье Сергея Маркеленкова - первой была длинная транзакция, потом было несколько конкурирующих с ней коротких. Короткие отработали первыми (без задержек), длинная транзакция ждала. В классическом блокировочнике (которому вы так безрассудно преданы) все бы ждали выполнения длинной транзакции, только позавершению оной прошли бы те мелкие. Так проще? Да. Вот только быстрее ли? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 20:36 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
Anton Demidov мнениепривильное их использование позволяет не делать рестартов и не грузить систему вовсе, а просто ждать на блокировке, установленной на необходимом для поддеражания логической целостности уровне изоляции. Такое впечатление, что у вас сложилось чрезмерно негативное мнение о реальном влиянии мини-откатов на общую производительность системы. Там, где блокировочник будет просто долго ждать, оракл с мини-откатами освободится быстрее от очереди. Обратите внимание на примеры в статье Сергея Маркеленкова - первой была длинная транзакция, потом было несколько конкурирующих с ней коротких. Короткие отработали первыми (без задержек), длинная транзакция ждала. В классическом блокировочнике (которому вы так безрассудно преданы) все бы ждали выполнения длинной транзакции, только позавершению оной прошли бы те мелкие. Так проще? Да. Вот только быстрее ли? В чем вы меня пытаетесь убедить? В том что Oracle в принципе удобнее, не спорю удобнее. Суппер OLTP приложение написанной на блокировочнике с поддержкой всех уровней изоляции будет предсказуемее с точки зрения производительности, и мене затратно по железу. При прочих равных. Если говорить о длинных транзакциях вообще можете затронуть еще более веселую тему (Заметьте не я это начал). Консистентность на уровне транзакции, а не отдельного стейтмента. И получите тот же супер-блокировочник снова, с одним уровнем изоляции serializable. А потом начнутся доказательства того что dbms_lock лучше всех уровней изоляции вместе взятых. Но это уже без меня. з.ы. Со всеобщего позволения откланяюсь, дабы не розводить флейм , как просил автор топика. с уважением, мнение. з.ы.ы Похоже любое мнение является глупым , если оно не соответствует мнению пользователей Oracle. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 21:41 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
мнение з.ы.ы Похоже любое мнение является глупым , если оно не соответствует мнению пользователей Oracle. нее, не любое, пока только конкретное, до которого так и не дошло, что миниоткат это фича не связаная ни с версиониоником ни с уровнями изолированости, а только с наличием/отсутсвием предикатных блокировок. да, а про читающий update, спасибо, такой глубокой мысли от такого мнения не ожидал - записал и поставил в рамочку рядом с эскалацией обеспечивающей целостность ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 22:38 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
Yo.! мнение з.ы.ы Похоже любое мнение является глупым , если оно не соответствует мнению пользователей Oracle. нее, не любое, пока только конкретное, до которого так и не дошло, что миниоткат это фича не связаная ни с версиониоником ни с уровнями изолированости, а только с наличием/отсутсвием предикатных блокировок. Похоже у Вас абсолютные проблемы с причинно следственной логикой. С вашим стилем общения у меня нет ни малейшего желания высказывать какое либо мнение и коментировать Ваш бред. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 12:02 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
мнениеПохоже что кроме заголовка Вы ничего осилили: Эта Ваша фраза и использованное Вами выделение убедили меня, что моей изначальной фразы (про связь read consistency и подзапросов) Вы просто не поняли. Ситуация упрощается, в частности, я убедился, что Ваше высказывание о передергивании вызвано исключительно недостаточным знанием. не важноСледует отметить, что здесь "мнение" право. Не было бы read consistency - не было бы и write consistency. Read consistency и write consistency - разные понятия. Чтобы проиллюстрировать это, достаточно вспомнить тот факт, что в блокировочнике выполнение select на уровне read committed не обеспечивает read consistency, однако этот режим активно используется и при адекватном подходе не разрушает базу (что было бы неизбежно при нарушении write consistency). Разумеется, это связанные понятия - так же, как связаны вообще любые частные концепции в рамках одной реализации, одного решения общей задачи. Мини-откаты обеспечивают write consistency, однако с read consistency они связаны не более, чем с какой-либо другой из основных концепций. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 12:23 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
мнение С вашим стилем общения у меня нет ни малейшего желания высказывать какое либо мнение и коментировать Ваш бред. OK, слив засчитан. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 12:24 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
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.02.2007, 12:42 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
похоже прийдется мнению уйти непонятым :) для того чтоб нарватся на миниоткат нужно найти кривое приложение в котором конкурентные транзакции бы модифицировали предикаты, в то время как задача проста как пробка - блокируется аукцион, после чего ставится ставка, т.е. версионику с головой хватит read commited, а вот блокировочнику read commited без хинтов нарушит целостность ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 13:04 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
Yo.!для того чтоб нарватся на миниоткат нужно найти кривое приложение в котором конкурентные транзакции бы модифицировали предикаты Это я упоминал выше - учитывая, что апдейты в такой задаче в 99% случаев идут по первичному ключу, шансов мягко говоря немного. Yo.!, в то время как задача проста как пробка - блокируется аукцион, после чего ставится ставка Я не уверен в том, что это хорошее решение. Такой дизайн сводит систему к блокировочнику и приводит к предсказуемой проблеме масштабируемости (что будет, если 10'000 человек одновременно попытаются сделать ставку на некую очень популярную хрень?) Возможно, такого ажиотажа не будет - не знаю предметную область, не готов судить - но вполне возможно, лучшим решением будет убрать это бутылочное горлышко, сделать ставки развязкой между лотами и покупателями. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 13:30 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
мнениеЯ пытался взлянуть на проблему более глобально, Не возражаю. Но хотел бы объяснить, как выглядит то, что Вы делали. Первое: я нисколько не собираюсь "проталкивать" Oracle для этой задачи. Я могу обсудить со специалистами других направлений преимущества-недостатки конкретных деталей, но не считаю себя достаточно компетентным, чтобы выносить экспертную оценку типа "именно Oracle подойдет лучше других". Соответственно, Ваши легкие намеки в эту сторону выглядят... приписыванием. Второе: Вы выдвинули сомнительное утверждение, к котому я придрался (более мягко - попросил расшифровать). Я не собирался опровергать Ваше основное утверждение (даже не собирался спрашивать, в чем именно оно состоит), но хотел бы четко понимать аргументацию, найти в ней интересную для меня деталь или дезавуировать ложный аргумент. В ходе расшифровки сложилось мнение, что Вы плохо ориентируетесь в том, на что опираетесь в своих рассуждениях. Третье: Вы довольно долго прятались и до сих пор прячетесь за общими словами. Скажем, "попытка взглянуть на проблему более глобально" звучит достойно, но обоснованием для "ошибок в деталях" не является. Если не хотите думать о деталях - так и не говорите о них. Если же без них система взглядов разваливается - таки о них надо думать. Четвертое: в последнем письме Вы фактически свели итог к следующему: "Я хотел как лучше, а что сказал чушь, так это фигня, все равно в главном я наверняка прав, но давайте не будем ковырять, а то окажется что и там не все гладко". В общем, получилось к сожалению "как всегда". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 13:44 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
softwarer Это я упоминал выше - учитывая, что апдейты в такой задаче в 99% случаев идут по первичному ключу, шансов мягко говоря немного. почему 99 ? на мой взгляд там может быть только один update - обновление победителя и выигрывающей ставки в аукционе (лоте), конечно же по первичному, т.е. шансов не просто мало их просто нет. softwarer Я не уверен в том, что это хорошее решение. Такой дизайн сводит систему к блокировочнику и приводит к предсказуемой проблеме масштабируемости (что будет, если 10'000 человек одновременно попытаются сделать ставку на некую очень популярную хрень?) Возможно, такого ажиотажа не будет - не знаю предметную область, не готов судить - но вполне возможно, лучшим решением будет убрать это бутылочное горлышко, сделать ставки развязкой между лотами и покупателями. не, конечно всю таблицу блокировать глупо - аукцион у меня синоним лота :) конечно достаточно заблокировать один лот на время транзакции ставки. а вот 10К для блокировочника будет тяжко, особдиво mssql который из-за эскалации начнет лочить все лоты, т.к. эскалировать до страницы не умеет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 13:48 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
Yo.!а вот 10К для блокировочника будет тяжко, особдиво mssql который из-за эскалации начнет лочить все лоты, т.к. эскалировать до страницы не умеет Зато он может совсем не эскалировать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 13:56 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
pkarklin Зато он может совсем не эскалировать. может, но станет еще хуже, т.к. будет вынужден юлозить по громадному списку локов в памяти и то при условии, что памяти на такой список хватит. правда, это скорее свойтсво lock менеджера чем версионник/блокировочник. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 14:04 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
Yo.!может, но станет еще хуже, т.к. будет вынужден юлозить по громадному списку локов в памяти и то при условии, что памяти на такой список хватит. правда, это скорее свойтсво lock менеджера чем версионник/блокировочник. Скажем так. Имеется недокументированная возможностью "отключить" эскалацию не только для всего сервера, но и для определенных "сильно нагруженных" таблиц. Насчет хуже\лучше - памяти можно и добавить. ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 14:09 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
Yo.!не, конечно всю таблицу блокировать глупо - аукцион у меня синоним лота :) Поэтому я и отвечаю для лота. Для "всемирного аукциона" даже блокировка лота может стать существенной неприятностью; лучше дать людям insert-ить биды или апдейтить каждому свой бид. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 14:29 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
softwarer Yo.!не, конечно всю таблицу блокировать глупо - аукцион у меня синоним лота :) Поэтому я и отвечаю для лота. Для "всемирного аукциона" даже блокировка лота может стать существенной неприятностью; лучше дать людям insert-ить биды или апдейтить каждому свой бид. а как тогда показывать актульного победителя и его ставку гораздо большему числу читателей ? вычислять каждый раз имхо несоизмеримо дороже выйдет ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 14:35 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
softwarer мнениеЯ пытался взлянуть на проблему более глобально, Не возражаю. Но хотел бы объяснить, как выглядит то, что Вы делали. Первое: я нисколько не собираюсь "проталкивать" Oracle для этой задачи. Я могу обсудить со специалистами других направлений преимущества-недостатки конкретных деталей, но не считаю себя достаточно компетентным, чтобы выносить экспертную оценку типа "именно Oracle подойдет лучше других". Соответственно, Ваши легкие намеки в эту сторону выглядят... приписыванием. Как вы заметили я не намерен протягивать ни один из брендов. Если уж речь зашла об oracle я высказал свое видиние ситуации по этому поводу. Экспертных заключений я не делал, я высказал возможность возникновения проблем связанных с описанным мною выше. softwarer Второе: Вы выдвинули сомнительное утверждение, к котому я придрался (более мягко - попросил расшифровать). Я не собирался опровергать Ваше основное утверждение (даже не собирался спрашивать, в чем именно оно состоит), но хотел бы четко понимать аргументацию, найти в ней интересную для меня деталь или дезавуировать ложный аргумент. В ходе расшифровки сложилось мнение, что Вы плохо ориентируетесь в том, на что опираетесь в своих рассуждениях. Аргументацию я кажется приводил. Или вы хотели что бы я вам statspack-и выложил? Конкретных замечаний по поводу фактов изложенных мной от Вас лично небыло. Ни одного из моих аргументов вы не опровергили (технически). Максимум что я от вас слышал это про Фому и Ерему а также softwarer Пока ограничусь констатацией того, что зря "не вызывает". и softwarer Эта Ваша фраза и использованное Вами выделение убедили меня, что моей изначальной фразы (про связь read consistency и подзапросов) Вы просто не поняли. Ситуация упрощается, в частности, я убедился, что Ваше высказывание о передергивании вызвано исключительно недостаточным знанием. Привидите пожалуйста цитату из сообщения с Вашей фразой. В подтверждение Ваших слов о моей некомпетентности прошу привести цитаты где я был не прав. Я люблю работать над собственными ошибками. softwarer Третье: Вы довольно долго прятались и до сих пор прячетесь за общими словами. Скажем, "попытка взглянуть на проблему более глобально" звучит достойно, но обоснованием для "ошибок в деталях" не является. Если не хотите думать о деталях - так и не говорите о них. Если же без них система взглядов разваливается - таки о них надо думать. Где я допустил ошибки в деталях? softwarer Четвертое: в по следнем письме Вы фактически свели итог к следующему: "Я хотел как лучше, а что сказал чушь, так это фигня, все равно в главном я наверняка прав, но давайте не будем ковырять, а то окажется что и там не все гладко". Где я сказал чушь? Цитаты , ссылки? softwarer В общем, получилось к сожалению "как всегда". Действительно, я об этом уже раньше говорил, что так будет. Дальше беспочвенных обвинений разговор не двинулся. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 14:50 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
Yo.!а как тогда показывать актульного победителя и его ставку гораздо большему числу читателей ? вычислять каждый раз имхо несоизмеримо дороже выйдет ... Вычислять каждый раз особой необходимости нет, эту информацию спокойно можно кэшировать. В онлайн-аукционе неизбежно будет пауза - минута или несколько минут - между последней ставкой и фиксацией результата. Соответственно, выдача лидера например с десятисекундной задержкой ничего существенно не изменит, и в любом случае такая система будет приятнее, нежели постоянные сообщения "вы не успели сделать ставку, другой уже поставил больше". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 14:55 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
Yo.! pkarklin Зато он может совсем не эскалировать. может, но станет еще хуже, т.к. будет вынужден юлозить по громадному списку локов в памяти и то при условии, что памяти на такой список хватит. правда, это скорее свойтсво lock менеджера чем версионник/блокировочник. Просьба обратить внимание на слоты траназкций в oracle, и кто и что там будет как вы выразелись елозить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 14:58 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
softwarer Yo.!а как тогда показывать актульного победителя и его ставку гораздо большему числу читателей ? вычислять каждый раз имхо несоизмеримо дороже выйдет ... Вычислять каждый раз особой необходимости нет, эту информацию спокойно можно кэшировать. В онлайн-аукционе неизбежно будет пауза - минута или несколько минут - между последней ставкой и фиксацией результата. Соответственно, выдача лидера например с десятисекундной задержкой ничего существенно не изменит, и в любом случае такая система будет приятнее, нежели постоянные сообщения "вы не успели сделать ставку, другой уже поставил больше". кешировать, сомневаюсь, да и пауза в минуту думаю не приемлимо. а наблюдал за аукционном наименьшей суммы (выигрывает кто сделал наименьшую уникальную ставку), так там все веселье начинается за минуту до конца аукциона (лота), т.е. эта минута все и решает. еще прикольно что может выйграть случайная ставка из-за того, что остальные ставки оказались неуникальны :) там за 10 секунд один пользователь способен сделать 20 ставок, т.е. видеть актуальное инфо просто необходимо ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 15:32 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
хотя там кажется как раз около минуты транзакции и рассасывлись после закрытия. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 15:41 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
мнение Просьба обратить внимание на слоты траназкций в oracle, и кто и что там будет как вы выразелись елозить. о да, я обратил, и вы тоже !? правда они великолепны ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 15:49 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
мнениеАргументацию я кажется приводил. Где, простите? Максимум того, что Вы привели, это "если попробуете последовать вот этому намеку, сможете самостоятельно подтвердите мою точку зрения". мнениеИли вы хотели что бы я вам statspack-и выложил? Если у Вас есть под рукой система с аналогичной нагрузкой, было бы неплохо. Особенно интересной была бы строка "потери на мини-откатах" из этого отчета :) Хватило бы живого примера. Что-нибудь типа "для обсуждаемой системы надо будет решать такую-то задачу, хороший программист решит ее таким-то кодом, но при этом довольно вероятен мини-откат". мнениеКонкретных замечаний по поводу фактов изложенных мной от Вас лично небыло. От Вас лично не было изложено конкретных фактов. Исключительно несколько общих слов. мнениеНи одного из моих аргументов вы не опровергили (технически). Технически, если Вы не в курсе, аргументы требуется сначала "обосновывать", и только после этого, может быть, "опровергать" 1 . 1 Аргумент - это "утверждение, выдвинутое в подтверждение другого утверждения" . До тех пор, пока аргумент-утверждение не обоснован, опровергать его необходимо не более, нежели любое другое необоснованное утверждение мнениеМаксимум что я от вас слышал это про Фому и Ерему Да и то, либо не поняли, либо не захотели понять. мнениеа также Пока ограничусь констатацией того, что зря "не вызывает". Если Вы вдруг пропустили при чтении часть того поста, на которое отвечаете чуть ниже в тексте, могу дать ссылку для более внимательного изучения: http://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.02.2007, 15:53 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
мнениеИли вы хотели что бы я вам statspack-и выложил? Выложи, а ? Все лучше чем попусту воздух сотрясать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 15:54 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
Yo.!кешировать, сомневаюсь Думаю, не имеет смысла искать истину - она зависит от постановки и условий задачи :) Yo.!, да и пауза в минуту думаю не приемлимо. Хм. Я почему-то уверен, что пауза будет больше. Просто представьте себе, что Вы покупаете например картину Рембрандта, и она уходит Вашему принципиальному сопернику из-за того, что Вы уронили мышку и не смогли нажать Ok :) Yo.!а наблюдал за аукционном наименьшей суммы (выигрывает кто сделал наименьшую уникальную ставку), так там все веселье начинается за минуту до конца аукциона (лота), т.е. эта минута все и решает. еще прикольно что может выйграть случайная ставка из-за того, что остальные ставки оказались неуникальны :) Судя по описанию, Вы говорите о весьма специфическом случае. На нормальных аукционах afaik торгуются до максимальной цены, а не до фиксированного времени завершения торгов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 16:02 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
Yo.! а как тогда показывать актульного победителя и его ставку гораздо большему числу читателей ? вычислять каждый раз имхо несоизмеримо дороже выйдет ... Гм, я все пытаюсь понять, как скорость проведения update (и, соотвественно, модель блокировок) связна с задачей аукциона? Там гораздо проще текущего победителя и всю локальную историю хранить и кэшировать на уровне сервера приложений (с разными очевидными стратегиями распределения нагрузки между серверами). А в БД в этом случае нужно только вставлять (без всяких блокировок) заявки игроков - да и то только в целях аудита и, при необходимости, восстановления после падения. И при таком подходе в качестве БД можно хоть MySQL использовать... (Впрочем, я бы использовал DB2 - благо тоже бесплатно для такого класса задач, на вставках весьма оперативна и имеет кучу возможностей к росту - но это личное мнение). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 16:05 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
DPHГм, я все пытаюсь понять, как скорость проведения update (и, соотвественно, модель блокировок) связна с задачей аукциона? Хм. В той теме, что начало мнение, связь с задачей аукциона вообще постоянно теряется. Если помните, я еще первым же своим письмом на эту тему сказал, что тезис имхо не имеет отношения именно к этой задаче :) DPHТам гораздо проще текущего победителя и всю локальную историю хранить и кэшировать на уровне сервера приложений (с разными очевидными стратегиями распределения нагрузки между серверами). А в БД в этом случае нужно только вставлять (без всяких блокировок) заявки игроков - да и то только в целях аудита и, при необходимости, восстановления после падения. Я бы не стал выделять сервер приложения. Собственно я сказал насчет вставок и кэширования, а как именно делать это кэширование - имхо уже вопрос десятый. DPHИ при таком подходе в качестве БД можно хоть MySQL использовать... А об этом я говорил чуть ли не во втором посте этого топика :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 16:10 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
softwarer Судя по описанию, Вы говорите о весьма специфическом случае. На нормальных аукционах afaik торгуются до максимальной цены, а не до фиксированного времени завершения торгов. ну да, специфический, просто думаю автор что-то подобное имел ввиду, щас это модно да и сомневаюсь я что за "Рембранта" будет 1К конкурентных транзакций .. пока он прекрасно продается табличками :) конечно гадать что автор имел ввиду под аукционом смысла нет, но что бы он там не имел ввиду, миниоткатам там взятся неоткуда ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 16:15 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
DPH Там гораздо проще текущего победителя и всю локальную историю хранить и кэшировать на уровне сервера приложений (с разными очевидными стратегиями распределения нагрузки между серверами). тут непонял, под кешом обычно понимают нечто неактуальное, которое периодически обновляется, вы похоже просто предлагаете конкурентно обновлять объект апп сервера, а не табличку ... но я не вижу разницы, в субд табличка будет в той же памяти ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 16:27 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
Yo.!сомневаюсь я что за "Рембранта" будет 1К конкурентных транзакций .. Безусловно, это уже утрирование для усиления эффекта :) Согласитесь, "серьезные аукционеры" вряд ли захотят терять деньги из-за того, что кто-то не успел нажать на кнопку. Поэтому пауза будет, и будет достаточно длинной (так, чтобы желающий поставить успел это сделать, но участники торгов и особенно победитель не слишком раздражались ожиданием). Yo.!конечно гадать что автор имел ввиду под аукционом смысла нет, но что бы он там не имел ввиду, миниоткатам там взятся неоткуда Безусловно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 16:32 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
Помнится когда-то давно обсуждали подобное...) http://www.sql.ru/forum/actualthread.aspx?tid=145611&hl=%e7%e0%e4%e0%f7%e0+oracle#1179863 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 16:48 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
Хм. Лень читать все "то" обсуждение, начало, честно говоря, не впечатлило. Чем она подобна обсуждаемой, не понимаю (возможно из-за того, что таки не прочитал те пять страниц, но есть впечатление, что подобна только упоминанием слова Oracle). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 17:06 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
gardenmanПомнится когда-то давно обсуждали подобное...) http://www.sql.ru/forum/actualthread.aspx?tid=145611&hl=%e7%e0%e4%e0%f7%e0+oracle#1179863 ну да, и решили, что грязное чтение в 21 юзать не серьозно ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 17:07 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
Yo.! DPH Там гораздо проще текущего победителя и всю локальную историю хранить и кэшировать на уровне сервера приложений (с разными очевидными стратегиями распределения нагрузки между серверами). тут непонял, под кешом обычно понимают нечто неактуальное, которое периодически обновляется, вы похоже просто предлагаете конкурентно обновлять объект апп сервера, а не табличку ... но я не вижу разницы, в субд табличка будет в той же памяти ... В СУБД "изменение таблички в памяти" требует ее изменения на диске, сохранения лога транзакции, весьма недешевую проверку блокировок и т.п Для AppServer, даже если не рассматривать асинхронные варианты persistance, все гораздо дешевле - нет блокировок, выполняется команда insert, а не update. Я неоднократно играл с подобными схемами, выигрыш от варианта "update объекта в кэше, вставка изменения в базу" по сравнению с "update поля в базе" зачастую более чем в десять раз. Ну и, конечно, никаких блокировок (вернее, блокировка по объекту AppServer, но она очень быстрая). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 17:13 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
softwarer Я бы не стал выделять сервер приложения. Собственно я сказал насчет вставок и кэширования, а как именно делать это кэширование - имхо уже вопрос десятый. Гм, тут не просто кэширование, тут еще и актуально кэширование без персистанса, т.е. уже вне уровня БД. Т.е., в общем случае, на промежуточном слое между persistance и клиентом. Это, конечно, не обязательно сервер приложений, но что же еще? (Если Web-server реализует такое кэширование - то это уже сервер приложения, по хорошему) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 17:16 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
Yo.!ну да, и решили, что грязное чтение в 21 юзать не серьозно ... И главное - зачем грязное чтение, если задача элементарно решается путем select for update skip locked? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 17:19 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
Yo.! gardenmanПомнится когда-то давно обсуждали подобное...) http://www.sql.ru/forum/actualthread.aspx?tid=145611&hl=%e7%e0%e4%e0%f7%e0+oracle#1179863 ну да, и решили, что грязное чтение в 21 юзать не серьозно ... Yo! так решил для себя...) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 17:20 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
softwarer Yo.!ну да, и решили, что грязное чтение в 21 юзать не серьозно ... И главное - зачем грязное чтение, если задача элементарно решается путем select for update skip locked? А затем, что если скипнуть лоченные записи не узнать реального положения дел в настоящий момент)) :D ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 17:22 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
DPHГм, тут не просто кэширование, тут еще и актуально кэширование без персистанса, т.е. уже вне уровня БД. Во-первых, "уже" вообще говоря не обязательно. Никто не мешает создавать объект в БД, но без персистанса. Во-вторых, я согласен с тем, что с практической точки зрения так, как предлагаете Вы, будет вполне удобно, но тем не менее, не вижу здесь принципиальности. Можно кэшировать и в БД и с персистенсом, ничего страшного не будет (конечно, дополнительные расходы, но контролируемые и непринципиальные). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 17:22 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
gardenmanА затем, что если скипнуть лоченные записи не узнать реального положения дел в настоящий момент)) :D А это уже нафиг не интересно с точки зрения постановки задачи. Там сказано - зарезервировать 50 билетов, for update это позволяет. Еще там сказано не мешать другим транзакциям, skip locked это позволяет. Если хочешь - иди в тот топик и придумывай другую задачу. Будет этакое соревнование: сумеет ли gardenman придумать задачу, которую Oracle не сумеет решить ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 17:25 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
DPH В СУБД "изменение таблички в памяти" требует ее изменения на диске, сохранения лога транзакции, весьма недешевую проверку блокировок и т.п непонял, вы считаете что это все лишнее ? DPH Для AppServer, даже если не рассматривать асинхронные варианты persistance, все гораздо дешевле - нет блокировок, выполняется команда insert, а не update. для того чтоб в случае сбоя воставновить ваш объект вы обязаны писать в персистент хранилище и не асинхронно а "сию секунду", т.е. тут съэкономить не удастся. к тому же изменение таблички не требует ее изменения на диске (надеюсь вы в курсе что требуется лишь последовательная запись в лог) DPH Я неоднократно играл с подобными схемами, выигрыш от варианта "update объекта в кэше, вставка изменения в базу" по сравнению с "update поля в базе" зачастую более чем в десять раз. Ну и, конечно, никаких блокировок (вернее, блокировка по объекту AppServer, но она очень быстрая). неверю, геморой по синхранизации объекта с субд не окупится, расскажите plz что вы будете желать если после обновления объекта связь с субд пропала ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 17:29 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
Yo.!непонял, вы считаете что это все лишнее ? Для задачи "возвращать актуального лидера" это действительно лишнее. Yo.!для того чтоб в случае сбоя воставновить ваш объект вы обязаны писать в персистент хранилище Это insert, следовательно без блокировок, следовательно горлышком являются только возможности железа. Yo.!неверю, геморой по синхранизации объекта с субд не окупится, Тут Вы вряд ли правы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 17:41 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
softwarer Это insert, следовательно без блокировок, следовательно горлышком являются только возможности железа. чудес не бывает, вместо блокировки в субд у него будет блокировка в объекте в чем разница ? softwarer Yo.!неверю, геморой по синхранизации объекта с субд не окупится, Тут Вы вряд ли правы. расшифруй, мне не понятно если я сначало обновляю объект, а потом асинхронно пишу в хранилище то в случае сбоя получу lost update ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 17:54 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
Yo.!чудес не бывает, вместо блокировки в субд у него будет блокировка в объекте в чем разница ? В том, что с объектом не делается "персистентных" операций, а следовательно блокировка удерживается на нем много меньше времени. Держать же эту блокировку на время персистентных операций совершенно необязательно. Yo.!расшифруй, мне не понятно если я сначало обновляю объект, а потом асинхронно пишу в хранилище то в случае сбоя получу lost update Хм. Вообще тут опять-таки надо плясать от постановки задачи; я бы сказал, весьма вероятна постановка "в случае неустранимого аппаратного сбоя аукцион переигрывается с начала". Если предположить, что ставки надо заведомо сохранять, безусловно, писать в хранилище нужно синхронно и с начала. Но блокировку на "объекте" при этом держать совершенно не нужно; после успешной записи накладывается короткая блокировка и new_leading_bid := max ( new_leading_bid, current_bid ), все. Возникает вопрос, что делать, если запись попала в хранилище и в этот момент рухнул аппсервер. Ответ - да ничего, как он поднимется, так и сделает select max() из хранилища. Это же относится к случаю, если аппсерверов несколько; обслуживание объекта перейдет на другой сервер. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 18:10 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
softwarerМини-откаты обеспечивают write consistency, однако с read consistency они связаны не более, чем с какой-либо другой из основных концепций.Хм... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 20:53 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
softwarerСудя по описанию, Вы говорите о весьма специфическом случае. На нормальных аукционах afaik торгуются до максимальной цены, а не до фиксированного времени завершения торгов. eBay - это нормальный аукцион или нет? Ради интереса найдите лот на iPod Nano 2Gb в последние 2 минуты торгов в вечернее время (американское) и полюбуйтесь на бурю страстей. P.S. Насколько я помню, у них активные лоты в завершающей стадии обрабатываются другим сервером. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 22:35 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
Yo.! для того чтоб в случае сбоя воставновить ваш объект вы обязаны писать в персистент хранилище и не асинхронно а "сию секунду", т.е. тут съэкономить не удастся Гм, на всякий случай сообщаю, что есть куча систем гарантированной доставки сообщения. В некоторых случаях производительность при использовании MQ, например, сильно повышается. Впрочем, это уже некоторая экзотика, я с ней дела непосредственно не имел, мне пока хватает синхнонных схем. DPH Я неоднократно играл с подобными схемами, выигрыш от варианта "update объекта в кэше, вставка изменения в базу" по сравнению с "update поля в базе" зачастую более чем в десять раз. Ну и, конечно, никаких блокировок (вернее, блокировка по объекту AppServer, но она очень быстрая). неверю, геморой по синхранизации объекта с субд не окупится, расскажите plz что вы будете желать если после обновления объекта связь с субд пропала ?[/quot] Гм, а зря не веришь. Синхронизация объекта с БД - элементарна: в БД лежит начальное значение на некий момент времени, при каждом изменении в отдельную таблицу в рамках транзакции пишется "дельта" (insert, без блокировок). на AppServer в кэше живет только актуальное значение, кэш освобождается по времени или по переполнению, изменение кэша синхронизируется (это все практически бесплатно). При откате транзакции кэш в AppServer, понятное дело, корректируется (что легко). Если упал AppServer или значения в кэше нет - то новое значение рассчитываем по начальному и дельтам (единственная блокирующая транзакция, но очень редкая). Реально на тестах такая схема показала примерно 2х кратный выигрыш при отсутствии конкуренции и 20ти кратный - при большой конкуренции по одному элементу. Да, разумеется, просто чтение значения в любом случае до БД не доходит (если есть запись в кэше). Вообще, смотри архитектуру ebay, неэлементарные транзакции в больших системах - зло. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.02.2007, 18:35 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
softwarer Если предположить, что ставки надо заведомо сохранять, безусловно, писать в хранилище нужно синхронно и с начала. Вообще, если говорить об оччень больших системах, то кластерный MQ-сервер с гарантией доставки и высокопроизводительным хранилищем, заточенным именно на временное хранение сообщений дает ту же надежность, что и синхронное хранение (но уменьшает некоторые затраты и упрощает зачастую кластеризацию). Но это уже недешевое удовольствие.... А 1000 операций в секунду можно получить и с бесплатным софтом и дешевым железом. Правда, на RAID придется потратиться. Ну и на программистов. DB/2 Express C + log shipping в этом случае - замечательный выбор, все компоненты уже готовы, а кластер получается надежный и простой. И бесплатный... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.02.2007, 18:50 |
|
||
|
Выбор СУБД
|
|||
|---|---|---|---|
|
#18+
Anton DemidoveBay - это нормальный аукцион или нет? Не знаю. Возможно, я отстал от жизни; я вообще не слишком понимаю смысла аукциона на серийную вещь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.02.2007, 20:01 |
|
||
|
|
start [/forum/moderation_log.php?user_name=Prohvatilov]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
52ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
186ms |
get tp. blocked users: |
1ms |
| others: | 645ms |
| total: | 949ms |
| 0 / 0 |
