Миф: как IBM победил БЭСМ

[oshibka_residenta]

StrangeR, скучный Вы человек - ни о чем кроме цен говорить не можете.

Надо срочно переходить в sales. Такой талант пропадает. В приложении со способностью нести разумный BS на технические темы - sky's the limit.

[StrangerR]

StrangeR, скучный Вы человек - ни о чем кроме цен говорить не можете.

Надо срочно переходить в sales. Такой талант пропадает. В приложении со способностью нести разумный BS на технические темы - sky's the limit.

Кому из нас двоих? Или обоим, а лучше в паре работать? А что, я думаю я найду способ МФ впарить. Или наоборот, 100 интелов впарить .

нести разумный BS на технические темы

Интересно, а если этот BS еще и практически - работает (в форме скриптов, дата центра и прочего) - это BS или не особо?

[oshibka_residenta]

Кому из нас двоих? Или обоим, а лучше в паре работать? А что, я думаю я найду способ МФ впарить. Или наоборот, 100 интелов впарить

Я про zVlad. Мне кажется он смог бы впарить решение за бОльшие деньги.
А у вас как-то мелковато - какие-то все расчет. Таким клиента не поразить. Но вы тоже терзайте.

[zVlad]

Сегодня случился такой порадокс в нашей конторе. Утром мой тим лид сообщает на тестовой системе сидит batch job с одним ad-hoc query к DB2, уже 20 часов сидит. Смотрю query, что-то вроде вот такого:

Select distinct c1 from table1 t1
where t1.TIME_STAMP > '2014-10-26-.....'
and ((Not Exists (select 1 from table2 t2
where t1.c2 = t2.c2)
Or Not Exists (select 1 from table3 t3
where t1.c2 = t3.c2)
Or.........
Or Not Exists (select 1 from table7 t7
where t1.c2 = t7.c2)))

а рядом коллега погодился, наш из Минска, программист на Wintel, говорит давай я этот query в реплике нашей DB2на MS SQL прогоню (я рассказывал про эту реплику), пришли мол мне его по e-mail. Шлю, отвечает - 18 секунд выполнения на реплике этой же самой BD что на MF, только под MS SQL на Intel server. А на МФ за 21 час не прошло, канцелировали вручную. Кстати query в плане подготовки к переносу на MF BD с Oracle (тоже рассказывал об этом раньше).

Начинаю искать в чем дело. смотрю на стороне MF. Вижу по именам таблиц что это весьма крупные таблицы (помню со времен DBA-ства). Вижу что индекса на столбце TIME_STAMP нет, индекс на столбец c2 только в двух таблицах из семи. Спрашиваю коллегу из Минска, а что там у вас на MS SQL, не знаю говорит, пришлю MS SQL DBA. Приходит MS SQL DBA, наш из Москвы, спрашиваю, отвечает у них индексы есть на все причинные столбцы. А какой у вас сервер, сколько чего. Отвечает 24 GB (у нас 8GB в тестовом LPAR), 32 кора (у нас 3 кора, правда МФ-ских).

Сегодня наша DB2 DBA, когда я уходил, создавала нужные индексы. Завтра будем посмотреть и рассказать.

[tengiz]

Сегодня случился такой порадокс в нашей конторе.

А в чем парадокс? Запрос с таблицами где есть, возможно, все полезные индексы на системе у которой в разы больше памяти и ядер выполнился заметно быстрее, чем запрос, возможно, без всех полезных индексов на системе с меньшей памятью и ядрами. Я бы ожидал, что это как раз вполне предсказуымый результат если таблица t1 реально большая и если данных там хотя бы за несколько месяцев и предполагая что по датам данные распределены более-менее равномерно и, следовательно, условие "where t1.TIME_STAMP > '2014-10-26-...." может уменьшить объем данных прочитанных из таблицы t1 в десятки или даже сотни раз при наличии правильного индекса.

[zVlad]

Сегодня случился такой порадокс в нашей конторе.

