Мы уходим с майнфрайм.

iDesperado
Уже с Приветом
Posts: 1422
Joined: 28 Nov 2008 17:50

Re: Мы уходим с майнфрайм.

Post by iDesperado »

valchkou wrote: 11 Dec 2020 00:22 Железо обошлось почти так же, с одним отличием - у кассандры 6 нод и high availability, а у оракла за те же бабки только одна гигантская VM.
Мигрировать с DB2 на Оракл считаю изначально было ошибкой. Но видимо бабло уже попилено. Жаль что меня к столу не пригласили :D
у оракла за те бабки в первую очередь acid и консистентное чтение. плюс гарантия что завтра, если что-то появится это что-то просто добавят в табличку и приджойнят. у noslq в этом плане все несколько сложнее.
оракл уже начинает уходить в легаси, но сдает позиции снизу, где з 4 месяца переписать что-то можно.
User avatar
valchkou
Уже с Приветом
Posts: 4185
Joined: 27 Apr 2011 03:43
Location: Сергели ->Chicago

Re: Мы уходим с майнфрайм.

Post by valchkou »

iDesperado wrote: 11 Dec 2020 21:59
valchkou wrote: 11 Dec 2020 00:22 Железо обошлось почти так же, с одним отличием - у кассандры 6 нод и high availability, а у оракла за те же бабки только одна гигантская VM.
Мигрировать с DB2 на Оракл считаю изначально было ошибкой. Но видимо бабло уже попилено. Жаль что меня к столу не пригласили :D
у оракла за те бабки в первую очередь acid и консистентное чтение. плюс гарантия что завтра, если что-то появится это что-то просто добавят в табличку и приджойнят. у noslq в этом плане все несколько сложнее.
оракл уже начинает уходить в легаси, но сдает позиции снизу, где з 4 месяца переписать что-то можно.
конечно речь тут совсем не о том что все нужно на кассандру или типа того переводить. Но оракл был явно оверкил под ту группу задач.
Кроме того разработчики заюзали какуюто фитчу в своих плскл, которая только с интерпрайз лицензией доступна.
в кассандре тоже можно сделать консистентное чтение задать CONSYSTENCY_LEVEL: ALL и пока все копии не запишутся, чтение их не увидит.
вот джойнить действительно проблематично.
У нас было конретное требование - zero down time.
Да с ораклом еще одна засада была, тестовые енв, лицензия на них такая же была, ну или близко по цене.
Кассандра бесплатно и к тому же динамически можно поднимать и убивать VM запросто для экономии средств. С ораклом не скажу, не знаю как у них там решается.
короче за два года как вышли в продакшн, никто к базе не приближался, один раз проапгрейдили с версии 2 до 3 и то на живую, zero down time.
iDesperado
Уже с Приветом
Posts: 1422
Joined: 28 Nov 2008 17:50

Re: Мы уходим с майнфрайм.

Post by iDesperado »

valchkou wrote: 12 Dec 2020 00:15 в кассандре тоже можно сделать консистентное чтение задать CONSYSTENCY_LEVEL: ALL и пока все копии не запишутся, чтение их не увидит.
этого мало. оракл, за счет UNDO структуры, выдает согласованный набор на момент старта запроса (транзакции) и это гарантируется и на RAC кластере. а касандра на сколько помню просто выдает все, что закоммитилось. т.е. если писатель изменил запись и запись переехала из одной партиции в другую то соседний читатель запросто может получить эту запись дважды. в варианте до изменения и после.
valchkou wrote: 12 Dec 2020 00:15 У нас было конретное требование - zero down time.
Да с ораклом еще одна засада была, тестовые енв, лицензия на них такая же была, ну или близко по цене.
ну в кровавом ентерпрайзе все таки не один узел обычно, хотя бы standby настраивают и на простаивающем standby узле всякие dev/test
но это конечно не то что можно с бесплатным софтом вытворять, когда мы на каждый интегрейшен тест целый хадуп в докере поднимаем. интересно что это почти ничего не стоит по сравнению с "embedded" mariadb.
User avatar
Dmitry67
Уже с Приветом
Posts: 28283
Joined: 29 Aug 2000 09:01
Location: SPB --> Gloucester, MA, US --> SPB --> Paris

