Comments 32
отвратительный маркетинговый буллшит-материал, вероятно достойный продажников «вендора», но не достойный тех. специалистов и других приличных людей из штата крупного банка.
Bla bla blaaa bla bla blaaa,
bla bla blaaa bla bla blaaa!
Bla-bla bla-bla,
bla-bla bla-bla blaaa bla!
(на мелодию «Прокатись на нашей карусели»)
Расходы на инфраструкутуру врядли уменьшатся, особенно с учетом требования к 3х кратному дубливанию дискового пространства. А вот расходы на лицензии вырастут в несколько раз. Особенно учитывая требования оракл консолидации всех лицензий. И требования оплаты поддержки всех когда либо приобретенных лицензий. Сначала реально посчитайте стоимость лицензий. Это для оракла очень поучительная и реально сложная наука. Ораклоиды обычно сами не заморачиваются чтением собственных правил лицензирования. Просто говорят — купите у нас вот эту законченную порнографию. Зачтем вам недоплату по лицензиям. Вы ш банк! С вас столько-то! Бабло в кассу!
bla bla blaaa bla bla blaaa!
Bla-bla bla-bla,
bla-bla bla-bla blaaa bla!
(на мелодию «Прокатись на нашей карусели»)
Расходы на инфраструкутуру врядли уменьшатся, особенно с учетом требования к 3х кратному дубливанию дискового пространства. А вот расходы на лицензии вырастут в несколько раз. Особенно учитывая требования оракл консолидации всех лицензий. И требования оплаты поддержки всех когда либо приобретенных лицензий. Сначала реально посчитайте стоимость лицензий. Это для оракла очень поучительная и реально сложная наука. Ораклоиды обычно сами не заморачиваются чтением собственных правил лицензирования. Просто говорят — купите у нас вот эту законченную порнографию. Зачтем вам недоплату по лицензиям. Вы ш банк! С вас столько-то! Бабло в кассу!
Дублирование используем двойное (normal redundancy). Расходы на лицензии могут вырасти за счет лицензирования Exadata Storage Software и если RAC на предыдущих системах не использовался. Экономия возникает за счет выноса части нагрузки на ячейки хранения и, как было написано выше, уменьшения вычислительных ресурсов под пиковые нагрузки.
Как насчет ситуаций попадания под санкции?
Огласите стоимость решений, пожалуйста.
Можно с учетом скидок, чтоб людей не сильно пугать.
Ну и, чтобы иметь возможность сравнить с аналогами, какие-нибудь технические параметры нагрузки. Кол-во запросов/с, объемы БД и т.п.
Можно с учетом скидок, чтоб людей не сильно пугать.
Ну и, чтобы иметь возможность сравнить с аналогами, какие-нибудь технические параметры нагрузки. Кол-во запросов/с, объемы БД и т.п.
А не было желания как в Сбере попробывать Apache Ignite? Я понимаю, что там очень очень очень много проблем, просто интересует процесс выбора? Или даже речи с Oracle уйти не было?
Если расматривать базу для OLTP то Oracle БД №1.
1) Килер фич не пересчесть (MsSQL питается копировать, иногда успешно, иногда не очень, PostgreSQL отстал такое чуство навсегда), прогнозированое быстродействие.
2) Простое маштабирование из коробки.
3) Удобство администрирования, отказовоустойчивость и возможность поддерживать систему Online 7*24. И очень многие вещи можно делать без остановки базы.
И да Oracle очень догогой, но если сравнивать не просто стоимость лицензий, а реальную нагрузку, которую держит система то разныци с MsSQL практически не будет.
Для DW можно использовать и MySQL и PostgreSQL.
Я могу сравнивать ибо пишу под MsSQL и Oracle, писал и MySQL и баловался PostgreSQL.
1) Килер фич не пересчесть (MsSQL питается копировать, иногда успешно, иногда не очень, PostgreSQL отстал такое чуство навсегда), прогнозированое быстродействие.
2) Простое маштабирование из коробки.
3) Удобство администрирования, отказовоустойчивость и возможность поддерживать систему Online 7*24. И очень многие вещи можно делать без остановки базы.
И да Oracle очень догогой, но если сравнивать не просто стоимость лицензий, а реальную нагрузку, которую держит система то разныци с MsSQL практически не будет.
Для DW можно использовать и MySQL и PostgreSQL.
Я могу сравнивать ибо пишу под MsSQL и Oracle, писал и MySQL и баловался PostgreSQL.
1) Килер фич не пересчесть (MsSQL питается копировать, иногда успешно, иногда не очень, PostgreSQL отстал такое чуство навсегда), прогнозированое быстродействие.
Вы по маркетинговым треш-страницам «вендоров» сравниваете? Или как оцениваете степень отставания и ее производную?
2) Простое маштабирование из коробки.
И что, горизонтальное масштабирование уже завезли и автоматический шардинг и по вертикали по горизонтали?
Для DW можно использовать и MySQL и PostgreSQL.
Озеро данных на SQL-базах, серьезно? :) Особенно на MySQL — без шуток, верный выбор!
маркетниг тут не причем, отставание у мсскл и постгрес от оракла 8 вышедшего лет 20 назад все еще огромно. ни у того ни у другого нет даже примитивных пакетов, нет отслеживания зависимостей, нет кластера, у постгреса нет даже партишенинга нормального или многоболочного чтения под капотом. мсскл прилепили версионность сбоку, но в таком виде (версии в темпдб) это скорее пародия, чем конкурент, хотя в зазуре это уже дефолтный уровень изолированности.
шардинг в 12ю версию оракла завезли.
дата лейк на mysql где тоже нет ни колончатых таблиц и многоблочного чтения, да — глупость.
шардинг в 12ю версию оракла завезли.
дата лейк на mysql где тоже нет ни колончатых таблиц и многоблочного чтения, да — глупость.
А от себя еще добавлю
1) RESULT_CACHE
2) Разнообразие Partition, отсутствие SubPartition.(в MsSQL на уровне 8i, в PostgreSQL в десятке прикрутили но до использования в продакшене им пилять и пилять)
3) INMEMORY(опция) — в MsSQL мягко говоря странное, в PostgreSQL нет., Да что говорить в PostgreSQL merge до сих пор нет и не будет в 11.
4) PL/SQL заточен на скорость, масовие обработки, компиляция в нативний код и тд.
Все ето дает прирост быстродействия в на некоторих участках в десятки раз.
Ви можете себе представить перенос дата файла с диска на диск или востановленя «битого блока» в состоянии Online?
А Переход на новие сервера без остановки работи БД?
От таки «маркетинговие» фичи позволяют БД бить в Online годами.
1) RESULT_CACHE
2) Разнообразие Partition, отсутствие SubPartition.(в MsSQL на уровне 8i, в PostgreSQL в десятке прикрутили но до использования в продакшене им пилять и пилять)
3) INMEMORY(опция) — в MsSQL мягко говоря странное, в PostgreSQL нет., Да что говорить в PostgreSQL merge до сих пор нет и не будет в 11.
4) PL/SQL заточен на скорость, масовие обработки, компиляция в нативний код и тд.
Все ето дает прирост быстродействия в на некоторих участках в десятки раз.
Ви можете себе представить перенос дата файла с диска на диск или востановленя «битого блока» в состоянии Online?
А Переход на новие сервера без остановки работи БД?
От таки «маркетинговие» фичи позволяют БД бить в Online годами.
>От таки «маркетинговие» фичи позволяют БД бить в Online годами.
Волшебному Ораклу не страшны даже выключения питания и сбои железа, всё равно ни одного разрыва! :)
Друг, если ты глаголишь про какие-то кластерные решения от Оракла, то прежде чем сравнивать с Постгресом, посчитай стоимость софта+железа+зарплату толкового Ораклиста (там ведь всё сделано максимально через задний проход, чтобы народ на курсы платные ходил). А потом уже расскажи как ПРИ ТОМ ЖЕ БЮДЖЕТЕ тормозит и не может годами работать в онлайне Постгрес.
Волшебному Ораклу не страшны даже выключения питания и сбои железа, всё равно ни одного разрыва! :)
Друг, если ты глаголишь про какие-то кластерные решения от Оракла, то прежде чем сравнивать с Постгресом, посчитай стоимость софта+железа+зарплату толкового Ораклиста (там ведь всё сделано максимально через задний проход, чтобы народ на курсы платные ходил). А потом уже расскажи как ПРИ ТОМ ЖЕ БЮДЖЕТЕ тормозит и не может годами работать в онлайне Постгрес.
да. ораклу за именно за это волшебство и платят миллиарды, что выключение питание и ни одного разрыва. а постгрес бесплатен, потому как выключение и он теряет транзакции. банку пофигу сколько там стоит постгрес и спец, если эта комбинация не способна при простом выключении пары нод клстера хоть чего либо гарантировать. у orace rac есть кэш, распределяющийся по нодам кластера, есть шаред диск, гарантирующий запись на все 100.000%. в постгресе же нет ничего похожего. потому в банке оракл, с его волшебством.
В банках (и других Жыр Трестъ Ынтырпрайзах) Оракл не потому, что волшебство, а потому что распилы + боятся ответственность брать на свою Ж.
Ну и традиционно, Ораклист тем круче, чем громче хает он Постгрес. Не первый, не последний ты…
Ну и традиционно, Ораклист тем круче, чем громче хает он Постгрес. Не первый, не последний ты…
только по факту на бесплатном линуксе и хадупе строить системы банк ответственности не боится. апач, томкат, гит, свн… нормальным опенсоурс системам в банке никакие распилы не мешают.
Ораклизы жгут. Банки хадупом и гитом транзакции обрабатывают?
нет. хадуп и гит банки используют ровно там где они лучшие и никакие распилы этому не помеха. в обработке транзакций лучший оракл, потому используют оракл. будет хадуп с kudu лучше оракла транзакции процессить, переключаться на хадуп. и никакие распилы хадуп не остановят.
у постгреса просто не подходящая архитектура с уборкой мусора, не подходящая под тяжелый поток транзакций, нет настоящего кластера. у оракла же волшебный UNDO и RAC. вот причина, распилы тут не причем.
у постгреса просто не подходящая архитектура с уборкой мусора, не подходящая под тяжелый поток транзакций, нет настоящего кластера. у оракла же волшебный UNDO и RAC. вот причина, распилы тут не причем.
«не подходящая под тяжелый поток транзакций»
Погугли для саморазвития какой поток транзакций у Яндекса, Скайпа, Авито :) Ну да, это не финансовые данные. Но нагрузка явно больше, чем у большинства банков. Итого вернулись к началу — «боятся ответственность брать на свою Ж».
Кстати, волшебный RAC это тот, что который Ораклисты пишут: My general advice: DON’T USE RAC? blog.2ndquadrant.com/oracle-high-availability-concepts-postgresql
Погугли для саморазвития какой поток транзакций у Яндекса, Скайпа, Авито :) Ну да, это не финансовые данные. Но нагрузка явно больше, чем у большинства банков. Итого вернулись к началу — «боятся ответственность брать на свою Ж».
Кстати, волшебный RAC это тот, что который Ораклисты пишут: My general advice: DON’T USE RAC? blog.2ndquadrant.com/oracle-high-availability-concepts-postgresql
школоло, пойди сначала разберись, чем фин транкции отличаются от веба, с его примитивными инсертами на IL RC. там и мусору неоткуда взяться.
по рац, блогер с бэкраундом постгреса слышал «at least qualified Oracle experts tell me so» (тм). аргумент суръезный. зачет.
по рац, блогер с бэкраундом постгреса слышал «at least qualified Oracle experts tell me so» (тм). аргумент суръезный. зачет.
«Примитивные инсерты» у всех вменяемых людей давно в носкле.
А ораклизы, как вижу, в английский не умеют. На: RAC specialist gave me the usual answer “You are not confident because the previous integrators were bad but with me it will be different. I asked the customer to buy new storage, I will follow the best practices and things will run”.
The previous integrators were platinum partners of Oracle and as I expected the specialist did nothing better than them. We had more incidents causing downtime with the RAC database than with the single instances databases left on the old AIX server.
The reasons are easy to understand but often ignored. A single Oracle Database instance is not simple but RAC completely breaks the KISS principle, it is a complex thing to deploy and to administer. You can have as many nodes as you want, Grid Infrastructure itself will remain a logical single point of failure. Every software has bugs, especially if it is complex and Grid infrastructure is no exception.
А ораклизы, как вижу, в английский не умеют. На: RAC specialist gave me the usual answer “You are not confident because the previous integrators were bad but with me it will be different. I asked the customer to buy new storage, I will follow the best practices and things will run”.
The previous integrators were platinum partners of Oracle and as I expected the specialist did nothing better than them. We had more incidents causing downtime with the RAC database than with the single instances databases left on the old AIX server.
The reasons are easy to understand but often ignored. A single Oracle Database instance is not simple but RAC completely breaks the KISS principle, it is a complex thing to deploy and to administer. You can have as many nodes as you want, Grid Infrastructure itself will remain a logical single point of failure. Every software has bugs, especially if it is complex and Grid infrastructure is no exception.
дитетко, ни в одном банке ты не найдешь nosql процессящих транзакции. и поменьше слушай блогеров, software bug завалит все ноды nosql точно так же. я лично на хадупе проверял.
Ты не только английский не умеешь, гугл тоже. ОК, на:
www.computerworlduk.com/data/jpmorgan-consolidates-derivative-trade-systems-with-nosql-database-3601382
или например www.fisglobal.com/solutions/banking-and-wealth/services/database-engine
или например
www.slideshare.net/PeterLawrey/no-sql-in-hft
www.computerworlduk.com/data/jpmorgan-consolidates-derivative-trade-systems-with-nosql-database-3601382
или например www.fisglobal.com/solutions/banking-and-wealth/services/database-engine
или например
www.slideshare.net/PeterLawrey/no-sql-in-hft
ок, ты не врубаешься что такое банк и что такое трейдинг система. для школоло это нормально.
для нешкололо ты очень плохо читаешь. второй пример — банковская сеть по всему миру. а в трейдинге нагрузки такие, что 99% банков и не снилось, не ты ли усирался что никто кроме могучего оракла не потянет? ещё тебе домашнее задание — погуглить про банки конкретно на Постгресе, такое тоже есть. упс?
трейдинг это специфическая задача с одними инсертами, без надобности полноценного acid. т.е. ты по прежнему не понимаешь чем задачи процессинга банковских транзакций от второстипенных систем отличаются. в мелких банках на постгресе вполне могут быть второстепенные системы типа HR или CRM, но не процессинг банковских транзакций.
ладно, утомили школьники, по блогам RACы изучающие.
ладно, утомили школьники, по блогам RACы изучающие.
Мы смотрим на все современные системы управления базами данных, в том числе на российские и open source. Для «сурового прома» альтернативы Oracle пока не видим.
Подобных систем в России единицы.
Коллеги, это именно в ВТБ? Или в намертво приклееной к ВТБ процессинговой компании «мультикарта»?
PS: в банках безраздельно властвует Oracle. Очень плотно. Так сложилось исторически.
Бывают потуги PostgreSQL, встречаются проекты на MS SQL. Но высоконагруженные системы, например карточный процессинг — только Oracle без вариантов. Смена Oracle на что-то другое, как правило, даже не рассматривается.
Коллеги, это именно в ВТБ? Или в намертво приклееной к ВТБ процессинговой компании «мультикарта»?
PS: в банках безраздельно властвует Oracle. Очень плотно. Так сложилось исторически.
Бывают потуги PostgreSQL, встречаются проекты на MS SQL. Но высоконагруженные системы, например карточный процессинг — только Oracle без вариантов. Смена Oracle на что-то другое, как правило, даже не рассматривается.
Sign up to leave a comment.
Укрощай и консолидируй: история переезда на Oracle Supercluster