Границы применимости решений

[metaclass]

Вот тут и тут идут практически идентичные срачи на тему "Зачем юзать (дорогую, энтерпрайзную, сложную) технологию А, если можно воспользоваться (простой, дешевой, десктопно-наколенной) технологией Б?".

А я, честно говоря, совсем уже потерял нить рассуждений, и не могу толком ответить на этот вопрос. Т.е. для меня вещи типа "бухгалтерию на dbf файлах в 2009 году не делают" и "mysql не является базой подходящей для систем со сложными расчетами и высокой нагрузкой" являются как бы самоочевидными, поэтому поиском аргументов на эту тему я себя никогда не утруждал.

Ну вот всегда, когда сталкивался с решениями на основе dbf (клариона, фокспро, клиппера, access, итд) - всегда очевидно, что разработчики блядь говно тупые уроды ебаные троечники по которым агрогородки плачут отстали от современных технологий, неважно по какой причине, соотвественно, они не способны принимать участие в современных разработках, у них нет для этого мыслительных категорий.
То же самое mysql, который в старых версиях, насколько я помню, вообще толком никакой логики на стороне сервера не содержал и транзакции умел только с одним типом хранилища. Для меня самоочевидно, что транзакции - это благо. И самоочевидно, зачем нужны вещи типа Software Transactional Memory и зачем нужны проверки целостности на стороне БД. Но большому количеству разработчиков это просто непонятно - я уже писал когда-то про попавшуюся под руки базу, в которой FK не было вообще.

С другой стороны - у меня в проекте Firebird молотит данные сотнями записей в секунду на обычном железе, с одновременными массовыми перерасчетами, и ничего. Хотя как бэ и СУБД тоже из разряда тех, на которые тупые линуксоиды наезжают в стиле "это же говно, потому что я так считаю".

И вот получается, что границы применимости решений (в данном случае СУБД) становятся совершенно непонятными. Очевидно, что при желании все недостатки отдельной СУБД можно обойти в программном коде. В экстремальных случаях это получится полное повторение функционала, уже существующего в другой СУБД, и это не всегда плохо - некоторые вещи настолько сделаны чрезмерно сложно и методом постепенного добавления фич, что переписывание с нуля их только улучшит.
Но вот где граница - "берем Postgresql, программиста и линуксоида на обслуживание" vs "покупаем Oracle, покупаем DBA, покупаем страшный софт за бешеные бабки и считаем что мы круты" - непонятно. Исключая, конечно, момент откатов за софт, тогда второй случай безальтернативен.

Comments

[theiced.livejournal.com]

>Oracle не нужен в 90% задач. Зато в тех 10% где он оправдывает себя - он делает это хорошо

я в том адовом треде вже писал. оракель нужен ТОЛЬКО в том случае если есть относительно большие (>100GB) объёмы данных и есть только тушкан мега-оракель-дба (ака тупое быдло ничего кроме рутинного обслуживания оракля не умеющая). постгре при больших объёмах всё же требует квалификации, но работает лучше.

Почему лучше:

1. быстрее
2. фичастее (а в оракле нетуть WITH RECURSIVE ня ня ня)
3. предсказуемее
4. можно _быстро_ получить вменяемую поддержку - что платную что на офф канале ирц - там и разработчики тусят и мощные визарды (мне вот в ирц за 15 минут оччччень нетривиальные вещи разжёвывали, брали мои 100меговые дампы и показывали на факапы за час итд - саппорт оракля который может ваш вопрос на пол года отложить тут рядом не срал).

[madeveloper.livejournal.com]

1. Быстрее под какой нагрузкой? На какой технике? Скока пользователей и характер запросов?
2. Нет. Потому что уже давно есть CONNECT BY. Списками фич не советую даже пытаться меряться.
3. Что, и хинты можно руками любые прописывать?
4. Ни разу не приходилось в суппорт обращаться. Зато обучиться можно вполне себе достойно.

[gds.livejournal.com]

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

нюню

[a-sure.livejournal.com]

Это мне напоминает историю с моим другом - его начальник пытался учить, как надо обращаться с б\п, считая себя более опытным - как-никак спалил2 штуки! То, что Серж за 10 лет не спалил ни одного, его как-то не убеждало.

Вы хотите сказать, что вопросы у вас НАСТОЛЬКО уникальны, что на них ответа нет даже на sql.ru ??? Пример можно ? (Хоть бы и в ЛС).