Re: Мы уходим с майнфрайм.

Post by Dmitry67 »

Все таки у MS SQL хорошо сделано, что в dev edition все фичи доступны, а не как в оракле
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
iDesperado
Уже с Приветом
Posts: 1422
Joined: 28 Nov 2008 17:50

Re: Мы уходим с майнфрайм.

Post by iDesperado »

Dmitry67 wrote: 12 Dec 2020 11:08 Все таки у MS SQL хорошо сделано, что в dev edition все фичи доступны, а не как в оракле
а что это меняет, если dev edition для персонального пользования ? dev/uat среда то обычно где-то на шаред сервере и в пайплайнах jenkins и gitlab.
User avatar
Dmitry67
Уже с Приветом
Posts: 28283
Joined: 29 Aug 2000 09:01
Location: SPB --> Gloucester, MA, US --> SPB --> Paris

Re: Мы уходим с майнфрайм.

Post by Dmitry67 »

iDesperado wrote: 12 Dec 2020 11:45
Dmitry67 wrote: 12 Dec 2020 11:08 Все таки у MS SQL хорошо сделано, что в dev edition все фичи доступны, а не как в оракле
а что это меняет, если dev edition для персонального пользования ? dev/uat среда то обычно где-то на шаред сервере и в пайплайнах jenkins и gitlab.
Я про фразу:

Да с ораклом еще одна засада была, тестовые енв, лицензия на них такая же была, ну или близко по цене.

Дев всегда можно и нужно толковать расширительно
Не PROD? Не Client facing? Идет отладка? Значит DEV
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
deev_a_v
Уже с Приветом
Posts: 4660
Joined: 07 Apr 2018 15:16

Re: Мы уходим с майнфрайм.

Post by deev_a_v »

iDesperado wrote: 12 Dec 2020 11:45
Dmitry67 wrote: 12 Dec 2020 11:08 Все таки у MS SQL хорошо сделано, что в dev edition все фичи доступны, а не как в оракле
а что это меняет, если dev edition для персонального пользования ?
Неверно.

Microsoft allows you to run any nonproduction workloads under Developer Edition, which is free, as long as your workloads aren't running production. This includes testing, training and user acceptance training.
zVlad
Уже с Приветом
Posts: 16196
Joined: 30 Apr 2003 16:43

Re: Мы уходим с майнфрайм.

Post by zVlad »

liamkin wrote: 10 Dec 2020 17:02
zVlad wrote: 28 Nov 2020 17:43 Оракла пока конь не валялся. У Оракл ДБА (а их два на миграции задействовано, один на OTG, второй на GoldenGate) нет времени и он ждет курсов по GoldenGate и эксперта из Оракл в помощь. Реально будем начинать в середине декабря.
Давайте по теме скажу. ГолденГейт очень дорогой - Голден не зря в названии. Менеджера похоже получили откат от Оракла. Требуйте свою долю! :)
Для передачи данных массово люди пользуют sqlloader - он бесплатно идет в составе Оракл РДБМС. И работает он очень быстро.
Если есть деньги, то нужно/правильно использовать ETL - DataStage или Informatica.
Оптимизация Оракла - отдельная задача, но решаемая, там есть встроенный генератор отчетов AWR, где говорится какие запросы жрут диск или ЦПУ.
8ядер и 32гб - ни о чем. У меня в домашнем компе 12 ядер-24 потока и 32 гб памяти. AMD 3900x -$400, RAM- $110.
Хотите нормальной Оракловой производительности - не жалейте памяти и ЦПУ. И смотрите отчеты AWR.
Работа с GoldenGate началась. GG работает иначе чем OTG и быстрее. GG больше жрет ЦПУ мэйнфрэйма и пихает на ремоте сервер быстрее. Вообще эти два способа очень разные и эффект разный.

