Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 22 23 24 25 26 27 28 [29] 30 31   вперед  Ctrl
 Re: MySQL vs Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30290
автор
но сервер то должен обрабатывать их стандартно!

должен, никто не спорит. но пока - не может. потому что это не просто баг, который можно исправить в исходниках парой строчек кода.
9 янв 08, 14:57    [5129469]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54850

leonbn
должен обрабатывать их стандартно!

Без ссылки/цитаты на стандарт такие заявления - пустой звук.

Posted via ActualForum NNTP Server 1.4

9 янв 08, 15:01    [5129504]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Yo.!
Guest
Dimitry Sibiryakov

Yo.!
любой кто из ФАКа по любой субд

Т.е. сначала один дебил при проектировании базы позволяет дубли, а потом
другой, пользуясь совершенно левой надписью на заборе пытается от них
избавиться. Аффигительно жизненный пример!
Posted via ActualForum NNTP Server 1.4


Эх молодость, а сколько еще открытий чудных в коде наших индуских друзей впереди ...
самый номер, то что наш Шумахер до сего дня не подозревал, что хрень то не в FIRST и даже не в подзапросах, а гораздо глобальней и прочесывать его код еще кому-то предстоит

2kdv
так на счет update можно все же пояснить ? и с курсорами в процедурах там тот же фифект вылазит ?
9 янв 08, 15:09    [5129567]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
leonbn
Member

Откуда: СПб
Сообщений: 522
fynda
Ну так я не увидел ответа на вопрос. Вы все это тащите в релиз, даже ни
разу не протестив? Или как?

В релиз чего - СУБД?
По вашему СУБД должна работать по разному для юзеров (в зависимости от разработка - эксплуатация).
9 янв 08, 15:12    [5129592]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
leonbn
Member

Откуда: СПб
Сообщений: 522
Dimitry Sibiryakov
Без ссылки/цитаты на стандарт такие заявления - пустой звук.

Если все видят, что белое - это белое, а черное - черное, но один дебил будет утверждать обратное, то ни какие ссылки не помогут.
kdv
но пока - не может. потому что это не просто баг, который можно исправить в исходниках парой строчек кода

Прикрасно это понимаю!
9 янв 08, 15:17    [5129627]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
S.G.
Member

Откуда: cartoon network
Сообщений: 30611
DocAl
Ну, мы действительно рассматриваем проблему с разных точек зрения, т.к. меня истересуют СУБД с точки зрения использования в качестве бакэнда сайта. В этом случае, проблемы лицензирования отходят на задний план, т.к., во-первых, это, как правило, не коробочный продукт, а решение, изготовленное под заказчика, а во-вторых, для LAMP в лицензии сделано особое исключение, так что для такого использования покупать коммерческую лицензию точно не требуется.

И в такой ситуации, собственно, я не вижу никаких преимуществ у фаербёрда, зато недостатков полно: суперсервер не SMP, да ещё и не на любой ОС есть. Классическую архитектуру для таких задач использовать -- это надо быть большим фанатом фаербёрда, чтоб игнорировать недостатки такого подхода. Памяти на вебсервере много не бывает, время соединения критично, при этом соединений много, они непродолжительны и работают примерно с одним и тем же набором данных. Кроме того, если вебсервер и СУБД работают физически на одной и той же машине, полагаться на кэш файловой системы вообще недопустимо: он же постоянно будет вымываться статикой!
У меня есть не очень большой, но все- таки опыт промышленного использования файерберда через веб. БД в локальной сетке, и есть другой комп с выходом в интернет; на нем веб-сервер- IIS, приложение на ASP.net. Связь с БД осуществляется через пул соединений, так что там извне хоть 100, хоть 1000 соединений - все проходят через небольшое количество заданных соединений пула. При этом архитектура сервера, его кеш и SMP уже не играют роли. К сожалению, не могу подтвердить это экспериментально, так как нагрузка небольшая, но мне кажется, сам принцип пула соединений + непродолжительности одного запроса по времени, будут давать малое время отклика при больших нагрузках. То есть- не терятеся время на коннект/дисконнект к БД; если пришло несколько запросов одновременно, используются несколько соединений из пула, если кол-во одновременных запросов превысило допустимое количество соединений пула- они ждут пока освободится соединение. Так как типовое время выполнения запроса в моем случае- намного меньше секунды, предполагаю что эта схема (может быть) будет испытвать трудности при более чем 5-10 запросов в секунду, что далеко превышает реальную нагрузку (в моем случае) сейчас да и в будущем.