А насчет иродов - если у вас из личного авто будут из бака бензин регулярно пиздить, что, замочек не поставите?

Re: нюню

[gds.livejournal.com]

по-моему, у Вас что-то с чувством юмора. Однако мы это проедем, так как ещё чего не хватало. Давайте лучше о хорошем.

вопросы -- например, из недавнего, запрос

select
case when a=0 then 1 else 0 as res1,
case when b>c then 1 else 0 as res2,
case when a=0 and b>c then 1 else 0 as res3
from ...

в некоторых строчках выдавал res1=1, res2=1, res3=0.
Причём стабильно, перегрузка базы не помогала.
Благодаря зоопарку бд мы случайно обнаружили, что вызывает подобное поведение. Но -- зацените всю красоту!

Но это относительно самой базы данных. Радость доставляют также неимоверно кривые oracle forms + reports. Не передать.

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

Re: нюню

[kurilka.livejournal.com]

а что вызывает, если не секрет?

Re: нюню

[gds.livejournal.com]

параметр cursor_sharing. Было "similar" -- всё работало, поставили "exact" -- этот запрос стал глючить. Обидно тут то, что запросов -- несколько тысяч, и как-то печально, что оно такое хрупкое, и что от таких не относящихся к делу мелочей оно может молча давать неправильные данные.

Re: нюню

[a-sure.livejournal.com]

Способ разбора запроса ребе считает не относящейся к делу мелочью? Особенно в плане того, как относиться к литералам?!?
Зря.

Чтобы не сваливаться в оффтоп - вот еще один компонент "границы": наличие или готовность купить лицензию на ОРАКЛ.

Re: нюню

[metaclass.livejournal.com]

А причем тут способ разбора запроса и cursor_sharing, если поведение очевидно бредовое?

Re: нюню

[a-sure.livejournal.com]

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

"CURSOR_SHARING=SIMILAR causes statements that may differ in some literals, but are otherwise identical, to share a cursor by replacing the literals with system-generated bind variables, unless the literals affect either the meaning of the statement, or the degree to which the plan is optimized.

With CURSOR_SHARING=SIMILAR we look at replaced literals in some query predicates during optimization, to calculate the predicate selectivity. This is the normal effect of BIND PEEKING.
A side effect of this bind peeking is to potentially mark the bind as unsafe, so it is no longer shareable. This is done for range predicates (eg <, >=) or equality predicates in the presence of a histogram on the column. The purpose of this is to ensure we only share cursors when bind values lead to the same selectivity.

In 9i there was a problem (Bug 3668224) which meant that we could not peek bind variables in predicates if they were under operators, for example WHERE ENAME = UPPER(:b1).
The fix for this problem is in patchsets 9.2.0.6 and 10.2.0.3, but for 9i release it has to be explicitly enabled by setting event 38044.
There was also a follow-on problem (Bug 4359367) which meant that we were peeking excessively (in circumstances other than those appropriate for cursor_sharing=similar) but this is also fixed in 10.2.0.3."

Процесс разбора тоже документирован. Из касающихся вопроса - сначала идет проверка синтаксиса, потом, если сказано cursor_sharing=similar, литералы заменяются на псевдопеременные. Потом идет поиск уже разобранного запроса. И если находится такой же, то берется его план на исполнение. А сколько в тех запросах литералов, и как они раскиданы и что получается после bind_peeking - только по месту.

2) select case ... вкупе с упоминанием, что там тысячи таких, мне тоже нормальным не кажется. Но пока я не разобрался, откуда оно выросло - говном,хрупким и прочими эпитетами не разбрасываюсь.

Re: нюню

[metaclass.livejournal.com]

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

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

Re: нюню

[a-sure.livejournal.com]

1) запроса я не видел - только его начало
2) сколько похожих запросов, отличающихся только литералами, у них там еще?

Re: нюню

[plumqqz.livejournal.com]

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

Причем тут разработчики сервера? Есть два одинаковых запроса с разными параметрами - они имеют разные планы в зависимости от параметров, и выполняются, соответственно, по разному. (И разработчики сервера удолбались объяснять, что порядок строк без order by произвольный) Строки выборки, соответственно, могут идти в разном порядке. По всей видимости, приложение где-то неявно завязано на определенный порядок строк резалтсета - и в результате при его изменении получаем проблемы.

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

Виноват во всем, разумеется, Оракл.

