Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Параллельные вычисления для TSQL.  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Вы будете смеяться, но репликация это механизм, решение некоторой задачи, которая стоит выше. Давайте сразу поднимемся как можно выше.
Данный механизм, как и любой механизм имеет свой набор преимуществ и недостатков - такова его природа, заложенная создателем.
+
Буквально вчера я расписывал одному разработчику его ошибку, это когда взял N вещей смешал в одну кучу (по обще-коренному слову), а потом применял разделяя по признакам. Запрос работал чертовски долго, запрос был чертовски сложный. Когда задача была расписана и всё разделено всё стало чертовки просто, быстро и кода меньше.
Да, тяжело видеть всю картину вцелом. Но это обязательно.


МуМу
К каждой такой записи соответсвует номер транзакции. Важно что бы изменения применялись в рамках транзакции.
Вот, есть логическая часть - считать набор изменений единым, а есть физическая TRANSACTION. С чего вы взяли что это единые/неделимые вещи?!
+
Транзакции работают всё равно через состояния. Можно пометить состоянием любую логическую сущность, разделяя во времени процессы и меняя состояния. Остальная часть системы должна на эти состояния адекватно реагировать.

Почему записи имеющие единую "транзакцию" лежат разделено?
Почему записи просты (только I/U/D по одной строке)?

МуМу
Попадаются иногда очень большие транзакции
Почему и откуда?
Почему они используют именно этот механизм?

МуМу
Service Broker использовать - слишком сложно
Да задача вообще прям по нему плачет. Не?
SB - чертовски простая вещь.

Ещё не могу понять, у MS уже есть репликация. Возможно (скорее всего) она не к месту для этой задачи, с её текущими возможностями. Может стоит сформулировать вопрос именно в этом направлении.
MS - больше интерфейсов к системе репликаций!
Только опять, это пока абстрактно.
2 апр 11, 19:48    [10461732]     Ответить | Цитировать Сообщить модератору
 Re: Параллельные вычисления для TSQL.  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Не, ну конечно можно говорить часами, как можно ускорить этот процесс "репликации" и какие заложить в него эвристики (их куча). Решая туже задачу:
Как оптимально распределить решение в пространстве и времени.
2 апр 11, 20:00    [10461752]     Ответить | Цитировать Сообщить модератору
 Re: Параллельные вычисления для TSQL.  [new]
МуМу
Member

Откуда:
Сообщений: 1134
Сейчас я занимаюсь больше стратегией и управлением, а раньше в " полях" работал на проектах связанных с повышением производительности и с онлайн обменами большими данными(лично я курировал более 50-и проектов). Эти проекты были у клиентов. То есть системы разрабатывались не мной. Чего и как было исторически меня интересовало мало. Нужно было как правило получить здесь и сейчас результат, в нужный срок и нужный бюджет. Поэтому рассуждения на тему как распределить решения в "пространстве и времени" это оставляем для чистых теоретиков. Я могу так сказать что для системы репликации важен вопрос унификации. Не было как правило времени(бюджета) анализировать как можно изменить функционал клиента или тем более бизнеспроцессы клиента. Система должна быть надежной , легко управляемой и производительной. Есть вполне измеряемые вещи к которым при разработки мы стремились. Например скорость обмеена,время задержки - многопоточность в этом варианте просто жизненно необходима. Я понимаю что можно обойтись другими способами - но это извините, бизнес. Насчет того почему не используем стандартные механизмы? - на это есть своя причина. Но могу сказать так - вели переписку с разработчиками из рейдмонда(некоторые ошибки скидывали). Решение стандартное было разложено просто до винтиков. В том числе я выступал не раз на конференциях и втом числе на MSSQL club на тему типовой репликации. Поэтому не хотелось бы вдаваться в дискуссию почему мы используем свой механизм. Это тема немного другая.
2 апр 11, 22:47    [10462294]     Ответить | Цитировать Сообщить модератору
 Re: Параллельные вычисления для TSQL.  [new]
МуМу
Member

Откуда:
Сообщений: 1134
Это была предистория. Теперь по существу.
Во первых по поводу транзакции. Я вам скажу с практической точки зрения. Пускай система работает надежно 99 процентов времени, но потом происходит перезагрузка сервера и т.п. В этом случае есть шанся того что определенная часть "разделенной" транзакции окажется не примененной. Есть конечно свой "лог", есть инструменты для автоматического наката, есть верификация и т.п. но они имеют ряд недостатков. Сервис может почему то не запуститься, "накат" может не пройти потому что уже произошел конфликт и автоматичеки это сделать нельзя и т.д. и т.п. Рассказывать клиенту о всех этих особенностях поверьте дело неблагодарное. Для клиента все просто. На одном севрере данные одни а на другом другие(на некоторый интеравл времени). Все остально его не волнует.
2 апр 11, 22:55    [10462327]     Ответить | Цитировать Сообщить модератору
 Re: Параллельные вычисления для TSQL.  [new]
МуМу
Member

