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

zVlad
Уже с Приветом
Posts: 15420
Joined: 30 Apr 2003 16:43
Has thanked: 1 time

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

Post by zVlad »

StrangerR wrote:....Это хороший подход :) но не без кучи граблей. Во первых, такое зеркало никогда не будет синхронным. во вторых, оно зазеркалирует все изменения в том числе например и 100 гигов временной таблицы. В третьих, оно же зазеркалирует ошибочно записанные данные из за которых база грохнулась. ....
Для этих граблей делается backup и restore чтобы исправить ошибочные данные, DR для этого естественно не применим, DR нужен для того чтобы быть максимально близко к состоянию основного сайта (Р.S. Каким бы он не был) в момент когда основной сайт физически разрушен. Вдумайтесь в это и Вы все поймете. DR это не локальный failover.
А временные таблицы не противоречат технике зеркалирования в DR strategy.

IBM предлагает еще одну стратегию для DR - GDPS - Geographically Dispersed Parallel Sysplex™:

http://www.redbooks.ibm.com/abstracts/s ... .html?Open

http://www-03.ibm.com/systems/z/advantages/gdps/

У нас такого нет, но я уверен любой IT манагер хотел бы чтобы в его IT такая штука имелась. Особенно там где IT делает основной доход и это не управление огромными стадами человекоподобных существ в сощетях типа Facebook, Twitter, и т.д включая Google (хотя доход в них конечно от ИТ и огромный).
Last edited by zVlad on 25 Oct 2014 01:05, edited 1 time in total.
User avatar
ARARAT.
Уже с Приветом
Posts: 34931
Joined: 20 Oct 2006 00:29
Location: RUS->USA
Has thanked: 5 times

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

Post by ARARAT. »

Блин, ну сколько можно ругаться, обвиняя друг друга...
<Давайте жить дружно!> (c)
User avatar
tengiz
Уже с Приветом
Posts: 4468
Joined: 21 Sep 2000 09:01
Location: Sammamish, WA

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

Post by tengiz »

StrangerR wrote:...переписав роскошные drop from TABLE where УСЛОВИЕ...
Вот так проваливаются разведчики :)
Cheers
StrangerR
Уже с Приветом
Posts: 38016
Joined: 14 Dec 2006 20:13
Location: USA

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

Post by StrangerR »

zVlad wrote:
StrangerR wrote:DR защита у меня была. Зеркало не обеспечивает DR защиту а обеспечивает бесперебойность главного сервиса. ..... Такое зеркалирование поддерживается той же VMware но вот только это именно DR а не бесперебойность сервиса.
Вы не только в DR ничего не понимаете, но и с зеркалированием запутались напрочь.
зеркало зеркалу рознь. Синхронный стендбай базы данных - средство High Availiability а также средство zero downtime при мейнтенсах.

Асинхронное, скорее всего снапшотное, зеркало сторейджа - средство защиты от потери сайта или вашей супер МейнФреймы. Оно всегда будет отставать, будет копировать кучу ненужного. Обычно делают комбинированное решение
- приложения, сами ОС и прочее защищают так как у вас, реплицированием на уровне SAN системы. Потому как они меняются редко и мало.
- данные (базу и файлы, особенно базу) реплицируют на уровне логическом, например базу - синхронным стендбаем. Ну или если репликация в другой город то асинхронным.

А так... сторейдж она реплицирует снапшоты, или же все транзакции вынуждены идти по каналу связи то есть он должен быть таким же как ширина вашего IO. В итоге (1) реплика отстает потому что снапшотная, и (2) реплицируется куча никому не нужного хлама, заодно. Нет, это хорошая стратегия, полная репликация на уровне SAN, но (1) очень дорогая по ресурсам, (2) вечно будет отставать то есть применима именно как DR _все пропало дата центр утонул_, и (3) если она не на VM то её нелегко тестировать. Обычно это применяют именно как DR между удаленными сайтами. Мы рассматривали такую возможность, но пока плюнули, обошлись rsync + DB репликацией + как я сказал - локально синхронное зеркало базы, удаленно репликация асинхронная другими средствами. Репликация дисков серверов базы данных - ну вероятно прошла бы ели снапшот раз в 20 минут делать, но канал бы потребовался раз в 10 толще чем сейчас.