А в чем парадокс? Запрос с таблицами где есть, возможно, все полезные индексы на системе у которой в разы больше памяти и ядер выполнился заметно быстрее, чем запрос, возможно, без всех полезных индексов на системе с меньшей памятью и ядрами. Я бы ожидал, что это как раз вполне предсказуымый результат если таблица t1 реально большая и если данных там хотя бы за несколько месяцев и предполагая что по датам данные распределены более-менее равномерно и, следовательно, условие "where t1.TIME_STAMP > '2014-10-26-...." может уменьшить объем данных прочитанных из таблицы t1 в десятки или даже сотни раз при наличии правильного индекса.

Парадоксом это выглядело лишь до тех пор пока не стало известно об индексах. А началось прояснение с того что я начал смотреть в ДБ2 есть ли индексы на колонках в предикатах. Их не оказалось и стало ясно что на MS SQL лучший результат мог быть только если там есть индексы. Индексы там оказались. Теперь дело за повторением этого на МФ с индексами.

[tengiz]

Парадоксом это выглядело лишь до тех пор пока не стало известно об индексах. А началось прояснение с того что я начал смотреть в ДБ2 есть ли индексы на колонках в предикатах. Их не оказалось и стало ясно что на MS SQL лучший результат мог быть только если там есть индексы. Индексы там оказались. Теперь дело за повторением этого на МФ с индексами.

Теперь понятно. Для такого запроса если оптимизатор выберет hash anti-join вместо nested loop/merge anti-join самым главным ресурсом для скорости может оказаться память, а не индексы.

[zVlad]

Парадоксом это выглядело лишь до тех пор пока не стало известно об индексах. А началось прояснение с того что я начал смотреть в ДБ2 есть ли индексы на колонках в предикатах. Их не оказалось и стало ясно что на MS SQL лучший результат мог быть только если там есть индексы. Индексы там оказались. Теперь дело за повторением этого на МФ с индексами.

Теперь понятно. Для такого запроса если оптимизатор выберет hash anti-join вместо nested loop/merge anti-join самым главным ресурсом для скорости может оказаться память, а не индексы.

Я сейчас создаю индексы, их никто не промялся создавать оказывается. Там посмотрим.

[zVlad]

После создания индексов лучшee время выполнения запроса упомянутого в начале страницы стало 20-40 секунд. 20 секунд выполнение в выводом первых 10 строк, 40 секунд с полным выводом - около 1000000 строк. См. столбец "Elapsed Time":

Code: Select all

+                                  Elapsed  CPU                          Term
+ End Time       Plan     Authid   Time     Time   SQL   Commit Abrt Pkg Status
+ ------------   -------- -------- -------  ------ ----- ------ ---- --- ------
+ 22:27:01.208   DSNESPUR SIVB       20.02  19.722    15     3     0   1 DEALLOC
+ 22:25:37.617   DSNESPUR SIVB       41.01  39.591  937K     3     0   1 DEALLOC
+ 22:24:17.839   DSNESPUR SIVB       40.58  39.227  937K     3     0   1 DEALLOC
+ 22:23:00.978   DSNESPUR SIVB       41.36  39.774  937K     3     0   1 DEALLOC
+ 22:21:02.016   DSNESPUR SIVB         .01    .000     4     1     0   1 DEALLOC
+ 22:19:54.000   DSNTEP91 SIVB       35.18  34.689  937K     1     0   1 DEALLOC
+ 22:18:20.031   DSNTEP91 SIVB       40.65  39.009  937K     1     0   1 DEALLOC

Запрос в MS SQL был не совсем на тех же данных что использую я сейчас. Тот запрос давал ~ 220000 строк. Этот почти миллион строк.

[StrangerR]

Парадоксом это выглядело лишь до тех пор пока не стало известно об индексах. А началось прояснение с того что я начал смотреть в ДБ2 есть ли индексы на колонках в предикатах. Их не оказалось и стало ясно что на MS SQL лучший результат мог быть только если там есть индексы. Индексы там оказались. Теперь дело за повторением этого на МФ с индексами.