Re: нюню

[gds.livejournal.com]

логику разбора и влияние данной опции на разбор и поиск плана я понимаю. На пару с дба честно накопали всю информацию, осмыслили, оба в ступоре. Более того, не представляете, как меня лично удивило влияние этой опции на выполнение запроса. Ещё может быть интересно, что по структуре этот запрос только один такой (не было других подобных; например, берущих из того же набора таблиц), и в нём нет bind variables вообще.
Пусть он заменяет литералы на bind variables, я не против (даже скорее за это), но зачем же неправильно вычислять результат применения "and" к двум предикатам? Один из ключевых моментов оптимизации -- неизменная семантика. А тут -- ёбаный стыд какой-то.

Re: нюню

[a-sure.livejournal.com]

1) он не заменяет литералы на Bind - я специально писал "псевдо". Мне счас негде уже (я дома) искать, но лежала где-то нота с металинка про поведение оптимизатора. Там скорее все литералы заменяются на одно и тоже для каждой позиции, после чего шарится в кеше уже разобранных запросов на предмет посимвольного совпадения.
2) второй источник засады - bind peeking, скорее всего именно эта штука вам всё и испортила. Это такой способ "припомнить", что было прошлый раз. И на основании этого строится план, в т.ч. и вычисление логики - "если первый предикат and уже ложен, второй вычислять не будем".


У каждого сложного продукта есть какие-то свои выверты, никуда ни денешься.

[madeveloper.livejournal.com]

Честно говоря, с Оракла я слез 7 лет назад. На 8.1.7 никаких хлопот небыло. Потом встречи стали эпизодическими ;)

[henu3detb.livejournal.com]

На нынешнем проекте постгрес шуршит на 8 терабайтах, и размер быстро растет. Оракл тоже используется, но только там, где без некоторых его фич просто не смогли обойтись.

[fas-tm.livejournal.com]

Верю. Поэтому дома ковыряю, привыкаю к нему.
Но на комплекс где стоит 100% MSSQL я не буду его ставить.
1. Админов местных надо обучать будет. Если эти лемминги испугаются и оперативно не подымут что то в течение получаса, то за невыход рекламы, на нас через суд повесят пару десятков штук ойро.
2. У нас нет 100Gb баз. 50Gb - да может быть, не больше.
3. У нас нет логики в базе.
4. Не вижу я смысла на Win юзать Postgree, MySQL, Oracle

Это не отменяет того что все остальные DB надо обязательно пощупать и выяснить те самы рамки применимости, о которых вопрошал автор корневого сообщения :)

[theiced.livejournal.com]

4. если у вас виндовз на серверах, то я вам просто сочувствую.

[metaclass.livejournal.com]

В РБ на госконторах виндовса на серверах 90% наверно. Юниксы промышленные - дорого, для линуксов линуксоидов которые бы обслуживали, не найти на ту зарплату и в тех ебенях.

[theiced.livejournal.com]

Ну так делайте дёшево и хреново, кто ж вам мешает ;))

[fas-tm.livejournal.com]

Андрей, спасибо за сочувствие. Но нам честно оно не нужно :)
Виндовый сервер для меня просто инструмент, его требует заказчик и платит деньги, при этом у нас есть отработанный набор инструментов для разработки обкатанные на куче проектов.
Точно так же мы работаем с Linux(для кластерных хранилок StorNext, ExaStore), MacOSX(для NLE станций).
Свои задачи WinServer выполняет. Как только Linux будет иметь инфраструктурные возможности (не просто "это в принципе можно наваять", а будет стандартно это делать) для наших задач и поддержка и сопровождение будет финансово выгодна - вопросов не будет.

[theiced.livejournal.com]

не ну требует заказчик говно - получает говно, вы получаете свои пару копеек, все довольны ;)

[a-sure.livejournal.com]

ребе, а по существу?

Вот работают третий год 5 серверов Вонь2003, Оракл 9.2.0.6.
Я плююсь, конечно, мне до них RDP ходить приходится в соседнюю область. Но проблемы были только с одним - распиздяям одминам моих 3х китайских предупрждений о том, что UPS надо настроить, было мало. Пришлось подключить главбуха.

Остальные 4 проблем за 3 года не вызвали. Может, таки начнем смотреть на задачу в комплексе? Или Вы готовы саппортить пол-россии в одно лицо?

[theiced.livejournal.com]

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