(Я про один только проект. Их много, в других может и дисковая репликация встретиться. Но я пока как то ей не вдохновился.)
Last edited by StrangerR on 25 Oct 2014 04:02, edited 1 time in total.
StrangerR
Уже с Приветом
Posts: 38016
Joined: 14 Dec 2006 20:13
Location: USA

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

Post by StrangerR »

tengiz wrote:
StrangerR wrote:...переписав роскошные drop from TABLE where УСЛОВИЕ...
Вот так проваливаются разведчики :)
Не знаю кто там проваливается, но почему то многие разработчики любят не думая написать что нибудь вроде, и включить в чейнджсет

drop from BalanceEntries where value = 0

а потом уже на тестировании на реальных объемах мы удивленно видим лог файл размером с бегемота и время работы измеряемое чуть ли не сутками... И так не первый раз. Так транзакции на БОЛЬШОЙ (точнее даже средней) базе не пишутся. Эта операция не обязана быть атомарной (мы чистим ненужне записи) а значит - пишем её через итерации, небольшими транзакциями. Чтобы и лог файл не рос и можно было обломиться а потом продолжить. Я уж не знаю, где нынешних студентов учат, я все таки не DBA но даже пришлось завести скрипт универсальный и каждый раз показывать, как _это_ надо переписать...
User avatar
tengiz
Уже с Приветом
Posts: 4468
Joined: 21 Sep 2000 09:01
Location: Sammamish, WA

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

Post by tengiz »

StrangerR wrote:drop from BalanceEntries where value = 0...
Да нет, дело не в этом, это скорее "у Вас ус отклеился" :). Нет такого синтаксиса в SQL. Должно быть "delete from....".
Cheers
User avatar
Dmitry67
Уже с Приветом
Posts: 28294
Joined: 29 Aug 2000 09:01
Location: SPB --> Gloucester, MA, US --> SPB --> Paris

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

Post by Dmitry67 »

Мы кстати вынесли все tempdb на отдельный драйв который не реплиципуется
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
User avatar
Komissar
Уже с Приветом
Posts: 64875
Joined: 12 Jul 2002 16:38
Location: г.Москва, ул. Б. Лубянка, д.2

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

Post by Komissar »

tengiz wrote:
StrangerR wrote:drop from BalanceEntries where value = 0...
Нет такого синтаксиса в SQL. Должно быть "delete from....".
Зато он всем скрипты переписывает! И учит, "как надо" :ROFL:
Easbayguy
Уже с Приветом
Posts: 10633
Joined: 17 Jul 2003 22:11

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

Post by Easbayguy »

Да тут все теоретики кунфу!
Пх'нглуи мглв'нафх Ктулху Р'лайх угахнагл фхтагн
User avatar
tengiz
Уже с Приветом
Posts: 4468
Joined: 21 Sep 2000 09:01
Location: Sammamish, WA

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

Post by tengiz »

StrangerR wrote:а потом уже на тестировании на реальных объемах мы удивленно видим лог файл размером с бегемота и время работы измеряемое чуть ли не сутками... И так не первый раз. Так транзакции на БОЛЬШОЙ (точнее даже средней) базе не пишутся. Эта операция не обязана быть атомарной (мы чистим ненужне записи) а значит - пишем её через итерации, небольшими транзакциями. Чтобы и лог файл не рос и можно было обломиться а потом продолжить. Я уж не знаю, где нынешних студентов учат, я все таки не DBA но даже пришлось завести скрипт универсальный и каждый раз показывать, как _это_ надо переписать...
Понятно что Вы имеете в виду, но как-то Вы уж слишком общо обобщаете и нарезать большую операцию на серию маленьких часто может быть нетривиально, так как несмотря на то, что полная операция может быть неатомарной, маленькие в серии в иных случаях обязаны быть атомарными, причем не на произвольных границах, а на вполне определенных. Студентов такому не учат. Это уже при работе на конкретном датабазном продукте нужно шишки набивать. И у разных датабазных продуктов разные удобные и эффективные способы с такими вещами бороться чтобы не было логов-бегемотов.
Cheers
StrangerR
Уже с Приветом
Posts: 38016
Joined: 14 Dec 2006 20:13
Location: USA

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

