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

[iDesperado]

не знаю чего народ на zVad так накинулся. У меня есть кое-какой опыт с Oracle, БД размером около терабайта вызвала нехилую головную боль у наших БД админов. Так оказалось что БД была в составе SIEM, что означало добавление сотен записей в секунду и выполнение постоянно нескольких десятков queries (alerts). В результате получилось, что БД перестала бекапится стандартными средствами Oracle. Бекап просто никогда не заканчивался! В итоге пришлось купить какую-то специализированную карту (непомню что за вендор был), которая позволяла как-то в обход стандартных средств делать с неё слепок. Сервер на котором все это "летало" был очень мощный - HP, что-то около полсотни коров, памяти от пуза, единственно, что диски были не SSD. Потом HP нафиг выкинул Oracle и поставил свой какой-то самопальный БД движок. Проблема ушла

да потому, что это детский сад. ну реально, весь мир выкинул нафиг всякие db2, informix, sybase и прочие рсубд. оракл по сути сожрал абсолютно все в финсекторе. все банки, все биржи, все что хоть как-то связано с большими деньгами сидит на оракле. реально кто-то думает, что там не работает бэкап и пара сотен записей в секунду может хотя бы в теории создать сложности ? ну смешно же.
что такое хот бэкап у оракла ? если бэкап делает утилита rman он останавливает запись в датафайлы, копирует их, копирует redo log. все. эта утилита отлажена в начале 90х и она работает. в банке, на бирже, у меня. там нечему сломаться. это оракл. эту технологию каждый день серьезные дядьки тестируют в банках. как и репликацию.
и еще раз, почему серьезные дядьки выкинули db2 и весь финсектор пересадили на оракл ? в первую очередь именно потому, что там такие вещи работают как часы.

[Flash-04]

Да плевать мне на ваши рассуждения. На практике, а не в теории нихрена он не работает нормально с большими БД где идет поток инсертов. Перестают нормально работать репорты, этой же сволочи нужен consistency, то есть он старается сделать временный слепок БД на время репорта. Другое дело что к примеру в SIEM это нафиг не надо, так как в момента создания репорта он уже устарел и это надо иметь ввиду.
А с бекапом я рассказываю реальный случай, у нас весь штат DBA ломал голову что с этой фигнёй делать. Они бы с радостью забили делать бекап, но не могли и кстати хорошо, один раз он таки понадобился.

[Palych]

этой же сволочи нужен consistency, то есть он старается сделать временный слепок БД на время репорта. Другое дело что к примеру в SIEM это нафиг не надо, так как в момента создания репорта он уже устарел и это надо иметь ввиду

Получается что дело не в Oracle было, а в RDBMS как классе?

[Flash-04]

Похоже что да. Но там много чего добавилось.

[iDesperado]

Да плевать мне на ваши рассуждения. На практике, а не в теории нихрена он не работает нормально с большими БД где идет поток инсертов. Перестают нормально работать репорты, этой же сволочи нужен consistency, то есть он старается сделать временный слепок БД на время репорта. Другое дело что к примеру в SIEM это нафиг не надо, так как в момента создания репорта он уже устарел и это надо иметь ввиду.
А с бекапом я рассказываю реальный случай, у нас весь штат DBA ломал голову что с этой фигнёй делать. Они бы с радостью забили делать бекап, но не могли и кстати хорошо, один раз он таки понадобился.

на практике какая-нить нью-йоркская товарная биржа обслуживает в миллионы раз больший поток транзакций и нормально у них работают репорты. просто задумайтесь, разница в нагрузке миллионы. ну а для верификации есть тесты tpc-c, как раз симуляция биржи. на верхних строчках системы обслуживавшие миллионы tps, при этом тоже по правилам теста проверяется восстановление системы на момент сбоя под нагрузкой. почему у них тоже не смотря на миллионы tps бэкапы и рестор исправно работал все эти десятилетия.
да, дело не в рассуждениях, дело в фактах. причем факты, которые проверял не фанбой оракла с привета, а серьезные дядьки с tpc.org

а с бэкапом - типичная история новичков - увидеть rman скрипты, неосилить, начитаться рекламы и натыркать мышой в гуи сторидж системы снепшоты онлайн, которые обещают интеграцию с ораклом. вангую, что история "бекапится стандартными средствами" (тм) из этой серии, как обычно.

[Komissar]

мне тоже удивительно, что были такие проблемы с относительно небольшой (всего 1 Тб) БД, тем более на адекватном железе. Может, ДБА был неопытный?