Гм, вполне вероятно что генерация страницы asp.net-ом - более медленный процесс, чем выполнение запроса файербердом ;) /хотя не проверял/
9 янв 08, 15:29    [5129740]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54850

leonbn
ни какие ссылки не помогут.

В отличие от конторы БГ, разработчики FB стараются придерживаться
стандартов, так что точная цитата из SQL2003, например, может служить
решающим аргументом. Единственное, что может помешать - проклятое legacy
и backward compatibility.

Posted via ActualForum NNTP Server 1.4

9 янв 08, 15:29    [5129741]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
S.G.
сам принцип пула соединений + непродолжительности одного запроса по времени, будут давать малое время отклика при больших нагрузк

Теперь осталось объяснить это DocAl-ю
9 янв 08, 15:36    [5129816]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Yo.!
Guest
FreemanZAV
S.G.
сам принцип пула соединений + непродолжительности одного запроса по времени, будут давать малое время отклика при больших нагрузк

Теперь осталось объяснить это DocAl-ю

че курим ? или это остаточный эфект праздников ?
какую связь вы нашли пула конектов с отсутсвием единового кеша субд !?
9 янв 08, 15:41    [5129869]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
Yo.!
FreemanZAV
S.G.
сам принцип пула соединений + непродолжительности одного запроса по времени, будут давать малое время отклика при больших нагрузк

Теперь осталось объяснить это DocAl-ю

че курим ? или это остаточный эфект праздников ?
какую связь вы нашли пула конектов с отсутсвием единового кеша субд !?
Или с отсутствием SMP в суперсервере...
9 янв 08, 15:45    [5129905]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30290
Yo
так на счет update можно все же пояснить ? и с курсорами в процедурах там тот же фифект вылазит ?


я еще не очень отошел от праздников, поэтому могу излагать несколько мутно. :-)
Так вот, может быть два варианта -
1. сначала выполняется подзапрос, затем update/delete идет по записям и проверяет совпадение
2. update/delete идет по записям и выполняет подзапрос (корреляция).

во втором случае наблюдаем эффект "нестабильности" курсора. потому что и update и подзапрос выполняются в контексте одной и той же транзакции. То есть, подзапрос может "увидеть" записи, уже измененные update/delete.

избавиться от этого можно только изолированием транзакций update/delete и подзапроса. Как бы, подзапрос выполнять в суб-транзакции.

Похожая (но несколько другая) ситуация и с нестабильностью select в режиме read_committed. То есть, select может увидеть записи, которые были committed ПОСЛЕ начала выполнения select. Об этом я писал тут:
https://www.sql.ru/forum/actualthread.aspx?tid=173455&pg=2

и, да, FOR SELECT в процедуре будет видеть изменения, которые производятся по DO внутри цикла.
(правила те же самые, что и для insert into select from - попадание в where или отсутствие plan sort).
9 янв 08, 15:58    [5130011]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
S.G.
Member

Откуда: cartoon network
Сообщений: 30611
DocAl
Yo.!