Теперь понятно. Для такого запроса если оптимизатор выберет hash anti-join вместо nested loop/merge anti-join самым главным ресурсом для скорости может оказаться память, а не индексы.

Я сейчас создаю индексы, их никто не промялся создавать оказывается. Там посмотрим.

А у вас что, можно просто взять и _создать индекс_? А по рукам не дают??

Создание индекса - это изменение. Изменение должно быть записано в виде скрипта, протестировано, желательно чтобы еще ДБА глянул, а потом только _скрипт_ выполнен в продакшене, с аппрувелом изменения. А прросто _ДБА пошел и создал_ вообще говоря - так и базу убить можно. Индексы то, они что-то ускоряют а что-то замедляют, и по уму если индекс не _просто потеряли_ - нужно перфоменс тесты прогонять.

[Dmitry67]

Фигня (подливая коньяк в кофе). Я вот недавно на production делал truncate table ) чтобы место почистить )

[tengiz]

У меня в молодости, когда я был DBA (ужас - 20 лет назад!) тоже такое бывало - самое кавалерийское что я сделал, это когда в банке балансы по счетам съехали из-за ошибки в триггере, который изменили тем утром, я ad-hoc update-ом перевычислил балансы и накатил их наживую (в самый разгар операционного дня, когда кассиры и операционисты вовсю лупили новые данные и обслуживали клиентов), после исправления триггера, причем с первого раза правильно :) ! Хорошо, схема была сделана так (сам делал, как считал нужным) что можно было все сделать коротко и ясно. На всякий случай сохранил этот update в процедуре на случай, если еще раз похожее случится. Но больше не случалось.

[zVlad]

Парадоксом это выглядело лишь до тех пор пока не стало известно об индексах. А началось прояснение с того что я начал смотреть в ДБ2 есть ли индексы на колонках в предикатах. Их не оказалось и стало ясно что на MS SQL лучший результат мог быть только если там есть индексы. Индексы там оказались. Теперь дело за повторением этого на МФ с индексами.

Теперь понятно. Для такого запроса если оптимизатор выберет hash anti-join вместо nested loop/merge anti-join самым главным ресурсом для скорости может оказаться память, а не индексы.

Я сейчас создаю индексы, их никто не промялся создавать оказывается. Там посмотрим.

А у вас что, можно просто взять и _создать индекс_? А по рукам не дают??

Создание индекса - это изменение. Изменение должно быть записано в виде скрипта, протестировано, желательно чтобы еще ДБА глянул, а потом только _скрипт_ выполнен в продакшене, с аппрувелом изменения. А прросто _ДБА пошел и создал_ вообще говоря - так и базу убить можно. Индексы то, они что-то ускоряют а что-то замедляют, и по уму если индекс не _просто потеряли_ - нужно перфоменс тесты прогонять.

Все нормально, StrangeR, я не на Production это делал - на так называемом Migration. E'to BD где девелоперы тестируют скорую загрузку данных с Oracle BD. Строго говоря это БД с данными из Production плюс что еще.
Я добавлю позже об этом - сейчас нет времени, хочу по утру еще пару тестов прогнать и убить те индексы что создал вчера вечером

[Dmitry67]

Фигня (подливая коньяк в кофе). Я вот недавно на production делал truncate table ) чтобы место почистить )

Справедливости скажу, чтобы не шокировать публику, что это технические таблички лога аппликации, которые иногда раздуваются изза всякого бреда, и у меня есть давно письмо от главного менеджера саппорта с разрешением чистить эти таблицы всегда и везде. Кроме того, у нас ведь adhoc по всем серверам пишется в аудит

[iDesperado]

Короче дружбан мой появился, но говорит Клиент2 ушел с нашего сопровозгдения вот уже год как.

ну да, ну да ...
так может все таки подберете время и покажете нагрузку серьезней, чем у меня на ноутбуке с вашего МФ как я понимаю вы там и буфера уже увеличили, мы за одно и оценим, не занят ли ваш МФ демонстрацией невероятного I/O на данных, которые запросто в памяти ноутбука помещаются.