Откуда:
Сообщений: 1134
Что касается записей.Почему они находятся в разных записях? Принцип простой. Автоматически генерируются триггеры. Эти триггеры добавляют записи в таблицы об измененных данных.Можно было бы писать в блоб поля и т.п.(вплоть до того что даже сжимать сразу) но это влияло бы на основную систем что не допустимо.(система репликации должна отбирать производительности не более 10%). Для создания своей транзакционной репликации других инструментов от микрософт нет.
2 апр 11, 23:01    [10462349]     Ответить | Цитировать Сообщить модератору
 Re: Параллельные вычисления для TSQL.  [new]
МуМу
Member

Откуда:
Сообщений: 1134
Теперь что касается длинных транзакций.
У клиента есть мониторинг как производительности, так и репликации. Система постоянно оптимизируется. Но тем не менее иногда у него возникают действительно "большие" транзакции. Т.е. допустим происходит в транзакции куча апдейтов за длительный интервал времени. На основную систему это не влияет потому как блокировок не создает. В ряде случае апдейты идут массовые а репликатор их иногда применяет по записи в силу объективных причин(и давайте на эту тему хотя бы не спорить а то спор вообще уйдет в другую тему). Если эти изменения применять в одном потоке - подобная транзакция введет большое время рассинхронизации. Что разумеется не приемлимо.
В общем почему длинные транзакции ? - Так сложилось, объективно нужно и самое главное я на это влиять не могу!
2 апр 11, 23:07    [10462371]     Ответить | Цитировать Сообщить модератору
 Re: Параллельные вычисления для TSQL.  [new]
МуМу
Member

Откуда:
Сообщений: 1134
Насчет Service Broker. Извините, но я нигде не говорил что применять его сложно! Посмотрите переписку , эта фраза принадлежит не мне.
Давайте рассмотрим следующий пример.
Обращается ко мне клиент. Вот система тормозит. Включаем мониторинга и т.п. Проводим линейную оптимизацию(индексы, запросы и т.п.) Сразу скажу, что структуру как правило менять существенно нельзя- нет времени, нет бюджета.
Затем видим что основной вариант для оптимизации это распараллеливание(как правило для регламентных задач).
Предположим что весь код на T-SQL. На данный момент после этого необходимо бить код на части после чего он становиться не читабельным и плохо споровождаемым. Реализовывать координатор соединений. Реализовывать интерфейсы взаимодействия. Предусматривать вопросы некорректной обработки, аварийных отключений и т.п.
Что было бы идеально. Для этого кода включаем специальный режим. Далее использую синтаксис от MSSQL указываем в коде что можно паралеллить а что нельзя, прописываем интерфейсы(но они будут более унифицированными), указываем параметры для координатора потоков.(сколько максимально потоков открывать, и т.п.). Вообщем была бы большая унификация а также вопросы связанные с координацией потоков мог бы для ряда задач взять на себя MSSQL. Ну и про транзакции не забываем, все накатывал-откатывал бы автоматом сервер. Подобные проблемы редко - но выстреливают.
2 апр 11, 23:19    [10462428]     Ответить | Цитировать Сообщить модератору
 Re: Параллельные вычисления для TSQL.  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
МуМу
Поэтому рассуждения на тему как распределить решения в "пространстве и времени" это оставляем для чистых теоретиков.
Вы совершенно неправы. Это ежедневная, ежесекундная кропотливая работа. Работа практически из этого и состоит без отлагательств.

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

МуМу
Я могу так сказать что для системы репликации важен вопрос унификации.
Который совершенно не подразумевает делать кашу из топора. Над хорошей мега-пупер системой надо думать и всесторонне обдумывать и развивать.

МуМу
Я понимаю что можно обойтись другими способами - но это извините, бизнес.
А вы, как обычный менеджер, хотите всё из ничего. Простая идея, топорная реализация. Старая песня. Лопату ему подавай, понимаешь.

Боже сколько воды, соплей, кичась налево и направо, мать родная.
И пока мы видим один лишь невразумительный пример.
МуМу
Это была предистория. Теперь по существу.
Сразу бы.

МуМу
Во первых по поводу транзакции. ... но потом происходит перезагрузка сервера и определенная часть "разделенной" транзакции окажется не примененной.
О боже, не держите нас за идиотов. Уже 120% понятно что вы нифига не врубились. Не верится что вы написали такое.
После перезагрузки состояние системы будет ровно такой же, как до падения сервера - полностью. И части этих кусочков продолжатся сначала восполняя всю мозаику до конца.
Меня больше всё ужасает то, что вы приводите аргументы которые применимы к любому подходу. Какая разница, не прошла одна транзакция и ста или ваша одна единственная.
Пост пролетел как фанера. Перейдём к следующему.

МуМу
Что касается записей.
[censored]
Что вы скажете об этом.
Надеюсь я правильно понял, читая между строк.
Ощущение, что вы пытаетесь конкурировать с самим MS на их же поле. Зачем?! Если вас не устраивает какая-то мелочь в их продуктах (репликация/зеркалирование/нотификации и т.п.) - требуйте её, а не эти непонятные "параллельные вычисления".