че курим ? или это остаточный эфект праздников ?
какую связь вы нашли пула конектов с отсутсвием единового кеша субд !?
Или с отсутствием SMP в суперсервере...
Собственно, мы уже курим возможность использования FB для web back-end :)
9 янв 08, 16:01    [5130030]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
S.G.
DocAl
Ну, мы действительно рассматриваем проблему с разных точек зрения, т.к. меня истересуют СУБД с точки зрения использования в качестве бакэнда сайта. В этом случае, проблемы лицензирования отходят на задний план, т.к., во-первых, это, как правило, не коробочный продукт, а решение, изготовленное под заказчика, а во-вторых, для LAMP в лицензии сделано особое исключение, так что для такого использования покупать коммерческую лицензию точно не требуется.

И в такой ситуации, собственно, я не вижу никаких преимуществ у фаербёрда, зато недостатков полно: суперсервер не SMP, да ещё и не на любой ОС есть. Классическую архитектуру для таких задач использовать -- это надо быть большим фанатом фаербёрда, чтоб игнорировать недостатки такого подхода. Памяти на вебсервере много не бывает, время соединения критично, при этом соединений много, они непродолжительны и работают примерно с одним и тем же набором данных. Кроме того, если вебсервер и СУБД работают физически на одной и той же машине, полагаться на кэш файловой системы вообще недопустимо: он же постоянно будет вымываться статикой!
У меня есть не очень большой, но все- таки опыт промышленного использования файерберда через веб. БД в локальной сетке, и есть другой комп с выходом в интернет; на нем веб-сервер- IIS, приложение на ASP.net. Связь с БД осуществляется через пул соединений, так что там извне хоть 100, хоть 1000 соединений - все проходят через небольшое количество заданных соединений пула. При этом архитектура сервера, его кеш и SMP уже не играют роли. К сожалению, не могу подтвердить это экспериментально, так как нагрузка небольшая, но мне кажется, сам принцип пула соединений + непродолжительности одного запроса по времени, будут давать малое время отклика при больших нагрузках. То есть- не терятеся время на коннект/дисконнект к БД; если пришло несколько запросов одновременно, используются несколько соединений из пула, если кол-во одновременных запросов превысило допустимое количество соединений пула- они ждут пока освободится соединение. Так как типовое время выполнения запроса в моем случае- намного меньше секунды, предполагаю что эта схема (может быть) будет испытвать трудности при более чем 5-10 запросов в секунду, что далеко превышает реальную нагрузку (в моем случае) сейчас да и в будущем.

Гм, вполне вероятно что генерация страницы asp.net-ом - более медленный процесс, чем выполнение запроса файербердом ;) /хотя не проверял/
Я не хочу кидать тут пальцы, но вы понимаете, что 5-10 запросов в секунду -- это вообще не цифра для такого типа нагрузки? При этом, вы уже рассматриваете решение с двумя физическими серверами. (А каждый юнит на техплощадки стоит лишних денег ежемесячно) Вынесение фаербёрда на отдельную машину, конечно, позволяет надеяться, что файловый кэш не будет так уж активно вымываться посторонними задачами, но, никоим образом не решает остальных проблем.
9 янв 08, 16:05    [5130073]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
S.G.
Собственно, мы уже курим возможность использования FB для web back-end :)
А я не понял, для web back-end не нужно SMP? Или память у этого бакэнда безлимитная? io у него от сети?
9 янв 08, 16:08    [5130089]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Yo.!
Guest
2kvd

все равно не понятно в чем отличие insert и delete

по мне обсалютно одинаковы подзапросы, но при update подзапрос не рестартится:


update xxx=xxx+5 where xxx in (select xxx where xxx=5 or xxx=10) ;
если xxx изаначально равно 5, то при рестарте оно станет равно 10 и ошибочно добавится еще раз, но этого не происходит ...
9 янв 08, 16:10    [5130104]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
fynda
Member

Откуда: Пенза
Сообщений: 2785

leonbn пишет:

>> Ну так я не увидел ответа на вопрос. Вы все это тащите в релиз, даже ни
>> разу не протестив? Или как?
>
> В релиз чего - СУБД?

Нет, вашей проги.

Posted via ActualForum NNTP Server 1.4