Post by StrangerR »

tengiz wrote:
StrangerR wrote:drop from BalanceEntries where value = 0...
Да нет, дело не в этом, это скорее "у Вас ус отклеился" :). Нет такого синтаксиса в SQL. Должно быть "delete from....".
Ну delete конечно... Описаться можно ? Я же написал, я базу программирую не очень часто, в основном когда серьезные база кодеры на грабли наступают. И синтаксис наизусть не помню... Когда нужно, открываю книжку или предыдущий скрипт и пишу.. какие проблемы то.. Может, ктото еще попросит наизусть оракловый rman запомнить? К терапевту...

drop table но delete from xxx, все верно. Суть не меняется. Она в том, что если у меня есть табличка гигов так в 100, и нужно почистить например накопившиеся там записи с нулем в каком то поле, и эта чистка не атомарная (то есть если мы почистим 30% сегодня а 30 завтра то ничего страшного), то попытка сделать это одной командой приводит к катастрофе
- система воспринимает команду как одну транзакцию (ну а то туда кодеры и еще добавят)
- таблица блокируется на время оной транзакции, по крайней мере на запись (на чтение зависит от isolation level в MS SQL)
- все что там было переписывается в логи в redo записи (ну или в оракле в redo tablespace)
- база пыхтит часов 8 дописывая лог файл. Если он конячился то еще часов 6 делая откат. Все висят и матерятся...

Так не пишут. Пишут цикл, с ограничением записей в 1 транзакции и лучше с ограничением общего времени выполнения. И выполняют например 2 часа ночью. За неделю все чистится.

Почему те кто пишут SQL код этого не понимают, не знаю. Но факт, не понимают. Может, потому что они с жабы приходят??
Зато он всем скрипты переписывает! И учит, "как надо"
Я уже написал. Для того чтобы точно помнить синтаксис, есть книжки и примеры. Я и не помню. Но скрипты пишу постоянно, в том числе для обработки базы - совсем недавно пришлось переписыватЬ для MS SQL, и бэкапы оракла (строк 500 на rman) и прочее. А упомнить наизусть все тонкости синтаксиса shell / bash / perl / mysql / ms sql / oracla sqlplus / rman / еще в винде бывает bat как то пару тысяч строк пришлось на нем наваять / еще php попадался / и прочее... нафиг нафиг. Для синтаксиса есть reference manual. Ну и drop понятно что там delete, и что с того? Все работает, в том числе и переписанный скрипт и кластеры и зеркала и DR. И что интересно, без миллионных вложений в мейн фреймы. А с кластерами мы еще во времена Бэсмов работали.
нарезать большую операцию на серию маленьких часто может быть нетривиально, так как несмотря на то, что полная операция может быть неатомарной, маленькие в серии в иных случаях обязаны быть атомарными, причем не на произвольных границах, а на вполне определенных.
Это то понятно.

Студентов такому не учат.
Гмм. А чему их учат? Синтаксису команды delete from table или join в SQL-е? Или все таки может надо учить правильному кодированию а не тому какой там синтаксис? А то меня поражает число ляпов, которые приходят от девелоперов, особенно правда от китайских (например выборка кусочков данных методом пропуска N записей, выбора M, затем N += M, и по новой, при забытом напрочь ODER BY... блин, ловили эту чуду 2 месяца пока не поймали, автор при том так и остался неизвестным...)
Last edited by StrangerR on 25 Oct 2014 09:44, edited 1 time in total.
User avatar
tengiz
Уже с Приветом
Posts: 4468
Joined: 21 Sep 2000 09:01
Location: Sammamish, WA

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