С Informatica мы работали когда это еще называлось иначе. Сейчас мы работаем с IBM InfoSphere Data Replication. Это лучше чем Informatica и лучше чем GG.
Оптимизация репликации в том смысле как оптимизация произвольных запросов для бизнес логики не имеет смысла поскольку это тупое копирование изначально и потом передача изменений. Ничего больше. На этапе начальной загрузки на стороны исходника это тупой table scan, на таргет стороне чем меньше индексов тем лучше. В дальнейшем на таргет нужен лишь уникальный индекс, больше ничего. Памяти даже для репликации особо не нужнo.
zVlad
Уже с Приветом
Posts: 16196
Joined: 30 Apr 2003 16:43

Re: Мы уходим с майнфрайм.

Post by zVlad »

mskmel wrote: 09 Dec 2020 06:10
zVlad wrote: 08 Dec 2020 22:59Данные переливались через 1Gb канал.
За условные 12 часов переливаются все 4ТБ в 4 ядра в виртуалке. Вопрос "как переливали" - остаётся открытым.
...
Ребята на днях переливали две таких таблицы одновременно. получилось 13 часов вместо 12.5. Переливали через Oracle Transparent Gateway.
User avatar
Flash-04
Уже с Приветом
Posts: 63377
Joined: 03 Nov 2004 05:31
Location: RU -> Toronto, ON

Re: Мы уходим с майнфрайм.

Post by Flash-04 »

не знаю чего народ на zVad так накинулся. У меня есть кое-какой опыт с Oracle, БД размером около терабайта вызвала нехилую головную боль у наших БД админов. Так оказалось что БД была в составе SIEM, что означало добавление сотен записей в секунду и выполнение постоянно нескольких десятков queries (alerts). В результате получилось, что БД перестала бекапится стандартными средствами Oracle. Бекап просто никогда не заканчивался! В итоге пришлось купить какую-то специализированную карту (непомню что за вендор был), которая позволяла как-то в обход стандартных средств делать с неё слепок. Сервер на котором все это "летало" был очень мощный - HP, что-то около полсотни коров, памяти от пуза, единственно, что диски были не SSD. Потом HP нафиг выкинул Oracle и поставил свой какой-то самопальный БД движок. Проблема ушла 8)
Not everyone believes what I believe but my beliefs do not require them to.
iDesperado
Уже с Приветом
Posts: 1422
Joined: 28 Nov 2008 17:50

Re: Мы уходим с майнфрайм.

Post by iDesperado »

Flash-04 wrote: 19 Dec 2020 15:58 не знаю чего народ на zVad так накинулся. У меня есть кое-какой опыт с Oracle, БД размером около терабайта вызвала нехилую головную боль у наших БД админов. Так оказалось что БД была в составе SIEM, что означало добавление сотен записей в секунду и выполнение постоянно нескольких десятков queries (alerts). В результате получилось, что БД перестала бекапится стандартными средствами Oracle. Бекап просто никогда не заканчивался! В итоге пришлось купить какую-то специализированную карту (непомню что за вендор был), которая позволяла как-то в обход стандартных средств делать с неё слепок. Сервер на котором все это "летало" был очень мощный - HP, что-то около полсотни коров, памяти от пуза, единственно, что диски были не SSD. Потом HP нафиг выкинул Oracle и поставил свой какой-то самопальный БД движок. Проблема ушла 8)
да потому, что это детский сад. ну реально, весь мир выкинул нафиг всякие db2, informix, sybase и прочие рсубд. оракл по сути сожрал абсолютно все в финсекторе. все банки, все биржи, все что хоть как-то связано с большими деньгами сидит на оракле. реально кто-то думает, что там не работает бэкап и пара сотен записей в секунду может хотя бы в теории создать сложности ? ну смешно же.
что такое хот бэкап у оракла ? если бэкап делает утилита rman он останавливает запись в датафайлы, копирует их, копирует redo log. все. эта утилита отлажена в начале 90х и она работает. в банке, на бирже, у меня. там нечему сломаться. это оракл. эту технологию каждый день серьезные дядьки тестируют в банках. как и репликацию.
и еще раз, почему серьезные дядьки выкинули db2 и весь финсектор пересадили на оракл ? в первую очередь именно потому, что там такие вещи работают как часы.
User avatar
Flash-04
Уже с Приветом
Posts: 63377
Joined: 03 Nov 2004 05:31
Location: RU -> Toronto, ON

