-
/yaxPVsbl.png)
Что должен знать и уметь администратор БД
Перенос из темы «Visa и Master Card в России. Какое будущее?»Теги:
V.Stepan
HolyBoy> А у других это всё было. И есть. Они прошлись по всем граблям и поэтому имеют фору.
Т.е. по твоим словам, Оракл слаб в опыте хождения по этим граблям?
Я напомню, что ещё относительно недавно Линукс был несерьёзен, как платформа, но как только на него взялись серьёзные фирмы (хотя бы одна IBM) и портировали в него свои технологии, то резко вырос "вес" Линукса как стабильной платформы.
HolyBoy> Потому что MySQL проще в освоении программистами?
Абсолютно нет.
HolyBoy> Для ве** вполне достаточно, а вот для остального — нафиг-нафиг.
А теперь прочти то, что я выше написал:
V.Stepan> Может, он отвечает только за веб-транзакции по карточкам?
Сами карточки хранить надо? Нет, достаточно к основной БД обратиться. Остатки по карточкам хранить надо? Нет, достаточно к основной БД обратиться. Полную историю движения по карте хранить надо? Нет, это всё в основной БД. Т.е. в мускуле достаточно сам факт транзакции сохранить, и всё. Причём уже вчерашние хранить не надо — это всё отреплицировано давно в основную БД.
Так с чего ты решил, что это для него неподъёмная работа?
Т.е. по твоим словам, Оракл слаб в опыте хождения по этим граблям?
Я напомню, что ещё относительно недавно Линукс был несерьёзен, как платформа, но как только на него взялись серьёзные фирмы (хотя бы одна IBM) и портировали в него свои технологии, то резко вырос "вес" Линукса как стабильной платформы.
HolyBoy> Потому что MySQL проще в освоении программистами?
Абсолютно нет.
HolyBoy> Для ве** вполне достаточно, а вот для остального — нафиг-нафиг.
А теперь прочти то, что я выше написал:
V.Stepan> Может, он отвечает только за веб-транзакции по карточкам?
Сами карточки хранить надо? Нет, достаточно к основной БД обратиться. Остатки по карточкам хранить надо? Нет, достаточно к основной БД обратиться. Полную историю движения по карте хранить надо? Нет, это всё в основной БД. Т.е. в мускуле достаточно сам факт транзакции сохранить, и всё. Причём уже вчерашние хранить не надо — это всё отреплицировано давно в основную БД.
Так с чего ты решил, что это для него неподъёмная работа?
"Класс – это исключение случайностей"
инфо
инструменты
спокойный тип
HolyBoy> По обсуждаемой вакансии админа БД аналогичные рассуждения были.
HolyBoy> И над всем этим веет дух маленькой зарплаты. Есть мнение, что хорошие спецы туда просто не идут, т.к. з/п не ахти, т.к. у хороших спецов не было бы вон того, что выше.
это да, зарплата там бредовая..такое во всех направлениях сейчас...ищут супер спецов меньше чем за штуку евро...тупо рынок зарплат упал в ИТ...а вакансию писала девочка-кадровичка (тоже с маленькой зарплатой) - спросила типа у гугла " а что сейчас типа нормальный сетевик должен знать" - и всё чесно скопировала...сам подумай кто будет нормальный знание SNMP писать как одно из КЛЮЧЕВЫХ требований
HolyBoy> И над всем этим веет дух маленькой зарплаты. Есть мнение, что хорошие спецы туда просто не идут, т.к. з/п не ахти, т.к. у хороших спецов не было бы вон того, что выше.
это да, зарплата там бредовая..такое во всех направлениях сейчас...ищут супер спецов меньше чем за штуку евро...тупо рынок зарплат упал в ИТ...а вакансию писала девочка-кадровичка (тоже с маленькой зарплатой) - спросила типа у гугла " а что сейчас типа нормальный сетевик должен знать" - и всё чесно скопировала...сам подумай кто будет нормальный знание SNMP писать как одно из КЛЮЧЕВЫХ требований
Ребята, вас не туда занесло. На открытых либо коммереческих БД делать национальную платёжную систему во-первых, нельзя, а во-втрорых, не нужно.
Соответственно, обсуждение их в этом контексте не имеет смысла.
Соответственно, обсуждение их в этом контексте не имеет смысла.
... так пускай наступает на нас холодным рассветом новый день ...
Sandro> На открытых либо коммереческих БД делать национальную платёжную систему во-первых, нельзя, а во-втрорых, не нужно.
А на каких нужно? На разработанных под эту НПС?
А на каких нужно? На разработанных под эту НПС?
Гораздо лучше обещать меньше и давать больше, чем наоборот
yacc> Т.е. получается для $250k 16 двухядерных лицензий или 8 четерыхядерных машин или 4 восьмиядерных ?
неполенился, поднял спеку - в ассортименте деллы R630 20-ти ядерные ( виндовс датацентр ну и mssqlent + немного еще по мелочи, калы всякие)
зы
цена может немного не совпадать в силу особых отношений клиента с микрософт (глобальная скидка протранслированная в РФ)
неполенился, поднял спеку - в ассортименте деллы R630 20-ти ядерные ( виндовс датацентр ну и mssqlent + немного еще по мелочи, калы всякие)
зы
цена может немного не совпадать в силу особых отношений клиента с микрософт (глобальная скидка протранслированная в РФ)
Это сообщение редактировалось 30.04.2015 в 13:31
Sandro> Ребята, вас не туда занесло. На открытых либо коммереческих БД делать национальную платёжную систему во-первых, нельзя, а во-втрорых, не нужно.
Sandro> Соответственно, обсуждение их в этом контексте не имеет смысла.
почему? я сам в бытность в ЦБ админом (отдела ГИС) занимался (немного) проектом на IBM Z-series\P-Series vs DB2 ( и суси линукс в LPARах на этих же машинах тоже c DB2). очень похожий проект был, процессили транзакции между банками , типа свифта
думаю что для НСПК это тоже хорошая платформа
Sandro> Соответственно, обсуждение их в этом контексте не имеет смысла.
почему? я сам в бытность в ЦБ админом (отдела ГИС) занимался (немного) проектом на IBM Z-series\P-Series vs DB2 ( и суси линукс в LPARах на этих же машинах тоже c DB2). очень похожий проект был, процессили транзакции между банками , типа свифта
думаю что для НСПК это тоже хорошая платформа
wstil> А на каких нужно? На разработанных под эту НПС?
Естественно. Благо, свифтовская платёжка имеет фиксированную и довольно простую структуру. А давать свои деньги подержать враждебно к тебе настроенным людям — попросту глупо.
И использование стороннего софта идёт именно по этой категории. ЕМНИМС случаи странного кода в опенсорсном софте уже были. Опять же, вспоминаем teardrop. Разумеется, так можно и просто по глупости накосячить, но возможно — это реальная закладка (там можно было дистанционно положить любую машину, имеющую доступ в сеть).
Естественно. Благо, свифтовская платёжка имеет фиксированную и довольно простую структуру. А давать свои деньги подержать враждебно к тебе настроенным людям — попросту глупо.
И использование стороннего софта идёт именно по этой категории. ЕМНИМС случаи странного кода в опенсорсном софте уже были. Опять же, вспоминаем teardrop. Разумеется, так можно и просто по глупости накосячить, но возможно — это реальная закладка (там можно было дистанционно положить любую машину, имеющую доступ в сеть).
... так пускай наступает на нас холодным рассветом новый день ...
Sandro> Естественно.
Сомнительно, что можно вот так быстренько слепить нормальную, удобную в работе, стабильную СУБД для больших объемов транзакций.
Sandro> А давать свои деньги подержать враждебно к тебе настроенным людям — попросту глупо.
ИМХО в данном случае стабильность работы важнее. При этом данная система - не система управления ядерным оружием.
Сомнительно, что можно вот так быстренько слепить нормальную, удобную в работе, стабильную СУБД для больших объемов транзакций.
Sandro> А давать свои деньги подержать враждебно к тебе настроенным людям — попросту глупо.
ИМХО в данном случае стабильность работы важнее. При этом данная система - не система управления ядерным оружием.
Гораздо лучше обещать меньше и давать больше, чем наоборот
ну ты же понимаешь что от закладок в ОС\СУБД можно защищаться по разному.
более того, в такой системе нужно заранее исходить из того что какие-то закладки где-то есть и при проработанной архитектуре (и модели угроз и мероприятия по защите) ядро системы с данными ставить глубоко в защищённом окружении, туда\оттуда "тупо" датаграммы приходят прошедшие через несколько пограничных машин пропускать
вот файрволлы и инфраструктура должны быть ФСТЭком аттестованы как надо, по гос тайне
вот если у тебя уже есть своя хорошая СУБД - то можно на неё ориентироваться, если нет - разрабатывать параллельно. нельзя в таком проекте на сырую субд ориентироваться, только если не прописать это в целях и как риск сразу этим управлять (риском того что своя субд слажает так как сырая и что в этом случае делать)
более того, в такой системе нужно заранее исходить из того что какие-то закладки где-то есть и при проработанной архитектуре (и модели угроз и мероприятия по защите) ядро системы с данными ставить глубоко в защищённом окружении, туда\оттуда "тупо" датаграммы приходят прошедшие через несколько пограничных машин пропускать
вот файрволлы и инфраструктура должны быть ФСТЭком аттестованы как надо, по гос тайне
вот если у тебя уже есть своя хорошая СУБД - то можно на неё ориентироваться, если нет - разрабатывать параллельно. нельзя в таком проекте на сырую субд ориентироваться, только если не прописать это в целях и как риск сразу этим управлять (риском того что своя субд слажает так как сырая и что в этом случае делать)
wstil> Сомнительно, что можно вот так быстренько слепить нормальную, удобную в работе, стабильную СУБД для больших объемов транзакций.
Про "быстренько" я не говорил. Но делать надо. Благо транзакции там простые, и нефиг городить огород с SQL, он там вообще как собаке пятая нога.
Sandro>> А давать свои деньги подержать враждебно к тебе настроенным людям — попросту глупо.
wstil> ИМХО в данном случае стабильность работы важнее. При этом данная система - не система управления ядерным оружием.
Она ещё опаснее. И поэтому должна быть целиком в наших руках. Сторонний код тут просо недопустим.
И это уже не говоря о том, что стабильность высокоспециализированного решения с тремя функциями (деньги положить, снять, перевести) будет заведомо выше, чем у мегамонстра на миллион строк кода, написанных неизвестно кем.
Да работать будет на порядок быстрее.
Про "быстренько" я не говорил. Но делать надо. Благо транзакции там простые, и нефиг городить огород с SQL, он там вообще как собаке пятая нога.
Sandro>> А давать свои деньги подержать враждебно к тебе настроенным людям — попросту глупо.
wstil> ИМХО в данном случае стабильность работы важнее. При этом данная система - не система управления ядерным оружием.
Она ещё опаснее. И поэтому должна быть целиком в наших руках. Сторонний код тут просо недопустим.
И это уже не говоря о том, что стабильность высокоспециализированного решения с тремя функциями (деньги положить, снять, перевести) будет заведомо выше, чем у мегамонстра на миллион строк кода, написанных неизвестно кем.
Да работать будет на порядок быстрее.
... так пускай наступает на нас холодным рассветом новый день ...
Sandro> Про "быстренько" я не говорил. Но делать надо. Благо транзакции там простые, и нефиг городить огород с SQL, он там вообще как собаке пятая нога.
Ну так нужно было запустить быстро. А параллельно с эксплуатацией существующей системы без спешки разрабатывать свою/переделывать существующую. Сделать нормальную масштабирующуюся СУБД - развлечение не быстрое, если вообще возможное в наших условиях, когда к проекту будет привлечено весьма ограниченное кол-во ресурсов, причем, как всегда, не самых квалифицированных.
Ну так нужно было запустить быстро. А параллельно с эксплуатацией существующей системы без спешки разрабатывать свою/переделывать существующую. Сделать нормальную масштабирующуюся СУБД - развлечение не быстрое, если вообще возможное в наших условиях, когда к проекту будет привлечено весьма ограниченное кол-во ресурсов, причем, как всегда, не самых квалифицированных.
Гораздо лучше обещать меньше и давать больше, чем наоборот
wstil> Сделать нормальную масштабирующуюся СУБД - развлечение не быстрое, если вообще возможное в наших условиях, когда к проекту будет привлечено весьма ограниченное кол-во ресурсов, причем, как всегда, не самых квалифицированных.
"Это хуже, чем преступление, это — ошибка".
На "нормальных" СУБД платёжную систему делать вообще нельзя. Там должна быть специализированная под задачу. Например, с невозможностью откатить транзакцию. С полной историей. Ещё много с чем.
А все эти SQL — дальше вебморды не пускать. Нечего им там делать.
"Это хуже, чем преступление, это — ошибка".
На "нормальных" СУБД платёжную систему делать вообще нельзя. Там должна быть специализированная под задачу. Например, с невозможностью откатить транзакцию. С полной историей. Ещё много с чем.
А все эти SQL — дальше вебморды не пускать. Нечего им там делать.
... так пускай наступает на нас холодным рассветом новый день ...
Sandro> На открытых либо коммереческих БД делать национальную платёжную систему во-первых, нельзя, а во-втрорых, не нужно.
Какие ваши доказательства?! ©
Какие ваши доказательства?! ©
с.т.> неполенился, поднял спеку - в ассортименте деллы R630 20-ти ядерные
Ну ты же что-то про виртуалки говорил, не ?
Там ядер может быть и поменьше.
Ну ты же что-то про виртуалки говорил, не ?
Там ядер может быть и поменьше.
с.т.>> неполенился, поднял спеку - в ассортименте деллы R630 20-ти ядерные
yacc> Ну ты же что-то про виртуалки говорил, не ?
yacc> Там ядер может быть и поменьше.
конечно никто не может запретить поставить энтерпрайз на слабый сервак, но смысл? это же боевая среда, виртуалки для снижения времени до ~0 простоя при миграциях и перекрестного HA резервирования, так что все ядра используются
зы хотя да, помню один раз случай действительно процы из пролианта g8 вынимали что бы оракл меньше стоил...купили сервак с запасом типа
yacc> Ну ты же что-то про виртуалки говорил, не ?
yacc> Там ядер может быть и поменьше.
конечно никто не может запретить поставить энтерпрайз на слабый сервак, но смысл? это же боевая среда, виртуалки для снижения времени до ~0 простоя при миграциях и перекрестного HA резервирования, так что все ядра используются
зы хотя да, помню один раз случай действительно процы из пролианта g8 вынимали что бы оракл меньше стоил...купили сервак с запасом типа
Sandro>> На открытых либо коммереческих БД делать национальную платёжную систему во-первых, нельзя, а во-втрорых, не нужно.
yacc> Какие ваши доказательства?! ©
1) Гвозди микроскопом не забивают.
2) Оставлять ключ от входной двери под ковриком тоже неправильно.
Ну в какой ещё формулировке мне надо сказать, чтобы дошло?
yacc> Какие ваши доказательства?! ©
1) Гвозди микроскопом не забивают.
2) Оставлять ключ от входной двери под ковриком тоже неправильно.
Ну в какой ещё формулировке мне надо сказать, чтобы дошло?
... так пускай наступает на нас холодным рассветом новый день ...
Sandro> 1) Гвозди микроскопом не забивают.
Sandro> 2) Оставлять ключ от входной двери под ковриком тоже неправильно.
Sandro> Ну в какой ещё формулировке мне надо сказать, чтобы дошло?
понимаешь, во всём мире платёжные системы, биллинги, процессинги, мерчи и тп - десятилетиями делают на SQLе, и ЧСХ они хорошо работают...тут ты приходишь и предлагаешь изобрести велосипед на гусеницах причём гусениц ещё нет
секьюрити через обскьюрити - это вообще не выход, проблема вообще не там
Sandro> 2) Оставлять ключ от входной двери под ковриком тоже неправильно.
Sandro> Ну в какой ещё формулировке мне надо сказать, чтобы дошло?
понимаешь, во всём мире платёжные системы, биллинги, процессинги, мерчи и тп - десятилетиями делают на SQLе, и ЧСХ они хорошо работают...тут ты приходишь и предлагаешь изобрести велосипед на гусеницах
причём гусениц ещё нетсекьюрити через обскьюрити - это вообще не выход, проблема вообще не там
Sandro> На открытых либо коммереческих БД делать национальную платёжную систему во-первых, нельзя, а во-втрорых, не нужно.
Чем тебе открытые не нравятся? Да и коммерческие чем не нравятся, если будут с открытым кодом?
Выбрать решение, сертифицировать, проверить. Кажется, какая-то из версий Postgres даже прошла сертификацию. Свой велосипед писать… нуууу обдумать надо дюже.
Чем тебе открытые не нравятся? Да и коммерческие чем не нравятся, если будут с открытым кодом?
Выбрать решение, сертифицировать, проверить. Кажется, какая-то из версий Postgres даже прошла сертификацию. Свой велосипед писать… нуууу обдумать надо дюже.
с.т.> конечно никто не может запретить поставить энтерпрайз на слабый сервак, но смысл? это же боевая среда
Я тебе так скажу - наши машинки на Амазоне вовсе не такие навороченные, хотя штук 30 баз там крутится в легкую
с.т.> виртуалки для снижения времени до ~0 простоя при миграциях и перекрестного HA резервирования, так что все ядра используются
Так ясен пень, просто у вертуалки не все ядра хоста. Скажем 4-8. Если часть ядер отдано на веб - их вычесть из лицензии - сиквелу их не дадут.
Я тебе так скажу - наши машинки на Амазоне вовсе не такие навороченные, хотя штук 30 баз там крутится в легкую
с.т.> виртуалки для снижения времени до ~0 простоя при миграциях и перекрестного HA резервирования, так что все ядра используются
Так ясен пень, просто у вертуалки не все ядра хоста. Скажем 4-8. Если часть ядер отдано на веб - их вычесть из лицензии - сиквелу их не дадут.
Sandro> 1) Гвозди микроскопом не забивают.
Вообще не понял.
Sandro> 2) Оставлять ключ от входной двери под ковриком тоже неправильно.
Надо закрыть вход в парадную
По части 1) - вовсе не значит, что если БД - платная - то она супернавороченная.
И да - что там с отечественными?
Вообще не понял.
Sandro> 2) Оставлять ключ от входной двери под ковриком тоже неправильно.
Надо закрыть вход в парадную
По части 1) - вовсе не значит, что если БД - платная - то она супернавороченная.
И да - что там с отечественными?
yacc> Так ясен пень, просто у вертуалки не все ядра хоста. Скажем 4-8. Если часть ядер отдано на веб - их вычесть из лицензии - сиквелу их не дадут.
в целом согласен, а так в данном же по условию задачи тяжелая база и все ядра под mssql, а апликуха (и вебморды) на отдельном серваке
девы считали сайзинг на основании предыдущих нескольких лет (и двух предыдущих инсталяций), вот так получается
в целом согласен, а так в данном же по условию задачи тяжелая база и все ядра под mssql, а апликуха (и вебморды) на отдельном серваке
девы считали сайзинг на основании предыдущих нескольких лет (и двух предыдущих инсталяций), вот так получается
с.т.> в данном же по условию задачи тяжелая база и все ядра под mssql
ОЗУ в первую очередь надо и быструю дисковую подсистему
П.С. Посмотрел на спеку сервера, облизнулся...
потому подумал, что хоть мне и нравятся 1U, но шумные они негодяи - у меня два делла таких ( правда стареньких стоят ), а новый я собрал таки в мидитаур корпусе - дома шума многовато - для серверной
ОЗУ в первую очередь надо и быструю дисковую подсистему
П.С. Посмотрел на спеку сервера, облизнулся...
потому подумал, что хоть мне и нравятся 1U, но шумные они негодяи - у меня два делла таких ( правда стареньких стоят ), а новый я собрал таки в мидитаур корпусе - дома шума многовато - для серверной
нене, дома только ноутбуки, максиму ноут с доком, делл пресижен м6500 - вот отличный ноут для дома ))))
брать хостинг работу на дом - это уже овердоз даже для DBAшников (к которым себя не отношу)
ps собственно именно из-за потребного ОЗУ нужен ms sql enterprise - так как 2014стандарт только 128гб берет
брать хостинг работу на дом - это уже овердоз даже для DBAшников (к которым себя не отношу)
ps собственно именно из-за потребного ОЗУ нужен ms sql enterprise - так как 2014стандарт только 128гб берет
с.т.> брать хостинг работу на дом
У меня не хостинг У меня лаба
У меня не хостинг
У меня лаба
Sandro>> Ну в какой ещё формулировке мне надо сказать, чтобы дошло?
с.т.> понимаешь, во всём мире платёжные системы, биллинги, процессинги, мерчи и тп - десятилетиями делают на SQLе, и ЧСХ они хорошо работают...тут ты приходишь и предлагаешь изобрести велосипед на гусеницах
И вот постоянно случаются двойные списания средств, или вообще списания в никуда, невозможно восстановить историю транзакций в случае чего и т.д. По-твоему, это нормально?
с.т.> причём гусениц ещё нет
Гусениц есть и применяются. И не на велосипеде, а на танке. В нормально спроектированных системах.
с.т.> секьюрити через обскьюрити - это вообще не выход, проблема вообще не там
Где я такое предлагал ??? Ты офигел, что ли ???
с.т.> понимаешь, во всём мире платёжные системы, биллинги, процессинги, мерчи и тп - десятилетиями делают на SQLе, и ЧСХ они хорошо работают...тут ты приходишь и предлагаешь изобрести велосипед на гусеницах
И вот постоянно случаются двойные списания средств, или вообще списания в никуда, невозможно восстановить историю транзакций в случае чего и т.д. По-твоему, это нормально?
с.т.> причём гусениц ещё нет
Гусениц есть и применяются. И не на велосипеде, а на танке. В нормально спроектированных системах.
с.т.> секьюрити через обскьюрити - это вообще не выход, проблема вообще не там
Где я такое предлагал ??? Ты офигел, что ли ???
... так пускай наступает на нас холодным рассветом новый день ...
Copyright © Balancer 1997..2018
Создано 29.04.2015
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
Создано 29.04.2015
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
- Поиск
- Настройки
-
- Персональное
-
Здравствуйте, гость!
Гостевой функционал сайта ограничен. Для полноценной работы зарегистрируйтесь, пожалуйста.
- Тема
- RPG (самоуправление)
- Твиттер сайта Твиты пользователя @AirbaseRu
- Статистика
-