Post by tengiz »

StrangerR wrote:Ну delete конечно... Описаться можно ?
Можно, конечно.
StrangerR wrote:- таблица блокируется на время оной транзакции, по крайней мере на запись (на чтение зависит от isolation level в MS SQL)
- все что там было переписывается в логи в redo записи (ну или в оракле в redo tablespace)
Опять, понятно, что Вы имеете в виду, но то что написано буквально - неправильно.
Гмм. А чему их учат? Синтаксису команды delete from table или join в SQL-е? Или все таки может надо учить правильному кодированию а не тому какой там синтаксис?
Их учат моделированию данных, нормальным формам и прочей реляционной азбуке. И да, синтаксису SQL. "Кодировать" не учат нигде и ни на каком языке, насколько я могу судить. Практически ВСЕХ кто приходил, скажем, к нам без реального опыта работы (в индустрии "на поток") нужно было учить кодировать заново. Самый ужасный код обычно писали бывшие "академики", но не всегда. И я сам через такое тоже проходил. Уже после примерно года работы в MS SQL на свой собственный C++ код написанный до того было больно смотреть - код должен быть простым, понятным и однообразным, написанным разборчивым почерком, так сказать. Умничать при написании продакшен когда никогда нельзя, за исключением когда это очень нужно, но нужно это бывает очень редко.

А вот SQL код у меня всегда был загляденье :)
Cheers
StrangerR
Уже с Приветом
Posts: 38016
Joined: 14 Dec 2006 20:13
Location: USA

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

Post by StrangerR »

Да нет, ну я преувеличиваю конечно. Я понимаю zVlad-а, который видит тот ужас что пишут в области _массового программирования_ и то что получается когда вместе лепим многоуровневый бутерброд (NetApp / VMWare / 100 хостов / 1000 VM под 10 операционками... а еще разные SAN и прочее вокруг, не считая нетаппов...) и сравнивает с чистой красивой архитектурой МФ. Я и сам вспоминаю код Алгола ГДР и кажется еще и Фортран ГДР был - чисто, красиво, по немецки аккуратно, без единой лишней запяток... а потом открываем что нибудь на жабе или C++ и ужасаемся...

Тем не менее, к сожалению, и МФ и _чистый красивый очень компактный код_ уходят в прошлоее. А на их место - сотня ПС серверов, тысяча индусских кодеров, и парочка грамотных архитекторов... Кстати, напоминает как ЕС вытеснила (точнее ИБМ) Бэсм - конечно бэсм была чистой красивой аккуратной, ЕС сборищем убожества, но ... функциональность важнее красоты...
User avatar
Dmitry67
Уже с Приветом
Posts: 28294
Joined: 29 Aug 2000 09:01
Location: SPB --> Gloucester, MA, US --> SPB --> Paris

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

Post by Dmitry67 »

Drop вместо delete. А один DBA к delete забыл добавить WHERE. И выполнил команду (до этого он пару суток не спал). И удалил все записи за минуту, как в эфир пошла реклама этой фирмы и все ломанулись на этот сайт. И его расстреляли. Место освободилось, и меня взяли в этот стартап. Это.было более 10 лет назад в Америке... так что для production dba опечатка в одну букву может быть концом карьеры )
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
iDesperado
Уже с Приветом
Posts: 1349
Joined: 28 Nov 2008 17:50

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

Post by iDesperado »

Dmitry67 wrote:Drop вместо delete. А один DBA к delete забыл добавить WHERE. И выполнил команду (до этого он пару суток не спал). И удалил все записи за минуту, как в эфир пошла реклама этой фирмы и все ломанулись на этот сайт. И его расстреляли.
забавный случай, но ДБА там явно не причем. виноват менеджер, не внедривший хотя бы базовые вещи по контролю. не было approve от QM, патч не протестировали на TEST и PREPROD, approve от продукт овнера не было. там ошибка была не в запросе, а в производственном процессе.

Return to “Вопросы и новости IT”