МуМу
Теперь что касается длинных транзакций.
.. (и давайте на эту тему хотя бы не спорить а то спор вообще уйдет в другую тему)
Баттхёрт детектед. Предупреждал же в начале. Кароче объективностью пример не страдает.
МуМу
В общем почему длинные транзакции ? Так сложилось, объективно нужно и самое главное я на это влиять не могу!
Именно! Не стоит теперь требовать физически невозможного, при заявленных условий. Слава богу MS не шла по этому пути. Их механизм работает приемлемо. Хотя конечно же есть свои ограничения, но это уже к спецам.

Ставим линию разрыва, из-за бесполезности всего выше сказанного.
------------------------------------------------------------------------------------------------------------

МуМу
Сразу скажу, что структуру как правило менять существенно нельзя- нет времени, нет бюджета.
Затем видим что основной вариант для оптимизации это распараллеливание(как правило для регламентных задач).
Старая песня:
Две крайности: существенные изменения <-> надуманные оптимизации. И ничего между ними. А между ними то бесконечность.
Вы что эти 50 проектов в режиме copy-paste делали?
Нет, я конечно могу понимать реалии корпоративной убогости систем, но если проект не имеет шансов, туда ему и дорога.
Ведение проектов это вам не в приферанс играть. Хотите выжить, думайте заранее, какие проблемы могут возникнуть заранее известно ещё на стадии проектирования.

МуМу
На данный момент после этого необходимо бить код на части после чего он становиться не читабельным и плохо споровождаемым...
Говно-менеджмент?