[iDesperado]

мне тоже удивительно, что были такие проблемы с относительно небольшой (всего 1 Тб) БД, тем более на адекватном железе. Может, ДБА был неопытный?

1Tb это вся база, при этом события идеально партиционируется по дате, можно хоть по часам нарезать партиции. т.е. даже если разработчики полные неадекваты и каждый "выполнение постоянно нескольких десятков queries (alerts)" фигачит фуллскан всей партиции - все равно тормозов не добиться, ведь активная партиция столь крошечной бд гарантированно влазит в память целиком.

[Komissar]

мне тоже удивительно, что были такие проблемы с относительно небольшой (всего 1 Тб) БД, тем более на адекватном железе. Может, ДБА был неопытный?

1Tb это вся база, при этом события идеально партиционируется по дате, можно хоть по часам нарезать партиции. т.е. даже если разработчики полные неадекваты и каждый "выполнение постоянно нескольких десятков queries (alerts)" фигачит фуллскан всей партиции - все равно тормозов не добиться, ведь активная партиция столь крошечной бд гарантированно влазит в память целиком.

нет, ну неадекваты среди DBA сумеют и БД из 100000 записей сделать тормозной.

[Flash-04]

мне тоже удивительно, что были такие проблемы с относительно небольшой (всего 1 Тб) БД, тем более на адекватном железе. Может, ДБА был неопытный?

да, причём все Я не DBA ни разу, проблема была сразу эскалирована "куда надо".
Кстати, из воспоминаний, один из пачей Оракла нахрен сломал БД. Это кстати потом было признано официально. Я откатывал апдейт (прибавилось седых волос) и ждал следующего пача с исправлениями.

[Flash-04]

мне тоже удивительно, что были такие проблемы с относительно небольшой (всего 1 Тб) БД, тем более на адекватном железе. Может, ДБА был неопытный?

1Tb это вся база, при этом события идеально партиционируется по дате, можно хоть по часам нарезать партиции. т.е. даже если разработчики полные неадекваты и каждый "выполнение постоянно нескольких десятков queries (alerts)" фигачит фуллскан всей партиции - все равно тормозов не добиться, ведь активная партиция столь крошечной бд гарантированно влазит в память целиком.

мне нравится как вы "все знаете". Там все было сделано по правилам: и БД нарезана по кусочкам и куча оптимизаций, да дофига всего. А в целом работало всё это не очень.
А, вот! из общения с другими их клиентами, летала вся эта хренотень на специальном железе от Оракла/SUN - ZFS. Но стоило оно... мама дорогая... Моя небедная организация не стала бы даже пропозал рассматривать.

[Flash-04]

1Tb это вся база, при этом события идеально партиционируется по дате, можно хоть по часам нарезать партиции. т.е. даже если разработчики полные неадекваты и каждый "выполнение постоянно нескольких десятков queries (alerts)" фигачит фуллскан всей партиции - все равно тормозов не добиться, ведь активная партиция столь крошечной бд гарантированно влазит в память целиком.

HP делал продукт. Им оказалось в итоге легче сделать новый движок "с нуля". Так что не всё так просто.

[zVlad]

Может кто-нибудь знает как управлять значением лимита по CPU time устанавливаемого когда задачи запускаются из ggsci. Оно устанавливает 15 минут и задачи абэдятся по веремени CPU. Native запуск берет время от системы и управляется просто. Это функция setrlimit(). В документации найти не удалось.

[iDesperado]

да, причём все Я не DBA ни разу, проблема была сразу эскалирована "куда надо".
Кстати, из воспоминаний, один из пачей Оракла нахрен сломал БД. Это кстати потом было признано официально. Я откатывал апдейт (прибавилось седых волос) и ждал следующего пача с исправлениями.

в оракле всегда была тьма багов. в мое время у dba было табу ставить первый релиз, можно было ставить 9.2, 10.2, 11.2 - но баги были в обвязке, оптимизаторе и прочей шелухе. ядро всегда у оракла было супер и бэкап/рестор всегда было святое. за 20 лет я видел лишь одну проблему с бэкап/рестор - ошибку на мутной ос от novel. я больше нигде не видел новел, но и там все решилось банальным обновлением версии оракла.
в этом и сила оракла - когда ты наступил на граблю, у тебя есть гарантия, что ты 100501, даже если у тебя ось от novel, о существовании которой ты еще 5 минут назад не подозревал.

