от МуМуМуМуЕще раз повторюсь, если приложение легко оптимизируется линейно - это самый правильный путь. Я говорю про класс задач в которых только линейной оптимизацией не справиться.
Вы опять не догоняете. Проблема не в параллелизации, не надо сводить из-за эмоций к простому за-против. Наоборот, я за параллелизацию.
Проблема не в этом. Самое главное достижение бизнеса, это формализация. Да именно бизнеса, вы не ослышались! Чем более формализован код, тем более он управляем. MS в отличие от оракакла это понимает и не даёт (скажем так - ставит палки в колёса) писать не формализованный код и не даёт ему шансов для выживания. Формализованный код можно распараллелить
автоматизированно т.к. формальность даёт получить критерии парралелизации, и вообще управляем. Вот соответственно уже есть механизмы в генераторе планов и таком инструменте как PDW.
Если вам дать написать неправильно, императивно (аля ASM) этот код мёртвый, его нельзя будет оптимизировать без его изменений и без разбирательства в нём. А если он формализован, и не размазан миллионами микрокоманд по тысячам процедур, а собран в единые запрос, то скуль составит более оптимальный план чем это сделает средний программист со всеми параллельностями на любом уровне. Только одна бяда - средний программист не умеет писать формализованно, как и мыслить. Но другого пути просто нет.
МуМус минимальными трудозатратами изменить таким образом что бы использовалось распараллеливание.Да хватит вам мечтать. Оставьте это нобелям, как нужно строить системы. Вы что спец по компиляторам и архитектурным решениям?!
МуМуЕсть открытых N сессий. Я указываю конструкцию по которой говорю что все эти сессии нужно связать(например spid-ы передаю, и какой нибудь уникальный идентификатор "обобщенной сессии"). После этого все блокировки в рамках сессий воспринимаются как общие, все изменения этих сессий идут в единой транзакции(т.е. если откатывается одна то откатываются все остальные) и что самое важное - они могут выполняться параллельно.Вы что специалист по ядру скуля, по кешированию планов, по оптимизатору блокировок. Явно видно что нет, так что не морочьте голову.
То что вы привели полный идиотизм. Зачем гдето что-то разделять, чтоб потом мучатся это собирать воедино. И бред и запутывание километрами ненужного кода. Передайте данные целиком логически, а там провайдер и сервер пусть сами параллелят. Кстати вы о технологии
MARS что-то знаете? Это так к слову.
МуМуПоверьте это не про меня. ...Сладки речи их ...
Да хоть семь пядей во лбу. Аргумент есть истина. А "авторитет" это этажом выше.
Можно сказать, что "слишком сказачно, чтобы быть правдой". Но если был бы спец, уже бы всё по полкам разжевал, а вы тупо проигнорировали
все аргументы, и ни на один не ответили. Вы что засланец, продвигаете ложные направления.
locky, спасибо что присоединились.
от alexeyvgalexeyvg, я не выступаю против. У меня просто на кое что аллергия.
alexeyvgЭтот путь не заменят никакие другие подходы (кроме распараллеливания на уровне сервера приложений). Нету никаких "другие имеющиеся N подходов". Точнее, может и есть, но как быть, если всё что можно уже сделано?
Это называется просто -непрофессионализм. Любая посильная проблема решаема, потолка нет.
Если система не параллелится, это либо невозможно физически, либо ваш код настолько убог что система не делает это сама.
Из моего опыта десятков корпоративных систем я не видел практически ни одной нормальной, они убоги на столько, что пути оптимизаций миллионы. И стоит проблема не в оптимальности, а низком уровне современных програмиздов и наплевательском отношении бизнеса.
Код можно совершенствовать бесконечно, было бы время и деньги, инструментов хватает, даже более того их настолько много, что это начинает многих путать. И кидаются на новое как красную тряпку.
Инструменты параллелизации уже есть и ещё будут, но данный вид это шаг назад.
Повторяю ещё раз, чтобы там говорить о новых механизмах, нужно понимать всё до уровня ядра и всей системы вцелом. В этом топике этим даже не пахнет.
alexeyvg... но при увеличении ядер это будет работать всё хуже и хуже.Да да, ну ещё раскажите мне про пролог, формальные системы и машины пятого поколения и теорию компиляторов.
Ой давайте не меряться пузами.
То что вы прошлись поверхностно по моим постам и сделали неправильный вывод о како-то неприязни к параллелизации или логики на сервере уже чего значит.
alexeyvgИ главное, (МуМу тоже писал) - сиквел покупают и используют совершенно не для написания оптимизированного кода, а для получения бабла. Только! для получения денег, больше ни для чего.Вот нинада ля-ля. У вас не будет аргументов на это.
Оракакл намного дороже и менее пристрастен к формализации. А если говорить про бизнес, то вокруг тысячи контор впаривающие говнокод на нём. Для MS систем такого намного меньше, и спасибо ему за это. Ой, ща такой срач начнётся.
Только не надо обобщать, у кого руки растут из правильного места уже неважно оракл это или MS. Просто пишу что вижу у себя в регионе, и мысли почему это так.
Гавриленко Сергей Алексеевичlockyформального анализа кода для t-sql... две большие таблицы лежат в разных файлгруппах ...Спеца видно издалека, хоть Сергея Алексеевича не знать нельзя. Ха-ха, теперь будем думать его мозгами.
Лично я выступал (неоднократно) в сторону другого коня в вакууме направления -
одновременное изменение сразу в нескольких таблицах, одной командой .
Сразу отвечу на последующие аргумент: Код либо связан логически (и физически, значит оправдано), или логика связывания вынесена на аппликейшн (а там уже есть механизмы), или они не в одной "транзакции".
Так вот, это даст лимон преимуществ:
дополнительные подсказки для админов
дополнительные направления в оптимизации блокировок
дополнительные направления в оптимизации запросов
По сути мы то и делаем в коде, что логический набор режем в последовательность команд по физических данным (таблицам). Зачем?!
Гавриленко Сергей Алексеевич, вы гений. Сразу видно что конкретно делать. Для начала (будем подводить мелкими шажками ) предложить MS такое:
1.
2.
3.
4.
5.
6.
WITH PARALLEL Statement1 AS (
INSERT ...
), Statement2 AS (
UPDATE ...
), StatementN AS (
DELETE ...
);
Естетственно, что с кучами ограничений.
С другой стороны, а нафиг менять код, уже пусть параллелят имеющийся. Факторы ограничений известны: изменяемые переменные ...
Но нижеследующее повествование отлагает. С другой стороны если на эти две таблы навешаны триггеры, то их логика может зависеть от последовательности изменений. Т.е. код потенциально может вести себя неадекватно.
Только если эти изменения раздельны, то данные будут разные от случая, а если изменения связаны одной командой, то данные всегда есть в наличии - цельные (см MERGE), но нет инструментов регулирования последовательности запуска триггеров, а это очень старая больная тема (см ещё OUTPUT).