МуМу
Что было бы идеально.
Указываем в коде что можно паралеллить, указываем параметры для координатора потоков.
Воду вырезал. Хотя опять нет конкретики.
Эм. И к чему пришли.
  • MS уже параллелит что можно, остально нельзя физически (или обращайтесь к оптимизаторам генератора планов).
  • Если поднятся на уровне блоков, SB работает именно так, как вы там пишете э... "интерфейсы/координаторы"
  • Слово Указываем в коде означает что логика проекта поднята, т.е. разрабы понимают модель системы, проблемные места. (Не?) Тогда зачем растрачивать буджет и время на оттягивание неизбежного, а не тупо решить проблему?!
  • Слишком абстрактно представляете, наделяя магической силой. Вот распишите прям тут этот ваш параллелизованный интерфейс. Почемуто уверен, что в в 80% случаев он будет совершенно неприменим на практике. Вам то не знать реалии говно-кода. Ключевая фраза: критерии параллелизации. Им негде взяться в конкретном месте кода, иначе см. 1.п.

    Если я правильно понял вашу задачу, как автоматизация продления жизни говно-кода. Могу сказать, смотря в эту абстрактность, что написать такую обёртку использующую SB со всеми транзакциями вроде не сложно, и будет вам унификально. Но требовать это из каропки от MS идиотизм. Вы можете это попросить у оракакла, но мелкие на это не поддадутся (во всяком случае так было до этого), тем более что никакого профита. Они не будут рыть яму себе, повышая уровень мелких некомпетентных клиентов. Нет денег на нормальный IT - сдохни, но мы не благотворительная компания.
  • 3 апр 11, 02:19    [10462695]     Ответить | Цитировать Сообщить модератору
     Re: Параллельные вычисления для TSQL.  [new]
    МуМу
    Member

    Откуда:
    Сообщений: 1134
    То Mnior
    Извините но на демагогию у меня нет времени. Вы говорите про конкретику, но ваши сообщения сводятся к тому что не нужно писать говнокод и т.п, я привильно понимаю? То есть вы смотрите со стороны исключительно разработчика которого вопросы бизнеса а в частности рентабельности и прибыли не интересуют абсолютно. У нас работают специалисты высокого уровня, тем не менее в некоторых программных продуктах пишется код мягко говоря не самый "оптимальный". В большинстве случаев это делается сознательно, потому как еще есть сроки за которые спрашивают. Есть еще бизнесплан с предпологаемой жизнью продукта. Поэтому утверждение о том что каждый разработчик должен писать "идеалный" код оставим для идеалистов. В тех же штатах очень много устаревших и тем не менее крупных и работающих ИТ систем. Их почему то никто не торопиться менять. Потому как затраты очень и очень большие, и простои от остановки ИТ системы в переходный период период могут вообще закрыть бизнес.
    Я вам привел конкретные аргументы, от вас таковых не получил. Поэтому предлагаю вам в моей ветке больше не дискутировать. Будем считать что я вам не смог объяснить. А примеры кода с своими предложениями, как я уже говорил, обязательно выложу, Если будет интересно потом почитаете.
    3 апр 11, 09:53    [10462794]     Ответить | Цитировать Сообщить модератору
     Re: Параллельные вычисления для TSQL.  [new]
    alexeyvg
    Member

    Откуда: Moscow
    Сообщений: 31355
    Mnior
    При надуманной В абстрактной проблеме можно уйти в схоластику и множественный подмен понятий.
    С ваших же слов:
    alexeyvg
    Нужно формулировать потребности и говорить об этом Microsoft-у
    Ну да, нужно формулировать (описывать бизнес сценарии и т.п.) Мы же только начали, пока есть только есть ощущения о том, что всё это необходимо, но больше ничего нет. Вот и начинаем формулировать.

    Mnior
    alexeyvg
    Это как?
    Очень просто, много абстрактных слов, мало конкретики.
    МуМу говорит "я практик", б.м. так давайте говорить о конкретной задаче, или точнее наборе конкретных задач.
    Если их обсуждение уйдёт в срач (в разные подходы и т.п.) значит "проблема надуманная", если нет то тогда "я плохо понял тему/вы плохо описали".
    Не все согласны с вашим тезисом о том, что работа с бизнес-логикой должна быть обязательно вынесена из СУБД. Собственно, все ваши возражения по теме относятся только к этому.

    Конечно, если БЛ выносить наружу, то проблем нету - на сервер СУБД посылаются только одиночные запросы, сервер их прекрасно распаралеливает, всё остальное (основное) распаралеливание берёт на себя сервер приложений.

    Но если логика работы с данными лежит в СУБД, то ситуация другая.
    К серверу идут запросы (вызовы ХП). Запросы средней сложности, ракспаралеливаются не всегда, к тому же распаралеливание ограничено теоретически (не всегда запрос можно будет эффективно распаралелить на тыщу потоков).

    Вполне можно расщепить потоки ещё в несколько раз.

    Mnior
    В чем отличие напрмиер от того же PDW?
    Как минимум, почему тут не рассматривается PDW - потому что это не специальная паралельная версия сиквела. PDW - это программно-аппаратный комплекс, сделанный под конкретную область применения на конкретном оборудовании.
    3 апр 11, 10:29    [10462829]     Ответить | Цитировать Сообщить модератору
     Re: Параллельные вычисления для TSQL.  [new]
    alexeyvg
    Member

    Откуда: Moscow
    Сообщений: 31355
    МуМу
    Я вам привел конкретные аргументы, от вас таковых не получил. Поэтому предлагаю вам в моей ветке больше не дискутировать.
    Как я понял, аргумент Mnior такой - не нужно программировать на сиквеле.

    Сиквер должен выполнять только одиночные запросы, всё остальное должен делать клиент или сервер приложений.

    При таком подходе действительно ничего менять не надо, всё и так хорошо.

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

    И вот как раз совершенствование средств работы с БЛ (не только распараллеливание) я считаю важной задачей для разработчиков сиквела.
    3 апр 11, 10:42    [10462842]     Ответить | Цитировать Сообщить модератору
     Re: Параллельные вычисления для TSQL.  [new]
    Mnior
    Member

    Откуда: Кишинёв
    Сообщений: 6723
    МуМу
    ... но ваши сообщения сводятся к тому что не нужно писать говнокод и т.п, я привильно понимаю?
    Нет!
    Есть говно-код написанный недо-программистом и говно-код написанный профессионалом (неоптимальный). Разница в том, что во втором случае известно где и куда и как копать в сторону оптимизации и у него "остаётся место для разворота".
    Т.е. ПМ управляет будущей архитектурой системы согласно составленным планам и срокам. Если этого нет, то значит даже и тупой говно-код скорее всего пишется не в сроки.
    Планы и сроки не заканчиваются сдачей проекта, туда включены и планы и сроки и методы по его допиливанию. Этим бизнес и управляет.

    А когда ВНЕЗАПНО прибегают, у нас бяда, Houston, we have a problem. А если ещё при этом бюджет нулевой. То повторяю - ничего не поможет, хоть имея 100500 механизмов включая этот. Это было конкретно описано в конце моего предыдущего поста.

    МуМу
    Их почему то никто не торопиться менять. Потому как затраты очень и очень большие, и простои от остановки ИТ системы в переходный период период могут вообще закрыть бизнес.
    Это что агрумент по теме? Даже если появится этот конь, то только в следующей версии. А у них системы далеко не на 2000х серверах, если ваабще на MS-е.

    МуМу
    Я вам привел конкретные аргументы, от вас таковых не получил.
    Вот давайте не надо. Вы привели аргументы. Они все контр-аргументами отброшены. Хотя я почемуто замечаю, что вы их словно не читаете или боитесь признать.
    На какой аргумент не отвечено конкретно?

    МуМу
    Поэтому предлагаю вам в моей ветке больше не дискутировать.
    Старая песня. Тут нет вашей или моей ветки, тут есть тема и аргументы. Аргументы не нравятся - это ваши проблемы. Притом что не я за язык тянул, а вы меня попросили. И я вас предупреждал, что будет срач, и заранее знал, что кто-то закроет глаза на явные аргументы.

    МуМу
    Будем считать что я вам не смог объяснить.
    Нет, дорого мой, это значит вы никому не объяснили. Этот топик прочитают тысячи, не надо отводить каждого к частному случаю.
    ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
    alexeyvg
    Ну да, нужно формулировать (описывать бизнес сценарии и т.п.) Мы же только начали, пока есть только есть ощущения о том, что всё это необходимо, но больше ничего нет. Вот и начинаем формулировать.
    Хоть вы понимаете, что мы имеем реально на руках. Спасибо хоть за это.
    Считаем аргумент с конём засчитан?

    Нужно не просто предполагать что что-то там можно распараллелить и мечтать об этом, нужно чётко знать как это можно сделать во всех встреченных местах кода. Это раз. И чётко высчитать, что затраты на изменение кода в параллельность дешевле чем изменение кода в оптимальность или другие имеющиеся N подходов, притом с затратами бизнеса и на будующее. Это два.

    alexeyvg
    Mnior
    Если их обсуждение уйдёт в срач (в разные подходы и т.п.) значит "проблема надуманная", если нет то тогда "я плохо понял тему/вы плохо описали".
    Не все согласны с вашим тезисом о том, что работа с бизнес-логикой должна быть обязательно вынесена из СУБД. Собственно, все ваши возражения по теме относятся только к этому.
    Вы совсем не угадали. Уж скорее ярый фанат оставлять всё на сервере.
    Но не люблю крайности. Да, сейчас модно вообще всё выносить из СУБД, и меня крайне бесит, когда это пропагандируется как единственный верный путь. Просто постоянно встречаются случаи когда пихают в сервер всё подряд и логику конкретного клиента.
    Архитектура системы требует расслоений. И в сиквеле должна быть сосредоточена бизнес-логики логической модели, т.е. отражение логической модели на физическую (схему данных). Всё что выше интерфейса логической модели системы должно быть вынесено в сервер аппликейшн и клиент, там сосредоточена логика взаимодействия и отображения.

    Так что ваши дальнейшие предположения были не верны.

    alexeyvg
    к тому же распаралеливание ограничено теоретически
    Именно.
    Давайте я за вас сформулирую:
    Существую вещи которые можно распараллелить, но автоматизировать это нельзя. Замечательно. Но я привёл аргументы выше:
  • Это вопрос к оптимизаторам планов
  • Это всё абстрактно, нужна конкретика и знание модели, бла-конь-бла тут не помогут
  • Решение ограниченно и плохо применимо. Ключевое слово: критерии параллелизации.

    alexeyvg
    Mnior
    В чем отличие напрмиер от того же PDW?
    Как минимум, почему тут не рассматривается PDW - потому что это не специальная паралельная версия сиквела. PDW - это программно-аппаратный комплекс, сделанный под конкретную область применения на конкретном оборудовании.
    Ну я понял уже, что всё сводится к препарированию трупов.

    Повторю ещё одну вещь, которую я вижу постоянно. Если вы что-то делаете очень много раз, вы в итоге это делаете в 100500 раз быстро и качественно. Что до этого считалось немыслимо дорого по сравнению с другими вариантами, после считается наоборот - непомерно дёшево. Поэтому нет одинаковых бизнес планирований. Поэтому чаще выступаю за оптимизацию кода, а не за закрытие на это глаза.
    Если вам надо выиграть время, SB должен помочь, как временное решение.
  • 3 апр 11, 15:17    [10463568]     Ответить | Цитировать Сообщить модератору
     Re: Параллельные вычисления для TSQL.  [new]
    МуМу
    Member

    Откуда:
    Сообщений: 1134
    То minor. Я понял ваши аргументы но меня они не убедили, как впрочем и мои видимо вас. Еще раз повторюсь, если приложение легко оптимизируется линейно - это самый правильный путь. Я говорю про класс задач в которых только линейной оптимизацией не справиться. Сейчас такие задачи решаем и решаем успешно, правда как правило управление распараллеливанием реализовывается на уровне приложения. Чего не хватает? Один из примеров я уже написал и напишу его еще раз ниже.(насчет распараллеливания в одной транзакции)
    Что еще не хватает? Того что бы прийти к клиенту посмотреть только T-SQL код - линейно оптимизировать его а если уже дальше не получается взять и с минимальными трудозатратами изменить таким образом что бы использовалось распараллеливание. Причем целиком и полностью на T-SQL, что бы это было читабельно и что бы можно было бы легко сопровождать клиенту. Вы скажете что слишком вообщем? - Я уже сказал что чуть позже(думаю в течении недели) я напишу конкретные предложения с конкретными примерам.

    Напишу один из примеров - конкретно что мне нужно.
    Есть открытых N сессий. Я указываю конструкцию по которой говорю что все эти сессии нужно связать(например spid-ы передаю, и какой нибудь уникальный идентификатор "обобщенной сессии"). После этого все блокировки в рамках сессий воспринимаются как общие, все изменения этих сессий идут в единой транзакции(т.е. если откатывается одна то откатываются все остальные) и что самое важное - они могут выполняться параллельно.
    3 апр 11, 15:44    [10463649]     Ответить | Цитировать Сообщить модератору
     Re: Параллельные вычисления для TSQL.  [new]
    locky
    Member

    Откуда: Харьков, Украина
    Сообщений: 62034
    в 99% случаев желание "распараллелить" проистекает от нежелания оптимизировать, в частности - хотя бы немного подумать об индексах, о формальной оптимальности кода и т.д.
    3 апр 11, 15:53    [10463682]     Ответить | Цитировать Сообщить модератору
     Re: Параллельные вычисления для TSQL.  [new]
    alexeyvg
    Member

    Откуда: Moscow
    Сообщений: 31355
    Mnior
    alexeyvg
    Ну да, нужно формулировать (описывать бизнес сценарии и т.п.) Мы же только начали, пока есть только есть ощущения о том, что всё это необходимо, но больше ничего нет. Вот и начинаем формулировать.
    Хоть вы понимаете, что мы имеем реально на руках. Спасибо хоть за это.
    Считаем аргумент с конём засчитан?
    Об этом и говорили с самого начала - да, сейчас только первый этап.

    Что, если возникает идея, то её нельзя озвучить, пока не появился нормальный востребованный продукт, её реализующий???

    Кстати, непонятно, почему вы так-же яростно не выступаете против других внедрений распараллеливания, например в PDW или в SQL Azure??? Видимо, просто ничего уже не поделать, продукты продаются и остаётся только горько рыдать? :-)

    И зачем покупают этот PDW за 10 лимонов, нужно просто сделать "изменение кода в оптимальность или другие имеющиеся N подходов" :-)

    Mnior
    Нужно не просто предполагать что что-то там можно распараллелить и мечтать об этом, нужно чётко знать как это можно сделать во всех встреченных местах кода. Это раз. И чётко высчитать, что затраты на изменение кода в параллельность дешевле чем изменение кода в оптимальность или другие имеющиеся N подходов, притом с затратами бизнеса и на будующее. Это два.
    Есть совершенно конкретное предложение по повышению производительности путём распаралеливания потока выполнения.

    Этот путь не заменят никакие другие подходы (кроме распараллеливания на уровне сервера приложений). Нету никаких "другие имеющиеся N подходов". Точнее, может и есть, но как быть, если всё что можно уже сделано?

    Mnior
    Повторю ещё одну вещь, которую я вижу постоянно. Если вы что-то делаете очень много раз, вы в итоге это делаете в 100500 раз быстро и качественно. Что до этого считалось немыслимо дорого по сравнению с другими вариантами, после считается наоборот - непомерно дёшево. Поэтому нет одинаковых бизнес планирований. Поэтому чаще выступаю за оптимизацию кода, а не за закрытие на это глаза.
    Если вам надо выиграть время, SB должен помочь, как временное решение.
    Теперь, значит, ваше предложение - просто нужно писать код оптимальнее, а выпуск многоядерных серверов прекратить :-)

    Бывает, знаете, люди пишут код не хуже вас (представляете???), и он вполне оптимальный.
    Но вот беда - потоков выполнения от клиента только 10 (ну просто пользователей столько), а ядер 100, и загружается только десятая часть ресурсов.

    А через 10 лет ядер в типичном дешёвом сервере будет 1000, и будет ещё хуже. Сейчас то обычно для потока тяжёлых запросов делается распаралеливание на уровне запроса, но при увеличении ядер это будет работать всё хуже и хуже.
    3 апр 11, 15:59    [10463704]     Ответить | Цитировать Сообщить модератору
     Re: Параллельные вычисления для TSQL.  [new]
    МуМу
    Member

    Откуда:
    Сообщений: 1134
    То locky. Поверьте это не про меня. У компании более 250-и проектов по оптимизации у крупных корпоративных клиентов. Задача линейной оптимизации поставлена на поток. Есть свои средства мониторинга которые показывают сколько дает вклад в нагрузку конкретная строчка кода(это поверьте не так уж тривиально) и многое,многое другое. Есть люди которые занимают отдельно вопросами оптимизации индексов и запросов, есть которые занимаются вопросами разработки оптимальной структуры, блокировочными механизмами, моделирования нагрузки и т.д. и т.п. (Есть даже экспертная система который парсит переданные из мониторинга тяжелые запросы после чего предлагает возможные варианты оптимизации запросов автоматом.) Просто есть класс задач который после линейной оптимизации кроме как распараллеливанием эффекта существенного не дает.
    3 апр 11, 16:02    [10463712]     Ответить | Цитировать Сообщить модератору
     Re: Параллельные вычисления для TSQL.  [new]
    alexeyvg
    Member

    Откуда: Moscow
    Сообщений: 31355
    locky
    в 99% случаев желание "распараллелить" проистекает от нежелания оптимизировать, в частности - хотя бы немного подумать об индексах, о формальной оптимальности кода и т.д.
    Ну может и не в 99%, вы всё таки немного преувеличиваете :-)

    И главное, (МуМу тоже писал) - сиквел покупают и используют совершенно не для написания оптимизированного кода, а для получения бабла. Только! для получения денег, больше ни для чего.

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

    И тот, кто поступит по другому - будет последний непрофессионал. Профессионал принимает решения исходя из требований бизнеса, а не исходя из красивости кода.
    А тот, кто предоставит для этого инструменты, и будет лидировать на рынке СУБД :-)

    Это не значит, что весь код должны писать студенты и что обязательно они сделают плохо, но очень часто бывает именно так и часто это правильно.
    3 апр 11, 16:12    [10463750]     Ответить | Цитировать Сообщить модератору
     Re: Параллельные вычисления для TSQL.  [new]
    locky
    Member

    Откуда: Харьков, Украина
    Сообщений: 62034
    alexeyvg,

    значит нужно развивать инструменты для формального анализа кода для t-sql, коих увы на рынке нет
    для того же шарпа есть решарпер, который мала-мала, но кривые и косые места (да, не все) показывает и подсказывает.
    Да и, если мне не изменяет маразма, для си/шарпа/паскаля было много тулов по статическому анализу кода
    а для скуля последним был MSBPA, для 2000, кажется.
    3 апр 11, 16:15    [10463764]     Ответить | Цитировать Сообщить модератору
     Re: Параллельные вычисления для TSQL.  [new]
    Гавриленко Сергей Алексеевич
    Member

    Откуда: Moscow
    Сообщений: 36968
    locky
    значит нужно развивать инструменты для формального анализа кода для t-sql, коих увы на рынке нет
    Не поможет. Потому что скульный код - это не только код сам по себе, но и все те данные, которые он обрабатывает.

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

    Вот тут и начинаешь думать, нужна ли эта целостность с этой общей транзакцией, или может ну ее, джобами параллельно зафигачим?..

    Сообщение было отредактировано: 3 апр 11, 21:14
    3 апр 11, 21:13    [10464472]     Ответить | Цитировать Сообщить модератору
     Re: Параллельные вычисления для TSQL.  [new]
    locky
    Member

    Откуда: Харьков, Украина
    Сообщений: 62034
    Гавриленко Сергей Алексеевич,

    скажем так.
    тот факт, что нельзя однозначно и гарантированно покрыть 100%, и даже 90% кодо-случаев вовсе не означает, что не надо стараться/пробовать покрыть хотя-бы 30-40% случаев.
    потому как случаи бывают крайне разные, иногда даже вопиющие.
    3 апр 11, 22:03    [10464650]     Ответить | Цитировать Сообщить модератору
     Re: Параллельные вычисления для TSQL.  [new]
    alexeyvg
    Member

    Откуда: Moscow
    Сообщений: 31355
    locky
    значит нужно развивать инструменты для формального анализа кода для t-sql, коих увы на рынке нет
    С этим не спорю - думаю, такие средства помогут очень многим.
    3 апр 11, 22:41    [10464870]     Ответить | Цитировать Сообщить модератору
     Re: Параллельные вычисления для TSQL.  [new]
    Mnior
    Member

    Откуда: Кишинёв
    Сообщений: 6723
    + от МуМу
    МуМу
    Еще раз повторюсь, если приложение легко оптимизируется линейно - это самый правильный путь. Я говорю про класс задач в которых только линейной оптимизацией не справиться.
    Вы опять не догоняете. Проблема не в параллелизации, не надо сводить из-за эмоций к простому за-против. Наоборот, я за параллелизацию.
    Проблема не в этом. Самое главное достижение бизнеса, это формализация. Да именно бизнеса, вы не ослышались! Чем более формализован код, тем более он управляем. MS в отличие от оракакла это понимает и не даёт (скажем так - ставит палки в колёса) писать не формализованный код и не даёт ему шансов для выживания. Формализованный код можно распараллелить автоматизированно т.к. формальность даёт получить критерии парралелизации, и вообще управляем. Вот соответственно уже есть механизмы в генераторе планов и таком инструменте как PDW.

    Если вам дать написать неправильно, императивно (аля ASM) этот код мёртвый, его нельзя будет оптимизировать без его изменений и без разбирательства в нём. А если он формализован, и не размазан миллионами микрокоманд по тысячам процедур, а собран в единые запрос, то скуль составит более оптимальный план чем это сделает средний программист со всеми параллельностями на любом уровне. Только одна бяда - средний программист не умеет писать формализованно, как и мыслить. Но другого пути просто нет.

    МуМу
    с минимальными трудозатратами изменить таким образом что бы использовалось распараллеливание.
    Да хватит вам мечтать. Оставьте это нобелям, как нужно строить системы. Вы что спец по компиляторам и архитектурным решениям?!

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

    То что вы привели полный идиотизм. Зачем гдето что-то разделять, чтоб потом мучатся это собирать воедино. И бред и запутывание километрами ненужного кода. Передайте данные целиком логически, а там провайдер и сервер пусть сами параллелят. Кстати вы о технологии MARS что-то знаете? Это так к слову.

    МуМу
    Поверьте это не про меня. ...
    Сладки речи их ...
    Да хоть семь пядей во лбу. Аргумент есть истина. А "авторитет" это этажом выше.
    Можно сказать, что "слишком сказачно, чтобы быть правдой". Но если был бы спец, уже бы всё по полкам разжевал, а вы тупо проигнорировали все аргументы, и ни на один не ответили. Вы что засланец, продвигаете ложные направления.

    locky, спасибо что присоединились.

    + от alexeyvg
    alexeyvg, я не выступаю против. У меня просто на кое что аллергия.

    alexeyvg
    Этот путь не заменят никакие другие подходы (кроме распараллеливания на уровне сервера приложений). Нету никаких "другие имеющиеся N подходов". Точнее, может и есть, но как быть, если всё что можно уже сделано?
    Это называется просто -непрофессионализм. Любая посильная проблема решаема, потолка нет.
    Если система не параллелится, это либо невозможно физически, либо ваш код настолько убог что система не делает это сама.
    Из моего опыта десятков корпоративных систем я не видел практически ни одной нормальной, они убоги на столько, что пути оптимизаций миллионы. И стоит проблема не в оптимальности, а низком уровне современных програмиздов и наплевательском отношении бизнеса.
    Код можно совершенствовать бесконечно, было бы время и деньги, инструментов хватает, даже более того их настолько много, что это начинает многих путать. И кидаются на новое как красную тряпку.
    Инструменты параллелизации уже есть и ещё будут, но данный вид это шаг назад.
    Повторяю ещё раз, чтобы там говорить о новых механизмах, нужно понимать всё до уровня ядра и всей системы вцелом. В этом топике этим даже не пахнет.

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

    alexeyvg
    И главное, (МуМу тоже писал) - сиквел покупают и используют совершенно не для написания оптимизированного кода, а для получения бабла. Только! для получения денег, больше ни для чего.
    Вот нинада ля-ля. У вас не будет аргументов на это.
    Оракакл намного дороже и менее пристрастен к формализации. А если говорить про бизнес, то вокруг тысячи контор впаривающие говнокод на нём. Для MS систем такого намного меньше, и спасибо ему за это. Ой, ща такой срач начнётся.
    Только не надо обобщать, у кого руки растут из правильного места уже неважно оракл это или MS. Просто пишу что вижу у себя в регионе, и мысли почему это так.


    Гавриленко Сергей Алексеевич
    locky
    формального анализа кода для t-sql
    ... две большие таблицы лежат в разных файлгруппах ...
    Спеца видно издалека, хоть Сергея Алексеевича не знать нельзя. Ха-ха, теперь будем думать его мозгами.

    Лично я выступал (неоднократно) в сторону другого коня в вакууме направления - одновременное изменение сразу в нескольких таблицах, одной командой.

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

    По сути мы то и делаем в коде, что логический набор режем в последовательность команд по физических данным (таблицам). Зачем?!
    +
    Гавриленко Сергей Алексеевич, вы гений. Сразу видно что конкретно делать. Для начала (будем подводить мелкими шажками ) предложить MS такое:
    WITH PARALLEL Statement1 AS (
    	INSERT ...
    ), Statement2 AS (
    	UPDATE ...
    ), StatementN AS (
    	DELETE ...
    );
    Естетственно, что с кучами ограничений.
    С другой стороны, а нафиг менять код, уже пусть параллелят имеющийся. Факторы ограничений известны: изменяемые переменные ...
    Но нижеследующее повествование отлагает.
    С другой стороны если на эти две таблы навешаны триггеры, то их логика может зависеть от последовательности изменений. Т.е. код потенциально может вести себя неадекватно.
    Только если эти изменения раздельны, то данные будут разные от случая, а если изменения связаны одной командой, то данные всегда есть в наличии - цельные (см MERGE), но нет инструментов регулирования последовательности запуска триггеров, а это очень старая больная тема (см ещё OUTPUT).
  • 4 апр 11, 01:54    [10465385]     Ответить | Цитировать Сообщить модератору
     Re: Параллельные вычисления для TSQL.  [new]
    _r2003
    Member

    Откуда: Владивосток (Москва)
    Сообщений: 56
    А что такое большая транзакция?
    это сотня мегабайт данных или миллион строк или её длительность час.
    27 июл 11, 12:14    [11033090]     Ответить | Цитировать Сообщить модератору
     Re: Параллельные вычисления для TSQL.  [new]
    _r2003
    Member

    Откуда: Владивосток (Москва)
    Сообщений: 56
    http://msdn.microsoft.com/ru-ru/library/ms131686.aspx
    http://msdn.microsoft.com/ru-ru/library/dd776382.aspx
    http://msdn.microsoft.com/ru-ru/library/bb510625.aspx
    27 июл 11, 12:33    [11033214]     Ответить | Цитировать Сообщить модератору
     Re: Параллельные вычисления для TSQL.  [new]
    Гавриленко Сергей Алексеевич
    Member

    Откуда: Moscow
    Сообщений: 36968
    _r2003
    http://msdn.microsoft.com/ru-ru/library/ms131686.aspx
    http://msdn.microsoft.com/ru-ru/library/dd776382.aspx
    http://msdn.microsoft.com/ru-ru/library/bb510625.aspx
    wtf?
    27 июл 11, 12:34    [11033220]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
    Все форумы / Microsoft SQL Server Ответить