Re: Мы уходим с майнфрайм.

Post by Flash-04 »

Да плевать мне на ваши рассуждения. На практике, а не в теории нихрена он не работает нормально с большими БД где идет поток инсертов. Перестают нормально работать репорты, этой же сволочи нужен consistency, то есть он старается сделать временный слепок БД на время репорта. Другое дело что к примеру в SIEM это нафиг не надо, так как в момента создания репорта он уже устарел и это надо иметь ввиду.
А с бекапом я рассказываю реальный случай, у нас весь штат DBA ломал голову что с этой фигнёй делать. Они бы с радостью забили делать бекап, но не могли :) и кстати хорошо, один раз он таки понадобился.
Not everyone believes what I believe but my beliefs do not require them to.
Palych
Уже с Приветом
Posts: 13975
Joined: 16 Jan 2001 10:01

Re: Мы уходим с майнфрайм.

Post by Palych »

Flash-04 wrote: 20 Dec 2020 03:25 этой же сволочи нужен consistency, то есть он старается сделать временный слепок БД на время репорта. Другое дело что к примеру в SIEM это нафиг не надо, так как в момента создания репорта он уже устарел и это надо иметь ввиду
Получается что дело не в Oracle было, а в RDBMS как классе?
User avatar
Flash-04
Уже с Приветом
Posts: 63377
Joined: 03 Nov 2004 05:31
Location: RU -> Toronto, ON

Re: Мы уходим с майнфрайм.

Post by Flash-04 »

Похоже что да. Но там много чего добавилось.
Not everyone believes what I believe but my beliefs do not require them to.
iDesperado
Уже с Приветом
Posts: 1422
Joined: 28 Nov 2008 17:50

Re: Мы уходим с майнфрайм.

Post by iDesperado »

Flash-04 wrote: 20 Dec 2020 03:25 Да плевать мне на ваши рассуждения. На практике, а не в теории нихрена он не работает нормально с большими БД где идет поток инсертов. Перестают нормально работать репорты, этой же сволочи нужен consistency, то есть он старается сделать временный слепок БД на время репорта. Другое дело что к примеру в SIEM это нафиг не надо, так как в момента создания репорта он уже устарел и это надо иметь ввиду.
А с бекапом я рассказываю реальный случай, у нас весь штат DBA ломал голову что с этой фигнёй делать. Они бы с радостью забили делать бекап, но не могли :) и кстати хорошо, один раз он таки понадобился.
на практике какая-нить нью-йоркская товарная биржа обслуживает в миллионы раз больший поток транзакций и нормально у них работают репорты. просто задумайтесь, разница в нагрузке миллионы. ну а для верификации есть тесты tpc-c, как раз симуляция биржи. на верхних строчках системы обслуживавшие миллионы tps, при этом тоже по правилам теста проверяется восстановление системы на момент сбоя под нагрузкой. почему у них тоже не смотря на миллионы tps бэкапы и рестор исправно работал все эти десятилетия.
да, дело не в рассуждениях, дело в фактах. причем факты, которые проверял не фанбой оракла с привета, а серьезные дядьки с tpc.org

а с бэкапом - типичная история новичков - увидеть rman скрипты, неосилить, начитаться рекламы и натыркать мышой в гуи сторидж системы снепшоты онлайн, которые обещают интеграцию с ораклом. вангую, что история "бекапится стандартными средствами" (тм) из этой серии, как обычно.
User avatar
Komissar
Уже с Приветом
Posts: 65198
Joined: 12 Jul 2002 16:38
Location: г.Москва, ул. Б. Лубянка, д.2

Re: Мы уходим с майнфрайм.

Post by Komissar »

мне тоже удивительно, что были такие проблемы с относительно небольшой (всего 1 Тб) БД, тем более на адекватном железе. Может, ДБА был неопытный?
iDesperado
Уже с Приветом
Posts: 1422
Joined: 28 Nov 2008 17:50

Re: Мы уходим с майнфрайм.

Post by iDesperado »

Komissar wrote: 20 Dec 2020 10:46 мне тоже удивительно, что были такие проблемы с относительно небольшой (всего 1 Тб) БД, тем более на адекватном железе. Может, ДБА был неопытный?
1Tb это вся база, при этом события идеально партиционируется по дате, можно хоть по часам нарезать партиции. т.е. даже если разработчики полные неадекваты и каждый "выполнение постоянно нескольких десятков queries (alerts)" фигачит фуллскан всей партиции - все равно тормозов не добиться, ведь активная партиция столь крошечной бд гарантированно влазит в память целиком.
User avatar
Komissar
Уже с Приветом
Posts: 65198
Joined: 12 Jul 2002 16:38
Location: г.Москва, ул. Б. Лубянка, д.2

Re: Мы уходим с майнфрайм.

Post by Komissar »

iDesperado wrote: 20 Dec 2020 10:57
Komissar wrote: 20 Dec 2020 10:46 мне тоже удивительно, что были такие проблемы с относительно небольшой (всего 1 Тб) БД, тем более на адекватном железе. Может, ДБА был неопытный?
1Tb это вся база, при этом события идеально партиционируется по дате, можно хоть по часам нарезать партиции. т.е. даже если разработчики полные неадекваты и каждый "выполнение постоянно нескольких десятков queries (alerts)" фигачит фуллскан всей партиции - все равно тормозов не добиться, ведь активная партиция столь крошечной бд гарантированно влазит в память целиком.
нет, ну неадекваты среди DBA сумеют и БД из 100000 записей сделать тормозной.
User avatar
Flash-04
Уже с Приветом
Posts: 63377
Joined: 03 Nov 2004 05:31
Location: RU -> Toronto, ON

Re: Мы уходим с майнфрайм.

Post by Flash-04 »

Komissar wrote: 20 Dec 2020 10:46 мне тоже удивительно, что были такие проблемы с относительно небольшой (всего 1 Тб) БД, тем более на адекватном железе. Может, ДБА был неопытный?
да, причём все :D Я не DBA ни разу, проблема была сразу эскалирована "куда надо".
Кстати, из воспоминаний, один из пачей Оракла нахрен сломал БД. Это кстати потом было признано официально. Я откатывал апдейт (прибавилось седых волос) и ждал следующего пача с исправлениями.
Not everyone believes what I believe but my beliefs do not require them to.
User avatar
Flash-04
Уже с Приветом
Posts: 63377
Joined: 03 Nov 2004 05:31
Location: RU -> Toronto, ON

Re: Мы уходим с майнфрайм.

Post by Flash-04 »

iDesperado wrote: 20 Dec 2020 10:57
Komissar wrote: 20 Dec 2020 10:46 мне тоже удивительно, что были такие проблемы с относительно небольшой (всего 1 Тб) БД, тем более на адекватном железе. Может, ДБА был неопытный?
1Tb это вся база, при этом события идеально партиционируется по дате, можно хоть по часам нарезать партиции. т.е. даже если разработчики полные неадекваты и каждый "выполнение постоянно нескольких десятков queries (alerts)" фигачит фуллскан всей партиции - все равно тормозов не добиться, ведь активная партиция столь крошечной бд гарантированно влазит в память целиком.
мне нравится как вы "все знаете". Там все было сделано по правилам: и БД нарезана по кусочкам и куча оптимизаций, да дофига всего. А в целом работало всё это не очень.
А, вот! из общения с другими их клиентами, летала вся эта хренотень на специальном железе от Оракла/SUN - ZFS. Но стоило оно... мама дорогая... Моя небедная организация не стала бы даже пропозал рассматривать.
Not everyone believes what I believe but my beliefs do not require them to.
User avatar
Flash-04
Уже с Приветом
Posts: 63377
Joined: 03 Nov 2004 05:31
Location: RU -> Toronto, ON

Re: Мы уходим с майнфрайм.

Post by Flash-04 »

iDesperado wrote: 20 Dec 2020 10:57 1Tb это вся база, при этом события идеально партиционируется по дате, можно хоть по часам нарезать партиции. т.е. даже если разработчики полные неадекваты и каждый "выполнение постоянно нескольких десятков queries (alerts)" фигачит фуллскан всей партиции - все равно тормозов не добиться, ведь активная партиция столь крошечной бд гарантированно влазит в память целиком.
HP делал продукт. Им оказалось в итоге легче сделать новый движок "с нуля". Так что не всё так просто.
Not everyone believes what I believe but my beliefs do not require them to.
zVlad
Уже с Приветом
Posts: 16196
Joined: 30 Apr 2003 16:43

Re: Мы уходим с майнфрайм.

Post by zVlad »

Может кто-нибудь знает как управлять значением лимита по CPU time устанавливаемого когда задачи запускаются из ggsci. Оно устанавливает 15 минут и задачи абэдятся по веремени CPU. Native запуск берет время от системы и управляется просто. Это функция setrlimit(). В документации найти не удалось.
iDesperado
Уже с Приветом
Posts: 1422
Joined: 28 Nov 2008 17:50

Re: Мы уходим с майнфрайм.

Post by iDesperado »

Flash-04 wrote: 20 Dec 2020 16:35 да, причём все :D Я не DBA ни разу, проблема была сразу эскалирована "куда надо".
Кстати, из воспоминаний, один из пачей Оракла нахрен сломал БД. Это кстати потом было признано официально. Я откатывал апдейт (прибавилось седых волос) и ждал следующего пача с исправлениями.
в оракле всегда была тьма багов. в мое время у dba было табу ставить первый релиз, можно было ставить 9.2, 10.2, 11.2 - но баги были в обвязке, оптимизаторе и прочей шелухе. ядро всегда у оракла было супер и бэкап/рестор всегда было святое. за 20 лет я видел лишь одну проблему с бэкап/рестор - ошибку на мутной ос от novel. я больше нигде не видел новел, но и там все решилось банальным обновлением версии оракла.
в этом и сила оракла - когда ты наступил на граблю, у тебя есть гарантия, что ты 100501, даже если у тебя ось от novel, о существовании которой ты еще 5 минут назад не подозревал.
Flash-04 wrote: 20 Dec 2020 16:37 мне нравится как вы "все знаете". Там все было сделано по правилам: и БД нарезана по кусочкам и куча оптимизаций, да дофига всего. А в целом работало всё это не очень.
А, вот! из общения с другими их клиентами, летала вся эта хренотень на специальном железе от Оракла/SUN - ZFS. Но стоило оно... мама дорогая... Моя небедная организация не стала бы даже пропозал рассматривать.
и моему работодателю это нравится. и нравится именно потому, что я в курсе в первую очередь об альтернативах. такого рода системы сейчас строят на кафке и спарк, с записью в облако, бывает в hadoop/hdfs. у нас подобного рода система пишет алерты в solr индекс на hadoop. да, сейчас по системам, где не нужны транзакции и согласованный набор, действительно нет особого смысла платить ораклу за каждое ядрышко + партишенинг + стенбай. но. но ! это совершенно не значит, что у оракла могут быть шансы сдохнуть на крошеной бд в 1Т, где замечательно получается партционировать не виликий поток данных.
а так да, под анализ потока данных есть более эффективные и что более важно дешевые фреймворки, даже совсем фанбои оракла это видят. HP в этом плане просто последовали за хайпом и логикой.
User avatar
Flash-04
Уже с Приветом
Posts: 63377
Joined: 03 Nov 2004 05:31
Location: RU -> Toronto, ON

Re: Мы уходим с майнфрайм.

Post by Flash-04 »

Вы так и не поняли что дело вовсе не в хайпе. Чтобы вам было понятнее, продукт о котором я говорю - ArcSight. Можете погуглить, почитать, хотя часть ресурсов уже недоступна. Я когда то плотно сидел на форуме где кастомеры обсуждали проблемы и решения продукта. К 5й версии отчётливо появилась проблема, что продукт не масштабируем. При том потоке данных что был у нас, БД стала бутылочным горлышком. Я тогда потратил довольно много времени, чтобы правильно получать и анализировать диагностику, и пришёл к выводу, что основной тормоз на записи данных. Процессоры сервера около половины времени простаивали ожидая когда данные запишутся. Утверждалось что ssd частично решали проблему, производительность увеличивалась, хотя как я отметил максимум достигался только на железе от самого Оракла и допиливании БД напильником под него.
То есть проблема была системная. HP полностью заменила движок БД в 6 версии и выложила большую статью где сравнивала версии по производительности. Новый движок делал в 5(!) раз меньше дисковых операций на одну операцию записи, что позволило использовать и обычные HDD. Мы перешли на 6 версию и с тех пор я забыл про Оракл как страшный сон.
Not everyone believes what I believe but my beliefs do not require them to.
iDesperado
Уже с Приветом
Posts: 1422
Joined: 28 Nov 2008 17:50

Re: Мы уходим с майнфрайм.

Post by iDesperado »

Flash-04 wrote: 21 Dec 2020 14:32 Вы так и не поняли что дело вовсе не в хайпе. Чтобы вам было понятнее, продукт о котором я говорю - ArcSight. Можете погуглить, почитать, хотя часть ресурсов уже недоступна. Я когда то плотно сидел на форуме где кастомеры обсуждали проблемы и решения продукта. К 5й версии отчётливо появилась проблема, что продукт не масштабируем. При том потоке данных что был у нас, БД стала бутылочным горлышком. Я тогда потратил довольно много времени, чтобы правильно получать и анализировать диагностику, и пришёл к выводу, что основной тормоз на записи данных. Процессоры сервера около половины времени простаивали ожидая когда данные запишутся. Утверждалось что ssd частично решали проблему, производительность увеличивалась, хотя как я отметил максимум достигался только на железе от самого Оракла и допиливании БД напильником под него.
То есть проблема была системная. HP полностью заменила движок БД в 6 версии и выложила большую статью где сравнивала версии по производительности. Новый движок делал в 5(!) раз меньше дисковых операций на одну операцию записи, что позволило использовать и обычные HDD. Мы перешли на 6 версию и с тех пор я забыл про Оракл как страшный сон.
ну и что вы от меня хотите ? доказать, что у оракла сложности записать аппендом в отдельную партицию монотонно возрастющие записи событий ? ну не докажете, я говорю, вон tpc-c просовывают десятки миллионов сложных транзакций, в том числе и с аптдейтми. десятки миллионов в секунду. понимете. десятки.
если бы вы там чего-то анализировали, вы бы нам рассказали, что индусы из HP сделали не так. проблема была не системная, а в людях, которые явно не писали аппендом поток событий, как это в любом учебнике советуют, а наколхозили что-то совсем кривое, вероятно с кривыми джоинами в процессе записи, с тучей foreign keys. ну такое в кровавом энтерпрайзе сплошь и рядом. но это не отменяет спсобность оракла выдавать миллионы простых tps даже на ноутбучном железе.
еще раз, оракл запросто спсобен петабайты в день писать на HDD, если ты хоть немного соображаешь как оно все в связке с железом работает. в рдбмс при серьезном потоке записи нельзя таблицы обвешивать FK, джоинами и т.п.

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