мне нравится как вы "все знаете". Там все было сделано по правилам: и БД нарезана по кусочкам и куча оптимизаций, да дофига всего. А в целом работало всё это не очень.
А, вот! из общения с другими их клиентами, летала вся эта хренотень на специальном железе от Оракла/SUN - ZFS. Но стоило оно... мама дорогая... Моя небедная организация не стала бы даже пропозал рассматривать.

и моему работодателю это нравится. и нравится именно потому, что я в курсе в первую очередь об альтернативах. такого рода системы сейчас строят на кафке и спарк, с записью в облако, бывает в hadoop/hdfs. у нас подобного рода система пишет алерты в solr индекс на hadoop. да, сейчас по системам, где не нужны транзакции и согласованный набор, действительно нет особого смысла платить ораклу за каждое ядрышко + партишенинг + стенбай. но. но ! это совершенно не значит, что у оракла могут быть шансы сдохнуть на крошеной бд в 1Т, где замечательно получается партционировать не виликий поток данных.
а так да, под анализ потока данных есть более эффективные и что более важно дешевые фреймворки, даже совсем фанбои оракла это видят. HP в этом плане просто последовали за хайпом и логикой.

[Flash-04]

Вы так и не поняли что дело вовсе не в хайпе. Чтобы вам было понятнее, продукт о котором я говорю - ArcSight. Можете погуглить, почитать, хотя часть ресурсов уже недоступна. Я когда то плотно сидел на форуме где кастомеры обсуждали проблемы и решения продукта. К 5й версии отчётливо появилась проблема, что продукт не масштабируем. При том потоке данных что был у нас, БД стала бутылочным горлышком. Я тогда потратил довольно много времени, чтобы правильно получать и анализировать диагностику, и пришёл к выводу, что основной тормоз на записи данных. Процессоры сервера около половины времени простаивали ожидая когда данные запишутся. Утверждалось что ssd частично решали проблему, производительность увеличивалась, хотя как я отметил максимум достигался только на железе от самого Оракла и допиливании БД напильником под него.
То есть проблема была системная. HP полностью заменила движок БД в 6 версии и выложила большую статью где сравнивала версии по производительности. Новый движок делал в 5(!) раз меньше дисковых операций на одну операцию записи, что позволило использовать и обычные HDD. Мы перешли на 6 версию и с тех пор я забыл про Оракл как страшный сон.

[iDesperado]

Вы так и не поняли что дело вовсе не в хайпе. Чтобы вам было понятнее, продукт о котором я говорю - ArcSight. Можете погуглить, почитать, хотя часть ресурсов уже недоступна. Я когда то плотно сидел на форуме где кастомеры обсуждали проблемы и решения продукта. К 5й версии отчётливо появилась проблема, что продукт не масштабируем. При том потоке данных что был у нас, БД стала бутылочным горлышком. Я тогда потратил довольно много времени, чтобы правильно получать и анализировать диагностику, и пришёл к выводу, что основной тормоз на записи данных. Процессоры сервера около половины времени простаивали ожидая когда данные запишутся. Утверждалось что ssd частично решали проблему, производительность увеличивалась, хотя как я отметил максимум достигался только на железе от самого Оракла и допиливании БД напильником под него.
То есть проблема была системная. HP полностью заменила движок БД в 6 версии и выложила большую статью где сравнивала версии по производительности. Новый движок делал в 5(!) раз меньше дисковых операций на одну операцию записи, что позволило использовать и обычные HDD. Мы перешли на 6 версию и с тех пор я забыл про Оракл как страшный сон.

ну и что вы от меня хотите ? доказать, что у оракла сложности записать аппендом в отдельную партицию монотонно возрастющие записи событий ? ну не докажете, я говорю, вон tpc-c просовывают десятки миллионов сложных транзакций, в том числе и с аптдейтми. десятки миллионов в секунду. понимете. десятки.
если бы вы там чего-то анализировали, вы бы нам рассказали, что индусы из HP сделали не так. проблема была не системная, а в людях, которые явно не писали аппендом поток событий, как это в любом учебнике советуют, а наколхозили что-то совсем кривое, вероятно с кривыми джоинами в процессе записи, с тучей foreign keys. ну такое в кровавом энтерпрайзе сплошь и рядом. но это не отменяет спсобность оракла выдавать миллионы простых tps даже на ноутбучном железе.
еще раз, оракл запросто спсобен петабайты в день писать на HDD, если ты хоть немного соображаешь как оно все в связке с железом работает. в рдбмс при серьезном потоке записи нельзя таблицы обвешивать FK, джоинами и т.п.