9 янв 08, 16:40    [5130317]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11578
Dimitry Sibiryakov
В отличие от конторы БГ, разработчики FB стараются придерживаться
стандартов, так что точная цитата из SQL2003, например, может служить
решающим аргументом. Единственное, что может помешать - проклятое legacy
и backward compatibility
а) Стандарт не обязывает курсоры быть стабильными. Он описывает оба варианта и всё. Это про "строгость" read-committed. Кстати, уровень изоляции по-умолчанию, как раз snapshot и в нём таких проблем нет по-определению. Можно сделать read-committed как в оракле (снимок на каждый запрос), но ценой некоторых дополнительных накладных расходов на старт каждого запроса. Я ещё не решал, когда этим заняться :)

б) update a=b, b=a действительно не правится из-за backward compatibility. Есть известные случаи сознательного применения этой фичи. Т.к. реально оно почти никого не волнует, то приорити минимальный.

в) insert from select скорее всего будет исправлен в одном из будущих релизов (2.5 или 3.0)
9 янв 08, 19:57    [5131385]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
hvlad
б) update a=b, b=a действительно не правится из-за backward compatibility. Есть известные случаи сознательного применения этой фичи. Т.к. реально оно почти никого не волнует, то приорити минимальный.

Хм. Я очень не люблю "переключатели поведения", но в этом случае наверное таки сделал бы именно так (работу "по-новому" плюс опцию "работать по-старому").
9 янв 08, 20:06    [5131406]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
hvlad
в) insert from select скорее всего будет исправлен в одном из будущих релизов (2.5

Какой ужос!!!! И о чем после будут говорит Yo и DocAl? Зачем вы так с ними Картинка с другого сайта.
10 янв 08, 09:11    [5132167]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
FreemanZAV
hvlad
в) insert from select скорее всего будет исправлен в одном из будущих релизов (2.5

Какой ужос!!!! И о чем после будут говорит Yo и DocAl? Зачем вы так с ними Картинка с другого сайта.
Ну так если ещё и с SMP у суперсервера станет получше -- так и хорошо. Особенно если напишут нормальную документацию.
10 янв 08, 09:28    [5132203]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54850

DocAl
если ещё и с SMP у суперсервера станет получше

Это вполне вероятно (хоть и ненамного), а вот с документацией вряд ли.

Posted via ActualForum NNTP Server 1.4

10 янв 08, 09:32    [5132220]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
Dimitry Sibiryakov

DocAl
если ещё и с SMP у суперсервера станет получше

Это вполне вероятно (хоть и ненамного), а вот с документацией вряд ли.
Это небыстрый процесс, в MySQL и Inno последние несколько лет этой проблемой занимаются с особым приоритетом. Есть некоторые успехи, но линейно не масштабируются даже оракл с дб2. Собственно, поэтому меня так и взбесили сказки про фаербёрд.
10 янв 08, 09:46    [5132282]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30290
DocAI
Собственно, поэтому меня так и взбесили сказки про фаербёрд.

делайте скидку на терминологию. ясен пень, что линейного масштабирования не бывает в принципе. В смысле, не бывает 100% прироста при добавлении второго процессора, второго компа и так далее. Нигде.

Потом, никто не говорил, что FB масштабируется лучше чем другие СУБД. Соответственно, никто "сказок" не рассказывал. Если мне кто-то расскажет, что MySQL масштабируется линейно, я это пропущу мимо ушей, только и всего.
10 янв 08, 10:10    [5132386]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11578
DocAl
Есть некоторые успехи, но линейно не масштабируются даже оракл с дб2. Собственно, поэтому меня так и взбесили сказки про фаербёрд.
а) А что такое - линейно, по твоему ?
б) сказки тут рассказывает в основном Ё
10 янв 08, 10:35    [5132519]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
leonbn
Member

Откуда: СПб
Сообщений: 522
Ну вот и мир :))
10 янв 08, 11:10    [5132778]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 22 23 24 25 26 27 28 [29] 30 31   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить